Friday, June 28, 2013

Fix: Unable to update User GPO via gpupdate

Group Policy issues are always a pain in the but, I've found.  This one was particularly annoying because of the impact that it had on the user.  The user was unable to access his personal drive on our server (G:\ Drive) as it would not map it during login.  Also, what he didn't mention, the system takes up to 5 minutes to log in.

At first I was strictly working on the drive map issue ... out of 3 network drives that he should get he was only getting one.  Manually running the login script seemed to clear that up temporarily but not permanently.  I then decided to do a GPO update (gpupdate /force /wait:-1) but it threw up an error.  In the System Event Log, I saw this:

The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F\}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:

a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

Since this was the only system on the network having this particular problem, I wasn't convinced that the issue was limited that computer and ... since it was late in the day ... was just going to reimage the box and be done with it.  I decided to check the Details tab for this particular event and noticed something rather peculular:

+ System

- Provider
[ Name] Microsoft-Windows-GroupPolicy
[ Guid] {AEA1B4FA-97D1-45F2-A64C-4D69FFFD92C9}
EventID 1058
Version 0
Level 2
Task 0
Opcode 1
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2013-06-27T23:33:35.377468900Z
EventRecordID 65946
- Correlation
[ ActivityID] {E6ACB131-AEEC-45A4-98D7-118272AA0081}
- Execution
[ ProcessID] 428
[ ThreadID] 3744
Channel System
Computer VAND105.mh.local
- Security
[ UserID] S-1-5-21-2823908405-3494369649-3172151183-3327

- EventData

SupportInfo1 4
SupportInfo2 816
ProcessingMode 1
ProcessingTimeInMilliseconds 16864
ErrorCode 1317
ErrorDescription The specified account does not exist.
DCName ServerName.domain.local
GPOCNName CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=local
FilePath \\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

Since I knew what stage the GPO was failing at (applying User Settings) and I knew what was able to complete successfully (applying Computer Settings) I think I figured it out ... and it was a nice easy fix:

Re-create the User Profile on the local machine!

To test I logged the other user out and logged in as myself and noticed that there were no GPO issues under that account.  Then I did the following:

  1. Restarted the PC and logged in as local administrator (you can use any account with admin rights as long as its not the affected account)
  2. Go to C:\Users\ and back up the users content.
  3. Right-Click Computer and select Properties
  4. Click Advanced System Settings
  5. On the Advanced Tab, click Settings under the User Profiles heading
  6. Click the Profile you wish to delete, then click delete
I should point out that at this step I received an error regarding the deletion of the Profile.  I had to hit Delete a 2nd time to remove it from the list, but it didn't actually delete anything ... solidifying the determination that the local user profile is at fault.  I continued on and did the following:

Deleted the profile store manaully (C:\Users\
Launched Regedit
Went to HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList

**Take care when editing the registry as you can cause major system damage if edited incorrectly, resulting in a reinstalltion of Windows.  Only proceed with working in the registry if you are comfortable

Within this key I deleted any sub-keys related to the damaged user profile.  You can discover this by clicking on each sub-key and looking at ProfileImagePath to see if it matches the username.  Also, delete any keys that reference TEMP.  After that, restarted the computer and allowed the user to log in locally ... GPO issue resolved!