SQL and SCCM on different servers

[KuifJe]

is sql Server on a different box to sccm ? not recommended.....

 

Quote from another post.

 

Why is this not recomended, in my mind it's best to seperate database and application to ensure optimal performance?

 

K

[wmmayms]

Quote from another post.

 

Why is this not recomended, in my mind it's best to seperate database and application to ensure optimal performance?

 

K

 

If you just make sure that you have good network connection (these should be on the same location) between your SCCM server and SQL server I see no reasons for not using this method.

[anyweb]

checkout this post from Sherry Kissinger regarding SQL on remote servers

 

http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/4b4ae8f1-18ff-484c-bde2-5ed64b14ab79

 

and I quote

 

the Best practice for ConfigMgr is you have SQL locally.

 

http://technet.microsoft.com/en-ca/library/bb735870.aspx

 

 

 

Best Practices for SQL Server

 

· Use a dedicated SQL Server for each site

 

· Do not use the Configuration Manager site database server to run other SQL Server applications

 

· Configure SQL Server to use Windows authentication

 

· Install Configuration Manager and SQL Server on the same computer

 

· Follow security best practices for SQL Server, noting the following issues:

 

o The site server computer account must be a member of the Administrators group on the computer running SQL Server

 

o If you install SQL Server using a domain user account, you must ensure that a Service Principal Name (SPN) is populated to Active Directory Domain Services

 

and that's from Microsoft *in bold*

 

I'm not saying it won't work, i'm just saying I would do SQL on the same box as configmgr, always.

[jamitupya]

though it states they should be installed on the same machine we have experienced SIGNIFICANT performance issues with this configuration in the past when performing large scale rollout.

 

I think this comes down to a "preference" model on how you'd like to proceed, we have built both models and hybrids and they all work well in a stable environment.

 

our current rollout is

 

Central Reporting (GlobalHQ) - 3x3Node SQLClusters

Central (Regional HQ) - 2x3Node SQLClusters

Primary (Country) - 3Node SQLCluster

Primary (Sites 100+) - Onboard SQL

Secondary (Sites >50) - Primary SQL

 

We run large clusters ONLY as a redundancy factor... we backup Sites to the Country SQL DB (daily) then too the Regional SQL DBS (weekly) and up too the Central Site (monthly).

 

Works well for us but had issues with bandwidth initially.

 

 

things to consider:

WSUS/SUP and PXE with remote DB can be very temperamental

even now we need to rebuild secondary sites enough that we have had to create proper doco to support this.

Consider your QoS/CoS on the LAN/WAN if using truly remote DB's

 

 

Before you go down this route give it some serious thought as MS are a bit particular about their supporting these type of instances.

There are NUMEROUS issues and HEADACHE's that come with this....

you really need a "sh!t hot"(GOOD) AD Admin, lots of little changes and designs to be applied.

your SQL Admin needs to be on the ball also.... we are always with the SQL Team fixing little things here and there ...mainly in the reporting side.

if your SQL is not contactable for a couple of minutes you *may* need to reboot servers and do lots of log digging.

 

You should aggregate your windows logs also to make life a little easier when reporting issues.

 

 

 

Anyway....food for thought :-)

[KuifJe]

That's as complicated as it can get I guess.

 

In our case SQL and SCCM would both be plugged into the same 1Gb switch so data throughput (normally) shouldn't be an issue.

 

My main reason to use a seperate (dedicated) SQL server is because we're thinking of virtualizing the SCCM server itself and we want to seperate functionality as much as possible.

 

Thankfully we have a sh!t hot AD admin (me!) ;-)

 

K

 

[edit]

 

This is from the official Infrastructure Planning and Design guide provided by Microsoft:

• Separate the site server and the site server database roles onto different computers.

Also:

• The use of virtual computer site systems for Configuration Manager sites that must process a large amount of data is not recommended.

 

So I guess the virtual path is out of the window.

 

[/edit]

[jamitupya]

[edit]

 

This is from the official Infrastructure Planning and Design guide provided by Microsoft:

 

Also:

 

 

So I guess the virtual path is out of the window.

 

[/edit]

 

We have virtualized our front ends, consoles, the Central Servers and Regional Servers are Virtualized (esx) however all the DP,PXE,SUP etc are all on physical servers. We also use these servers as Storage and Printing services etc.

Works well....