How to deploy Powershell App Deployment Toolkit with Workspace ONE

Powershell App Deployment Toolkit is an awesome open source tool that enables all kinds of features when deploying apps with the main one being a user-interactive UI that allows for app install deferral. I’ll walk through how to deploy this with Workspace ONE and some of the adjustments you’ll need to make in your environment to make this work.

Create the App

  1. In your PS ADT folder, select all of the content and send to zip.

    NOTE: Don’t select the top-level parent folder and zip that as it will create an additional sub-folder underneath
  2. Upload the zip file to Workspace ONE as an app (Devices > Apps & Books > Applications > Native > Add Application)
  3. Configure as follows on each tab:
    1. Details Tab
      1. Fill out metadata as needed
      2. For “Supported architecture”: Setting to 32 bit will support both 32 and 64 bit. Setting to 64bit will be 64bit only.
    2. Files Tab
      1. App Uninstall Process
        1. Custom Script Type: Input
        2. Uninstall Command: N/A
          NOTE: For now leave it as N/A as you will need add custom code to PS ADT to support this rollback behavior. When a user clicks “Defer” it will run this uninstall command. So to prevent an interactive uninstall and the removal of deferral history, leave this blank.
    3. Deployment Options Tab
      1. How to Install
        1. Install Context: User
        2. Install Command: Deploy-Application.exe
        3. Admin Privileges: Yes
        4. Device Restart: Do Not Restart
        5. Retry Count: 0 (more on why we set this to 0 later)
        6. Retry Interval: 0 (more on why we set this to 0 later)
        7. Install Timeout: Can leave default or set higher if desired
        8. Installer Reboot Exit Code: Leave Blank
        9. Installer Success Exit Code: Leave Blank
      2. When to call Install Complete
        1. Fill out as you need (generally use “App Exists” if the app makes a proper GUID registration.) Can use this powershell command to find it:
          get-wmiobject Win32_Product | sort name | Format-Table IdentifyingNumber, Name, LocalPackage -AutoSize

The reason we set Retry Count and Retry Interval to 0 is that the built in Software Distribution client (SFD) only has a max retry interval of 10 minutes. Because we need a longer deferral interval we need the server side to initiate it. So essentially we’re doing only one try on client and then retrying one day later as the 2nd attempt.

Change Server Settings

  1. On the server side, there is built-in retry logic to automatically retry failed app installs. This is located under All Settings > Installation > Performance tuning. If you are a SaaS customer, you will need to submit a SaaS ops ticket.
  2. The two settings we are interested in are:
    1. Failed Application Install Retry Interval (minutes) > set to 1440 (for 1 day)
    2. Max retry attempts for failed app install (Windows) > set to max of 8 (days)

Expected Behavior

I’ll use my Google Chrome PSADT app as a test to walk through the behavior.

  1. I assigned the app to my smart group as an “on demand” app for testing. On demand apps must be triggered manually from device details page in the console or from the catalog.
  2. App downloads and runs. The Install window pops up:
  3. When I click “Defer”, I see a toast notification in the bottom right saying the app install did not complete. I double-check the PSADT registry to ensure the deferral count is tracked.
  4. The app will “fail” in WS1 and get queued up on the server for re-processing per the changes you made above. When I look at the Workspace ONE app registry, I can see the app failed final detection and has a “LastStatusCode” of 0x40000901.
  5. The detailed log is stored in the “LastDeploymentLog” registry key, so copy paste it into notepad to see it in a more readable format.
  6. You can see that since it failed final detection, the SFD agent runs a rollback to ensure everything it tried to do it is cleaned up. However, since we put bogus info into the uninstall command windows as “n/a”, nothing actually happened.
  7. The next day around the same time, the app should automatically re-run and repeat this process until installed and/or the server limits are hit.

While this isn’t a perfect solution for PS ADT, it does get the job done until “official support” can be added into Workspace ONE. For more info on software distribution with Workspace One, check out some of these articles:

Basics of win32 app deployment

Tips and Troubleshooting

Tips and Tricks

Leave a Reply