This video shows how to create a Windows Patch Catalog. Patch Catalogs store Patch Vendor metadata, and are the source of information used for analysis, downloading patch payloads, and deployment. The next video after this one will show Patch Analysis.
Here's the script from this video (underlined text is not spoken, included for reference):
Hi, I'm Sean Berry, and I work with BMC Server Automation.
I'm here today to talk about setting up basic Windows Patching.
The general case behind patching is simple: as problems are found, or new features are built, the vendor builds patches to deliver these fixes to customers.
All patch vendors publish some kind of information that basically says that a given patch is needed based on operating system or application version or existing patches.
Patch analysis is the process of figuring out which systems need which patches.
Remediation is delivering those fixes to the operating system or application.
We call this information the patching metadata, because it tells us information about the patch: specifically where the patch applies. In BladeLogic, this metadata is stored in the Patch Catalog. In this video, we'll build a Patch Catalog, and in the next, we'll use a Patching Job to measure which patches should apply to a given host.
Let's look at our development instance. In the Depot workspace, if we've run blcontent, we'll have some sample Patch Catalogs we can look at later.
Since we want to learn a bit, let's create a new Catalog. Go to the "Workspaces" folder, create a Compliance Folder, open that folder, create a "Patch" folder, right-click there and create new Windows Patch Catalog.
Let's call the catalog "Windows 2008 Patch Catalog".
We'll select "Source From Vendor", aka Online Mode, which will download the patch metadata and payloads from Microsoft and Shavlik. Offline mode is useful when, for whatever reason, BladeLogic doesn't have internet access.
A helper server is useful if our App Server is not on Windows: this gives us a place to run the tools that open and process the metadata. I'll browse to a folder on the Windows App Server.
The other important part here is the Repository Location: this is where patch metadata and payloads will be stored. I usually create a "patch" folder within the fileserver data store. I've already created that directory in Windows Explorer. Under that directory, I create a "Windows" folder. I then use that directory in the Patch Catalog's "Repository Location".
We're going to skip RBAC Policy for right now, and specify a filter that will include all Windows Server 2008 Patches. Note that there are a range of other patches available, including Windows 2003, SQL Server, and a host of other applications. Once we've selected Windows Server 2008, click Next.
Updating the Patch Catalog is fairly important: if there's a problem, someone's going to want to know about it. Here's where you put the email address of the person who will look at this if there's a problem. Click next.
Ok, I want to get some data into this patch catalog, so I click "Execute Job Now". I also want this catalog to update every week, so I'm going to schedule it to update Tuesday evenings at 5PM. You may want to use a different time, day, or even update less often.
To check on the status of our Patch CAtalog update, open the catalog, and browse to the "Results" tab. Click on the "running man" to see job detail like we would with any other job. Right click on the current run and select "show log" to see detailed information. It will take a few minutes to pull down the information the first time.
To see which hot fixes have been downloaded, expand the Windows Patch CAtalog, right click on Hotfixes, and select "Group Explorer View", this will give a list of the hot fixes available in this patch catalog in the bottom right window.
Ok, so we now have a serviceable Patch Catalog: in the next video, we'll use it to measure our servers for patch compliance.