[END OF "SUPPORT" NOTICE]
Hello everyone, after close to 5 years maintaining various tools around Symantec Connect this legacy is turning to be more of a burden than anything else.
It's still is a great set of tool and they all have their use, but as such I'm not going to maintain them anymore.
The source code for this tool may still change over time, and can be found on Github: https://github.com/somewhatsomewhere?tab=repositories
[/END OF "SUPPORT" NOTICE]
Update: Just released version 10, which removes the ties to Altiris.PatchManagementCore.dll.
I have extended the ZeroDayPatch tool to meet my customer requirement to further automate patching operations:
In this tool we not only want to create policies automatically but we also want to follow a 3 step process:
- Stage required bulletin and create a policy that targets a test group (Test phase)
- Check if policy in Test were created more than n days ago. If yes move the policies target to a validation group (Validation phase)
- Check if policy in Validation were created more than m days ago. If yes move the policies target to a production group (Production phase)
The conditions used to move policies from one phase to another are configurable, but here's a flow chart that explain the logic in details:
Please remember to copy the Altiris.PatchManagementCore.Web.dll to the directory where you have unpacked PatchAutomation.exe.
And finally here is the command line documentation:
PatchAutomation (version 10) command line usage:
/targetguid-test=<target_guid>
/targetguid-validation=<target_guid>
/targetguid-production=<target_guid>
The 3 command line options above are mandatory and used to define
the target used with each phases (Test, Validation, Production).
/day2validation=<n>
/day2production=<n>
The 2 command line above define the interval in days necessary to
move policies from one phase to the next. The days are match using
>= n, so if you set these to 1 (day) the policies created the day
before will be re-targeted (so the interval could be as low as a
few minutes if the tool runs at 2300 and again at 0005 the next day.
/fr
Switch the automatic policy names postfix from English to French like:
* 'Test Target' <--> 'Cible de Test'
* 'Validation Rarget' <--> 'Cible de Validation'
* 'Production Target' <--> 'Cible de Production'
/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.
/duplicates
Use this command if you want the tool to generate duplicate
policies. This is useful if you want, for example, to migrate
policies from a parent to a child SMP without disruption.
Note! Duplicated and new entries will be added to the exclusion
table in the database for safety reasons.
/exclude-on-fail
Use this command to add bulletins to the excluded table if it fails
3 times during the stagging or policy creation phases. If not uses
the failing bulletin will only be skipped.
/version
Print out the current version of the tool.
/?
Print this help message to the console (stdout).
Document changes:
Version 1.1: Changed the attached file to PatchAutomation-0.6.3 (build from revision 747).
Version 1.2: Changed the image link to the full size version.
Version 1.3: Updated the command line help message, workflow and uploaded release 0.6.4 (built from revision 750).
Version 1.4: Added patch exclusion using a database table in build 0.6.6 (built from revision 770).
Version 1.5: Added /custom-sp feature to allow users to call-in their own stored procedure and better control the bulletins handled by the program (built from revision 777)
Version 1.6: Added /fr switch and /version and updated the documentation accordingly and uploaded release 0.6.9 (built from revision 787). Also moved the data from the original blog post to a proper download page which is better suited.
Version 1.7: Added /vendor and /config command line options. Uploaded custom stored procedure to provide the missing vendor field (needed with /vendor). Uploaded version 0.7.0 (built from revision 1499b791f1eb)
Version 1.8: Pulled a bug fix and some spelling corrections (58f95c9cd476 and ade2195063cc) from Brian Nelson and bumped the version to 0.7.1.
Version 1.9: Changed the numbering scheme, so we are now at version 8 and added a "/duplicates" switch. This allows you to generate duplicate policies if you need them, or brand new ones. Any policy created will then be added to the "patchautomation_excluded" table that we generate automatically now. This is useful if you want to transition existing policies to a new target, or as in my case, from hierarchy based to locally generated. Amended the command line /? print out to match those changes.
Version 2.0: Added Patch Automation version 10 (Built for 7.1 SP2 MP1.1) and documentation on the /exclude-on-fail switch.