Intune Management Extension not installing

Copper Contributor

I am testing Intune/EMS on Windows 10 (1709) PCs and trying to get Powershell scripts to run without success. I think the issue is with the Intune Management Extension not installing but cant find much information on how to troubleshoot this particular issue.

 

Can anyone advise how I get Powershell scripts to run ? TIA

 

Scott

70 Replies

Has the machine synced? Can you see any log files in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs ? 

No this directory ( IntuneManagementExtension ) does not exist....

Hi Scott,

 

maybe have a look at my blog post here:

 

Deep dive Microsoft Intune Management Extension – PowerShell Scripts

https://oliverkieselbach.com/2017/11/29/deep-dive-microsoft-intune-management-extension-powershell-s...

 

I cover inner workings and troubleshooting of the agent to find such particular issues with installing Intune Management Extension.

 

Two things to check for agent install issues are event viewer and the Agent MSI install log:

 

Start event viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin (event id 1924 and others)

 

MSI install log:

C:\Windows\system32\config\systemprofile\AppData\Local\mdm\ {25212568-E605-43D5-9AA2-7AE8DB2C3D09}.log

 

best,

Oliver

Oliver, thanks for the update.

 

If I look in the appdata\local\mdm folder it is empty

 

In event viewer I have a number of errors with Event ID 822 ( MDM PolicyManager:Acquiring the merge lock.... ), each ending with "cannot find the file specified", and a number of Event ID 454, Command failure status.

 

Not sure from your guide what this means or where to look next  ?

 

Regards

 

I should note that as a test I have deployed a few MSI's to my PC ( Notepad++ and 7Zip etc ) and these appear to install ok.

Okay the way the MSI's gets pushed to the machine is the same how the Intune Agent gets pushed down. So basically it should work.

How is your assignment did you use user assignment? In my tests that was the only functional way.

I've checked a few of my test machines, I can't find event entries with ID 822. Can you post a little more detail on your error events?

Is your problem still existing? Can you share us some details about the event log entries?

 

ok

Oliver, thanks for following up on this. Unfortunately I haven't made any progress on this as I have been working on other things. I will get back to it, hopefully sometime this week and let you know how I get on

 

Cheers

Did you get anywhere with this?  I have been struggling to figure out why sometimes I do not get the service and sometimes I do.  I have checked logs everywhere on the machine and do not see any relevant errors.

In our environments it's working quite well. We had problems due to interrupted network connectivity but this is not a problem of Intune or the agent. Are you targeting the scripts as user assignments? Can you share logs from a machine not getting the service? MDM report, logfiles, eventlogs, Intune Agent logfiles registry (HKLM\Software\Microsoft\EnterpriseDesktopAppManagement)...

I have the same problem. Intune management extension does not get installed.

I created a powershell script and assigned it to a group containing the user.

 

Any ideas? Or at least a way to troubleshoot the issue?

Sounds like problems with the initial MSI Install job via EnterpriseDesktopAppManagement CSP:

see here:

https://docs.microsoft.com/en-us/windows/client-management/mdm/enterprisedesktopappmanagement-csp

MSI/ProductID/Status Status of the application.

 

In the registry at HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\<SID>\<MSI-ProductCode> you can find the Status according to the CSP site above.

 

Try to figure out this status - Download error or what else and correlate with your machine and environment (may there be a proxy issue?). In the past Intune followed a retry logic. I give an example: try it 3 times with timeout of 10 min and then fail. If failed, Intune tried it again in 7 days (the 7 days setting after fail was fix in the past, maybe this interval is lowered now but I don't now, registry suggests that this is changed). So again the values above are examples based on registry values for the logic! I do not know if this is correct as I do not have documentation for it.

What are the registry values for Enforcement* on that machine. Values are in the same path as described above. There are the Retry, Interval, Timeout, Index and StartTime values... I'm not sure if this is all and how they correlate to each other exactly... But maybe we can extract some information from the retry values. For example it may look like that all retries are failed and the machine is in extended timeout currently....

 

Other way dealing with MSI install fails in the past, was to change something at the MSI metadata to re-enforce push/install. This is not possible in our case as we have no control over the SideCar agent metadata.

 

Can someone share the MDM advanced diagnostic report... what is listed there and what about the eventlogs...

I also noticed the same since approx 2 weeks.  This worked absolutely fine in the past (in Dec for example, I built internal docs based on these positive results).

 

Unfortunately, I did not found any root cause so far : in "devicemanagement" event log, stuff seems to communicate to the Intune backed and no obvious errors. Hitting "Sync button" does not help. The file  C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.txt  and  the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Policies\ are no longer created.

 

Since that time (coincidence?), I have also problems with devices enrolled with on-prem users coming from "synched AD groups" (from an on-prem infra, and using ADFS), where neither apps, scripts, or profiles are applied, even if "devicemanagement" event log does also not show obvious errors.    

 

I will post here once I will progress in my tests.

Hi Olivier,

 

what about HKLM\SOFTWARE\Microsoft\EnterpriseDesktopAppManagement\<SID>\<MSI-ProductCode> can find the status there?

I assume the failure has something to do with the CSP as mentioned in my last post. Can you check this, please? I like to know if the backend is not even trying to deliver or if the corresponding CSP EnterpriseDesktopAppManagement has a problem getting the sidecar msi and finally to execute it.

Screenshot attached (enrolled this time my VM at OOBE with an AAD user), and "Status" key is 0x46 (70).

 

This looks good! According the info from the screenshot the CSP has successfully downloaded and triggered the install of the sidecar msi. Do you have the Management Extension Service in the VM now? If not do you have the msi logfile of the sidecar now?

This morning, everything went fine and thought I would pull all my hair off. It worked with any users (AD or AAD), scripts were installed sometimes after 7 to 10 min of uptime after OOBE, but there were installed at some point.

But while writing this post, I did a last test with the same user I used during all my tests, and I hit the issue again : even the start menu icons (like for for XBox, Alarms, Weather, Sway,...) were not populated after 10 minutes, and were left with these "down-arrows" signs (see attachment), even if the Intune Management Extension MSI could already be seen in Settings/Apps pane.

But at the exact moment, that "wsappx" process starts to re-eat your CPU (it did it first time shortly after landing on desktop to install my 7-Zip MSI, Arduino and Bitcoin Calculator apps from the Store... I flagged them in Intune as "Required"), my PS scripts were executed after exactly 20 min of uptime!, and 4 minutes later, the start menu icons for XBox&Co started to be all populated.

So one thing is sure : you really have to wait until "omadmclient.exe" and this "State Repository Service" are really idle for long time, and you have to wait even few minutes more to be on safe side.

It makes me believe there is now like an artificial throttling interval, that didn't existed before, and is why people believe "PS scripts do not always work", especially when your CPU/network/disk are fully idle for few min.

Absolutely you have to be patient. Like ConfigMgr on-prem environment it takes time sometimes. A lot of background processes are running after OOBE and depending on various facts it may result in longer wait times. You observed it, OMA-DM client and so on... I have machine where I waited more than an hour. In the beginning of Intune (Silverlight portal and old backend) it was even worse, we waited for things sometime up to 4 hours and more. The new Azure based infrastructure is much better but it also takes some time infrequent. 

So again I can confirm that it takes time sometimes. But my past is defined by ConfigMgr environments and there you learn to have patients :-).