Client Management Suite

 View Only

{CWoC} ZeroDayPatch: Patch Automation Tool for PMS 7.1 SP2 

Nov 09, 2012 05:10 PM

[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: Moved to version 10 of the toolkit. No features were added _but_ this build cut the ties with the Altiris.PatchManagementCore.Web.dll.

So the program will work fine without the DLL in the current directory. Wee are free at last :D.

Please note that this build is targetting 7.1 SP2 MP1.1, with or without roll-ups.

#################

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: Version dependant - but normally starting with ZeroDayPatch.

File path: Any, but make sure you have the Altiris.PatchManagementCore.Web.dll (which can be found here on Connect for version 7.1).

Usage:

ZeroDayPatch (version 10)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.

  /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.

  /retarget
    Use this command if you want to switch existing policies to use a
    new target. The target guid should be provided with /targetguid=...

  /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!

[1] https://www-secure.symantec.com/connect/articles/readypatch-management-solution-automation-tools-patch-management-solution-62

###################################################################

Document version 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 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 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 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 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 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 7b:

  • 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>

Document version 8:

  • Attached version 8
  • Updated the command line message to reflect changes
  • Added feature /duplicates
  • Added automatic creation of the "patchautomation_excluded" table.
  • Changed naming scheme to be simpler
  • Aligned doc and release versions

Document version 9:

  • Attached version 9 for 7.1
  • Updated the command line message to reflect changes
  • Added feature /exclude-on-fail
  • Added feature /retarget

Document version 10:

  • Attached version 10 for 7.1
  • Updated the command line message to reflect changes

Statistics
0 Favorited
4 Views
7 Files
0 Shares
0 Downloads
Attachment(s)
txt file
cwoc_getallbulletins.sql_.txt   3 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-0.7.1.zip   183 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-7.1-v9.zip   17 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-7.5-v9.zip   17 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-v0.7.0.zip   13 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-v10-7.1-SP2-MP1.1.zip   18 KB   1 version
Uploaded - Feb 25, 2020
zip file
ZeroDayPatch-v8.zip   15 KB   1 version
Uploaded - Feb 25, 2020

Tags and Keywords

Comments

Feb 17, 2015 05:57 AM

Version 10 is out today for 7.1 and 7.5, whilst the 7.6 download is in the Connect publishing workflow now as well as a new utility: PatchExclusion (which helps handling the content of the exclusion table - also in the Connect publishing workflow):

Standard documentation and 7.1 builds:

7.5 Gold build (no longer supported)

7.5 SP1 builds:

7.6 Gold builds:

Patch Exclusion (7.1, 7.5 and 7.6 builds):

Enjoy, and let me know if you encounter any issue _and_ if all goes well (I'm not averse to good news ;)

Nov 13, 2013 05:45 AM

It does work if you take the 7.1 dll along.

But I've got a 7.5 build going as well and available on a seperate download:

{CWoC} PatchAutomation and ZeroDayPatch with Patch Management 7.5 Native Support

Nov 13, 2013 05:21 AM

Hi Ludovic,

What about PM in Altiris 7.5? Will be working whith your tool?

Regards

 

 

Oct 21, 2013 04:44 PM

Hello there,

I found the DLL here on Connect now. I tested it - it works perfectly fine. The sha256 hash is:

7165eae8f0b93667e8d8583d8318b5bbaad179755708692d9b998a576c8143ee

Oct 21, 2013 03:34 PM

Hi Ludovic, having same issue as Preppietechie, can you please share the dll, if that helped him. Is there any aditional thing we need to do that, I just ran the sql to create stored procedure and run the ZeroDayPatch-v8.exe with parameters.

Jul 10, 2013 10:36 AM

Sent!

Jul 10, 2013 10:08 AM

Tried it from an elevated command prompt.  Sadly, no dice.  Tried to think of any "unusual" security tools we have installed that might be goofing things up, but this box is just just running SEP, so nothing too unexpected.  If you would, shoot me that DLL when you get a chance and I'll give that a shot.

Thanks!

Jul 10, 2013 10:04 AM

Very ineterested in this tool.  Ran into a hiccup though.  The exe crashes on me when I run it because of an IO issue accessing Altiris.PatchManagementCore.Web.dll.  I've got a copy of that file sitting in the same directory, and I've checked the permissions on it to make sure that my account has full rights to the file.  I'll be the first to admit that user error is the likely problem.  Wondering if someone could point me in the right direction.  Here's what I'm getting:

D:\Symantec Tools\ZeroDayPatch-v0.7.0_0>ZeroDayPatch.exe /vulnerable /dryrun /pa
tchall
Runtime Configuration data:
        Debug = False
        Dry run = True
        Help needed = False
        Patch all vendors = True
        Released after = 7/10/2003 9:47:46 AM
        Released before = 7/10/2013 9:47:46 AM
        Severity = critical
        Test run = False
        Vendor name = *
        Custom stored procedure =
        Vulnerable = True

ZeroDayPatch 0.7.0 starting.
# Using exec [ZeroDayPatch_GetVulnerableMachines-0003] to get bulletin candidate
s.
# 13 bulletins returned by the stored procedure execution.
# 0 bulletin names found in the exclusion table.
3 bulletins match the critical severity and will be checked for policies.

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl
y 'Altiris.PatchManagementCore.Web, Version=7.1.7580.0, Culture=neutral, PublicK
eyToken=d516cb311cfb6e4f' or one of its dependencies. The located assembly's man
ifest definition does not match the assembly reference. (Exception from HRESULT:
 0x80131040)
File name: 'Altiris.PatchManagementCore.Web, Version=7.1.7580.0, Culture=neutral
, PublicKeyToken=d516cb311cfb6e4f'
   at Symantec.CWoC.ZeroDayPatch.RunAutomation(GuidCollection bulletins)
   at Symantec.CWoC.ZeroDayPatch.Main(String[] args)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\M
icrosoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure lo
gging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fus
ion!EnableLog].


D:\Symantec Tools\ZeroDayPatch-v0.7.0_0>

Any help is appreciated!

Jul 10, 2013 09:59 AM

Hello there,

This is strange as I am running the same version (albweit the tool is build on plain SP2).

Have you tried running from an elevated command line? This may be the issue.

If all fails, I can send you a copy of the DLL (it worked for someone else - strangely enough).

Mar 26, 2013 07:11 AM

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.

Mar 18, 2013 01:40 AM

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. 

Jan 02, 2013 10:53 AM

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

Jan 02, 2013 10:39 AM

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/bulletin/%bulletinname%.
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?

Dec 16, 2012 01:31 PM

Good to know :)

Dec 16, 2012 12:33 PM

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 ;).

Dec 14, 2012 08:12 AM

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...

Dec 10, 2012 03:23 PM

Thanks for the feedback!

Dec 10, 2012 01:49 PM

no issue with the new version yet.

Nov 19, 2012 01:24 PM

Version 0.5.7 is out now :D.

Nov 16, 2012 12:23 PM

Great, I'll take the week end now. Shutting down everything.

Nov 16, 2012 11:21 AM

Thanks again. Correcting that + an issue with auto-updating the stored procedure...

Nov 16, 2012 11:15 AM

Line removed. Thanks!

Nov 16, 2012 11:13 AM

Corrected. Thanks.

Nov 16, 2012 10:53 AM

Found the bug:

if (sqlRdr.GetName(i).ToLower() == "released")

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 :)

Nov 16, 2012 10:11 AM

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
                    )
 

Nov 16, 2012 09:50 AM

I found

WHERE   srl.SeverityName = 'CRITICAL'

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.

Nov 16, 2012 09:29 AM

Typos detected:

  • /vulerable (Help Message)
  • vunerable = true (On execution)

Nov 16, 2012 09:09 AM

Test Result:

  • "know what you type" ... i still strongly recommend to check for unknown parameters ... i always make a typo (like you did)
  • help says released_after/before, but parameter is released-after/before
  • /dryrun says 37 Critical bulletins (i have MS12-034 not installed, btw)
  • /dryrun /severity=Unclassified  says 113 Unclassified bulletins (i miss 3)
  • /dryrun /vulnerable for me is 0 always (report says i am vulerable for 1 Critical, and 3 Unclassified)
  • same with /released-after=2000-01-01 ... just different numbers (366/852)... /vulnerable goes 0
  • release-after can be after release-before (well ...)
  • I miss a /severity=All
  • What will happen with localized severities? (didnt try, thanks god i use the english console)

To make it short ... as /vulnerable wasnt working for me i was not able to test it.

Nov 16, 2012 07:40 AM

Thanks Mistral.

I corrected the typo in the text output for dryrun and a coulpe of issues not cuaght for the releaseed-* switches.

Nov 16, 2012 05:38 AM

Found a typo if you are interested "tryrun"

ZeroDayPatch 0.5.6 starting , tryrun = true, ceiling = 2012-11-16, floor = 2011-11-16

Nov 16, 2012 05:33 AM

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)?

Nov 16, 2012 04:59 AM

New command line switches added:

  • /released-before
  • /released-after
  • /patchall

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:

  • severity=critical
  • released-before=runtime
  • released-after=(runtime - 1 year)
  • vendor=microsoft (security updates only)

Nov 14, 2012 10:05 AM

I am not everyone, but sounds tasty for me :)

Nov 14, 2012 10:00 AM

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?

Nov 14, 2012 03:59 AM

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

 

Nov 14, 2012 03:50 AM

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.

I see your point. It's your tool, so you decide :)

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.

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 ;)

Nov 14, 2012 03:35 AM

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.

Nov 14, 2012 03:30 AM

Yes, I can do that very easily and will. Stay tuned.

Nov 14, 2012 03:05 AM

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?
 

Nov 14, 2012 02:38 AM

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:

By default we use the "Windows computers with Patch agent plugin"

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.

Nov 14, 2012 01:01 AM

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!!!

Nov 13, 2012 10:54 AM

While everyone wants everything, I'd like to say Thank You.  This is an amazing start in the right direction!

Nov 12, 2012 08:00 AM

Okay, point taken. Let me see what I can do for you.

Nov 12, 2012 07:46 AM

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?

Nov 12, 2012 07:34 AM

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 ;-).

Nov 12, 2012 07:27 AM

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?

Related Entries and Links

No Related Resource entered.