I'm trying to find a consistent recommendation on disk assignments for data folders when installing SQL Server 2012 for use with SCCM 2012 R2. The search hits I'm getting seem to vary a lot. Here's what I've compiled so far, but please let me know if I'm missing something or need to correct it somewhere?  (note: This is for a relatively small standalone primary site, but with option to accommodate future growth)

• Windows Server (OS) on C:
• D: is assigned to DVD/CD
• E: for SCCM 2012 R2 install root, and SQL Server install target
• F: for SQL database files
• G: for SQL LOGs and TempDB logs
• H: for SQL TempDB
• I: for SCCM content (apps, packages, etc.)

Is this overkill?  Where should the default backup directory be pointed?  TIA!

(EDIT)  I also wanted to ask about using AD (domain) user accounts for mapping to the SQL services.  Article https://technet.microsoft.com/en-us/library/hh427336.aspx#BKMK_ManageSPNforDBSrv says an SPN has to be assigned manually for this.  If there's only one standalone primary site, I assume I can use local (server) accounts, but if later I need to add this to a CAS to build out a hierarchy, it will likely need domain accounts to allow for replication traffic.  Is this correct?

• Edited by David M. Stein 12 hours 34 minutes ago Added to question

What is the underlying disk structure? If those are all just partitions on the same spindles, then breaking it into logical drives like that is kind of useless.  It also depends on the size of your site.  How many clients are you going to support?

Jeff

This is generally similar to what I do and recommend; however not that unless each f those volumes listed above is backed by separate sets of physical spindles, they provide no value and just waste space. I'm certainly not saying to use one big volume as some logical separation is good no matter what, but for example, if the F and G drives listed above use the same physical drives, you've gained nothing. And remember, a LUN is in no way indicative of different spindle use, LUNs are also logical divisions. Thus, if you are going to a SAN with sufficient IOPS for these volumes, using separate LUNs is useless.

Incorrect on the replication and use of accounts. If you use local System, then it has the ability to register its own SPN. So it's not that using the local System account, which in turn uses the computer's AD account doesn't use an SPN, it's that it auto-registers it for you. Note that the generally recognized best practice of not using local System for SQL Server in my opinion is not applicable to ConfigMgr. This so called best practice is based off of the ability for malicious code, usually via SQL injection, to be run by the database engine. With a well-defined application like ConfigMgr where there is no direct user input anywhere, the chance of any type of code being injected is slim to none. Depending upon exactly what you do though, I would recommend using the network service account. This account is similar to local System in that it uses the computer's AD account for network communication however it has no elevated local permissions whatsoever.

These are separate virtual disks. Right now I expect around 6,000 clients.  However, it is possible that an M&A could lead to a much larger environment.

• Edited by David M. Stein 12 hours 9 minutes ago

How many clients will you be managing in total?

Jason - Thank you!  I fully understand the logical to physical ramifications, so no argument from me.  I was just curious if the purpose assigned for each disk is generally accepted as a rough "best practice" for when the demand is sufficient.

Torsten - Thank you (also)!  Right now 6000 clients (approx.) but it might grow exponentially in the near future (depending upon business events)