MSI Patching with SMS

Recently I was working on a rather fustrating and somewhat boring project that involved getting the latest office patches to 12,000 machines. You'd think with SMS, ORK and MBSA that this would be easy, but I found I actually had alot of work ahead of me.

This will be a very long post if I go into great detail so I'm going to try to stay high level. The design I finally settled on works like this:

1) An MBSA OfficeScan occurs where a machine is scanned for Office vunerabilites. The data is placed into WMI and replicates up through SMS as discovery data.

2) A collection of machines is automatically refreshed based on a WQL query that says I want resources where one of these products is installed and one of these patches are applicable.

3) An advertisement for the machines in that collection runs a custom application I wrote called PatchManager.

4) PatchManager begins by triggering the SMS MSI Source agent. If a local DP has the source bits of an installed product code, MSI adds it as an available source list.

5) PatchManager then queries the SMS site database to find out if any other distribution points serve as remote DP for the subnet the client is located on. If one is found it is checked to see if the source files are on it and if so WindowsInstaller is called to add that location as a source location.

6) Next we manually fire an MBSA Office Scan to make sure we have the most current data in WMI.

7) Now we start walking through an INI file looking to see if patches are needed. For each patch we query WMI to see if the patch is needed. If so, we call MSIEXEC to install the patch. If the patch needs source files it goes out to the DPs to get them.

8) After each patch is applied we do another MBSA office scan to get new data in WMI. This is because Microsoft annoyingly doesnt report patches as applicable until prerequisite patches are applied.

Eventually all the patches are applied. The next night the process starts all over again. Because no patches are applicable the machine falls out of the collection and doesn't receive the advertisement again until a new patch is added to the patch manager.

Chris's rant about Repackaging

Someone on Community suggested that I should make this a sticky. I can't, so I'll put it on my blog instead:

I remember busting out laughing when I read some guy post here a couple months ago that he just got AdminStudio and now he wanted to try Office 2003 as his first install.Seriously, depsite InstallShields attempts to offer repackaging as a seamless solution for Systems Administrators, repackaging is VERY difficult to do correctly. Basically every time someone throws you a new install to repackage you have to reverse engineer. The repackager is pretty good, but it only goes so far in capturing the "setup intent". It takes years of development work and writing installs to really understand deeply what's going on in someone elses installs. You need to be fluent in every aspecto f windows from Win32 API Base to registry, C programming, VB/VBScript, .Net, application isolation, OLE through ComPlus, so on and so on. You need to know pretty much every SDK Microsoft has out there. ODBC/JET/ADO/SQL. Oracle, Sybase, Informix, MFC, ATL, PowerBuidler, Delphi, JRE.... the list just goes on and on cause you never know what technology some install might use. Do you really want to be the guy that just runs the repackager and trusts that it did it right? Well it SEEMS to work. LOL [SIC]Most of my installs normally go way beyond what the original install did into the territory of what the original install SHOULD have done. There are very few of us. Most guys do such a bad job that many people FEAR repackaging.

Avaya OutlookReserver

Recently I did an install for a product from Avaya called OutlookReserver. It's a neat little Outlook AddIn that allows conference calls on an enterprise bridgeline to be scheduled just like any other Outlook meeting request. Unfortunatly the install the vendor provided was far from desirable. Administrator privledges were required to install the application and an interactive utility needed to be ran for each users profile to establish a form in their calendar. After doing some research I found out that this really must be done through the client and could not be done through a back side exchange server process. My design came together and I realized to make this an Hard Core Setup I had to solve two problems. First was to find a way to automate the interactive utility, second was a way to impersonate interactive user while running my install as SYSTEM through SMS2003. First I'll discuss automation of the form publish.

Outlook supports automation through MAPI. With all the versions of Office out there we want to use late binding. Basically we just observe what the interactive utility is accomplishing and reverse engineer it. We also find out that by only doing what we need to do we can eliminate the annoying security alert popups from Outlook. A simplistic prototype looks something like this:

Set Outlook=CreateObject("Outlook.Application")
Set NameSpace = Outlook.GetNamespace("MAPI")
Set Folder = NameSpace.GetDefaultFolder( 9 )
Set Item = Outlook.CreateItemFromTemplate("confcall.oft")
Set Form = Item.FormDescription
Form.Name = "Conference Call"
Form.PublishForm 3 , Folder
Item.Close 1

So we put this in a VB6 project, compile the EXE and slap it into the install. We also give it some logic to know if it's ever ran before and put it in the Run Key for AllUsers.

Now on to the second problem: We push silently as system. This is the case even if the interactive user goes to Control Panel Advertised Programs and manually runs the advertisement. I can't just simply put the EXE in a Custom Action, it would run as SYSTEM. So what we do is compile an ActiveX EXE in VB6. It's simply a wrapper for the Run command that gets exposed as a DCOM server. Why DCOM instead of COM? Because by making it a DCOM server I can configure it to run as the Interactive User instead of the Launching User. I build it as a merge module ( so that I can reuse it in future installs ) and add it to the redistributables of my project. Then I just place a VBScript custom action in my project that looks something like this:

set oCoMsiHelper = CreateObject("coMsiHelper.Shell")
oCoMsiHelper.RunAsLoggedOnUser "publish.exe", Session.Property("INSTALLDIR"), 1
set oCoMsiHelper = nothing

Bingo! The merge module installs and configures my DCOM server to run as the Interactive User then my custom action comes by at the end and publishes the form silently for the user. Hard Core Setup Engineering has occurred. The user is spared from having to do any manual steps. From his perspective, it just works.

What Is Hard Core Setup Engineering?

Hard Core Setup Engineering is the combination of the mindset that anything can and WILL be automated while preserving the long time principal of BulletProof Installs. After all any good setup package must accomplish two basic things: Install the product perfectly every time and be brain dead simple for the user to use. A poorly written package will be cursed while a wonderfully written one will be taken for granted. Sadly setup engineers are usually looked down at by their fellow developers. This kind of work is often seen as boring and unimportant - a minor necessary evil to be accomplished just before deployment. Very few developers understand how much a product can be improved when the integrated environment - including the setup package - is considered early on in the design phase of the application.

Welcome To Hard Core Setup Engineering

Welcome to my newly created blog. I've never had much to say on the Internet, but I realized how useful blogging with RSS was when I started keeping up on Robmen's blog. Over the last year I've tried to stay fairly active on the InstallShield Community website. My goal has always been to help developers learn new concepts, the second was to push myself to learn new concepts by exposing myself to other peoples problems. Problems that I might not have ever come across in my own day to day work. Today I'd like to start something new. I want to try to create a site where myself ( any maybe soon others ) can publish articles that go way beyond the typical newbiew "how do I" discussions. A site where we inspire people to get hard core with Software Engineering. I