This is part 2 of a series on user experience.  Click here for Part 1

I know. I know. User interaction is typically a big no no when it comes to deployments. The less the user knows, the less opportunity there is for something to happen that you didn’t see in testing. It’s the reason tools like SCCM were created in the first place!  In a perfect world we would be able to do our job without interacting with the user aside from friendly water cooler banter about how the local sportsball team won the big game.

Sometimes it’s like a suicidal raccoon running out in front of your car - simply unavoidable.

So how do you effectively interact with the user when deploying software?  In SCCM 2012 it is a much easier task than it was in SCCM 2007 - so I’m going to detail both processes.

SCCM 2007 / SCCM 2012 Packages Since 2007 proved to be the most challenging for me to get right, where the application ran with administrative rights but still notified the user inside the user context, we’re going to cover this first.  SCCM 2012 Packages (not applications) work in a very similar fashion.

The first thing(s) you will need are the PSTools from Microsoft available here.  Inside this package you will find PSExec.exe which we will be primarily focused on.  The next thing you will need is some sort of executable that will communicate with the user.  This could be a compiled custom AutoIt script or the PowerShell App Deployment Toolkit* or something else entirely, the important thing is that you have something.  Finally, you need the rest of your application to be packaged.

*NOTE: If you choose to use the PowerShell App Deployment toolkit, the need for using psexec is removed and you can follow their guide on usage of that application.  We’ll cover its use in a later blog post.  This post is more or less geared towards people who want to send completely custom communication.

When creating your package, normally you will call setup directly from the program created in the SCCM package.  Sometimes, you might choose to point to a script to execute - in this case we will need to point to some sort of script.  For our example we’ll use the script option.

In the root of your package source folder, add PSExec.exe, the user notification executable, and a batch script called install.cmd.  PSExec is required because when SCCM 2007 executes the command, it is running as the SYSTEM user - and the user notification will also end up in that session.  PSExec allows you to redirect the notification to the user session.  Inside this batch script you’ll need the following line at the beginning:

For those of you unaware “%~dp0” is a batch variable pointing to the location of the batch script.  If the batch script was located in c:\windows\ccmcache\b4\install.cmd, “%~dp0” would equal “c:\windows\ccmcache\b4".  This way you can reference the location of the EXEs/MSIs inside of your package source folder.

Now, when creating the program for your package, use the following command line: “install.cmd”

Under the environment tab, ensure that “Allow users to interact with this program” is checked.  NOTE: Under the “Program can run:” drop down - unless your user interaction has some sort of timer on it, you will need to run it “Only when a user is logged on” - otherwise the user notification will never dismiss and the application will not install.

And that’s it!  You can deploy the application as you would normally, and it will present a user notification in the user context, and continue to install the application with administrative rights.

SCCM 2012 Applications In 2012 applications although it doesn’t require the use of PSExec, I’ve only been able to notify the users when the “Only when a user is logged on” is selected for the logon requirement. This is because the “Allow users to view and interact with the program installation” is only available when this option is selected.

In a similar fashion to the 2007 method, you will create an “install.cmd” file and add the path to the user notification executable at the beginning:

Since SCCM 2012 does a better job of executing things with system permissions but still inside the user session you don’t have to use PSExec to notify the user.

Now, when creating the deployment type for your application, use the following “Installation program:” - “install.cmd”

Do your normal detection methods, deploy the application as you normally would, and that’s it!

Summary User interaction might be a no no, but it’s still possible.  While easier solutions exist as long as you don’t mind having less control over the notification display, this guide was provided to get you started with your own custom user interaction pieces.  We make use of these steps quite frequently in our organization to make sure our users stay happy, and we have yet to introduce critical issues in our patching and upgrading.  Next week we’ll talk about building your own user notification with AutoIT.  The following Wednesday we’ll talk about the PSAppDeploy Toolkit.

Thanks for reading and happy admining!