47

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 Garcia
  • 603
  • 2
  • 8
  • 10

13 Answers13

64

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 Anderson
  • 141,071
  • 19
  • 191
  • 328
  • I was running into the above error code in the original question. After applying your fix I got into the 'Error 1612. The installation source for this product is not available. Verify that the source exists and that you can access it.' It exists and I can access it. Any ideas on how to troubleshoot that? (tried `gpupdate /force /boot`)? Any special permission required on the distribution point? – Unreason Aug 26 '10 at 13:54
  • 1
    Giving 'Domain Computers' read access to distribution point did the trick for me. – Unreason Aug 26 '10 at 14:14
19

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.

screen shot

Andrew Bucklin
  • 435
  • 1
  • 5
  • 12
6

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 Minimus
  • 8,937
  • 1
  • 22
  • 36
  • Thanks for the suggestion, but upon running the utility I didn't see the app listed. I'll keep this bookmarked in the future though in case this is a solution to other problems. – David Thomas Garcia Aug 10 '09 at 17:43
4

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.

Richard
  • 41
  • 1
3

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.

2

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.

pbc5501
  • 51
  • 6
2

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
  • 8,561
  • 21
  • 31
  • 47
1

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...

1

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.

hyvokar
  • 11
  • 1
0

we modified the setup.bat and wrote another one to run using UNC (\...) path and added this as a startup script to the GPO, if you like to try it:

https://github.com/lhpitn/ManageEngineEndpointSetup

lhpitn
  • 1
0

Problem SOLVED!

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 \IP\share_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:

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

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

108 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

1112 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

Setup:

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

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

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 \LANIP\Utils\Software\GPO\7zip-7z920-x64.msi * Google Chrome v66.41 Assigned \LANIP\Utils\Software\GPO\googlechromestandaloneenterprise.msi * Mozilla Firefox (en-GB) v35.0 Assigned \LANIP\Utils\Software\GPO\firefox-35.0.1-en-gb-msi * Synology Cloud Station v3.1 Assigned \LANIP\Utils\Software\GPO\synology-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.

webcoder
  • 11
  • 3
0

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.

Atta
  • 1
-1

Windows 2012 R2

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

  • 7
    This answer appears to be a duplicate of an earlier one. Do you have any additional information to add? – womble Aug 25 '15 at 02:19