This is just a quick post to cover off the mysteries of policy assignment with Microsoft Teams.
Whether you’re applying policies via the Teams admin console or via PowerShell you may be thinking it is a random act of chance as to when the policy will take effect on the target user’s client?
A lot of settings via policy are delivered to the client in-band. If you’re not familiar with this term, it essentially means that the client will receive configuration changes whilst being used and apply them without the user signing out and back in. However, when these configuration changes sync to the client is a bit of a lottery.
In most cases you can sign out and back in to bring in the new changes to force it if you cannot wait for in-band provisioning. However, even this seems to be somewhat of a lottery some times.
The old rule of on-premises was to wait for 15 minutes before attempting to sign back in. This rule derived from the typical AD Domain Controller replication time and had nothing to do with any other application replication. But the rule stuck for many applications due to their dependency on AD.
In respect to Microsoft Teams things are a little more complicated in the cloud. Its made up of lots of different micro services that all have to understand settings and parameters. In particular policies in Teams are driven from Skype for Business Online for UC based policies as well as AzureAD for group based restrictions. In order for the policy to take effect, these systems have to replicate between themselves and this can take a variable amount of time. Therefore, sometimes the 15 minute rule does not apply in this instance.
When you speak to Microsoft they invariably tell you to wait up to 30 minutes between change and test. Even though most of the time this will be more than sufficient there are times where the cloud goes a little bit wrong.
I was working with a premier support engineer on a Microsoft Teams policy issue and the feedback that was given by Product Group was that it can take up to 24 hours for a newly created policy to replicate properly through their cloud. As well as up to 24 hours for the user to become affected by the policy.
This seems an overly excessive amount of time. However, there are things that you can do to prove the theory on whether your tenant has policy sync issues.
The primary option would be to use the web client to validate policy restrictions in the first instance. Being a web app, you’re getting the settings directly from the tenant pre-loaded into the web interface and therefore not impacted by the desktop application cache. If it is not as expected in the web interface, then it is likely you haven’t waited long enough, or there are more issues that require a support ticket. If your settings have not come through on the web client within one hour, it is probably time to troubleshoot and consider a support case.
If you’re getting the settings in the web client but not in the desktop client then you can either wait for 24 hours for the cache to refresh itself (may be done sooner) or clear the Teams client cache.
You can do this by browsing in Windows Explorer to %appdata%\Microsoft\Teams and deleting the Application Cache and Cache folder and logging back into Teams
This will force the fresh retrieval of your policy settings from your tenant. If this still fails, then you will need to raise a ticket with Microsoft.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale