Jump to content

Recommended Posts

Posted (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 by CHiLL
Posted (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 by HPlum78
Posted (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 by CHiLL
Posted
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.

Posted (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 by HPlum78
Posted
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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...