locked
New ConfigMgr Site; what happens with the client assignment RRS feed

  • Question

  • Hi,

    At a customer site we are trying to upgrade the ConfigMgr 2012 (no R2) site to a new ConfigMgr site server (1710) based on Windows Server 2016.

    Now, I have quick question regarding the Client assignments, just to validate if we can run in any issues..

    The old site is published into the Active directory, at this stage all the boundaries are defined on these server using IP address ranges or AD sites and Services. Clients are installed with an Auto MP assignment, so they find the site using AD. We want to create a new ConfigMgr site, publish this site also into the Active Directory (site codes are different). Then two sites are published into Active Directory. We then delete the corresponding IP (at first test) subnet from the boundaries of the old site server and place them on the new Site Server. We will then transition the old content (and cleanup) to the new site server and recreate stuff where it is necessary, but this takes some time. 

    The question is; can we expect issues while the old SCCM client when this is setup, will they still be targeted to the old ConfigMgr server? And will the new installed SCCM Clients (in the corresponding boundaries) automatically target to the new Site server if the boundary is not there anymore on the old ConfigMgr site?

    Any ideas?

    Thanks 

    Friday, January 26, 2018 8:06 AM

Answers

  • > "The old site."

    How do you have an old site if you are upgrading? It sounds like you are migrating. If so, why? That's the path involving the most work and possible issues.

    > "Clients are installed with an Auto MP assignment, so they find the site using AD."

    How is client installation being performed and why rely on auto-site assignment at all? You know which site it belongs to, so assign it at install time.

    > "We then delete the corresponding IP (at first test) subnet from the boundaries of the old site server"

    Why? All you have to do is remove the boundary from any boundary groups marked for site assignment. Also, why use IP Subnet boundaries -- they are problematic at best.

    > "recreate stuff"

    Why recreate anything? An in-place upgrade solves everything that you've posed here.

    > "can we expect issues while the old SCCM client when this is setup"

    As long as you have no over-lapping boundaries marked for site assignment, then there are no issues with this specifically, but the entire process you laid out is questionable at best. There certainly may be some mitigating circumstances here, but strictly based on what's in the post, you've chosen the wrong path.

    References:

    https://home.configmgrftw.com/configmgr-site-backup-restore/

    https://home.configmgrftw.com/configmgr-site-server-os-instance-change/


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


    Friday, January 26, 2018 2:30 PM

All replies

  • > "The old site."

    How do you have an old site if you are upgrading? It sounds like you are migrating. If so, why? That's the path involving the most work and possible issues.

    > "Clients are installed with an Auto MP assignment, so they find the site using AD."

    How is client installation being performed and why rely on auto-site assignment at all? You know which site it belongs to, so assign it at install time.

    > "We then delete the corresponding IP (at first test) subnet from the boundaries of the old site server"

    Why? All you have to do is remove the boundary from any boundary groups marked for site assignment. Also, why use IP Subnet boundaries -- they are problematic at best.

    > "recreate stuff"

    Why recreate anything? An in-place upgrade solves everything that you've posed here.

    > "can we expect issues while the old SCCM client when this is setup"

    As long as you have no over-lapping boundaries marked for site assignment, then there are no issues with this specifically, but the entire process you laid out is questionable at best. There certainly may be some mitigating circumstances here, but strictly based on what's in the post, you've chosen the wrong path.

    References:

    https://home.configmgrftw.com/configmgr-site-backup-restore/

    https://home.configmgrftw.com/configmgr-site-server-os-instance-change/


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


    Friday, January 26, 2018 2:30 PM
  • We are indeed recreating and migrating stuff. The reason why we use this longer option is that the current site server is still Windows Server 2008R2 and there is also allot of garbage in the ConfigMgr environment which we don't need (and basically don't want to clean up).

    We don't want to do an inplace upgrade of the Site server to 2016 coming from 2008R2, but it is ofcourse an migration method that is possible when we first upgrade it to 2012R2 (also need to upgrade SQL server then, this one is also still 2008). I think this part is more risky basically then the option with a new site server.

    This environment is being created for a new project where we going deploy Windows 10 devices, the old clients and servers will eventually be changed to newer operating systems and platforms. On the old servers we also don't want to upgrade the SCCM client, this because  the customer don't want to upgrade .Net framework from version 4 to version 4.5 on all clients and servers. They still use legacy applications where they know it is not compatible, this upgrade is part of another project. 

    But you gave me an answer that when there are no overlapping boundaries, that there are no issue's expected with the current ConfigMgr clients when we introduce a new site server where it is active directory published. 

     


    Friday, January 26, 2018 4:47 PM
  • > "The reason why we use this longer option is that the current site server is still Windows Server 2008R2"

    That is not a good reason to migrate.

    > "there is also allot of garbage in the ConfigMgr environment which we don't need (and basically don't want to clean up)."

    That's not valid either IMO. A migration won't migrate everything that you need and you'll still end up migrating things you think are garbage meaning you end up doing even more work.

    > "We don't want to do an inplace upgrade of the Site server to 2016 coming from 2008R2"

    No one said you had to.

    > "the customer don't want to upgrade .Net framework from version 4 to version 4.5 "

    The .NET Framework 4 hasn't been supported for two years so they've got bigger issues. If this is truly a limiting factor, then it's costing the org pain, time, and money and it should be clearly called out as this is a terrible limiting factor.


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

    Friday, January 26, 2018 5:46 PM
  • >> "The reason why we use this longer option is that the current site server is still Windows Server 2008R2"

    >That is not a good reason to migrate.

    It's one of the reasons. 1710 doesn't support 2008R2 and SQL 2008, also 2008R2 is only still in extended support till beginning 2020. This is one reason to start upgrading Operating Systems and not to stay with 2008R2. All other servers are also being upgrade to 2016, so it is also part of a bigger plan.

    >> "there is also allot of garbage in the ConfigMgr environment which we don't need (and basically don't want to clean up)."

    >That's not valid either IMO. A migration won't migrate everything that you need and you'll still end up migrating things you think are garbage meaning you end up doing even more work.

    I don't agree. We start the Windows 10 (only surfaces in the new setup) and server builds as greenfield. So no stuff is being copied if it is not being used somewhere in the new deployments. So the chance is not very big, almost none, that the environment is being polluted.

    >> "We don't want to do an inplace upgrade of the Site server to 2016 coming from 2008R2"

    >No one said you had to.

    Correct. But we don't prefer this upgrade path, it would also take more upgrade steps with more risks. So we do a new installation besides it, the risk is then also way less (but involves more clicking to create things :) ).

    >> "the customer don't want to upgrade .Net framework from version 4 to version 4.5 "

    >The .NET Framework 4 hasn't been supported for two years so they've got bigger issues. If this >is truly a limiting factor, then it's costing the org pain, time, and money and it should be clearly >called out as this is a terrible limiting factor.

    You're correct. It would also be my method that we upgrade the .Net framework to 4.5.2 and therefore upgrade the ConfigMgr clients (because the upgrades does not give you much issue's anymore), but the customer want to avoid this path and choses for a platform upgrade in the upcoming months and leave everything as is. 





    Friday, January 26, 2018 6:06 PM
  • You're still missing the preferred path here which does not require any in-place upgrades of the OS: backup and restore. It's quicker and requires far less work than a migration. The time saved by doing a backup and restore can be used to clean up -- I think you'll find there is far more that you'll be keeping than you think -- there always is.

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

    Friday, January 26, 2018 6:21 PM
  • Thanks. It is always easy to migrate data from one site to another, it is easy to connect two sites and copy everything..that is not the big issue. But to use a site recovery for a platform upgrade, I never used that method. How should the main steps looks like then? Because, as far as I can see, you cannot perform a restore if the platform is not running on the same version? e.g. you need to be on the same SQL version where you are restoring to or does this not matter (https://technet.microsoft.com/en-us/library/gg712697.aspx#BKMK_RecoverSite) ?

    Thanks!

    Friday, January 26, 2018 7:48 PM
  • > "It is always easy to migrate data from one site to another,"

    Except that a migration doesn't actually migrate everything and leaves you with lots of work to do including re-deploying clients (which causes historical data loss), migrating or re-deploying DPs (both of which can be problematic), and problems hard-coded site codes to just name a few things I see regularly. Calling this one easy is asking for trouble.

    > "Because, as far as I can see, you cannot perform a restore if the platform is not running on the same version"

    This is not correct. The OS can absolutely be up-level. In-place upgrades of SQL are painless and ultra-reliable.

    Please just read the blog posts I linked to. All of this is in them.


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

    Saturday, January 27, 2018 12:07 AM
  • Thanks for the reply; At this customer site mostly servers are added to ConfigMgr, and primarily patch management being used, nothing else. Most normal clients are Thin clients now. OS deployment was there only for the creation of a Citrix master image only, which we don't use in the future. We are now building a new modern management workplace where everything is SaaS and Office 365

    But we always test our procedures at first (or we accept risks), so I never used this method before as a site server migration, I always migrated objects to a new site server and renewed the ConfigMgr clients. I will look into this! Thanks! 

    Saturday, January 27, 2018 7:34 AM
  • It's a better way IMO, but there are also always possible mitigating factors like the .NET compat issue that you raised. It's good to have options, and ultimately, my point here is that you do have options so don't consider migration your only path forward.

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

    Saturday, January 27, 2018 4:29 PM