SCCM : "the self signed certificate can not be created sucessfully"

Came across this problem the other day.  When I tried to create a Task Sequence Media, I get this message "the self signed certificate can not be created successfully".  Hmm... make no sense at all.  Looking at the log file (CreateTsMedia.log) which is located at C:\Program Files\Microsoft Configuration Manager Console\AdminUI\AdminUILog.  There is this error about "Cannot acquire crypt context".  You wonder what that means...

After doing more research on Internet, the error was caused by a PXE certificate which was created previously and not removed automatically when PXE point was reinstalled.  The certificate needs to be remove manually..  The folder is location is at:   C:\Users\<UserID>\AppData\Roaming\Microsoft\Crypto\RSA.
Once I removed the folder under RSA, things go smoothly again...  

Working with Windows 7 laptops, folder redirection and offline files - my experience

Working with Folder Redirection on laptops with offline files can be very challenging because laptops can be in a few different scenarios and they are need to be taken care of.  They can be:

1.  docked in the office and connected to LAN.
2.  undocked in the office and connected to wireless network at work
3.  undocked, lid close, brought it home, connect to home wireless and VPN into work.
4.  undocked, shutdown and VPN from home.

Let's look at each scenario closely.

Scenario 1:  docked in the office and connected to LAN.
Well, this one is easy.  Nothing really needs to be changed to make this work.  When laptop is connected to a fast network, the offline files should be online. 
The following group policy settings in Administrative Templates | Network | Offline Files should be set:
- Allow or Disallow use of Offline Files feature = Enable
- Configure Background Sync = (it varies, set to suit your environment)
- Enable Transparent Caching = 60ms  (varies, we set to 60ms in our situation)

Scenario 2:  Undocked in the office and connected to wireless network at work.
Okay, depending on your internal wifi setup, this one could be a bit tricky./  In our situation, this one would pretty much falls into scenario because our wifi setup is pretty good and the latency is very low.

Scenario 3:  Undocked, lid close, brought it home, open lid,  connect to home wireless and VPN into work.
In this situation, user is not log off when they bring their laptop home.  So, most likely the offline file status would show Offline (Not connected) when they open the lid.  User will launch their VPN application and establish a connection back to work.  As soon as the connection is established, the status will go 'online'.  Okay, this is going to be an issue, because your home Internet connection might be slow especially if you are using wireless at home and when you try to copy something to your local desktop, guess what?  slow as hell... because everything you copy to the desktop is actually being redirected to the network share.  So, to get around this problem, we need to configure the 'Slowlink mode' settings..  The trick is to figure out what is the right value for latency or bandwidth..  In our case, we utilize 'latency' to distinguish between an acceptable network connection and a slow network connection.  This is a good article for determining the latency of the network.  The following group policies are applied to Laptops OU.  Anything about 60ms will be considered as slow link.
Computer Configuration | Administrative Templates | Network | Offline Files
- Configure slow-link mode.  UNC = \\server1\share1\*    Value = Latency=60

Scenario 4: undocked, shutdown and VPN from home.
This scenario would be very similar to scenario 3.  The only difference is that user has the laptop shutdown and bring it home.  So, when user start it up at home, user will login with their cache credential.  At this stage the offline file status would be "Offline (Not connected)", user will initiate the VPN session and connect to the network, once it is connected to the network, depending on the speed, if latency is set correctly (see Scenario 3) and falls above 60ms, the offline status will change to "Offline (Slow-link)", otherwise it will stay online if the latency is less than 60ms.

Another option to explore is to define the throughput (bits per second).  E.g.  Throughput=10000
or even a combination of both.  Value Name="*" Value="Throughput=10000, Latency=50

Userenvlog for Windows 7

User Environment Log is useful in troubleshooting login issues.  UserEnvLog is not enable by default, this is how you enable it:

1.  Create this folder if it does not exist:  %windir%\debug\usermode
2.  Create a registry subkey "Diagnostics" under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
3.  Create a new DWORD key  GPSvcDebugLevel
4.  Enter the value 30002 (hex)   http://blogs.technet.com/b/instan/archive/2008/04/17/troubleshooting-the-intermittent-slow-logon-or-slow-startup.aspx

5.  Reboot your machine and login, you should be able to find the Gpsvc.log in the folder %windir%debug\usermode directory.

Enabling winlogon.log
1.  Navigate to the this registry key.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}.
2.  Edit this value :  ExtensionDebugLevel   DWORD    2
3.  Reboot
4.  Log file will be located at %systemroot%\security\logs

Resetting Offline File Cache in Windows 7

When you enabled Folder Redirection with offline files, one of the benefits is that user do not have to wait for the files to be copied over to the network before they are able to access their desktop.  When you have offline files enabled, during the logon process, the files in your folders will be copied to local cache (c:\windows\csc), once completed, it will create the folder structures on the network and users will have access to the desktop.  The background sync will happen shortly after and the local cache will sync the files to the redirected folders. 

However, there are times where your local offline cache is corrupted due to various reason and you will run into all sorts of sync issues.  The only way to fix this is to blow away the local cache and have folder redirection sync the files from local folders again.  The way to do this is:

-  With admin privillege, start Registry editor.
-  Navigate to  HKLM | System | CurrentControlSet | Services | CSC | Parameters
-  Create a new key of "FormatDatabase"   REG_DWORD
-  Assign the value "1"
-  Reboot the machine.

After the reboot, check the "Offline files" in the Sync Center, it should be empty.  Also, the above key should be removed after the reboot. 

You will not have a fresh empty copy of the local cache database and the sync issue would be resolved (hopefully...)

Location of My Documents Folder - Folder Redirection

The path to the My Documents folder is stored in the following registry key, where path is the complete path to your storage location:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Value Name: Personal
Value Type: REG_SZ
Value Data: path

Any modification from the default is recorded in the following location and the path listed earlier is also updated:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Value Name: Personal
Value Type: REG_SZ
Value Data: path

If the administrator redirects My Documents by using group policy folder redirection, the path is present in this value and the option to modify the location of the My Documents folder is not available when you view properties of the My Documents folder.

Display Information about previous logons during user logon - Windows 7

When Windows Active Directory been raised to Windows 2008 domain functional level. you can specify a group policy settings to display information about previous logon. This is a good feature to have especially if you are really security fanatic guy and want to know if your domain account's been compromise in any sense.

The group policy setting is at:
Computer Configuration | Administrative Templates | Windows Components | Windows Logon Options

Display information about previous logons during user logon : Enabled.


Things to watch out for. 

1.  The domain controller will need to have this same setting set to "enabled" before the workstation get the policy otherwise you will get a nasty information like "Security policies on this computer are set to display information about the last interactive login.  Windows could not retrieve this information" and could never login to the domain.

2.  If you have a screen logout policy in place which lock the screen every 15 mins of inactivity, eveytime you hit Control-Alt-Delete to login to the domain, you will be presented with these logon information, user account attributes will be updated and the domain controller will be working extremely hard to replicate these information between each other.  I find this put a lot of load on the DC and really annoying at times.

3.  The registry settings is at : [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"DisplayLastLogonInfo"=dword:00000001

So, if you decided to rollback this settings and disabled the group policy on the domain controller and workstation but your user still getting the nasty information and not able to login.  Most likely you will need to login as local admin and delete this registry key.

Reference:  http://blogs.dirteam.com/blogs/jorge/archive/2008/02/10/showing-last-logon-info-at-logon-in-windows-server-2008.aspx

Rebuilding User Profiles in Windows 7

Time comes when you need to rebuild user profile locally on the system.  Things are a bit different with Windows 7.  Renaming the user directory in c:\users is not sufficient, you need to delete one of the registry key associate with the image path.

Steps involved:

1. Rename the user profile under c:\users\
2.  Go to the following registry and delete the correct key base on ProfileImagePath.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList

Restart your system and whola!!!!

Enabling Folder Redirection Logging to gather verbose troubleshooting

http://support.microsoft.com/kb/907355

To enable Folder Redirection logging for troubleshooting purposes.  Create a registry key under:
(Please note this only applies to pre-Windows Vista machines)

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics

New DWORD   |  FdeployDebugLevel

0000000F for verbose logging

00000000 for normal logging

The log files will be located at %windir%\debug\usermode\fdeploy.log

For Windows Vista and above, the logs will be in the application log or go straight into the Windows component, Folder Redirection log.

Re-initialize offline file cache and database

There are times when the offiline file cache gets corrupted and you will need to rebuild or re-initialise the cache database.  Microsoft has published a KB Article regarding to this.

http://support.microsoft.com/kb/230738

Running Powershell Interactively

When you run a powershell script locally in a powershell box, you will get error message like "Script cannot be loaded because execution of script is disabled on the the system.."

This is in fact what it says, execution of script is prohibited.  This is the default settings:  To run script interactively on the box, execute this command:

"Set-ExecutionPolicy RemoteSigned"

You will be fine after that.

Viewing MSS: GPO settings in GPMC.

Ever wonder how you can view the MSS settings in the management console to look at those FDCC group policy settings from NIST?

1.  Download the Windows 7 Security Compliance Management Toolkit.  This tool replaces the previous version called GPO Accelerator

2.  Install the Windows 7 SCM Toolkit with elevated admin privillege. 

3.  Install the LocalGPO from Start Menu | All Programs | Microsoft Security Compliance Manager | Local GPO

4.  Once installed, go to Start Menu | All Programs | LocalGPO | LocalGPO command-line and Run as Administrator

5.  Execute this command "cscript LocalGPO.wsf /ConfigSCE"

6.  Wait for "Security Configuration Editor has been modified successfully" message.

Launch your GPMC and you should see the MSS settings. i.e. Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options

Mounting WIM with ImageX

It's been a while since I need to do one of this.  I think I better document this here for my reference.  This is no rocket science.

To mount a WIM file so that you can deploy some custom settings such as additional folders and stuff as part of the OS installation.  This is what you do:

1.  Install Microsoft Windows AIK.
2.  Run a command prompt with elevated privillege in Windows 7
3.  Create a directory c:\mounted_images
4.  Change directory to c:\Program files\Windows AIK\Tools\x86
5.  Imagex.exe /mount Z:\Windows7_Source\Sources\install.wim 1 c:\mounted_images

Once mounted, you should be able to make modification.

6.  Imagex.exe /unmount /commit c:\mounted_images

http://technet.microsoft.com/en-us/library/cc766067(WS.10).aspx

Managing Stale Computer Accounts.

There were times where your computer accounts removal procedures failed somewhere along the process and that all these stale accounts floating around in the A.D and affecting your SCCM system discovery.  Hopefully this will at least help you to put in some sort of management for these stale accounts.

Assuming that you have the right access to A.D

Discovery - identify how many stale computer accounts.
Most organisations have separate OU for servers and workstation.  To find out how many stale workstation, bring up command prompt and run the following
- dsquery computer OU=Workstations,DC=domain_name,DC=net -inactive 12 -limit 1000
(querying workstations OU and look for computers that have been inactive for 12 weeks and limit the search by 1000)

Count - Do a count of stale computer accounts.
- dsquery computer OU=Workstations,DC=domain_name,DC=net -inactive 12 -limit 5000 | find /c "Workstations"

Move - For all those stale accounts you found, move them to a specify OU
- dsquery computer OU=Workstations,DC=domain_name,DC=net -inactive 12 -limit 5000 | dsmove -newparent OU=Stale,OU=Workstations,DC=domain_name,DC=net

Now, time for you to decide what you want to do with these computer accounts in this specific OU.  I would recommend leaving these computer accounts in the OU until about a year or so but put some sort of group policy to limit users from logging in and notify them to contact helpdesk for further actions.

Group policies you might want to consider is:
- Display Interactive Logon Message:
Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Interactive Login message.

- Deny Logon Locally
Computer Configuration | Windows Settings | Security Settings | Local Policies | Local Rights Assignment

Denying logon to the computer buy display a useful message to let user knows exactly what they need to do would be a good idea.

Removing - The following will remove the stale computer accounts which are inactive for 1 year (52 weeks)
- dsquery computer OU=Stale,OU=Workstations,DC=domain_name,DC=net -inactive 52 -limit 1000 | dsrm

Event 1096 The processing of Group Policy failed.

We came across this issue and I think it's worth mentioning it here.

There was the laptop which was not getting any domain machine policy.  Looking at the GPRESULT policy event, it has a lot of Event ID 1096 errors "The processing of Group Policy failed.  Windows could not apply the registry-based policy settings for group policy object LocalGPO."

When you do a "gpupdate /force", you see errors like these:

"Computer policy could not be updated successfully. The following errors were encountered:
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy
bject LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for mor
 information on the file name and path that caused the failure."

So, it turned out that the domain policy cannot be processed due to a problem with the local policy.   To fix this problem, the local policy file will have to be removed.  There is this registry.pol file located at:
c:\Windows\System32\GroupPolicy\Machine.  Rename this file to .bak or whatever and refresh the policy with a gpupdate /force.  The problem will go away.  The policy file could have been corrupted.

Source:  http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/ccf3b6ef-1321-46bc-95ae-03e534b5ae5c/

Enabling User Environment Debug Logging..

The following KB article is particularly useful if you are troubleshooting group policy issues.
http://support.microsoft.com/kb/221833

Enable logging by inserting the following registry key.

Entry: UserEnvDebugLevel  (DWORD) 
Type:  DWORD
Value: 10002

UserEnvDebugLevel can have the following values:

NONE 0x00000000
NORMAL 0x00000001
VERBOSE 0x00000002
LOGFILE 0x00010000
DEBUGGER 0x00020000

Location in registry:

HKLM | Software | Microsoft | Windows NT | CurrentVersion | Winlogon


Reboot your system and the log file will be created here.

%Systemroot%\Debug\UserMode\Userenv.log

*** Please note that this only work on Windows XP machines.  For Vista and Windows 7, you will need to check the group policy operational log.

Event 4110 CAPI2 Failed to add certificate to Third-Party Root Certification Authorities store with error: A certificate chain could not be built to a trusted root authority.

We have been noticing a lot of Event 4110 CAPI2 " Failed to add certificate to Third-Party Root Certification Authorities store with error: A certificate chain could not be built to a trusted root authority." errors in the eventlog of Windows 7 workstations lately.

After some thorough investigation, all these Windows 7 systems are in fact having issues with their Trusted Root Certificate updates.  It worked differently from Windows XP where their CA store doesn't get updated from Software Updates from Microsoft Software Updates, WSUS or SCCM Software Updates etc.  In Windows Vista or Windows 7, the update root certificates feature automatically check the list of trusted authorities on the Windows Update Website when the check is needed by a user's application.  The Event 4110 was generated when the certificate chains cannot be verified due to missing CAs.

So, in an enterprise environment where proxy servers and firewall are used, default Windows 7 (or Vista) will have problem requesting the updates of CAs.  There are a few ways to move forward.

1.  If you have one proxy server and very unlikely it will get changed, you can direct all Windows 7 systems to go through the proxy when requesting an update for CAs.  The following command will do just that.  When you restart the Cryptographic Service, you can see some actions happening.  Go to the Windows | Cryto Logs and make sure you enable the log before you do so.

To Set Proxy = netsh winhttp set proxy http://proxy:8080/
To Reset = netsh winhttp reset proxy


2.  Update the trusted root CAs by installing this file.  http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe

The rootsupd.exe can be run with a "/q" switch and it will get installed silently if you are thinking of deploying it using SCCM or something.

The problem with this option is that, you might need to do this every couple of months and also the risks of application acquiring certificates which are new and not found in this rootsupd.exe


3.  Use Group Policy to import certificates into the Trusted Root CA store.
Computer Configuration | Windows Settings | Security Settings | Public Key Policies

A lot of manual work for admins and also they will have a difficult time figuring out what trusted CA are being used by applications.


4.  Punch holes in your firewall and allow Windows 7 systems to connect directly to Microsoft for CAs.

5. Implement your own certificate domain services.  E.g.  PKI.



Articles:

Managing Trusted Root Certificates
http://technet.microsoft.com/en-us/library/cc754841.aspx#BKMK_adddomain


Certificate Support and Resulting Internet Communication in Windows Vista
http://technet.microsoft.com/en-us/library/cc749331%28WS.10%29.aspx


Dreamslayer:
http://dreamlayers.blogspot.com/2009/12/windows-7-cant-always-automatically.html

One way to get around desktop shortcuts missing ...

So, there is this scheduled maintenance task in Windows 7 which runs every Sunday at 1:00am and  removes broken desktop shortcuts if more than 4 are found.  (I am still a bit puzzled about the word "Broken".  In my tests I created some shortcuts which points to some network shares, they are legitimate desktop shortcuts but when the maintenance scheduled task ran, it found them to be broken for whatever reasons and removed them.  I am guessing that it might not have permission to access those files/shares and thefefore classified them as broken???)

The maintenance task actually runs some powershell scripts located at c:\windows\diagnosis\scheduled\maintenance which performs several maintenance tasks.  However, the one which we are interested in is called "TS_BrokenShortcuts.ps1"

This is my idea and I am yet to cofirm this.

The TS_BrokenShortcuts.ps1 is owned by "TrustedInstaller", so even the administrators will not have permission to modify it.  So, we will have to take ownership of the file.

- Bring up an elevated command prompt and issue this command:  What this will do is to change the owner of the file to Administrators.
"Takeown /f C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /A"

- Copy this file to a source location and change the number 4 to let say 50, which the maintenance task will only delete the broken shortcuts if  over 50 are found.  Come on..  50?  You got to be kidding me!!
(Get-ListLength $brokenStartupShortcuts)) -gt 4))

- Now, being the owner doesn't mean you will have permission to write/modify this file.  So, we will have to change the ACL (Access Control List) of this file.  Issue the following command will grant Administrators to have Full Control over the file.
icacls c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /grant Administrators:F

- The final step would be to copy the modified  TS_BrokenShortcuts.ps1 file and override the original file. 
xcopy TS_BrokenShortcuts.ps1 c:\windows\diagnostics\scheduled\Maintenance\TS_Brokenshortcuts.ps1 /y

Depending on what you want to do, you might want to consider deleting this file so that this particular task will never execute again. (Again, I am yet to confirm this!)

Now, the challenge is, how do I accomplish all these in SCCM OSD Task Sequence.  My quest continues...

[Updates  Feb 11th 2011]
I implemented the above findings to SCCM OSD Task Sequence with the following and it works like a charm.  The TS_Brokenshortcuts.ps1 is deleted and the Maintenance Task will not remove anymore broken shortcuts from now on.

1.  Run command Line "Takeown /f C:\Windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /A"

2.  Run Command Line "icacls c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /grant Administrators:F"

3.  Run Command Line "cmd.exe /c del c:\windows\diagnostics\scheduled\Maintenance\TS_BrokenShortcuts.ps1 /q"

(Note that when running OS command, such as "Del, Ren" etc, make sure you do the "cmd.exe /c <command>")

Deskop shotcuts gone missing after Windows 7.

I been hearing a lot of the complains from users about their desktop shortcuts gone missing in Windows 7 especially over the weekend.  Digging around the internet concludes that it is a known behavior of the System Maintenance Troubleshooter which runs every Sunday at 1am.  (The name of the task is called  Scheduled under Diagnosis in Task Scheduler).  If it finds more than 4 broken shortcuts, it will removes all the broken shortcuts.

As detail in http://support.microsoft.com/kb/978980/

The System Maintenance Troubleshooter runs a few maintenance tasks (powershell script) which can be found in C:\Windows\diagnostics\scheduled\Maintenance.

There are a few ways to deal with this:

1.  Keep broken shortcuts to less than 4.  (I think this is going to be a challenge for some users)

2.  Take ownership of the powershell script "TS_brokenshortcuts.ps1" and modify | rename | delete it.

3.  Disable the task in the task scheduler which is not a good idea as it runs other maintenance tasks as well.

It took me a while to work out how to use the schtask.exe command to find the right tasks for this one.
When you use "schtasks.exe /query", you will see the "Scheduled" task name which  System Maintenance Troubleshooter runs.   However, if you do a -- schtasks.exe /change /disable /TN "Scheduled"--, it will return an error because it couldn't find a task name called "Scheduled".

The Syntax is actually -- schtasks /change /disable  /TN "\Microsoft\Windows\Diagnosis\Scheduled" --

Software not getting installed from SCCM. execmgr.log showing spRebootRequest->JobStart failed 0x80004005

I ran into a situation a couple of times where softwares are not getting installed on the systems via SCCM deployment.  Upon checking the execmgr.log file,  I am seeing the job failed start with error messages spRebootRequest->JobStart failed 0x80004005.

As detailed in http://support.microsoft.com/kb/970635, under very rare condition, the job counter is not decremented when the job is finished.  The coordinating system prevents the system from being restarted because it thinks that the job is still running based on the job counter value.

The way to get it going again. 

1.  Check the registry key (HKEY_LOCAL_MACHINE\Software\Microsoft\Sms\Mobile Client\Reboot Management\JobCounter) and make sure that the value is not greater than 0

2. Restart the system manually.

Windows 7 RDP session randomly disconnected. (Part 2)

More researches lead me to this Microsoft KB article.
http://support.microsoft.com/kb/2083411

The above article make sense because users are being disconnected from RDP session randomly which match the interval of group policy refresh.

I have adjust the registry key to set to "0" manually and doing a final test to confirm the resolution.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
fDenyTSConnections.

This article is also useful.

http://setspn.blogspot.com/2010/12/remote-desktop-session-disconnection.html

Windows 7 RDP session randomly disconnected. (Part 1)

Users are experiencing RDP session disconnected randomly when connected remotely to servers via RDP session.  Checking at the event log.  You will see the following errors:
EventID 56 : Source TermDD
The Terminal Server security layer detected an error in the protocol stream and has disconnected the client. Client IP:  X.X.X.X
EventID 50 : Source TermDD
The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client
I did some research and found the following:


http://blogs.technet.com/b/askperf/archive/2010/03/25/the-curious-case-of-event-id-56-with-source-termdd.aspx


http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/ab950c6e-847a-4f51-bc15-b9f54793787c


Suggested cause of actions are:
1.  Disable Autotunning in the TCP to determine any improvement:    Open up an elevated command prompt and issue the following command.

netsh interface tcp set global autotuninglevel=disabled
netsh interface tcp set global autotuninglevel=normal 
(this will reverse the change if you find it has adverse effects.)
netsh interface tcp show global
(to show the TCP settings)


2. Set the MTU to 1300 (Default is 1500)

netsh interface ipv4 show interface
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1300 store=persistent
I carried out with some test and couldn’t come to a conclusion with this. After adjusting the MTU size, I managed to keep the RDP connection for over 2 days now without disconnection.  I will have to keep monitoring this one.

Event 8194, The Client-side extension could not remove computer policy settings for { } because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.

I am seeing this error in the application event log on a few Windows 7 clients.
"Event 8194, The Client-side extension could not remove computer policy settings for { } because it failed with error code '0x8007000d The data is invalid.' See trace file for more details."

Resolution:


- Log on to the machine
- Open Windows Explorer
- Navigate to %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History
- Delete all subdirectories under History.  (Please note %ALLUSERPROFILE% would be c:\programdata)


- Open a command prompt
- In the command prompt, enter gpupdate /force
- Verify that subdirectories will populate under %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History

Note: %ALLUSERSPROFILE%\Application Data\Microsoft\Group Policy\History contains a copy of the preferences contained in GPOs. If the copy process failed somehow, an invalid XML file may be left in one of the subdirectories, thus creating the 0x8007000d Error. By following the method described above, a clean copy of the GPOs is created and the GPO is working again.

Also, The following GUID registry keys under both of the following will need to be deleted too.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History

Ray's IT Technical Blog

This is Ray's personal I.T. technical blog.  A lot of times, when I come across an technical issue, I keep saying to myself "I remember fixing that issue before, how did I fix it again?" and it will take me a while to find the solution.  Well, this is what this blog is for, documenting the very specific solution to the problem.

Ray.