Forum Discussion
Intune Doesn't Install Win32 Apps Until a User Logs On?
I've just re-imaged the device and run it through autopilot and it is setting at the logon screen. The device record has not show up in Intune yet but it is in AAD and of course, the devices area in Windows enrollment/Autopilot in Intune, with an enrollment profile assigned.
The device completed ESP almost immediately and I didn't have to click the "Continue Anyway" button. I think this is because I have all my apps assigned to a dynamic SG that doesn't get populated until after ESP completes. I changed this around a bit to allow ESP to complete successfully since it was getting endlessly hung up on a few apps that wouldn't install due to expected installation failures. I don't trust ESP enough to expect everything to go perfectly so I'd rather limit it to the basics then have the rest of the apps and config be pushed down once the device joins the dynamic SGs.
Here's the basic flow of how I have this set up
1. Apply OS bits to bare metal
2. Get device on Wi-Fi
3. Hit Shift-F10 for cmd/powershell
4. Run Get-WindowsAutoPilotInfo -Online -AssignedComputerName "DEVICENAME" -GroupTag "DEVICENAME" -AddToGroup "Autopilot-ROLETYPE" -Assign
5. Wait for autopilot deployment profile to be assigned to the device
6. Reboot the device
7. Autopilot starts and does all the typical autopilot stuff and completes ESP
8. Device ends up at login screen
I'm now using a dedicated SG for assignment of the deployment profile. At one point, I was using the same SG for assignment of both apps and the deployment profile. When I did this, ESP would try to install all 10 of my apps which were assigned to the same SG which caused ESP to hang on failed apps.
So now, my theory is to get the device through the imaging and enrollment process as fast as possible then let all the apps and config come down post-imaging/ESP once the device gets added to the dynamic SG which the apps and config are assigned to.
Hope that makes sense. Let me know if that's a terrible idea.
I'm currently sitting at the logon screen but the new device is not showing up in Intune. AAD knows about it and so does autopilot but Intune does not yet and it's been about 20 minutes.
I'm expecting the Intune record to show up eventually and add to the dynamic SGs and at that point, I'll be able to see if it can install the Win32 apps now that I've removed the MSI app.
Question: At what point is autopilot done? In other words, when is a device just joined to AAD and managed by Intune vs having things run by autopilot? Is it when ESP completes?
- E-mail sent.
Thanks! - Haha indeed !
You're e-mail address is removed, but can i send them to your Call4Cloud email address i see on your website?
- Hi, okay so no kiosk :)… a normal autopilot … could you send them to Email address removed (together with the ime log) i have been interrested in this issue for some while but cant reproduce it on my own devices 🙂
Hi Rudy, thanks for you reply!
No i did not use the Kiosk template. It is default/custom Autopilot profile. The PC is intended for Presentation use on a big screen. So only one local user account with Powerpoint, browser, adobe reader, youtube, browser citrix login, etc. The kiosk template is too strict / locked down for the intended use.
Maybe i can export some of the logs you're interested in. How can i get them to you?
Thanks,
Corné.- Hi as you are mentioning local accounts. I am assuming autopilot self deploying kiosk or did i read it wrong 🙂
If not i would love to see some autopilot and modern deployment /device management logs Hi Dan, i'm experiencing exactly the same issue when using an Autopilot enrolled pc with only local accounts. W32-apps (which were published after the Autopilot enrollment has taken place) start installing only after i login with an AAD account.
Did you get this resolved in the mean time?- Hi Nate, I have done that setup and it does work. My scenario is a little different. There's obviously a lot of history in the thread above but basically, I am building a fairly complex digital signage player device that needs to automatically log on to an open desktop with a local account. That in itself is not so much of a problem. The problem is that there is a "deadzone" between autpilot's ESP stage and first AAD user login where Win32 apps do not get evaluated or installed. In my case, we have several win32 apps that need to be installed for the digital signage function to work. It would be possible to assign all of these win32 apps to the same security group used for the autopilot profile, which would install them during ESP but even if all the apps did install, the device would still be unmanageable from that point forward if Win32 apps are broken until an AAD user signs it.
I suppose we could require an AAD user to sign in following autopilot, as part of our device build process, to kick Win32 apps into gear but it seems like there's a bug here. - Could you follow the steps in this article and use the AutoLogon feature?
https://www.inthecloud247.com/setup-a-windows-10-kiosk-device-using-intune-and-autopilot/ - This is a kiosk type device so there won't be any users logging in to install apps on-demand. As I mentioned, I did move all of the device-based app assignments to a dynamic group that populates later so those apps can come down after ESP. I agree, it's best to limit the apps that are required during ESP and even the MS blogs mention that too. So I've tried it that way as well as requiring them during ESP.
But that's not really the problem here. The problem is that after autopilot and ESP, Win32 apps don't get installed until an AAD user signs in. This is a problem for kiosk type devices because if they don't get installed during autopilot/ESP, they'll never get installed. It's like the IME engine just shuts down after autopilot until an AAD user signs in. - There is a difference between assigning the apps to all devices and make them required in the esp (setting them as required doesn't mean no other apps will be installed)
But my recommendation (as the appps do get listed during esp... so esp is aware of them.. that's why I asked to target those apps to all devices)
Assuming those apps are device apps (and not configured as user based Install behavior) I would recommend to only set office365/onedrive as required apps in the device esp. In our environments we have some necessary powershell scripts converted to win32apps and required them during esp.
All of the other apps are assigned them as available so people could install them when they want from the company portal app... Works great.. You really don't want all apps to be installed during the device esp... You will need to ask yourself the important question.. are they really really necessary when the user logs in. OK, I assigned all my apps to "All Devices" instead of my dynamic SG and it's still the same behavior. The only thing that changed was that on the Enrollment Status Page, it showed all 10 apps and tried to install them. It installed the ones it could then didn't time out, so I hit the "continue anyway" button.
At that point, the behavior was the same; no Win32 activity at all until I logged in with an AAD account. The ADD device object is still showing the last activity time of when the device was imaged, and the Intune device object took several hours to appear in Intune. Now that I've logged in with my AAD account, the "Last Checkin" column for the device record in Intune is updating more often and Win32 apps are installing quickly.
Device Configuration Profiles and LOB apps (UWP and MSI) are working great throughout all of this. I tested this while logged in with a local account by creating a config profile to block camera and assigning a new MSI app. Both were pushed down to the device immediately after doing a sync under Accounts > Access Work or School. I did just notice that the button under Accounts > Access Work or School changed from "Managed by Autopilot" to "Connected to xxxx's Azure AD" as soon as I logged in with my Azure AD account.
After autopilot finished, I logged in as a local user to test the Win32 apps. One strange thing I noticed is that when deleting nodes under \Win32Apps from the IME section of the registry, they wouldn't be recreated after restarting the IME Windows service. The only way I can get any kind of action in the registry when logged in as a local account, is by deleting the top-level \IntuneManagementExtension node and restarting the IME service. When I do that, it does re-create the \Win32 node but nothing below it. It's as if it's not even trying to install Win32 apps. And not surprisingly, if I uninstall an app, delete the registry and restart the IME service, the Win32 app never gets installed.
When I'm logged in with an AAD account and I uninstall an app, delete the corresponding GUID folders below \Win32apps in the reg, it immediately re-creates the GUID sub-nodes under the \Win32Apps folder and installs the missing app. That works perfectly.
Seems like there's a dead zone between when Autopilot finishes and when an AAD login occurs. If the Win32 app doesn't install during ESP or you don't log in with an AAD account, the app will never get installed. I think I need to file a bug.Mornin' guys - I can give that a try but I don't think there's any issue with assignment of the autopilot profile. If I assign 10 apps to the SG that I also assign my autopilot profile to, then ESP will show 10 apps that need to be installed. It usually installs 5 or 6 of 10 then hangs indefinitely which is why I started assigning my apps to a dynamic SG that gets populated later. App installs are bound to fail sometimes so I can't hinge the whole autopilot process on 100% app success. I think there may be a separate bug I'm running into that is preventing ESP from timing out and moving on when app install failures happen. It should be 60 minutes but it'll sit forever if, for example, 5 of 10 apps install but the other 5 fail. That's why I had to enable the "continue anyway" button. But the rest of the apps don't install until an AAD account logs in. If it sits at the logon screen or if a local account logs on, the apps don't install.
I'll try assigning apps to all devices to see what happens but if I had to guess, autopilot will recognize them during ESP which is great, but it will fail on a few, I'll have to hit the "continue anyway" button and it'll be the same issue where they won't install until I log in with an AAD account.
It's really not so much of an issue with autopilot or Intune knowing what needs to be installed, it's just that IME isn't installing what is assigned. The screenshot below is what the "managed apps" section of my device looks like after sitting overnight with my local account logged in. The apps just won't go - doesn't matter if it's during autopilot/ESP or after, they just won't install until I log in with an AAD account.
Hopefully this makes sense. Even some of the autopilot blogs from MS employees recommend forcing a minimal set of apps during autopilot/ESP and letting the rest install lazily, later after autopilot completes. So I think I'm on the right track there, it's just that Win32 apps don't install unless I'm logged in with an AAD account which won't work here because this will be a kiosk device and needs to autologon with a local account.
- I echo this, using all devices and filters may be a better approach, I should have time to look at this in more detail late this afternoon
- Hi, good morning. I read the replys mentioning the dg and static groups. Just wondering... just to make sure this isn't or is your issue. What happens when configuring an app to all devices ? If the device would get the proper autopilot profile, that's step one..
OK, no apps or anything else seemed to be happening with the device logged out. I decided to log in as a local account and all I'm seeing in the IntuneManagementExtension.log is these "Failed to get AAD token" and "AAD User check is failed" errors every 1 minute.
I'll let it sit for a couple hours but I don't think any apps will be coming down to this device. Is this a bug maybe? If I don't get any apps after a couple hours, I'll try logging in with an AAD account to see if the apps come down then. I'm pretty sure they will since they have in the past.
- Thanks for that link... that's interesting. I've been waiting about 2 hours now, at the login screen, following Autopilot/ESP, for the device record to show up in Intune. I don't think it's happening until I log on. So, at that point, is it re-joining AD and re-enrolling into Intune? If so, I'll be waiting forever for these apps to install.
Am I just doing self-deployment/white glove wrong? It's starting to seem like if you want apps and policies to be assigned during Autopilot/ESP, then you need to assign them to the same SG you assigned your deployment profile to. Otherwise, they won't get configured or installed until a user logs in, which triggers AAD/Intune re-join, at which point the device record will start flowing into dynamic SGs and get any apps and policies that are assigned to SGs other than the SG used for autopilot deployment profile.
--- Update since I started writing this ---
After a reboot of the device, the device finally showed up in Intune. Not sure what that means. Maybe I need to build a reboot into the autopilot process?
All my "managed apps" now have the "Waiting for install status" in the Intune console so I guess I'll see if they ever install.
I'm wondering if maybe I need to setup a kiosk/autologon device restrictions configuration profile and assign it to the same SG that I'm assigning my deployment profile to. Then maybe the device would immediately log in after Autopilot/ESP and get these other things kicked off. - Answer to the question: It depends 🙂 https://call4cloud.nl/2021/10/willys-white-glove-wonderland/
At the first phase, the device gets azure ad joined, mdm enrolled and instantly aad unjoined... (object is created in azure)... but only at the last step (userlogin) the device will again join azure ad.
