CHiLL Posted June 22, 2018 Posted June 22, 2018 (edited) So after discovering that the execution policy has been set to Bypass site wide by a GPO, I've changed the configuration to RemoteSigned. I did some testing with scripts that I've made and they executed fine. However we have some scripts that launch tasks on our 2012 R2 servers, such as a manual DirSync...and they're running/executing...but returning this error message: Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of RemoteSigned. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy". At line:1 char:46 + ... -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: ( [set-ExecutionPolicy], SecurityException + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Commands.SetExecutionPolicyCommand I have performed "Get-ExecutionPolicy -List" on the server with the following results: MachinePolicy RemoteSigned UserPolicy RemoteSigned Process Undefined CurrentUser Undefined LocalMachine RemoteSigned The GPO that was amended was: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell > Enabled: Allow local scripts and remote signed scripts. I don't understand why the CurrentUser is Undefined when it has been defined at the machine level. (Logged on as a domain admin) Edit: Found this Microsoft blog with the same issue: https://blogs.msdn.microsoft.com/pasen/2011/12/07/set-executionpolicy-windows-powershell-updated-your-execution-policy-successfully-but-the-setting-is-overridden-by-a-policy-defined-at-a-more-specific-scope/. I didn't want to have to go round the servers and set these manually, but if needs must! Edit2: Changed those on the server and now they're all showing as RemoteSigned, but the script is still complaining. The script is only three lines (and one is commented out and the other is a pause command!): Start-ADSyncSyncCycle -PolicyType Initial # & "C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe" Yet the same error is returned. The error references a command for "Set-ExecutionPolicy Bypass", which is clearly not in my script. I wonder if the "Start-ADSyncCycle" command is trying to call something else with a Bypass command in that? Edited June 22, 2018 by CHiLL
HPlum78 Posted June 23, 2018 Posted June 23, 2018 (edited) Are these schedule tasks? If so I would guess that the task has the -execution bypass setting being passed. (as part of the arguments of the task) Edited June 23, 2018 by HPlum78
CHiLL Posted June 23, 2018 Author Posted June 23, 2018 (edited) Are these schedule tasks? If so I would guess that the task has the -execution bypass setting being passed. (as part of the arguments of the task) I believe so, we just have a basic script to run it on demand if need be. I'll have another look on Monday. Edit: Though thinking about it, that script doesn't actually call/run the scheduled task. It purely runs the specified AzureAD cmdlet. Edited June 23, 2018 by CHiLL
CHiLL Posted June 23, 2018 Author Posted June 23, 2018 Are these schedule tasks? If so I would guess that the task has the -execution bypass setting being passed. (as part of the arguments of the task) When do you run that script? Usually when a change to an account has been modified and needs to be synced with Azure quickly.
HPlum78 Posted June 23, 2018 Posted June 23, 2018 (edited) You should not have to do an initial sync on a new user creation / account updates a delta will do. Triggering an initial sync is generally done when the schema of the metaverse changes/ or a MA changes. A delta sync will do for day to day operation. - - - Updated - - - As a side note to the issue Edited June 23, 2018 by HPlum78
CHiLL Posted June 23, 2018 Author Posted June 23, 2018 You should not have to do an initial sync on a new user creation / account updates a delta will do. Triggering an initial sync is generally done when the schema of the metaverse changes/ or a MA changes. A delta sync will do for day to day operation. - - - Updated - - - As a side note to the issue Well we do have another script for the delta too, which produces the same message in Powershell.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now