locked
Heirarchy Change at Migration RRS feed

  • Question

  • Two Questions....

    1. We have a simple setup with 1 primary parent and 4 primary child sites. This is or "political reasons" and also because much of the administration is done from the parent primary. Also, packages and collections are placed here where they trickle down to the child sites and the other admin can manage their machines with that stuff. Also organization-wide reports are available in one place.

    Since i need a CAS, I was debating doing away with my primary parent and simply having a CAS with 4 primaries. Obviously, I would move the clients from the primary parent to another site and lock them down with the new role based administration (thank "goodness" for this change). I don't foresee any issues doing it this way but out of concern that we may need a primary parent I am reluctant to eliminate it. Am I over thinking the issues with my hierarchy or is this a no brainer given my existing heirarchy?

    2. Also more than one webinar that we've done "skimmed" over scenarios that are not supported to migrate. I heard on instructor say that its not supported to migrate a hierarchy that (in hindsight) sounded like mind. I haven't run across this in any of the documentation but having heard this twice its enough to be of concern. Are there any unsupported migration scenarios?

    Monday, March 25, 2013 10:06 PM

All replies

  • Hi,

    1. Why do you need a CAS? a CAS is primarily for scaling out scenarios where you have more than 100'000 clients. With SP1 for Configuration Manager 2012 you can add  a CAS afterwards if you need one.

    2. Otherwise, yes it will work fine to migrate to a new configmGr 2012 hierarchy.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Monday, March 25, 2013 10:15 PM
  • I kicked around the idea of a cas because of the multiple primary sites. if sp1 lets us add this later we will take that into consideration. technically, we coupd have one big site but we have different support groups that often step on each others toes (yeah its like that). also with the all or nothing type of permissions it made it easy with multiple sites in 2007. the role based administration could change this. with 30000 computers I know this setup is overkill that's why in my hierarchy scenarios that we are considering, the front runners all eliminate sites.
    Monday, March 25, 2013 11:27 PM
  • Role based administration does change this. Using primary sites for delegation or segregation in 2012 is not valid because it doesn't work that way at all. A primary site in 2012 is not the same thing as a primary site in 2007 and thus designing your hierarchy based on what you had in 2007 is invalid.

    Multiple primary sites don't add functionality in any way so it's not overkill when you do so (they don't expand computing power or anything along those lines); however, adding multiple primary sites will add latency and overhead to everything that you do. Primary sites are almost completely about scalability in terms of number of managed clients: 100,000 per primary site. Unless you are going to go over this or if you have large grouping of clients (10,000+) separated by poor connectivity, using multiple primary sites is a poor decision not based on primary sites actually do in 2012.

    It's a no brainer not to use multiple primary sites and thus not to use a CAS. Unless you have an explicit reason to use multiple primary sites, you should not do so.


    Jason | http://blog.configmgrftw.com

    Tuesday, March 26, 2013 2:39 AM
  • Thanks jason, You're right I shouldnt have used "overkill". Over-complicated is more appropriate. However, the setup that I am migrating from is grossly over-complicated and I am searching for ways to consolidate without affecting the day to day flow of the techs and also the performance.

    More reasons why we had multiple primary sites: each group has different task sequences advertised to unknown computers. They freak out when anything new shows up in the list that they don't recognize. Heaven forbid I test something that shows up where someone can see it and panic as to how it got there. This makes it easier so that they only see what they create on their site. Also different groups manage computers that check in at different intervals. Because they are on different sites, I can set different heartbeat intervals and maintenance windows for each site according to how the clients behave. Also one of the sites manages computers that are not on the domain which means that they would have to manually approve every single computer that gets a client pushed to it. 

    I'm not justifying keeping the extra sites but looking back at why it was setup that way, it probably did make things simple in 2007 but with 2012's changes it may eliminate the need to keep this setup. I did not plan our existing hierarchy so I understand that it is not the best for our environment but you have to play the cards that you are dealt and I would love to simplify things. waiting on changes to replicate up to the primary parent is a headache, and having 5 different servers to manage packages and collections is a pain.

    Tuesday, March 26, 2013 1:00 PM
  • Everything in you middle paragraph is not valid for primary sites in 2012:

    There is only a single set of unknown computer objects in a hierarchy (you shouldn't test using unknown if folks can't handle it though), clients settings in 2012 can not set on a site basis -- they are set on a collection basis, and client approval for workgroup systems has nothing to do with primary sites -- it had to be done no matter what unless you enable approval of all systems.

    As mentioned, a primary site in 2012 is not a primary site in 2007 -- they are two completely different things and it's invalid to design your hierarchy this way.


    Jason | http://blog.configmgrftw.com

    Tuesday, March 26, 2013 1:48 PM
  • Yes you are right that is how it is setup on that particular site. it approves all systems that join that site.

    Based on all that's been discussed I'll shift gears and consider consolidating to one site.  I had put a lot of faith in our existing infrastructure that it was setup in a relatively favorable way. I knew it wasn't optimal, but you guys opinions coupled with seeing the changes that 2012 offers have confirmed my suspicion that it may be easier to scratch everything and rebuild using fewer, more powerful servers with just one site and let the role based admin work its magic. If it turns out that one site doesn't get it done like Jorgen pointed out we can add it later. Thanks.

    Tuesday, March 26, 2013 2:54 PM