I tried the following to isolate the problem but...
I duplicated the package and changed it slightly to cater for 32 bit version.
The package installs without error.
Then about 2 seconds after its installed, it wants to re-install again.
I've tried many variations of the FileExists rule and the FileModified rule under the Installed Rule area and I can't get them to work at all. Even if I remove the dates completely from the FileExists rule.
So in summary I still have a package that repeatedly installs the C:\Windows\System32\Macromed\Flash\mms.cfg file even though the Installed rule is
I would appreciate some help here. Has anyone successfully used just one FileExists rule in the Installed rule area ?
I've used File Exists rules as an installed rule for several packages but I was always checking version numbers not modified date. I would guess that the problem lies somewhere with the date and time check.
When you removed the date parameters from your package, did you expire the old version before republishing it? It's possible that your test workstation has cached the original package with the date rule and continues to apply it. Try expiring the package, allow the workstation to detect that it has been expired so that it will be deleted from cache, then publish the new one with the date parameters unspecified.
I've also found this Technet article to be an invaluable resource for the specifics of the update rules: Basic Rules
I was hopeful that this was the answer, because I'd been declining the packages and not expiring them.
I expired all of the previously declined packages and deleted them. I also cleared the SoftwareDistribution\Downloads folder.
With each test variation, I'm duplicating the package so it gets a new update id.
This fixed the repeated installation for the package with no modified date checks. So now I have a package that just checks for the existance of the file and if it's there then the package does not repeat installation.
I have also raised this with SolarWinds as a support case. They contacted me during this time and advised that the FileExists rule requires a UTC date and time.
So I tried the package again with the UTC date and time. I also tried the FileExists and the ModifiedDate rules seperately but both of these variations still did not eliminate the repetitions.
1 of 1 people found this helpful
I’ve got this working now.
This is the rule that I used.
The date/time stamp is what's been causing the problems.
The date stamp;
- at the source is 20/02/2013 11:29:00 AM
- on the Patch Manager server is 20/02/2013 11:29:00 AM
- on the WSUS server the date and time stamp changes 20/02/2013 11:29:02 AM
- on the deployed PC is 20/02/2013 11:29:02 AM
I was checking that the time stamp was the same as the source when in-fact it was 2 sec's different. I’m not sure how the 2 second difference is introduced, but all 4 files in the package are 2 sec's older than their source files at the time of creating the package.This was easy to reproduce in another package.
Can someone else check to see if this is a bug. This is the process i followed to reproduce the issue.
- Create a new package and fill out the mandatory info on the package information screen
- Don't bother with a Prerequisite rule, just click next.
- Select 'I already have the content...' and download an exe file. (i used an inert executable)
- Tick 'include additional files...' and add another file (i added mms.cfg)
- Click Next to finish the wizard and save the package, ignoring the errors about not having any rules. (add rules if you want but they're not important)
- Now check the date and time stamp of the 2 files you added to the package from both the upload source and in the Content tab of the package details.
- The date and times match.
- Now publish the package to your WSUS server.
- Browse to the deployed test package in WSUS and get the file URI from the File Information tab.
- Open the cab file by pasting the URI into explorer.
- Extract the 2 files from the cab and check the date and time stamp. For me they are 2 seconds older.
I'm running Patch Manager Version 1.85.490.0
Whether there might be a 'bug in how the timestamps are handled when a CAB file is created is really beyond the scope of SolarWinds or Patch Manager, as that's a Microsoft specification, a Microsoft tool, and a Microsoft product where the CAB file was built. (Patch Manager does not build the CAB file; the WSUS API actually does that part of the process.)
Phil, fundamentally there is nothing wrong with the process that you used, except that you need to base your ruleset off of client-side post-deployment data, not pre-deployment data, particularly when defining the *Installed* rules.
So, the important takeaway from this thread is that it is critically important to build rules from the actual data contained on the CLIENT. Specifically Installation Rules must be built from the actual state of reality on a client where the product is installed, not the expected results of that installation. (Things change; stuff happens.)
I have a curriculum I wrote on "Local Publishing" a few years ago, which I'm in the process of re-purposing into blog articles for PatchZone.
One of the tenets of that curriculum was this comprehensive approach to package creation:
1. Document the state of a reference system PRIOR to the installation of the update. This is the basis for your Prerequisite and Applicability Rules.
2. Install the update on that reference system using the vendor supplied installer. Part of this will be the basis for your Installation File specifications.
3. Document the state of the reference system AFTER the installation of the update. This is the basis for your Installed Rules.
4. Build the package based on the information obtained in Steps #1 through #3.
5. Publish, approve, and deploy the package to a system configured exactly as the refernence system in Step #1.
6. If the behavior at the conclusion of Step #5 is different from that observed at the end of Step #3, revisit the data obtained from Step #3.
- I wasn't implying that SolarWinds was responsible for the bug and in fact I'm not even sure it is a bug (might be a feature :-). I simply wanted to confirm if anyone was aware of the behaviour, so I provided a quick step-by-step just in case anyone was interested in checking it and thereby confirming if its normal or expected.
- Yeah, thanks for the 'important takeaway', once I realised the Time stamp was being changed, it became obvious that the destination details were what was required. After this I quickly resolved the issue. I had actually tried the destination time stamp earlier but had no luck probably due to the caching issue that Andrew M spoke of earlier in this discussion.
- I'd be keen to see the curriculum that you have written. I'm new to PM and any assistance is welcome. Could you please post a link to it?
There are two videos available that were created a few years ago...
Package Creation Part 1 - covers basic package definition, installation file acquisition, and a very basic look at rules and rulesets
Package Creation Part 2 - covers rules more in-depth and looks at the interrelationships between Applicability and Installed rules
And these three articles that were recently written for PatchZone...