Starting with the October 2011 Release Candidate, two new activities for installing and uninstalling Windows applications will be available in the Runbook - Powershell category of the workflow activity picker. The Install Windows App and Uninstall Windows App activities will help you automate tasks like pushing new version of software out to your users, provisioning new systems with standardized configurations, and removing rogue installs of unauthorized software. Let's take a quick tour of them.
Uninstall Windows App
I'm going to start with the Uninstall activity. Its dead simple to use, so we might as well just get it out of the way. As the name promises, the activity will run an unattended uninstall of a Windows app on a remote target. It only needs 2 parameters, the ip address of the target machine, and the name of the software being uninstalled. This name must exactly match the name that is listed in the Add/Remove Programs control panel.
Pretty easy, right? Of course, you would probably want to set the the IP address and/or application name from workflow input variables in order to make your Runbook more flexible. All inputs on both these activities allow script expressions, so that's not a problem. You could do something like: ${workflow.inputs.u_targetIP} for your hostname, or even ${workflow.scratchpad.programs[0].appName} for the Program name.
Install Windows App
This activity works similarly to the Uninstall, but with a few wrinkles. You need to pass it the ip of the target you want the app installed on, the path to the installer, the name of the installer .msi file, and a space-delimited list of parameters that should be passed to the installer. That's our first wrinkle. You will need to track down the command-line parameters for any values or options that you need the install to use. Not too bad a wrinkle, more like a faint crease. Here's an example that installs our Winzip package.
Note that we're setting the INSTALLDIR and ADDDESKTOPICON parameters for the installer.
The other interesting thing in that screenshot is that we're accessing the install package via a UNC path. The permissions and credentialing that allow that to happen are not as straightforward as you may think. Under the covers, when Powershell opens that package, it has to do a Kerberos double hop. That can be a complex subject, but to make a long story short1, if you have a fairly standard AD implementation, you should just have to mark the target's computer account as Trusted For Delegation. You can do that manually from the AD Users and Computers management app. Find the right account, right-click and go to properties, then select "Trust this computer for delegation to any service (Kerberos)" and apply the change.
"Wait a minute!" you say. "That's a real PITA!.2 I don't want to have to do that for every target I need to install this app on." Runbook automation can come to your rescue here also. Look for a future post on how to use the Run Powershell activity to turn on the delegation trusting before your install, and then turn it back off after.
OK, there's one final caveat. The trust delegation will only work if your MID server, install target, and the UNC fileshare are all in the same AD domain. I've heard rumors that its possible to make it work across domains with some fancy AD footwork. If anyone is interested, I can hunker down with one of our AD experts and work out the details on making that work.
1If blindly changing security settings makes you nervous and you want the long story about Kerberos double hops, I recommend the Understanding Kerberos Double Hop post from the MS Directory Services team blog. They also have a couple good entries on troubleshooting Kerberos authentication in case you run into problems.
2(P)ain (I)n (T)he (A)$$
3 Comments
