Before attempting to deploy a package, please confirm that the client computer(s) of interest actually report the update as NotInstalled in the console.
If the update is NotApplicable, it won't deploy. The above error sometimes occurs when the update is NotApplicable.
Also the above error can occur when the client computer(s) of interest are assigned to a downstream server and the DSS has not yet synchronized the update, or transfered the files.
Thanks for the reply Lawrence.
The update is showing as Not Installed. I have done a manual sync on our WSUS, but still no joy.
Then that leaves us with the rules...
Can you post your rulesets?
Pre-req - Registry Key Exists: HKEY_LOCAL_MACHINE\SOFTWARE\Intel\AMT
Applicable - Registry DWORD Value:HKEY_LOCAL_MACHINE\SOFTWARE\Intel\IntelAMTUNS\AMT State - Registry Value:AMT PROVISIONING STATE Equal to DWORD Value: 0
Okay so, you have two requirements..
HKLM\SOFTWARE\Intel\AMT must exist, and
HKLM\SOFTWARE\Intel\IntelAMTUNS\AMT State "AMT PROVISIONING STATE" must be set to zero.
And, the package is evaluating as NotInstalled, so we know both of those rules are evaluating correctly.
And they're valid rules. The PreReq ensures that AMT is installed, and the Applicability Rules determines that it's not configured.
Which then brings us to the actual activity being performed by the Windows Update Agent as the next possible cause.
Keeping in mind the original error which is still a strong issue to contend with: Unable to find the Update by ID to perform the requested operation.
But the fact that the update has been evaluated as NotInstalled tells us that the WUA DID find the Update -- or at least, that's a natural conclusion at this point.
But what if that conclusion is flaweed?
The question may go to the actual Deployment Task.
Please confirm that the Update published and evaluated is the SAME Update that you attempted to deploy.
If you've published multiple instances of this update, and failed to expire/decline/delete previous instances, this may be confusing the issue.
I'm somewhat glad that you have come to the same conclusions as me in as much as the rules are fine.
I can confirm that in the process of creating the package I have been tweaking the package many times, but each time I amend it I use the Delete option when I republish. Believe it or not over the last four days during troubleshooting I'm up to version 32!
From what you have said it could be a case that PM hasn't fully deleted a revision of the package.
How can fully remove all instances of the package? Is there a cleanup tool. I'm quite happy to rebuild the package and start at version 1 again.
Thanks again for your help.
I can confirm that in the process of creating the package I have been tweaking the package many times, but each time I amend it I use the Delete option when I republish.
This may be part of the issue. The "Delete" option from the Publishing Wizard is not always successful at fully deleting a package from WSUS *and* if you didn't duplicate the package, then it's actually just a revision anyway. Depending on what your'e doing in the package's binary attachment, this could also be part of the problem.
As a starting point, I would suggest visually scanning the Update View of the WSUS node and verifying that [a] all previous packages are declined/expired/deleted, and [b] any revisions to the current package are also expired.
You might even opt to expire/decline/delete all of them and start with a fresh Revision #1 package.
In general, if you're just changing RULES in a package, you only need to publish a revision (which happens automatically if the UpdateID already exists in WSUS).
If you're changing PackageBoot or the BINARY files, then the best approach is this:
- Expire the update on WSUS and allow for all clients to detect and get the expiration (or force a Detect Now to get expirations immdiately). After the expiration has been received by the affect client(s), then you can Decline or Delete the update. (I suggest deleting it.)
- After configuring the expiration via the WSUS node of the PM console, then Duplicate-and-Publish the package (with needed changes).
What this gives you then is:
- The original UpdateID is now expired, so clients will ignore it.
- The modified update package has a new UpdateID which will keep it from getting confused with the earlier packages.
Thanks Lawrence. I will work on this on Monday and report back.
Just to clarify for future reference - if I make an amendment to RULES only to a package do I have to republish or not?
1 of 1 people found this helpful
if I make an amendment to RULES only to a package do I have to republish or not?
You still have to republish, but you don't have to duplicate the package or manipulate anything on the WSUS side.
When you publish a package that already exists on WSUS (based on the UpdateID), WSUS will automatically create a new revision of that UpdateID, and the clients will see the revised rulesets at their next detection. (A RevisionID change triggers an update metadata recache; but, it does not trigger changing the binaries associated with the package, including the packageboot.xml if relevant.)
Thanks for your help Lawrence. Deleting the package and then recreating worked!