Running after create script as admin

Hi all! I’m using the sample afterCreate rule here to launch a script to do some additional provisioning tasks. The issue that I’m running into though is that there’s a few cmdlets that need to be run in an admin context. I won’t share the full details of their code since it’s not mine to share but we need to execute Enable-RemoteMailbox, Get-RemoteMailbox, and Set-RemoteMailbox. For whatever reason in their environment, when testing the script, we could only get them to run inside of an admin powershell window.

So, is there a way to accomplish this inside of the context of an afterCreate script whether it’s launching the entire script in admin context via the rule or passing the AD object as a parameter into a secondary script run as admin?

When testing afterscripts from a remote server via powershell, I too have to open the PS console as an administrator, but when they are lauched via IQService, they run just fine. Did you configure the logon user for IQService inside “services” to be your service account?

Yes, IQService is running as the service account already.

Gotcha, my next attempt would be what you said in your post, from the afterscript, call another script and force elevated creds via “start-process”

Yeah, and you can do that with start-process powershell.exe -verb runas but the issue I’m running into is I can’t figure out how to pass the variable that contains the AD object into the next script.

You could pass the samaccount and just do a get-aduser, unnecessary call some would say but it’s extremely quick in most environments.

if there’s multiple DC’s you could run into an issue with propagation, one hack i’ve done is:

function getADUserAllDCs 
- Get-ADDomainController  get all the domain controllers
- loop through them, call get-aduser till you find your account, return account AND dc name, save $dc as variable

- specify -server $dc in all subsequent calls

I like this idea. Mind sharing how you pass the variable with start-process though? I’m having trouble getting my head wrapped around that one for some reason. I can do it no problem with functions but start-process is throwing me off.

I think the better solution here would be to figure out why your script isn’t running properly as-is, rather than making the script run as local admin (for security reasons).

My first guess would be the execution policy. Throw a Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser in there (before you set up your Exchange session) and see if that resolves it.

Otherwise, can you share the errors that Powershell is throwing? If you need to capture them, you can either add specific logging or just throw a Start-Transcript in your script to record all output.

If you do wanna try passing arts with start-process, you just add something like

-ArgumentList "-arg1 value1" , "-arg2 value2"

You can use provisioning plan data and find out on which DC provisioning activity was performed. You do not need to query DCs to get this. IdentityNow provides this data inside provisioning plan.

This appears to have solved the issue however I will ask for confirmation from the client first.

Glad to hear it! Please remember to mark that as the solution if it works on the client side :slight_smile:

1 Like

Hey Adam, did this work out?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.