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

This Post Has 6 Comments

  1. Hello,

    I have tried App Deployment to import packages into WorkspaceOne and it’s working fine.
    Is there a way to see the real version of the application (the .MSI version) ?
    Because, when you upload application inside a .zip file, the displayed version of that application on the console or on the catalog shows the .zip file version only (example : version = 1.0.0 for the first import).

    Thank you for your help

    1. Unfortunately not at this time for exe or zip files. However, I know that the product team is aware and hopefully will be adding support for custom file versions soon.

  2. Since the uninstall command is n/a. How can we uninstall it from WS1?

    1. This is the one trade off at the moment until true app deferral can come in the platform. One of the customers I worked with developed a custom method inside of PSADT that accounts for rollback and doesn’t do a true uninstall. It’s fairly complicated but if you are interested and good with powershell I might be able to send it over. App deferral is coming in the platform soon the last I heard from product group.

  3. Hi everyone
    First of all: Call the Powershell ‘Deploy-Applicatio.ps1’ instead of the EXE version. In there you can edit the install and uninstall command directly and it works pretty smooth with wsONE.

    => Open the Deploy-Application.ps1 in an editor of your choice and look for the customizable section starting around line 109. You’ll find PreInstallation / Installation / PostInstallation / PreUninstallation / Uninstallation and a PostUninstallation section (we use only the Installation and Uninstallation sections).

    In every section you will find a comment like this ‘## ‘
    Right below you add your installation command. For example if you want to install FileZilla with EXE installer you call:
    Execute-Process -Path “$dirFiles\FileZilla_3.45.1_win64-setup.exe” -Parameters “/S /user=all /D=$env:ProgramFiles\FileZilla”

    NOTE: If you use a MSI Installer, the call looks a bit different from the one above. For extense documentation on all possible commands simply start the ‘AppDeployToolkitHelp.ps1’ in the Toolkit subfolder ‘AppDeployToolkit’. There all commands are fairly presented in a nice helper format.

    Back to the script: ‘$dirFiles’ refers to the directory inside your ZIP (usually Files). With’-Parameters’ you pass on the arguments given by the installer. For FileZilla ‘/S’ is for silent installation, ‘/user=all’ let it be installed for every user on the device and ‘/D’ passes on the installation directory, where ‘$env:ProgramFiles’ simply calls the environment variable in PowerShell for the application installation directory on the device.

    For UnInstallation search for the section’UNINSTALLATION’ and look for the comment ‘## ‘ again.
    Again we insert the appropriate uninstallcommand for our purpose. For FileZilla this looks like this:
    Execute-Process -Path “$env:ProgramFiles\FileZilla\uninstall.exe” -Parameters “/S”

    Please note, that different apps ship with different uninstallers. Take your time and check the documentation of your app on how to best call the uninstaller.

    OK, that’s the scripting part. Now archive everything like Brook told you to. Open your wsONE console, open the app and enter the following in the “Install-Command” field: powershell -executionpolicy bypass -file Deploy-Application.ps1 install
    and that in the Uninstall-field: powershell -executionpolicy bypass -file Deploy-Application.ps1 uninstall

    DONE. Save and test.

    It took me a bit in the first place as well, but the PowerShell Script is well commented and when you get it running, you’ll see how easy everything just falls into place. Just take your time and experiment. It’s well worth the time 😉

    1. Thanks Joel for the additional info for those who are less familiar with PSADT. Keep in mind though that calling Deploy-Application.exe does actually call the Deploy-Application.ps1 powershell script so it’s a simpler way of running it.

Leave a Reply