10 Replies Latest reply on Jul 21, 2014 3:24 AM by ascoyne

    Custom package not deploying - Result code: 0x80240003

    ascoyne

      I have built a customer package to configure Intel AMT.  I have set the applicability rule and pre-requisite to a registry key that I know exist on the computers, but each time I try to deploy the package I get the following error:


      Update not applicable. Unable to find the Update by ID to perform the requested operation. The update may not be applicable for the selected computer Result Code: 0x80240003


      I have triple checked the rules and got my colleagues to check and the computers to meet the requirements.

       

      Please help.


        • Re: Custom package not deploying - Result code: 0x80240003
          Lawrence Garvin

          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.

            • Re: Custom package not deploying - Result code: 0x80240003
              ascoyne

              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.

                • Re: Custom package not deploying - Result code: 0x80240003
                  Lawrence Garvin

                  Then that leaves us with the rules...


                  Can you post your rulesets?

                    • Re: Custom package not deploying - Result code: 0x80240003
                      ascoyne

                      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

                        • Re: Custom package not deploying - Result code: 0x80240003
                          Lawrence Garvin

                          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.


                            • Re: Custom package not deploying - Result code: 0x80240003
                              ascoyne

                              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.

                                • Re: Custom package not deploying - Result code: 0x80240003
                                  Lawrence Garvin
                                  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:

                                  1. 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.)
                                  2. 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.