Dear @Sushil Dangi,
Welcome to Microsoft Q&A Forum!
Thanks for reaching out with your questions around simplifying the assignment of Resource-Specific Consent (RSC) policies in Microsoft Teams. After reviewing your current process and exploring available options, I wanted to clarify that:
- PowerShell is still required to create and assign RSC policies.
- At this time, Microsoft Graph API does not support creating or fully assigning RSC (ApplicationAccessPolicy) policies. While Graph can help with other aspects (like calendar subscriptions or user management), the actual policy creation and assignment must still be done via PowerShell.
That said, I have several suggestions that you can try to see if they can help you to simplify the process:
1.Option 1: This method enables or disables RSC for all apps across Teams and Chat using Microsoft Graph PowerShell SDK:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
Set-MgBetaTeamRscConfiguration -State EnabledForAllApps
Set-MgBetaChatRscConfiguration -State EnabledForAllApps
Set-MgBetaTeamRscConfiguration -State DisabledForAllApps
Set-MgBetaChatRscConfiguration -State DisabledForAllApps
This controls whether apps with RSC permissions can access Teams and Chat resources across your tenant. However, this does not assign the RSC policy to users, that still requires PowerShell.
2.Option 2: This method ensures your app is automatically installed and pinned for users or groups:
- Go to Teams admin center > Teams apps > Setup policies
- Create or edit a policy
- Configure app installation permissions
- Assign policy to users/groups
This ensures the app is deployed and visible to users, but it does not grant the app access to meeting content. To enable access to meetings and chats, you still need to assign the RSC policy via PowerShell.
Additionally, I have some information for your second requirement: Handling UPN/Email changes in Calendar Subscriptions & RSC. Here’s how identity changes affect your integrations:
- When subscribing to a user’s calendar via Graph API, use the user’s UPN (login email) or, preferably, their Azure AD object ID. Avoid using primary email aliases, as they may not be accepted by all endpoints.
- If a user’s UPN or email changes, any Graph subscriptions using the old UPN will stop working. You’ll need to re-subscribe using the new UPN or ideally use the object ID to avoid this issue.
- RSC policy assignments are tied to the user’s Azure AD object, not their email or UPN. So, if a user’s email or UPN changes, the RSC policy remains assigned. No re-assignment is needed unless the user account itself is deleted or recreated.
- For long-term stability in integrations, always use the user’s object ID where possible. It is immutable and survives UPN or email changes.
Also, I found these articles that may be related and helpful for you:
- Teams Setup Policies: Assign policies to users and groups
- UPN Change Planning: Plan and troubleshoot UserPrincipalName changes in Microsoft Entra ID
- Graph API User Identification: Get a user
- Calendar API Usage: Working with calendars and events using the Microsoft Graph API
I hope this information can give you more insights in this case. Wish you a pleasant day!
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.