This one drove me a bit crazy I must admit. I had a GPO that would install an MSI file when scoped to a computer account. However, recently, it stopped working. When I ran rsop.msc and looked at the error tab, it kept stating “Software Installation did not complete policy processing because a system restart is required for the settings to be applied. Group Policy will attempt to apply the settings the next time the computer is restarted.”
Restarting the computer several times did nothing. Of course, I did what any normal IT person would do and I immediately consulted various AI chatbots. This lead me down many dead ends, the reason being this may be one of the worst errors I’ve ever seen. It had nothing to do with a pending restart. The problem? The GPO couldn’t find its source files.
This wasn’t reflected in the event logs or the RSOP error tab, it’s just a generic error that Microsoft decided to present when the software install piece of a GPO does not work. When I was working in GPMC on another server with an elevated account, the first thing I did was check the source path in the GPO and I could see the MSI file was there.
What I didn’t do right away is check the source path from a normal (non-elevated) user account. Once I did this, a bell rung in my head. Our security team found that the applications folder on our SCCM server was set with weak permissions, so the SCCM administrator restricted those permissions to elevated accounts and thus, my GPO was broken.
ChatGPT o3 came the closest finding the to the solution, in it’s third bullet point, it came up with
Use psexec ‑i ‑s cmd to open a SYSTEM shell and run dir \\server\share\package\app.msi. to resolve access issues
When the SYSTEM account is used by a GPO, the GPO will use the computer’s AD account (i.e. computername$) to reach the UNC path. ChatGPT is suggesting we use psexec with the -s option to force the computer into using its own AD account to access the UNC path and a failure to see the MSI file from this SYSTEM elevated session means we have some type of NTFS ACL problem on the source folder.
Rather than monkeying with the permissions of the original folder, I moved the source files to the NETLOGON share of the DCs. The files were relatively small, so I didn’t have to worry about the replication of the source folder between DCs.
-Soli Deo Gloria