Secondary domain controller synching issues.

albanga

Hello again all ,

Just recently we added our first secondary domain controller to our network and since this we have been having lots of difficluties with active directory.

To begin with when i open AD it always looks for the secondary domain controller which is in our other states office, and this takes about 2 minutes to even open.

This however is not our biggest problem, the bigger issue is that when i create an object in AD on the main DC this object cannot be initialised for as long as up to 1 hour.

For example when i create a new user it sets it all up fine but when i go to log on using that account i get username and password errors for about an hour and then it just works.

Then when im finally in i go to set up there outlook account and get exchange errors when they are looking for the username.

Im not sure exactly what the problem is but it seems to be some sort of synching issues with the main and secondary DC that is causing these issues. The thing is this secnodary DC really does not have to talk to the main DC very often. All its really doing is authenticating one office in the morning and also being used to share one directory so it pretty much sits idle all day.

To be honest we dont even really need it, but we had an old server there sitting around gathering dust so decided to turn it into a DC.

So i guess what i am really asking is either does anyone know whats happening and how do we stop it? Or how do I tell it to only synch and talk to our main DC in the eveings so that it stops affecting me during the day.

I hope this makes sense because i am very new to multiple DCs and would like to iron out the issues as we have quite a few branches in different states that seem to be increasing every week and i can only see more of the same in the future.

Treg

Is this new DC on a different Subnet?
Is sites and services properly configured?
What is the WAN link speed between the sites?
IS DNS installed on this new DC?
Is DNS pointing to itself?

strauchr

Check your site set up. Sounds like you haven't configured any sites or subnets and everything is just under one site.

If you have the bandwidth, well I'd just recommend it anyway if its a small business, make both your dcs a global catalogue server.

This should prevent the issues you are experiencing.

albanga

The new DC is on a different subnet.

To my knowledge sites and services is configured properly, but then again i am having this issue so maybe i have missed something.

The WLAN link between the 2 domain controllers is a 2MB link.

DNS is not installed on the new DC however. Do you think this could be the issue?

Hey stauchr could you tell me more about the globasl catlog server. I ave had a read and it seems like it could help, but what is the disadvantage of it? Why do you think it would benefit our sites?

Treg

Are both Domain Controllers runing 2000 or 2003?

You will probably want to investigate the following:


1) Install DNS on the new Domain Controller and wait for DNS to replicate the DNS zone from your Primary DC
2) Point DNS to itself from TCP properties
3) Global Catalog: Since your separated between a slow WAN link and using Exchange then a GC server in this site will be very handy. Queries will be directed to the Local GC instead of over the WAN link.


By the way, smart move on adding a second DC. You'd be f***ed if that DC died

strauchr

albanga wrote:

The new DC is on a different subnet.

To my knowledge sites and services is configured properly, but then again i am having this issue so maybe i have missed something.

The WLAN link between the 2 domain controllers is a 2MB link.

DNS is not installed on the new DC however. Do you think this could be the issue?

Hey stauchr could you tell me more about the globasl catlog server. I ave had a read and it seems like it could help, but what is the disadvantage of it? Why do you think it would benefit our sites?

Definitely set up DNS and have DHCP point clients to the subnets local DNS server for a start.

The only disadvantage of a GC is that in a large environment over a slow or unreliable WAN link replication of the global catalogue could affect network performance. On a 2Mb link it would seem reasonable to put a GC there.

If you have all Windows 2003 DCs make your domain and forest functional level 2003 native. This will reduce replication overheads. But understand you can only add 2003 DCs after that, no 2000 (and no NT if you really had to!)

If you have clients authenticating from Subnet A to the DC in Subnet B then you must set up to separate sites and add the appropriate subnet to each site.

sprkymrk

I agree, check that Sites and Services is set up correctly and set up a GC. Set a replication schedule to best allow for traffic. When you create a new AD object, you can force replication to occur manually between the sites from Sites and Services if needed.

You really need DNS set up with PTR records or the Sites and Services won't work very well. The DCs and clients use reverse lookups for much of that functionality.

Here is a good link and a few excerpts:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsbh_rep_gtka.mspx?mfr=true

When to Define a New Site
When you have slow links between network segments, it is recommended that you create two sites and place domain controllers into the sites according to the following general rules:

• Deploy at least one Global Catalog per site.

• Deploy DNS servers on a site level.

Having a Global Catalog server in each site improves search performance because searches do not have to cross site boundaries. In addition, a Global Catalog server is required for logging on to the domain; if a connection between sites is not available, logging on is not possible.

Note

If a Global Catalog server is not available in one site but there is another Global Catalog server in a remote site, the server in the remote site can be used for the logon process. If no Global Catalog is available in any site, the logon process proceeds with cached logon information.

The availability of DNS directly affects the availability of Active Directory. Clients rely on DNS to be able to find a domain controller, and domain controllers rely on DNS to find other domain controllers. As a general rule, you configure at least one DNS server in every site.

albanga

G Thanks a million! U guys totally Rock!

My mistake before on saying it was our second DC, we do actually have another backup one on our main site for if the main DC did ever fail. We do some dodgy stuff to get things working at times but we are not that bad

O.K, so i have done the following, set-up DNS on the secondary domain controller, got DNS to point to itself and made the secondary DC a global catalog server (the main DC already is one).

The secondary machine is a 2K server so i cant turn into 2003 Native (Bummer!!).

I will see how everything goes today and definately let you guys know how i go, in the meantime though if possible can anyone explain to me something?

If i am working on the primary DC then why am i being affected by the secondary DC. I dont understand why it is having a bearing on me. From my knowledge it should just be sitting there to authenticate that site only and the only time it should talk to the primary is when it synchs with it (which is once every 3 hours).

But why i am on this, ever since we installed the secondary DC we have also been having problems with terminal service manager?? We have 4 terminal server machines and usually when we hop between the servers using terminal servers manager is works super quick, but ever since this additional DC it hangs every time you click on a different terminal server? STRANGE!!!!

And lastly on some instances our users on this site have logged on in the morning and usually they will recieve mapped drives depending on what groups they are part of. On a couple of instances they have come back with no mapped drives. What im guessing is happening is that our main DC for some reason is not authenticating them and they are going of to our new DC site and loggin in from there but when they go to get there mapped drives from the active directory script the WLAN is to slow and not doing it correctly.

Im sorry to be a nuisance guys, i just cant get my head around why it's doing this. Is there a way to say only Adelaide is to use the secondary DC (Adelaide is the state, im from australia), the rest of the offices is to use the primary DC??

sprkymrk

albanga wrote:

Is there a way to say only Adelaide is to use the secondary DC (Adelaide is the state, im from australia), the rest of the offices is to use the primary DC??

Once you have the DNS, Sites and Services, and the GC running smooth those problems should disappear.

It might be worth asking about your IP addressing scheme. Do you use DHCP? Private or public IP's? Dynamic DNS? Are the two sites using different IP ranges?

Check out this article to make sure the DC's have the correct SRV records:
http://support.microsoft.com/Default.aspx?kbid=270915

Also, when you open the ADUC MMC, you can tell it which DC to connect to. Right click on the domain icon and select "Connect to specific domain controller".

strauchr

albanga wrote:

G Thanks a million! U guys totally Rock!

My mistake before on saying it was our second DC, we do actually have another backup one on our main site for if the main DC did ever fail. We do some dodgy stuff to get things working at times but we are not that bad

O.K, so i have done the following, set-up DNS on the secondary domain controller, got DNS to point to itself and made the secondary DC a global catalog server (the main DC already is one).

The secondary machine is a 2K server so i cant turn into 2003 Native (Bummer!!).

I will see how everything goes today and definitely let you guys know how i go, in the meantime though if possible can anyone explain to me something?

If i am working on the primary DC then why am i being affected by the secondary DC. I dont understand why it is having a bearing on me. From my knowledge it should just be sitting there to authenticate that site only and the only time it should talk to the primary is when it synchs with it (which is once every 3 hours).

But why i am on this, ever since we installed the secondary DC we have also been having problems with terminal service manager?? We have 4 terminal server machines and usually when we hop between the servers using terminal servers manager is works super quick, but ever since this additional DC it hangs every time you click on a different terminal server? STRANGE!!!!

And lastly on some instances our users on this site have logged on in the morning and usually they will recieve mapped drives depending on what groups they are part of. On a couple of instances they have come back with no mapped drives. What im guessing is happening is that our main DC for some reason is not authenticating them and they are going of to our new DC site and loggin in from there but when they go to get there mapped drives from the active directory script the WLAN is to slow and not doing it correctly.

Im sorry to be a nuisance guys, i just cant get my head around why it's doing this. Is there a way to say only Adelaide is to use the secondary DC (Adelaide is the state, im from australia), the rest of the offices is to use the primary DC??

Adelaide is a city not a state

Since your an Aussie as well maybe I can offer more help.

The problems you are having seem to be related to incorrect site set up. It sounds like you have got both your sites under one site (probably DefaultFirstSite)

What you need to do is have one AD site per physical site (as a general rule, it can be more complex). So say you have a site in Adelaide and a site in Perth (my hometown) you create a site for each. You then associate the appropriate site subnets to each site.

This will fix most if not all the symptoms you describe.

As for scripts not running it sounds like the script may not have replicated to the DC on the other site. Check to see if it has replicated under the Netlogon share.

sprkymrk

strauchr wrote:

It sounds like you have got both your sites under one site (probably DefaultFirstSite)

Good call strauchr. I bet you're right.

albanga

Sorry strauchr meant to say site not state

So still having problems!! AAGGHHH!!

Alright to answer your questions sprkymrk i have checked all DNS settings and they seem to be fine. All entries are correct and SRV records are fine. In regards to the ADUD i already know this. The problem is when you start ADUD it defaults to the othe site which takes ages, but any ahcnges made on that AD actually work, if i connect to the primary DC it works mega fast but any changes made do not work. Like i said its as if the secondary has taken over as the primary DC.

Our IP addressing scheme uses DHCP with private IP ranges using dynamic DNS. The two sites are on different IP ranges and i have set this up correctly in sites and services to indicate it. Just so you know.

Default First name site is on 10.0.9.0/24
Adelaide site is on 10.0.6.0/24

I will explain to you how i have sites and services set up.

I have an adelaide site, in this is server DC2. It is a global catalog server that replicates from DC1 and to DC1 once every 3 hours (I could probably change this if need be but i dont see that as the problem)

I have the Default first name site, in this is server DC1 and a backup DC. DC1 is a preferred bridgehead server using IP. It is a global catalog server replicating to DC2 and from DC2 every 3 hours.

In my inter site transports i have under IP a site link between melbourne and adelaide. Sites in this link are adelaide and default first-site-name.

Lastly in subnets i have 10.0.6.0/24, its properties say site is Adelaide on network 10.0.6.0 with mask 255.255.255.0

Then i have 10.0.9.0/24 its properties say its the default-first-name-site on network 10.0.9.0 with mask 255.255.255.0.

That is exactly how sites and services is currently set-up. I have followd every single instruction to date and still no luck.

We dont have a DC in each site because we have around 10 sites. Like ive mentioned before every single person should authenticate to DC1 except the adelaide site which should authenticate to DC2.

I am at an absolute lost as to why when i make a change in AD with DC1 the changes to not work. For example if i re-set a password the change will not take effect for some time. If i do this same password re-set on DC2 it works immediately. It has come to the point where DC1 isnt even doing anything anymore.

Hope this helps explain it a lot more! Also dont know if this has anything to do with it but DC1 is probably the worst in shape PC of all time. When our network guy got here it was a DC, file server, print server, terminal server, DNS machine. So as you might understand it is in pretty bad shape so im thinking that it might be slower to answer than DC2 which is why we might always be connecting to DC2 first. That is just a thought.

Thanks again for everyones input.

sprkymrk

Have you run gpresult on a couple of clients on each site? That will tell you which DC they last applied group policy from.

Your problems will take some good trouble shooting and thought... I'll let you know if I can think of something else.

strauchr

Yeah this is a hard one. One thing I'll also advise you to do is if those other sites you have are on different subnets (and I bet they are) you'll need to add them into Sites and Services and associate them to the DCs site that you want them to authenticate against.

You can use the SET command a cmd prompt where you can find which server the user authenticated against.

Where do your FSMOs sit? I am guessing DC1. You could try (and this is a bit of a long shot) moving your FSMOs to a higher performing server.

Is every DC you have a GC? If not I would advise you do that. This could have an impact with the Infrastructure master being on a GC when not all DC are a GC. In a small environment it is MS recommended that all DCs are GCs.

Theres also a possibility of it being a networking issues, congestion or routing. You can blame those comms guys every now and then

Just another thing. How long are we talking for delay of password changes? These are not always immediate depending on a number of factors.

Try the changes one step at a time and test after each change. I'd document any changes you do to in case things get worse or you want/need to roll back. Let me know how you go, I am determined to see this one fixed

albanga

Alright, still no good!! DAMN IT!

Just ran a gpresult on a couple of client logins and as expected they are getting there policies from DC2, but what is even stranger is they think they are in the Adelaide site when they are blatantly not!

Again i have gone through sites and services and checked every single possible properties and task page and set it up perfectly.

Yeah you are totally right about the other sites they are on different subnets, so i could also do that but at the moment i just want to get this part working.

I hear what you are saying about the FSMOs but at the present time we dont really have anything to move them onto.

Every DC is a global catlog server.

The delayed password is about 1 hour, which i dont think will make to many users happy.

Y Y Y Y Is this being such a pain, it was suppose to be a simple DC to authenticate 1 office and also be used as an off-site back-up if anything were to happen to our server room. Now its turning out to be an absolute bugger of a thing!!!

Like i said i just dont get why every computer is authenticating to DC2 when they are not part of that site. My understanding is anything in 10.0.6/24 go to DC2 in the adelaide site. Anything else is part of the default first-name site so go to 10.0.9.0/24.

Thanks for sticking thick guys! Really appreciate the help. I have the patience for about 2 more days at which time DC2 is going swimming with the fishes.

Treg

Might be best to hire out an AD engineer to help you out onsite if you cant resolve this with your IT team in an efficient time frame. A little costly, but the job will get done. Your management team might start snooping about if users start complaining about these issues.

If not, suppose you could just demote the DC and revert Sites and services to how it was and then properly plan for next time.

strauchr

Yeah, you can always fly me out to Adelaide (or give me remote access ).

Don't think I can help out more without seeing it for myself or going through your logs.

I'm still going with a sites and services issue somewhere. The only other thing that comes to mind is DNS records. It would be strange if thats an issue but again hard to tell without looking myself. There are a million things to look for. AD is a very complicated issue which is hard to fix over forum chats.

I'll have a think still and see what I can come up with. Put simply if your clients are not authenticating to your local DC you have an AD Site issue or DNS issue.

And just to throw this in, you probably have already done it, reboot the troublesome DC. Restarting all the services may bring things back online - don't laugh cos this is does happen.

strauchr

Just to add one more last fundamental. Have you installed all the latest service packs and patches on all servers?

sprkymrk

I'm not sure, this is a long shot, but can you change your IP scheme to use 192.168.x.x? Even though you have the subnet mask set to create different sites (/24) I wonder if Windows is trying to be helpful and assuming that since you are using a 10.x.x.x range that the mask is really /8, thus making everything confused about what site it is on.

Second, change replication to once every 45 minutes or so instead of once every 3 hours and see if that helps with the length of time for password updates.

Third, what are the clients running? If they are anything less than W2K they can only authenticate against the PDC Emulator.

Fourth, when you set up this DC did you do run dcpromo from the remote site? I have heard of cases where it is better to set it up on the same site as the original DC first and leave it there for a day to replicate fully, then move it to the remote site.

Last long shot - create a hosts file entry on one of the clients at the remote site with an entry for your domain and local site DC like this:

10.0.0.1   PDCNAME #PRE #DOM:DOMAIN_NAME
10.0.0.1   "DOMAIN_NAME    \0x1b"   #PRE

Restart that computer and see if it authenticates against the correct DC.

strauchr

So what happened? Is it fixed?

Ahriakin

Okay I'm intrigued now too...btw isn't the PDC emulator also the DC on which GPO is set when you edit it, and it propagates from there to the other DCs? Just a thought, I'd make sure it hadn't been moved to DC2. All servers check with the emulator too before denying a login due to password failure so it might explain some slowdown?
Other possibly stupid thoughts: It sounds like you run a single domain, I believe in this case GCs are not a major factor. AFAIK they are only required as part of the authentication chain in domains where Universal groups can be in use. I know they're used by default for active directory searches regardless of domain structure but their relevance to account replication is questionable in this scenario (again I know i might be missing something) as in a single domain environment they store the exact same information as a std. DC. I guess one of the most important things you could do at this stage is try and get a snapshot of traffic on your wan link. Is it congestion, is AD replication actually occurring in a timely fashion regardless of your logical settings etc.
Then of course I could just be talking out of my ass. I need more exposure to indepth AD methinks (hence reading these posts....)

strauchr

Anything?