Patch Automation Tool for PMS 7.1 SP2
######### Important Forewords #########
This tool will allow you to stage and distribute all bulletins that match the critical severity (or more if you use the /severity switch). I and Symantec in general do not advise to do this on test, validation or production systems _unless_ the MetaData Import Task is configured to import bulletins that you want to distribute or test.
#####################################
It's been a very long while since I posted a download on Connect but tonight I've got something worth sharing.
This week I needed to work on implementing automated patching for one of my customer with Workflow and this lead me to consider writing something similar to the 6.2 [1] tool we had, but for 7.1.
And it turned out to be rather trivial, compared to the code we previously had to write.
This is because the Patch Workflow API contains everything needed to handle the staging of bulletins and creation of software update policies.
So, I'm attaching an executable file to this download and you will need to copy the Altiris.PatchManagementCore.Web.dll file to the directory for the tool to work.
And here's a brief description of the tool command line options:
File name: ZeroDayPatch.exe
File path: Any, just keep all release files in the same folder.
Usage:
ZeroDayPatch (version=0.7.0)command line usage:
/vulnerable
Use this command line switch to install and run a custom stored
procedure to retrieve candidate bulletins. The procedure will be
installed is and named ZeroDayPatch_GetVulnerableMachines-0003.
/targetguid=<target_guid>
Use this option to set the target guid to be used with newly
created policies. This will over-write the default target defined
globally.
/config=<file path>
Reads the file at the provided path and parses each line for com-
-mand line options. Here is a sample config file content:
/severity=critical
/custom-sp=CWoC_GetAllBulletins
/vendor=google
/dryrun
/debug
/test
Run the automate in test mode only. A maximum of 10 policies will
be created in this mode.
/dryrun
Run the automate in fry run mode. No changes will be made to the
system, but expected operation will be printed to the console.
/severity=<severity>|*
Set the severity used to select bulletins that will be handle by
the automate. The * wildcard can be use to match all severities.
/patchall
Use this command line if you want to manage bulletins from all
vendors in the database. By default we only handle Microsoft bul-
-letins.
/released_before=<yyyy-MM-dd formatted date>
Configure a date filter that will include bulletin released before
the specified date. It is set by default to the current date.
/released_after=<yyyy-MM-dd formatted date>
Configure a date filter that will include bulletin released after
the specified date. It is set by default to (current date -1 year).
/custom-sp=<sp_name>
This option allows the user to specify a custom stored procedure to
be called during the execution. The stored procedure may be present
on the database (if not the automate will return with no errors) and
must contains the following columns that are used and needed:
* _resourceguid [Software bulletin guid]
* released [Software bulletin release date]
* bulletin [Bulletin name]
* severity [Bulletin Severity]
You can also add a vendor column if you want to filter bulletins by
vendor (see option /vendor)
/vendor=<vendor string>|*
Configure a vendor filter to only return bulletins that match the
vendor string from a custom procedure. This is because the vendor
field doesn't exist in default Patch Procedures used by this tool.
If /vendor is specified with a custom-sp that doesn't contain the
vendor field the setting will be ignored (all bulletins will be
returned).
/debug
Output extra information on the command line to allow debugging or
reporting problems to Symantec Connect.
/version
Print out the current version of the tool.
/?
Print this help message to the console (stdout).
This tool was coded to be as simple and straight forward as possible. Here are some key points on what it does and doesn't do:
- It creates a policy if no policy exist (so we don't create duplicates)
- It enables the policy by default
- It does not verify whether the targetGuid provided is a valid target
Now, please let me know if this helps and if you have some feature needs or comments, post them here or contact me directly!
###################################################################
Document version 0.2:
- Replaced the file with version 0.5.3 (ZeroDayPatch-0.5.3.zip)
- Added /vulnerable switch to the tool and documentation
- Implemented custom target guid during policy creation (missing from the API)
Document version 0.3:
- Added foreword section
- Attached file with version 0.5.4
- Remove the hardcoded target for new policies. This will now use the system default target (normally user configured)
- Added /? handler and help message for the console
Document version 0.4
- Added command line switch /released-before
- Added command line switch /released-after
- Added command line switch /patchall
- Converted the command line switch description to be a copy of /? output
- Attached file version 0.5.6b which contains the Altiris.PatchManagementCore.Web.dll to allow the tool to run on 7.1 SP2 versions up to MP1.
Document version 0.5
- Added stored procedure schema versioning (and auto-update)
- Corrected stored procedure field to match "Released" date
- Corrected a typo in the console messages
- Attached file version 0.5.7
Document version 0.6
- Attached version 0.6.6 (from revision 770)
- Made previous versions visible (so you are not forced to get the latest only ;)
Document version 0.7
- Attached version 0.6.7 release (from revision 777)
- Attached version 0.6.7 debug (from revision 777)
- Updated the command line message on this download to reflect changes
- Added feature /severity=*
Document version 0.8
- Attached version 0.7.0 release (from revision 8755b369fd0e)
- Attached custom-procedure sample CWoC_GetAllBulletins.sql
- Updated the command line message on this download to reflect changes
- Added feature /custom-sp=<store procedure>
- Added feature /vendor=<vendor name>|*
- Added feature /config=<config filename>
Comments 37 Comments • Jump to latest comment
Love the idea and tried "dryrun".
Do i get this right: It will create a policy for _every_ Bulletin? No matter if you are vulnerable, or not?
This will create thousands of policies (one for each update) in the system. Most of them will probably never be used, but slow down the system.
Any plans to make a "/vulnerable" switch?
It will create a policy for every bulletin that is not superseded and that match the severity setting you choose (with /severity or the default critical).
I guess we could have a list of vulnerability from the Patch Assesment scan results, but this is not what my customer (and other) wanted.
I guess a feature request I could implement would be to include a custom filter based on the release date, or the bulletin name, to give you more control on how far back we go.
Would that suit you better?
Also note that the /test option will create policies by batches of 10, starting from the newest and going down. So run that a few times and you'll cover this year or last year ;-).
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Hmm ...
A lot of bulletins are simply not needed, because:
a) i don't have a certain OS installed (and i am not excluding things from "Microsoft", way too many checkboxes and you never know if you need it some day... things are matter to change)
b) many bulletings are pre SP and not need if you reach a certain SP level.
here is how i go:
"Compliance by Bulletin" -> Sort by "Compliance" (ascending) -> Distribute where compliance is not 100% (you are vulnerable)
Sure i could manually add this bulletins to a filter. But i would love to have a kind of /vulerable switch so everything is automatic. Add the bulletin to a filter, or select "distribute" manually is not that different (making this tool obsolete).
Maybe i am doing something completely wrong?
Okay, point taken. Let me see what I can do for you.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
While everyone wants everything, I'd like to say Thank You. This is an amazing start in the right direction!
Thanks Zac, I reapply appreciate the positive comment.
I'll attach here a new version (0.5.3) which is not dependant on the MP1 release (this was hardcoded on the assemblies, so I removed the dependancy from the project and it just picks the assemblies from the GAC - using the version based on the policy files there).
Also note that there is one bug fix with the /targetGuid that wasn't working (because the feature was not implemented in the API!).
Finally, there'll be something for Mistral: /vulnerable made it in!!!
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Fantastic work :) I felt in love a little bit ;)
One question: there is a difference between applicable and vulnerable, isn't it?
Going to test it soon. I just need to create some vulnerable clients first :)
One more Idea, you might want to think about:
How about using the target from
Settings -> Software -> Patch Management -> Windows Settings -> Windows Patch Remediation Settings
Software Update Options -> default Resource Target
this way the tool is not bypassing the native Patch Management configuration.
BTW: you have a typo in your command line switches for vulnerable.
Yes, I can do that very easily and will. Stay tuned.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Tested it
First i noticed:
The command line parameters are not checked.
If you make a typo it just starts with ignoring the parameter.
Esp. dangerous if you misstype /dryrun. ^^
Also /? (or no parameter) immediately starts to stage critical bulletins, where someone would proably expect some "Usage" text.
My Enviroment (compliance reports with no date restriction, means 2000 till today):
313 applicable bulletings, 1 vulnerable (not installed)
Your tool would create 73 policies (/vulnerable /dryrun).
Well ... i get close to this (74) if only report the last 8 months.
So probably should be an /applicable switch.
Do you use any time frame in your query?
Hello Mistral,
> The command line parameters are not checked.
Hum... they are, clearly, checked for expected input.
> If you make a typo it just starts with ignoring the parameter.
I don't feel like writing a spell checker for command line tools, if you see what I mean ;-). Be careful what you type, and if you fail, Ctrl +C is your saviour.
> Also /? (or no parameter) immediately starts to stage critical bulletins, where someone would proably expect some "Usage" text.
Noted. I did this in the other tool I'm working on (for my customer - it's going to CSV tooday and will be also published in full here on Connect.
I did put the _warning_ regarding the current builds ;).
Also remember I started coding last Friday alone, and I don't touch computers on week-end. So it'll be much better fast, but humanly fast - not lightning fast.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
I see your point. It's your tool, so you decide :)
I really appreciate your effort and don't expect anything. I just try to give a helping hand to make it better (as good as _you_ want it to be).
But you know how it works. First you code a little tool, then you get tons of input and in the end you have a huge applications and have to establish a new company ;)
No worries.
I just fixed the 2 points you mentionned. It'll be probably uploaded here tomorrow or at the end of the week so I can add any other fixes etc.
Herer are the revision details:
http://code.google.com/p/altiris-ns-tooling/source/detail?r=742
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Before someone ask - I will add another switch so that it is possible to set a release date beyond which bulletins will be ignored.
How would that suit everyone?
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
I am not everyone, but sounds tasty for me :)
New command line switches added:
This should be it for the core feayures really!
Also note that I packaged a DLL in the release to avoid issue running the tool on MP1 (I couldn't work out assembly binding redirect last night) and that it is a lot more fail safe now, with the following defaults:
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Going to test in the afternoon.
When you say default (vendor=microsoft), is there a "/vendor" switch you forgot to mention, or is it just /patchall or not (microsoft only)?
Found a typo if you are interested "tryrun"
ZeroDayPatch 0.5.6 starting , tryrun = true, ceiling = 2012-11-16, floor = 2011-11-16
Thanks Mistral.
I corrected the typo in the text output for dryrun and a coulpe of issues not cuaght for the releaseed-* switches.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Test Result:
To make it short ... as /vulnerable wasnt working for me i was not able to test it.
Typos detected:
Corrected. Thanks.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
I found
hardcoded in your stored procedure ... shouldnt that be a parameter?
I executed your stored procedure manually and i got a result (even when i got applicable computers, not vulerable ones). So the 0 from /vulnerable does not come from the stored procedure.
Maybe you want to add the second block to your query to filter out installed updates
(result: applicable - installed = vulnerable)
WHERE sua.UpdateGuid NOT IN -- filter out supersede applicable updates
( SELECT DISTINCT ChildResourceGuid
FROM ResourceAssociation
WHERE ResourceAssociationTypeGuid = '644A995E-211A-4D94-AA8A-788413B7BE5D'
)
AND sua.UpdateGuid NOT IN -- filter out installed updates
( SELECT DISTINCT sui.UpdateGuid
FROM vPMWindows_UpdateInstalled sui
WHERE sua._ResourceGuid = sui._ResourceGuid
)
Line removed. Thanks!
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Found the bug:
But in your stored procedure do:
swb.Released AS [Release Date],
...
ORDER BY [Release Date] DESC, Bulletin DESC
@Edit ... with the modified stored procedure ... working like a charm now ... love it :)
Thanks again. Correcting that + an issue with auto-updating the stored procedure...
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Great, I'll take the week end now. Shutting down everything.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Version 0.5.7 is out now :D.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
no issue with the new version yet.
Thanks for the feedback!
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Today it tried to stage an Adobe patch without /patchall ... is this a general bug, or a /dryrun issue?
(I cannot really execute this, so i need /dryrun)
C:\ZeroDayPatch>ZeroDayPatch-version-0.5.7.exe /dryrun /released-after=2000-01-01 /vulnerable ZeroDayPatch 0.5.7 starting , dryrun = true, released-after = 2000-01-01, vulnerable = true, released-before = 2012-12-14, released-after = 2000-01-01 Using exec [ZeroDayPatch_GetVulnerableMachines-0002] to get bulletin candidates. 3 bulletins match the critical severity and will be checked for policies. ######## THIS IS A DRY RUN ######## Processing bulletin MS12-075 (404b2b77-0b19-4547-b7cc-aac4e2170398) now. This bulletin is already staged. Checking if we need to create a new policy now. ... create a policy for the bulletin now. Software update policy created! Processing bulletin MS12-074 (60347c47-0df5-4dea-963a-9630a0df1f81) now. This bulletin is already staged. Checking if we need to create a new policy now. A policy already exists for this bulletin. Processing bulletin APSB06-20 (bcb45e2e-d5ed-45a1-94e1-847b437dfb3a) now. ... bulletin will be stagged now. Bulletin is now stagged. Checking if we need to create a new policy now. ... create a policy for the bulletin now. Software update policy created! 0 software update policy creation tasks were started. ZeroDayPatch execution completed now. See you soon...Hello Mistral,
I cannto be a /dryrun issue given the dry run takes the same input as a /test or full execution.
Now you have the /vulnerable switch in your command line, so clearly it comes from "ZeroDayPatch_GetVulnerableMachines-0002" which returns data outside of the expected scope (Msft vulnerable computers only).
From a quick look on the SQL it brings back any vendor information. So I should probably document this fact accordingly (for now) and write a Microsoft only /vulnerable option ;).
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Good to know :)
Ludo, have you thought about an alerting process?
Lets just say we have an admin and they use this to create policies to automatically rollout to a test filter, ahead of their main pushes. So of course we can make this a scheduled task, but once run that task won't know what happened and the admin won't know if anything was performed.
OK so he's REALLY lazy :)
Probably have to interface with an automation policy or workflow since its unlikely the NS has a mail client but here's the picture;
Your code runs, NS creates and activates the policies etc. Then it emails the admin:
Oh hi,
I recently sent %bulletinname% to your test group (randomly made up a variable there)
It's here: http://technet.microsoft.com/en-us/security/bullet....
And the admin forwards the email to his test users...and goes back to sleep (one day)
This leads to a second potential development use: editing/adding a policy target/filter guid to add patching "groups" after UAT to prod, dev and so on.
Any thoughts?
Michael Cole
Remote Product Specialist
Business Critical Services
Hello Michael,
> Ludo, have you thought about an alerting process?
No, not really. But that's because I don't think there's a need for it to be built -> its already in the product
> Probably have to interface with an automation policy or workflow since its unlikely the NS has a mail client but here's the picture;
> Your code runs, NS creates and activates the policies etc. Then it emails the admin
So, the question really is how to create an automation policy to be used with the tool.
I have planned to punlish an article with step-by-step information to use the other tool (PatchAutomation.exe) which is a little more complex - but the data could be used in this case as well.
> This leads to a second potential development use: editing/adding a policy target/filter guid to add patching "groups" after UAT to prod, dev and so on.
This, my friend, already exists and it's called PatchAutomation.exe exactly. Check out my blog post on this (may be I should push it to the download section, to improve its visibility?):
https://www-secure.symantec.com/connect/blogs/patch-71-automation-version-20
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
We are using ZeroDaypatch-v0.7.0 and using commandline C:\Program Files\Altiris\Notification Server\Bin>ZeroDayPatch.exe /released-after=2010-01-01.
Policy are created on server but we found that policy are geting assine but they all show update shedule.if we apply it by sheduling in console as run as soon as posible then patch gets installed secussefully.
Can you tell me how can I apply runoption to all policy created using commandline.
Hello CBZ9104,
The tool doesn't cater for this side of the configuration, but I still can help.
It looks like your "Default Software Update plug-in policy" (in Settings > Agent plugins > Software > Patch Management > Windows) schedule is not matching your current expectations.
If you want updates to run asap you can change this policy to install at a given time starting from a date in the past.
Let me know if this is unclear or if it doesn't help solving this issue.
Ludovic FERRÉ
Principal Remote Product Specialist
Symantec
Need help with IIS log files? Check out the self-service portal on http://aila.15-cloud.fr/
For a view
Would you like to reply?
Login or Register to post your comment.