locked
Automatic Deployment Rules - Just Not Working/Reboot RRS feed

  • Question

  • Good Morning:

    For the better part of 5 days I have been trying to get ADR deployed in my lab to install and automatically reboot machines.  I have gotten everything set up and the rule is working and downloading the update, just never making it to the clients to install the updates and or reboot.  For simplicity sake, I created a device collection, "domain controllers" and this finds my two DCs just fine.  I then created a ADR

    Collection - Domain Controllers, Add to Existing Software Update Group - Software Updates (date released - 2 months, Product - 2008 R2) as both of my DCs are 2008 R2 - Evaluation Schedule (Run on schedule - once a week at 11:30 pm) - Deployment Schedule (software/specific time 1 hour) (installation/2 hours) - User Experience Software Installation Checked - Then I create a new deployment package and then run it.

    It created the deployment packages, and the software update group, I checked the logs and it downloads the files just fine and shows 42 updates needed.  However I cannot get those two servers to install updates and reboot for the life of me.  I have google and read everything possible.  I checked the permissions of the package source, I created a maintenance window for that time, I attempted to change the work information via powershell in case it was overlapping.

    Can anyone please give me a little push in the right direction on what I could possibly be missing? 

    I did see this in the log, 

    Could not find element DeploymentId SMS_RULE_ENGINE 1/3/2014 10:03:35 AM 3240 (0x0CA8)
    Could not find element UpdateGroupId SMS_RULE_ENGINE 1/3/2014 10:03:35 AM 3240 (0x0CA8)
    Could not find element UpdateGroupName SMS_RULE_ENGINE 1/3/2014 10:03:35 AM 3240 (0x0CA8)
        SQL is: select cis.CI_ID from vCI_ConfigurationItems cis join vProvisionedCIs pci on cis.CI_ID = pci.CI_ID where cis.CI_ID in (16789853, 16789855, 16789865, 16789867, 16790069, 16790071, 16790077, 16790081, 16790087, 16790089, 16790164, 16790166, 16790193, 16790195, 16790203, 16790205, 16790213, 16790217, 16790221, 16790424, 16790426, 16790430, 16790436, 16790438, 16790444, 16790448, 16790452, 16790509, 16790517, 16790523, 16790527, 16790531, 16790535, 16790537, 16790547, 16790568, 16790574) order by cis.CI_ID SMS_RULE_ENGINE 1/3/2014 10:03:35 AM 3240 (0x0CA8)
          42 of 42 updates are downloaded and will be added to the Deployment. SMS_RULE_ENGINE 1/3/2014 10:03:35 AM 3240 (0x0CA8)

    Any assistance would be greatly appreciated as this is just making me spin in circles.

    Friday, January 3, 2014 4:10 PM

Answers

  • Looks fine. Is there a GPO overriding in Computer Configuration>Policies>Administrative Templates>Windows Components>Windows Update>Specify Intranet Microsoft Update service location?

    Run a RSOP on a DC and check.

    Check the windowsupdate.log on a DC and check the status of that - it will confirm where the device is picking up the WSUS server from to apply update.

    Also take a look at the WUAHandler.log on a DC. See any errors there?


    Cheers

    Paul | sccmentor.wordpress.com

    Friday, January 3, 2014 4:51 PM
  • Thanks for your replies guys, I waxed both of those GPO's.

    I can get them to report now, as it shows a local GPO with the SCCM server.  It appears some updates are being applied but still seeing odd behavior.  No machines have been rebooted after windows updates, and some show updates are not automatically being installed.   I attached my SCCM settings, are these appropriate for a reboot?


    • Edited by wisowebs Monday, January 6, 2014 4:48 PM
    • Marked as answer by Joyce L Thursday, January 9, 2014 10:57 AM
    Monday, January 6, 2014 4:48 PM

All replies

  • Check the update group in the console. Can you see all the updates there? Check the package source and make sure they are there and also check that they are distributed to a DP.

    Cheers

    Paul | sccmentor.wordpress.com

    Friday, January 3, 2014 4:25 PM
  • Paul, thanks for your reply.

    Yes in the Software Update Group I can see all the updates, and show as downloaded = yes and deployed = yes.

    The package source is populated with 185 MB of data with applicable updates.

    I attached my distribution settings for the deployment package, did I miss something here?
    


    • Edited by wisowebs Friday, January 3, 2014 5:24 PM sp
    Friday, January 3, 2014 4:33 PM
  • Looks fine. Is there a GPO overriding in Computer Configuration>Policies>Administrative Templates>Windows Components>Windows Update>Specify Intranet Microsoft Update service location?

    Run a RSOP on a DC and check.

    Check the windowsupdate.log on a DC and check the status of that - it will confirm where the device is picking up the WSUS server from to apply update.

    Also take a look at the WUAHandler.log on a DC. See any errors there?


    Cheers

    Paul | sccmentor.wordpress.com

    Friday, January 3, 2014 4:51 PM
  • Do your SCCM client settings for the targets have Software Updates enabled? (I'm sorry if this seems obvious but I actually did that myself before is why I ask)

    Also do you have any Group Policies that point to a WSUS server? SCCM sets local policies and domain policies overwrite the local ones that SCCM will set. I had a situation where a set of servers I was pushing updates to had some that had a WSUS setting from a AD Site linked GPO, and others didn't. The ones with the Site GPO didn't get the updates, and the others did.

    Friday, January 3, 2014 4:52 PM
  • I have a GPO with the listed settings. I did have WSUS working for quite a while in my lab, but I waxed that GPO and powered off that VM a while ago.
    Friday, January 3, 2014 7:11 PM
  • In the WUAHandler

    <![LOG[Failed to Add Update Source for WUAgent of type (2) and id ({425A8C16-C127-4006-B60D-8F04DF0333EB}). Error = 0x87d00692.]LOG]!><time="11:28:02.414+360" date="01-03-2014" component="WUAHandler" context="" type="3" thread="6796" file="cwuahandler.cpp:2325">
    <![LOG[Its a WSUS Update Source type ({425A8C16-C127-4006-B60D-8F04DF0333EB}), adding it.]LOG]!><time="12:58:08.788+360" date="01-03-2014" component="WUAHandler" context="" type="1" thread="4344" file="sourcemanager.cpp:1232">
    <![LOG[Enabling WUA Managed server policy to use server: http://KSP-SCCM.waw.local:8530]LOG]!><time="12:58:08.788+360" date="01-03-2014" component="WUAHandler" context="" type="1" thread="4344" file="sourcemanager.cpp:948">
    <![LOG[Waiting for 2 mins for Group Policy to notify of WUA policy change...]LOG]!><time="12:58:08.803+360" date="01-03-2014" component="WUAHandler" context="" type="1" thread="4344" file="sourcemanager.cpp:954">
    <![LOG[Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://KSP-SCCM:8530 and Policy ENABLED]LOG]!><time="12:58:10.348+360" date="01-03-2014" component="WUAHandler" context="" type="3" thread="4344" file="sourcemanager.cpp:1013">
    <![LOG[Failed to Add Update Source for WUAgent of type (2) and id ({425A8C16-C127-4006-B60D-8F04DF0333EB}). Error = 0x87d00692.]LOG]!><time="12:58:10.348+360" date="01-03-2014" component="WUAHandler" context="" type="3" thread="4344" file="cwuahandler.cpp:2325">

    So now I think that GPO setting maybe causing my issues.

    Friday, January 3, 2014 7:22 PM
  • That is the same thing I was getting on my servers that didn't get the updates that I mentioned earlier. 

    Unfortunately I couldn't nuke that GPO to confirm absolutely that prevented updates from SCCM going through. However servers that DID NOT have that GPO applied worked correctly by getting updates.

    If possible I'd try getting rid of that GPO, or at least doing whatever it takes to prevent it from being applied.

    Good luck!

    Friday, January 3, 2014 7:31 PM
  • Yes remove the setting or block for the effected DC's

    Cheers

    Paul | sccmentor.wordpress.com

    Friday, January 3, 2014 9:56 PM
  • Thanks for your replies guys, I waxed both of those GPO's.

    I can get them to report now, as it shows a local GPO with the SCCM server.  It appears some updates are being applied but still seeing odd behavior.  No machines have been rebooted after windows updates, and some show updates are not automatically being installed.   I attached my SCCM settings, are these appropriate for a reboot?


    • Edited by wisowebs Monday, January 6, 2014 4:48 PM
    • Marked as answer by Joyce L Thursday, January 9, 2014 10:57 AM
    Monday, January 6, 2014 4:48 PM
  • Can anyone please give me any more insight.  My SUP is working perfectly, no errors in my component view.  My ADR are working and creating the Software Update Groups, and I am seeing applicable updates there.  They just simply do not make it to my machines and or install any updates or reboot EVER.  I even created new device collections via my Active Directory environment, and re-created the rules.  Also my logs all are checking out fine, and no SQL errors as well.

    I have no idea what I could be possibly be missing.  Do I need to create the GPO to schedule the install?  I thought this was all handled within the ADR?  Any help would be great, as all I want is for this to work as it should.  This way I can explore more of SCCM.

    Thanks for any insight.

    Saturday, January 11, 2014 4:06 PM
  • Hi, did you ever get any insight on this one?  I'm fighting the same battle.  Any log files to look at on both client and server?

    Kevin

    Thursday, February 20, 2014 12:21 PM