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

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:
*.manage.microsoft.com, *.msocdn.com, *.office.com, *.office.net over 443

 

Steps to perform proof of concept and validation
1. Create a test user, ours will be “Kasper Graf”, kgraf@contoso.com.
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:

Create1.png

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”.

Create4.png

Create3.png

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

Create2.png

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.

signin.png

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.

Warning.png

 

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.

 

Setup
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, https://apreltech.com/.
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.
https://sourceforge.net/projects/runassystem/ 
https://www.winhelponline.com/blog/run-program-as-system-localsystem-account-windows/ 

 

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 ocps.manage.microsoft.com to retrieve the policies for the user and a call to ocps.manage.microsoft.com 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.

OCPS2.png

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

OCPS3.png

ParentSettingId
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.

OCPS4.png

OCPS5.png

 

FAQ:
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.

73 Comments
Brass Contributor

@Chris Hopkins Hi, back in May 2021 you responded to someone's question about user impersonation & proxy support with:
"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."

Just to confirm, we shouldn't need to configure anything for OCPS to attempt to use WinInet, right? If connection via WinInet fails, does it still attempt to connect via the SYSTEM local account too? I'm having difficulty getting the policy check working within our network environment (it works fine outside of it), and I suspect it's because our network security service (Zscaler) isn't compatible with WinInet for non-interactive applications/services.

On a related note, the list of URLs Microsoft recommend we allow to bypass proxy are pretty broad and we're having difficulty convincing our network team to allow them (especially *.msocdn.com, *.office.com, *.office.net). Are you able to suggest a 'bare minimum' set of URLs used by OCPS?

Thanks in advance for your help! :)

Microsoft

Hi @KarriS,

The policy agent is built into the C2R component of Office which is running as System.  The first attempt is made to call our webservice using System.  If that fails, the policy agent will then attempt to impersonate the signed in Office user.

 

As for endpoints, you need to allow for OCPS to work correctly.
*.office.com

*.office.net

*.msocdn.com

Copper Contributor

Hi.  Is it expected behaviour that the scope/group cannot be adjusted once a policy is created?  The 'Scope' page is all greyed out for me.  Less interested in changing scope, more in add/removing groups to the policy.  Thanks.

Microsoft

@thecockneymanc yes that is the current design.  The Copy operation can be used to create a duplicate configuration which will ask you to target a different group.  We are working on an update to allow for editing the target.

Brass Contributor

I'm a little confused by this.  Normally, anything under HKEY_CURRENT_USER\SOFTWARE\Policies is restricted, however, a standard user can simply delete or modify everything under HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Cloud.  Is that correct?

 

[Edit] I retract the above statement, EPM software caused the issue here.

Microsoft

@DRich22 typically the policy hive () has special permissions that restrict modification of subkeys and values to admins.  If the user is a local administrator then they will have that ability.

Copper Contributor

@Chris Hopkins Is there any timeline on when the scope will be able to be changed?  We plan to do a staggered rollout with many different phases, and having to copy and delete policies whenever we want to add the next group of target users worries me a little.

Microsoft

@russellhowes73 If your policy configuration has the scope set to Group, you can edit the group that is targeted by removing the group and choosing to add a different group.

We are currently working on adding support for targeting multiple groups for a single policy configuration which we are targeting for release in the next few months.

Copper Contributor

Office cloud policy has one big problem, to apply new settings you need to open office application first. To solve this issue, currently we are also using GPO, but we plan to move to Intune configuration profiles. We have more than 170 configuration items in Office cloud policy, so it would be time consuming to migrate same policies to configuration profiles. Maybe you have some ideas how we can easily migrate all policies to Intune configuration profiles? Or maybe you know how to apply cloud policies before opening any Office application?

Copper Contributor

Hi,

 

This document is still useful in 2023... but we still have no mechanism of evaluating a device's current, resultant policy status.

This was indicated as on the backlog back in 2019.

 

Is there any update on this?

Hopefully the PM understands that this shortfall is possibly the largest single barrier to customer adoption: if our endpoint techs can't tell my CTO what settings are in place, he says "hell, no", and Microsoft Support get inundated.

 

Thanks in advance

Copper Contributor

We've been testing deploying policies via Intune and ended up with an odd issue.
Our policy was initially downloaded (months ago) and created the known registry key under HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Cloud\Office.
But any changes we make now, lead to the new policy being downloaded into HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\{GUID}_ADAL\Cloud\Office. None of the Office products appear to be checking that location, they all keep pulling their settings from the first registry location - which is no longer being updated.
We can delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\CloudPolicy and close/open Office apps as often as we like, the result is identical.

Copper Contributor

@RomanDoerr  I am seeing exactly the same problem, policies are now going under my Azure user GUID_ADAL\Cloud and being ignored.  For some users it seems to read from the root cloud key, and for others from the GUID_ADAL\Cloud key, which makes troubleshooting nigh on impossible.

Microsoft

@russellhowes73 @RomanDoerr the behavior you are seeing in the registry is by design and allows Office apps to apply policies for multiple users as they switch between accounts independent of the account used to sign into Windows.  Under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy you will see the LastUser key which holds the policy check-in information for the last user that triggered the policy check-in (the last signed in user) and a duplicate of that information using the ADAL ID.  This behavior is also used in the Cloud Policy hive (HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud\Office) to cache each user's set of policies and allow for quick switching between users.

If you believe policies are not being properly applied, please reach out to support or send me a private message and I can ensure we get this resolved.

Copper Contributor

@Chris Hopkins that is useful information, thanks - though I'm a little bit surprised to see a reference to ADAL in a system developed for 2023, given that library's imminent deprecation?

 

Is it just an error in expression?

 

Naturally, we're all still keenly awaiting diagnostic tools analogous to Resultant Set of Policy in this area.

It would likely have saved me tens of hours on the one trial deployment of OCPS we have.

Brass Contributor

Was there a change in behavior for for OCPS or Servicing profiles relating to the way automatic updates are enabled on the client?

Historically if going to Office > Account > Updates it used to state "Updates are Managed by your system Administrator" and correctly follow the defined Rings for the release schedule.

 

Now on the accounts screen in Office, I see "Updates are automatically downloaded and installed" and the user can run an immediate Check for Updates.  The following key is set:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate
enableautomaticupdates=1

ignoregpo=1

Microsoft

Hi @DRich22 - thanks for the question. There was a change with Servicing Profiles in the May MEC update. This change is unrelated to OCPS. To be more specific, we made some reliability improvements on the client side and 1 of those removes the need to set officemgmtcom = 1, which is responsible for the message: "Updates are managed by your system administrator". With this value now set to 0, you can expect to see the behavior you reported. That said, even though the end user can now click "Update now", there are still policies in place that restrict which update they receive. Specifically, the update channel and target version being set.

 

Copper Contributor

How can cloud policy be implemented in a non-persistent VDI environment? We currently have the issue that it doesn't pull the cloud policy into our non-persistent VDI, only after the following steps:

1. Delete the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy registry key

2. Start an Office app

3. Exit the Office app

4. Start an Office app - the policy is now active and gets applied

Copper Contributor

So what's the correct way to force a device to recheck in? I have 45 devices still sitting at the Feb update.

 

When I go to any of these devices and look at the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate

 

Chip_12_0-1712840840359.png

 

I tried deleting the following on a single device.

1. Delete the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy registry key

2. Start an Office app

3. Exit the Office app

4. Start an Office app - the policy is now active and gets applied

 

But the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate is not showing the latest targetversion

 

 

I also just noticed that all these devices say

 

Onboarding To Monthly Enterprise Channel under the cloud update status out in https://config.office.com/officeSettings/inventory/devices

 

I see this in regards to my last statement

https://learn.microsoft.com/en-us/deployoffice/admincenter/cloud-update#devices-are-updating-outside...

 

But I am still wondering why devices skipped last months updates....

 

Copper Contributor

@Chip_12 if you want to force Office update you need to use this command from PowerShell (you can change arguments): 

start-process "C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" -ArgumentList "/update user forceappshutdown=false displaylevel=false".
 
This registry: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\CloudPolicy will force cloud policy renewal not Office update.
Copper Contributor

Yeah I am looking at how you can force a sync for the cloud policy...

Microsoft

Hi everyone - Please note that this blog post pertains to Office Cloud Policy. For any feedback or questions pertaining to Cloud Update or any other products in the Apps admin center for that matter, please use the feedback tool

 

@Chip_12 your registry screenshot indicates the device was offboarded from Cloud Update (ignoregpo=0). Please check to ensure the device is not excluded and if you are using rollout waves, that the device is in an active wave for the fastest action.

Copper Contributor

I'm using Monthly Enterprise

https://config.office.com/officeSettings/MPmecChannel

 

My settings:

 - No rollout wave

-  Deadline 3 days

 

Yet I have like 50 devices stuck @ Onboarding To Monthly Enterprise Channel

Still confused by this!

Microsoft

@Chip_12 take a look at our documentation > https://learn.microsoft.com/en-us/deployoffice/admincenter/cloud-update#devices-are-stuck-in-an-onbo...

 

If this is still an issue, please share via the feedback tool or open a case so we can investigate. 

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