So what patches are not on the file system but show that the url exists ?
What about letting the Catalog Update Job run, and set a property on the “approved” patches, then use that property for the smart group?
Most customers who have this kind of need use a regular online catalog, then use the property (COMPANY_APPROVED. You can always go delete the patches (or as you’re doing, not import them in the first place), but if there’s dependencies or pre-reqs, that may get difficult to manage.
The property idea is already in use on 2 other catalogs which are both on-line and working fine. This new catalog is for another business unit who simply wants to take their individual patches and copy them over.
what's the condition on the smart group and what's the value of the SOFTWARE_PAYLOAD_EXISTS_AT_URL_FLAG* property on the patches where the file isn't there ?
the only reason those should have been flagged as downloaded is if they downloaded.
you could try running a new cuj w/ the debug mode enabled and maybe we can see why the 'payload exists' flag is being set.
I finally had some time to do some testing. Here is what I discovered. I created several different NEW catalogs. Each time I replaced the patches in the Payload Source Location with different patches (single bulletin). Each time the catalog was updated it found those patches copied them to Repository Location and added the bulletin for those patches but in doing so it flagged each of the patches in the bulletin as being in the repository even though I did not provide all of the patches.
Example: Created new catalog
used the downloader & filtered on Windows Server 2008 and Internet Explorer only
performed the download
reviewed bulletin MS13-037 (there were 23 patches downloaded)
copied those 23 patches to the Payload Source Location
Performed the catalog update
Results: Bulletins 855 Hotfixes 11660 added
Created a Patch smart group for exists lag: 28 show
counted patches in Payload 23 (as expected)
reviewed Bulletin MS13-037 has 28 hotfixes
Conclusion: since a single patch of the bulletin was found, the catalog update flagged all patches of that bulletin as in repository. The 5 patches flagged but not in the repository seem to be for products not in my catalog. I do not believe this would be a problem since the products are not to be analyst with but it doesn't seem right.
For now I can live with this since I understand it. I will need to test this in BladeLogic 8.7 to see if the same behavior since the client will be upgrading in the near future.
The attached job export reflects testing bulletin MS13-037
CUJ -ResultsExported.csv 11.5 MB
?i would say that what you are doing isn't standard use case so this probably wasn't tested but it should be a defect because the 'other' patches should not be marked as downloaded because others in the bulletin exist. you should open a ticket w/ support on this and have them file a defect.
Bill, I understand this not being a standard use case but we are looking at several different offline catalogs and the client would like to save space if at all possible. This approach, although not a standard case seems that it would work in the environment just fine and save lots of disk space in the process. I will go ahead and open a ticket with support and as soon as I have a chance I will be testing this in BL 8.7 as well.
Thanks for you assistance and feedback, it is always appreciated
Based on our call yesterday, I tried to reproduce the issue with a patch belonging to MS15-053. Below are the steps and the results.
1. I chose to copy only "Windows6.0-KB3050945-x64" from MS15-053 to the new payload location.
2. Catalog Details:
3. Payload Location:
4. Repo Location (after CUJ):
5. Hotfixes page: The ones highlighted in red have "SOFTWARE_PAYLOAD_EXITS_AT_URL" flag set to "Y". Others do not have it set.
6. Smart Group Condition for Lou above:
Is set correctly for the patches which are 64 bit only because the payload for all the 64-bit patches is the same which is "Windows6.0-KB3050945-x64" (present in payload and repo loaction).
The x86 patches are NOT flagged "Y" which is expected.
So this does not seem to be a defect according to the above results. Can you please check and comment?
Thank you for conducting the test. Can you explain why the internet
explorer patch was also flagged as in repository?
I can understand a patch being valid for several platforms but I don't
understand why the explorer is there?
here is what I obtained for that bulletin
ivyletc2.png 43.8 K
I believe that is because of VBScript 5.7. Below is the screen capture which shows IE 6 and 7 highlighted for VBScript 5.7 from the URL Microsoft Security Bulletin MS15-053 - Important