How to deploy a PowerShell script with Workspace ONE

There are two ways to deploy a powershell script with Workspace ONE. One is via an area called “Product Provisioning”. This is very similar to “Packages” in SCCM. The other is with the standard “Apps and Books” section (aka Software Distribution). Each method has its strengths and weaknesses and should be used accordingly.

Method 1 – Product Provisioning

Pros:

  • Very simple way to deploy a basic script with some files
  • No “detection criteria” to worry about – simply fire it off. It will succeed/fail based on the exit code of the script.
  • Can deploy multiple files without having to zip
  • Works in parallel to Software Distribution
  • I’ve found it to work best for scripts that do configuration during initial enrollment

Cons

  • Difficult to do version control
  • To update files already deployed to a device, you have to send a delete command first and then update (hence why this method is best suited for initial enrollment)

Steps

  1. First, navigate to Devices –> Staging & Provisioning –> Components –> Files/Actions.
    Then click the “Add Files/Actions” button at the top.
  2. Select “Windows”, then “Windows Desktop”.
  3. Fill out the Name and Description. Verify you have the correct Organization Group (OG) in the “Managed by” field.
    ​In my example, I have a script to disable UAC.
  4. Click the “Files” tab and the top and then “Add Files”.
  5. Browse for your PowerShell script.
  6. Fill out the download path where you want the script to be downloaded to on the client.
  7. Click Save.
  8. Now click on the “Manifest” tab and click “Add Action” to configure the actual command to run the script.
    .
    Complete the following:

    • Action(s) to Perform: Run
    • Execution Context: System
    • Command Line and Arguments to run: Enter full path to Powershell script configured in previous step. No need to add any “powershell -executionbypass” commands in front of the file as the Product Provisioning engine automatically runs in bypass mode.
    • TimeOut: Configure as needed.
  9. Add optional “Uninstall Manifest”
  10. Once you added the necessary files and manifests, click Save.
  11. Now, we need to create a “Product” that will be associated with this Files/Action item.
  12. Go up to “Product List View” and click on “Add Product”.
  13. Select “Windows” and then “Windows Desktop”.
  14. Fill the “General Tab” with the appropriate information. Select or create a smart group in the “Assigned Groups” area.
  15. Click on “Manifest” tab, and then “Add”.
  16. Under “Actions to Perform” select “Install Files / Actions”
  17. Under “Files/Actions” select your previous created item. Mine is called “Disable-UAC”.
  18. You can configure additional download or install conditions in the “Conditions” tab. You can modify the deployment schedule in the “Deployment” tab. And you can also add any dependencies in the “Dependencies” tab. For now, I”m leaving all three of these default.
  19. Once ready, click “Activate” to view final device assignment list. If everything looks good click “Activate” again to send down the script.

Method 2 – Apps & Books (Software Distribution)

Pros:

  • Gives you full lifecyle control over apps and scripts. You can add new versions, remove old, report on install status etc.
  • Will be published to Workspace ONE catalog if you have vIDM
  • A lot more control over the commands to run and install criteria
  • Can be used to export as PPKG as part of Factory Provisioning

Cons:

  • Takes a little bit longer to setup as there are more fields required (not too bad once you get used to it)
  • If you have apps set to auto deploy, updating a new version will also automatically deploy to those same smart groups

This method is probably most commonly used in conjuction with doing a software install, but driven by a PowerShell script. However, you can “just” deploy a script with this method, but it is more work as there are more fields you have to configure and fill out. I’ll show you how using the same “Disable-UAC” script used in the first example.

  1. Create a folder with your script and corresponding files in it
  2. The Software Distribution engine (SFD) expects an msi or exe file inside of the zip file we will make later. If you are only deploying a script you will either need to include a small EXE or MSI that won’t be used, or simply create a text file and call it “dummy.exe”. 
  3. Select both of these files, right click then Send To –> Compressed (zipped) Folder. NOTE: Don’t go up a level and do this on the parent folder as it will make an additional and necessary sub-folder inside your zip file.
  4. In the Workspace ONE console, browse to Apps & Books –> Applications –> Native. Then click “Add Application”
  5. Click on the “Upload” button and select your zip file.
  6. Click “Save” to upload.
  7. Select correct Organizational Group and then click “Continue”.
  8. On the “Details” tab, fill out the necessary fields. I generally fill out these ones:
    – Name (update the name)
    – Supported Processor Architecture (64bit)
    – Change log (add info and put my username so other admins know who uploaded)
    – Put in Description detailing what this does
  9. Click on “Files” tab
  10. The App Uninstall Process section toward the bottom must be filled out. If you don’t care or need an uninstall command, simply type in dummy text. Note that if you don’t fill this out, this app (or script) will permanently remain on the device even if un-enrolled or enterprise wiped. You can also upload a custom script that does the uninstall.
  11. Click on “Deployment Options” tab.
  12. The first section called “When to Install” (ask Data Contingencies) sets minimum system requirements in order for this to install. One good example would be for OEM type. You can specify a registry key that corresponds to the correct OEM vendor.
  13. Next, the “How to Install” section is the important bit. Select “Device” context, input the Install command, and say “Yes” for admin privileges. This is a sample powershell command:
    powershell -executionpolicy bypass -nologo -NoProfile -WindowStyle Hidden -file “Disable-UAC.ps1”
  14. I also recommend setting the “Install Timeout” to 1-5 min so that if it does fail, it doesn’t take forever to report (default 60 min)
  15. And finally, you must fill out the “When to Install Complete” section by telling the SFD engine how to know when this is finished. Click on “Add”.
  16. You have a number of options:
    1. App Exists/App Does not exist – SFD will do an app GUID lookup from win32_product. Here’s a quick script you can run on the client to get GUIDs
      get-wmiobject Win32_Product | sort name | FormatTable IdentifyingNumber, Name, LocalPackageAutoSize
      {AC76BA86-7AD7-1033-7B44-AC0F074E4100}
    2. File Exists/Does not exists – Probably the easiest of the list to configure. I often set this to a log file that gets created when the script runs successfully.
      C:\VMware_IT\Logs\Disable-UAC.log
    3. Registry Exists/Does not exists – Look at a registry key to determine success. Make sure you use HKLM instead of the full HKEY_LOCAL_MACHINE.
  17. Once you’ve added your detection criteria, click on “Images” tab to upload a icon (optional). Make sure you upload in the “Icon” section and not “Mobile Images”.
  18. Click “Save & Assign” to deploy.

Leave a Reply