LOGONSERVER environment variable

[charlsteve]

I want to know the effect of having incorrect LOGONSERVER environment variable in a windows XP or windows 2003 machine. When I say incorrect, it is pointing to other site DC instead of local domain controller. Also want to know at what all places this environment variable will be used in windows XP.

Please let me know if I need to provide any more details for better understanding.

Thanks,
Sitaram

[Stonelaughter]

I think you have it the wrong way around. The "Logonserver" environment variable is set when you log on to the name of the server which processed your logon.

[charlsteve]

I understood that, Stonelaughter. I have a requirement where I have to switch hole active directory infrastructure to Disaster Recover site, which means that, I will be shutting down all DC's of current site and making DR servers online. During this process, all desktops will be running and the LOGONSERVER environment variable will be set to local DC which I had to shutdown. After switching to DR site, if the client still tries for local DC, then it will be a problem.

So, I just want to understand, what all processes that will make use of this variable. If it is not a problem, then I want to change the LOGONSERVER to DR site DC manually.

Thanks,
Sitaram

[gforceindustries]

Switching to DCs at a different site is something you'd do out of hours isn't it? When your users aren't logged on.

[charlsteve]

Incase of disaster, we need to do it immediately irrespective of time.

[gforceindustries]

True. In that case, you would just get users to reboot their machines if they experience problems.

[Stonelaughter]

Changing "Logonserver" environment variable would achieve nothing. Like GF said, when you have to do this for a disaster, have the users reboot. They will log on to whichever DC is available, and logonserver will be set correctly.

Changing "logonserver" manually would address I estimate about 1% of the problems you would experience when the servers went down. Rebooting would address all of them.

[Smart-X]

Having the DRP backup the primary site without getting client machines to reboot is a legitimate request.

As far as I know, Windows operating system does not use the LOGONSERVER environment variable. It is calculated upon logon and is primarily used by legacy applications, scripts, batch scripts and other application that does not use API calls such as dsGetDCName to retrieve the DC.

When you actually take the primary site offline (and switch to the DRP site), do you experience any problems that you think might be related to the LOGONSERVER environment variable?

[Stonelaughter]

Originally Posted by Smart-X

Having the DRP backup the primary site without getting client machines to reboot is a legitimate request.

Indeed it is; however to my knowledge such a capability was not implemented in Windows up to XP/2003.

In my experience, when the DC which the users authenticated to goes down, so does their ability to do anything. When the DNS server they were talking to goes down, so does their ability to do anything. When the file server they were using goes down (for roaming profiles, MyDocs and shared data) so does their ability to do anything.

Reconfiguring their environment at the back end to give them new DNS servers, a new DC and a DR File server and then asking them to reboot seems to me to be a perfectly reasonable DR plan and would have them up and running reasonably quickly.

[Smart-X]

It depends on the DR site scenario and file system distribution between the two sites.

To my knowledge, Windows 2000 will get over a non-reachable Domain Controller without having to reboot (Even if this is the DC used for authentication at logon) Previous operating system will require reboot.

Regarding DNS, you should configure at least two DNS servers - one (or two) in the primary site and another one (or two) in the DR site.

Regarding file system (Shared data, roaming profiles, My Documents, etc.), it depends which method of file system distribution you are using. Basically, there are two major alternatives:
1. A cluster of two or more nodes which uses a storage system that replicates between the two sites.
2. Two separate file servers which replicate the information.

If you use the first method - than your clients probably access the file system using the cluster's logical name, so nothing should be changed when the primary site fails.

If you use the second method - you should configure your clients to use the file system through DFS links only. This way, even if one of the file servers fail, you will still be able to use the file system since client requests will be directed to the available server. (There will be a pause when client are accessing the FS right after the server they where using failed).

BTW, DFS is also smart enough to direct clients to their nearest file server according to their site.