How to troubleshoot onboarding devices to the new Apps Admin Center

[BobClements]

Hi everyone, the Microsoft 365 Apps Rangers would like to share some tips & tricks with you on our latest set of features released to the Apps Admin Center. No idea what we’re talking about? Take a minute and review the Road map to modern management for Microsoft 365 Apps. This article will highlight how you can benefit from these new features (Apps health, Inventory, Servicing Profiles and Monthly Enterprise Channel). Takes just 5 minutes!

When you enable the new inventory feature (preview) and start getting insights across all the Microsoft 365 Apps installed and connected to your tenant, you might run into scenarios where some devices do not appear in the portal. Below you will find the two most common root causes for devices not showing up in inventory and steps on how you can resolve them:

• The device is running a version of Microsoft 365 Apps that does not support inventory.
• The device cannot connect to the Apps Admin Center due to a failure retrieving the Tenant Association Key.

This post will walk you through the steps to identify and fix these issues. We will do our best to update and expand this post as issues are identified.

Step 1 - Identify devices that are running an outdated build of the Microsoft 365 Apps

First things first: we need to check if your devices are running a version of the Microsoft 365 Apps that supports the new features in Apps Admin Center. This is a prerequisite for onboarding devices to the new service. The Microsoft 365 Apps need to be running version 2008 (16.0.13127.21064) or higher. Here are the steps:

• If you are running Microsoft Endpoint Configuration Manager, implement dynamic collections to identify which channels are actually in use.
• Then implement a dynamic collection to identify devices which are running releases older than version 2008.
• The first set of dynamic collections will show you which channels are in use within your environment. Deploy the latest update to the collection containing devices running releases older than version 2008.
• Trigger a Software Updates Deployment Evaluation Cycle for all contained devices. They will only download the deltas for their matching channel.
• Monitor progress. To speed things up, trigger the following actions:
  • Machine Policy Retrieval & Evaluation Cycle
  • Software Updates Scan Cycle
  • Hardware Inventory Cycle
• If you find some devices are not moving, review the ConfigMgr agent. Consider repairing the ConfigMgr agent and/or verifying that the devices can access their update source.

When this step is completed, all devices should be running on version 2008 or newer. Within a few hours they should start registering with the new service and appearing in inventory.

Step 2 - Identify devices that have not onboarded with Apps Admin Center

The next step is to identify devices that meet the minimum app version requirement, but failed at one of the following stages:

• Making the initial connection to the Apps Admin Center by fetching and storing the Tenant Association Key used to connect to the service.
• Collect and upload the initial inventory.

The net result of both issues is that the devices are not visible in the Apps Admin Center.

The Ranger team has crafted a configuration baseline for Microsoft Endpoint Configuration Manager to help automate the detection and remediation of these issues. The content is provided AS-IS and is hosted on GitHub for your reference. To leverage the baseline, proceed as follows:

• Download and import the baseline.
• Deploy the baseline to your devices with remediation turned off.

• Run a report on the baseline results to review how many devices are impacted. You can use the built-in report: Summary compliance by configuration items for a configuration baseline.

• To remediate non-compliant devices with a missing Tenant Association Key, update the configuration item with your tenant’s unique key. Note: Do not generate a new Tenant Association Key in the Apps Admin Center, just copy and insert the existing one.
• Enable remediation for your baseline deployment and verify if devices start to appear in inventory.

The remediation script will stamp the Tenant Association Key into the registry, which acts as a token to make the connection to your tenant. This will mitigate any issues which are rooted in the device’s inability to fetch the key for itself.

With the next launch of an Office application, the onboarding process should kick off and the device should become visible in inventory within the next few hours.

Feedback

We value your feedback as you use the Apps Admin Center and if you wish, you can use the feedback tool in Apps Admin Center to provide feedback directly to the team working on the different features. Optionally you can also add your email address to the feedback, so the team can get in contact with you.

Wrap-up

At the time of writing this post, the Apps Admin Center features (Apps health, inventory, and Servicing Profiles) are in Public Preview, so things might change over time. We will try to keep this post as current as possible. We are happy to answer any questions or take your feedback in the comments below.

The Ranger team is a small team of die-hard experts when it comes to deploying, servicing and managing Microsoft 365 Apps. The above guidance is based on our experience working during the Preview phase with the new products and is provided as-is.

In addition to this information, we have an Ignite session available for viewing that walks through the device onboarding process in greater detail. For more information about this session and our other content check out aka.ms/IgniteAACLinks.

Change Log:

• 03/03 - Initial Release

[#2]

Hello!
We have been following this guide and do have a question about the Tenant Association Key (TAK):

These baselines appear to search for the TAK registry key and if it doesn’t exist it creates it. It reads from one location and writes to another. Can you please verify where the TAK should live?

Checks this location:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officesvcmanager

If it doesn’t exist, it writes it to this location:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office\16.0\common\officesvcmanager

[#3 · Accepted solution]

Hi @josephlamb

Great question and attention to detail. This behavior is intended. The TAK should exist under the cloud key. If Serviceability Manager is unable to pull the TAK and write it to this location we fallback to the GPO key. This is why the script remediation writes to the GPO location. If you attempt to manually write the TAK to the cloud key it will be overwritten during the next checkin. TAK delivery will be receiving some fixes in a future release to address this.

In addition, the baseline has been updated to address the TAK CI. The detection logic now properly checks both registry keys for the TAK. Previously it was only looking at the cloud key, resulting in the CI remaining non-compliant. 

[#4]

Thank you for the quick response! I really do appreciate it!

Another quick question for you -- We are seeing two different TAK keys. As we are onboarding these devices we are finding that devices that register have a different TAK key than what is defined here - https://config.office.com/officeSettings/settings

We can easily recreate this by deleting the TAK key from: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officesvcmanager and it will recreate the TAK that is not listed in the Apps Admin settings.

Hopefully that makes sense! Would you know why that would be the case?

Also, is there a better place for us to ask about questions or issues? Is there a Yammer created for the Apps Admin console yet?

Thank you again for all of your help!

[#5]

@josephlamb 

There is a decimal point towards the end of the string with another set of characters following. Do the keys match up to this point? 

We are currently using TechCommunity to discuss the new preview features, so feel free to continue the discussion here. 

[#6]

There is a decimal towards the end. A co-worker noticed that these were a JSON Web Token and showed me how to decode them.

The Tenantid is the same, but the appid is different:

Portal TAK contains: 3cf6df92-2745-4f6f-bbcf-19b59bcdb62a
Mystery TAK contains: d3590ed6-52b3-4102-aeff-aad2292ab01c

Any idea what might be causing this?

Thank you!

Joey

[#7]

@josephlamb 

With regards to onboarding, the TAK is only used to identify the tenant. If you are in a scenario where the TAK is not being pulled down automatically the recommendation is to use the one from the portal (and corresponding appid). Devices that do automatically retrieve the TAK will end up with a unique appid, but it does not affect the onboarding process.