Video Screencast Help

Moving from WSUS to Altiris for Patching

Created: 03 Jul 2013 • Updated: 25 Jul 2013 | 10 comments
This issue has been solved. See solution.

Hi, I am looking for some suggestions in planning a move from WSUS to Altiris 7.1 for patching. I work in a 24 hour environment. The solution needs to automate workstation install on the 3rd Wednesday 3:00am every month, like WSUS does. However, there needs to be room for exceptions as well. The patches are downloaded to each server using WSUS but not installed as we need to schedule these with the application owners who own and run these servers. Often there needs to be a maintenance window for different groups of servers. I would like to automate these installs, but patch them on demand as we watch them. For example, I might be able to push updates to 20 IS internal servers, such as monitoring servers, backup servers, Altiris, etc... I would like to choose these 20 servers as a group, patch them, reboot them, and rescan. But 5 other servers belong to a specific team or application and need to be patched at a different time. This is the first time I am doing any patching with Altiris. I understand that with everything Altiris, it's often based on Policies and Filters. I get that. I just don't know how to really plan this out to make it easy to use.

Also approx 300 servers are divided up among 12 people.

Thank you!

Operating Systems:

Comments 10 CommentsJump to latest comment

SaschaH's picture

Its a complex topic and quite some ways to get where you need to be. You can create the patch policies for all servers but create different schedules by cloning the default software update plugin policy and targeting the specific servers in each. All server will start to download patches as soon as you create the policy but only start patching during the schedule in the policy.

If you need to apply patches immediatly there is always a possibility to trigger aexpatchutil on the client/server with a task.

Bechtle – your strong IT partner. Today and tomorrow

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

SOLUTION
HighTower's picture

Yes, you can create multiple different Plug-In Policies that contain your schedules and patch agent behaviors but target All Servers with one "payload" policy (as I call it).

PatchPayloadTarget.PNG

SOLUTION
svillar's picture

CFarrell - Not really, but thanks.  I actually have that already.  It goes into the "how to" but doesn't really explain how to logically attack the issue.  I'm looking more for the thinking about the plan of attack.

SaschaH - Please tell me more about how all of this stuff works.  For example, I didn't know that as soon as you create the patch bulletin policy it downloads to the servers.  I thought it only downloaded to the CMS server?  Also, tell me more about aexpatchutil.  I think that might help me and my planning.

HighTower's picture

AeXPatchUtil:

C:\Program Files\Altiris\Altiris Agent\Agents\PatchMgmtAgent\AeXPatchUtil.exe

Altiris (R) Software Update Plug-in
Copyright (C) 2010 Symantec Corporation. All rights reserved.

Software Update Plug-in Command Line Interface

AeXPatchUtil [/i] [/Xa] [/reboot] [/C]
/I       Run full System Assessment Scan
/Xa      Start Software Update Cycle
/f {GUID1} {GUID2} ...   Forces the installation of one or more software updates

/reboot  Reboot only if the Software Update Plug-in requires a reboot
/C       Update plug-in policies
/q       Run in quiet mode. No user input required.
/s       Show current state of the Agent.
/?       Usage Screen

I always run mine as "AeXPatchUtil.exe /Xa /reboot".

I've never had any luck using the /f switch.  Good luck to you in finding which GUID they're talking about.  And the failure mode it to run all pending updates.

You can configure this as a Task in CMS to trigger an on-demand patch activity and then use that Task in a Policy in order to apply a Patch policy more flexibly like an SWD policy (run at xx:xx time or as soon as possible thereafter).

SOLUTION
SaschaH's picture

Sorry late reply. As soon as you create a patch policy it first downloads the Patch files to the CMS correct. As soon as they are there and later on the site servers they will already download to the computers targeted by the patch policy to be ready when the actual run for installing the patches is scheduled.

So you create the policy on monday and schedule the for friday the patches already download to the computers sometimes after monday.(as soon as the policy/patches show up in the tab in the agent).

@Hightower its the same as the ones in the Software Delivery folder, or more practically the package delivery folder on a site server. Just search for the KB or patch you care for and use the folder name(=GUID).

One thing that doesnt work well with a task is if you would actually need several reboots during one patch cycle to install all patches. Then a schedule actually works better.

Bechtle – your strong IT partner. Today and tomorrow

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

SOLUTION
svillar's picture

Thanks to all. I have started testing. So far so good.

jasonj86tx's picture

I actually use Maintenence windows to schedule everything , they are very useful.

svillar's picture

How do maintenance windows work and what is the benefit? How are the plug-in settings changed so that they can be used?

HighTower's picture

You should start a new thread to discuss maintenance windows but you can get started with this:

http://www.symantec.com/business/support/index?page=content&id=HOWTO45170