Fix Microsoft Purview Compliance Issues: Australian Gov Guide

Why This Is Happening

I've helped dozens of Australian Government agencies get their Microsoft Purview compliance for Australian Government configurations off the ground , and I can tell you honestly, the setup is more involved than Microsoft's getting-started pages suggest. If your sensitivity labels aren't appearing for staff, your DLP policies are blocking legitimate workflows, or your auto-labeling simulation has been spinning for three days without finishing, you're not doing anything wrong. You've just hit the walls that almost everyone hits.

Here's the core issue: the Protected Security Policy Framework (PSPF) and Information Security Manual (ISM) lay out clear classification requirements , UNOFFICIAL, OFFICIAL, OFFICIAL: Sensitive, PROTECTED, but Microsoft Purview doesn't come pre-configured for Australian government classification schemes. You have to map your agency's information classification tiers to sensitivity labels manually, then layer data loss prevention policies on top, then add auto-labeling to catch the items that fall through. Each of those three systems needs to be working independently before the combined effect actually meets your PSPF obligations.

The Microsoft Purview maturity model for Australian Government exists precisely because most agencies can't implement everything at once. Trying to go from zero to full auto-labeling enforcement in a single weekend is a reliable way to end up with broken workflows, furious staff, and a support queue full of "I can't send my email" tickets. I've seen it happen. The maturity model gives you a staged path, but the documentation doesn't warn you loudly enough about all the places where the configuration can silently fail without any useful error message.

Common scenarios that bring people to this guide:

• Sensitivity labels not visible in Word or Outlook, the label policy hasn't been published to the right users or groups, or the policy hasn't synced yet
• DLP rules blocking internal SharePoint access, overly broad conditions that catch internal-to-internal sharing when they were only meant to block external recipients
• Auto-labeling simulation stuck at 0%, the scanning service doesn't have read access to the targeted SharePoint sites, so it never starts
• Copilot-generated documents coming out unlabeled, label inheritance with Microsoft 365 Copilot requires specific label scope settings that aren't enabled by default
• "You don't have permission to apply this label" error, the user's account isn't in the label policy's scope, even though they can see other labels
• PROTECTED label applying but encryption not working, the label's protection settings weren't configured before it was published, and a republish is needed

I know this is genuinely frustrating, especially when it blocks real work and you're under pressure to demonstrate PSPF compliance to your agency's security team. The good news is that every single one of these problems has a concrete fix. Let's go through them. Browse all Microsoft fix guides →

The Quick Fix, Try This First

If your staff can't see any sensitivity labels at all, start here before you do anything else. Ninety percent of the time, the problem is that the label policy hasn't been published to the affected users' accounts or security groups, not a licensing issue, not a service outage, not a client problem. Just a scope setting that got missed.

Here's what you do:

1. Sign into the Microsoft Purview compliance portal at compliance.microsoft.com using a Compliance Administrator account.
2. In the left navigation, go to Information Protection > Label policies.
3. Click on your existing policy name (if you don't see one, the labels have never been published, jump to Step 2 in the step-by-step section).
4. Under Assign policy to users and groups, click the edit link and verify the affected user or their AAD security group is listed. If they're not there, add them and save.
5. Wait, labels can take up to 24 hours to propagate, but in most cases, having the user close Office completely and re-open it brings the labels through within 1–2 hours.

If you need to confirm what's actually published without relying on the UI, run this PowerShell from a machine with the Exchange Online Management and Security & Compliance PowerShell modules installed:

Connect-IPPSSession
Get-LabelPolicy | Select-Object Name, ExchangeLocation, ModernGroupLocation, SharePointLocation

The output shows exactly which users, groups, and sites each policy is scoped to. If the column shows "All" but the user still can't see labels, the next thing to check is their Microsoft 365 license, basic sensitivity labeling for documents and email requires at minimum a Microsoft 365 E3 or equivalent license. Features like automatic sensitivity labeling and advanced DLP require E5 Compliance.

If labels are visible but the wrong ones are appearing, for example, a user sees generic labels instead of PSPF classifications, you likely have multiple policies published and one is taking priority over the other. The policy with the lowest number in the "Order" column wins. Reorder them in the Label policies view so your PSPF policy is first.

Advanced Troubleshooting

If you've worked through all five steps and still have issues, you're most likely hitting one of three scenarios: a Group Policy or registry conflict on domain-joined machines, a federated identity mismatch causing silent policy failures, or a service-side issue that needs Microsoft's involvement. Here's how to diagnose each one.

Group Policy and Registry Conflicts on Domain-Joined Agency Machines

Domain-joined machines managed via Group Policy can have Office sensitivity labeling client behavior overridden by local policy settings. The key registry location to check is:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Common\Security\Labels

If this key exists and has values set, those values override your cloud-delivered label policy. Open Registry Editor on an affected machine (Win+R, type regedit) and navigate to this path. If you see label-related DWORD values here that don't match your intended configuration, work with your GPO team to remove or correct the conflicting Group Policy Object. The name of the GPO responsible will be in the gpresult /h C:\gpresult.html output, look for Office/security-related policies.

Reading the Event Log for Labeling Client Errors

When the labeling client fails silently, the user sees labels, clicks one, and nothing happens, or a label recommendation appears and disappears without applying, the errors go to the Office Alerts log in Event Viewer. On the affected machine, open Event Viewer and navigate to:

Applications and Services Logs > Microsoft Office Alerts

Filter for events in the past hour. Look for event IDs in the 40000–50000 range from the "Microsoft Office" source. Common messages that indicate labeling client failures include policy download errors (check proxy/firewall access to *.protection.outlook.com port 443) and encryption service errors (check RMS service endpoint access to *.aadrm.com).

Local Label Cache Check

The labeling client caches downloaded policies locally. If the cache is corrupt or empty, labels won't appear even if the policy is correctly published:

dir "$env:LOCALAPPDATA\Microsoft\Office\CLP"

If this folder is empty or absent, the policy hasn't downloaded to the machine. The most common cause for this on agency networks is a web proxy blocking the label policy endpoint. Have your network team confirm that *.protection.outlook.com is on the proxy allowlist for all agency endpoints.

Federated Identity UPN Mismatches

In whole-of-government identity federation scenarios, users' UPNs in the identity provider sometimes don't match their Microsoft 365 UPN. When this happens, the label policy check at sign-in fails silently and users don't get their assigned labels. Verify with:

Connect-MsolService
Get-MsolUser -UserPrincipalName user@agency.gov.au |
  Select-Object UserPrincipalName, ProxyAddresses, Licenses

Check that the UPN returned matches what the user uses to sign into Windows and Office. A mismatch here, even a subtle domain suffix difference, causes policy assignment failures that don't produce visible errors to the user.

Checking DLP Match Audit Logs

When users report unexpected DLP blocks, the fastest way to diagnose what rule triggered is the audit log in the compliance portal. Go to Audit in the left navigation, click Search, and filter on:

• Activities: DLP rule matched, DLP policy matched
• Date range: time window of the reported block
• User: the affected user's email address

The results show you the exact policy name, the specific rule that fired, and what condition was matched. This is infinitely more useful than asking the user to describe what happened. Screenshot this and use it to tune your DLP exception conditions.

Prevention & Best Practices

The agencies that have the fewest Purview compliance headaches aren't the ones who configured it perfectly the first time. They're the ones who built a repeatable process around it. Here's what actually works in practice for keeping your Microsoft Purview PSPF compliance configuration stable and your users out of the support queue.

Use the Microsoft Purview Maturity Model as your roadmap, not a suggestion. The maturity model for Australian Government starts with sensitivity labeling, then adds DLP enforcement, then adds auto-labeling. Skipping straight to auto-labeling enforcement before your label policy is stable across all your endpoints is how you get mass false-positive DLP blocks. Each layer needs at least two weeks of pilot testing before you expand to all staff.

Run DLP policies in test mode for a minimum of two weeks. Review the matched items daily during that window. Every "false positive" you catch in test mode is one less helpdesk ticket after you switch to enforcement. Pay particular attention to shared drives with legacy content, auto-labeled or manually labeled items from before your PSPF alignment will often match DLP rules in unexpected ways.

Maintain a label schema register. Document in a spreadsheet: each label's name, its PSPF equivalent classification tier, its encryption settings, its visual marking settings (header, footer, watermark text), and which label policy publishes it. When Microsoft Purview releases an update that affects label behavior, and they do, regularly, you need a baseline to compare against. Check the Microsoft 365 Message Center at admin.microsoft.com > Health > Message Center weekly and filter for Purview-related messages.

Test label inheritance with Copilot before your agency-wide Copilot rollout. Run the five-step validation from Step 5 above against every classification tier in a non-production tenant or pilot group. Document the results. If inheritance isn't working for a specific label, you want to know before 5,000 staff start generating AI content from classified documents.

Set up a "sensitivity label support" page on your agency intranet. Link to it from the label policy's "Help link for user" field in the portal. When users click the info icon next to a label they don't understand, they'll see a link to your internal guidance page. This reduces helpdesk contact volume significantly and keeps staff informed of what each PSPF classification means in practice.

Frequently Asked Questions