The fact that machine Windows GPOs are automatically revoked on shutdown can cause issues when there are settings that need to be present at all times (prime example: Windows shutdown scripts, for further details see this thread: https://forums.novell.com/showthread.php/495848-Windows-GPO-Shutdown-Script-not-working-properly)
I do not understand why machine GPOs are revoked at all, in my understanding, different users get different GPOs, but a machine usually has one GPO set that never changes (unless the admin wants to change some settings manually), but there are no settings that change depending on external variables (like for user GPOs changing users).
Even if for some reason it is necessary to have machine GPOs revoked automatically on shutdown in some scenarios, there should at least be an option (just a regkey to set) for admins to prevent that, as in my scenario this revoking of machine GPOs at shutdown makes things harder rather than easier, and I could imagine this to be the case in virtually every scenario which relies on the shutdown scripts made possible by Windows GPOs.
by: Peter S. | over a year ago | Policy Mgmt
Comments
This was used by many customers in ZDM, it's amazing it's never been put in ZCM
We have an issue in Windows 10 where automatic updates are turned off by GPO. Somehow during shutdown or startup the GPO is being revoked. This results in automatic updates sometimes getting turned back on and sometimes not. I've had two situations as a result of this. My supervisor left their pc on intentionally overnight because they had work open. Windows update starting installing updates and rebooted the pc overnight even though we have that turned off. She ended up loosing work.
The second scenario was a user that had to wait an hour to login into their windows 10 workstation because updates had run during the day. One of the updates was a major windows release. It took an hour from the time they powered on until the update completely applied and they could login.
I opened an SR (101019977211) and was told development couldn't be convinced that this needs to be changed. I was provided a cheesy workaround that doesn't explain why this is acceptable behavior.
https://www.novell.com/support/kb/doc.php?id=7017792
This is a joke.
In our hospital, with more than 2.000 workstations, we have the same problem. I have opened many SR, and I couldn´t understand why Zenworks don´t keep machine policies on every restart.
We have decided set GPO values through fixed registry values, waiting a solution from Novell.
I hope I don't have to resort to making manual settings that GPO is suppose to take care of but may have to. What's the point of using GPO if it doesn't working properly? Is this how it operates in a complete Microsoft environment? If not, why is this deemed acceptable?
Microsoft Active Directory Policies don´t remove the "c:\windows\system32\grouppolicy" content.
The folder is only updated when a new or updated policy is established by the admin.
So it should also behave the Novell policy manager.
Official answer from Novell.
https://www.novell.com/support/kb/doc.php?id=7017792
Really? Are you kidding?
After reading these comments and the relevant posts from @baedamichi about how GPOs are applied, I think Novell should provide the suggested workaround as a "feature" in next updates:
- If ZW Agent cannot ensure policies are correctly applied (as stated by Novell in their KB Doc), it SHOULD have the option to copy the policy files to the agent cache (where ZCM has full control) on every logon/startup/logoff/shutdown (selectable by ZCM admin depending on the kind of policy).
This way, if I understood everything all right, will ensure that we get the right policies in effect at the right time. Moreover, it will avoid the need for an additional bundle which must be updated every time ZCM Policies change, thus reducing load on ZCM servers.
Please vote for this Idea if you find similar problems. This will be a change for the better.
I would like to add that Novell's workaround as seen in https://www.novell.com/support/kb/doc.php?id=7017792 is a poor one. Why?
When a shutdown is initiated, the ZenWorks agent STILL REMOVES the policy in place and REPLACES it by the one the admin has put in the cache. Now, depending on your machine's speed and depending on what else is happening on a machine during shutdwon, there is still a short window (might be 1 second to 10 seconds) during which it is NOT the correct machine GPO which is in place. This is especially annyoing if you have shutdown scripts in place, as even with the workaround, the do not always run on every shutdown (they do not run if the time when Windows would trigger the script coincides with the window during which the correct GPO is not in place). On my machines, I would estimate a probability of 98% to 90% for shutdown scripts to run (the slower the machine, the lower the probability).
Thus, to my mind, the only real solution would be an option to tell the ZenWorks agent to leave machine GPOs completely alone at all times (unless there really has been a change on the GPO on the server of course, that is).
And here's the reason this behavior shouldn't be deemed acceptable. Because of the possibilities of GPO not being set correctly due to revoking on startup and shutdown, we had Microsoft patch KB3185614 install automatically. What did this do? It causes the Novell/Microfocus client to crash thus not executing login scripts. This results drives not being mapped.
When more customers experience this hopefully it will be a wakeup call. Microfocus, you need to pay attention. Any other customer reading this make sure patch KB3185614 doesn't get installed.
https://www.novell.com/support/kb/doc.php?id=7018051