rheuermann
Posts: 253
Score: 4
Joined: 7/11/2002
Status: offline
|
To recap and help out with some answers (impressions from the Microsoft document library)
Generally, the 500 client load should be easily handled by a single server with SQL and ConfigMgr installed on the same box.
One Microsoft Presentation did suggest installing the bare minimum on a box, such as status fallback point, managment point and put roles initially on a seperate box such as a distribution point - just to see what the load was like before combining into a single box. However, with a decent server - 500 clients is probably not a big deal.
In one call with Microsoft, support described ConfigMgr very similar in load (minus the new roles introduced) to SMS 2003 except with some increased disk I/0, slightly more database activity and significant increase in transaction log.
There are no good sizing guidelines for ConfigMgr yet, except for some upper limits for roles found at:
http://technet.microsoft.com/en-us/library/bb680869.aspx
As you can see, nothing here unless you grow beyond 4000 clients for a single distribution point.
Microsoft intends to use System Center Capacity Planner for ConfigMgr sizing but has not yet released the models necessary to support it. (When I tried to use the beta version it was wildly off base). In another call Microsoft suggested that I deploy Operations Manager to monitor ConfigMgr to get a handle on loading.
In your case, you can move SQL off the box to another server or even better, sql cluster with san backend. In this case, if you already such a SQL install ready to support your databases, then there's no extra cost. I see recommendations from Microsoft that your SQL backend would best run under 64 bit and could be used to support your operations manager databases as well (if you deploy opsmgr). However, your SQL servers should do nothing but SQL, be on a well connected local LAN (1Gig) with little or no traffic on it from other apps. In short, you may want a fast, 1G lan and isolated from other traffic.
If you don't already have another SQL server 2005 built then your licensing costs are much lower when SQL is on the same box and is only used to support ConfigMgr and no other databases. You can use licesnsing "Configuration Manager with SQL technology" rather than pay the per processor charge for SQL. AND you don't have to worry about lan latency.
Perhaps with a max of 5000 clients, I would consider maintaining current SMS services but also add status fallback point to a central site server.
I'd start with a single server that will host ConfigMgr and SQL on the same box as a central site server. It would be the management point for your initial 500 clients as well as a distribution point. Though you have a SAN backend, I would consider the server or SAN equivlent of 4 mirrors, mirror one is used for OS, SQL and ConfigMgr programs, Mirror 2 is used for databases as well as tempdb, Mirror 3 used for transaction log as well as transaction log for tempdb - perhaps also for the OS page file, Mirror 4 for the inboxes.
ConfigMgr server would be a 32 bit OS because if you attempt to install ConfigMgr (primarily a 32 bit app) on a 64 bit OS, Operations Manager will not be able to monitor it since it cannot monitor anything in the 32 bit subsystem of a 64 bit OS. You might consider using Windows Server 2003 Standard x86 to save further licensing costs. You will effectively max out at 3.5 or 3.75 GB with 4GB installed because of the hard limit 32 bit has on the addressing scheme (it cannot access beyond 4GB and the BOIS needs to reserve some of it for PCI and other bus devices). But using enterprise 32 bit, may not offer much more because there would be a minor performance hit with the methods needed by the OS to work around the 32 bit 4GB OS limit... primarily I get the feeling that the Disk i/o and network adapter will become bottlenecks before the RAM does - but others on the forum may have seen different. Go ahead an get two quad processors as well.
Next, WSUS wants to run on 64 bit OS and so this becomes your second server and is configured by ConfigMgr as a Software Update Point. The only role you cannot add here is the reporting point. It wants a 32 bit OS and IIS application to run on and is incompatible.
As your client growth begins, you can create an additional distribution point on another virtual server, a new management point and assign new clients there could be an option as well. Personally, I plan to create a new child site for two major groups of clients and place management points and distribution points on those servers - keeping reporting and status fallback point on the central site.
Other roles that have a heavy impact and may be best suited on a different server include User Status Migration Point and Operating System Deployment.
Hopefully this helps, the planning docs on the technet library are very good if you need more. In short, I think you can easily get away with a two servers, one for configmgr and one for wsus, as client count grows, you have lots of options to deploy additional managment points, distribution points or child sites if necessary to assign those clients to...
Ray
|
Printable Version
Intial setup - database placement - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread