Case #
There are various cases in Azure resource configuration and in Microsoft 365 resource provisioning or configuration in which a configuration change made by an administrator cloud-side is not reflected immediately at user-side.
Solution #
This behavior in most cases is by design but the end-users should be aware of ways to "reset" their local client state to reflect the cloud-side configuration changes.
One possible reason why a new Azure or M365 resource provisioning or configuration action is not reflected immediately to the clients is because it normally takes some time for the configuration change to replicate in all underlying components which comprise the configuration in question. For example in an Azure VM scale set or in an Azure Web App with multiple instances running simultaneously, replicating the configuration changes to all underlying resources may take some time. This is especially true if the Azure resource is setup in a multi-region design, in which case configuration changes need to be replicated between regions. This replication time is usually not higher than 1 hour. However in certain cases it make take up to 8 hours or longer. If this is the case, then you will most likely need to open an Azure or Microsoft 365 technical support ticket, so that the operations team can carry out checks in the respective Azure service back ends.
A second factor to take into account is that for the configuration and management of various Azure and Microsoft 365 resources, different APIs can be used. One great example is the case of the Microsoft 365 portal vs the Exchange Online portal for managing Azure AD users and Exchange Online mailboxes. Configuration changes are reflected almost immediately in the Exchange Online admin portal while they may take some time to be reflected in the Microsoft 365 portal.
Some of the admin interfaces utilize Microsoft Graph API in the back end while others utilize the Office365 REST API (to be deprecated). In the case of Azure, administrators can always use the Azure Resource Explorer tool to verify the Azure resource state after any configuration change.
A third factor why a configuration change in an Azure resource may take longer than expected to complete is because a third party application does not handle the Azure resource configuration change in such as a way so as to avoid restarting the application instances themselves. One typical scenario in which this can happen is if a .NET app hosted on Azure does not implement the RoleEnvironment.Changing Event. By using the Changing event, an application instance can respond to a configuration change in one of the following ways:
- Accept the configuration change while it is running, without going offline.
- Set the Cancel property of RoleEnvironmentChangingEventArgs to true to take the instance offline, apply the configuration change, and then bring the instance back online.
A fourth factor for Azure provisioning or resource migration delays is that the Azure Geomaster Databases which contain meta data information regarding the status of the Azure resources are not synced and the issue resolves itself when the syncing is complete. This is especially true when changing configuration which affects resources spanning multiple regions or when moving/migrating resources between different Azure regions.
On top of the above considerations, the end-users can carry out the following tasks to "reset" their client state on the client-side and be able to reflect the cloud-side configuration changes after waiting for about 1 hour, depending on the case/scenario:
- Restart Outlook client or other Microsoft 365 application client.
- Run the Microsoft 365 Support and Recovery Assistant tool.
- Perform graceful logoff in VDI/DaaS environment
- Hit Ctrl+F5 in a Web browser session
- Clear the Web browser cache. Or request that the Web server running on Azure has its CDN endpoints' cache cleared.
- Check on-premises logs and Azure AD Connect synchronization logs, if on-premises Active Directory users are being synced to Azure AD.
- Clear the client application local cache and retry.
