Let me start off by saying I am a super newb with power shell and orchestrator. I have been tasked with porting over an existing run book into a new environment. There is a section that is calling power shell to do a validation to make sure the user running the run book has permission. I want to be able to use 2 security groups “helpdesk” and “Infrastructure” instead of "User1, User2, etc…
Anytime there is turn over the code requires modification and its a pain.
$Adminuser = $env:UserName
Write-Output "Validation succeeded"
# Write-host "Validation succeeded"
$cmd = "Validate-Parameters "
if ($Adminuser -ne "")
$cmd += ' -Adminuser $($Adminuser)'
$Output = iex -Command $cmd
Also im not quite sure what the “$Output = iex -Command $cmd” is doing either. but its working so…
thanks in advance
Why don’t just configure the right permissions in Orchestrator? While I understand the code, it doesn’t make sense in my opinion to do it like this in Orchestrator. Check this blog post for some inspiration: https://blogs.technet.microsoft.com/manageabilityguys/2016/11/23/setting-system-center-orchestrator-runbook-operator-privileges/
Part of it is because I don’t understand orchestrator and have never worked with it. I’m just trying to replicate what we already have in a new environment, and make some improvements if there are opportunities. I think part of the reason is users don’t actually run the Runbook using orchestrator. They launch a powershell script and enter some variable, and the powershell script runs the runbook. This runbook is used to disable terminated users and remove them from groups, disable email etc…
The powershell script that kicks off the whole things requests usernames of the person being disabled, and the validation piece in the runbook is making sure the helpdesk analyst has the rights to do so.
Additionally by using powershell t start the runbook we are able to capture the user who is running the runbook as a parameter. I can use this parameter to update AD fields like description so I know who the person was that disabled a user account. I was looking to see if I could do this native in orchestrator, and it looks like I would need a separate “Get User” runbook to capture who invoked it by running a SQL query, but from what I can tell this does not work 100% of the time.