Geek of all TradesHow to Install Non-Microsoft Patches Using System Center Essentials

Greg Shields

Contents

Custom Catalogs
Dynamic Groups
Executing Executables
Sounds of Silence
SCE's Double Power

Earlier this year, I had the great pleasure of offering my first session at Tech·Ed, the annual Microsoft conference for IT pros. That presentation, "Best Practices in Architecting & Implementing WSUS," was surprisingly well-attended. I was even more surprised by the number of people who are still struggling with building an effective patch-management infrastructure. More than two dozen attendees stopped me after the session to ask specific questions or bounce around ideas. (If you missed this session at Tech·Ed, you can stream it on demand from the TechEd online site.)

In my opinion, WSUS—Windows Server Update Services—is a beautifully designed solution that scales across organizations small and large. Companies with 50 machines can use it as effectively as those with 50,000. The new WSUS guidance from Microsoft further extends its applicability through the creation of Internet-facing WSUS servers. The result is an always-connected approach to managing updates across even your mobile work force.

Of the many questions I fielded outside Room 515B, one in particular came up repeatedly: "I know I can install Microsoft patches with WSUS, but how do I use it to install patches from other vendors as well?"

My response, unfortunately, was: "Realistically, you don't."

That's because WSUS is a solution primarily designed for managing and deploying Microsoft patches. Its ease of use stems in many ways from the fact that Microsoft owns the updates. Think for a minute about all the different non-Microsoft updates your environment potentially needs: WinZip, Adobe Acrobat, Java Runtime, ACT!. These, like pretty much any other piece of software, require patching from time to time. Unless your environment consists of only Microsoft software, which I highly doubt, WSUS by itself won't meet all your needs for patching these other third-party applications.

The good news: A different class of Microsoft management software is designed for exactly that purpose. You've probably heard of Microsoft System Center Configuration Manager and System Center Operations Manager (likely through this very magazine). These two platforms work together in larger environments to manage machine configurations as well as to monitor and provide alerts about their behaviors. The platforms are great tools for system administrators who need to get a handle on centrally controlling their environments.

But you're a jack-of-all-trades IT professional, most likely in a small or midsize business (SMB) environment. Such large-scale management and monitoring tools aren't in your budget, nor are they scoped for your needs. You need smaller tools for smaller uses. That's where the Microsoft SMB-friendly System Center Essentials (SCE) platform comes in. SCE combines a specially extended functionality of Windows Server Update Services with the monitoring power of Operations Manager in an easy-to-use package specifically designed for small environments.

Custom Catalogs

One area where SCE provides great power is in the automated distribution of software. That software can be anything from a completely new installation to an update for an application that's already in place. Focusing on software updates, SCE incorporates multiple mechanisms for finding, configuring and ultimately deploying such patches to computers on your network.

The first such mechanism is through the use of downloadable update catalogs. These compilations of update metadata can be downloaded directly from Microsoft. They contain information on patches from third-party vendors such as Dell, Citrix, HP, Intel and 1E.

For example, consider a situation where you need to update the software for your environment's Citrix servers. Perhaps in this case you wish to update your servers with a hot-fix rollup package developed and released by Citrix. You could do that by downloading the update from Citrix's Web site and manually installing it to all your servers. But with more than one server in your farm, automating that procedure will greatly speed up the process.

To do this with SCE, start by navigating to the Updates view and clicking the link marked Import Updates From Partner Catalogs. Clicking through the first screens takes you to selection labeled Choose Catalog to Import, shown in Figure 1.

Figure 1 System Center Essentials Update Catalog Import Wizard (Click the image for a larger view)

You'll see a small number of partner companies available in the drop-down list. If you select the catalog marked Citrix Systems Inc. – Citrix Hotfix Catalog and click Next, you'll see the updates that Citrix currently makes available to Microsoft for SCE distribution. (At this writing, only a few updates are available.) Selecting an update and clicking Import will initiate a download to your SCE server. Once it's imported, right-click the update and select Approve to approve the update for installation to selected computer groups.

Dynamic Groups

SCE groups computers together in ways that are slightly different than WSUS—and dramatically more powerful. SCE can first create a group by manually adding computers to a specified group. This is done from the Computers view by clicking the link to Create a Computer Group. Creating static groups this way is great for short-term uses, but over time, group membership changes. So what's needed is a dynamic way to populate groups based on the characteristics of the computers being managed. SCE provides this through its Operations Manager roots. To create a managed computer group with a dynamic membership, navigate first to the Authoring view and choose Create a New Group. On the following screen, give the group a name and select the destination management pack to store its information. Click Next twice to skip past the selection for adding explicit group members—that would result in the same sort of static membership you're trying to avoid—and click the Create/Edit Rules button on the Dynamic Inclusion Rules screen.

The resulting screen is a query builder that provides a whiteboard for creating rich formulas that define the computers that should be part of the group. If you want to limit your group to just Domain Controllers, you can do that. Want to focus just on laptops, or machines with a particular configuration? Those membership rules are similarly configurable. The expressions available in this screen are based on the management packs you've added to your server. So if you're looking for more rules, consider adding new Management Packs for additional functionality.

By creating dynamic groups instead of static ones, you can be sure that updates are deployed to the right computers, even as your network changes over time.

Executing Executables

You'll quickly notice that the Microsoft partner update catalog is far from complete in terms of covering the entire spectrum of software available today. At this writing, it supports updates from only five vendors. For updates not in the catalog, you don't have that immediate and super-automatic deployment infrastructure. So to deploy those updates, you need to do a bit more work.

First, think about the process of manually installing an update to a computer. You probably start the process by double-clicking the installation file. This file may have an .EXE, .MSI or other extension. In any of those cases, double-clicking the installation file launches a process that begins the software's installation. Your next steps usually involve answering any questions that are prompted by the installer before it begins its work.

Remember that a software installation's executable is functionally similar to any other process you might launch on a system. Thus, from the system's perspective, launching one .EXE is really the same as launching any other.

With that in mind, there's also a behavior that's intrinsic to every automated installation platform currently available. Tools such as SCE effectively automate the double-click of an executable across the computers in your infrastructure. When you use SCE to "automatically install" a piece of software, what that tool actually does is launch the software's setup file locally on each configured computer. That setup file can be a piece of software's setup.exe or setup.msi, or it could be a different executable entirely.

For example, you could use SCE to launch "ipconfig.exe /renew". SCE would simply instruct each of its clients to run that executable with the /renew switch at some configured time. In a way, SCE already does this for you when you navigate to the Computers view and highlight one of the computers under management. Look at the far right side of the screen in Figure 2. There you'll see numerous Windows tasks that can be run on those computers. As with a software or update installation, SCE's role in running those tasks is essentially to launch them locally on that computer.

Figure 2 SCE’s Windows Computer Tasks Screen (Click the image for a larger view)

Sounds of Silence

What's critically different between a manual software installation and one that's automated through a tool such as SCE is the presence of you, the administrator. In a manual installation, you hang around after launching the setup file to answer questions asked by the installation routine. Once any questions are answered, the installer goes through its job of actually installing the software. However, when SCE remotely launches the installer's executable, you're not there to answer the installer's questions.

That means that for any installation of a custom update—or, really, any software—you must find a way to pre-answer those questions on the installation's behalf. The process for doing this goes by many names, but is generally referred to as making the software "install silently". For MSI and MSP installations done through SCE, this process is usually straightforward. Native to the Microsoft Installer format are the necessary switches to install that software silently. When you import an MSI installation into SCE, the console interrogates that installation and determines how to install the software silently. This usually involves little extra effort.

For example, let's assume you're attempting to upgrade your installation of the third-party software App123 to version 2.3. Assume that this update can be downloaded from App123's Web site and arrives as a file named App123_Update_2.3.msi. Because this software update arrives as an .MSI, SCE's packager can automatically determine its silent switches directly. You would do this in the SCE console by navigating to the Updates view and clicking the link for Create New Update. In the resulting wizard, you would enter the path to the package setup file. Depending on how the package was created, the package name may automatically populate with the correct information. If not, you'd enter a unique name and description for the package. The result would look similar to Figure 3.

Figure 3 SCE’s New Update Wizard (Click the image for a larger view)

Obviously, directly installing software this way means it will install only with the defaults. For most software and update installations, there are additional configurations that you want to ensure are included in the install. SCE enables you to do this on the next screen by specifying MSI property values in the format PROPERTY=VALUE. Unlike the silent switches, these values aren't standardized across all MSIs; instead, they're specific to the software or update you wish to install. Finding these values usually involves a bit of sleuthing on the vendor's Web site.

Another excellent clearinghouse of installation customizations for many common software packages and updates is at the IT community site. There you can search for the software or update you wish to install and learn more about the customizations possible within its MSI.

This process with other installation types—such as those with an .EXE extension—uses the same process but requires more work. Unlike with MSIs, there is no common framework across all .EXE-based installations. That means that any .EXE installation requires additional research to find the silent switches as well as any customizations. Silent switches for .EXE files may be /q, /quiet, /s, or any number of switch combinations that were originally baked into the .EXE package by its developer. While some commonality among packagers is prevalent in many .EXE-based installations, it's safer to assume that dealing with .EXEs will be a painful process. As before, searching through the vendor's Web site or AppDeploy.com is a great way to start finding the exact syntax for a silent and customized installation.

Be aware, too, that some .EXE-based installations are little more than wrappers for an .MSI-based installation under the covers. You've seen these before when an installation routine starts by unpacking itself, usually to your computer's %temp% folder. Because the unpacked .MSI is dramatically easier to work with than its .EXE wrapper, consider cheating the process through this little trick: First, double-click the .EXE file and allow it to unpack. When the first installation screen appears, leave it open and navigate to your computer's %temp% location. Dig around to find the software's more user-friendly .MSI file buried within its folder structure. Copy that .MSI file, as well as any additional files and folders that are necessary for the installation, to a different location, and then cancel the original .EXE-based installation. Then integrate your newly-acquired .MSI into SCE for a quick package creation.

SCE's Double Power

Software and update installation represent only half System Center Essentials' power. We haven't been able to focus on the other piece: SCE's Operations Manager-based monitoring roots. This integration inexpensively provides a much greater vision into your network's inner workings. Discover more by looking at SCE's Monitoring view. Once it's connected to the servers or workstations in your infrastructure, you'll quickly find out where you have problems—some of which you probably never realized you had.

Microsoft offers several different ways to download a test drive of SCE. If you're a TechNet Plus subscriber, you can download a full installation as one of your membership benefits. Microsoft also provides a preconfigured VHD online that enables you to quickly spin up an evaluation instance that works with your own domain.

If you don't want to impact your existing network or build up the evaluation network needed to correctly test it, Microsoft also offers a System Center Essentials virtual test lab that provides 90 minutes on an actual fully configured VM so that you can try out the software and work through a lab guide. For more information on the virtual lab, visit the TechNet Virtual Lab.

Greg Shields, MVP, is a partner at Concentrated Technology. Get more of Greg's Geek-of-All-Trades tips and tricks at ConcentratedTech.com.