Hi, I am looking to deploy SCCM (SQL, Site server & majority of the other site roles) all on one server and was wondering if this is advisable? If so, can somebody please suggest how to configure the server especially in terms of disks e.g how big should 'c' drive be, 'd' etc..and should the OS be installed on 'c', SQL on 'd' drive, Site server app install on 'e', OS images and apps to deploy hosted on 'f' drive etc??? I am looking to setup the SCCM box as a virtual server if that would make any difference. There will roughly be around 200 clients (100 winxp machines + 100 win2k3 general purpose servers) and around 100 apps deployed - not sure if this would impact the sizing by a big deal? Sorry for the open ended question....it's just that the docs ive seen so far, give estimates for 1000s of clients in various sites/offices etc and this environment will be no where near that size. Any feedback/help would be much appreciated.

Hi, For 200 machines, personnaly I will go to System Center Essentials http://www.microsoft.com/systemcenter/en/us/essentials/sce-2010.aspx

Thats a ball park figure...could be more depending on how well it works for us. Any recommendation/suggestions for the enterprise version of sccm? I'd prefer to go with sccm due to the info and knoweldge and experience gained so far...

As a general statement, regardless of the server application whether it is configmgr or not, never install anything on the C: drive. To me, the drive housing %windir% (which is usually c:) should only ever be for the operating system. Not any applications. If you have access to the MMS 2009 DVD, Brian Mason/Steve Thompson did a presentation on how one large company (over 200,000 clients) designed their server for drives and partitioning. For a smaller set as you are proposing, you could probably get away with just 1 partition, a D: (for example), and house both inboxes, the database, and anything else you care about on the large D: drive. If you have unlimited budget or expect to go well over thousands clients, you might want to consider separate controllers and drives, like d: for inboxes, e: for SQL Db, F: for SQL tempdb, G: for package storage, H: for Distrib Point... you could go very nuts if you wanted to. Or even have 2 completely separate servers just hanging out as Distrib Points. About the only thing I would recommend is do NOT put SQL on a different computer. do NOT virtualize unless you know exactly how to design your virtual computers to work the optimum way with ConfigMgr, Sql, Drive partitions, memory, and CPU. ConfigMgr can be virtualized; I know a lot of companies do so. But it's not a next/next/finish kind of configuration.Standardize. Simplify. Automate.

What about HA/redundancy considerations for the SCCM server itself? - from what i understand you can configure the management points using microsoft NLB....what what about the site server and other roles (e.g. PXE), how would you configure these for HA/redundancy

You are talking about 200 clients, right? It's only once you start to hit 25,000 clients per primary site that you would need to start thinking about having multiple management points, and putting them behind a Microsoft NLB. Or any other site roles. You'd have to really, really be insane about client settings, like every 15 minutes or something on settings, to overwhelm a 200-client environment. I suppose someone could, you could set every discovery, every agent setting, every component to be so tight that you'd melt your server, even with less than 1,000 clients. But you'd have to be pretty insane. If you have some serious, the-business-will-die considerations where you absolutely must have 5 9's availability, then you are going to want to pull in a consultant that does specific design plans for ConfigMgr to give you those 5 9's. At your size, 1 server with all roles will be more than adequate. Just use the built-in ConfigMgr Site Backup task (NOT, I repeat NOT the SQL backup. SQL backup is completely pointless for ConfigMgr backup. ConfigMgr Site Backup is what you need to restore)Standardize. Simplify. Automate.

Cool...thank you very much for your response. Possibly...initially the environment will probably cater for around under 1000 clients (mixture of winxp and win2k3), maybe even under 500 clients and about 500 apps or so (maybe less) to be deployed...i would also be looking to use the OSD feautre aswell as stuff licent inventory/asset inteligence. I'd probably stick with default discovery/agent inventory polling settings and see how it goes...definetly wouldnt set it to some crazy like 15mins as you suggest. That's the thing most docs i read, suggest one server would be adequate for up to 25000 but I still wasn't convienced....it just seems dangerous with putting it all on one server (esp sql and the app sccm itself). Btw any idea on database growth for the figures listed above??? im just thinking about how much disk space to allocate to sql db, sql logs, sccm app, osd images, apps for distribution etc. Once again, your advice and suggestions are much appreciated.

http://blogs.technet.com/b/deploymentguys/archive/2008/05/20/sccm-for-deployment-rough-sizing-guidelines.aspx Dangerous? use the ConfigMgr Site Backup task, and ensure the results are in a safe location. That's about it. If you can't get your hands on the backup results in the case of a Disaster scenario, then yes, you are out of luck. With it, it's almost a next/next/finish restore. fyi, it usually has to be a really horrible disaster to need the restore. Or you are replacing hardware (then you'd restore from backup in that case, too). fyi... you have to be a smidge careful how you read the docs. It's not necessary 1 server; but 1 primary site for up to 100,000 clients. That doesn't mean 1 single server. You'd move some of the roles elsewhere, like having 4 MPs behind an NLB (so that you have 25k each per docs), and having multiple Distribution Points, and your SRS role is elsewhere, WSUS Sync point role is elsewhere, etc. etc. So you'd end up with a dozen or so servers; but just 1 site code. Which by the way... is exactly what Brian, JD, John designed here; works beautifully. But for 1k or less... you can have 1 single server, and function just fine. If you have some budget, put the $$ into getting lots of memory, and lots of disk controllers/disk space. That is usually a better investment in optimizing ConfigMgr vs having multiple servers. Sizing: that's a huge variable. According to http://technet.microsoft.com/en-us/library/bb932140.aspx, "Estimated disk space requirement (estimated 3 MB per client)."Standardize. Simplify. Automate.

Hi, Thanks for your feedback! I have spoken to our SQL DBAs and they have said that internal build procedures state that SQL needs to be installed accross a number of different different (e.g. SQL binaries on 'c', logs on 'e' backups on 'f', leaving a seperate drive for sccm install and packages/osd images etc) I know its abit hard to get an extact figure but i was just wondering how much disk space to assign each drive (10 -20GB?)- from peoples experience is anybody able to tell me roughly what the database growth would be like (using default polling/inventory settings etc) and how much disk space will roughly be taken up. I rather assign slightly more disk space to the drives to start off with, instead of going through with the install and then running low on space a month or two into the deployment.