Forum Discussion
Intune Doesn't Install Win32 Apps Until a User Logs On?
Hi, I'm using autopilot in self-deployment mode to provision devices. I have about 10 apps assigned to a dynamic security group that contains my devices. I have ESP configured to allow the user to "C...
Please let me know the outcome 🙂 you could also reach out on twitter if removing the msi didnt solve your issue
OK, I was able to uninstall a Win32 app while logged in as a local user, then restart the IME service and it did re-install the app. So, I think this means Win32 app install is not completely broken for local user accounts if at all.
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?
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?