This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Welcome to Part 2 of our series! To sum up, in today’s article we’ll approach how to see, analyze & compare some of the label data we might find to troubleshoot sensitivity labels on the clients. Most of what will be described in the current article can be summarized into collecting a Problem Step Recorder (PSR), while running a fiddler trace, or using graph to check replication, performing a client reset whenever possible and compare the results to what we have configured on the server. So please never forget to check & use Get-Label and Get-LabelPolicy Cmd-lets to compare.
Now, why did we bore ourselves with knowing all these label actions and policy customizations in part 1? Because, even for the unknowing cause or issue, this is what we see in network traces & graph requests. It’s what the client (office desktop & web apps) receives after replication. As such, the easiest way to introduce ourselves to these topics is by quickly approaching Graph Explorer. Yes, that graph explorer! But for now, let’s approach policy distribution.
Settings, policy distribution & replication
Going back to labels, is worth mentioning that each of the action configurations from labels (as well as Label Policies and its customizations) can take time to replicate across all clients and respective workloads.
A label needs to be available for classification. One of the first steps upon label creation is to check the policy’s distribution status1. Once a policy is effectively distributed, then the replication towards the clients starts. As this process acts, both labels and policies and respective settings are received & updated from client side. While an administrator can see the labels and policies on the admin portal, it might not yet reach the user and therefore, its several clients & apps.
As such, labels can take some time to be available for classification, since settings propagate as the clients get the info from server source (once distributed) and replicate. First at the organization level, then at user level. As expected, the higher the seat count, the more it might take for a policy to properly replicate.
To exemplify label & policy replication, we’ve created a mail enabled security group2 containing 5 Users. Created 3 labels:
- one for “Assign permissions now” with a footer (LabelA),
- another for “Let users assign permissions” with a footer (LabelB)
- a 3rd one for removing encryption (LabelC).
All, applied to email and files only.
1.Do remember that a policy’s distribution status needs to be checked individually.
2.If you select a label to be applied to members of a group, make sure that group is mail enabled.
We then created a policy containing these 3 labels and scoped this policy to our mail enabled group and therefore its members (every other option left as default). We then waited for this policy to be correctly distributed via PowerShell:
Command: $LabelPolicy="LabelPolicyName";$a=0;DO {if ((Get-LabelPolicy -Identity $LabelPolicy).DistributionStatus -eq "Success") {write-host "$(get-date -Format g;'->';(Get-LabelPolicy -Identity $LabelPolicy).DistributionStatus)" -BackgroundColor Green} Else {write-host "$(get-date -Format g;'->';(Get-LabelPolicy -Identity $LabelPolicy).DistributionStatus)" -BackgroundColor Red} ;Start-Sleep -Seconds 3;$a++;} While ($a -le 540) # Allows to check for policy distribution status for aprox. 25 minutes with 3 second intervals
PowerShell Modules used: S&C
Do consider that some of the advanced settings configured can affect the Policy distribution (e.g. incompatible settings or actions). As such, we usually start with the base configurations, like in our example. Once the distribution status shows “success” we can then progress further.
Desktop Clients, Client Reset & Replication
Once the status is showing as distributed, we can check the local clients. For this example, we’ll be using Outlook, but most steps can be applied to other apps too. Let’s approach both desktop clients, the AIP UL client and the Office Built-In client. For a quick mention, the clients can be distinguished in 2 ways. First, their position:
Secondly, the AIP UL client is the only one having the “Help and Feedback” option, which allows for client reset & log export but, for our current example we’ll be using the UnifiedLabelingSupportTool to perform the reset as it works for both desktop clients.
First, let’s check the user’s Outlook using the AIP UL Client. After configuring the account on the machine, we open Outlook and click “New Email”, followed by clicking the sensitivity button:
Hum... it seems no labels are being displayed. Let’s try to access “File” > “Info” > “Encrypt”:
We only expanded encrypt and we quickly saw the “Loading protection templates, please wait…” changing to “Connect to Rights Management servers a…” but we didn’t click it. We then went back to the email and re-checked the “Sensitivity” button:
Good. We can now see all Labels within the AIP UL client. All are available and can be applied with no issues.
Let’s now test using the Built-In Client. For this, we closed Outlook, ran a reset using the UnifiedLabelingSupportTool via PowerShell and configured the DWORD “UseOfficeForLabelling” with value 1 on registry path HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Security\Labels.
After doing the above, we were met with a “grayed” sensitivity button:
Doing the same steps as for the AIP UL sometimes does help to replicate but it wasn’t the case here. Let’s try a client Reset. We first launch PowerShell as administrator and install the tool via Install-Module UnifiedLabelingSupportTool:
Command: Set-ExecutionPolicy Unrestricted; Install-Module UnifiedLabelingSupportTool
We then proceed to close all Office apps. We go back to PowerShell and run UnifiedLabelingSupportTool -Reset Default:
Command: UnifiedLabelingSupportTool -Reset Default
PowerShell Modules used: UnifiedLabelingSupportTool
We can see the outcome was successful (Reset on green) but might be times that, either because you have an office app open or it can be a lack of permissions, the reset doesn’t fully complete. If this is the case, the UnifiedLabelingSupportTool will let you know, like shown below:
If needed, you can also collect logs from both desktop clients using the UnifiedLabelingSupportTool:
Command: UnifiedLabelingSupportTool -RecordProblem -CompressLogs
PowerShell Modules used: UnifiedLabelingSupportTool
Open a PowerShell window as admin (if applicable) and:
- <# Run #> UnifiedLabelingSupportTool -RecordProblem -CompressLogs
- Close all office apps à Go back to PowerShell and press Enter à Replicate the issue and close all office apps again
- Then, go back to PowerShell and press Enter again to collect and compress logs (usually saved to the user’s desktop)
This will save a zip file with several logs from Office, information protection & a PSR among others. You can run it while also performing a fiddler trace for more data.
NOTE: AIP UL client does have an option of exporting logs, by clicking Help & Feedback > Export Logs but as its currently in maintenance mode, we’ve focused on the above method as it works for both.
If no labels are to be displayed, another check that can and should be made beside the above log collection and fiddler is to check for the user’s certificate on the machine and see if it is being downloaded as shown on the last line below:
Commands: $request = [System.Net.HttpWebRequest]::Create("https://admin.na.aadrm.com/admin/admin.svc"); $request.GetResponse(); $request.ServicePoint.Certificate.Issuer
Note: The endpoint can depend on you tenant’s region. The “na” after the admin stands for North America. If applicable, you can change it to “eu” or which region your AipService was provisioned. You can quickly confirm this by running Get-AipServiceConfiguration (connected to AipService Ps)
Continuing with our example, after performing a reset using the UnifiedLabelingSupportTool we re-opened Outlook and checked. Upon clicking “New Email”, we immediately saw “retrieving templates from server”, which seems a good start:
And, upon clicking the sensitivity button, we could see all intended Labels available:
Web Clients & Replication
As demonstrated above, we could see the intended labels being available for the intended users but what about web clients, like OWA or Office Apps? Upon checking one of our users in OWA not only we wouldn’t see our labels but we also didn’t see the “sensitivity” button itself. In its place we’d see “Encrypt” on OWA:
Signing out, closing the browser and Login again didn’t change our outcome, even with different browsers. And, in Office apps, no button was displayed at all:
(this usually means that no labels are assigned to that user, which isn’t our case)
Do consider that other clients (like Teams, AzureAD or SharePoint Online) weren’t checked as the created labels are only available for emails & files.
Taking into consideration replication time, this can be expected. Showing the option to “Encrypt” in OWA means that the user has no labels published for him but, we clearly saw this isn’t the case for the desktop clients. In OWA, users can still use the default “Encrypt-Only” and “Do Not Forward” in emails and this is why you see the “Encrypt button”. Can we somehow check / compare settings? Its now time to use Graph Explorer and see what we can find. But first, let’s do a quick pit stop for approaching graph.
Graph Explorer and Permissions
We won’t delve on it too much but essentially, graph explorer is a tool, which upon consent, can provide the same/similar information the clients themselves receive for each user/account. Upon login, you’ll be having access to your user labeling and policy information. Due to how graph explorer handles permissions, even if you’re an admin, you’ll not be able to see other user’s labels (only yours and organization labels), as for that it will require a custom app. For more searches and customizations as query other users, you might want to create & use your own app, although it won’t be needed for the current article. For more info on creating custom apps for graph, check here.
Access https://developer.microsoft.com/en-us/graph/graph-explorer. Click on the “Sign in to Graph Explorer” on the right. Upon connection you’ll be prompted for credentials (if not already logged in in M365), but you’ll also be prompted for permissions to read the logged user’s profile (if connecting for the first time). Click Accept and you’ll be logged in as that user:
It’s worth mentioning that some of the queries will require additional permissions for reading the user’s labels. If a query fails, you might have to go the “Modify Permissions” tab and click “Consent” for “InformationProtectionPolicy.Read” permission. Alternately, you can click the “…” > “Select Permissions” > search “informationprotection” & tick it> click “Consent”:
IMPORTANT: If you authorized graph explorer via browser and want to remove permissions, while connected to AzureAD Powershell just run (admin):
Remove-AzureADServicePrincipal -ObjectId (Get-AzureADServicePrincipal -All $true|?{$_.DisplayName -match "Graph Explorer"}).ObjectId
(This will remove all Graph Explorer permissions and if you try to access graph explorer afterwards, you’ll be prompted for permissions again)
As we seen on the previous part, another thing we might need to get used to is the .json format for label actions and policy properties, especially when playing with graph explorer (although xml format can also be used and found on some client logs among others). Having this said, let’s continue.
Querying Graph Endpoints for Sensitivity Labels & Policies
As we were mentioning, the web clients were still behaving as the user had no labels assigned to them. Let’s see what information graph explorer returns.
After logging on graph explorer, change the v1.0 to beta and use this endpoint https://graph.microsoft.com/beta/me/informationProtection/policy/labels?$orderby=sensitivity. For a clear perception of the endpoints within graph, let’s call it Label Endpoint 1. Check the response preview:
If wanting to query a specific label (if the user has access to it) by specifying its id as such https://graph.microsoft.com/beta/me/informationProtection/policy/labels?$orderby=sensitivity?$filter=id eq 'label id' (For root labels only)
So it seems graph does return some label information, like showing its active. You can click expand on the top right to see the full output. Let’s check the endpoint https://graph.microsoft.com/beta/me/security/informationProtection/sensitivityLabels?$orderby=sensitivity (Label Endpoint 2) :
With this endpoint, we can see the content formats (content type) the label is applicable to as well as a few additional settings but nothing towards policy information or settings. There is another endpoint we can check that should return label information as well as policy information. Let’s use https://graph.microsoft.com/beta/me/informationProtection/sensitivityLabels (Label Endpoint 3) :
Hum.. It seems that no value is being returned. Let’s compare it with an already existing label published to another user (different label, user and policy, previously distributed), while using the same endpoint (Label Endpoint 3). We’ve expanded the response to have a better view:
So, we can see some of the label general settings (blue), the label actions (red) and which label policy has the label published (green). We can also see that there is no default content label, which is a setting from the policy itself and not the label. In short, this would be the response we’d be expecting for our 3 labels if they were fully ready for classification by the web clients. Here we can see that, not all clients get the label information from the same endpoint, as the desktop clients already can use it. This is in agreeance with the 2 initial endpoints that were showing already some information but not all.
This last endpoint is actually similar to the ones used by the web clients. In fact, some of the clients, like Teams web client, do collect some of the label and policy information from this endpoint (once labels are available and published to that content type).
Now that we know what to expect, can we query the policy settings? We actually can but, it the information returned is only of the highest priority policy (in case a user has more than one policy applied) and its not that useful. Again, for simplicity purposes, lets call it Label Policy Endpoint 1. To check it we can use https://graph.microsoft.com/beta/me/informationProtection/sensitivityPolicySettings:
Or https://graph.microsoft.com/beta/Me/security/informationProtection/labelPolicySettings (Label Policy Endpoint 2):
Like explained above, unless the user has several policies assigned and you want to check which settings might being taken from the highest priority policy applied to that user, getting the label Policy information isn’t much useful in our case as our users only have one policy assigned and both endpoints return limited policy information.
Do consider that all endpoints we’ve queried were performed on the “user’s perspective”, i.e., we’ve been getting the label information that the user would but, we can also query which labels are available at organizational level. To do this, we’d need to be logged in in graph as an administrator, otherwise by querying the endpoint https://graph.microsoft.com/beta/dataClassification/sensitivityLabels (Organization Labels Endpoint) we’ll be greeted with the below error:
If instead we use an administrator, we should be able to see all labels, including the ones that were published for our target users. Let’s check LabelA, LabelB and Label C (with focus on LabelA as the others are similar):
Command: Get-LabelPolicy “Policy name”|FT name,Labels,GUID,Distributions*
PowerShell Modules used: S&C
We joined the above image with a Label Policy’s PowerShell output. At first glance, it seems labels are published to a policy but a few notes:
-The “assignedpolicies” id does not match our actual GUID of the policy containing these labels (blue) – This is usually a temporary value
-Not all Label actions are present as LabelA also has an action to add a footer, which is missing but we do see the encrypt action (green) only
But, what is most important on the image itself are 2 specific parameters on red. We can see that, although some of label information is present, we can see:
-“IsEnabled” is having a value “False”
-“AvailableForEncryption”, applicable only to “assign permissions now” labels is also set to false.
So, it seems that, although policy is properly distributed and even though a few hours have passed, the information returned is the same, i.e., still no label and still showing only the “Encrypt” option in OWA. This leads us to believe that not all information is properly synced, which will lead us to another question which is, could we perhaps do a server synchronization? Or, in other words, can we push the sync? Yes and No. In a client perspective, (as seen on some of the clients, like the desktop ones), can be reset and updated if the information is already correctly propagated/distributed from server side but what about to synchronize server side?
Server Sync via Label & Policy Management
Although there’s no actual method to send a sync request to the server side, it’s not often needed either. What can be done is label and policy management. Not only what you want to remove but sometimes also to publish or recrate an item. I.E., if a label action or policy setting hasn’t yet synced given proper replication time has passed, close & reset the client if applicable. Now create a new label, publish it on an existing or new Label Policy (I often use the latter to later delete it), & wait. Some changes can take more replication times than others, but the idea is this will cause new label, policy and rule creation, which will have to be updated on the server side, re-syncing the MIP service. It is essential that we allow this new policy to successfully be distributed.
Let’s try exactly that. We’ve created a new Label via PowerShell, with no action. Just Name, DisplayName and Tooltip (in our case, we called it EmptyLabel). We then proceed to publish this on a policy, scoped only to the admin (to avoid impact to any other users) and waited again for this new policy to be successfully distributed. Do note that, no actions were taken until this new policy is distributed and we logged out from any browser the user was connected to. After this new policy is distributed, let’s again take a look at graph (Label Endpoint 3):
Seems that now the labels are not only now showing, but we can see the label actions (in which we can see available for encryption) but more importantly, we can see the information regarding the assigned policies, which is now the correct policy GUID. Let’s check our user’s OWA:
Great, they now replicated and are available for the user. What about Office Online? Let’s take a look:
Only LabelA and LabelC are being displayed in Office Online, which is expected considering that we selected “Let users assign permissions”, which prompts for custom permissions, not yet supported by SharePoint Online and therefore Office Online apps as well. In regard to the new policy created to “force” the sync, it can now be safely deleted, as long its distributed, even if the “EmptyLabel” itself isn’t showing for the administrator yet, as our focus was just to use it to trigger a sync on the encryption store. Both end-user Label endpoints & Organizational endpoints can often give us a clue if an “update” to the MIP store might be needed, just by creating, deleting or publishing items and wait.
Important: Do note that other things, like incompatible/incorrect settings or even objects in pending deletion (labels, policies or rules) can affect the policy distribution. In some of these cases, upon searching on the logs you might find something similar to the below:
Desktop client log example
Although no specific reason or issue is specified, this can sometimes prevent the labels to be downloaded and applied. When this is the case, we advise on either removing the policy’s advanced settings and add it one by one, waiting for a proper distribution each time or a check in the Labels, Policies, Rules or template status/distribution using PowerShell.
As for our example, there might be situations in which the administrator can see the label enabled but the label isn’t present for a specific user or group. When this is the case, remember that browser cache can have an impact on the information returned and, besides analyzing possible issues with the settings chosen, try to remove & re-add the labels on a said policy, waiting for distribution to be completed in each step. Or alternatively, do the same for users / groups in the policy, removing and re-adding them, whilst always waiting for the distribution to complete.
You can also remove the policy and create a new one or even all of them (this shouldn’t have any impact as long as you don’t delete the labels themselves), as some settings can also affect other policies to correctly publish the labels for clients or even other users.
Other Graph queries:
There are other few endpoints that we can use to check and get label information from graph. For example, for showing groups with and without labels, we can use (admin) https://graph.microsoft.com/beta/groups?$select=DisplayName,Assignedlabels,mail,Id&?$orderby=displayName&?$top=100:
Note: If displayed, you might have to expand by selecting the option “This response contains an @odata property.: @odata.nextLink Click here to follow the link.” on the request top.
Do note that above it might not show all groups (depending on how many you have) and you might need additional permissions. Either way, you can see a specific group as well if needed by using https://graph.microsoft.com/beta/groups/{group id}?$select=DisplayName,Assignedlabels,mail,Id
As administrators, we can also view which labels that are applicable to a specific type of content (e.g. Sites & Groups on organization’s labels) via: https://graph.microsoft.com/beta/dataClassification/sensitivityLabels?$filter=applicableTo has 'site,unifiedGroup'
Do note that, if a label is set to email, site & unified group it will be included in the above filter
Other queries that might also be relevant can include AzureAD settings (for example, to check if “EnableMIPLabels” is set & enabled)* can also be queried. For this use (admin): https://graph.microsoft.com/beta/settings
Additionally, and as shown in part 1, the Conditional Access policies can have an impact on the user getting the labels/opening content. As such you can also query the organization’s CA policies (admin) via graph using: https://graph.microsoft.com/beta/identity/conditionalAccess/policies
*Note: Needed for having the sensitivity label features for AzureAD groups
Do consider that some of the query parameters are not available for all endpoints, as it can be seen on Graph query documentation here. Also, some of the queries, especially the ones concerning to the whole organization are only accessible to an administrator. Depending on your organization’s configuration and environment, some of the queries can require additional permissions, so always remember to check “Modify Permissions” tab. Also remember that you can always remove permissions by using the command mentioned at the topic “Graph Explorer and Permissions”.
DISCLAIMER: All the above-mentioned graph endpoints are currently in the beta version of the API and can be removed/changed without prior notice. As per graph beta documentation:
“(…) The beta endpoint includes APIs that are currently in preview and aren't yet generally available. (…) The APIs in the beta endpoint are subject to change. We don't recommend that you use them in your production apps.”
As such, we’re only using them here as a current way to demonstrate how we can troubleshoot labels by distinguishing what we see on the several client(s) and, which graph settings are being replicating at a given instance. Even when you perform a network / fiddler trace when running the apps/clients, although not all apps use graph, this will often be the label information the client receives, being in .json format or others (like .xml for example).
Compare Graph and Clients:
As you can promptly see, comparing the output on the several clients, as well as using graph can allow us to see and analyze the actions & settings that some clients might be receiving from the server & compare. This can be particularly useful when client & graph info are not matching:
We’ve omitted the label actions but graph only shows us a Root Label (USERS-Labels) and a sublabel (“WhiteLabel”). It seems the Outlook desktop is receiving 4 additional sublabels which aren’t present in graph. When troubleshooting it’s always good to compare our clients with graph, as it can give us an idea of what is being replicated at a given time.
Or even comparing the several clients, like OWA and Outlook below:
What’s the issue here? We’ve just removed 4 sublabels some time ago from the root label & policy. Although it will eventually sync, the client hasn’t yet replicated the changes, but you can force the reset if the info on graph is already up to date. It’s a bit similar to our previous issue but, in this case, its the desktop client that didn’t update.
In other words, by comparing the values received from graph or other clients, and as a troubleshooting step, it can happen that that client hasn’t synced, and the info you’re seeing on the it, simply isn’t up to date yet, but we can reset it. As explained previously, to quickly reset a desktop client you can use the UnifiedLabelingSupportTool. Install it as a PowerShell module and upon installed, close all Office Apps and on PowerShell run: UnifiedLabelingSupportTool -Reset Default
After the Reset, our Desktop Outlook started to show only the expected root label (USERS-Labels) and Sublabel “WhiteLabel”, in either client:
Do remember that desktop clients are the only ones currently supporting client reset. Although web clients are handled differently and it’s not the same thing as a reset, you can always try a web client to be run in incognito session, or different machine as browser cache does have its impact.
On the other hand, as this might not always address all issues, but as explained before, do consider that if only a label or user/group are affected, it can be related with the label or policy itself (Or even rules as shown here), which if possible, should be checked permission wise and setting wise (there might be some conflicting settings).
Even sometimes tools like fiddler, if incorrectly configured (like checking for certificate revocation enabled), can lead to network and client issues:
For permission check’s, remove/re-add a user or even create a group and re-add it to the policy, instead of the user or vice-versa.
Also, for permissions and specifically when using Encryption Templates (“assign permissions now” only), do remember that they are published also when added to a policy.
Although the above might lead to some misperception, and since in part 1 we spoke about how templates should be enabled when a label with “assign permissions now” is published to a policy and the template keeps showing as disabled, I wanted to address a particular common issue that can give the same error of “template can be found” and its not related with a disabled template. You’ll often see this manifested in different ways:
Image to the left error: Azure Information Protection cannot apply this label because its configured for a protection template that can’t be found. (…)
Image at the middle error: Your machine isn’t set up for Information Rights Management (IRM). (…)
Image to the right: Sensitivity button greyed out.
Now, we’re not saying this is the only cause for the prompts above but its very often a common issue and its not directly related to S&C, the policies, or labels themselves. For example, for the first error, labels are displayed but upon selection of one with encryption (assign permissions now), the error would show. For the second error, we do know that most of the times, Outlook rarely makes use of IRM to collect label information. Lastly, for the 3rd error, generally seen more on the Office Built-in, is due to the same issue. The client cannot get all the label information and as such, cannot provide the user the MIP features. Everything seems to be pointing to the RMS side of the service.
Another form of the above error can come in different ways. For example, if you are trying to select a label with user defined permissions, the error might be a bit different in some cases:
In the previous image, the client couldn’t make the connection and therefore, no labels with encryption could be retrieved. The difference between the above “template cannot be found” and this latter one is that, since you’re trying to use a user defined permissions label, this requires either Do Not Forward or Encrypt-Only from EXO, which need to be accessed via IRM and therefore the above error.
The above can happen if an administrator has restricted the AIP features to a subset of users. This can be checked via the cmd-let mentioned below:
Command: Get-AipServiceOnboardingControlPolicy
PowerShell Modules used: AipService
In regards to the command, documentation states that the “(…) Get-AipServiceOnboardingControlPolicy cmdlet obtains your Azure Information Protection user on-boarding control policy to support a gradual deployment by controlling which users in your organization can protect content (…)”. This can be based on “(…) assigned user licenses for the service or membership in a designated security group. (…)”.
In our case, the onboarding policy was scoped to a security group including only the administrators and as such, the users wouldn’t get the labels. Upon running the below:
Command: Set-AipServiceOnboardingControlPolicy -SecurityGroupObjectId $null -UseRmsUserLicense $true -Confirm:$false
PowerShell Modules used: AipService
Which removed the group, (and an eventual client reset if needed) users were now able to see and apply the labels correctly:
We should also mention that, even upon troubleshooting an issue with sensitivity labels, documentation is often key to understand supportability as well as limitations. Although its far from being complete, we can say that the following articles can clear some of the general limitations and they should be consulted when addressing an issue:
Known issues with sensitivity labels in Office (microsoft.com)
Message encryption FAQ | Microsoft Docs
Known issues - Azure Information Protection | Microsoft Docs
Sensitivity labels in the Microsoft Purview Data Map FAQ
FAQs – General
FAQs – Classification & Labeling
FAQs and known issues - Microsoft Information Projection SDK. | Microsoft Docs
Another common misperception that should often be verified for troubleshooting a specific feature is the office version, where more information can be found by checking the link for Support for sensitivity label capabilities in apps
For a clearer view, we created a table below with all graph endpoints used on the current article, by order of mention, reinforcing that these can be subjective to change without prior notice:
*It can depend on if a user is part of that group or, it can depend on if the group is hidden for that user.
Note: The names used were just for reference and to simplify each of the endpoints and information returned in the examples.
So, what can we conclude from using graph or analyzing endpoints? Besides comparing graph data with clients?
We seek to troubleshoot label or encryption data, we will often need to not only proceed with a Client reset, but we also need to consider what a client is receiving after a given change. This is why a new reset might be needed if changes were done.
The Distribution status of the policy is also important as its what tells us that latest changes were successfully synced and updated server side. Its not relevant to troubleshoot a client if the policy is still pending but do remember that policies need to be queried individually for a correct status.
We’ve also concluded that an admin can also trigger a sync by creating a new label & policy scoped to the admins, wait for that policy to successfully distribute so that it doesn’t impact the end users. When this is done, please do ensure that user is logged out and logged in and preferably use an incognito/in private mode if on a web client.
Also, although the above endpoints & data can change its form, its the data collected by the client that often needs to be checked if suspecting of label replication (server side) issues. In other words, different clients might download data from different endpoints and in different formats (like json or xml). This can often be seen and compared using a network trace.
And once again, we reach the end of the 2nd part of our series. But, as stated before there’s still quite a few things to cover. Join us next time in which we’ll be approaching Auto Labeling as well as Label & template Backup. Stay tuned!