439905: Home folders are not mapping correctly
Related tickets:
 456883
 456130
Relevant articles:
 http://support.microsoft.com/kb/q305293/ - XP Fast Logon issues: XP can sometimes
log the user on before the network stack is fully functional using cached credentials.
Once the user is logged on and the stack reports UP a GP Refresh will take place.
However, mapped drives will not be refreshed. If the stack is not up, the home folder
may be mapped to the root share instead of the user’s folder.
o Possible work around: Have the user log off and log back on.
o Possible solution: disable Fast Logon via GPO – This may also disable cached
credentials.
 http://support.microsoft.com/kb/969006 - Home folder might be mapping incorrectly
to the root share instead of the user folder.
o No suggest possible work around or solution
Thoughts on this issue:
 This appears to be a timing issue with the drive mapping vs the availability of the shares.
– Need to determine the source of this timing issue.
Machines affected at this time:
 OSP-KHENRY2
Issue can be reproduced by mapping a network drive, disconnecting the network cable,
restarting and then logging back in. The drive will report back “Drive not accessible” (Duh, the
computer is not on the network)
Random notes:
 http://www.computing.net/answers/windows-2003/home-folder-mappingissue/8194.html is a pretty good thread on a similar issue.
o One suggestion is to enagle in GPO Configuaration ->Administrative Templates >System->Scripts->Run logon script synchronously
 It’s possible that the machines that are having this issue are using DryCreek3 for
logonserver
Other possible theories:
Current hypothesis:
The Always wait for network at logon is supposedly set in the print groups. It may not be
applying as at least ONE of the machines with this known issue is missing the
HKLM/SOFTWARE/POLICIES/MICROSOFT/WINDOWS NT/CurrentVersion key.
Steps to test:
1. Created XP VM and placed it in the TESTGPO
2. Verified the key was not installed.
3. Using GPO Editor edited the TESTGPO to enable the “Always wait for the network at
computer startup and logon”
4. Set the logon server to DryCreek3
5. Rebooted the machine and noted that the key was still not created.
6. Ran a gpupdate /force and saw the key was created.
7. Deleted the Current Version key
8. Set the logon server to DryCreek1
9. Rebooted the machine and noted that the key was still not created.
10. Ran gpupdate and noted the key was not created
11. Ran gpupdate /foce and noted the key was created.
12. Deleted the key
13. Set the logon server to DryCreek3 and rebooted
14. Noted that the key was not created
15. Ran gpupdate and noted the key was not created
16. Ran gpupdate /force and noted the key was created
Conclusion:
I am still operating under the assumption that the “Always wate for network…” setting is the
root cause of this problem. It does not appear that the issue relates only to DryCreek3.
It appears that a normal GPUPDATE does not apply this particular GPO opject correctly. Further
research is needed to determine if this is a known problem.
Additional Information:
I note that the OIT – Test Group Policy Preferences are filtered out as Disabled (GPO) Why?
This behavior is the same if the gpupdate is run with the /force or without.
GPUPDATE Server is DryCreek2 in the last two attempts. Unsure of what it was
previous. Once was DryCreek3
Current hypothesis:
The GPO rule “Always wate for network…” is not applying correctly.
Steps for tomorrow:
Add test machine to Print_OSP membership
PSEXEC to OSP-khenry (OSP-khenry2??? Machine name does not match) and verify gpresult
Weds 10/6/2010
Reverted to earlier snap shot, ran all updates and took a new snapshot
Noted upon logon the existense of the SyncForegroundPolicy key.
Deleted the key and noted the logon server as: drycreek2
Noted the policy server as: drycreek3
PC is in the test GPO, member of Domain computers ONLY
GPO policy is all not configured/disabled
Reboot 1 GPO settings no change:
Key: No
Logon Server: DryCreek2
GPO Server: DryCreek2
Reboot 2 GPO settings, GPOTest = Wait for network setting enabled
Key: Yes
Logon Server: DryCreek1
GPO Server: DryCreek1
Deleted the key, rebooted
Reboot 3 GPO settings, GPOTest = Wait for network setting enabled
Key: No
Logon Server: DryCreek1
GPO Server: DryCreek1
Reboot 4 GPO settings, GPOTest = Wait for network setting enabled
Key: No
Logon Server: DryCreek3
GPO Server: DryCreek2
Ran gpupdate /force
Key: Present
Notes from the field: Log Off and Log On is not a workaround. (Verified on 2 computers)
Gpupdate /force did not create the key on osp-rbishop
Printer is a member of print_osp
Current Hypothesis:
Move the Logon setting out of the print group GPO and move it up the chain.
Steps to test:
1. Disable the logon on the test gpo, reboot and make sure that the key is not created
from some other source. (Machine is not part of any printer group)
2. Move the test machine in AD to the F&A/OIT/Computer Service/computers group
3. Reboot, gpupdate /force and verify the key is not created. (Check the gpresult /z logs)
4. In the OIT Admin Desktop enable the logon policy
5. Reboot and verify the key is created
Expected Results:
Steps 1 – 4 should result in no key being created
Step 5 should result in the key being created and the gpresult /z showing the policy being
enforced.