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.