File access after installing new DC

[jmorr34]

Ok, I made our new dc the FSMO role holder yesterday. I transfered all 5 roles. Everything seem to go smooth, except today I find out that some machines are taking a while to load excel and word files from the fileserver, while other machines load them perfectly fine. Adobe files open fine. I have not tested other files, but those are the ones we primarily use. A tried a persons login on a machine that opened the file correctly and it continued to open correctly. So it does not seem to be a user issue, but a machine issue.

Any help is much appreciated.

 

[ITPangaeaArchitect]

1. make sure PDCe faces itself and itself only for preferred DNS
2. make sure replica DCs point to PDCe for preferred DNS and themselves as alternate DNS
3. Make sure clients have proper DNS configuration (pointed to a DC for DNS).

we can start and go from there....

-Brandon Wilson
MCSE:Security00/03
MCSA:Messaging00
MCSA:Security03
A+

 

[jmorr34]

Ok, my new PDCe (10.0.0.17) was pointing to the old PDCe (10.0.0.15). I now have the new one pointing only at 10.0.0.17 and the old pointing prefered to 10.0.0.17 and alternate to 10.0.0.15. Some clients are set to obtain DNS automatically and some are static. Problem continues with both and works with both.

Note 1: Loading word and excel files works 100% with a computer that has Office 2000, but works on half the machineswith Office 2007.

Note 2: I have my old alternative turned off and never demoted it. Could that cause a problem? I had DC1 (PDCe), DC2, and the new system DC0. I transfered roles to DC0 and turned off DC2 and have not demoted yet, just to see how things worked before I did that. Should I go ahead and do that?

I am working through remote right now so I will not be able to tell the true speed of things until I go in in the morning.

 

[ITPangaeaArchitect]

ah yes note 2 can cause a problem that can be remedied by deletion of the SRV records in DNS for that particular DC. Otherwise, clients will attempt to still authenticate to it, wait for the timeout, then finally move to the live DC..if the old DC is the first one alphabetically anyways. Eitehr way though, it can still cause issues.
I will say, I doubt its causing any office issue unless the file server is attempting to authenticate to the downed DC. Based on your explanation of behavior, I'd have to say that's probably not the case.
It seems like I ran into a bug awhile back for DFS with this specifically relating to MS Office documents....specifically, look into something called OpsLock (opprtunistic locking)...office had a problem with releasing the opportunistic locks on office files when shared on a DFS server...but outside of that notion, OpsLock has further office implications as well.
I think your problem here is more office related than DC related, but you could always find the old DC and authentication attempts to it were in fact the problem, which is also possible.

The office 2000 working 100% of the time is what makes me think its an office problem and not a problem with your infrastructure.


oh for DNS...ensure your DHCP scopes are altered to reflect the live DC IP address...static clients can be changed manually on the console, or manual/programmatic through the registry.

-Brandon Wilson
MCSE:Security00/03
MCSA:Messaging00
MCSA:Security03
A+

 

[jmorr34]

Update: It has to be DC related. I turned DC2 back on and immediately people are telling me it is running up to speed. (still confused about Office 2000 working though).

With DC2 up and running, what do you think my next course of action is? Will demoting it delete the SRV records as well? I couldnt find much documentation on deleting SRV records even though it sounds like an easy task.

as for DHCP scopes, I still have DC1 as the DHCP server. Should I make the new server DC0 the DHCP server? and I am not sure what you mean by alter the DHCP scopes to reflect the live DC IP address. Under Scope Options I have DNS Servers as DC0 and DC1.

Thanks for the help Brandon.

 

[ITPangaeaArchitect]

Q: With DC2 up and running, what do you think my next course of action is? Will demoting it delete the SRV records as well? I couldnt find much documentation on deleting SRV records even though it sounds like an easy task.

A: If you are running Win2003 SP1, you shouldn't need to delete anything manually after the dcpromo. To delete SRV records manually, the easiest course of action is to go into the _msdcs.domain.com zone, then go through the subfolders and delete the _LDAP, _Kerberos, and other SRV records for the DC who was taken down through each subnode inside of _msdcs.


Q: Should I make the new server DC0 the DHCP server? and I am not sure what you mean by alter the DHCP scopes to reflect the live DC IP address. Under Scope Options I have DNS Servers as DC0 and DC1.

A: Actually DHCP should never be ran on a DC. the FRS database and DHCP database are both JET databases and can compete for resources, which can cause an inadvertant DoS to either DHCP or AD itself. Very bad juju, very big downage...
If you have a very small environment though, you *should* be ok, as the resource usage won't be that high to begin with.
If the old DC is going to be decommissioned and the hardware removed, then obviously you will want to move DHCP to the new DC. If you are keeping the hardware, I would suggest a reload with Win2003 and make it a member server, and teh DHCP server, additional file server, or whatever other uses you have for it. While the reload is occurring, you could temporarily duplicate your current DHCP config onto the new DC so DHCP is fully operational during the transition.
The adjustment you need to make to your scope is to remove the old DC from the DNS servers list.


All of that should keep you operational throughout any transitions being performed with little to no user impact.

-Brandon Wilson
MCSE:Security00/03
MCSA:Messaging00
MCSA:Security03
A+

 

[jmorr34]

I was looking under DFS on the fileserver and there is \\DC1\Public and \\DC2\Public but no root target for DC0. Should I create that?

DC0 is a brand new server with more power than it knows what to do with and the environment is very small. I guess I could transfer DHCP to DC0 even though DC1 will still be running. DC1 resources arent so great.

 

[ITPangaeaArchitect]

are you running standalone or domain based DFS?

DFS will likely need recreated on the new DC....if all the data is already replicated over, this will be easily done. Otherwise, put the new DC up as a replication partner, then let it replicate the data (and btw, this is where you may see the DHCP vs. FRS engine battle)..after that, you can simply wipe the environment and redo it (10 minutes, give or take a couple).

-Brandon Wilson
MCSE:Security00/03
MCSA:Messaging00
MCSA:Security03
A+

 

[jmorr34]

pretty sure it is domain based. I have created DFS on the new DC.

I think I have covered everything except demote the old dc (DC2). The problem continues to happen when I turn dc2 off. I guess I can go ahead and demote it, but I dont want to do that and the problem continue then not be able to return back to it working until I figure it out. Should I try to demote?

Also, When I use netstat -a command on a client, it still continues to look for DC2 even though I have DNS configured on the client for DC0 preferred and DC1 alternate. DHCP has been move from DC1 to DC0 also.

Here is what it says when DC2 is turned on:
Active Connections

Active Connections

Proto Local Address Foreign Address State
TCP pcjody:http pcjody.xxxxxxx:0 LISTENING
TCP pcjody:epmap pcjody.xxxxxxx:0 LISTENING
TCP pcjody:https pcjody.xxxxxxx:0 LISTENING
TCP pcjody:microsoft-ds pcjody.xxxxxxx:0 LISTENING
TCP pcjody:990 pcjody.xxxxxxx:0 LISTENING
TCP pcjody:1044 pcjody.xxxxxxx:0 LISTENING
TCP pcjody:3389 pcjody.xxxxxxx:0 LISTENING
TCP pcjody:47922 pcjody.xxxxxxx:0 LISTENING
TCP pcjody:netbios-ssn pcjody.xxxxxxx:0 LISTENING
TCP pcjody:1379 dc2.xxxxxxxxx.com:1025 ESTABLISHED
TCP pcjody:1396 dc1.xxxxxxxxx.com:1025 ESTABLISHED
TCP pcjody:1397 dc1.xxxxxxxxx.com:1025 ESTABLISHED
TCP pcjody:1399 exch.xxxxxxxxx.com:5668 ESTABLISHED
TCP pcjody:1401 exch.xxxxxxxxx.com:5668 ESTABLISHED
TCP pcjody:1402 exch.xxxxxxxxx.com:5668 ESTABLISHED
TCP pcjody:1403 exch.xxxxxxxxx.com:5668 ESTABLISHED
TCP pcjody:1420 fileserv.xxxxxxxxx.com:microsoft-ds ESTABL
ISHED
TCP pcjody:1446 dc1.xxxxxxxxx:microsoft-ds ESTABLISHED

TCP pcjody:1448 dc2.xxxxxxxxx:microsoft-ds ESTABLISHED

TCP pcjody:1064 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:1105 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:1107 localhost:27015 ESTABLISHED
TCP pcjody:1114 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:5354 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:5679 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:7438 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:27015 pcjody.xxxxxxxxx:0 LISTENING
TCP pcjody:27015 localhost:1107 ESTABLISHED
UDP pcjody:microsoft-ds *:*
UDP pcjody:isakmp *:*
UDP pcjody:1028 *:*
UDP pcjody:3456 *:*
UDP pcjody:4500 *:*
UDP pcjody:6004 *:*
UDP pcjody:ntp *:*
UDP pcjody:netbios-ns *:*
UDP pcjody:netbios-dgm *:*
UDP pcjody:1900 *:*
UDP pcjody:5353 *:*
UDP pcjody:ntp *:*
UDP pcjody:1025 *:*
UDP pcjody:1054 *:*
UDP pcjody:1378 *:*
UDP pcjody:1900 *:*

 

[jmorr34]

and when DC2 is off, I get a little of this:
TCP pcjody:1846 dc1.xxxxxx:netbios-ssn TIME_WAIT
TCP pcjody:1850 dc0.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1852 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1854 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1858 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1860 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1862 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1864 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1866 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1868 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1872 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1874 dc1.xxxxxx:microsoft-ds TIME_WAIT
TCP pcjody:1876 dc1.xxxxxx:microsoft-ds TIME_WAIT

and
TCP pcjody:1880 dc2.xxxx:microsoft-ds SYN_SENT

while it was off I got this once:
dc2.xxxxxx.com:ldap CLOSE_WAIT

 

[jmorr34]

i also get TIME_WAIT on epmap

example from fileserv:

TCP fileserv:epmap pcjody.xxxx.com:2901 TIME_WAIT
TCP fileserv:epmap pcjody.xxxx.com:2902 TIME_WAIT
TCP fileserv:epmap pcjody.xxxx.com:2903 TIME_WAIT

example from pcjody
TCP pcjody:2900 fileserv.xxxx.com:epmap TIME_WAIT
TCP pcjody:2901 fileserv.xxxx.com:epmap TIME_WAIT
TCP pcjody:2902 fileserv.xxxx.com:epmap TIME_WAIT

until it establishes (about 20 seconds)

 

[ITPangaeaArchitect]

ok so domain based would mean the DFS share can be accessed via \\domain.com\root-target\share rather than \\servername\root-target\share (well, technicall either or could be used with domain based, but it eliminates thee point).


If DC2 will be shut down, it has to be erradicated from the environment. I'd suggest taking a backup of the old DC (full backup including system state), then demote it.
You should not be referencing any DC that is not running in your list of DNS serversz, or you will always have failures.

As far as the clients...after reconfiguration of DHCP, one of two options is necessary: 1. reboot client PC so it acquires the new settings (or it will keep the old for 7 days by default) 2. run ipconfig /release & ipconfig /renew (I personally suggest a reboot to eliminate any cached behavior issues on the client side.

also, if a router exists between the clients and the DC, your RPC issues denoted in your netstat results above could be due to RPC bind time negotiation. We'll touch on that if it really starts to look more like thats a problem though (as we could easily be seeing cached behavior here from clients).


-Brandon Wilson
MCSE:Security00/03
MCSA:Messaging00
MCSA:Security03
A+