Novell is now a part of Micro Focus

Logging in to Two Trees in WinXP

Novell Cool Solutions: Trench
By Jack Turner

Digg This - Slashdot This

Posted: 28 Apr 2004

After we posted this article, Jack got some feedback that this doesn't work in all cases, and he did some additional research and found that this is true. He opened an incident with Microsoft, found out additional information, and figured out a workaround that does seem to work in every case. Check the Addendum for details.

I log into two different NetWare trees, and have permanent mapped drives in each tree. Under Windows 2000, when I logged in, the system would stop and prompt me for passwords for these additional connections. Under XP, the logon process does not pause, but simply marks these connections as "unavailable" with a red X. I looked high and low for a solution, and checked with a number of user groups, but no one had a solution to the problem. Finally, today I found the solution!

Windows XP was designed with something called the "Windows XP Professional Fast Logon Optimization Feature." According to Microsoft, "By default in Windows XP Professional, the Fast Logon Optimization feature is set for both domain and workgroup members. As a result, Windows XP does not wait for the network to be fully initialized at startup and logon. Existing users are logged on using cached credentials. This results in shorter logon times. Group Policy is applied in the background after 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. Additionally, 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 you turn off this feature, 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. This results in the asynchronous application of policies when the computer starts and when the user logs on. This application of policies is similar to a background refresh process and can reduce the length of time it takes for the Logon dialog box to display and the length of time it takes for the shell to be available to the user. An administrator can change the default by using the Group Policy MMC snap-in."

To turn off Fast Logon Optimization, you can use the following policy setting:

Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at computer startup and logon

When this policy is enabled, a Windows XP client behaves in the same manner as a Windows 2000 client at both system startup and at user logon.


The problem is that Microsoft, in their infinite wisdom, fundamentally changed the way Windows XP logs into a network. With EVERY previous version of Windows, from Windows for Workgroups, through NT and the 9x series, up to the last release with Windows 2000, the login sequence worked the same: when you logged in and the system started to restore network drives, Windows would pause and ask for the userid and password for any drive that couldn't be mapped with existing credentials (the current NDS tree and/or AD tree).

Without any notification to the end-user, Microsoft modified Windows XP in several different ways.

First, they introduced the Fast Logon Optimization process that basically speeds up the login process, and runs the logon scripts asynchronously (meaning that the system does not wait for the logon script to finish before the desktop is initialized).

Second, they introduced the Credential Manager, which manages userid and passwords for XP. There is currently NO WAY to make Windows XP work exactly like Windows 2000 during the login sequence (thanks, Microsoft!!).

I have submitted this as a problem to our account manager, but I frankly feel that this "feature" (bug?) will not be changed (resolved?) any time soon.


There is a way that we can work around these limitations, however. First you need to be aware of a few things:

  1. When you map a ?Permanent Drive Mapping?, DO NOT click on the ?Connect using a different name? link before you map the drive. Just map the drive and let Windows prompt you for the userid and password. I have not verified this, but my Microsoft tech told me that this is the only way to get a proper entry into the Credential Manager. Thereafter, any permanent map to a Windows share should reconnect automatically at login, using the information from the Credential Manager.
  2. If you are logging in as an AD domain member, Credential Manager will not work properly with any other account in that domain. The permanent drive mapping will remember the proper userid from the domain, but not the password. You will not be prompted for the password when you log in, and the connection will not be restored. The only solution I can find to this is to grant your current AD domain user the rights needed on that workstation.
  3. If you are using Peer sharing under Windows XP outside a domain environment, by default XP will be setup to only permit a connection using the Guest account name. To change this, modify the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\forceguest key to a value of ?0?, then reboot that workstation. You can now attach as any user.
  4. The Credential Manager can be opened by:
    • Start | Run ?control keymgr.dll?, or
    • By going to Control Panel | User Accounts, selecting the ?Advanced? tab, and clicking on ?Manage Passwords?
  5. The Credential Manager will not properly store NDS context-sensitive userids and passwords.

To make an XP workstation connect to a second NDS tree or a Windows share outside the domain, you need to do the following:

  1. Open the Group Policy Editor in the MMC (gpedit.msc)
  2. Browse to Computer Configuration\Administrative Templates\System\Logon, and change the ?Always wait for the network at computer startup and logon? to ?Enabled?, as discussed in the previous Cool Solution article I submitted.
  3. Browse to Computer Configuration\Administrative Templates\System\Scripts, and change the ?Run logon scripts synchronously? to ?Enabled?
  4. Now you just need to modify a login script with one of the following: a.
    • For a Windows login script (either the domain or Group Policy login script), add a line that says
    • For a NetWare login script (profile, container, or user), add the following:
  5. In either case, the startup sequence will now be delayed and you will be prompted for the password to this permanent drive mapping.

NOTE: Some Microsoft articles will tell you to use "EXPLORER Q:" to force a connection to a permanent drive mapping, but this will not work in this situation, because as soon as you run "Explorer", the desktop will initialize, and the system startup will not be delayed.

If you are not a domain user, you can modify the local login script on the XP workstation by using the Group Policy Editor (opened as shown above), by doing the following:

  1. Create a batch file with the NET USE command listed above, and save with a name like ?startup.bat?
  2. Open a window in Windows Explorer and copy this file to the clipboard.
  3. In the Group Policy Editor, browse to Computer Configuration\User Configuration\Windows Settings\Scripts (Logon/Logoff).
  4. Double-click on ?Logon?
  5. Click on Show Files
  6. Paste the ?startup.bat? file into the window which opens, which is the
    C:\Windows\System32\GroupPolicyUser\Scripts\Logon directory.
  7. Close the Group Policy Editor.
  8. You will now be prompted for the password to the share when you log in.

Note that this process only works for local users, not for domain users. You'll have to have an AD administrator modify your domain login script for AD domain members, as the local login script does not seem to run when you are logging in as an AD domain user.

This solution does not ask for your password in a pretty GUI box, but it will prompt for it in a command interpreter window--which at least is better than not prompting you at all!


  net use x: \\server\share /user:windowsuserid

  #net use x: \\server\share /user:.context.sensitive.userid

You could probably include your login password in the login scripts above, but I consider that to be a security violation, so I did not test that scenario.

Refresher: The "#" in the NetWare login script above tells NetWare to run an external command--in this case the command interpreter.

If you have any questions you may contact Jack at

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates