Hey everyone, I apologize in advance if I won't be able to answer all of your questions, but I'll try my best. I'm not an Active Directory Administrator, but I know a little.
Currently in our Windows Server 2003 environment, our users were experiencing slow response times on certain applications. It wasn't until we noticed that our consultants didn't have the same issue, and we traced it to the fact our users have a Home Profile set that maps an H:\ drive to their home folder.
All of our corporate systems are housed in a hosting facility and the users use clients installed on terminal servers there to access those applications. So when a user is logged into those terminal servers, their home folder will be across the WAN and the response times will be very slow at times (depending on users internet traffic and other things).
We think the issue is a Windows problem with DLL Search Order, but we can't pinpoint the resolution.
The way we determined this was by running ProcessMon from SysInternals and view what was going on. When we launched the application, it was searching for a particular DLL (XYZ.DLL, for instance). In ProcessMon, you would see a bunch of lines where the result was "NAME NOT FOUND", but the order looked something like this:
1 - Folder where Executable was launched
2 - C:\Windows\system32\xyz.dll
3 - C:\Windows\system\xyz.dll
4 - C:\Windows\xyz.dll
5 - H:\Windows\xyz.dll
6 - Folder where Executable was launched (again?)
7 - C:\Windows\system32\xyz.dll
8 - C:\Windows\xyz.dll
9 - C:\Windows\system32\wbem\xyz.dll
10 - etc
Starting at line 7, everything starts matching what's defined in our PATH environment variable. According to this, http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx, we have SafeDllSearchMode enabled.
So the problem appears as though in a Windows Terminal Server environment, it also looks on the home directory for the user as specified in Active Directory.
We know a fix is to either disconnect that drive or specify a Terminal Services Profile in Active Directory to the local path, but we would prefer to do neither. We would like to keep the users Home Directory, but achieve better performance.
Currently in our Windows Server 2003 environment, our users were experiencing slow response times on certain applications. It wasn't until we noticed that our consultants didn't have the same issue, and we traced it to the fact our users have a Home Profile set that maps an H:\ drive to their home folder.
All of our corporate systems are housed in a hosting facility and the users use clients installed on terminal servers there to access those applications. So when a user is logged into those terminal servers, their home folder will be across the WAN and the response times will be very slow at times (depending on users internet traffic and other things).
We think the issue is a Windows problem with DLL Search Order, but we can't pinpoint the resolution.
The way we determined this was by running ProcessMon from SysInternals and view what was going on. When we launched the application, it was searching for a particular DLL (XYZ.DLL, for instance). In ProcessMon, you would see a bunch of lines where the result was "NAME NOT FOUND", but the order looked something like this:
1 - Folder where Executable was launched
2 - C:\Windows\system32\xyz.dll
3 - C:\Windows\system\xyz.dll
4 - C:\Windows\xyz.dll
5 - H:\Windows\xyz.dll
6 - Folder where Executable was launched (again?)
7 - C:\Windows\system32\xyz.dll
8 - C:\Windows\xyz.dll
9 - C:\Windows\system32\wbem\xyz.dll
10 - etc
Starting at line 7, everything starts matching what's defined in our PATH environment variable. According to this, http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx, we have SafeDllSearchMode enabled.
So the problem appears as though in a Windows Terminal Server environment, it also looks on the home directory for the user as specified in Active Directory.
We know a fix is to either disconnect that drive or specify a Terminal Services Profile in Active Directory to the local path, but we would prefer to do neither. We would like to keep the users Home Directory, but achieve better performance.