You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a service which manages cost and security governance across several thousand tenants. This service runs in Azure Functions, which scales out by creating additional Powershell runspaces. The challenge is that the msgraph cmdlets only have a single per-process context which changes when calling Connect-MgGraph.
This causes the following behavior:
Runspace 1 calls Connect-MgGraph -TenantId <Tenant 1> and starts running other graph commands.
Runspace 2 starts and calls onnect-MgGraph -TenantId <Tenant 2>.
Runspace 1 incorrectly executes its commands against Tenant 2.
Our service also manages Azure subscriptions using the Az cmdlets. Az cmdlets solves the multiple runspace issue by providing the -DefaultProfile parameter on all commands. This allows each runspace to execute independently against different tenants and subscriptions. The pattern looks like:
We have a service which manages cost and security governance across several thousand tenants. This service runs in Azure Functions, which scales out by creating additional Powershell runspaces. The challenge is that the msgraph cmdlets only have a single per-process context which changes when calling Connect-MgGraph.
This causes the following behavior:
Our service also manages Azure subscriptions using the Az cmdlets. Az cmdlets solves the multiple runspace issue by providing the -DefaultProfile parameter on all commands. This allows each runspace to execute independently against different tenants and subscriptions. The pattern looks like:
Ask:
Provide a common -DefaultProfile type of parameter for all msgraph cmdlets which allows for a saved context to be utilized.
The text was updated successfully, but these errors were encountered: