locked
rogue policy preventing further software deployments RRS feed

  • Question

  • Hi,

    I use Group Policy extensively to deploy software. I usually never tick the option to uninstall the application when it falls out of the scope of the policy. However, on a recent deployment I did tick this option. The software was then deployed. The software was no longer needed so I removed this policy, thinking the software would uninstall. It didn't. 

    Now I have a situation where every computer in my domain skips over new and amended software deployment policies upon start up. Two errors are logged in the Application log:

    Error 108 - Failed to apply changes to software installation settings. Software changes could not be applied. A previous log entry with details should exist (it doesn't). The error was: Not enough storage is available to complete this operation.

    Error 1085 - The Group Policy client-side extension Software Installation failed to execute. Please look for any errors reported earlier by that extension.

    These two errors appear identically on all computers in the domain.

    I believe the culprit to be the policy I deleted. A policy GUID appears in HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt\{04b66c...etc}. This key has a value of 'AppState' which is set to Hex 11.

    If I delete this key, then immediately run gpupdate /force and refresh the registry the key reappears! The key will also reappear if I reboot the machine.

    It appears nowhere in the Group Policy Mangement Tool, nor is a sysvol folder on the DC. I have looked in ADSI edit, under DC=OurDomain, CN=System, CN=Policies, but it doesn't appear here either. Am I looking in the correct place using ADSI edit?

    Is there anywhere else to look? what does gpupdate look at to populate the registry keys?

    Suggestions much appreciated.

    Michael.

    Tuesday, April 10, 2012 5:07 PM

Answers

  • Hello Michael,

     

    did you also delete the corresponding files in C:\Windows\System32\appmgmt?

    Please delete the Registry Key and the Files and try to run a gpupdate again.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!


    Tuesday, April 10, 2012 6:51 PM

All replies

  • Hello Michael,

     

    did you also delete the corresponding files in C:\Windows\System32\appmgmt?

    Please delete the Registry Key and the Files and try to run a gpupdate again.


    MVP Group Policy - Mythen, Insiderinfos und Troubleshooting zum Thema GPOs: Let's go, use GPO!


    Tuesday, April 10, 2012 6:51 PM
  • Hi,

    Thanks for your posting.

    This is a known issue, Group Policy to Remove Program May Not Be Applied to Some Users and Computers

    To prevent this issue from occurring, you should click to select the Uninstall the applications when they fall out of the scope of management check box when you initially deploy (assign or publish the package) the group policy. This option stores the uninstall information in the user profile when the user installs the program. When the GPO is no longer applicable, the program is uninstalled.

    Have you delete the GPO form GPMC, if not, re-link the GPO to its previous OU and select “Immediately uninstall the software form users and computers” in All Task.

    For Error 1085, you may refer to this article to fix it:

    Event ID 1085 may be logged in the Application event log on Windows XP
    http://support.microsoft.com/kb/898062

    For more information please refer to following MS articles:

    Group Policy to Remove Program May Not Be Applied to Some Users and Computers
    http://support.microsoft.com/kb/240790
    How to use Group Policy to remotely install software
    http://support.microsoft.com/kb/816102

    Lawrence

    TechNet Community Support

    Wednesday, April 11, 2012 7:13 AM
  • Thanks Matthias,

    Your tip fixed this problem. Within C:\Windows\System32\AppMgmt\ was a folder called MACHINE and a single file called AppMgmt.ini. I deleted the MACHINE folder, as well as the rogue registry key mentioned above, and ran gpupdate /force and rebooted.

    Upon restart, the computer started to install the software!

    Under C:\Windows\System32\AppMgmt\ I now have the AppMgmt.ini file along with a dozen {GUID}.aas files, which represent my deployed software. The same dozen GUID keys also appear in the registry under HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\AppMgmt\. I still see the key which I thought was causing the problem - {04b66c...etc} - but I guess this is just ignored?

    Thanks again for your assistance.

    Michael.

    Wednesday, April 11, 2012 8:57 AM
  • Hi,

    I am reopening this question as the problem is not fully resolved. Deleting the files within C:\Windows\System32\AppMgmt and also all the Group Policy registry keys from HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy does resolve this problem temporarily. Upon the first reboot, all applications applicable to that machine install themselves (reinstall themselves to be accurate, as they already existed on the machine).  

    However, the rogue policy reappears after a second reboot. This causes the event viewer to log 

    Application Event 108 (Application Management) - "Failed to apply changes to software installation settings.  Software changes could not be applied.  A previous log entry with details should exist.  The error was : Not enough storage is available to complete this operation."

    and

    Application Event 1085 (UserEnv) - "The Group Policy client-side extension Software Installation failed to execute. Please look for any errors reported earlier by that extension."

    Future software deployments then do not happen. Within HKLM\...\Group Policy, under AppMgmt, I see 7 policies (represented by their GUID). However, according to GPMC only 6 polices are applied to this machine. The rogue 7th policy has only the following registry attributes...

    Appstate = (Hex) 11

    Compared to the other 6 policies, this doesn't look right at all. Deleting this key and running gpupdate /force causes the key to regenerate. But where from???

    I have looked everywhere. Within Sysvol on my domain controllers I have 52 policies. I checked each one carefully and all are valid. I then looked through ADSI Edit, under System\Policies\ again checking each one. Also 52. All are valid and current.

    I know this rogue policy is one which I deleted from GPMC a long time ago, but I don't see how the machines are picking it up. I'm baffled. Any suggestions??

    Thanks very much

    Michael.

    Tuesday, August 21, 2012 9:31 AM