How to deploy Powershell App Deployment Toolkit with Workspace ONE

Update June 23, 2020 – PSADT is now a fully supported feature in UEM so the below steps are deprecated. Check out my new post explaining how to use the feature.

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 9 Comments

  1. Aissa IRMOULI

    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. Brooks Peppin

      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. Salina

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

    1. Brooks Peppin

      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. Joël Brunner

    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. Brooks Peppin

      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.

  4. Angela Lacy

    Hi, Brooks

    Can we use this tool for applications installed in the Device context?

    Thanks!

  5. Ken

    ditto Can this be installed using the SYSTEM context and perhaps a silent mandatory installation? Anyone?

    1. Brooks Peppin

      Ken – Yes, PSADT can be deployed in a fully silent way but I’m not sure I see the value in doing that. If you are doing that, then you don’t need really PSADT unless you need one of the functions they have. Just deploy the app (via MSI or EXE or basic script) if doing as SYSTEM. PSADT is designed to have a user interface and the only way to see that popup is in user context.

Leave a Reply