Forum Discussion
Intune and PSADT v4.x
I have a reboot package PSADT and the first dialog give the user the choice to defer the install, and a Scheduled Task is created to run an hour later.
I am returning a 1618 (retry) and inside the PSADT, If Intune runs the app again, it will check my reg key for the defer and check that the task is active and hasn't run, and will exit without any interaction to the user and exit with another 1618. I am not an Intune admin and wondered if there are some downsides to trying this type of package in Intune. The defer time is the unknown for me and I am not sure how many times Intune will try to reinstall the reboot package within the deferred hour, and what Intune will do after the 3rd try...which I think is the max retries it might attempt in an hour? Any suggestions for a change in the exit codes or script interaction with Intune? Thanks.
2 Replies
Rather than using the PSADT user interaction features, my recommendation would be for you to configure your package to exit with code 1641 (hard reboot), enable the "Restart grace period" on the deployment and configure the grace period settings per your requirements, as documented at https://learn.microsoft.com/en-us/intune/app-management/deployment/win32#set-win32-app-availability-and-notifications.
Your package is using exit code 1618 as a planned one-hour deferral, but Intune interprets a Retry code as a short transient installation failure. For a Win32 app, the Intune Management Extension retries a Retry return code three times, waiting five minutes between attempts, so the scheduled task will still be pending and those retries will be consumed well before the hour ends. Reserve 1618 for a genuine installer-busy condition. If installation completed and only a restart is pending, return the code you mapped as Soft reboot, normally 3010. If the user is truly deferring installation, use one PSADT deferral path and a distinct custom code whose Intune mapping and detection logic reflect that state; do not have Intune and an independent scheduled task compete to own the install. Test Required and Available assignments separately, and confirm the detection rule changes only after the package has actually completed.
