Win 2008 Terminal Server Mapped Drives Issue

[DukeOfAwesome]

Hi Everyone,

Please bear with me while I try and explain my issue with mapped drives on a Win 2008 Enterprise Terminal Server.

We have an unusual setup in that the user data is stored on the Terminal Server itself on a RAID 10 Array. Most people would have the data component on a NAS or something similar but we find that the access speeds when the data is local is brilliant. The Terminal Server is a member of a Win 2003 Small Business Server Domain.

Now to my issue. We originally created shares on the Terminal Server itself and mapped UNC drives via a log on script via the various Group Policies. Problem is these UNC mappings to the Terminal Server itself caused it to freeze and needed to be reset once a user tried to access a file on any of the mapped drives. Weird!!! We have done this previously on our Win 2003 server with no issues and it is working to this day.

We decided to get around this issue we would use subst to map the drives instead. This works and does not freeze up the server and all works OK. We discovered and issue though when a user logs on to his profile from a second PC while still logged onto the first, the subst drives don't appear in the second session. No idea why, and there are no errors in the event log.

Has anyone experienced something like this? Can anyone think of a better way of doing what we're trying to achieve?

Thanks is advance...

Duke

[cluberti]

Your workaround isn't really sustainable, and subst wasn't meant to work that way (it does, but it may have bugs I'd guess).

Usually a server freezing when you map a drive to itself falls back on loopback support in the network card driver being substandard (even though you are doing it local, it still hits the network stack) or a layered service provider (LSP) driver like a 3rd party antivirus or firewall driver messing with the IRPs as they pass through the stack.

I'd suggest building a server in a VM and trying to reproduce the issue to see if it reproduces - assuming it doesn't, start narrowing down the differences in software until your TS is as similar to the (hopefully) working VM. Once you've eliminated software, start looking at the drivers on the TS itself, beginning with network and antivirus.

[DukeOfAwesome]

Your workaround isn't really sustainable, and subst wasn't meant to work that way (it does, but it may have bugs I'd guess).

Usually a server freezing when you map a drive to itself falls back on loopback support in the network card driver being substandard (even though you are doing it local, it still hits the network stack) or a layered service provider (LSP) driver like a 3rd party antivirus or firewall driver messing with the IRPs as they pass through the stack.

I'd suggest building a server in a VM and trying to reproduce the issue to see if it reproduces - assuming it doesn't, start narrowing down the differences in software until your TS is as similar to the (hopefully) working VM. Once you've eliminated software, start looking at the drivers on the TS itself, beginning with network and antivirus.

Cluberti,

Many thanks for your reply and you were right, it was the network card and now the server does not freeze since I updated the network card drivers. My other problem still remains though. If a user is logged onto Terminal Services on one PC then moves to another PC (while still logged on in the first) and logs onto Terminal Services from there under his username the Mapped Drives are not mapped in the second session for some reason.

I have checked the GPO's that apply and run gpresult to see if the script was actually executed and it was but no drives are shown. If I manually run the script within the users session the drives are mapped and there is no problem accessing and using the drives as per normal.

Do you have any ideas as to why this would be?

Thanks in advance...

Duke

[cluberti]

Assuming the profiles aren't roaming profiles, not really. I normally suggest mandatory profiles for TS and loopback GPOs and logon scripts specific for TS environments, but that may or may not be feasible depending on how your users utilize the TS servers in your environment.

[DukeOfAwesome]

Assuming the profiles aren't roaming profiles, not really. I normally suggest mandatory profiles for TS and loopback GPOs and logon scripts specific for TS environments, but that may or may not be feasible depending on how your users utilize the TS servers in your environment.

No they aren't roaming profiles and the GPO that applies has loopback in replace mode. Funnily, when I applied the logon script to the actual user profile it does run evrytime and maps all the drives. For some reason the GPO's logon script will only run the first machine the user log on with...Really weird...

Thanks

Duke

[cluberti]

Did you set the logon script in the GPO, or in the user's profile in ADUC? If you set it in the GPO itself, if it's not a local GPO, it will indeed only run once (I haven't tried this on a 2008/R2 domain yet, but I remember this happening in a 2003 domain hence my work-around). Unless the logon script differs from the one they would get on a normal machine, using the profile itself is a better place to set it.

[DukeOfAwesome]

Did you set the logon script in the GPO, or in the user's profile in ADUC? If you set it in the GPO itself, if it's not a local GPO, it will indeed only run once (I haven't tried this on a 2008/R2 domain yet, but I remember this happening in a 2003 domain hence my work-around). Unless the logon script differs from the one they would get on a normal machine, using the profile itself is a better place to set it.

I set it in the GPO of the domain controller. When you say local GPO do you mean the GPO of the Terminal Server itself?

[DukeOfAwesome]

OK, I've even tried adding it to the Terminal Server GPO via a custom mmc and the same result, first log on is OK subsequent logons no network drives... Can you share your work around?

[cluberti]

Go to the properties of the user's account in ADUC - you can use the profile tab to set a logon script for the user account itself. If the script is already in the domain netlogon share, you can just use the name of the file itself as the logon script.

[DukeOfAwesome]

Go to the properties of the user's account in ADUC - you can use the profile tab to set a logon script for the user account itself. If the script is already in the domain netlogon share, you can just use the name of the file itself as the logon script.

Thanks cluberti, but that defeats the purpose of having GPO's.

I have done some more testing and fired up our old Win 2003 Terminal Server to see whether this is an issue there and found that everything worked as expected. The user can log on as many times as he like from as many PC's and the drives are mapped. That points me to something on the Win 2008 Terminal Server and the configuration there.

Duke

[DukeOfAwesome]

For anyone else experiencing this it seems to be a confirmed bug in Win 2008. Read about it here:

http://social.technet.microsoft.com/Forums.../?prof=required

There are few things you can do like the GPP solution, the registry hack provided or simply adding the logon script to the Users Property Sheet in AD...The only good thing to come out of this is the fact that I'm not going mental and finding that there is actually an issue. Mind you, there is 2 weeks wasted in all of this...

Good luck.

Duke