locked
R2 Clients cannot be assigned to SP1 sites (during SP1-R2 upgrade) RRS feed

  • Question

  • We've upgraded our CAS from 2012 SP1 to 2012 R2, but we still have all the Primary Sites in that hierarchy running SP1 (an iterative process to upgrade them). The CM Client install (2012 R2) gets automatically pushed throughout when you upgrade the CAS, which we expected. However, new Operating System Deployments are getting the R2 client (also expected) and failing to get site assignment on the SP1 sites. Reading through an interoperability article (http://technet.microsoft.com/en-us/library/jj822985.aspx), I take it that R2 clients on SP1 sites are supported with SP1 "reduced" functionality.

    Client to down-level management point communications

    • A Configuration Manager client that communicates with a management point from a site that runs a lower service pack version than the client can only use functionality that the down-level version of Configuration Manager supports. For example, if you deploy content from a System Center 2012 R2 Configuration Manager site to a System Center 2012 R2 Configuration Manager client that communicates with a management point that is installed at a secondary site that has not yet upgraded to System Center 2012 R2 Configuration Manager, that client cannot use new functionality from System Center 2012 R2 Configuration Manager.

    However, we're seeing new systems with the R2 client in SP1 sites failing to get assigned:

    <!-- clipped from the ClientIDManagerStartup.log--> OS Version: 6.1 Service Pack 1 ClientIDManagerStartup 12/16/2013 10:33:06 AM 1992 (0x07C8) SCCM Client Version: 5.00.7958.1000 ClientIDManagerStartup 12/16/2013 10:33:06 AM 1992 (0x07C8) <!-- clipped from the LocationServices.log --> The MP name retrieved is 'blah' with version '7804' and capabilities '<Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities>' LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) MP 'blah' is compatible LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) The MP name retrieved is 'blah' with version '7804' and capabilities '<Capabilities SchemaVersion="1.0"><Property Name="SSLState" Value="0"/></Capabilities>' LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) MP 'blah' is compatible LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) Lookup Management Points from AD: LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) Name: 'blah' HTTPS: 'N' ForestTrust: 'N' LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) Name: 'blah' HTTPS: 'N' ForestTrust: 'N' LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) Retrieved lookup MP(s) from AD LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) LSGetSiteVersionFromAD : Successfully retrieved version '5.00.7804.1000' for site 'EQM' LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) LSIsSiteVersionCompatible : Site Version '5.00.7804.1000' is not compatible. LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) LSIsSiteCompatible : Site <EQM> Version '5.00.7804.1000' is not compatible. LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38) LSVerifySiteAssignment : Client cannot be assigned to site <EQM>. LocationServices 12/15/2013 11:19:25 PM 2872 (0x0B38)



    • Edited by Olaf Gradin Wednesday, December 18, 2013 2:39 PM Added additional data supporting client version
    Wednesday, December 18, 2013 2:33 PM

Answers

  • I think you're onto something, Jason. The official response I've gotten points to another article that hasn't yet been updated for R2:

    http://technet.microsoft.com/en-us/library/jj822197.aspx

    "Client installation package

    • The source for the default client installation package is automatically upgraded to the Configuration Manager SP1 version and all distribution points in the hierarchy are updated with the new client installation package, even on distribution points at sites in the hierarchy that have not yet been upgraded to SP1.
    • Clients that run SP1 cannot be assigned to sites that have not yet been upgraded to SP1. Assignment is blocked at the management point."

    Regarding the material clipped at the beginning of this post, my technician informs me it only pertains to Secondary Sites. I'm scratching my head about how/why a Secondary Site in the midst of an R2 upgrade would accept R2 clients, but I think it's case-closed at this point. I hope (and part of the intention of writing this post was to contribute to this) that the upgrade documentation includes this limitation.

    • Marked as answer by Olaf Gradin Monday, January 6, 2014 9:41 PM
    Monday, January 6, 2014 7:02 PM

All replies

  • "The CM Client install (2012 R2) gets automatically pushed throughout when you upgrade the CAS, which we expected."

    This is not an accurate statement. The upgrade will only get pushed if (and only if) you have automatic upgrade enabled. This should have been disabled before starting the upgrade.

    How many primary sites do you have that it is taking that long to upgrade them that this is causing an issue though?


    Jason | http://blog.configmgrftw.com

    Wednesday, December 18, 2013 3:57 PM
  • I didn't say that quite right. I mean to say that the R2 bits are pushed automatically to all the distribution points within the hierarchy - presumably during the site reset. That client won't actually get installed anywhere unless, like you say, you automatically or manually upgrade. In the case of OSD, the built-in Task Sequence step will use the default SCCM client that is automatically made available by the CAS software level. So in our case, existing clients are having no issue. New OS deployments, which are limited right now, are getting clients that don't work.

    Regarding the quantity and timing of site upgrades, it's not entirely relevant. At my company, we're currently in a change "freeze" period for production systems and won't be able to upgrade certain sites until next year when the freeze is lifted. For now, we're working in the context of non-production site that we *can* make changes to. My concern over the client interoperability problem is one that will not actually affect us until January (because sites that are protected by the freeze aren't getting new systems provisioned either), but will be a bad time to deal with problems like this that we're creating here at the end of 2013.

    Wednesday, December 18, 2013 4:17 PM
  • Well, that sort of makes sense, but the timing and quantity is relevant because the decision to space out the upgrades to R2 was a bad one (as was having that many primary sites and a CAS unless you have 100,000+ managed clients) -- there is a base assumption that folks will be upgrading their entire hierarchy in short-order. Add this as reason #1,756 not to use multiple primary sites and a CAS also.

    At this point you are stuck though. Only way I can see through is to create a new client package for use with your task sequences -- there's no explicit reason to my knowledge that you must use the built-in package. You should be able to grab the bits off of one of the non-upgraded site servers. Make sure to use this package for any other client deployment tasks that you have also.


    Jason | http://blog.configmgrftw.com

    Wednesday, December 18, 2013 4:27 PM
  • I guess I'm still hung up on the text I captured from the article referenced in original post. Am I reading the intent of that incorrectly, or is the scenario of an R2 client talking to a down-level MP supported (with caveat)?
    Wednesday, December 18, 2013 4:34 PM
  • R2 is not a service pack, it is a completely new version of ConfigMgr and they may have explicitly precluded this in the code because R2 is not a free upgrade. Based on the above log snippet, that seems to me what is going on.

    Jason | http://blog.configmgrftw.com

    Monday, January 6, 2014 4:16 PM
  • I think you're onto something, Jason. The official response I've gotten points to another article that hasn't yet been updated for R2:

    http://technet.microsoft.com/en-us/library/jj822197.aspx

    "Client installation package

    • The source for the default client installation package is automatically upgraded to the Configuration Manager SP1 version and all distribution points in the hierarchy are updated with the new client installation package, even on distribution points at sites in the hierarchy that have not yet been upgraded to SP1.
    • Clients that run SP1 cannot be assigned to sites that have not yet been upgraded to SP1. Assignment is blocked at the management point."

    Regarding the material clipped at the beginning of this post, my technician informs me it only pertains to Secondary Sites. I'm scratching my head about how/why a Secondary Site in the midst of an R2 upgrade would accept R2 clients, but I think it's case-closed at this point. I hope (and part of the intention of writing this post was to contribute to this) that the upgrade documentation includes this limitation.

    • Marked as answer by Olaf Gradin Monday, January 6, 2014 9:41 PM
    Monday, January 6, 2014 7:02 PM