With the requirement of OAuth 2.0 for Exchange Online and the need to work directly with credentials. There is a benefit to be gained by moving the script under direct control of SCSM through its workflow engine. However, placing the script within the current MP and sealing it would go against a founding principle of the connector in that administrators should be able to freely tailor it to their needs.
That's why the it seems that the best middle ground is to introduce an optional workflow (C#) that starts the script (PowerShell) in a target destination with the Run As Account of one's choosing. In doing so:
SCSM then takes direct responsibility for the connector's execution
administrators can continue to freely edit the script as they have done so the last several years
Run as Account management becomes dramatically simpler for on premise and online Exchange deployments
Since it's an optional workflow, those running in SMA or Azure Automation can continue to do so in the event platform specific customizations have been introduced
With the requirement of OAuth 2.0 for Exchange Online and the need to work directly with credentials. There is a benefit to be gained by moving the script under direct control of SCSM through its workflow engine. However, placing the script within the current MP and sealing it would go against a founding principle of the connector in that administrators should be able to freely tailor it to their needs.
That's why the it seems that the best middle ground is to introduce an optional workflow (C#) that starts the script (PowerShell) in a target destination with the Run As Account of one's choosing. In doing so: