Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Patch Management - Patching Strategy on New Built Desktops or Servers

Created: 31 Jul 2013 • Updated: 14 Aug 2013 | 12 comments
This issue has been solved. See solution.

What is the best way to patch newly built desktops or servers? What works for you guys? please share

Operating Systems:

Comments 12 CommentsJump to latest comment

HighTower's picture

For our servers we're currently using an MDT build process that hits them with Windows Updates at build time.

For our workstations we're have our Software Update Policy to run silently several times a day so machines wind up getting patched in the background and are usually complete by the time a user is ready to login.  Workstation images are updated twice a year and if there is a super-critical patch that has to get applied I'll insert a Run Script task in the sequence to command line install the update.

SaschaH's picture

You can inject(slipstream) OS patches once or twice a year into your images. We use some command line scripts to call the windows assesment scan and later on the patch cycle during the setting up of the new machines. So a computer has all software installed and is patched after around 2-3 hours. Just be aware that there is a point fix for 7.1 as there is a bug in the Patch Management when several clients try to aquire patch managment licenses.

 

Bechtle – your strong IT partner. Today and tomorrow

If that seems to help, please "Mark as Solution"

BugTastic's picture

Hi SaschaH, would it be possible to share the scripts you use for this ? I find this part of CMS very slow and frustrating when it comes to patching new machines.

Thanks

 

SaschaH's picture

Its actually quite simple. First of all if you want to implement it for new machines make sure you have the pointfix meantioned in this Tech installed. http://www.symantec.com/business/support/index?page=content&id=TECH203418

Else the clients wont get the right license information and not patch. Ugly bug that only shows if you set up several new machines at a time.

There is a Task already in Altiris called Run System Assessment Scan, use that to let the computer deliver the info on what patches it will need to Altiris. Run that quite early after Windows is installed on the machine.

Run the task Update Client Configuration on the computer. Afterwards give it some time to process on both the NS and the computer. 

Then we use a powershell script to start the actual patch cycle. We start it fire and forget style at the end of the deployment. We just spawn a process without checking the outcome as it tends to hang quite often or run long.

Start-Process -Filepath "C:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgent\AeXPatchUtil.exe" -Argumentlist "/C /Xa /q"
Start-Sleep -s 1800

So not really a lot of scripts involved.

Process looks as follows here.

Windows Setup > Install Default Apps > Run Assessment Scan > Run Configuration Update > Install Standard Software (Office..) > Run Assessment Scan again(catch Office patches) > Some Finalisation Tasks > Run Configuration Update > Start Patch Cycle

Most patches that are not blocked by others needing reboot will be installed after that.

Bechtle – your strong IT partner. Today and tomorrow

If that seems to help, please "Mark as Solution"

BugTastic's picture

OK, will try and get that pointfix, cause otherwise my best option is just connecting to MS update and downloading from there as its quicker.

sganatra's picture

We have the OS image stored on a VM with a snapshot taken just before sysprep. Every 3 months the image is rolled back, patched, snapshot then syspreped and captured.
For the patches released in between image updates, we download the updates to a central location and use dism in WinPE to inject the patches just after the ghost image is complete. The PC is then fully patched even before it boots into Windows.

Tomasz Wozniak's picture

In our cases we have 2 strategies for clients and servers.

Our clients targets are dynamic and basically all computers with exclusion for servers plus clients that are not supposed to receive the updates, are patched monthly.

We patch our computers monthly and all polices remain always enabled for clients. So when you build a new client it automatically receives all approved bulletins so far.

In regards to server the story is pretty similar. The difference is we have dedicated target 'New servers' and dedicated configuration policy. The target is added every month apart from standard servers targets. The bulletin policies again remain always active.

While deploying new server it drops into the 'New servers' target and again receives all approved bulletins in production.

You control the patching by means of dedicated configuration policies for standard servers. While configuration policy for new servers is always active.

This way you do not need to worry about injecting new updates. Also your clients always get the latest releases. This way you also avoid having superseded updates in your image.

I hope it helps someone.

Tomasz

 

 

JeanWilson's picture

Tomas, your method is exactly like mine, down to the 'New server' name, I actually call the filer 'New Server build' I do find that the policy has some bulletins that has been supersceded.  According to the local agent, is there a way around this? so that it is replaced as new patches replaces the old ones?

Tomasz Wozniak's picture

sdedg,

As 'High Tower' stated below, you need to check 'Disable all superseded software updates' and 'Enable distribution of newly added software updates' in PM import task options. The disadvantage of having this checked is that some old bullletins may get disabled after import before you manage to deploy the latest ones.

Also as stated in kb 'Once enabled; this process only affects Software Update Policies moving forward. The process is not retroactive and will not enable the advertisements for revised Software Updates prior to this setting being enabled.'

As long as understand the risk and accept it should work fine for you.

Also it is good to understand the difference between the revised software update and superseded one.

The following articles plus the attachements may help you in sorting out this.

http://www.symantec.com/docs/TECH40390

http://www.symantec.com/docs/HOWTO10963

https://www-secure.symantec.com/connect/forums/why-are-some-updates-not-enabled-policies

regards,

Tomasz

 

SOLUTION