Jump to content


Recommended Posts

Hi Experts,

I am currently designing a Current Branch implementation for a customer who continues to ask for a Microsoft best practice evidence/ documentation. From whatever I have gathered over my past years of experience, i have never really come across a single "best practice rulebook" as one size can never fit all. In any case, could you guys direct me to any such guide which has design decisions/ used cases documented? other than these

https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/supported-configurations 
https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/design-a-hierarchy-of-sites

Meanwhile, just to get an idea i am planning an implementation for ~ 7K clients and below is what I have proposed

- Single Primary at one of the Datacentre ( 8 Core, 48GB RAM)
- Management server holding client facing roles in another Datacentre (4 Core, 32GB RAM)
- Dedicated server for SQL (I was all for co-hosting the SQL on the same server as the primary but due to reasons more political in nature had to go with a dedicated SQL server) (4 Core, 16GB RAM)
- 2x Secondary sites at remote sites (4 Core, 16GB RAM)
- Distribution points (across various sites spread across the globe)
- No CAS ( Future expansion possible)

Let me know what you think, thanks in advance :) 

  • Like 1

Share this post


Link to post
Share on other sites

As you note there is no such thing as Best Practices. There is no where need enough details for anyone to give you a good answer.

Therefore based solely on what is posted, your server set is all messed up.

  • You have not listed off where WSUS/SUPs will exist.
  • You have not listed off where RP/SSRS will exist.
  • 16 GB for SQL is tiny vs 48 GB for only the Primary is Monstrously huge, if there is no SQL on it.
  • 32GB for the MP is Monstrously huge, Why 4 CPU for a MP? 
  • Why have two secondary at all? Why have 4 CPU in them? Why only 16 GB, keep in mind that they must run SQL too.
  • Will you have a dedicated connection between SQL and the Primary server site? if not why bother have SQL remote? You do know that having remote SQL will seriously increase complexity with no benefit.
  • Is everything physical or virtual?

 

Share this post


Link to post
Share on other sites

and i'd add, why keep sql remote, i know you dont want it remote, take that fight again, having it remote only causes problems, keep it on the primary and things will be much better

Share this post


Link to post
Share on other sites

+1 host SQL on the primary, you're in for a load of headaches hosting it remotely, stick to the idea that you need to reduce points of failure.

as if you need a +1 when anyweb comments (you shouldn't!)

  • Like 1

Share this post


Link to post
Share on other sites

On 22/07/2017 at 9:37 PM, GarthMJ said:

As you note there is no such thing as Best Practices. There is no where need enough details for anyone to give you a good answer.

Therefore based solely on what is posted, your server set is all messed up.

  • You have not listed off where WSUS/SUPs will exist.
  • You have not listed off where RP/SSRS will exist.
  • 16 GB for SQL is tiny vs 48 GB for only the Primary is Monstrously huge, if there is no SQL on it.
  • 32GB for the MP is Monstrously huge, Why 4 CPU for a MP? 
  • Why have two secondary at all? Why have 4 CPU in them? Why only 16 GB, keep in mind that they must run SQL too.
  • Will you have a dedicated connection between SQL and the Primary server site? if not why bother have SQL remote? You do know that having remote SQL will seriously increase complexity with no benefit.
  • Is everything physical or virtual?

 

Hi Garth, 

Thanks for your response. 

The SUP and WSUS role will be installed on the Primary MP server. This will become the upstream data source location. The Windows and office Updates will be synced from Primary, Secondary and the DPs.
RP will also reside in the Primary MP server and the reporting database will be installed on the SQL server. 
Yes, there will be a dedicated connection between SQL and the Primary server site (Datacenters). The reason for having a dedicated SQL is mostly IOPS and <billing>
Everything will be virtual. 

Hi anyweb, Yes I'am all for fighting this battle once again especially keeping the future roadmap in mind.

Thanks for your suggestions, much appreciated.

Share this post


Link to post
Share on other sites

So where is the SQL database for WSUS?

Why have SSRS remote for SQL?

Why have a Secondary sites?

Why so little RAM for SQL?

Why 4 VCPU for the MP?

When you say dedicated connection between CM and SQL but you also say everything is VM, how exactly are you planning to do that?

I hate to say it but you are looking for lot of problems with this setup.

 

 

Share this post


Link to post
Share on other sites

HI Garth,

I am not in for a remote SQL and will have it co-hosted with the primary. That would take care of a lot of things.

What in your view would be a realistic setup for an implementation similar to this? Assuming this setup would scale up to a ~ 15K (desktops+servers) in future.  

Share this post


Link to post
Share on other sites

Update - I have finally been able to convince the management to co-host SQL on the Primary server computer. This is how the final compute looks like

PSS co hosting SQL DB - 8 Core, 64GB RAM
Primary MP hosting (MP+DP+App+Reporting+SUP) - 4 Core, 32 GB
IBCM Server  (MP+DP+SUP) - 4 core, 8GB RAM 
16 x DPs - 4 core, 16GB RAM 
 SS in remote regional site with poor connectivity with the DC - (8 Core, 16GB RAM)

I would probably not get a RAID and instead get a VM which would be sitting on a V-SAN pure Stroage. 

Any IOPS recommendations?

Share this post


Link to post
Share on other sites

So why have RP remote from the Primary server? 

Where will SQL be installed for the SUP?

Why have DP with 16GB of Ram?

What have SS at all?

Without your network layout there is no way anyone can tell you that 16 DP and SS is a good idea.

 

Share this post


Link to post
Share on other sites

Update - I have finally been able to convince the management to co-host SQL on the Primary server computer. This is how the final compute looks like

PSS co hosting SQL DB - 8 Core, 64GB RAM
Primary MP hosting (MP+DP+App+Reporting+SUP) - 4 Core, 32 GB
IBCM Server  (MP+DP+SUP) - 4 core, 8GB RAM 
16 x DPs - 4 core, 16GB RAM 
 SS in remote regional site with poor connectivity with the DC - (8 Core, 16GB RAM)

I would probably not get a RAID and instead get a VM which would be sitting on a V-SAN pure Stroage. 

Any IOPS recommendations?

As a general practice they wanted to keep all client facing roles separate from the primary site to reduce any load on the primary site. However I have recommended to keep the RP on the Primary site server. SUP will be using the site database.

For DPs it is a typo, they will run *8GB* RAM.

There are 16 branch offices with ~ 150-200 seats with good connectivity to the DC, and the sites for which the SS has been proposed is connected with a fairly small pipe 20M ( with the DC (sites are in India and US) and has nearly 1000 seats. Thus to prevent excessive WAN  traffic due to content distribution the SS was proposed. There are remote sites with a DMVPN circuit and 5M/10M connectivity however lesser number of seats.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.