• Software Install Event Id
• Event Id 103 Software Installation Manual
• Event Id 103 Software Installation Download

I'm trying to deploy an MSI via the Group Policy in Active Directory. But these are the errors I'm getting in the System event log after logging in:

• The assignment of application XStandard from policy install failed. The error was : %%1274
• The removal of the assignment of application XStandard from policy install failed. The error was : %%2
• Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon. The error was : %%1274
• The Group Policy Client Side Extension Software Installation was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.

When I reboot and log in again I simply get the same messages about needing to perform the update before the next logon. I'm on a Windows Vista 32-bit laptop. I'm rather new to deploying via group policy so what other information would be helpful in determining the issue? I tried a different MSI with the same results. I'm able to install the MSI using the command line and msiexec when logged into the computer, so I know the MSI is working ok at least.

David Thomas GarciaDavid Thomas Garcia

Well this is just as annoying as can be but it turns out to be pretty quick to resolve. If you reboot your client PC’s but find some software you pushed via Group Policy did not install, you likely are in Asyncronous Policy Processing Hell. Software wont deploy, but GPO gets applied and MSI is installable manually. Event ID 108 should provide 'Failed to apply changes to software installation settings.

12 Answers

You're seeing the dreaded scourge of asynchronous policy processing. It's not a 'feature' (and was default-off in Windows 2000 but default-on in Windows XP and above) and causes exactly what you're seeing-- non-deterministic behaviour with processing some types of GPO settings.

In a GPO that applies to that computer, add the following setting:

• Computer Settings
  • Administrative Templates
    • System
      • Logon
        • Always wait for the network at computer startup and logon - Enabled

After you set that (and allow the GPO to replicate if you're in a multi-DC environment), do a 'gpupdate /force /boot' on the subject PC. It will reboot and you should see the software installation occur.

The 'Always wait for the network at computer startup and logon' slightly slows down the startup and logon because all GPO extensions are allowed to process, but the upside is that all GPO extensions are allowed to process.

Evan AndersonEvan Anderson

I tried the Always wait for the network at computer startup and logon - Enabled setting from the answer by @Evan Anderson, but it wasn't until I added this setting below as well that allowed the software to install. Not sure if it was a combination of both settings or not. It's working now, so I'm leaving both settings.

In a Group Policy applied to these workstations, navigate to:

Computer Configuration > Policies > Administrative Templates > System > Group Policy

Enable the Specify startup policy processing wait time. Set Amount of time to wait (in seconds): = 120

120 might be overkill, but that worked for me. Other forums suggested setting that to 30 seconds. Even though 30 seconds default (when policy is not set), forcing it to 30 seconds worked for them.

This can happen if the application is already installed but msiexec is unable to uninstall it. Most common scenario is a previous manual install with 'Only for me' selected instead of 'Everyone who logs on to this computer'.

You can use the Windows Installer Cleanup Utility (http://support.microsoft.com/kb/290301) to trick the PC into thinking that the app is no longer present, and then it should come good.

Maximus MinimusMaximus Minimus

And I just found another different cause of this error. If you have 'Spanning Tree' configured on the ethernet switch connected to the problem workstation, it will delay activation of the switch port when the PC boots up. Disabling Spanning Tree for the switch port or enabling 'Spanning Tree Portfast' for the switchport solved this problem on a few of my workstations.

I had the same problem but none of the fixes above worked. I finally figured out that there was another GPO trying to install software before mine, and it was failing with the %%1274 error because the GPO itself had the wrong permissions. For some reason that failure was then preventing my GPO from installing, even through mine had the correct permissions. Once I disabled the other problem GPO, my GPO installed correctly.

Changing the 'Startup policy processing wait time' worked for me. It was set to 30 seconds, but certain workstations were still failing with %%1274.

I upped it to 90 seconds and they were happy.

Sometimes your group policy can get screwed up. Try removing the entire registry key HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Group Policy. You will probably find everything from GP gets installed again on reboot. You may want to backup your registry first..

Software Install Event Id

I faced the same behavior with couple of laptops. They worked fine for couple of years, and then suddenly they didnt install any new software via gpo. Forcing the 'Startup policy processing wait time' setting seem have corrected the problem. As said before it should be 30secs by default, but for me it seemed, that laptops didnt wait at all on startup for policies but skipped straight over.All laptops were win7x64, DCs Server2008R2 and Server2012.

We had the same issue. We finally figured out that our laptops were RADIUS authenticated to WiFi, and the network installation couldn't start until the user logs in with AD credentials (because no network connectivity until then to remotely execute the installation files). And after the user logged in, it was too late as the installation should start before that.

When client connected via Ethernet it worked like a charm!

Andrew Schulman

Problem SOLVED!

Event Id 103 Software Installation Manual

I was logging into client machines as domain user with Enterprise/Domain admin privileges and able to access a shared folder containing MSI installation packages without any problem. Though, at some point tried accessing it via IPshare_path_to_msi_packages_folder from another non-domain PC and kept getting a login pop-up.Basically, even though one allows all domain and non-domain users/groups or 'Everyone' read/write permissions on shared folder it would still not work and prompt me for username/password thereby not allowing local client to pull down packages pointed by GPO. This is caused by anonymous access disabled by default. After enabling it and giving read/write permissions to MSI folder was then able to successfully deploy majority of packages and only synology-cloud-station-3.1.-3320.msi failed (need to look into it). I was also able to access the shared folder from any non-domain machine.

I was getting these error messages pretty much every 5 minutes in Events > System:

101The assignment of application 7-Zip 9.20 (x64 edition) from policy DOMAIN base packages installation failed. The error was : %%1274

103The assignment of application 7-Zip 9.20 (x64 edition) from policy DOMAIN base packages installation failed. The error was : %%1274

108Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon. The error was : %%1274

1112Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon. The error was : %%1274

Setup:

SERVERS DC1 (PDC) + DC2 (BDC) + DC3 (DBC)Windows 2012 R2 Standard fully updated

CLIENTSWindows 7 Pro SP1 (clean Dell restore, fully updated, conflicting packages such as old Adobe Flash uninstalled)

Drivers acer aspire m3610 windows vista. Have already tried on clients:

• gpupdate /force
• gpupdate /force /boot (both ask to reboot and throw error that policies have not been applied)
• gpresult /r (looking good)
• both servers and clients can access shared drive where MSI packages are stored
• rebooted multiple times DC1 and clients after changes to GPO

GPO disable UAC:

* Computer Configuration * Policies * Windows Settings * Security Settings * Local Policies * Security Options ELEVATE WITHOUT PROMPTING: User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode DISABLE: User Account Control: Detect application installation and prompt for elevation DISABLE: User Account Control: Run all administrators in Admin Approval Mode

GPO deploy base software:* Computer Configuration * Policies * Administrative Templates * System * Logon ENABLE: Always wait for the network at computer startup logon * Group Policy ENABLE: Specify startup policy processing wait time (temporarily set to 120 will change to 30 later)

* Computer Configuration * Policies * Software Installation * 7-Zip 9.20 (x64 edition) v9.20 Assigned LANIPUtilsSoftwareGPO7zip-7z920-x64.msi * Google Chrome v66.41 Assigned LANIPUtilsSoftwareGPOgooglechromestandaloneenterprise.msi * Mozilla Firefox (en-GB) v35.0 Assigned LANIPUtilsSoftwareGPOfirefox-35.0.1-en-gb-msi * Synology Cloud Station v3.1 Assigned LANIPUtilsSoftwareGPOsynology-cloud-station-3.1.-3320.msi

All GPOs are placed in Group Policy Objects then linked from GPOs directly under our domain. Other settings such as IE restrictions from another GPO setup the same way apply to client correctly.

There is no other errors in AD, DHCP, DNS are working perfect, machines get IPs and can resolve names via nslookup as well as ping each other on IPv4/IPv6.

Evan Anderson's answer is fine, but he's missing a pretty important disclaimer:

This can significantly slow down off-domain logins for laptops and wireless clients.

Considering the workaround without this GPO is to simply reboot twice, I don't really see why anyone would take that trade off.

Windows 2012 R2

Event Id 103 Software Installation Download

In a Group Policy applied to these workstations, navigate to:

Computer Configuration > Policies > Administrative Templates > System > Group Policy

Enable the Specify startup policy processing wait time. Set Amount of time to wait (in seconds): = 120

Not the answer you're looking for? Browse other questions tagged active-directorygroup-policymsi or ask your own question.

Hey SavannahMick,

This behavior occurs because Windows automatically closes any registry handle to a user profile that is left open by an application. Windows Vista does this when Windows Vista tries to close a user profile.
In versions of the Windows operating system that are earlier than Windows Vista or Windows 7, you must install the User Profile Hive Cleanup Service (UPHClean) utility to have the same functionality. However, the UPHClean utility is incompatible with Windows Vista and Windows 7. Additionally, the UPHClean utility is not needed because this functionality is built into Windows Vista.

You may try performing aClean Boot to check if any security software is not letting windows to close the registry key.

To help troubleshoot error messages and other issues, you can start Windows 7 by using a minimal set of drivers and startup programs. This kind of startup is known as a 'clean boot.' A clean boot helps eliminate software conflicts.

How to troubleshoot a problem by performing a clean boot in Windows 7:

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

Also, see the section on how to return your computer to a Normal startup mode by following the steps under “Reset the computer to start as usual.

Regards,

Savan – Microsoft Support.