Tuesday, November 13, 2007

Mapped drives missing in explorer.

We ran into a problem with our mapped drives on our network. First time logins failed to display in explorer until they logged in the second time. You can see them from a command or dos prompt. The disconnect drives dialog also showed the mappings. I can also kill the explorer.exe process and when I run it from the task manager, the mapping show up.

Running the logon scripts manually will make the drives show up. It looks like a timing issue. If my script maps a lot of drives, the earlier ones are the ones that don’t show up. Any that map after explorer loads work fine. It did not matter if it was the users individual logon script or the group policy log on script. Different logon scripts didn’t fix it either. I have a custom vb script that I use, but I also tested it with a batch file full of NET USE commands.

I have worked on this issue for a long time. Searching different ways and posting to various forums. Finally Lanwench [MVP - Exchange] responded to my problem on microsoft’s technet newsgroup on Windows XP Networking. His solution was to enable the “Always Wait for Network” GPO setting and linked me to the detailed reason for that.

Always wait for the network at computer startup and logon

Administrative Template: System
Policy Node: MACHINE
Policy Path: Administrative Templates\System\Logon
Supported On: At least Microsoft Windows XP Professional or Windows Server 2003 family

Help/Explain Text: Determines whether Windows XP waits for the network during computer startup and user logon. By default, Windows XP does not wait for the network to be fully initialized at startup and logon. Existing users are logged on using cached credentials, which results in shorter logon times. Group Policy is applied in the background once the network becomes available. Note that because this is a background refresh, extensions such as Software Installation and Folder Redirection take two logons to apply changes. To be able to operate safely, these extensions require that no users be logged on. Therefore, they must be processed in the foreground before users are actively using the computer. In addition, changes that are made to the user object, such as adding a roaming profile path, home directory, or user object logon script, may take up to two logons to be detected. If a user with a roaming profile, home directory, or user object logon script logs on to a computer, Windows XP always waits for the network to be initialized before logging the user on. If a user has never logged on to this computer before, Windows XP always waits for the network to be initialized. If you enable this setting, logons are performed in the same way as for Windows 2000 clients, in that Windows XP waits for the network to be fully initialized before users are logged on. Group Policy is applied in the foreground, synchronously. If you disable or do not configure this setting, Windows does not wait for the network to be fully initialized and users are logged on with cached credentials. Group Policy is applied asynchronously in the background. Note: If you want to guarantee the application of Folder Redirection, Software Installation, or roaming user profile settings in just one logon, enable this setting to ensure that Windows waits for the network to be available before applying policy. Note: For servers, the startup and logon processing always behaves as if this policy setting is enabled.

Registry Settings: HKLM\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon!SyncForegroundPolicy

7 comments:

Mauricio said...

I'm not sure if this dicussion is still active but I'm having the same issue after installing IE7 and it only happens to some users.

I know the network is ready before the login process because it happens on Windows 2003 server which has been up for days. It happens on Win XP too without rebooting the computer.

In addition, the drives are mapped (net use commands were successful), so the network was ready when the logon script ran.

I agree with your coment that it looks like a timing issue. I haven't fixed the issue but this may help: If I restart explorer.exe (kill the process and then run it again from Task Manager) Windows Explorer shows the drives and everything works properly.

I think the logon script is running before "a process" which is making explorer.exe to fail to show the mapped drives.

Any idea?

Thank you!

Mauricio

KevMar said...

Mauricio, that’s the exact problem we still have. I have never found a real solution to it.

If you set it to persist in the profile, it will be there the next time they log in.

Now when we receive that trouble call, the just instruct them to log out and log back in. In a setting where the user has one or 2 machines, this is not a big deal. Unfortunately, that is not our setting and we see this often.

Mauricio said...

The problem seems to happen when the logon script runs simultaneously with the login process, so I have two workarounds that seem to work:

1. Map the drives after the desktop is active (include a delay in the logon script before the mapping commands).

2. Run the logon script before the desktop (before Windows Explorer starts) by enabling the "Run logon scripts synchronously" policy.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/gp/10.mspx?mfr=true

I'm using the second one because I don't want my users to access the desktop before the drives are mapped. But the login process takes a little longer.

Let me know if it works for you. However, I'd still like to know what the problem is.

KevMar said...

Thanks for the feedback.

We did use the synchronous policy for a while. In an effort to speed up the login process we ended up removing it.

We did run into an issue with the delay, but I don't recall what that was anymore. I'm thinking that setting it long enough to map on slower machines for first time logons was too slow for some of our faster machines.

I hate to sound like im shooting down your ideas, because they do work. And I sugest people that are running into this issue to try them. I am just in a unique enviroment.

The thing that gets me about this issue is that so few people have it. As solid as I can reproduce it, I would expect lots of people talking about it online. I would also like to know if moving to Vista or Server 2008 resolve this issue.

MidSpeck said...

You are the first place on the Internet I found discussing this problem that I am having directly. One with an XP laptop, the other with an XP x64 computer. I am not sure whether it is fixed on Vista/Server 2008 or not.
I haven't tried any of the fixes or workarounds you two were discussing yet. I do find that restarting the explorer process will show the drives for me though. Interestingly enough, they will also show up in Word and Adobe Acrobat... just not in "My Computer".
Most of the computers I work with don't have this problem -- but the ones that do seem to have it consistently.

redbruce said...

The problem is due to the logon script running before the explorer.exe (shell process) has started. Mapped drives (as visible in Exploer) are handled by explorer.exe, so if the drives are mapped before this has started they do map, but at a lower system level, which Explorer doesn't seem to show.

TBone said...

I have this exact problem. I do believe this is not an issue in Vista because I had a user who had this problem log in to a Vista machine and did not have this problem. However, I also had them login to a different XP machine and did not have this problem. So it was probably one of those different computer flukes.

I have tried changing the mapping order of the drives in the login script to no avail. Doesn't matter which order or where in the script they run. Also, we are using KIX32 to run our scripts, what is everyone else using? Are you doing group membership checks prior to mapping the drive?

Have also tried a new user profile on the computer, no dice.

The always wait for network policy is enabled in my environment as well. I'm at a loss, these should have fixes aren't working and I don't know where else to look.

I have already inquired about re-writing the script in VB, but was told to leave well enough alone.