GPO Activation Issue
katanka
Posted messages
9
Registration date
Status
Member
Last intervention
-
kelux Posted messages 3065 Registration date Status Contributor Last intervention -
kelux Posted messages 3065 Registration date Status Contributor Last intervention -
Hello,
In a Windows Server 2012 environment / Windows 7 workstations, I want to set up a GPO on a number of computers in my domain.
I created a specific OU that contains these stations and I created and linked my GPO to this same OU. The goal of this GPO is to install a scheduled task on the workstation that will result in the shutdown of the PC at a fixed time, regardless of the user logged in.
In my GPO, I went to the computer configuration/preferences/... section to define my scheduled task (in creation mode) with the execution identifier as the domain admin account.
Result: the GPO executes on the concerned workstation but the creation of the scheduled task is rejected (Ox80070005 access denied).
I suspect this is a permissions issue; I have tried adding the domain admin account as an administrator on the workstation but it hasn't changed anything.
Thank you for your help.
In a Windows Server 2012 environment / Windows 7 workstations, I want to set up a GPO on a number of computers in my domain.
I created a specific OU that contains these stations and I created and linked my GPO to this same OU. The goal of this GPO is to install a scheduled task on the workstation that will result in the shutdown of the PC at a fixed time, regardless of the user logged in.
In my GPO, I went to the computer configuration/preferences/... section to define my scheduled task (in creation mode) with the execution identifier as the domain admin account.
Result: the GPO executes on the concerned workstation but the creation of the scheduled task is rejected (Ox80070005 access denied).
I suspect this is a permissions issue; I have tried adding the domain admin account as an administrator on the workstation but it hasn't changed anything.
Thank you for your help.
13 answers
Hello, I may not provide a solution, but I have some comments.
We do not use a domain admin account to run scheduled tasks, and even less on workstations. (And surely the domain admin account, I assume it’s the original account, so it has the most rights...)
You are jeopardizing your infrastructure; this is very dangerous:
https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati
https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/
With GPP you store the password of the domain admin account in the sysvol, in a file that everyone can read, and that everyone can decrypt. Microsoft has published the keys to encrypt and decrypt, and with a script in 20 seconds it’s done...
There is a patch that allows you to disable password storage via GPP (there are other tasks affected as well); if this patch has been applied on the domain controller, it is no longer possible for the password to be stored for the task creation, which could explain the error. You did not mention how the task was created via GPP. (if the password was indeed recorded, etc...).
On the other hand, the machine does not need domain admin rights to shut down... Also, adding the domain admin account as a local administrator is unnecessary, as the 'Domain Admins' group is by default a local administrator on every workstation/server.
-
In one of my posts, I had already addressed this issue.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
We do not use a domain admin account to run scheduled tasks, and even less on workstations. (And surely the domain admin account, I assume it’s the original account, so it has the most rights...)
You are jeopardizing your infrastructure; this is very dangerous:
https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati
https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/
With GPP you store the password of the domain admin account in the sysvol, in a file that everyone can read, and that everyone can decrypt. Microsoft has published the keys to encrypt and decrypt, and with a script in 20 seconds it’s done...
There is a patch that allows you to disable password storage via GPP (there are other tasks affected as well); if this patch has been applied on the domain controller, it is no longer possible for the password to be stored for the task creation, which could explain the error. You did not mention how the task was created via GPP. (if the password was indeed recorded, etc...).
On the other hand, the machine does not need domain admin rights to shut down... Also, adding the domain admin account as a local administrator is unnecessary, as the 'Domain Admins' group is by default a local administrator on every workstation/server.
-
In one of my posts, I had already addressed this issue.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
With method 3, we don't use GPP, just a GPO that runs a script.
This script executes the schtasks command to create the scheduled task.
The scheduled task will run the shutdown command.
I set the /F parameter in schtasks to overwrite the creation even if the task already exists. This ensures that it will be created, and also, if we want to update the task's parameters, we are sure to overwrite the existing task.
We create a GPO of the "logon script" type, on the machine side. The script will therefore be executed at each startup of the machine.
In this GPO, we run the script "create_task_shutdown.bat"
And in "create_task_shutdown.bat" we put this:
Then we need to play a bit with the schtasks and shutdown commands depending on what we want to do.
The options I provided are for illustrative purposes.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
This script executes the schtasks command to create the scheduled task.
The scheduled task will run the shutdown command.
I set the /F parameter in schtasks to overwrite the creation even if the task already exists. This ensures that it will be created, and also, if we want to update the task's parameters, we are sure to overwrite the existing task.
We create a GPO of the "logon script" type, on the machine side. The script will therefore be executed at each startup of the machine.
In this GPO, we run the script "create_task_shutdown.bat"
And in "create_task_shutdown.bat" we put this:
:: Creation of the scheduled task AutomaticShutdown
:: Runs every day at 20:30 minutes
:: and executes the command shutdown /s /t 0 (immediate shutdown)
:: the following code is on a single line
schtasks /create /ru system /rl highest /sc DAILY /tn AutomaticShutdown /st 20:30 /F /tr "shutdown /s /t 0"
Then we need to play a bit with the schtasks and shutdown commands depending on what we want to do.
The options I provided are for illustrative purposes.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Hello,
check the NTFS permissions of this directory on Windows 7 machines
C:\ProgramData\Microsoft\Crypto\RSA. The administrators and system groups must have full control.
Best regards.
check the NTFS permissions of this directory on Windows 7 machines
C:\ProgramData\Microsoft\Crypto\RSA. The administrators and system groups must have full control.
Best regards.
Hello,
Yes, that's correct. Can you explain to me how this check can affect the activation of my GPO (for my personal knowledge ;) ).
For your information, the domain user account on the concerned workstation is not listed in the user configuration section of the control panel. Does it matter or not to define it in this location?
Yes, that's correct. Can you explain to me how this check can affect the activation of my GPO (for my personal knowledge ;) ).
For your information, the domain user account on the concerned workstation is not listed in the user configuration section of the control panel. Does it matter or not to define it in this location?
Thank you very much for these clarifications Kelux, in this case I thought the admin account was only necessary for creating the task on the station and therefore would not be stored.
I just read your previous response to a similar question and I would like some clarifications on the implementation of method 3, particularly regarding the account to be used for creating the GGP, and the content of the verification script.
I just read your previous response to a similar question and I would like some clarifications on the implementation of method 3, particularly regarding the account to be used for creating the GGP, and the content of the verification script.
Thank you very much for these detailed explanations, I didn't know the schtasks command.
I will take a closer look at that.
I will take a closer look at that.
Hello,
I just ran the test following your recommendations.
So, I created a GPO that applies to an OU containing only one workstation.
I created the .bat file with the script and placed it in a subfolder of the sysvol folder on the AD.
In the GPO, I went to the Computer Configuration/Policies/Windows Settings/Script (Startup/Shutdown) section.
I modified the startup element to specify the .bat file.
I then forced the application of the GPO by right-clicking/updating the policy on the concerned OU.
A little while later, I saw a DOS window pop up on the workstation with the message about applying the policy.
However, at the scheduled shutdown time (1 PM), nothing happened! No specific messages in the Windows logs and no trace of the task when I open the task scheduler.
I just ran the test following your recommendations.
So, I created a GPO that applies to an OU containing only one workstation.
I created the .bat file with the script and placed it in a subfolder of the sysvol folder on the AD.
In the GPO, I went to the Computer Configuration/Policies/Windows Settings/Script (Startup/Shutdown) section.
I modified the startup element to specify the .bat file.
I then forced the application of the GPO by right-clicking/updating the policy on the concerned OU.
A little while later, I saw a DOS window pop up on the workstation with the message about applying the policy.
However, at the scheduled shutdown time (1 PM), nothing happened! No specific messages in the Windows logs and no trace of the task when I open the task scheduler.
I then forced the application of the GPO by right-clicking/updating the strategy on the concerned OU.
So this is useless. It's a bad translation from English.
In English we have "enforced," in French it translates to "appliqué."
Uncheck this box, it doesn't serve to "update a GPO on the OU," besides, that's not how it works, the sentence doesn't make sense.
I saw a command prompt window appear on the workstation moments later with the message of strategy application.
No link again.
-
This GPO, even if it is "seen by the workstation," will only take effect when the workstation starts. It is during the startup phase that this type of strategy will have its effect.
I mentioned this in my earlier messages:
The script will be executed at every startup of the machine.
If you don't start the machine, you won't see the effect of a startup script (loginscript); let's say the name is ambiguous.
-
Second point, no need to wait until 1 PM, just check if the task is created... if the task is created, the loginscript has had its effect.
And you will confirm that the task is correct by editing it.
If you need to modify or adjust the parameters, you just have to modify the script ;)
The main goal is to ensure that a task is created via the loginscript; after that, it's just a matter of adjustment.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
So this is useless. It's a bad translation from English.
In English we have "enforced," in French it translates to "appliqué."
Uncheck this box, it doesn't serve to "update a GPO on the OU," besides, that's not how it works, the sentence doesn't make sense.
I saw a command prompt window appear on the workstation moments later with the message of strategy application.
No link again.
-
This GPO, even if it is "seen by the workstation," will only take effect when the workstation starts. It is during the startup phase that this type of strategy will have its effect.
I mentioned this in my earlier messages:
The script will be executed at every startup of the machine.
If you don't start the machine, you won't see the effect of a startup script (loginscript); let's say the name is ambiguous.
-
Second point, no need to wait until 1 PM, just check if the task is created... if the task is created, the loginscript has had its effect.
And you will confirm that the task is correct by editing it.
If you need to modify or adjust the parameters, you just have to modify the script ;)
The main goal is to ensure that a task is created via the loginscript; after that, it's just a matter of adjustment.
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
I may not have expressed myself clearly regarding the application of the GPO. When we are in the “Group Policy Management” tool, on the left is the description of the forest/domain/OUs/GPO. If we right-click on an OU, the context menu displays an option “Group Policy Update...”. It is this option that I used.
Nonetheless, the GPO applies correctly, but the task is not created. schtasks /query does not list it. I copied/pasted the script on the machine to run it locally, the result was null, likely due to the limited rights of the connected user. When I launch a command prompt as admin and execute the command, the task is indeed created, it is visible with schtasks /query, visible in the task scheduler, and runs properly at the scheduled time.
Finally, no command prompt window appeared at the startup of the workstation, whether before or after the user's authentication.
Nonetheless, the GPO applies correctly, but the task is not created. schtasks /query does not list it. I copied/pasted the script on the machine to run it locally, the result was null, likely due to the limited rights of the connected user. When I launch a command prompt as admin and execute the command, the task is indeed created, it is visible with schtasks /query, visible in the task scheduler, and runs properly at the scheduled time.
Finally, no command prompt window appeared at the startup of the workstation, whether before or after the user's authentication.
The "machine" startup scripts launched via GPO run as "local system," so the task can be created without issue.
Finally, no DOS window appeared at the workstation startup, either before or after user authentication
This is normal; we don't see machine startup script windows by default on Win7. (Well, I need to verify, I still have some doubts).
As soon as we get past User authentication, the machine part has finished executing, so we will never see machine startup scripts after this point.
-
The tests are not precise enough to pinpoint where it fails.
Edit the line with the schtask command.
and add this at the end:
schtask .................. >> C:\TEMP\testgpo.txt
To see the result ...
If there’s nothing in the file, replace the entire line with:
At least we’ll see if a simple echo works ...
If it still doesn't work, then the machine is either unable to execute the script or can't find the script in the Sysvol ...
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Finally, no DOS window appeared at the workstation startup, either before or after user authentication
This is normal; we don't see machine startup script windows by default on Win7. (Well, I need to verify, I still have some doubts).
As soon as we get past User authentication, the machine part has finished executing, so we will never see machine startup scripts after this point.
-
The tests are not precise enough to pinpoint where it fails.
Edit the line with the schtask command.
and add this at the end:
schtask .................. >> C:\TEMP\testgpo.txt
To see the result ...
If there’s nothing in the file, replace the entire line with:
echo test >> C:\TEMP\testgpo.txt
At least we’ll see if a simple echo works ...
If it still doesn't work, then the machine is either unable to execute the script or can't find the script in the Sysvol ...
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Everything works!
I just found the source of the problem: the name of my script file!
I had named it script_coupure.bat and apparently it doesn't like the '_'.
Otherwise, the redirection to the txt file worked well, except at first because I didn't have a TEMP folder at the root of C:\. The txt file contains "Operation successful: scheduled task created."
If I understood the previous explanations correctly, it's better to use this method rather than the one with GPT, especially if you want to go back and modify the content of the scheduled task.
I would like to take advantage of your expertise to ask you 2 other questions about developments I want to bring to my infrastructure.
1) Is there a way to set connection time frames for my users other than typing them one by one?
2) The network drives of our users are mapped the old-fashioned way using netlogon scripts defined in each user record. Is it possible to define them a bit like we just did with the scheduled shutdown script? If so, is it as flexible as with the old method?
In any case, thank you for helping me solve this problem.
I just found the source of the problem: the name of my script file!
I had named it script_coupure.bat and apparently it doesn't like the '_'.
Otherwise, the redirection to the txt file worked well, except at first because I didn't have a TEMP folder at the root of C:\. The txt file contains "Operation successful: scheduled task created."
If I understood the previous explanations correctly, it's better to use this method rather than the one with GPT, especially if you want to go back and modify the content of the scheduled task.
I would like to take advantage of your expertise to ask you 2 other questions about developments I want to bring to my infrastructure.
1) Is there a way to set connection time frames for my users other than typing them one by one?
2) The network drives of our users are mapped the old-fashioned way using netlogon scripts defined in each user record. Is it possible to define them a bit like we just did with the scheduled shutdown script? If so, is it as flexible as with the old method?
In any case, thank you for helping me solve this problem.
For the "_" it's strange, I often use the underscore as a separator in my script names.
-
To get back to the GPP method:
Let's say GPP has a very particular behavior, especially depending on the context.
In some contexts, once applied, the GPP will not reapply itself, even if we modify the parameter; pushing an update can sometimes be cumbersome. We need to remove the GPP when it fails and redo it.
We have to reconsider the context, of course, when I said that the method without GPP was better, it was because the person also had Windows XP in their environment and not a full Windows 7 or 8...
GPP is not natively understood on XP.
-
Today, it is recommended to use GPP, especially when we have Windows 7 on client machines.
Be careful with using the "Apply once and do not reapply" option; that's where it can get tricky...
I still invite you to redo the same thing with GPP.
You asked to use the method without GPP ... so I responded accordingly.
There are some comparisons made here: https://docs.microsoft.com/en-us/archive/blogs/
The notion of tattooing, for example... if I remove my parameter, does the initial parameter get reset? With GPP, the answer is no....
-
Let’s say modifying a script is quite easy... however, it does have its constraints: we have to consider that machines will execute it at startup (or shutdown)... and not "live."
Scripting feels a bit "old-school" too... but some prefer to modify a line of code rather than click through 40,000 things.
-
1. No, you have to go through each account; you can't do it by group. However, you can multi-select users and configure them all at once.
However, it can be scripted in Powershell, but I don’t have the time to do it, and I’ve never done it before, but it shouldn’t be too complicated.
A super nice gentleman has already done it too:
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-Users-Logon-1bb4b1a2
However, be careful, you need to configure next to it, the "forcing" of user session disconnection when outside of the hour.
https://www.rebeladmin.com/2014/06/use-of-group-policies-to-control-log-on-hours-to-the-network/
-
2. Uh, yes and no.
It also depends on the schools; some prefer it as before, others do not...
We can very well do network drive mapping with GPP ;-)
Give it a test with GPP and you’ll see.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
-
To get back to the GPP method:
Let's say GPP has a very particular behavior, especially depending on the context.
In some contexts, once applied, the GPP will not reapply itself, even if we modify the parameter; pushing an update can sometimes be cumbersome. We need to remove the GPP when it fails and redo it.
We have to reconsider the context, of course, when I said that the method without GPP was better, it was because the person also had Windows XP in their environment and not a full Windows 7 or 8...
GPP is not natively understood on XP.
-
Today, it is recommended to use GPP, especially when we have Windows 7 on client machines.
Be careful with using the "Apply once and do not reapply" option; that's where it can get tricky...
I still invite you to redo the same thing with GPP.
You asked to use the method without GPP ... so I responded accordingly.
There are some comparisons made here: https://docs.microsoft.com/en-us/archive/blogs/
The notion of tattooing, for example... if I remove my parameter, does the initial parameter get reset? With GPP, the answer is no....
-
Let’s say modifying a script is quite easy... however, it does have its constraints: we have to consider that machines will execute it at startup (or shutdown)... and not "live."
Scripting feels a bit "old-school" too... but some prefer to modify a line of code rather than click through 40,000 things.
-
1. No, you have to go through each account; you can't do it by group. However, you can multi-select users and configure them all at once.
However, it can be scripted in Powershell, but I don’t have the time to do it, and I’ve never done it before, but it shouldn’t be too complicated.
A super nice gentleman has already done it too:
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-Users-Logon-1bb4b1a2
However, be careful, you need to configure next to it, the "forcing" of user session disconnection when outside of the hour.
https://www.rebeladmin.com/2014/06/use-of-group-policies-to-control-log-on-hours-to-the-network/
-
2. Uh, yes and no.
It also depends on the schools; some prefer it as before, others do not...
We can very well do network drive mapping with GPP ;-)
Give it a test with GPP and you’ll see.
--
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Hello,
Regarding the underscore, it's the only thing I changed between the two attempts, unless it's the fact that I modified the script content from its storage folder without going through the setup done in the GPO...
For my upcoming setups, thank you for the information and the links provided; I'm discovering PowerShell and I think this will be an excellent practical case.
One last question regarding the functioning of GPOs. In my case, I created a GPO changing computer configuration settings. Does this mean that, on the OU where I will apply it, its impact will only affect the computers present in that OU, or will it also affect the users present?
Regarding the underscore, it's the only thing I changed between the two attempts, unless it's the fact that I modified the script content from its storage folder without going through the setup done in the GPO...
For my upcoming setups, thank you for the information and the links provided; I'm discovering PowerShell and I think this will be an excellent practical case.
One last question regarding the functioning of GPOs. In my case, I created a GPO changing computer configuration settings. Does this mean that, on the OU where I will apply it, its impact will only affect the computers present in that OU, or will it also affect the users present?
Does this mean that, on the OU where I am going to apply it, its impact will only be on the computers present in this OU or also on the users present?
Indeed, only on the computers.
When configuring the "computer" part of a GPO, it will only affect computers. (The same reasoning applies to the "users" part.)
We can then filter the application of the GPO to a certain population of computers in this same OU using groups. We can also use WMI filters for more precision that AD groups do not allow.
Lastly, there is a special case, an exception.
You can indeed apply user settings to computers using the feature called "loopback processing" - it's good to know, but when you are starting out it complicates understanding.
You need to keep this concept in mind when the time comes.
-
A little bonus: when processing group policies. If the policy contains only computer (or user) settings, but not both, it is advisable to disable the application of the settings that will not be used.
For example, I have a GPO with only computer settings, I will disable the application on the user side, this is configured on the GPO in the "Details" tab, under "GPO status"; in this example, I would set "Disable user configuration settings".
This helps speed up the application of the policies, making it less time-consuming.
This is very noticeable in very large environments, though. But it's still a good habit to adopt.
-
Another point: there is RSoP which allows you to check what is applied to a machine/user. It is very useful for debugging when a GPO is not applying correctly or when we do not understand what is happening.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772175(v=ws.11)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736424(v=ws.10)?redirectedfrom=MSDN
Indeed, only on the computers.
When configuring the "computer" part of a GPO, it will only affect computers. (The same reasoning applies to the "users" part.)
We can then filter the application of the GPO to a certain population of computers in this same OU using groups. We can also use WMI filters for more precision that AD groups do not allow.
Lastly, there is a special case, an exception.
You can indeed apply user settings to computers using the feature called "loopback processing" - it's good to know, but when you are starting out it complicates understanding.
You need to keep this concept in mind when the time comes.
-
A little bonus: when processing group policies. If the policy contains only computer (or user) settings, but not both, it is advisable to disable the application of the settings that will not be used.
For example, I have a GPO with only computer settings, I will disable the application on the user side, this is configured on the GPO in the "Details" tab, under "GPO status"; in this example, I would set "Disable user configuration settings".
This helps speed up the application of the policies, making it less time-consuming.
This is very noticeable in very large environments, though. But it's still a good habit to adopt.
-
Another point: there is RSoP which allows you to check what is applied to a machine/user. It is very useful for debugging when a GPO is not applying correctly or when we do not understand what is happening.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772175(v=ws.11)?redirectedfrom=MSDN
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736424(v=ws.10)?redirectedfrom=MSDN
I just read your previous response to a similar question and I would like some clarification on implementing method 3, especially regarding the account to use for creating the GGP and the content of the verification script.