Troubleshooting Cloud Policy Service (CPS) - part 1
Published Dec 17 2019 08:05 AM 48.2K Views

Note: if you are experiencing issues with the Cloud Policy service, please contact Microsoft Support.


The Office cloud policy service (OCPS) is a cloud-based service that enables you to apply policy settings for Office 365 ProPlus on a user’s device.  The policy settings roam to whichever device the user signs into and uses Office 365 ProPlus.  As end users become increasingly mobile, IT Pros need a single approach to secure Office 365 ProPlus for traditional on-premises domain devices, Azure AD registered devices, Azure AD Joined, and Hybrid Azure AD joined devices.  OCPS applies to all scenarios above without the need to download and replicate any content such as Administrative Template files (ADMX/ADML) on-premises.  The goal of this blog is to provide some transparency of how the service works to help IT Pros during their validation phase and to encourage transition from classic domain-based policy to OCPS service for Office 365 ProPlus.


Requirements of OCPS

1. At least Version 1808 (August 2018) of Office 365 ProPlus
2. User accounts created in or synchronized to Azure Active Directory (AAD). The user must be signed into Office 365 ProPlus with an AAD based account.
3. Security groups created in or synchronized to Azure Active Directory (AAD), with the appropriate users added to those groups.
4. To create a policy configuration, you must be assigned one of the following roles in Azure Active Directory (AAD): Global Administrator, Security Administrator, or Office Apps Admin.
5. Connectivity to addresses below. Microsoft recommends proxy bypass\whitelist for these URLs and not make modifications to the headers that are sent with the requests:
*, *, *, * over 443


Steps to perform proof of concept and validation
1. Create a test user, ours will be “Kasper Graf”,
2. Create security group “OCPS Service Validation” and add user to group within Active Directory Users and Computers.
3. Allow AAD Connect to synchronize user and group to Azure AD. (lunch break :) or force synchronization via commands below)

(optional) From AAD Connect Server and elevated PowerShell, run the following commands:
PS C:\WINDOWS\system32>import-module adsync
PS C:\WINDOWS\system32>Set-ADSyncScheduler -NextSyncCyclePolicyType Delta
PS C:\WINDOWS\system32>Start-ADSyncSyncCycle

Browse Azure AD portal and explore Users – All Users, select Kasper Graf and then Groups. Verify that group “OCPS Service Validation” has been assigned and source says, “Windows Server AD”. This confirms user and group were synced into Azure AD successfully and we can proceed to next steps.
4.  Create your first OCPS policy and select “Create” button:


5. Complete input fields, when selecting assigned security group input “OCPS” and service should filter results to “OCPS Service Validation” group.  Next, define a policy.  For the demo, I chose policy "VBA Macro Notification Settings", "Enabled" where VBA Macro Notification Settings are set to "Disable all with notification".   Once selections have been made “Create” or “Save”.



6. From Policy Management, we can now see our policy exists.


So, we’ve got a policy, we’ve assigned it to a security group containing our test user, our next step is to validate. My test machine happens to be classic on-premises domain joined machine. My user, Kasper Graf, is signed in with his normal Active Directory credentials which is displayed in upper right hand corner of Word.


Traditional Group Policy uses Client-Side Extensions in Windows to apply policy every 90 minutes.  IT Pros can force policy by using command line “gpupdate /force” and inspect\verify registry as well as application behavior prior to broad deployment.  OCPS checks for policy upon initial Office application launch, calls into cloud service endpoints listed above, determines policy applicability based on group membership and priority assignment and registry keys are populated. 


Specifically, there are two locations of interest in registry.

1. HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy\
This will contain information about FetchInterval, 90 minutes is default, as well as record of Last Fetch Time and Last Payload Hash.

2. HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud. This key will contain path to registry keys representing the policy assignment. For example, ours will be HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud\Office\16.0\word\security
Vbawarnings = 2 (DWORD)


IT Pros can achieve the same behavior of gpupdate by simply deleting the key HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy, close Office application and relaunch to fetch policy.  I typically use tools like Process Monitor to help trust\verify operations of this type with filters such as “Path” contains “CloudPolicy” or where Operation is “RegSetValue” etc.  Opening a Word document containing a Macro displaying warning with notification as expected.



Advanced troublshooting

The OCPS client on Win32 is built into the C2R service. The C2R service runs as SYSTEM on the device and is not aware of the active user(s). When you launch one of the Win32 Office apps (like Word) the user token is passed to C2R by the app and then C2R is able to call the OCPS service with the user token and request the policies. This makes it difficult to troubleshoot as the traffic to the service is managed via this SYSTEM process.
Below is the set of steps needed to monitor the HTTPS traffic running under the SYSTEM account on the Win32 device.


Tools you need
- Fiddler (or some tool to monitor the HTTPS traffic and decrypt the HTTPS traffic)
By monitoring and decrypting the HTTPS traffic you will be able to see the content that is sent and received via the OCPS check in service.
In Fiddler there is a configuration option that allows Fiddler to decrypt HTTPS traffic by installing a trusted certificate on the target machine. Without this you cannot decrypt the content.

- The ability to run Fiddler as SYSTEM on the Win32 device
runassystem.exe is a small tool available from a third party,
This tool allows you to specify an EXE to launch in a new process that is run under SYSTEM.
There are other tools and methods available to accomplish this. 


Steps to troubleshoot
1. Shut down all Office apps
2. Delete the OCPS registry hives
3. Launch runassystem.exe and accept the elevation prompt.
4. Provide runassystem.exe the path and EXE of Fiddler
5. Launch Word and monitor the traffic


What you should see
You should see a call to to retrieve the policies for the user and a call to to send the acknowledgement that the policies were received and the health status.


Call to retrieve
The retrieval of policies includes a JSON payload that contains the policies and their values. Select the item in Fiddler and review the payload using the JSON tab.


Each configured policy is detailed in the JSON response showing the policy ID (ParentSettingId), the data type (Type) and the value name and value.


If the policy is an ADMX based policy you will see this as [admxfile][admx id]. Ex. office16;L_UseOfficeForLabeling. You can look up L_UseOfficeForLabeling in the office16.admx file.
If the policy is not an ADMX based policy you will see this as [app][policy id] as defined by the app team. Ex. cortana;C_AllowBingAnswersInCortana. There is no reference for these policies as they are only defined in the OCPS policy library.


Call to acknowledge

The call to the /ack API is passed details on the payload that was received by the client and the success status for writing to the client.

The JSON data will contain the device name, platform and Office version as well as Success or Failure and additional failure information if needed.




How does conflict resolution work if the same policy is set via traditional domain-based policy as well as OCPS?
OCPS takes priority if there are any conflicts with traditional domain-based policies.


Computer accounts within my organization don't have direct internet access and sit behind a proxy.  With this configuration I've noticed OCPS doesn't work even though the User does have access to all required Office 365 URLs?

We have added proxy and User Impersonation support to address this issue.  The tentative release date is 2020 September SAC-T and 2021 January SAC.


Currently policies are limited to user settings. Are there plans on adding machine settings?
Yes. This has been accepted and currently is in our backlog. We hope to have this available next year.


Group Policy provides a view of all policies on the device or for the specified user. Does OCPS support this?
Currently OCPS does not provide a list of all Office policies applied to a specific user or device. This is on our backlog and we hope to have this available next year.


Will OCPS support other platforms such as MacOS, Android and iOS?
Yes, OCPS in the future will also support additional platforms such as MacOS, Android and iOS. We will create additional blog postings per platform once features are generally available.


Are there any environments where OCPS is not available?

The Office cloud policy service isn't available to customers who have the following plans: Office 365 operated by 21Vianet, Office 365 Germany, Office 365 GCC, or Office 365 GCC High and DoD.


Change log

8/19/2020 Updated to include more prescriptive guidance for troubleshooting


The Author

This blog post is brought to you by Dave Guenthner, a Senior Premier Field Engineer and “ProPlus Ranger” at Microsoft. Feel free to share your questions and feedback in the comments below.

Copper Contributor

Is it really the case that OCPS-Policies are only applied during the 2nd start of the application?

If that is the case is there any way to speed this up, so the policies are applied right away from the very first start of the application?


@julkarl Yes. For example, if Word were launched, OCPS would fetch policy for all Office applications.  Therefore, launching Excel a minute later would see all policies applied on first start.  However, Word would need to be launched a second time to ensure all policies are picked up on initialization. This is something actively being worked on our side, perhaps an "Out of process heartbeat".  Specific implementation details are still being discussed but you are correct.  Thank you for commenting.

Iron Contributor



@Mike Crowley You were looking for integration with Intune?  You got it, please see announcement below.

Office Cloud Policy Service integrated with the Microsoft Endpoint Manager portal

Brass Contributor

Is there a 'report' capability for these policies?  Or do we need to dive into the registry each time?  Kind of difficult for remote PCs or cases when an end user might have logged into the office client on a 'BYOD' type device.


@Ivan Webb At this time, there is no reporting feature.  Can you provide an specific example of what you're looking for? (I'd like to record request formally so need more detail)  For BYOD, this will work fine because whether you're on-premises or in the cloud, authorization still takes place against Azure AD so as long as they sign in with their account into Office it should work. 

Iron Contributor

How does this handle different languages installation of M365 Enterprise Apps? For instance, if I wanted to use the Enterprise Templates Path setting in my policy, would I have to create a separate policy for each country where a different language is being used to apply the word, excel, powerpoint templates?

Brass Contributor

@Dave Guenthner , An example that I'm looking for here would be to view a users sign-in to Office (via the Azure portal in 'sign-ins' or something similar) and then bring up the config of the office app that they are using against that session.  As the use of the web version of Office apps (especially with Teams being rolled out now) have grown dramatically. 
Also making it easier for 1st and 2nd level support to be able to determine where the office config is coming from.  E.g. is the end-user picking up config from AD GPOs?, SCCM Config Items? Intune Policies?  Or these new Office Cloud policies.  Being able to determine what is in the environment would clue them in earlier on where to look.
Happy to discuss offline if you would like to.


@Ivan Webb I've shared your feedback directly with PM who owns OCPS and have been assured request for reporting in terms of where config is coming from is a feature which has been recorded and is presently in backlog.  No ETA on availability but when released I certainly will update this blog as the capability will be important for troubleshooting.  Thank you for the feedback.

Copper Contributor

Looking to create a base policy to contain the MS Security Baseline settings.  When filtering on 'Security Baseline' settings, there are (at the time of writing) 87 policies that need to be 'configured' as part of the baseline.  I can't find a way of doing this en-mass and am not going to click through each one.  Is there a better way of applying the MS Sec baseline settings such as a graph/PS interface we can script through, or something nice and obvious i am missing?


@thecockneymanc Thank you for the feedback. This functionality isn't available today.  I have confirmed with Program Manager who owns OCPS we do indeed have a backlog item for this recorded, no ETA to share at this time.  Thank you.

Brass Contributor

@Dave Guenthner - Sorry for the late reply, have been madly deploying Teams to several customers.  Thanks for the update and I'll be keeping an eye out for that feature.

Copper Contributor

Is there a feature request site for updates on this?  I'd like to add a few things not the least of which is a reporting capability.  I would also like to find out how we can be notified when new settings are added.  Currently we have to review this all manually on a regular basis and since there is not an easy way to export and compare it is hard to see if something is new or just modified a little.  Last some PowerShell or other programmatic capability on both the Admin side and the client side would make this a very capable solution. 


As it sits today I see promise, but this does not appear to yet have the Enterprise Level of maturity needed for a larger organization to make it useful. 


@CDQuinn thank you for posting.  There is a Feedback button on the site.  You can use that to post additional information about features you would like to see or things that are not working as you would expect.  We have a bunch of feature ideas to improve the experience as well as the capabilities, some of which are:

- notifying admin's of new policies or changed policies

- enhanced reporting to show admins health of configured policies

- resultant policy set 

- bulk configuration for recommended policies

- migration from existing Group Policy configuration


Chris Hopkins

PM - Office

Copper Contributor

Has Proxy and user impersonation support been added yet?  I don't see it on the fixlist.  Does it require additional steps on customer side?


@Randyi803 the updates to support WinINET were released for SAEC Version 2008 (Build 13127.21064) released on Jan 12.  This functionality is available to clients in all update channels if their version is > 13127.21064.


Are there log files or Event Viewer entries that log what's happening?


@Fred Duarte To my recollection, No.  

Copper Contributor

I've been trying to make OCPS work, but the registry keys don't ever get created when launching the app.   No keys exist in either of those two main locations ('Cloud' or 'CloudPolicy'), so I can't just 'delete' them to retry, because they never exist in the first place.   Running 2008 (Build 13127.21668).


One possible issue, we are running GCC, however, I *can* go and create the policy at, so I'm getting conflicting info on whether GCC is supported.


If GCC isn't supported, how am I supposed to apply the setting to disable the upcoming 'Microsoft Outlook Extension' Notification (MC264090)?   They are apparently rolling it out to GCC, but yet only provide OCPS as a means to turn it off. 


Any suggestions are appreciated!


@jdobiash I can confirm per Overview of the Office cloud policy service for Microsoft 365 Apps for enterprise - Deploy Office | ... "The Office cloud policy service isn't available to customers who have the following plans: Office 365 GCC, or Office 365 GCC High and DoD."  For this specific feature\message center post, I recommend reaching out to MS Support to ensure you're receiving best guidance from the right folks.

Copper Contributor

Sorry to bring this up again, but I'm still having issues even getting support to recognize the issue.    I'm trying to get it escalated, but I may have to actually talk to my federal account rep here shortly.


Regarding the OCPS, one thing I *did* notice - Its lets me configure the policy on '', but the "Health Status' never loads.  It just says 'Loading...' and stays that way forever.   (screencap below)    Any thoughts?    Maybe it's related to my issues.  I'd bring it up with Support, but they'd probably just refer me back to this page, which was literally the first thing they told me to do, followed by 'look at the message center'.





@jdobiash If your tenant is GCC and currently OCPS is not supported for that scenario, this could explain unexpected results you're seeing.  Seeking an alternative, not using OCPS, would be the way to go as there is no ETA when GCC will be supported.

Copper Contributor

@Dave Guenthner, thanks for the quick response.   Unfortunately the only option that was given to 'opt-out' of this upcoming change is to use OCPS.     The change apparently is set to affect all tenants, including GCC.   


Question - At what point in the process does the Office Client put the registry keys in so it can keep track of settings?  Does it first have to reach out and verify eligibility of OCPS first?   If so, that would explain why the keys never get created.


@jdobiash That is correct.  The client creates the registry keys when it receives the policy set from the service.  As GCC is not currently eligible there are no settings to return thus no registry entries are created.

Copper Contributor

Thanks @Chris Hopkins for the update.  I sent you our Tenant ID via PM and Email as well - I wasn't sure which method you were wanting me to use.   

Copper Contributor

after facing issues to get the cloud policies applied.
I tried deleting the cloudpolicy key and restarting the whole office 365 suite, after running word for example again, the registry key gets created but the policies aren't being applied, however, I have noticed something weird which is that the policyHash key value is empty and the fetch interval is set to zero instead of 90 which makes me believe that the cloud policies aren't being retrieved in the first place since there is no policyhash registered! Do you have any idea on what could be causing this issue!


Hi @SimoMoti.  If you could private message me I would like to get more information about this issue so we can troubleshoot and determine why the client is not receiving policies.  Your tenant ID and some information about your network and client configuration (proxy) would be helpful.

Copper Contributor

@Chris Hopkins thank you for your reply, I will have to check with my manager before I can send you that information.

Copper Contributor

Hello Again,
@Dave Guenthner @Chris Hopkins We managed to fix the issue above, however now the policies are being retrieved, registry keys get populated but not taking effect! I tried logging in with M365 account on a standalone machine (not part of a domain) and always same issue keys are being retrieved as expected but the settings are not being applied! any hint on what's preventing the cloud settings from taking effect, Thank you 

Copper Contributor

@Chris Hopkins Is there a way to increase the fetch interval times ?


@Tate2021 the fetch times are calculated by the service and provided to the client.  There is no setting that allows you to adjust this.  What sort of interval are you looking for?

Copper Contributor

"How does conflict resolution work if the same policy is set via traditional domain-based policy as well as OCPS?
OCPS takes priority if there are any conflicts with traditional domain-based policies."

@Dave Guenthner @Chris Hopkins 

We have a GPO that activates the cache mode for the users (can not be changed by user)

We wanted to disable the cache mode for a group of users with the OCPS. The registry is correctly created. But the cache mode remains activated by the GPO.

Name: Use Cached Exchange Mode for new and existing Outlook profiles.

Is it still correct that OCPS > GPO ?

We also tried to create a new profile, but the cache mode remains enabled.



@Aris212 I was recently informed some fixes for cached/online mode have arrived in Version 2108. Checking the version page, version is in Current Channel.  Can you move Office client to Current Channel and delete the key HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy, close Office application and relaunch to fetch policy.  Let us know if its resolved.  If not please provide specific GPO name.  Thanks.

Copper Contributor

@SimoMoti we too are finding that the fetch interval is set to 0. Did you ever figure out this issue, and if so what was the solution?

Copper Contributor

I've noticed that cloud policy has stopped working last week. I've raised Microsoft case, unfortunately support is terrible so maybe you will be able to help me. In short: Last week I've noticed that new Office 365 users miss our configuration (cloud policy), then I've tested on my own computer. I've deleted this registry key: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\CloudPolicy , and nothing happens if I run office software, this key is still missing. I thought maybe this our proxy issue or something similar, but I've same problem on my test tenant where I have full access to the internet and no antivirus. Maybe this is know issue already? We had to stop our migration to Office 365. Environment: windows 10 and 11, Office version: 16.0.15028.20248 Monthly Enterprise Channel.

Copper Contributor

@lachvit - I'm experiencing this issue on one of my client's tenants. A group of computers with recently installed Office apps are not receiving the policy at all. Verified that they are in the scope of the policy, but it's not looking like it's even attempting. These users are spread out over a few different working environments, so there's no commonality in the connection to the web.

Copper Contributor

@lachvit @Nate Mills I should have updated this sooner. I have found that if office is installed when no policy is in place it will never check again. If you have a policy in place then install office, it will consistently check. We fixed this by modifying the registry key on existing installs after a policy was put in place. 

Once we modified the registry key to enable the checking we were good to go. New installs of office are also good to go. 


@JaredA58 Can you share the explicit key\steps you are referencing? I would like to forward this to appropriate team as that would be undesirable for sure.

Copper Contributor

It turns out that the information I was receiving from my contact was erroneous and as soon as I directly connected with the user and deleted the CloudPolicy reg key (which had a fetch timer set to 0) and reopened office, it started to receive the new policy.

Copper Contributor

For example I've 7 test computers (laptops). If I delete cloud policy and reopen office software, it works on 3 computers and 4 computers are still missing cloud policies. Similar situation with in my organization, on some computers it works fine, on another no. And it has started after previous office version update (2203).

Copper Contributor

@JaredA58  maybe you can share more information? What registries you are referring?

Copper Contributor

@lachvit HKCU\SOFTWARE\Microsoft\Office\16.0\Common\CloudPolicy\<String>\FetchInterval. See comments above with some more details about this RegKey.

Copper Contributor

@JaredA58on computers where I have this problem if delete this registry, reopen office application and nothing happens, also no activity from click2run process, no connection to cloud, nothing. Month ago it was working fine...

Copper Contributor

Hi everybody, we are facing the same issue as mentioned earlier by @lachvit@JaredA58 and @SimoMoti. The "FetchInterval" has the value 0 (zero) on our clients, so the clients do not seem to contact the Office Cloud Policy service at all and no policies are deployed to our clients.


This problem is blocking us from rolling out Microsoft Information Protection and sensitivity labels to an environment of 10k users, because we want the cloud policy to enforce the setting "Use the Sensitivity feature in Office to apply and view sensitivity labels" instead of using the legacy AIP add-in for Office.


Anyways, after we deleted the whole HKCU\SOFTWARE\Microsoft\Office\16.0\Common\CloudPolicy\ registry key on some of our clients, these clients successfully fetched the desired registry settings from the Office Cloud Policy service, and the "FetchInterval" was set to 90 minutes.


Nevertheless, after we removed again the clients/users from the group, which is in scope of our cloud policy, these clients got the FetchInterval = 0 setting again. Consequently, the clients are now stuck in the bad state again. We would need to delete the whole  ...\CloudPolicy\ thing again, before we were able to deploy new policies via to the clients.


In summary, we are not happy with this workaround. We do not want to be required to delete the ...\CloudPolicy\ registry key on clients, which have not been in scope for a cloud policy before.

Is there any better solution Microsoft can offer to us? @Dave Guenthner Do you already have some news from the team you got in contact with?

Thanks a lot for any further help.


@duschu I sent you a message to connect directly so we can look deeper into this issue.

Copper Contributor

Today I've been informed that this is known issue? I've spend 2 month trying to explain that this is Microsoft bug and after 2 months I'm receiving email that this is know issue... 

Brass Contributor

Is it possible to override OCPS with Group policy in isolated cases?  e.g. RDS host with shared activation enabled.

Brass Contributor

I am also seeing some of the same issues with the FetchInterval being set to 0 after a successful policy push.  I used this to disable PST from Outlook.  I am looking at changing this setting but it will not grab for my clients, unless I delete the reg entry  for HKCU\SOFTWARE\Microsoft\Office\16.0\Common\CloudPolicy\.

Once I do this it then sets the FetchInterval to 90min.  Is this known issue going to be dealt with in a way that we do not have to manually remove this reg key to fix the issue?





@Robert_Hurd FetchInterval of 0 is a valid value and tells the client to check again in 24hrs which is the normal check in interval.  Take a look at the Troubleshooting tips here Overview of Cloud Policy service for Microsoft 365 - Deploy Office | Microsoft Docs

Brass Contributor

@Chris Hopkins Okay, that is great.  Thanks for letting me know that.  Why would a policy that I enabled to disable the PST option in outlook not update when I change the new value to disabled?  Can you not change an existing policies settings and have that update?  I have even tried changing the name of the policy to see if that would force the change.  I am going to test deleting that policy and creating a new one.  Any insight would be appreciated.  Thanks

Version history
Last update:
‎Nov 21 2023 03:49 PM
Updated by: