Sign in with
Sign up | Sign in
Your question

Replication issues with Win2003

Last response: in Windows 2000/NT
Share
Anonymous
July 13, 2005 5:40:04 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

I am having two issues, not sure if both are related, but here goes. I have
two DCs at one site (Originally DC1 contained the PDC emulator and the RID
Master and DC2 contained the other three) also contained on DC1 was the
'shared' drives. Occasionally users connecting to this site via a point to
point VPN would not be able to access the DC1 which contained the shared
data. They would be able to connect DC2 where their home drives are located.
After rebooting DC1 all would be ok again (for a week or so). Thinking it
would be better to move the PDC emulator and RID masters to DC2 just incase
DC1 decides to go bad. But now when the problem occurs with the VPN connected
users cannot access their home drives which are on DC2 and they can access
the DC1 server. Those I figure that the problem must be with one of the two
fsmo roles that I moved (PDC or RID). Any ideas?

The second thing I found (trying to fix this problem) is that I am having
replication issues with a newly connected site which contains DC3.
Interesting thing that I found with this is that running dcdiag /e on DC2
(the one now containing all the FSMO roles) that it fails the connectivity
test to the DC3 server, all others ok. If I run the dcdiag /e utility from
DC1, all connectivity tests pass including DC3.

From all of this I think there must be a problem with one of the FSMO roles
(PDC or RID) but which and what do I do to correct? Or am I having two
unrelated issues?

Any help would be greatly appreciated,
Jeff
Anonymous
July 14, 2005 11:58:57 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

The FSMO thing should have absolutely nothing to so with this. I'm guessing
only the vpn users are having troubles connecting and that is typically dns
issues. What do the vpn clients have for their primary dns server? It
should be the internal dns server and their secondary should be their ISP
dns server.


Try a few nslookup calls, from a vpn client, on some of the internal
machines to see if they can be found.

--


Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.


"Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
news:57EFF025-255F-4351-8C79-40075B9F30E2@microsoft.com...
>I am having two issues, not sure if both are related, but here goes. I have
> two DCs at one site (Originally DC1 contained the PDC emulator and the RID
> Master and DC2 contained the other three) also contained on DC1 was the
> 'shared' drives. Occasionally users connecting to this site via a point to
> point VPN would not be able to access the DC1 which contained the shared
> data. They would be able to connect DC2 where their home drives are
> located.
> After rebooting DC1 all would be ok again (for a week or so). Thinking it
> would be better to move the PDC emulator and RID masters to DC2 just
> incase
> DC1 decides to go bad. But now when the problem occurs with the VPN
> connected
> users cannot access their home drives which are on DC2 and they can access
> the DC1 server. Those I figure that the problem must be with one of the
> two
> fsmo roles that I moved (PDC or RID). Any ideas?
>
> The second thing I found (trying to fix this problem) is that I am having
> replication issues with a newly connected site which contains DC3.
> Interesting thing that I found with this is that running dcdiag /e on DC2
> (the one now containing all the FSMO roles) that it fails the connectivity
> test to the DC3 server, all others ok. If I run the dcdiag /e utility from
> DC1, all connectivity tests pass including DC3.
>
> From all of this I think there must be a problem with one of the FSMO
> roles
> (PDC or RID) but which and what do I do to correct? Or am I having two
> unrelated issues?
>
> Any help would be greatly appreciated,
> Jeff
Anonymous
July 14, 2005 12:54:16 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Paul,

Thanks for your response. DNS looks ok, I can ping, tracert, nslookup
between all sites and servers. I hope I didn't lead you astray when I
mentioned VPN clients. What we have here is a VPN tunnel from our remote
sites to our site. The people that are connected at these sites connect the
same way as if they were here. (They are not using any vpn client software to
connect). With all that said, I can access all but the one server from the
remote sites. If I try to connect from the remote site I get an error along
the lines of '...the specified resource is no longer accessable' any other
server is fine, if I reboot the server that is unaccessable all will be ok
for a while. I can access this server fine from here. If they were having DNS
issues wouldn't they have problems with the other servers as well? and why
would rebooting fix it?

Thanks again,
Jeff
"Paul Bergson" wrote:

> The FSMO thing should have absolutely nothing to so with this. I'm guessing
> only the vpn users are having troubles connecting and that is typically dns
> issues. What do the vpn clients have for their primary dns server? It
> should be the internal dns server and their secondary should be their ISP
> dns server.
>
>
> Try a few nslookup calls, from a vpn client, on some of the internal
> machines to see if they can be found.
>
> --
>
>
> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
> news:57EFF025-255F-4351-8C79-40075B9F30E2@microsoft.com...
> >I am having two issues, not sure if both are related, but here goes. I have
> > two DCs at one site (Originally DC1 contained the PDC emulator and the RID
> > Master and DC2 contained the other three) also contained on DC1 was the
> > 'shared' drives. Occasionally users connecting to this site via a point to
> > point VPN would not be able to access the DC1 which contained the shared
> > data. They would be able to connect DC2 where their home drives are
> > located.
> > After rebooting DC1 all would be ok again (for a week or so). Thinking it
> > would be better to move the PDC emulator and RID masters to DC2 just
> > incase
> > DC1 decides to go bad. But now when the problem occurs with the VPN
> > connected
> > users cannot access their home drives which are on DC2 and they can access
> > the DC1 server. Those I figure that the problem must be with one of the
> > two
> > fsmo roles that I moved (PDC or RID). Any ideas?
> >
> > The second thing I found (trying to fix this problem) is that I am having
> > replication issues with a newly connected site which contains DC3.
> > Interesting thing that I found with this is that running dcdiag /e on DC2
> > (the one now containing all the FSMO roles) that it fails the connectivity
> > test to the DC3 server, all others ok. If I run the dcdiag /e utility from
> > DC1, all connectivity tests pass including DC3.
> >
> > From all of this I think there must be a problem with one of the FSMO
> > roles
> > (PDC or RID) but which and what do I do to correct? Or am I having two
> > unrelated issues?
> >
> > Any help would be greatly appreciated,
> > Jeff
>
>
>
Related resources
Anonymous
July 14, 2005 5:28:44 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Ok I misunderstood. When it becomes unavailable are there any error
messages on the server that is unavailable? Can you run a tracert to it to
see where it is stopping? I'm guessing it can get all the way but not sure.



--


Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.


"Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
news:FDDB323F-C972-4EF3-BDE3-EA90BCA50441@microsoft.com...
> Paul,
>
> Thanks for your response. DNS looks ok, I can ping, tracert, nslookup
> between all sites and servers. I hope I didn't lead you astray when I
> mentioned VPN clients. What we have here is a VPN tunnel from our remote
> sites to our site. The people that are connected at these sites connect
> the
> same way as if they were here. (They are not using any vpn client software
> to
> connect). With all that said, I can access all but the one server from the
> remote sites. If I try to connect from the remote site I get an error
> along
> the lines of '...the specified resource is no longer accessable' any other
> server is fine, if I reboot the server that is unaccessable all will be ok
> for a while. I can access this server fine from here. If they were having
> DNS
> issues wouldn't they have problems with the other servers as well? and why
> would rebooting fix it?
>
> Thanks again,
> Jeff
> "Paul Bergson" wrote:
>
>> The FSMO thing should have absolutely nothing to so with this. I'm
>> guessing
>> only the vpn users are having troubles connecting and that is typically
>> dns
>> issues. What do the vpn clients have for their primary dns server? It
>> should be the internal dns server and their secondary should be their ISP
>> dns server.
>>
>>
>> Try a few nslookup calls, from a vpn client, on some of the internal
>> machines to see if they can be found.
>>
>> --
>>
>>
>> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
>> news:57EFF025-255F-4351-8C79-40075B9F30E2@microsoft.com...
>> >I am having two issues, not sure if both are related, but here goes. I
>> >have
>> > two DCs at one site (Originally DC1 contained the PDC emulator and the
>> > RID
>> > Master and DC2 contained the other three) also contained on DC1 was the
>> > 'shared' drives. Occasionally users connecting to this site via a point
>> > to
>> > point VPN would not be able to access the DC1 which contained the
>> > shared
>> > data. They would be able to connect DC2 where their home drives are
>> > located.
>> > After rebooting DC1 all would be ok again (for a week or so). Thinking
>> > it
>> > would be better to move the PDC emulator and RID masters to DC2 just
>> > incase
>> > DC1 decides to go bad. But now when the problem occurs with the VPN
>> > connected
>> > users cannot access their home drives which are on DC2 and they can
>> > access
>> > the DC1 server. Those I figure that the problem must be with one of the
>> > two
>> > fsmo roles that I moved (PDC or RID). Any ideas?
>> >
>> > The second thing I found (trying to fix this problem) is that I am
>> > having
>> > replication issues with a newly connected site which contains DC3.
>> > Interesting thing that I found with this is that running dcdiag /e on
>> > DC2
>> > (the one now containing all the FSMO roles) that it fails the
>> > connectivity
>> > test to the DC3 server, all others ok. If I run the dcdiag /e utility
>> > from
>> > DC1, all connectivity tests pass including DC3.
>> >
>> > From all of this I think there must be a problem with one of the FSMO
>> > roles
>> > (PDC or RID) but which and what do I do to correct? Or am I having two
>> > unrelated issues?
>> >
>> > Any help would be greatly appreciated,
>> > Jeff
>>
>>
>>
Anonymous
July 14, 2005 6:52:02 PM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

Tracert does go all the way, I can also ping, by name and IP, in both
directions as well. I got replication errors on the 'unaccessable' server.
Interesting detail; if I use the LDP.exe utility on a 'accessable' DC here
(local to the 'unaccessable' DC), I can connect and authenticate to ANY other
DC (local or remote, including the unaccessable one). If I follow the same
procedure on the 'unaccessable' DC I can connect and authenticate to all
except the remote DC. If I try the same procedure from the remote DC I can
connect and authenticate to all except the 'unaccessable' DC. Note- when I
say 'unaccessable DC' I mean unaccessable from the remote site, it is
accessable from the local site. Also note- how I determine the accessablity
is through My Network Places, the DC is listed, it just gives the unable to
access error mentioned in an eariler post. My thinking is this, since between
the remote DC and the 'unaccessable' DC LDAP cannot be accessed and thus this
won't allow the access to the other servers resourses. The big question, if
this is correct, is what is preventing the two DCs to be able to authenticate
LDAP but can between any other DCs (remote and or local)?

Thanks again for all your help,
Jeff

"Paul Bergson" wrote:

> Ok I misunderstood. When it becomes unavailable are there any error
> messages on the server that is unavailable? Can you run a tracert to it to
> see where it is stopping? I'm guessing it can get all the way but not sure.
>
>
>
> --
>
>
> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
> news:FDDB323F-C972-4EF3-BDE3-EA90BCA50441@microsoft.com...
> > Paul,
> >
> > Thanks for your response. DNS looks ok, I can ping, tracert, nslookup
> > between all sites and servers. I hope I didn't lead you astray when I
> > mentioned VPN clients. What we have here is a VPN tunnel from our remote
> > sites to our site. The people that are connected at these sites connect
> > the
> > same way as if they were here. (They are not using any vpn client software
> > to
> > connect). With all that said, I can access all but the one server from the
> > remote sites. If I try to connect from the remote site I get an error
> > along
> > the lines of '...the specified resource is no longer accessable' any other
> > server is fine, if I reboot the server that is unaccessable all will be ok
> > for a while. I can access this server fine from here. If they were having
> > DNS
> > issues wouldn't they have problems with the other servers as well? and why
> > would rebooting fix it?
> >
> > Thanks again,
> > Jeff
> > "Paul Bergson" wrote:
> >
> >> The FSMO thing should have absolutely nothing to so with this. I'm
> >> guessing
> >> only the vpn users are having troubles connecting and that is typically
> >> dns
> >> issues. What do the vpn clients have for their primary dns server? It
> >> should be the internal dns server and their secondary should be their ISP
> >> dns server.
> >>
> >>
> >> Try a few nslookup calls, from a vpn client, on some of the internal
> >> machines to see if they can be found.
> >>
> >> --
> >>
> >>
> >> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
> >> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
> >> news:57EFF025-255F-4351-8C79-40075B9F30E2@microsoft.com...
> >> >I am having two issues, not sure if both are related, but here goes. I
> >> >have
> >> > two DCs at one site (Originally DC1 contained the PDC emulator and the
> >> > RID
> >> > Master and DC2 contained the other three) also contained on DC1 was the
> >> > 'shared' drives. Occasionally users connecting to this site via a point
> >> > to
> >> > point VPN would not be able to access the DC1 which contained the
> >> > shared
> >> > data. They would be able to connect DC2 where their home drives are
> >> > located.
> >> > After rebooting DC1 all would be ok again (for a week or so). Thinking
> >> > it
> >> > would be better to move the PDC emulator and RID masters to DC2 just
> >> > incase
> >> > DC1 decides to go bad. But now when the problem occurs with the VPN
> >> > connected
> >> > users cannot access their home drives which are on DC2 and they can
> >> > access
> >> > the DC1 server. Those I figure that the problem must be with one of the
> >> > two
> >> > fsmo roles that I moved (PDC or RID). Any ideas?
> >> >
> >> > The second thing I found (trying to fix this problem) is that I am
> >> > having
> >> > replication issues with a newly connected site which contains DC3.
> >> > Interesting thing that I found with this is that running dcdiag /e on
> >> > DC2
> >> > (the one now containing all the FSMO roles) that it fails the
> >> > connectivity
> >> > test to the DC3 server, all others ok. If I run the dcdiag /e utility
> >> > from
> >> > DC1, all connectivity tests pass including DC3.
> >> >
> >> > From all of this I think there must be a problem with one of the FSMO
> >> > roles
> >> > (PDC or RID) but which and what do I do to correct? Or am I having two
> >> > unrelated issues?
> >> >
> >> > Any help would be greatly appreciated,
> >> > Jeff
> >>
> >>
> >>
>
>
>
Anonymous
July 15, 2005 11:11:15 AM

Archived from groups: microsoft.public.win2000.active_directory (More info?)

The reason I had you do the tracert was to try and see if there was some
type of routing issue. I don't think there is anything wrong with the
servers themselves, when you reboot the machine the names are being
repopulated. LDP is ldap (port 389), so some how or other something is not
forwarding or something to that effect. But since it is only port 389 not
all I'm unsure what is being blocked.

I suspect it is a routing issue but could be mistaken. I would target that
as your chief suspect.

--


Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA

This posting is provided "AS IS" with no warranties, and confers no rights.


"Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
news:FB63A06F-CAF0-4F22-8904-25E5C53BDBEC@microsoft.com...
> Tracert does go all the way, I can also ping, by name and IP, in both
> directions as well. I got replication errors on the 'unaccessable' server.
> Interesting detail; if I use the LDP.exe utility on a 'accessable' DC here
> (local to the 'unaccessable' DC), I can connect and authenticate to ANY
> other
> DC (local or remote, including the unaccessable one). If I follow the same
> procedure on the 'unaccessable' DC I can connect and authenticate to all
> except the remote DC. If I try the same procedure from the remote DC I can
> connect and authenticate to all except the 'unaccessable' DC. Note- when I
> say 'unaccessable DC' I mean unaccessable from the remote site, it is
> accessable from the local site. Also note- how I determine the
> accessablity
> is through My Network Places, the DC is listed, it just gives the unable
> to
> access error mentioned in an eariler post. My thinking is this, since
> between
> the remote DC and the 'unaccessable' DC LDAP cannot be accessed and thus
> this
> won't allow the access to the other servers resourses. The big question,
> if
> this is correct, is what is preventing the two DCs to be able to
> authenticate
> LDAP but can between any other DCs (remote and or local)?
>
> Thanks again for all your help,
> Jeff
>
> "Paul Bergson" wrote:
>
>> Ok I misunderstood. When it becomes unavailable are there any error
>> messages on the server that is unavailable? Can you run a tracert to it
>> to
>> see where it is stopping? I'm guessing it can get all the way but not
>> sure.
>>
>>
>>
>> --
>>
>>
>> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in message
>> news:FDDB323F-C972-4EF3-BDE3-EA90BCA50441@microsoft.com...
>> > Paul,
>> >
>> > Thanks for your response. DNS looks ok, I can ping, tracert, nslookup
>> > between all sites and servers. I hope I didn't lead you astray when I
>> > mentioned VPN clients. What we have here is a VPN tunnel from our
>> > remote
>> > sites to our site. The people that are connected at these sites connect
>> > the
>> > same way as if they were here. (They are not using any vpn client
>> > software
>> > to
>> > connect). With all that said, I can access all but the one server from
>> > the
>> > remote sites. If I try to connect from the remote site I get an error
>> > along
>> > the lines of '...the specified resource is no longer accessable' any
>> > other
>> > server is fine, if I reboot the server that is unaccessable all will be
>> > ok
>> > for a while. I can access this server fine from here. If they were
>> > having
>> > DNS
>> > issues wouldn't they have problems with the other servers as well? and
>> > why
>> > would rebooting fix it?
>> >
>> > Thanks again,
>> > Jeff
>> > "Paul Bergson" wrote:
>> >
>> >> The FSMO thing should have absolutely nothing to so with this. I'm
>> >> guessing
>> >> only the vpn users are having troubles connecting and that is
>> >> typically
>> >> dns
>> >> issues. What do the vpn clients have for their primary dns server?
>> >> It
>> >> should be the internal dns server and their secondary should be their
>> >> ISP
>> >> dns server.
>> >>
>> >>
>> >> Try a few nslookup calls, from a vpn client, on some of the internal
>> >> machines to see if they can be found.
>> >>
>> >> --
>> >>
>> >>
>> >> Paul Bergson MCT, MCSE, MCSA, CNE, CNA, CCA
>> >>
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >> "Jeff Wagaman" <JeffWagaman@discussions.microsoft.com> wrote in
>> >> message
>> >> news:57EFF025-255F-4351-8C79-40075B9F30E2@microsoft.com...
>> >> >I am having two issues, not sure if both are related, but here goes.
>> >> >I
>> >> >have
>> >> > two DCs at one site (Originally DC1 contained the PDC emulator and
>> >> > the
>> >> > RID
>> >> > Master and DC2 contained the other three) also contained on DC1 was
>> >> > the
>> >> > 'shared' drives. Occasionally users connecting to this site via a
>> >> > point
>> >> > to
>> >> > point VPN would not be able to access the DC1 which contained the
>> >> > shared
>> >> > data. They would be able to connect DC2 where their home drives are
>> >> > located.
>> >> > After rebooting DC1 all would be ok again (for a week or so).
>> >> > Thinking
>> >> > it
>> >> > would be better to move the PDC emulator and RID masters to DC2 just
>> >> > incase
>> >> > DC1 decides to go bad. But now when the problem occurs with the VPN
>> >> > connected
>> >> > users cannot access their home drives which are on DC2 and they can
>> >> > access
>> >> > the DC1 server. Those I figure that the problem must be with one of
>> >> > the
>> >> > two
>> >> > fsmo roles that I moved (PDC or RID). Any ideas?
>> >> >
>> >> > The second thing I found (trying to fix this problem) is that I am
>> >> > having
>> >> > replication issues with a newly connected site which contains DC3.
>> >> > Interesting thing that I found with this is that running dcdiag /e
>> >> > on
>> >> > DC2
>> >> > (the one now containing all the FSMO roles) that it fails the
>> >> > connectivity
>> >> > test to the DC3 server, all others ok. If I run the dcdiag /e
>> >> > utility
>> >> > from
>> >> > DC1, all connectivity tests pass including DC3.
>> >> >
>> >> > From all of this I think there must be a problem with one of the
>> >> > FSMO
>> >> > roles
>> >> > (PDC or RID) but which and what do I do to correct? Or am I having
>> >> > two
>> >> > unrelated issues?
>> >> >
>> >> > Any help would be greatly appreciated,
>> >> > Jeff
>> >>
>> >>
>> >>
>>
>>
>>
!