Aug 30 2022 02:40 AM
Aug 30 2022 02:40 AM
We are currently testing the Servicing Profile feature (for M365 Apps) in our tenant. Results so far are not ideal.
All our devices are built via Autopilot and enrolled into Intune and AADJ. They are added to a servicing profile via a dynamic AAD Group membership. However, some devices show up and others do not, even after multiple days. They are all online and successfully communicating with Intune. The Servicing Profile config reports the correct number of devices in the AAD Group. Yet several devices just do not show up.
All the devices that are part of this test are connected directly to the internet (no proxy involved). The next phase of testing is to try testing with the Zscaler client active on the device (this is where we expect to see issues).
I've checked the registry keys mentioned in the docs and the videos on the Office Deployment insiders YouTube channel. Even the 'working' PCs don't seem to have the stated configuration.
Currently, we are at a loss to explain why some devices show up, but others don't.
Any assistance will be gratefully appreciated.
Aug 31 2022 05:48 AM
Aug 31 2022 07:37 PM
Sep 01 2022 01:38 AM
@Ivan Webb Thanks for checking. Given that the devices are in inventory (so communicate with the AAC backend), are in the AAD groups (so in-scope for Servicing Profiles), are AAD-J (we don't support AAD-R), there seems to be something off with how the group members are resolved and matched to the inventory.
Please go to the apps admin center, onto the servicing profile page and hit the feedback button on the top right corner. Include your original post, the things you already checked, mentioned "Rangers on TechCommunity" and leave your email. I will ping the team in the background, so we can start investigating your case.
Sep 02 2022 01:23 AM
Sep 02 2022 02:28 AM
Oct 06 2022 02:20 AM
Oct 11 2022 02:43 PM
Oct 24 2022 12:01 AM
Nov 15 2022 12:43 AM
@Ivan Webb Error 35 is a transient issue which is caused by the agent not being able to fetch the current status from the C2R API, e.g. caused by system reboots (as the C2R service gets reset as well). It automatically retries to fetch the status, that's why you see the number of issues fluctuating.