Deploy Java Runtime Environment as SCCM application using PSADT

This guide will show you how to deploy Java Runtime Environment (both 32- and 64-bit) via SCCM with user interaction using PSADT. The app will do the following:

  • Prompt user to close Java apps
  • Uninstall previous JRE(s)
  • Install both 32- and 64-bit JRE
  • Disable update notifications

Get the files

Get latest offline executable JRE installers, as well as latest PSADT (3.70 as of writing). Also, get ServiceUI.exe (32-bit) from MDT if your SCCM version is less than 1802.
Copy both installers to the PSADT Files directory. Next, let’s modify Deploy-Application.ps1.

Install Script

Variable declaration
Let’s start by declaring some global variables. Specifically check that $appVersion is current. In general take model of following:


Pretty straightforward. If user is running java app, allow closing of app, or deferral. Also show installation progress.
As part of the installation, we remove previous versions of Java.


In the install phase, let’s set install parameters to e.g. disable Java auto-updates.
Lastly, for all .exe installers in the Files directory, execute them. This shall install both 32-bit and 64-bit Java.


Not much here. If Java was running in the beginning, show a prompt to user to inform of successful update.


Basically copy the pre-install commands, i.e. Show-InstallationWelcome,Show-InstallationProgress and Remove-MSIApplications.

Application in SCCM

For SCCM => 1802:
Create application as you normally do. For deployment type, select Script Installer.
For installation program command, use Deploy-Application.exe.
For uninstallation program command, use Deploy-Application.exe Uninstall.
For User Experience, choose “Whether user logged on or not” and check “Allow users to view and interact”.

For SCCM < 1802:

Create application as you normally do. For deployment type, select Script Installer.
For installation program command, use ServiceUI.exe Deploy-Application.exe.
For uninstallation program command, use ServiceUI.exe Deploy-Application.exe Uninstall.
Lastly, check to run in 32-bit. For User Experience, choose “Whether user logged on or not”.

Detection method

Use the following for detection method, please check that you have correct version declared.

That’s it.

Deploy FileMaker Pro 16 as SCCM application using PSADT

This guide will show you how to create a FileMaker Pro 16 SCCM application with user interaction using PSADT. The app will do the following:

  • Install FM Pro 16 with latest patch.
  • Apply licensing information.
  • Set default remote server.
  • Optionally remove previous FM Pro versions.

Get the files

Get latest FM Pro installer and patch, as well as latest PSADT (3.70 as of writing). Also, get ServiceUI.exe (32-bit) from MDT if your SCCM version is less than 1802.

Run the Installer, but cancel it. The installer will have created a subfolder called “FileMaker Pro 16”. Inside, copy contents of the Files folder into PSADT Files folder.

Next, do the same thing with the latest updater. Copy the .msp file into PSADT Files folder.

Installation script

Fill out the default application variables in the beginning of Deploy-Application.ps1.

Here’s the pre-install step. Mostly self-explanatory but I explain some things.
First, we declare variables. Shared variables (both install and uninstall) are the application name and process name.
For installation, we get currently installed application information. Later on, if previous installation exist, we only need to patch.
Most important is the $addParams variable. Include here your FileMaker license information.
For $FMserver variable, insert address of your FileMaker server. This will later be set as the default server when user opens the app.
Under pre-installation tasks, in this case we remove previous FileMaker Pro 14 installation. Modify as needed.

Next up, install step.

Basically two-liner. If there is no previous installation, perform full install. If there exists previous version, then the patch is all we need.

Post-installation step. Here we declare registry entries, which includes default remote server and skips “getting started”. Then we apply these registry entries to all users. Lastly, display popup for successful installation.

Uninstall step is a one-liner.

Create application in SCCM

Create application as you normally do. For deployment type, select Script Installer.
For installation program command, use ServiceUI.exe Deploy-Application.exe.
For uninstallation program command, use ServiceUI.exe Deploy-Application.exe Uninstall.
Lastly, check to run in 32-bit.

UPDATE: As of SCCM 1802, you no longer need ServiceUI for user interaction, instead, check the box to allow user interaction in the user experience tab. You may also uncheck the 32-bit installation process, to allow native 64-bit.

Detection method

Remember to check correct version.

Lastly, you may deploy the app. You may set it to run as whether user is logged on or not.
Remember to test thoroughly before deploying to production.

Updating Lenovo ThinkPad/ThinkCentre BIOS as SCCM application

Updating BIOS is no easy task. You probably have several models with differing BIOS versions. Also, the update requires a restart making it difficult to deploy without interrupting work. In this case, user interaction is recommended if a user happens to be logged on during deployment. This is where PSADT comes in to play.

Goal of this guide is to help you create a repository of Lenovo BIOS updates and automate updates using a single application in SCCM. User interaction is made possible by PSADT.
This repository may also be used during OSD. I’ll show this in an upcoming post.

Disclaimer: This has been tested on L/T/X series ThinkPads for *30-*70 generation. For ThinkCentres we only have M900. So adjust and test accordingly.

Getting latest BIOS
An easy way to get the latest BIOS is to download it from Lenovo. Let’s take a ThinkPad L460 as an example. The URL for downloads is: Here you can find the BIOS section. You want to download the BIOS update utility pack. For other models, you can easily modify the URL.

After download, extract the update (run the .exe to extract, but don’t run utility afterwards) to a folder with the model name, in this case a folder named L460. Do this for all your models.

Next, create a .txt file called biosversions.txt. Here, create tab delimited headers ‘Model’ and ‘Version’. Then enter all your models and the latest BIOS version you downloaded. As such:

Model Version
L530 2.67
L450 1.25
M900 7FA
X1 Carbon 6th 1.15

Later on, we’ll use this text file in conjunction with our detection method. Here’s a template if you want: biosversions.txt

You may have noticed the differing versioning for ThinkCentre M900. For some reason Lenovo doesn’t use conventional version numbers for ThinkCentre, but instead hexadecimal(?). The complete version number for M900 is FWKT7FA. The FWKT characters are constant, but the three last characters change between versions, and the version is ascending in hexadecimal value if you watch the changelog from previous version.

Folder structure/placement
As mentioned, we’ll use PSADT for this setup.
So, copy all the folders for the models under the PSADT Files folder. Also copy biosversions.txt to the root of the PSADT folder. Finally, get a copy of 32-bit ServiceUI.exe from MDT and place it in the root folder (this allows for user interaction in “Whether user logged on or not” scenario).


Inside the files folder:

Disregard SCCM-UpdateBIOS.ps1 and ServiceUI64.exe until the next blog post…

Make the contents of the PSADT and subfolder readable and executable for Domain Computers on a server. In our case, we keep it on the SCCM server. We do this so the client doesn’t need to download all BIOS updates. The script will see to it that the client only copies the applicable update. If you want to perform BIOS updates in WinPE during OSD (wait for next post!), you should give read/execute permissions to the Everyone group. Additionally, for anonymous access (WinPE), you need some more tweaking, see this guide:

Installation script
Here’s the code for the pre-install phase, i.e. insert the code under pre-install phase in Deploy-Application.ps1.
In a nutshell, check for AC power and show prompt if anyone is logged on.

Here’s for the installation phase (thanks for bug report from /u/davidnait over on reddit):

And lastly, post-install phase. Note that ThinkCentres require a shutdown.

Full Deploy-Application.ps1 here:

Create application in SCCM
Create application as you normally do. For deployment type, select Script Installer.
Leave content empty.
For installation program command, use ServiceUI.exe Deploy-Application.exe in conjunction with Installation start in containing the path to the location of the contents. Lastly, check to run in 32-bit.

Detection method
Next up, detection method. Use custom script of type PowerShell. Remember the temporary registry key from the script? Here we’ll check for it and remove it.
Make sure you have the correct network location for the biosversions.txt file.

Lastly, you may deploy the app. You may set it to run as whether user is logged on or not. This will allow automatic updating of BIOS if PC is on, but no user logged on. Wake-on-LAN is to recommend in this scenario.

Remember to test thoroughly before deploying to production.

PSADT interaction in an SCCM task sequence

PSADT is a great toolkit. I use it for all our SCCM applications and packages. In fact, the toolkit is installed as a module on all systems through GPO. The cmdlets it provides are excellent (Get-InstalledApplication and
Invoke-HKCURegistrySettingsForAllUsers being personal favorites). PSADT is so great, there’ll be many posts in the future containing it.

Anyway, this post is about PSADT in a task sequence. This need was born out of the need to perform an organization wide Windows 7 to 10 upgrade using a SCCM TS. TS’s are out-of-the-box without any sort of interactivity, but with PSADT and ServiceUI.exe magic we can make it happen.
So, using the upgrade scenario as an example, what we want is:

1. Have the upgrade available to users in software center, so they can install it at their own leisure
2. After a certain date, make the deployment required.

Required task sequences are tricky. You can make people easily angry with that kind of stuff. So, a deferral option has to be in there. What else? Well, pre-flight checks in general would be. We want to check that user has power connected, as well as wired network connection, for starters.

PSADT has a deferral system. In a script, specifically in the Show-InstallationWelcome cmdlet, you can specify how many times a user is allowed to defer. After the user has deferred the allotted times, the prompt will be inescapable. Lovely!

So, on to the PSADT script. You may have the code in either the pre-installation or installation section of Deploy-Application.ps1. Doesn’t really matter since we’re just running PoSH code, not doing any installation.

Let’s start with pre-flight checks. Let’s assume first that AC is plugged, if the system has a battery, we’ll actually check it, by using WMI.

Network connections. Let’s check for a wired connection as well as wireless. In our case, we don’t want to allow upgrades over VPN. Depending on VPN, you may need to modify so the variable suits your environment. Included WMI query checks for Palo Alto GlobalProtect.

Next, let’s invoke TS environment to the $TSEnv variable.

Here we set TS error dialog timeout to one second. Doesn’t look cool if the user defers and they still have an error dialog for 20 minutes…

For clear visibility of our PSADT prompt, let’s close the TS progress UI, but only if a user is logged on. $usersLoggedOn is a PSADT built-in variable.

Now, if a user is on VPN, we’ll inform the user to come to the office for the upgrade. Then, we exit with code 60012 (PSADT deferral code).

If AC power is not available, let’s inform that the user has to plug it in for the upgrade to continue. There’s also an option to defer to run the upgrade at another time.
To accomplish this, I believe it’s best to use a While loop.

Let’s do the same thing for Ethernet.

Lastly, if both Ethernet and Wifi is enabled, let’s disconnect from the Wifi network.

If all checks out, let’s inform the user of the pending upgrade, and allow deferral. Let’s also prompt for the closing of applications. We can do this with the Show-InstallationWelcome cmdlet.
If you want custom text in this cmdlet, you need to edit AppDeployToolkitConfig.xml inside the respective language tag, as well as set -CustomText to true in the command. Like this:

And that’s pretty much the script. Of course, consider this a template and modify to your needs. Please comment if you have some handy additions!

Now, to include this in a task sequence, you’ll want to include it as the first step. For user interaction you need to provide ServiceUI.exe in the package (Get it from MDT).
Finally, the command line will be:

Interaction will look like this:

That’s all for now!

SCCM OSD with multiple disks

OSD with systems that have multiple disks can be troublesome. Out of the box, SCCM TS steps don’t offer much in regards to this. You can make Format Drive steps for each disk, but there is no immediate way to identify which disk is which!
Even going into BIOS to check which disk is on which channel won’t help. At each boot, Windows may interpret the disk channels differently:

BUT, all hope is not lost. SCCM has a TS variable named OSDDiskIndex. The docs ( describe it as “Specifies the physical disk number to be partitioned.”. Hm, specify it how? Well, basically you find the number ID of the disk you want to specify for formatting, and you give that number to the OSDDiskIndex variable. How do we do this? You guessed it, with Powershell of course!

Since Server 2012/Windows 8, there exists the cmdlet Get-PhysicalDisk. You’d think it’d be a part of Powershell 3.0 for Windows 7/2008 R2, but for some reason the storage modules were not included in that ( I don’t know if it’s included in PS 4.0 and higher. But don’t fret, I will show how to accomplish the same thing with a WMI query.


Get-PhysicalDisk is a nice cmdlet. It gives all the relevant information you could wish for from a disk. For OSD, you probably want to differentiate disks on two criteria, SSD/HDD and size.
Getting disk type is easy. The MediaType property of a disk object from the cmdlet describes if the disk is an SSD or HDD. Size is decribed in the… size property! What else do we want? Oh, right the most important one, the ID! This is in DeviceID property.
Output example:

So, in a two disk scenario, where one disk is SSD and you want to select it, the command is as simple as

This will give us the ID of the disk that is an SSD.
Defining on size basis is easy as well (300GB):

For combination of size and SSD:


This is all fine and dandy if you’re on at least Win8/2012/PE4.0 (or possibly Powershell 4.0 or higher on Win7/2008), but what if you’re not? Good old WMI it is then! Here’s the last example in WMI:

Basically, we use Win32_DiskDrive WMI class to get disk info. Sadly, there is no definite property in WMI that will tell if disk is SSD or not… But in my experience, all SSDs have “SSD” in the model name, so we’ll have to make do with that. Lastly, the ID of the disk is in the Index property.

So now we should know how to find the disk we want to partition. Next, let’s pass this information to the SCCM TS variable OSDDiskIndex, so the TS partition step will select the disk we want!

I find using Run Command Line TS step, with powershell.exe with the Command argument is the easiest way to run one-liners.

In the one-liner, we simply give the OSDDiskIndex variable the ID of the disk.

Of course, if you want to use WMI, replace the second portion of the command argument with the WMI equivalent.

When you run this, that disk will now be selected for later partitioning step.

Capturing SCCM TS logs – The PowerShell way

Ever had a task sequence fail? Wouldn’t it be nice to view the logs from a central location? Then this is the tutorial for you.

There are several posts out there how to capture logs, but they’re all a bit cumbersome for my tastes… involving several additional steps in your task sequences and relying on CMD commands (yuck!).

Here’s how to do it all in a single PowerShell script.


As you probably know, when a task sequence fails it stops and usually show you this a countdown like this:

So, instead of just stopping when a failure occurs, how do we force the TS to proceed to copy logs instead? Answer lies in taking advantage of the “Continue on error” TS step property:

By nesting the TS under one group, checking its “Continue on error” property and lastly setting the capture log step last in the TS, we make sure logs will always be copied, regardless of outcome.

Now for the script.

The script

For the impatient and experienced, you can skip further down for the full script. Verbose description follows:

First we need to initialize the task sequence environment to an object stored in a variable called $TSEnv.

Next, let’s store the computer name in the variable $TSComputerName

If OSDComputerName doesn’t exist, we will use _SMSTSMachineName instead.

Let’s set the TS logpath to a variable.

Now for more involved stuff. For a good organization of your TS logs, it’s preferable to sort them by Success and Failure. How do we determine if a TS was either? The self-explanatory boolean _SMSTSLastActionSucceeded variable tells us! If it’s false, the last step was a failure, if true, all’s ok.

So, our IF statement, in case of TS failure:

For better visibility of our later custom error message, it’s best close the TS progress bar. We do this by invoking the TSProgressUI object and calling its CloseProgressDialog method.

At this point, let’s set the central log location we want to write the logs to. We’ll use the computer name as the last folder.

Let’s remove old logs for this model, recursively, forcefully and without error (in case previous logs don’t exist).

Let’s then copy the logs!

Finally, let’s display an error message using WshShell popup method! This method has some possibilities. In this example, we display a popup that will say that an error occurred, log location and prompt the user if the want to shut down the system or continue (and exit the TS). You can read about the syntax more here:

Start by creating a WshShell object and setting it to the $WshShell variable.

Create popup. Insert your text as in the example.

It will look like this.

A useful pop-up for once.

Again, I recommend you read the documentation if you want do make further customization to the prompt.

For the next step, we process the input to the prompt. The docs state, an answer of Yes equals Return value of 6, 7 for No. In this case, we only need to do something if the user chose to shut down the system.
Since shutdown.exe is not provided in WinPE, we have to use the command Wpeutil ShutDown instead. As for full OS, we use shutdown.exe, but we use it through the SMSTSPostAction variable instead. SMTSPostAction is basically an optional command line that is run after a TS ends, after TS environment is closed. In this case it’s preferable to shut down that way, ensuring that the TS environment does not end abruptly, possibly causing the client to be stuck in provisioning mode (a hassle!).

That’s it for the failure scenario! Next, let’s get dressed for success. Basically we just copy the logs, pretty much like in the failure scenario.
Also, if you want to set a SMSTSPostAction, you can do it here. In this case we have a restart.

Full script

Apply script in TS

Now it’s time to put the script in the TS. Due to SCCM task sequences being executed in Session 0 and user console session being in Session 1, we need some assistance to move execution of the script to the user session to show the prompt.
Enter ServiceUI.exe. ServiceUI.exe is an executable found in MDT (Microsoft Deployment Toolkit) and its purpose is to break out processes from Session 0 into Session 1. You can find the executable in an installed MDT instance. Insert ServiceUI.exe in the same folder as the script.

Anonymous access to network share

For the script to work in both full OS and PE, you need to have the log folders to allow Anonymous write access. To avoid packages, you can also insert the script into a folder where Anonymous has read access.
Here’s a fine guide written by Vitorio Delage how to accomplish this:

Script in TS

Finally, insert a “Run command line” step as the last one in the TS. The command line should be:

In the “Start in:” field, add the location of the script. Also check to Disable 64-bit redirection, no need for that.

That’s it!

Hello world! Introduction etc.

Hi there. This marks the beginning of a blog that I hope will be helpful to others (and myself!). The contents will be mostly SCCM/ConfigMgr related material. But occasionally I might write on something related to MDT (Microsoft Deployment Toolkit), PowerShell, Group Policy, etc. All material will be somehow related to deployment in a Windows environment.

A little about myself. Currently I’m working on finishing my CS studies (Bachelor) as well as working on the side as an IT technician for a non-profit. At my job I’m mostly responsible of our workstation infrastructure, taking care of deployment of applications, operating systems, you name it. In addition of having passion for my job, I like to play racket sports as well as play drums on my freetime (whatever there’s left of it!).