locked
Replacing Stand-alone Primary site with new server and site code - will the clients pick up new site code RRS feed

  • Question

  • Hi all- we have a bit of an odd scenario we will be doing.  We currently have one primary site and and 11 secondary sites in the US.  Again, we have an odd scenario and as a result we are planning these changes.

    1. The current PRI server will go away and will be replaced with a clean install and new site code (Basically starting with a clean infrastructure)
    2.  We will also being adding a second PRI server for a new (and future additional) international offices).
    3. Of course the secondary site servers will eb redeployed when the new PRI server is operational.

    That being said my questions are:

    1.  For the clients currently deployed, will the site code change auto once we replace the PRI server and set the boundaries?  If not, would it be suggested to push the agent out again or simply a script to change the site code?
    2.  Any red flags, besides this being a very odd thing to do ;)

    Thanks!

    Thursday, August 28, 2014 9:51 PM

Answers

  • No, client's will never reassign themselves automatically to another primary site. You could use the same site code for the new site but then you can never be sure if something is lingering.

    Why would you create another primary site? That's not the purpose of primary sites. Primary sites are for scale out in terms of clients supported and unless you have 100,000+ clients to manage, there's not technical reason to use multiple primary sites. And in fact, there are technical reasons why you shouldn't use multiple primary sites.

    Also, why of course on the secondary sites? In many/most cases, a remote DP is more than sufficient to handle the traffic for remote clients.


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

    • Marked as answer by Danny206 Friday, August 29, 2014 2:30 AM
    Friday, August 29, 2014 1:03 AM

All replies

  • No, client's will never reassign themselves automatically to another primary site. You could use the same site code for the new site but then you can never be sure if something is lingering.

    Why would you create another primary site? That's not the purpose of primary sites. Primary sites are for scale out in terms of clients supported and unless you have 100,000+ clients to manage, there's not technical reason to use multiple primary sites. And in fact, there are technical reasons why you shouldn't use multiple primary sites.

    Also, why of course on the secondary sites? In many/most cases, a remote DP is more than sufficient to handle the traffic for remote clients.


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

    • Marked as answer by Danny206 Friday, August 29, 2014 2:30 AM
    Friday, August 29, 2014 1:03 AM
  • Jason, great point.  It's been one of those days... weeks!

    The reason for the secondary site servers vs a remote DP was mainly the heavy use of state migration role at our regional offices.

    I think you are right on with forgetting about the second primary site server and possibly utilizing a remote DP instead.  The main purpose of this is to address our DirectAccess clients (which is significant for our mobile work force).  We would place the DP in a IaaS situation (or Azure DP) so the DirectAccess clients would be accessing content from there pipe rather then our on-prem infrastructure.  Does that make sense?

    In terms of reassigning the clients to the new site (we would prefer a clean site code) - any suggestions.  I can think of a few ways to archive, but a best practice is always good.

    Thanks again!

    Friday, August 29, 2014 2:37 AM
  • Secondary sites have nothing to do with SMPs. You can have remote SMPs just like you can have remote DPs.

    Hosting a DP in Azure IaaS is not supported. There is however a Cloud DP option: http://technet.microsoft.com/en-us/library/jj613909.aspx

    For the new site code, you can either use a script (pushed by the old site) to reassign the client agent or you can use client push to push the client from the new site in effect changing its site code (unless you have a GPO in place assigning the site code then you'll have to strip the values from the registry first because it doesn't use a real group policy).


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

    Friday, August 29, 2014 1:13 PM
  • Jason thanks for all the info - I really appreciate the time and basically consulting session :)

    So if I were to propose something along the scenario below, does that make sense?

    1 PRI Site
    Remote DP's for each office (still allows for PXE Boot, State Migration)
    Azure DP (with network boundaries defined for DirectAccess clients)

    Thanks for the feedback!

    Friday, August 29, 2014 3:36 PM