locked
Content NOT distributing to secondary sites RRS feed

  • Question

  • I've got one primary site and two secondary sites.  I'm trying to push out a windows update to all my DP's and distribute them to my clients.  The primary site works just fine and all clients got the update, but when I look at the deployment package it just shows as "In Progress" for distributing the content out to the other DP's located at my secondary sites.  Any idea where to look to see whats going on?

    ***EDIT***

    When I look under the content status for it, the message says "Distribution manager instructed Scheduler and Sender to send package SP0000F to child site "Secondary Site"

    Tuesday, October 28, 2014 3:49 PM

Answers

  • First note, that this is no different than 2007.

    Yes to pointing the clients that report to the secondary site (remember also that clients never really "belong" to a secondary site -- they always belong to the primary site and simply use the resource at a secondary site). You wouldn't really point it at your primary site server though, you would point it at your WSUS instance that your primary site's SUP is installed on (these may be the same, I'm just being very specific here).

    Yes you could also install a SUP (and WSUS instance) in your secondary site as well. The upstream configuration will be set and enforce by ConfigMgr automatically.

    The choice between the two really comes down to where you want the clients to get the update catalog from. The initial catalog download is usually 10-20MB with changes coming down as deltas -- all catalog downloads are done using BITS. Thus, assuming you put the secondary site in because you are concerned about bandwidth, it probably makes sense to also add the SUP to the secondary site but it isn't technically required.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Joyce L Monday, November 3, 2014 8:41 AM
    • Marked as answer by Joyce L Friday, November 7, 2014 7:50 AM
    Wednesday, October 29, 2014 3:50 PM

All replies

  • So the sender is now distributing the files to the secondary site. That might take a while depending on the size and available bandwidth.

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, October 28, 2014 4:06 PM
  • True, I jumped the gun and it finally made it to the DP.  But now the client is not getting the package.  Any ideas?
    Tuesday, October 28, 2014 4:37 PM
  • on the primary site server, open the log "sender.log". Does it show that it is attempting to to write to the secondary site DP ("Attempt to write xx bytes" / "Wrote xx bytes")?
    Tuesday, October 28, 2014 4:38 PM
  • Yes it sent the files and its now showing it completed.  But now the client is not receiving the package.  I manually ran the machine policy retrieval and the software updates deployment evaluation cycle and it never shows up in Software center.  Not sure where to go from here.
    Tuesday, October 28, 2014 4:44 PM
  • Do I need to have WSUS role installed and SUP role running on Secondary site servers in order to push windows updates to PC's at the secondary site or no?
    Tuesday, October 28, 2014 5:40 PM
  • WSUS and SUP are required at the Primary Site. You can have a SUP at the secondary, but it is not required.

    Check the logs to see if there is activity: WUAHandler.log, UpdatesHandler.log, UpdatesDeployment.log

    Tuesday, October 28, 2014 5:44 PM
  • It shows a couple things under there, but nothing that really jumps out as it actively doing anything.  I have noticed that at all of my secondary sites it never shows what clients are compliant or not for updates, it always just shows them as unknown.
    Tuesday, October 28, 2014 6:06 PM
  • Check wuahandler.log on those clients. They must scan against the WSUS database available from the WSUS instance in your primary site (since you don't have a WSUS instance in your secondary site).

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, October 28, 2014 6:11 PM
  • All I see in the WUA handler on the client are lines and lines of the same thing, they all show this:

    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 12:17:36 PM 3904 (0x0F40)

    And when I look at the deployment under monitoring it just shows "Unknown" for the deployment.
    Tuesday, October 28, 2014 6:26 PM
  • There must be other information in this logfile ... also examine windowsupdate.log and check if it's scanning against the SUP.

    Torsten Meringer | http://www.mssccmfaq.de

    Tuesday, October 28, 2014 7:11 PM
  • Well one thing I did notice is that none of the clients at the secondary sites have the Intranet address for windows updates section in group policy.  Why would these not take affect on secondary site clients, but show up on my primary site clients?
    Tuesday, October 28, 2014 8:15 PM
  • in group policy

    Do you mean in their local group policy? Have you directly checked the registry?

    Also, as Torsten pointed out, there must be more in wuahandler.log. A single line doesn't mean anything really. Can you post the entire log?


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, October 29, 2014 12:46 PM
  • Yes, when I log in to a client here at my primary site and look in Start > Run > gpedit.msc and go to Computer configuration > Administrative Tools > Windows Components > Windows Updates I can see where it says "Specify intranet Microsoft update service location" and it shows my Primary Site server.  However, if I go to that same spot on my clients at my secondary site (except for one client that is actually working correctly) it doesn't show anything in that field, it just says "Not configured."  Its almost like all my clients at my secondary site have no clue where to go for anything.

    As for the WUAHandler.log it literally only has 7 entries and they are all the same, here is the entire log:

    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 2:27:56 PM 4832 (0x12E0)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 2:31:38 PM 1352 (0x0548)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 3:47:28 PM 3648 (0x0E40)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 4:59:05 PM 2212 (0x08A4)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/28/2014 7:47:38 PM 924 (0x039C)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/29/2014 12:47:26 AM 3572 (0x0DF4)
    CWuaHandler::SetCategoriesForStateReportingExclusion called with E0789628-CE08-4437-BE74-2495B842F43B;E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for leaves and E0789628-CE08-4437-BE74-2495B842F43B,A38C835C-2950-4E87-86CC-6911A52C34A3; for bundles WUAHandler 10/29/2014 5:47:35 AM 3328 (0x0D00)

    Wednesday, October 29, 2014 3:17 PM
  • What version of ConfigMgr 2012 (RTM, SP1, or R2)?

    I know there have been bugs in the past depending upon the order you added roles and the secondary site.

    An easy work-around at this point though is to simply assign the proper location using a group policy (local or domain, doesn't matter although domain would be easier).


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Wednesday, October 29, 2014 3:21 PM
  • I've considered that, but I'm rather confused with 2012 as to what a secondary site is actually capable of.  So do I just point all clients at all locations back to my Primary site server as the update point or can I install the SUP role on the secondary sites, tell my secondary site servers to use my upstream Primary site as the WSUS master and then point all my clients to the secondary site server?  (Hope that makes sense and isn't confusing)

    ***EDIT***

    Sorry, just seen your question.  This is SCCM 2012 R2

    Wednesday, October 29, 2014 3:25 PM
  • First note, that this is no different than 2007.

    Yes to pointing the clients that report to the secondary site (remember also that clients never really "belong" to a secondary site -- they always belong to the primary site and simply use the resource at a secondary site). You wouldn't really point it at your primary site server though, you would point it at your WSUS instance that your primary site's SUP is installed on (these may be the same, I'm just being very specific here).

    Yes you could also install a SUP (and WSUS instance) in your secondary site as well. The upstream configuration will be set and enforce by ConfigMgr automatically.

    The choice between the two really comes down to where you want the clients to get the update catalog from. The initial catalog download is usually 10-20MB with changes coming down as deltas -- all catalog downloads are done using BITS. Thus, assuming you put the secondary site in because you are concerned about bandwidth, it probably makes sense to also add the SUP to the secondary site but it isn't technically required.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Joyce L Monday, November 3, 2014 8:41 AM
    • Marked as answer by Joyce L Friday, November 7, 2014 7:50 AM
    Wednesday, October 29, 2014 3:50 PM
  • OK I guess I'll try that then so I can see if the software updates will actually work.  Its just odd because my Primary Site server clients work just fine, but none of my secondary site clients will even find the update I've pushed out.  Is there something in particular I need to do when discovery clients?  I thought someone said you can only manage clients you've discovered?  I just ran an active directory system discovery from my Primary site server and then used an AD boundary and an IP address range boundary to put clients in the correct site.  Is that the correct way to do it?  Also I noticed on the client push install settings under installation properties they all say SMSSITECODE=<Primary Site Server> even if they are located at a secondary site.  Is this correct or could this be causing an issue?
    Wednesday, October 29, 2014 4:22 PM
  •  Also I noticed on the client push install settings under installation properties they all say SMSSITECODE=<Primary Site Server> even if they are located at a secondary site.  Is this correct or could this be causing an issue?

    That's perfectly fine.

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, October 29, 2014 4:32 PM
  • As mentioned, this is most likely a bug. Clients reporting to your secondary site should (if your secondary site does not have a SUP) be automatically pointed to the WSUS instance from the primary site by their client agent via the client policy.

    This has nothing to do with discovery. Also as mentioned above, clients never belong to secondary sites and thus will all have the site code of the primary.


    Jason | http://blog.configmgrftw.com | @jasonsandys


    Wednesday, October 29, 2014 4:35 PM
  • OK thanks, I'll give it a try and see what happens.  Right now I've went ahead and removed the SUP role from both of my secondary site servers so all of my clients should go ahead and look back to my primary site server for all of their updates.  I'm going to go ahead and make a GPO that points them all back to my primary site and see if that doesn't fix it.
    Wednesday, October 29, 2014 6:19 PM