SOLVED

How to troubleshoot onboarding devices to the new Apps Admin Center

Microsoft

For the latest information regarding onboarding and inventory, visit: Onboarding Devices in the Microsoft 365 Apps Admin Center - Microsoft Tech Community

 

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:

 

BobClements_1-1614808933483.png

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

BobClements_2-1614809012503.png

 

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

BobClements_0-1614809282130.png

 

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

 

18 Replies
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
best response confirmed by BobClements (Microsoft)
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. 

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!

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

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

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

N/A

 


@KrisDeb wrote:
Hello and thank you for all this documentation and guides.
Is there anything else we can do if our devices are not shown in the Inventory?
We followed the process from your video clip 'How to onboard devices to the Microsoft 365 Apps admin center' and used all the information from here.

The device has the TAK properly sitting in the registry, all tasks from the scheduler are running etc. but I can't find any check-ins in the logs in Temp folder and ProgramData -> Office is also empty, no sign of Inventory text file/log.

Is there anything you guys need to do from the Cloud side, I understand the device will be deleted from the cloud after 180 days but it's a long time to find out... Anything we can do more?

I can see another device will disappear as well as it's not changed for two days, just the same as it was with the first one. Will update about the progress.

Thanks.

@KrisDeb a change was introduced recently that disabled logging for Serviceability Manager by default. This might be why you are not seeing the check-in messages, along with any other pertinent information. To re-enable logging add the following registry value:

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\C2RSvcMgr]

"EnableLocalLogging"=dword:00000001

 

Once added, logging will resume during the next scheduled task execution. I will PM you if there is more investigation necessary. 

Hello,

I found this post when I'm trying to understand why 2 users devices are not present in the list; I elaborated it and ask this: is this possible that I can't see them beacuse I installed it with the Office deployment tool and not directly from the users portal?
If so, what I can do? We haven't Endpoint manager, so maybe we can create the entry in the Windows registry and insert the TAK and this help to discover the devices? What is the correct location?

--
Thanks,
Marco

@Marco Mangiante deployment using the ODT is supported and should not impact onboarding.

 

First I would confirm the missing devices meet the following requirements:

  • Microsoft 365 Apps for enterprise or Microsoft 365 Apps for business, Version 2008 or later
  • A version of Windows 10 supported by Microsoft 365 Apps for enterprise or Microsoft 365 Apps for business
  • Microsoft 365 (or Office 365) for Business Standard, Business Premium, A3, A5, E3, or E5 subscription plan
  • Client devices can reach the following endpoints:

Overview of inventory in the Microsoft 365 Apps admin center - Deploy Office | Microsoft Docs

 

If the requirements look good, you can manually stamp the TAK in the registry using the following steps:

 

  1. Copy your current TAK from the Apps Admin Center portal (Settings).
  2. Create a new REG_SZ registry value titled "TenantAssociationKey" in the following location: HKLM:\SOFTWARE\Policies\Microsoft\office\16.0\Common\officesvcmanager
  3. Add your TAK to this value.
  4. Open a terminal window and run the following command: "C:\Program Files\Common Files\microsoft shared\ClickToRun\officesvcmgr.exe" /checkin

If there are no additional blockers, I would expect to see the device appear in Inventory within 5 minutes.

Hello
I have an old employee who I revoked access to 365. However there may be a risk that they kept the app with old emails. Is there any way how I can check it?

@LegalAlien the inventory feature isn't designed for auditing account termination and access. For that I would recommend the following: Remove a former employee - Overview - Microsoft 365 admin | Microsoft Docs

Hello @BobClements

thanks for your reply. I've seen on one of my colleague pc that the entire path HKLM:\SOFTWARE\Policies\Microsoft\office\16.0\Common\officesvcmanager is not present, it stops to "Microsoft"; I've also seen that the path is not present on my notebook, but there is the path  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officesvcmanager; so, could however create the remaing \Microsoft\office\16.0\Common\officesvcmanager and then the kye TenantAssociationKey?

 

Thanks.

@Marco Mangiante 

That is correct. You need to create the full path (HKLM:\SOFTWARE\Policies\Microsoft\office\16.0\Common\officesvcmanager) and the corresponding value (TenantAssociationKey). This path will not be present unless you had prior Office policies on the client device.

@BobClements 

Will this work with Intune? Since the last Zero Day in office, i was shown this site and have used it to manage our devices. However, some of our enrolled devices are not listed. 

Hi @RiceHDA this particular baseline is for Configuration Manager and cannot be imported into Intune. However, you can create some scripts and deploy them using Proactive Remediation to detect issues. Take a look at the troubleshooting section in this article for some of the areas to look for: Onboarding Devices in the Microsoft 365 Apps Admin Center - Microsoft Community Hub

@BobClements 

Hi Bob,

I've been struggling to get any devices into inventory. I've waited 5 days from enabling inventory, verified we are running a version of office that supports, can see "Monitored Devices" in Channel Metrics, but 0 "Devices", All of inventory says "Getting this info", I've changed the TAK in the portal, manually set the TAK on a couple machines, manually forced a checkin with the officesvcmgr.exe, added the "enablelocallogging" dword in the C2rSvcMgr reg entry.
I do not see the "OfficeSvcManagerAddons" in the Component Services snapin. 
Any ideas? I've exhausted the troubleshooting details I can find, hoping you are still monitoring these posts.

Hi @Kalen von Olnhausen - I just sent you a DM to get some additional information.

1 best response

Accepted Solutions
best response confirmed by BobClements (Microsoft)
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. 

View solution in original post