Automate Application creation in ConfigMgr with Powershell

Automate Application creation in ConfigMgr with Powershell

In my previous post i wrote about a convoluted way of hiding credentials whereever possible when working with Task Sequences. Fortunately, this entire solution became obsolete when Microsoft decided to offer to mask sensitive data in a Task Sequence with a mere checkbox. First in the 1804 preview, then in release with 1806.

This time, i’d like to share something that is a little less situational. It’s a Powershell script to create Applications and (almost) everything with it. There are plenty similar scripts around on Technet or so, so you may wonder: what makes this one so different? Honestly, probably not that much. If anything, it would be its flexibility and ease of use as you can basically go through it with just a few mouse clicks. It evolved from simply automating repetitive tasks to a handy tool that I use at pretty much all my customers.

 

What does it do:

Depending on the specified parameters it will;

  • Create an Application in an optional specific folder within the ConfigMgr console.
  • Create either a script-based or MSI-based Deployment Type for that Application, including its Detection rule.
  • Create an AD Group with a Prefix based on your naming-convention.
  • Link this Group to an ‘All Apps’ Group, so an admin or device in this group has access to all created apps in one go.
  • Create either a User or Device Collection in an optional specific folder within the ConfigMgr console.
  • Create a Membership rule for said Collection based on the AD Group created earlier.

Once executed (without any parameters), it will load the required modules and prompt you to browse to an installation file.
If you select an MSI file and you have an icon file in your source folder, the script will do everything else. If there’s no icon file; it will ask you to select one. Though you can cancel the prompt and ConfigMgr will use the rather ugly default icon.
If you select a .cmd or .ps1 file, the script will prompt you for an uninstall file and a detection script file. And again an optional extra prompt for an icon file.

 

What doesn’t it do:

It does not create Deployments. When i get around to it i’ll probably add a switch for that too. But since in most cases deployments need to be tested first, so far I’ve always preferred to create these manually.

It has no option to remove stuff. I may or may not integrate that into this script. For now, automating cleanup is something for a future blog post 🙂

 

Requirements:

  • you have your content share set up in a specific way:
    \\server\share\folder\AppVendor\AppName\Version\Bitness(Optional)
    This is needed because the script will fill in several fields such as Manufacturer, Name and Version based on this folder structure. This is then also used to create AD Groups and/or Collection name.
  • you have the ConfigMgr Cmdlets available or installed,
  • you have the AD Cmdlets available or installed,
  • you prepare your (script-based) Application properly.
    In most cases, all you’ll need is an install, uninstall and detection script. For MSI-based installers you have the option to specify arguments or let the script handle everything for you.
    Ideally, you also have an icon file present that is, at the time of writing, no larger than 250x250px.

For example, you could have the following files;

install.cmd:
Calling Setup.exe with some silent parameter from the same folder as the batch file:

 

uninstall.cmd:
Calling Setup.exe with some silent parameter from the same folder as the batch file:

 

detect.ps1:
Most properly built installers will write their application info to this location so that it shows up in Add/Remove Programs in Windows. So its fairly reliable to detect a successful installation. You can make your detection as complex as you want. Just make sure the script ends with an exitcode 0 and non-error string. We only return a True and no False (or any other string), as doing so would be picked up by ConfigMgr as a failure.  See this documentation over at Microsoft for valid return values.

Note that 32-bit software on a 64-bit system will redirect to HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall’.

 

The script:

For ease of use, you may want to check some parameter defaults and edit them to match your environment. Most notably the AppPath and GroupOU parameters.


If you have any questions or comments, i’d be happy to hear them.