none
Windows Updates Not being deployed at remote location RRS feed

  • Question

  • I have a Primary SCCM CB in Chicago. 

    I have a Distribution Point set up in Sydney.

    I can deploy software and operating systems in Chicago and Sydney.  

    I set up a Software Update Baseline and deployed to Chicago no problem.  Sydney refuses to work.

    They had a GPO that pointed to an older WSUS server as we have in Chicago as well.  I added WMI Filtering on the GPO to only apply to the Windows 7 boxes that remain.  Windows 10 should then point to the SCCM server.  This is working in Chicago.  It is not working in Sydney.  

    LocationServices.log for Chicago PC shows entries such as Current AD site of machine is US, while Sydney logs show Unable to retrieve AD site membership. and ConfigMgr is no longer managing WindowsDO GPO..... 

    WUAHandler.log in Chicago shows immediate expected entries as soon as I run a Software Update Scan. Sydney logs show nothing.  

    I feel like I should have been able to figure this out by now.  I thought it was a Boundary issue, but ruled that out when I was able to install a new application.  I have removed the GPO all together from my test PC.  

    Anyone have any ideas?

    Matt 


    Matt Dillon

    Friday, February 8, 2019 9:25 PM

Answers

  • The General tab does not show anything in the Boundaries section.  Not sure if that is normal or not.  

    Yes, that's normal. Boundaries cannot be added to the default site boundary group because it's (as it's name implies) the default boundary group.

    As long as the updates are getting installed from sydney, ithink this should be resolved.

    As noted, they won't necessarily be because that server is also a DP if I understand your description correctly and so the clients may (based on a different set of criteria) choose the DP in Chicago over the DP in Sydney.

    Unable to retrieve AD Site membership in the LocationServices.log on Sydney PC's

    If you are not using AD site boundaries, this is irrelevant although this could influence a selection between two DPs by a client when both the site systems hosting those DPs are referenced in the same boundary group as it appears you have.

    I'm wondering if this has to do with Active Directory Sites and Services being incorrect. 

    Most  likely.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by pugmohone Monday, February 11, 2019 7:44 PM
    Monday, February 11, 2019 7:09 PM

All replies

  • I set up a Software Update Baseline

    Do you mean an update group and deployment on that group? Baselines are something different and don't deploy updates.

    This is working in Chicago.  It is not working in Sydney.  

    It's not unusual for removed group policies to not actually be removed on client systems. You need to examine systems there manually and/or check the wuahandler.log.

    Also, make sure that the boundary (or boundaries) for Sydney are included in a boundary group that references the site system or site server that holds the SUP role.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, February 8, 2019 9:54 PM
  • YEs.  Not a config baseline.  Just a software update group, etc.  

    boundary and boundary groups are good from what I can tell.  i have two boundary groups - us and sydney.  all sydney boundaries point to sydney bg and same for us.  

    Maybe giving it the weeknd will clear out the gpo's.  otherwise - i am stumped.  


    Matt Dillon

    Friday, February 8, 2019 10:34 PM
  • What type of boundary are you using AD (yuk), IP subnet (yuk) or IP Ranges (Good)?

    Garth Jones

    Blog: https://www.enhansoft.com/blog Old Blog: https://sccmug.ca/

    Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleashed

    Friday, February 8, 2019 10:58 PM
    Moderator
  • IP ranges the ad ones keep throwing themselves in there, but I have nothing assigned to them.

    Matt Dillon

    Friday, February 8, 2019 11:00 PM
  • That doesn't answer the question though, what kind are you actually using and have assigned to the boundary groups?

    Also, you wrote that the Sydney BG points to them and your boundary group points to you. That honestly doesn't mean anything. Can you be more specific? To be clear, I'm referring to whether a site server or site system containing the software update point role is associated with each boundary group?

    As for the GPOs, you need to examine the systems directly as once again, it's not unusual from the settings to linger even though the policies are removed particularly for Windows Update settings. Time won't change this but you need to directly examine the systems to rule this in or out. You can do this by checking the registry and the wuahandler.log on the clients.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, February 11, 2019 12:45 AM
  • It could be related to the client site mostly to me, as the machines are installing all but updates.

    It could be the WSUS server is not reachable from the Australia location, the Client side log - windowsupdate.log or WUAHandler.log should tell the same.

    May be the ports 8530 or 8531 (if default) or custom port may have the access enabled for those clients to communicate with the wsus server in the Americas ?


    Kamala kannan.c| Please remember to click “Mark as Answer” or Vote as Helpful if its helpful for you. |Disclaimer: This posting is provided with no warranties and confers no rights

    Monday, February 11, 2019 2:15 AM
  • I have IP Range Boundaries for the US Sites and they are assigned to the US Boundary Group that has the Primary Server assigned.

    I have IP Range Boundaries for the Sydney Sites and they are assigned to the SYD Boundary Group that has the SYD Distribution Point assigned. 

    The US Site is my Primary Site and has the Software Update Point role installed, among all the other roles (DP, MP, Reporting, Service Connection, Site Database, Site Server, and Site system)

    The SYD  Site has Distribution point and Site system role attached.  

    I know the Software/Windows Updates themselves are getting distributed to both of my sites.  

    Reading some of the comments here today, I am wondering if I need to :

    a) add the primary site to the SYD Distribution Point.

    b) add the Software Update Point role to the SYD server.  

    c) This may or may not be firewall related.   

    This is my first time setting Windows Updates up so there is a 100% chance I am not fully understanding what needs to be done and going by memory of what I have seen in the past.  Any and all suggestions are really appreciated.  

    I will verify the GPO that is actually being deployed.  

    The LocationServices.log is the one that has me stumped.  I will verify the Boundaries are correct.  Overlap should be fine from everything I read and all the Sydney boundaries point to the SYdney DP anyways.  

    The WUAHandler.log on the SYdney PC's does not show much of anything.  All I see is 4 entries that state CWuaHandler::SetCategoriesForStateReportingExclusion called with ...

    Matt 


    Matt Dillon

    Monday, February 11, 2019 1:37 PM
  • The US Site is my Primary Site

    No, not really. The US location may contain your primary site *server* but both locations are part of the primary site. Primary site != Primary site server and a location is not a ConfigMgr site.

    I will verify the GPO that is actually being deployed.  

    What GPO are you referring to? You shouldn't be using any domain GPOs to set the WSUS server.

    All I see is 4 entries that state CWuaHandler::SetCategoriesForStateReportingExclusion called with ...

    This takes me back to the question I keep raising (sorry, not to be rude, but that you keep ignoring): Is the site server or site system holding the SUP role associated with the boundary group for the Sydney location? If not, those clients will never be assigned to use a SUP or the WSUS instance where the SUP is installed. This log snippet is indicative of that not being the case.

    Without knowing more details on your intentions and infrastructure here, you need to add the site server (assuming that's the server holding the SUP role) to the default boundary group (on the reference page). This has other fallback implications though so be aware that if you don't want the clients in Sydney falling back for content, then you need to disable fallback on the default boundary group (or create a neighbor boundary group and disable it there).


    Jason | https://home.configmgrftw.com | @jasonsandys


    Monday, February 11, 2019 4:05 PM
  • Thank you for the response.  Sorry - I don't mean to ignore your question.  I thought I answered it, but I'll try again

    The SUP role is only on my Primary (US) Site - not the SYD DP.  In my response above, I asked the question, which is what I think you are saying to do, of  if I add the Primary Site (where the SUP role is installed) to the Sydney Boundary Group, I guess I would see the updates then.  My follow up question is this: 

    Will the Updates be installed from Chicago instead of Sydney if I do this even though they are distributed to the Sydney DP?  If so, I guess the follow up question is how do I get them them to ton install in Sydney from the Sydney DP?  

    I'm struggling with GPO's at the same time as I am setting this up so sorry for the delay in my response.  (I think I have the GPO's set) 

    To review my issue:

    All US Boundaries are part of US Boundary Group which has Primary Site as the assigned Site Server.

    All Sydney Boundaries are part of the SYD Boundary Group which only has SYD DP as the Site Server.  

    From what I am reading and from what I think I now understand is that I need to have the SUP role in both Boundary Groups for the Software Updates to be pushed.  

    Matt 


    Matt Dillon

    Monday, February 11, 2019 5:58 PM
  • The SUP role is only on my Primary (US) Site

    No, it's on the primary site *server* because there is a big difference between it being part of a primary site and being on the primary site server itself.

    if I add the Primary Site [server] (where the SUP role is installed) to the Sydney Boundary Group, I guess I would see the updates then.

    > You can't add a primary site, you can only add a primary site server. Once again, these are not synonmous terms and the distinctive is important.

    If you add the primary site server to the Sydney boundary group, then clients in Sydney may end up choosing the DP role co-located on the primary site server as well. That's why I called out adding it to the default site boundary group instead and possibly disabling fallback for the distribution point role to prevent Sydney clients from falling back to the DP on primary site server (if desired as maybe you do in fact want this).

    > Will the Updates be installed from Chicago instead of Sydney if I do this even though they are distributed to the Sydney DP?

    Binary files for updates always come from the DP based on the boundary groups. Update metadata (along with EULAs) come from the WSUS instance on the client's configured SUP.

    Thus, if you directly add the primary site server to the Sydney boundary group, they may come from either DP. If you instead add the primary site server to default site boundary group, the clients will choose the DP in Sydney first and only fallback to the DP in the US (unless as noted, you disable DP fallback on the default site boundary group).

    From what I am reading and from what I think I now understand is that I need to have the SUP role in both Boundary Groups for the Software Updates to be pushed.  

    Almsot. You don't add the SUP though, you add a site server or site system. Thus, all other roles co-located on that site server or site system would also be impacted (client location and use of those roles really) which is why you can't just think about the SUP.


    Jason | https://home.configmgrftw.com | @jasonsandys


    Monday, February 11, 2019 6:30 PM
  • I think I get what you are saying. 

    I added my Primary Site Server to Default-Site-Boundary-Group-SiteCode on the References tab.  The General tab does not show anything in the Boundaries section.  Not sure if that is normal or not.  

    I added my Primary Site Server to the Sydney Boundary Group.  This Boundary group has both my server in Chicago and the server in Sydney listed as Site system servers.  

    I seem to be getting updates as soon as I added the chicago server to the sydney boundary group.  As long as the updates are getting installed from sydney, ithink this should be resolved.  I appreciate the help. 

    I am going to examine the Sydney Boundaries a little closer as I still see Unable to retrieve AD Site membership in the LocationServices.log on Sydney PC's, bu the Chicago PC's show Current AD site of machine is US.  I'm wondering if this has to do with Active Directory Sites and Services being incorrect.  The Sydney office did get new IP addresses a few months back.  


    Matt Dillon

    Monday, February 11, 2019 6:54 PM
  • The General tab does not show anything in the Boundaries section.  Not sure if that is normal or not.  

    Yes, that's normal. Boundaries cannot be added to the default site boundary group because it's (as it's name implies) the default boundary group.

    As long as the updates are getting installed from sydney, ithink this should be resolved.

    As noted, they won't necessarily be because that server is also a DP if I understand your description correctly and so the clients may (based on a different set of criteria) choose the DP in Chicago over the DP in Sydney.

    Unable to retrieve AD Site membership in the LocationServices.log on Sydney PC's

    If you are not using AD site boundaries, this is irrelevant although this could influence a selection between two DPs by a client when both the site systems hosting those DPs are referenced in the same boundary group as it appears you have.

    I'm wondering if this has to do with Active Directory Sites and Services being incorrect. 

    Most  likely.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by pugmohone Monday, February 11, 2019 7:44 PM
    Monday, February 11, 2019 7:09 PM
  • I appreciate the help.  Updates are definitely installing in Sydney now.  Any idea how to check where the updates are getting installed from or how to make sure they get installed from Sydney in Sydney?  

    Matt Dillon

    Monday, February 11, 2019 7:12 PM
  • Well, moving the primary site server out of the Sydney boundary group and leaving it only in the default boundary group would guarentee this (except in fallback scenarios).

    However, you can check the logs on the local clients, the CAS.log or contenttransfermanager.log (don't remember which off-hand) will have the DP location in it used for each download.

    But, part of the selection criteria is random, so just because the client you check today is downloading from the Sydney DP doesn't mean it will do the same tomorrow or the next time which is why putting the site server in the default boundary group is a better option here (most likely -- I still say most likely because I'm not familiar with your enitre environment and goals).


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, February 11, 2019 7:24 PM
  • Hmm.  So just to clarify - if I have the primary server in the default-site-boundary-group and not the sydney group , i should still see the windows working in sydney.  I will check that out and let you know what happens.  

    Matt Dillon

    Monday, February 11, 2019 7:26 PM
  • Correct as the default boundary group is all about fallback behavior so in lieu of a SUP role directly associated with the Syndney boundary group, it would fallback to the default boundary groups site system and site server references.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, February 11, 2019 7:44 PM