We currently have the central site server and DB on the same server and would like to move the DB to a separate server to improve performance and adhere to MS best practice for sites with over 100,000 clients. The current Central server is setup as follows: HP DL585 G2, 4 x AMD Opteron 8220 processors. Has the Site, WSUS, SCUP databases, Using Windows 2003 sp2 x86 OS and MSSQL 2005 x86. Has 5,000 clients directly attached and has 20 secondary sites, and on primary child site. I am going to move all databases to the new HPDL380G6 server and would like to use x64 Windows 2003 sp2 and x64 MSSQL 2005. Would this be feasible and has anyone a step by step of how this was achived (any pitfalls?). I believe that a dedicated high speed network connection should be setup between the site server and remote sql server - if anyone could provide any info on this so that I could request the network team to sort this out then that would also be useful. For the backout plan, I guess I just run the site repair wizard and point the database name back again and start all the DB services on the original server (also add the db name back in the site system tab if I have changed it). Is this correct? Are there pros and cons to moving the DB? I guess for 100,000 clients it is a necessity? I'm also planning to move the packages repository share to another server, but I would think that it just a case of running a script to change the package source path to the new server location. Any help is appreciated, Thanks. Jaz

Here's the official doc for moving the DB: http://technet.microsoft.com/en-us/library/bb680707.aspx. Yes it is this simple. No site repair needed. Although, why would you use three version old products like Server 2003 (almost 10 years old!) and SQL Server 2005? As for moving the package source files, no issues, just plan it out because it will trigger an package update on any package moved.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

Hi, Here is a blog post and script that can assists you in moving the package source - http://myitforum.com/cs2/blogs/cnackers/archive/2010/09/01/system-center-configuration-manager-configmgr-updating-package-source-paths.aspxKent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund

Reading old blogs (about 2 years ago), people were saying to keep the site server and db on the same central site server even for hierarchies supporting over 100,000 clients, but Microsoft's deployment uses a separate db server due to performance problems. Has anyone installed / moved the DB onto a separate server and then had to move it back again due to performance or security problems etc? If anyone has used a separate DB, did you have to use a separate high speed nic for the sql traffic or just plug it into the same switch as the site server and have all traffic go over that ethernet connection? Thanks Jaz

Microsoft recommends a dedicated GB connection between the siteserver and the database server. I would keep the database on the siteserver, especially when talking about 5k clients only.

Torsten, The sccm hierarchy will have over 100,000 clients in total. I'm creating an administrative central site which needs to be able to cope with that amount of clients, since this site server and db will get hammered dealing with data from other sites. Microsoft have separated the site server and db in their organisation http://blogs.msdn.com/b/shitanshu/archive/2010/10/22/configmgr-site-role-hardware-used-in-microsoft-it.aspx and http://technet.microsoft.com/en-us/library/ff684119.aspx I've seen some docs that recommend high speed connections of 1gbps, but most servers come with NICs capable of that anyway. Under the old sms 2003 MS did not recommend this, but they do now. Has anyone done this and had no problems? How did you design the network topology (dedicated nics for sql? 1gbps connection speed). Could you let me know how you did this for the sccm side and the sql side. Thanks Jaz

Just a point here, Wells has on order of 200,000-300,000 managed systems in their ConfigMgr hierarchy and they do not use remote SQL Servers. So, it is by no means a hard and fast requirement.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

We have a little of 100k clients and growing. We currently have the database on the central server. If you use Raid 10 and have a good server you don't need to seperate it. If you are follow MS best practices then place the DB on its own server and make sure you have a GB fiber channel or GB switch between so you don't have any latency. This comes in to play if you can't get a big enough box at the central site that has the power, drives, memory, etc to handle everything. Also if you don't have a dedicated SQL DBA to watch the performance then you truly should move the Database off to a different server since you really should tune the database. Wells has extensive knowledge in this area, hence why they have a big heirarchy and do "magic" with ConfigMgr.http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com

Both servers will be heavy duty with raid 10, running in parallel to spread the load. Most resource hungry apps with databases work this way, look at MOM and ops mgr. Separating the db will also help the db team to diagnose problems easier. gigabit connections are very common these days,but I have seen reports of companies using less and being successful. MS with all their processing powers separated the roles due to inbox backlogs and it has been recommended by techies at MS on the sccm project in numerous posts.Jaz

Thanks, All On the advice of this forum, I have decided to keep sccm and database on the same server since it is a heavy duty server. I'd probably only go for the separated db if I was goint to cluster it. ThanbksJaz