Forum Discussion

DanWheeler's avatar
DanWheeler
Brass Contributor
Mar 07, 2022

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...
Intune
cdgier's avatar
cdgier
Copper Contributor
Apr 12, 2022
I've resolved this issue by reinstalling the PC with the original Dell W10 image (Boot from Dell OS Recovery USB key). When i did that and after installation upgraded to Windows 11 manually (Windows 11 installation assistant) the W32 apps deployed succesfully.
The previous install (where it did'nt work) was a clean Windows 11 ISO installation.
Another thing i noticed when installed with the clean W11 installation was that de AutoPilot profile computername did not apply. The default Windows computername (DESKTOPxxxxx) was applied.
When installed with the Dell W10 installation the computername which i configured in the AutoPilot profile was succesfully applied.

I don't know exactly what caused this two problems (computername and w32-apps) when using the clean Windows 11 installation. But as a workaround i reinstalled the PC's with de Dell W10 installation to get things working as expected.
Rudy_Ooms_MVP's avatar
Rudy_Ooms_MVP
MVP
Apr 12, 2022

cdgier 

 

i am hearing all kinds of issues when using win11 and autopilot. (Still waiting to get my hands on a problem device) 

 

as example. When using wufb (targetted at devices) windows 11 could skip the whole installation and will trigger a reboot. Because some bug with the insider build settings is set to not configured it will still try to apply it.

  • DanWheeler's avatar
    DanWheeler
    Brass Contributor
    May 24, 2022

    For anyone else running into this issue, I'm having some luck with Win32 apps installing for local users with this CSP/OMA-URI:

     

    OMA-URI: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
    Data type: Boolean
    Value: True

     

    I'm actively experimenting with it now, but it seems to solve the problem. I'm trying to figure out how and where to configure my Intune application that configures autologon. I'm finding that during ESP may be a bad place to set up autologon with the typical reg keys because the Autopilot/ESP phase uses those same registry keys. I think it may either be overwriting my reg key settings or not allowing them because I get stuck in a reboot loop when I force my autologon app to install during ESP and have it exit with a 1641 for a forced reboot. ESP just keeps looping over and over again.

     

    The whole idea here is to get through autopilot, auto log on as a local account then install Win32 apps. The problem is that the autologon needs to be a win32 app... I don't know how else to do it. There's an Intune configuration profile specifically intended for building kiosk devices but those put the device into kiosk mode with a locked down desktop and start menu. I need full desktop access.

     

    Maybe I can find the CSPs that the Kiosk configuration profile is using and implement a select few of them to just do the autologon parts but not the desktop lockdown. I assume config profiles are using CSPs under the hood.

     

    • Mark_Destreel's avatar
      Mark_Destreel
      Copper Contributor
      Apr 04, 2024

      DanWheeler 

      Great find.

      Implemented SkipUserStatusPage and sure enough Win32 apps started installing again, without logging on.

      • Pete_Maudlin's avatar
        Pete_Maudlin
        Copper Contributor
        Apr 16, 2024

        Mark_Destreel 

        This entire blog was very helpful. However, Microsoft changed how "Required Apps" are discovered and install during ESP, with the March 2024 update to Intune. They added the option in the ESP, under Blocked Applications, called "Only fail selected blocking apps in technician phase".

         

        If you create a new ESP, this option is set to Yes. All preexisting ESP will have this set to No.

         

        When set to Yes, what is means is that the ESP will now scan for all apps set to required for the device and will attempt to install all of them during the device configuration portion of provisioning. Those that are in the Blocked Apps, will fail the ESP if it doesn't install properly. That that are outside of the Blocked Apps, will be ignored if they fail.

         

        So how does this help install all required apps when pre-provisioning only, while only installing the Blocked Apps for all other provisioned devices? Great question. What we discovered worked well was to:

         

        1. Leave your main ESP with the setting mentioned above, set to No.

        2. Create a new ESP (Autopilot Pre-Provisioning) and add one application (probably VPN) to the Blocked Apps and then set the option mentioned above to Yes. Note, you may want to set the timeout to say 180 minutes.

        3. Assign the Pre-Provisioning ESP to a Dynamic Group that is based on Group Tag.

        4. Then just go to Enrollment | Devices in Intune, find the device via SN and set the Group Tag to whatever string your decided on for the dynamic group. (I.E. "PreProv")

        5. You will then see the Group Tag show on the device in Autopilot and the SN show as a member of the group you created.

        6. Follow the steps to Pre-Provision your device and you will see the list of applications found be much larger and start processing through the list it found.

         

        To clean up the group, either manually or automate the removal of the Group Tag under Enrollment | Devices.

         

        Dynamic Group Syntax:

         

        (device.devicePhysicalIds -any (_ -eq "[OrderID]:PreProv"))

         

        I hope that helps! It made it much easier for us to separate those that we wanted to just install a few apps during ESP and hand off vs. those that we call hot swap devices with everything already installed.