none
System Center Endpoint and Group Policy Results

    Question

  • I have an odd issue relating to Endpoint and how it affects local policies.

    A brief history:

    Several months ago we began deploying Endpoint to our domain, and we currently have over 600 clients. Around the same time, I began having issues seeing Administrative Templates in gpresult or RSOP through GPMC. I would always get an error that stated

    The following errors were encountered:

    Registry value "%windir%\Security\Database\*.jrs" is of unexpected type.

    or something similar. This would show under the computer's administrative templates heading.

    Whatever was listed, it was always located near the top of the registry.pol file under c:\windows\system32\grouppolicy\machine\

    After much experimenting, I found that simply deleting the registry.pol file would allow it to be re-created on the next policy update. We don't have any local policies other than those set by SCCM, and those seem to regenerate properly on their own.

    BUT.. when the Endpoint policies apply, the problem recurs, and gpresult no longer shows admin templates for the computer. This occurs on any computer running the Endpoint client.  It would appear that the file/folder exclusions are causing problems when the rsop is generated.

    Does anyone else have similar experiences? 

    We are running on Windows 7 x64 on a 2008 R2 Domain. I haven't tested this on other OS versions.

    Saturday, September 22, 2012 6:34 PM

Answers

  • Brandon,

    We noticed this exact same issue within my environment.  What I figured out was that there's a mismatch of registry data types between Microsoft's Administrative Templates for FEP2010 and the registry data type that is prescribed (written in registry) when FEP is installed using one of the XML policy template files that were either generated by (I presume) Microsoft or SCCM.

    I believe what is happening is that GPRESULT is trying to interpret registry entries related to FEP under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\ based upon registry data types that are prescribed within the group policy templates for FEP2010 (that are probably on your central store) but are throwing an error because the policy file that was probably specified during installation of FEP (likely something like 'Default Desktop Policy.xml') writes those exact same entries, only using the REG_DWORD data type rather than the expected (by GPRESULT/Administrative Templates) data type of REG_SZ.

    I'll bet you a dollar (not really) if you change the data type of the registry entry corresponding to the value of "%windir%\Security\Database\*.jrs"  under (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Exclusions\Paths) from REG_DWORD to REG_SZ and run GPRESULT again, you'll still get an error, but it'll complain about a different registry entry under the same general area of the registry.

    What I did to narrow all this down was to use FEP2010GPTool that Microsoft provides to convert the XML based FEP policy file to a GPO.  Before applying the resulting GPO to my test system, I installed FEP2010 specifying the XML based policy file, then exported HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware to a text file and called it "BeforeGPO.txt".  Next, I applied the GPO to the system and once again exported the same registry to a text file and called it "AfterGPO.txt".  Then a used WinMerge to compare the two text files.  What I found was that (aside from timestamps) the differences between the two files representing FEP related registry entries is that several longer string registry entries were first registry type "REG_DWORD" before applying the FEP GPO, and then the identical entries were registry type "REG_SZ" after applying the GPO.

    After applying the GPO to the effected systems, the registry entries were changed to the expected types (from the perspective of GPRESULT) and the GPRESULT errors went away in our environment.

    Hope this helps.

    Wednesday, October 17, 2012 8:07 PM

All replies

  • Brandon,

    We noticed this exact same issue within my environment.  What I figured out was that there's a mismatch of registry data types between Microsoft's Administrative Templates for FEP2010 and the registry data type that is prescribed (written in registry) when FEP is installed using one of the XML policy template files that were either generated by (I presume) Microsoft or SCCM.

    I believe what is happening is that GPRESULT is trying to interpret registry entries related to FEP under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\ based upon registry data types that are prescribed within the group policy templates for FEP2010 (that are probably on your central store) but are throwing an error because the policy file that was probably specified during installation of FEP (likely something like 'Default Desktop Policy.xml') writes those exact same entries, only using the REG_DWORD data type rather than the expected (by GPRESULT/Administrative Templates) data type of REG_SZ.

    I'll bet you a dollar (not really) if you change the data type of the registry entry corresponding to the value of "%windir%\Security\Database\*.jrs"  under (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware\Exclusions\Paths) from REG_DWORD to REG_SZ and run GPRESULT again, you'll still get an error, but it'll complain about a different registry entry under the same general area of the registry.

    What I did to narrow all this down was to use FEP2010GPTool that Microsoft provides to convert the XML based FEP policy file to a GPO.  Before applying the resulting GPO to my test system, I installed FEP2010 specifying the XML based policy file, then exported HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Antimalware to a text file and called it "BeforeGPO.txt".  Next, I applied the GPO to the system and once again exported the same registry to a text file and called it "AfterGPO.txt".  Then a used WinMerge to compare the two text files.  What I found was that (aside from timestamps) the differences between the two files representing FEP related registry entries is that several longer string registry entries were first registry type "REG_DWORD" before applying the FEP GPO, and then the identical entries were registry type "REG_SZ" after applying the GPO.

    After applying the GPO to the effected systems, the registry entries were changed to the expected types (from the perspective of GPRESULT) and the GPRESULT errors went away in our environment.

    Hope this helps.

    Wednesday, October 17, 2012 8:07 PM
  • Thanks for that great info Tim!  I'd seen this issue a few times but I'd never had the time to dig into.  Just recently I finally had to tackle it.  Your post made it go a lot faster than I thought it would!
    Monday, April 29, 2013 8:31 PM