locked
SCCM 2012 SP1 & SQL Same box and Hierarchy simplification question RRS feed

  • Question

  • Hi,

    I've been tasked with our SCCM 2007 - 2012 migration project, and I would just like to get peoples opinion on our scenario. We have about 5000 clients. 3500 of which are in our primary site.

    I've done plenty of reading, but I'm struggling to determine is whether to install SCCM on the same box as SQL 2012, or to put it onto a different site system? I don't think with 5000 clients that the server will ever be particularly overworked if we give it say 4-6 cores and 16gb ram, and i also understand that if this is the case it would be easier to use a snapshot to restore the server should anything bad happen - and the sccm backup/restore process doesn't work (i.e worst case scenario). Is there any benefit at all for having SQL on a separate server for a site of this size?

    Our current 2007 configuration Consists of 7 site servers, which 2 DPs and other roles are split between them one hosts the database. We also have 7 Secondary's with no more than 300 clients at each site. I thinking out current setup is overkill and am questioning whether it can/should be simplified. So my initial thoughts would be to have the following:

    - Primary Site server with SQL on box (2 DPs and 2 MPs on different site servers, one of each hosted in a different data center) and 2 other site servers with the other roles required on.

    - Distribution points rather than secondary’s at all of our other sites

    Any thoughts/Comments are greatly welcome. Thanks

    Friday, February 22, 2013 10:31 AM

Answers

  • I do not see any advantage in installing SQL on a separate box.

    You can go for the one server setup with the specs you specified. Make sure to configure SQL memory usage to use 50% of the available memory. Your total amount of RAM may be a bit on the low end depending on your actual configuration and usage of the features, but as you are running virtualized I assume it would not be too difficult to beef up the memory if needed in the future.

    Simplifying your infrastructure with a standalone primary and DP's sounds like a plan. Maybe check the pull DP functionality if you are running over slow WAN links.

    Friday, February 22, 2013 10:40 AM
  • Start out simple, then add the complexity of secondaries as needed.  A simple hierarchy tends to be more reliable than a complex one.  The DP is going to keep traffic down to a minimum.  In the future, you may decide that you need a secondary with additional roles on it for traffic reduction, but there's no need to deploy it ahead of time.

    Nicholas Jones, MCITP® | Core Infrastructure Consultant | Sparkhound | https://www.mcpvirtualbusinesscard.com/VBCServer/nicholas.jones/profile

    Friday, February 22, 2013 2:16 PM
  • Secondary sites have no resiliency mechanisms. If a secondary goes down, the clients in that secondaries boundaries are essentially orphaned until you can restore functionality. Using just a DP eliminates another single point of failure and also eliminates a hop from the content distribution path.

    Also that you mentioned putting two MPs in two different data centers. There is nothing specifically wrong with this as long as you understand that client location of MPs is not location aware (except between different forests).


    Jason | http://blog.configmgrftw.com

    Saturday, February 23, 2013 2:04 AM

All replies

  • I do not see any advantage in installing SQL on a separate box.

    You can go for the one server setup with the specs you specified. Make sure to configure SQL memory usage to use 50% of the available memory. Your total amount of RAM may be a bit on the low end depending on your actual configuration and usage of the features, but as you are running virtualized I assume it would not be too difficult to beef up the memory if needed in the future.

    Simplifying your infrastructure with a standalone primary and DP's sounds like a plan. Maybe check the pull DP functionality if you are running over slow WAN links.

    Friday, February 22, 2013 10:40 AM
  • Thanks,

    The server ram can be beefed up, that's not a problem.

    I know the powers that be are going to start getting 'upset' due to the change in the design I am proposing (rather than just replicating our 2007 environment set-up) so need to be sure i get my facts clear. 

    When would there be an advantage in having SQL on a separate box then? Is backup and restore easier if they are on the same box? If say for example there was a massive failure and i have to completely rebuild the server which hosted the Site and the DB, would it just be a case of installing SQL again, and then running the set-up and choosing the restore feature? Is it that simple? I will obviously test for myself but a brief answer from someone who has done it would be very helpful.

    Is there any drawbacks to using a DP rather than secondary site with 2012? Other sites just use software updates, distribution and OS deployment. Does hardware and software inventorys produce a lot of traffic upstream? should i be concerned with this?

    Here is our machine count and link speed to primary site

    Site 1 = (PCs - 3578) - Primary Site 

    Site 2 =  278 Pcs, 50mbps

    Site 3 = 145 Pcs, 100mbps

    Site 4 = 58 Pcs, 34mbps

    Site 5 = 191, 100mbps

    Site 6 = 125, 50mbps

    Site 7 = 26, 10mbps

    Site 8 = 229, 50mbps (Also our DR site)

    Again, really appreciate any comments

    Thanks


    Friday, February 22, 2013 11:40 AM
  • The advantage to running SQL Server remotely is that it allows for a greater number of clients.  Since you're no where near those numbers, it would be best if you run SQL locally.

    Start thinking of using Secondary sites when a remote location has over 500 computers (or if the network guys complain), otherwise you're probably fine with a DP.


    Nicholas Jones, MCITP® | Core Infrastructure Consultant | Sparkhound | https://www.mcpvirtualbusinesscard.com/VBCServer/nicholas.jones/profile

    Friday, February 22, 2013 1:16 PM

  • We may plan to manage macs too eventually though, as well as using endpoint protection and i do wonder what implication that will have in the future as our computer count at each site will obviously increase.. 

    And we plan on using endpoint protection which will add to the load i would imagine? 

    I do like the idea of the simpler structure though and at the moment it seems it will work. I don't really see our computer count increasing over 500 in any of our current sites though to be fair. However, i don't really see any drawback over just creating secondary sites at the sites anyway, even though they are not needed.

    I guess this leads me to another question.

    What would the benefit be with going with a distribution point rather than a secondary site, if we have less than 500 clients? Is there really much point in me changing how it is now and doing away with secondaries when i could just stick them in there anyway over a DP and probably get met with less friction from the powers that be?


    Friday, February 22, 2013 2:12 PM
  • Start out simple, then add the complexity of secondaries as needed.  A simple hierarchy tends to be more reliable than a complex one.  The DP is going to keep traffic down to a minimum.  In the future, you may decide that you need a secondary with additional roles on it for traffic reduction, but there's no need to deploy it ahead of time.

    Nicholas Jones, MCITP® | Core Infrastructure Consultant | Sparkhound | https://www.mcpvirtualbusinesscard.com/VBCServer/nicholas.jones/profile

    Friday, February 22, 2013 2:16 PM
  • Secondary sites have no resiliency mechanisms. If a secondary goes down, the clients in that secondaries boundaries are essentially orphaned until you can restore functionality. Using just a DP eliminates another single point of failure and also eliminates a hop from the content distribution path.

    Also that you mentioned putting two MPs in two different data centers. There is nothing specifically wrong with this as long as you understand that client location of MPs is not location aware (except between different forests).


    Jason | http://blog.configmgrftw.com

    Saturday, February 23, 2013 2:04 AM
  • Thanks for your help guys, its very much appreciated.

    Will go with DPs then, it definitely seems the better option for our environment.  And SQL will go on the box.

    Jason, the reason I made a point about the distribution points and management points being in a different data center, stems from my initial thoughts (and they were literally just that) that if I did this, it would result in some sort of redundancy if one of the data centers (i,e the one hosting the site system and DB) was to have a severe problem, as we would still have an MP and DP available for clients to find...

    Its become apparent to me that this would not be the case anyway, as in that scenario the site server and obviously the DB wouldn't be available to the MP and DP either if this happened, and therefore they would not be of any real use anyway. Besides, if a data center went down there would be a lot more to worry about than SCCM that's for sure.

    Could you, or anyone else reading please confirm if what has become 'apparent' to me, is in fact correct?

    Thankyou

    Saturday, February 23, 2013 10:09 PM
  • Besides, if a data center went down there would be a lot more to worry about than SCCM that's for sure.

    This is a major point folks never seem to realize; glad you got it on your own :-)

    Do note however, that putting the MP and DP is different data centers is still valid for availability purposes. Neither technically needs the DB for serving client requests as the MP caches policies and content location and of course the DP already its content. You won't be able to add or servicing anything new, but existing clients will still maintain current functionality and allow normal client activity to continue.


    Jason | http://blog.configmgrftw.com

    Sunday, February 24, 2013 10:20 PM
  • I see.. OK then great, will implement it like that so we have availability.

    I did in fact have the meeting this morning and put forward my plan and reasons and all is good, so thanks for all your help! Its been valuable.

    And Jason, SCCM Unleashed which I see is partly written by you is a brilliant source of info for SCCM. Would highly recommended to others. Great stuff and has helped me a lot.


    Tuesday, February 26, 2013 5:13 PM
  • And Jason, SCCM Unleashed which I see is partly written by you is a brilliant source of info for SCCM. Would highly recommended to others. Great stuff and has helped me a lot.

    Thank You! Glad to help.

    Jason | http://blog.configmgrftw.com

    Tuesday, February 26, 2013 8:32 PM