Last Updated on January 26, 2023 by rudyooms
This blog will be about (yes… again) an Intune sync issue. After we took over management of a Microsoft Tenant from a new customer we experienced some weird Intune issues.
I will divide this blog into multiple parts
- What did they do?
- The DmWappushservice
- The Fix
- Results after applying the fix
As mentioned in the beginning, we took over management of a customer their Microsoft tenant. We took over management because they weren’t happy with the old Managed Service Provider(MSP). Also, they were experiencing a lot of weird problems.
When we take over management we will always try to change their device configuration to our own baseline but while doing so we stumbled upon some weird issues.
Implementing the missing device configuration profiles, made us add an additional settings catalog to configure the Storage Sense settings
To be sure storage sense was enabled and configured we logged on to a device to initialize a device sync from the Company Portal. As shown below, I guess this isn’t good!
That’s odd? Of course, we also tried to run a sync from the Settings menu in the Work or School section but that one gave us the same kind of error. As shown below the device sync status is mentioning that “The Sync could not be initiated (0)“
That’s weird, we also tried to do the same on another device but we end up with the same error. Besides this issue, we noticed that new or other changed device configuration profiles also weren’t applying
I guess it’s safe to say, we have got ourselves a sync issue again!.. Let’s party
Luckily I do have some limited experience with weird Intune sync errors. When you need to troubleshoot sync issues, this blog would be the first place to start (Or use my IntuneSyncDebugTool)
First things first…Are we having the pleasure to have another NOT valid MDM device certificate? To be sure, we opened the LocalMachine certificate store and opened the properties of the Microsoft Intune Device CA. As shown below, this time an expired MDM certificate isn’t causing all the pain.
Checking dsregcmd /status also didn’t show us anything that could indicate that something went wrong. Maybe triggering a sync from Intune itself could help?
To be sure it started syncing I again logged on to a device to check out if the Device Configuration Policy arrived at the device. You could guess the outcome! I guess it was not my lucky day! In a working situation when you initiate a remote sync from Intune, the Windows Notification Services (WNS) will establish a connection with the management server through a Push notification and it will trigger the PushLaunch task.
If these tasks were removed or the corresponding WNS service wasn’t working, the sync would fail so I needed to check out both of them
First, I opened the task scheduler to make sure those important tasks were still there. As shown below, when opening the “EnterpriseMgmt” tasks, I noticed the “PushLaunch” and “Schedule to run OMADMClient by client” were still there
Let’s proceed to the WNS service. To have a clear view of all possible services that were disabled I made sure I sorted the services to check out the disabled ones.
Luckily, the corresponding service: “Windows Push Notification System service” was also configured to run automatically and was started.
So, it looks like something else is giving us issues, as there are no expired Intune Certificates and all services are running, right? I decided to try to run the “Schedule #1 created by enrollment client” scheduled task to determine if it could run successfully.
As shown above, when trying to run that task manually, it mentioned that there are no more endpoints available from the endpoint mapper (0x800706D9). Before starting my journey on Google, I decided to start some tracing with the latest and greatest WPRP file below
In this WPRP file, I made sure I added the 86625c04-72e1-4d36-9c86-ca142fd0a946 AKA OmaDmApiProvider. I started the trace and tried to perform some Intune sync actions and tried running the scheduled task manually
As shown above, the OmaDMApiProvider is giving us the same error code we noticed earlier: 0x800706D9. I guess we are on the right track here! But that error code is not the only thing the trace was showing us. Besides that error code, it is also mentioning the OmaDMApi.dl and the OmaDmInitiateSession_internal operation
I guess it’s time to open our almost favorite troubleshooting tool, called IDA. After opening IDA I opened the OmaDMApi.DLL, and start searching for the OmaDmInitiateSession_internal operation.
This is what my “search” got me! Some stuff mentioning the X-Wap-Application-ID and the import of DMPushProxy.dll. When scrolling down, I noticed that it also calls upon the PushRouter_SubmitPush
Oooooppppppsss I totally forget to check the dm”WAP”pushservice (WAP Push Message Routing Service) I guess I just needed to start searching Google first before deep diving into the DLL… but who cares right?
Because If I remembered correctly there was an issue when that DmWapPushService was disabled.
Looking at this warning above, I guess we can be sure that this service is pretty much required for the device to be able to sync with Intune.
Did I miss something? As I did check out if some services were disabled. I am pretty sure, that service wasn’t on the list (Windows 10). To get a better view, I opened this registry key
In a normal situation, the dmwappushservice should be listed in the registry. As shown below, on the left side were our problem devices, while on the right was my own device.
What happened with Mon… uhhh the dmwappushservice?
3. The DmWappushservice
Before continuing our wonderful story, let’s focus a bit more on the Device Management Wireless Application Protocol (WAP) Push message Routing Service (DmWappushservice). First, Let me explain what correlation it has with OMADMCLIENT.exe when trying to sync a device.
When you initiate a manual sync action from the Windows Settings menu or the Company portal, you will notice that the “Schedule to run OMADMClient by client” task will be executed to initiate the sync. As shown below, you will notice that this will call up on the OMADMCLIENT.exe
When we initiate a management session with an OMA DM solution as shown above we do have some requirements to be met. One of them those requirements is to have the DmWappushservice enabled and to start automatically.
Do you remember my blog about which certificate store the Intune MDM certificate is placed during enrollment? In that blog, I showed you how the device knows in which store it needs to place the Intune Device Certificate during Enrollment.
When taking a closer look at the beginning of that decoded request, we will notice the next line: WAP-provisioningdoc.
Guess in which service the name WAP pops up? The DmWappushservice.
In a normal situation, this service will start automatically (delayed) at boot and would initiate and orchestrate management sync sessions with the Mobile Device Management server.
When the MDM server wants to push settings to the device, it has to send a notification packet to it to start new management session. This phase is done using Wireless Application Protocol (WAP)
If this service isn’t enabled or if it’s missing in action and you try to sync your device you will end up with some nice errors. Also good to know is when trying to enroll your device into Intune and that service isn’t enabled or started, those tasks I mentioned earlier will not be run successfully
If those 2 scheduled tasks aren’t executed when enrolling the device into Intune, the PushLaunch and PushRenewal scheduled tasks will not be created
The consequence of those tasks not being created and not being run will be that we will be missing the SslClientCertReference in the OMADM\Accounts registry key because it didn’t have the chance to fetch the wap-provisioningdoc with the information in it
4. What did they do?
As stated before, we took over the whole tenant and its configuration. I guess it was time to check out what configuration profiles were configured but after digging through all the configuration profiles it was time to check out the PowerShell scripts.
If you want to check out those PowerShell scripts, you could easily download them to your own device by using this PowerShell script
After downloading all of them, we noticed one with a particular name: Windows_DisableTelemetry. That’s odd as we normally make sure Telemetry is configured to “Basic” but not disabled! Otherwise, a whole lot of stuff isn’t going to work
So we opened the PowerShell script. At that same time, I needed to pick up my jaw off the floor
sc delete dmwappushservice sc delete DiagTrack reg add "HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\DataCollection" /v AllowTelemetry /t REG_DWORD /d 0 /f
“They” were deleting the dmwapppushservice? to disable the telemetry... Oh my… that isn’t good. Why on earth was this PowerShell script added to Intune? I guess Jóhannes described that clean-up script perfectly
That’s something we NEED to fix because, without that important service, the Intune sync is never going to work!
5. The Fix
When the device isn’t syncing anymore, it won’t mean the PowerShell script won’t arrive at the problem device. When the Intune Management Extension service is still running, you are good to go! So we uploaded this PowerShell script to their tenant
6. Results after the fix
After some time of waiting and letting the users shut down their devices to enjoy the weekend, we noticed the fix did its job. When opening the agentexecutor.log we noticed the PowerShell script arrived at the device and created all the necessary keys
After a second reboot, the required service was back in action!
As expected, with this service being called to arms again, the sync issues are gone! As shown below, the last sync was successful!
This time it wasn’t an expired certificate but just an important service missing in action. Luckily when your device isn’t syncing anymore, you could still push some nice PowerShell scripts to the device as long as the Intune Management Extension is still working.
Sometimes you are wondering why people do stuff they do… but disabling telemetry this way… Not my cup of tea
But then again, I am also messing with the system permissions on the IMECACHE folder… so who is counting 🙂