Forum Discussion
Deploying Win32 Apps that use scripts to install - first install takes forever
I am trying to deploy some apps that use scripts packed in the intunewin package and deployed to Company Portal as Win32 apps. So far I use both .cmd and .ps1 script files, and at deployment to Intune these script files are called as the Install and Uninstall commands. My problem is that the first attempt to Install these apps through Company Portal takes forever to install, usually sitting in the "download pending... your device is syncing" stage for well over 30 minutes. However, once that first install completes, and thankfully it usually completes successfully, any subsequent app install that uses a script installer finishes with a much more appropriate speed where it is not sitting at "download pending" for a more than 1-2 minutes.
- The IME log does not have anything jumping out (TBH I don't really know what to look for though). Based on this article IME | Troubleshooting failed Intune Win32App installation it does not even look like any of the Win32 install steps begin until the long "download pending" cycle ends
- We also have both MS Store and Win32 apps that are straight up MSIs or EXEs. None of these exhibit the same first run "download pending" delay. This is only happening on the intunewin-wrapped installs that call a script to install the application.
- As mentioned before, this is exclusively a problem for the first time a script based application attempts to install from Company portal. Subsequent installers with scripts proceed without the excessive "download pending" delay.
Can anyone help me figure what is causing this excessive "Download Pending" delay when installing Win32 apps that use a bundled script to install? Thanks!
klenTAHNthanks for those pointers. #1 certainly sounds like it might play into the issue - I'm surprised it doesn't seem to be more common of a problem if that's the case. Would love to know if there's a way to confirm that in the logs and/or speed it up. I do use the syntax in your #2 examples too.
Rudy_Ooms_MVPyes, it only happens the first time, and only when a script (CMD or powershell) is called for the install - all other scripts run without the long wait no matter how long after the first install or reboot. I can certainly access the appworkload log - could not find the company portal log (or it's logged under a different log file name/location and I'm not aware).
Our default Delivery Optimization policy sets our end-user PCs to "HTTP only, no peering (0)" mode for updates and to restrict download bandwidth (foreground and background) usage during business hours. I am also playing with a few endpoints that use the DO settings recommended here. So far, I haven't noticed a difference in that first endpoint script execution time under either policy.
Depending on the situation (new device vs existing) as well as your Intune configuration, i've found a couple of things:
- Once every 8 hours or so, the IME does a full roll of scripts/remediations/software installs, etc. Depending on how much you have in Intune, this can take a while. If the device is new and hasn't completed this initial run, that wait can feel pretty significant (40min plus depending on connectivity).
- Make sure your install command is properly configured. just having the filename in the install field can cause Intune to take forever to install and often fail.
- PowerShell
- powershell.exe -executionpolicy bypass -file "filename.ps1"
- batch/cmd
- cmd.exe /c "filename.bat/cmd"
- PowerShell
If neither of those are the issue, I'd look at the connectivity level of your environment. If you have updates coming in from WUfB or you have Delivery Optimization turned off, either can cause a larger load on your network.
Hi... just wondering... but does this only happens once and from there on it works as expected (no 30 minute delay) or does it return once the device has rebooted? Do you have access to the appworkload log and the company portal log (user appdata)
Also how did you configured the delivery optimization settings in the app: Content download in foreground or in the background
