Autopilot, Co-Management and ESP Timeouts (and BITS too)
I'm working with a customer who has been having a great deal of issues with their Autopilot implementation. Basically, the ESP page will timeout with one of these two error codes: 0x800705b4 0x00000004 This shows as an error to the end-user, and is unacceptable The interesting thing was that, if you left the device for an hour, then hit continue (that option is set in the ESP properties), then everything will have installed correctly, and the device is compliant. So why would the ESP page fail with a timeout way before the 6 hour limit I had set? The0x800705b4 Error The first thing I discovered is that all this is related to co-management and the CM client install. Getting the first timeout:0x800705b4 I noticed the following two value's values were strange: HKLM\Software\Microsoft\Windows\Autopilot\EnrollmentStatusTracking\Device\DevicePreparation\PolicyProviders\ConfigMgr Updating Media InstallationState would be 1 (Installing) or 4 (Failed) (It's 1 if the client is still installing, it will switch to 4 if the install fails or the registration fails) InstallDuration would be 1800 (not 1801, nor 598, nor 1799, ALWAYS 1800) If I looked at the CCMSetup.log file it would show that the installation was successful, and the return code would be 0, as expected. But on looking at start time and end times on the logs, I noticed the install was taking over 40 minutes to complete. In this case it was 27 minutes but the ESP still failed? This is becaause the client, although installed, has not registered I'll go into this more in the 0x00000004 error below. But is this case the combined install time of 27 minutes to install and 10 minutes to register took the install time over 1800 seconds and so it failed with the0x800705b4 error. If the combined times (say 500 for the install and 600 for the registration, which comes to 1100) is less than 1800, but the registration fails 6 times taking 10 minutes, then we get the 0x00000004 error On further investigation of this log, I found that I would occasionally get a BG Error Context is 5 notification, and that the download of the client would be divided into multiple 5-minute segments, with each segment downloading only around 28MB. Which meant the net time to download the binaries would be 40 minutes or more. Now given that 1800 seconds = 30 minutes, I realized that the ESP had a second timeout, totally unrelated to the one set in the properties within Intune. Basically, if the CM client did not install within the 30 minutes, the ESP failed, regardless of whether the install was finished or not. So when linking this with the BG Error Context is 5, I realized that this was a BITS issue, I have no idea why BITS would be throttled during an Autopilot install process, but it was. The solution was to add the following command line option to the Co-Management properties. /BITSPriority:FOREGROUND. This effectively removes the limitations on the BITS download, and the entire installation time sunk to less than 3 to 10 minutes, depending on Internet bandwidth. This was a great win, and with it, the 0x800705b4 disappeared. The 0x00000004 Error Only to be replaced by the 0x00000004 error (I might have the number of 0s wrong here, I'm working from memory). The 0x00000004 Error As with the previous error, this was not a constant, it would happen, then it wouldn't, then it would again. But it happened enough to be a problem. I looked at the registry again and noticed this: InstallationState would be 4 (failed) InstallDuration would be LESS THAN 1800 I kept digging. The answer was found in the ClientIDManagerStartup.log log. Once the CM Client is installed, the next step is to register it with an MP and get it into the MECM database. As shown by the image below, if it fails, it sleeps 60 seconds, and tries again, then another 60, then 120, then another 120, and then 240 and finally a final 240 (10 minutes in total) at which point it fails, and if you look at the last line in the daigram, it sets the ConfigMgr Install state to 4, which fails the ESP, this time with the 0x00000004 error. As with the previous error, this doesn't mean anything actually broke. It just means it didn't occur with the allowed timeframe (this time 10 minutes). The difference between the two errors is simply that in the first one the combined time to install the CM Client and the 10 minutes of sleeps in the ClientIDManageStartup log exceed 1800, whereas in the second, they do not. The important note, is that they both register the 10 minutes of sleeping and fail the ESP. So, if you factor 10 minutes to install the CM Client and another 10 attempting to register, this failure can occur after only 20 minutes, way less than the 3600 minutes set in the ESP. So why is the client not registering immediately? That is the million-dollar question. and asfar as I have got with this issue. I looked to the MPs to see if there was a bottleneck in the outboxes, returning the acknowledgment that the client is registered, but couldn't see anything out of the ordinary. Another thing to note, is that if you have a Provision TS running, it will kick off immediately after the ClientIDManager fails the ESP. So any apps being delivered via this task sequence will install and the device will complete successfully (other than the ESP error). Final Thoughts What is interesting (or frustrating, depending on your viewpoint) is that Autopilot and the ESP really doesn't actually do anything (except a few things like setting user install type and making ConfigMgr a 1st app, to ensure it takes the MDM authority, preventing ESP from ending until certain apps are installed. The rest is controlled by Intune or ConfigMgr natively. If you don't assign blocked apps to users or groups, they don't get installed that's it. Same with policies and profiles etc., but by the same process, if the ESP (and by extension Autopilot) fails, it doesn't mean everything stops installing. It continues installing everything and provided there are no actual issues it finishes successfully which makes it very hard to troubleshoot. The first thing I do when I start troubleshooting is look to see what didn't get installed/applied. In this case everything gets installed, everything gets installed. The only error is the ERROR ITSELF. In a prefect world, if I have set the timeout for 6 hours and the CM client takes 5 hours to install, then there should be no error. Same with registering the client. If it takes 2 hours of 'sleeping' to get it registered, who cares? I have 6 hours to play with. Obviously we don't want things to take that long, but we all know that MECM is not the fastest moving software in the world, before it was Intune Configuration Manager, and Microsoft Endpount Configuration Manager (MECM) etc., it was knows as SMS which was affectionately renamed Slow Moving Software.
Windows Servers AAD Hybrid Joined and SCCM ConfigMgr Co-Management MDM Auto-Enrollment
I have doubts about some configurations. Basically, we have: sccm installation with co-management performed via cloud-attach wizard intune pilot group device collection configured default client setting policy allows device registration in azure ad azure ad connect configured for hybrid join mdm user scope configured to all in azure ad mam user scope configured to none users can register devices in azure ad (Users may join devices to Azure AD) business premium licenses usage location configured in the azure ad synced user no conditional access or mfa configured The situation is that both client and server are synchronized in azure ad and are seen as join type "hybrid azure ad joined". In azure ad the clients has as mdm "microsoft configuration manager", the same clients then on intune in the managed column by show "co-managed". Servers on the other hand (windows 2016) are not automatically enrolled in intune and i don't understand why, the are hybrid azure ad joined in azure ad as devices. Other unclear thing, do i have to create the gpo for automatic enrollment in active directory (enable automatic mdm enrollment using default azure ad credentials)? At the moment it is created and linked to the OU containing servers and set as "device credential" (i read in documentation that with sccm or azure virtual desktop it is supported), even if i set in "user credential" anyway it doesn't work. With the gpo applied the scheduled task is created but in the events I get the following error:Auto MDM Enroll: Device Credential (0x1), Failed (Unknown Win32 Error code: 0x8018001c) By doing a dsregcmd /status on the machine everything seems ok. I don't understand what the best practices are regarding this gpo, and where I am going wrong.
Co-Management: no client details no timelines..why?
Das Co-Management ist aktiviert und ich sehe bei dem Pilotclient keine Client Details, Ressource Explorer, Collections, Timeline...Warum ist das so? Wer kann hier helfen? Ich habe noch zwei Screenshots hinzufgefügt. The co-management is activated and I don't see any client details, resource explorer, collections, timeline... Why is that? Who can help here? I added two more screenshots.Detection of Office C2R after Co-Mgmt Workload Move
Hi Everyone, I am in the process of identifying potential issues with moving our C2R workload from SCCM over to Intune. Our SCCM devices currently have Office C2R installed on them from when they were imaged, but are not managed using SCCM. From the Intune side we actively deploy Office to all machines using the built in Office C2R. My concern is when I toggle the switch over to Intune that my existing device will get Office reinstalled/removed. I have tested this and the result is inconsistent, but at least some of the devices did get Office reinstalled, MS Support confirmed this. In an effort to try and minimize the amount of devices that will get Office reinstalled I am trying to identify how Intune detects Office C2R built-in to be able to compare against our existing devices. Anyone have any info around how Intune detects the built in Office.Co-Managed showing "Disabled" but machine is appearing in Intune
We are just beginning to enable co-management on our estate, and have started with just 1 test device. After enabling co-management in SCCM, the device is now showing in Intune. However, on the device itself under Control Panel - Configuration Manager, it says "Co-Management - Disabled" and I'm not sure whether this should be ignored. It has been several days, and I have tried Syncing policy within Intune, but it is still showing Co-Management as Disabled. Any tips on how to troubleshoot this?
