Need to run the powershell script from Servicenow on the Midserver for the shared mailbox removal

[Atiruveedula]

Hi all,

I've built an employee offboarding flow in Flow Designer (Zurich) that handles the AD side end to end - disable user, remove from groups, update attributes, move to an Archived OU - all working using the OOTB Microsoft AD (ADv2) spoke actions.

I now need to add two Exchange Online mailbox steps on offboarding:
1. Convert the leaver's own mailbox to a shared mailbox (Set-Mailbox -Type Shared).
2. Remove the leaver's access (Full Access / Send-As) to any shared mailboxes they had (Remove-MailboxPermission / Remove-RecipientPermission).

**What I've found so far:**
- There are no OOTB actions in the Exchange Online spoke for either of these (no convert-to-shared, no remove-mailbox-permission).
- My understanding is this is because Microsoft Graph has no API for mailbox permissions or mailbox-type conversion - they can only be done via Exchange Online PowerShell. So these have to run as custom PowerShell on the MID Server.

**The blocking problem:**
Custom (inline) PowerShell will not execute on our MID Server at all. To prove it wasn't my script, I created a trivial custom action with a single line - Write-Output "test successful" - set to run inline on the MID Server via our AD connection alias. It fails with:

- Failed while executing commandScript<number>.PS1 (Access denied)
- PowerShell script execution failed. Script returned status 1 using account user <domain>\<service account>

So even a one-line inline script fails with Access denied. OOTB spoke actions (which use pre-existing scripts on the MID Server) work fine - it's specifically custom/inline PowerShell that fails. From investigation, it looks like the inline script gets copied into a hidden AppData folder under one account's profile but is executed under a different PowerShell service account that can't access that folder. We tried setting the MID Server property mid.powershell.target_base_dir to a neutral folder both accounts can access, confirmed it applied, but scripts still execute from the profile path and still fail.

**My questions:**
1. Has anyone gotten custom/inline PowerShell to run reliably on a Windows MID Server, and how did you resolve the 'commandScript.PS1 (Access denied)' execution-context issue?
2. Is mid.powershell.target_base_dir the correct property to relocate inline script execution, and why might it not take effect (Zurich)?
3. For Exchange Online mailbox permissions / convert-to-shared specifically - has anyone automated these from ServiceNow? Did you use custom PowerShell on the MID Server, or an external approach (Azure Automation, Power Automate) triggered by ServiceNow?
4. Is there any OOTB or supported route for these two operations I might have missed?

**Environment:** ServiceNow Zurich, Windows MID Server, Exchange Online (M365 cloud-only), ADv2 + Exchange Online + Entra ID spokes installed.

Any guidance appreciated - happy to share more detail.

Thanks!

[J Siva]

Hi @Atiruveedula 

I implemented the end-to-end mailbox and distribution group creation and management workflow using ServiceNow IntegrationHub and custom PowerShell scripts executed through MID Server script files rather than inline scripts. Although our process and requirements differ somewhat, I'm confident that you can execute your custom PowerShell scripts in a similar manner.

Regards,
Siva

[Atiruveedula]

Thq Shiva. will try that approach and see if it works or not for us.

[Atiruveedula]

Thanks so much for the reply - really helpful to hear you got the end-to-end mailbox/DL workflow running with custom PowerShell through MID Server script files.

I tried exactly that - I created the script as a MID Server Script File (so ServiceNow syncs it to the MID Server) and referenced it in the action as Script Type = 'MID Server Script File' rather than inline. But it still fails with the same error, even for a trivial one-line test script (just Write-Output "test successful"):

- Failed while executing <scriptname>.ps1 (Access denied)
- PowerShell script execution failed. Script returned status 1 using account user <domain>\<service account>

So in my environment, both inline scripts AND synced MID Server Script Files fail with 'Access denied'. Interestingly, the OOTB spoke PowerShell actions (AD v2, etc.) run fine - it's only custom scripts that fail. It looks like the custom script gets written to a location tied to one account's profile, but is executed under a different PowerShell service account that can't read it.

Since you clearly got custom script files executing successfully, could you share what you had to configure to make that work? Specifically:

1. Did you have to do anything on the MID Server host itself - e.g. folder permissions, or which Windows account the MID Server service runs as vs the account used to execute the PowerShell?
2. Did you set the MID Server property mid.powershell.target_base_dir (or any other property) to relocate where scripts are written/executed? I tried it but scripts still ran from the profile path.
3. Is the account you use in the connection/credential alias the same as, or different from, the account the MID Server service runs under? (I suspect the mismatch between those two is my problem.)
4. Any other MID Server or Windows permission setup you did to get custom PowerShell to run without 'Access denied'?

Anything you can share on how your MID Server was configured to allow this would be a huge help - I'm stuck on exactly this execution/permission step.

Thanks again!

[J Siva]

Hi @Atiruveedula 

1. Make sure your mid server service account has full access to the "Powershell" folder within the Mid server folder.

2. No.. i haven't done any changes to this system property.

3. Both are different. I'm not using the same service account.

I did this integration long back. So, need to check the level of access granted to the integration service account. Will try to setup this in my PDI and let you know.