After setting up an online test lab its time to install the production servers.

Currently we have five 2007 site servers with about 95 DP shares and branch DPs.

I plan to replace the five with one stand alone VMware virtual Windows 2012 R2
standard site server plus a second box hosting MBAM 2.5.

(The MBAM is integrated with configmgr and its data base is on the site server.)

My lab used Windows Server 2012 R2, SQL 2012 SP2 standard, MBAM 2.5, MDT 2013, on
SCCM 2012 R2. I set up OSD for w7 and 8.1 64 with MDT 2013 and MBAM so the
finished laptop or workstation has ip subnet determined settings and is fully
encrypted with the key saved to the MBAM data base.

(I also upgraded Configmgr to R2 SP1 and made sure everything still worked.)

I've got three questions:

1. SQL 2014 is now available and I'm wondering if I should stick with the SQL 2012 which I
know works with MDT 2013 and MBAM 2.5 or go with the new stuff and hope for the
best?

2. I've read that disk I/O performance is the first key factor that limits performance.

Here is my proposed partitioning: (Please modify or give advice. What about the size of
the SQL logs?)

Main Server: (Is VMware Disk I/O increased by creating separate virtual drives? Or
partitioning a single allocated space?

Partitioning: 550 gig

C:  100 GIG Windows 2012 R2 (operating system only)

E:   75 gig   All program files (SCCM/SQL/MBAM/MDT/WADK

F:   125 gig   Data Base files

G:  25 gig  Data Base Logs

H:   225 gig Distribution Point (source files and distributed content)

3. In the interest of improved performance, would it be better to include the
first distribution point on the site server, or put it on a separate virtual box?

Thanks for reading through this any advise would be great.

• Edited by David Best 17 hours 40 minutes ago

Well for number 1 if all the software you mention are supported by SQL 2014 and you want to change go for it. But unless you need the feature i see no reason to change.

Number 2 is confusing you want performance and you install everything on the same box. You should move the SQL to it`s own server. After moving it i would keep c for windows, d: for the program files and E: for the sources.

Number 3 Well having a separate DP will not hurt but it all depend on the number of client you plan to serve.

But reading your post all i can think of is you keep talking about performance and you go and install everything on the same machine. Witch to me sound like you are planing to serve a small amount of clients. 

If you plan to serve few 1000+ and i would strongly suggest having the DB off the primary site.

1. There are a couple of things that don't officially support SQL 2104 like WSUS. There are many advanced in SQL 2014 but until everything supports it, I would tend to stay with SQL 2012 SP2.

2. Partitions are meaningless when it comes to perf. The only thing that affects perf (on the storage side) is the number of spindles involved. If all of those volumes are on the exact same set of disks, you gain nothing (except wasted space) by separating them into separate volumes. Separating the volumes onto separate spindles has a perf impact also as this isolates IO and thus dedicates those spindles for use by a specific function. Using separate spindles also has a potential cost benefit also because you can use slower/cheaper storage for things that don't require faster perf like the contentlib or your source files.

How many managed systems will the new site be handling?

225GB is most likely way low for content. First, the site server stores a copy of all content in its own sccmcontentlib whether or not it also hosts the DP role.

3. Makes no difference really. In all by the smallest of sites, I always place all of client facing roles (MP, DP, SUP) on a separate site system. This prevents having to install IIS on the site server, prevents any clients from ever having to communicate with the site server, and enables easy scale-out and scale-up by simply duplicating this client facing system (in configuration).

Thanks for the quick replies.

How many managed systems will the new site be handling?

We have  less than 14000.

So if I'm hearing you both right:

I should stick with the SQL 2012 which should be hosted on a separate box along with

All of client facing roles (MP, DP, SUP) which will keep IIS off the site server.

And for disk I/O performance I'll research the number of spindle involved and save a bit of space by reducing the separate volumes.

If you plan to serve few 1000+ and i would strongly suggest having the DB off the primary site.

Disagree. See the table in https://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigClientNumbers

I concur with Torsten, moving the DB off box may allow you to add more spindles because of the physical chassis and drive capacity, but this will be offset by the need for network communication and increases complexity and thus points of failure.

Also, I didn't finish my thought for #2: Second, once you start dealing with OS images and updates, space goes quick. Allocate all that you can up front. Add spindles if you can -- as mentioned, these can be lower performing spindles also with higher capacity as the perf of contentlib on the site server isn't really critical.

Also note that saving space shouldn't necessarily be a factor in your design, but if you are just creating multiple partitions on the same spindles, you aren't gaining anything.

For 14,000 clients, you won't need anything extra special here, but it is worth adding as many spindles as you can and throwing as much memory to the mix as is possible.