Now that we know about the great advantages that The Patch solution provides, understand the main goals of The Patch Solution, it’s time to look at how it’s configured. Keep on reading to see how easy it is to set up and get going.

Installing The Patch Solution

To over simplify things, The Patch Solution is a collection of PowerShell scripts. You’re going to have multiple machines that you’re going to use it with. It was designed to be installed on a central file server and executed remotely from the calling system. We’ll talk more about how to do this later, but essentially a Schedule Task is used to run from a computer and load it across the network. Place The Patch Solution on the file server, edit the config file, and away you go. That being said, it works great for say 90% of the systems on your corporate environment. What about locked down environment or network segments like the DMZ? The nice thing about PowerShell is that you can copy it locally to any computer and on that computer schedule it to run! Great!

The Files

The core files that make up The Patch Solution are:

File

Purpose

PatchConfig.xml

Default Configuration File/Settings

PatchReporting.ps1

Script to send emails/report. See Blog Post The Patch Solution – Part 5 for more information

PatchSolutionUpdateGPO.ps1

Updates the GPO for Scheduled Tasks

PatchFunctions.ps1

Shared code between the other scripts

InstallUpdates.ps1

Main script that is called to install updates

 

The two files that we’ve talked about so far in previous posts are the first two. The configuration file and the Patch Reporting. The configuration file

File Share

As mentioned above, I prefer to install this on a corporate file server. If you have a dedicated windows machine, this is how I go about creating the share. When the script is executed across the network, it is smart enough to load any helper files from that directory too. Also by default it will look for the configuration file in the directory where the script is located, and not the directory of in which the script was invoked.

First off I create a directory. The files themselves are small, but every time you run the report, by default it will create an excel output file. If you let this thing run for years, you could run out of drive space, but I highly doubt it. In any case after running this in production at some client sites for over 5 years, this has never been an issue!

  1. Create a directory:
PowerShell -Command "New-Item -Type Directory C:\PatchSolution"
  1. Share the directory

This is a straight forward Windows share, but it’s locked down so that only the service account that runs the scheduled task has access and the computer accounts. No funny business here. If you want to give help desk users access to it, add them into the mix. Also, change the CORP in the example below to your domain.

PowerShell -Command "New-SmbShare -Name WSUS -Path C:\PatchSolution -FullAccess 'corp\Domain Admins','corp\svc_WSUS' -ReadAccess 'SYSTEM','corp\Domain Computers','corp\Domain Controllers' -Description 'The Patch Solution'"

Locally Installed

If you decide not to put this on a file server, and/or require it to be installed locally on a single system, by all means go ahead. For each machine where you need to run it locally you would have to:

  1. Create a directory
  2. Copy all of the files into it
  3. Edit the configuration file
  4. Manually create scheduled tasks of when to run it

This could get cumbersome to do and maintain. The configuration file is where all the maintenance windows are stored. Anytime the maintenance windows are updated within your company, you’ll have to edit each of these configuration files. My recommendation is that for each network segment, try to find a computer where you can run it from a file share and decrease the number of machines where you have to have a local install/configuration file.

Advertisements