SCCM2007 - splitting system roles

[sonofsanta]

I am currently managing about 4 minutes of reading TechNet before I suddenly find myself distractedly reading something else, so whilst I try and force myself to read through that, I thought I'd ask here - seems like a few have gone through this before me so if I ask nicely maybe y'all can share some of that hard-earned wisdom

 

Setting up SCCM2007 on a new 2008R2 server here, really so that I can have SCVMM ready to run some Hyper-V hosts across two other physical servers, but I want SCCM set up properly as well. The server I'm setting up on is the physical DC for the new virtual infrastructure. We run about 400 clients, 1100 users, so not a massive network but still pretty reasonable.

 

So my point is: I would prefer to have as much running on Hyper-V as possible, for failover and easy backup etc., but with SCCM needing to run on the physical host anyway, is it better having it all on one box for integration? Or does SCCM really prefer being split up a bit for load-balancing? The physical server has a 2Gb connection where the 2 virtual hosts will have 8Gb each (although this will have to cover all the VMs), so software deployment might be better from the virtual hosts, where they will have SAN sized storage and faster links. In that case, does the SUP role (with WSUS) want hosting on the same virtual box as the distribution point?

 

Also - and this point could render the whole discussion moot - I assume that the SCCM licence allows for the roles to be split like this, or am I meant to buy a full SCCM licence for every instance?

 

What I'm really asking, I suppose, is how you've all done it, and how you'd do it differently if you would. Is one server fine for a school-sized network, or are there benefits to be gained from splitting even for us? I'm not worried about complicating installation, as I'd rather take my time on this and do it right for once, rather than the usual kludge that happens with school set ups

[sparkeh]

but with SCCM needing to run on the physical host anyway

It does? I have it running on a VM with no problems.

 

Personally I would keep it all together on one server and throw as much RAM at it as you can. Keeping it in one place is as much for convenience as anything, getting it all setup and running smoothly on one box is enough of a challenge let alone trying to split it over several machines and getting everything to talk to each other.

[sonofsanta]

It does? I have it running on a VM with no problems.

 

Personally I would keep it all together on one server and throw as much RAM at it as you can. Keeping it in one place is as much for convenience as anything, getting it all setup and running smoothly on one box is enough of a challenge let alone trying to split it over several machines and getting everything to talk to each other.

 

I'm sure it would run fine on a VM, but it needs to be on the physical for the SCVMM side of things to manage the VMs. Doesn't it? Otherwise how do I set up the Hyper-V shenanigans in the first place without SCVMM to configure the failover cluster initially? (EDIT: none of this is sarcasm, it is genuine enquiry. Just to be clear)

 

I think bandwidth limitations are what concern me most. But then, we've been fine with separate physical servers running on 1Gb connections all this time, so it wouldn't be disastrous.

[sparkeh]

Whoops sorry, reading fail, was concentrating on the SCCM bit. :S

 

Yes its probably I good idea to run SCVMM on hardware rather than VM.

 

If you are concerned about bandwidth then SCCM might actually help as transfers for things like software distribution and OS deployment use BITS, also you can schedule these kind of activities to avoid impacting busy periods.

[sonofsanta]

Whoops sorry, reading fail, was concentrating on the SCCM bit. :S

 

Yes its probably I good idea to run SCVMM on hardware rather than VM.

 

If you are concerned about bandwidth then SCCM might actually help as transfers for things like software distribution and OS deployment use BITS, also you can schedule these kind of activities to avoid impacting busy periods.

 

S'alrright, end of term, know how you feel right now

 

Busy periods are at least easy to avoid in a school, and we've managed alright with WSUS and AppDeploy GPO's so far so I imagine it'd be alright, it's just the way that TechNet constantly goes on about a Site Server plus one or more Site Systems - makes it sound like it wants to be split over two servers as a minimum.

 

16Gb RAM enough or should I go for the 24Gb mark, d'you reckon? I know it's easy to tell if it's struggling later, but it's easy to plug the RAM in now while the server's not really doing anything!

[sonofsanta]

Another consideration - the physical host has about 300Gb of space on the data drive; is that likely to be enough for all the updates, software and possibly OS deployment, or can SCCM target UNC paths on DFS for that stuff? (as the physical host will have no direct connection to the SAN)

[gshaw]

Depends if you use the physical box as a distribution point and package source. SCCM ends up duplicating images and files to deploy as it needs a set of source data and then a distribution point to send it out from...

[sonofsanta]

Depends if you use the physical box as a distribution point and package source. SCCM ends up duplicating images and files to deploy as it needs a set of source data and then a distribution point to send it out from...

 

I'm being a bit slow here. So if I run it all on the physical box, it either needs all the stuff stored locally, or if it references it remotely, it caches it locally anyway and still uses the same amount of space?

 

Whereas splitting the distribution etc. off onto a VM would allow it to just deploy from the SAN?

[sparkeh]

The way SCCM works is that when you create a software package you point it to the source files, it then copies this to a distribution point which the clients can access, therefore you really end up with two copies, if you have more that one distribution point you end up with mulitple copies. I guess if your distribution points are all VMs using the same SAN you could end up with multiple copies of the same package on the SAN.

[gshaw]

Yup that's the one!

 

Best bet might be to either use an old server (or cheapy NAS box) for the source files then use your VM infrastructure for the distribution point (or again if there's a spare server with disk capacity this could be a good use for it)

 

Either way split your disto point away from the main SCCM server and you get the flexibility to choose how to do it (and in the case of virtualised server mobility of where to put the datastore away from the more CPU-intensive site server database role)

 

In this scenario Server 8's file dedupe role would be a killer feature, can't we just have it now please Microsoft

[sonofsanta]

Tah muchly chaps. So sounds like I'm best served splitting the roles then - my scribbled notes so far have me pondering the following split:

- Physical: Site server, DB server, reporting server, SMS provider, management point, health validator, asset intelligence

- Virtual: Dist point, Software update, PXE, Server locator, fallback point, (state migration, OS deployment gubbins)

 

Does that seem reasonable? As that is based purely on a first-pass reading of the TechNet introduction...

 

 

(also, how I hate the Reply to Thread button clearing out this text box when I click it accidentally. I know it's stupid of me, but that button stands out so much more than Post Quick Reply, and I'm not always scrolled down far enough for that to be on my screen)

[gshaw]

Haha I've done exactly the same before and took a few seconds to figure out why my post disappeared!

 

Plan looks OK at the moment, I've had everything on one server and it runs fine although YMMV depending on number of clients and spec of the physical machine \ VM you run it on.

 

If anything I'd be tempted to swap it the other way around so the distribution point doesn't hammer your SAN if there's a lot of OS and software deployment going on (again depends on resources you have available virtually for SQL \ SCCM)

[sonofsanta]

Haha I've done exactly the same before and took a few seconds to figure out why my post disappeared!

 

Plan looks OK at the moment, I've had everything on one server and it runs fine although YMMV depending on number of clients and spec of the physical machine \ VM you run it on.

 

If anything I'd be tempted to swap it the other way around so the distribution point doesn't hammer your SAN if there's a lot of OS and software deployment going on (again depends on resources you have available virtually for SQL \ SCCM)

 

Don't think I can swap it round given that SCVMM is the main reason for this SCCM instance's existence. TBH from everything I've seen and read a single box seems a much easier way to go, so if someone can let me know how much storage their system uses (and I know that's only a ballpark figure) I have a couple of spare HDD bays in the physical server and can always stick a couple of cheap 7.2k SATA drives in there in RAID 1 - they shouldn't be a bottleneck compared to the 2Gb NIC, particularly if it's just larger files for software packages on them so seek times aren't so important.

[gshaw]

Are you doing imaging from the SCCM server as well? That's where your disk space will go (but even then, our 20GB XP image compressed down to around 6-7GB)

[sonofsanta]

Are you doing imaging from the SCCM server as well? That's where your disk space will go (but even then, our 20GB XP image compressed down to around 6-7GB)

 

Not initially, as we have FOG running here with XP already, but if that struggles with Win7 (not that it should) I want the option to.

 

Looking at our existing app folders, we have about 75Gb total of data for deployment and shared (run from server) applications. So I might even just be able to throw it on the 300Gb data partition I already have without too much inconvenience. If it ever gets that bad I can stick the extra HDDs in and move files over then anyway.

 

Reckon I might just go ahead with the single server installation and if there's problems, I can always just split off the second server onto a VM then. Should be doable shouldn't it?

[gshaw]

I think if the physical server has plenty of grunt the single install should be OK, if you run out of disk space the distribution point is easy to move onto another box.