SCCM scalability planning (2012 R2 and above)

Hi Friends

Hope this post finds you in good health and spirit. I was out of this space for a while as was busy with few due obligations but now I am back so here we go.

There are lot of documents online to guide about SCCM scalability numbers however these are long and scattered ( atleast for me,lol) so I thought to compile data. This will work as quick reference guide for SCCM designing and planning. I will try to keep this post short and crisp.

Client support number in sites and hierarchy

Clients supported in hierarchy with SQL Datacenter/enterprise edition

a. Till SCCM 2012 R2  – Windows and Linux/Unix Clients – 400,000, including mobile devices, MAC clients and Intune clients –  725,000.

b. SCCM 2012 R2, CU3+ – Windows and Linux/Unix Clients – 500,000, including mobile devices, MAC clients and Intune clients –  825,000.

c. SCCM 2012, SP2 + – Windows and Linux/Unix Clients – 600,000, including mobile devices, MAC clients and Intune clients –  925,000.

Clients supported in hierarchy with SQL Standard edition

Windows and Linux/Unix Clients – 50000, including mobile devices, MAC clients and Intune clients –  375,000

Stand-alone primary site

a. Till SCCM 2012 SP2 – Windows and Linux/Unix Clients – 100,000, including mobile devices, MAC clients and Intune clients –  175,000

b. SCCM 2012 SP2 and onwards – Windows and Linux/Unix Clients – 150,000, including mobile devices, MAC clients and Intune clients –  225,000

Secondary site

Till SCCM 2012 SP2 – 5000

SCCM 2012 SP2 and onwards – 10000

1 Central administration site – 25 Primary sites

1 Primary site – 250 secondary sites

Management Point

1 Central administration site – 25 MP

1 Primary site – 10 MP

1 Secondary site – 1 MP

1 MP- 25000 clients

Distribution Point

1 Primary site or Secondary site – 250 DPs + 2000 Pull DPs

1 Primary site including its child Secondary sites – 5000 DPs

1 DP – 4000 clients *

1 DP – 10000 packages *

* Actual number depends on size of package and network bandwidth.

Other site system roles

1 Software update point (SUP) installed on site server – 25000 clients

1 SUP on remote server before SP2 – 100,000 clients

1 SUP on remote server on and after SP2 – 150,000 clients

1 Fallback status point – 100,000 clients

1 instance of Application catalog website/web service point – 50000 clients ( You can have multiple instance and install both on same server)

1 System health validator point – 100,000 clients

I will keep on updating this list as new facts will add-on. Before we close let me answer a question which is asked lot of time

Should I use DP or Secondary site ?

Kent Agerlunds has described this beautifully in his Book “SCCM 2012 – Mastering the fundamentals”. He recommend installing a secondary site at remote locations if one of the following statements is true:

– The Remote locations have more than 500 and fewer than 5000 clients
– You need to compress traffic going to the site
– You need to control the upward flowing traffic
– You need a local management point
– You need a local SUP

otherwise settle for DP. 🙂

So, that’s all in this post. Stay tuned for more technical stuff to come.

Troubleshooting “The trust relation between this workstation and primary domain failed” error without domain rejoin

Hi Friends

Hope this post finds you in good health and spirit. Today we will discuss a very common error and its troubleshooting. You must have got the “The trust relation between this workstation and primary domain failed” error multiple times. How do you solve the problem ? Rejoin client computer to domain ? This is not a good idea. For answer keep reading.

Why we get this error ?

Every client in domain has an domain account and  its own password just like user account. This account is created by default in Computer container. Client computer uses his account and password to authenticate himself into domain. Computer accounts also reset their password for security reason. By default they reset their password every 30 days.

Note: Computer account password changes are driven by the client computer account, and not by domain controller.

There can be multiple circumstances when password reset between client computer and domain controller becomes out of sync for example:

  1. When computer is out of network for more than 30 days ( default password age).
  2. You restored your machine from old backup.
  3. You did reset of computer account from domain controller.
  4. You reverted to old checkpoint.

Due to any of the reason you get the above mentioned error.



To solve this problem, many admins rejoin client computer to domain.This works but its not a good idea because its time consuming affair. Single machine can take excess of 10 mins so what if we need to do same on multiple computers ? Whole day activity. Duh ! Here are two solution which can solve the problem without rejoining domain.

Using PowerShell – If you are using PowerShell 2.0 and above then login to your client computer using local admin account and run this command:

Reset-ComputerMachinePassword -Server -Credential  

Credential should be the of user account with permission. Your local admin account should work.

Server will be domain controller account.


It will prompt for password of account so provide the same

You may also use Test-ComputerSecureChannel command. This command checks trust relation between local computer and domain. Ideally its result should be True but unfortunately in event of error you will get False as result. To solve the issue run this command:

Test-ComputerSecureChannel [-Repair]

This command resets the secure channel between the local computer and its domain.

That’s it. It will reset your computer account. There is no need to restart your client machine either.

Using Netdom: This is another method for resetting account for legacy machine. If you don’t have support for PowerShell 2.0 then you can use Netdom. This method is beautifully described here:

Ok, so our job is done. But what to do if in case company have lot of roaming users and they seldom come to office? When they come help desk will be getting call with same error.

They will get this error as discussed earlier in post. Won’t it be better to disable password reset or at least increase the duration? This will be helpful as we won’t get the error at all. If you also think so here is the solution.

You can configure password reset duration or settings by registry or by GPO policy.



DisablePasswordChange (default off) prevents the client computer from changing its computer account password. To disable, give it a value of 1.

MaximumPasswordAge (default 30 days) determines when the computer password needs to be changed. Change it to whatever number of days you think may be enough.


GPO Policy

Computer Configuration\windows Settings\Security settings\Local Policies\Security Options

Domain member: Disable machine account password changes

Domain member: Maximum machine account password age


You should input the value which best suits your environment.

Ok. So we have solved the problem, congratulation 🙂

I will see you soon with some other technical post. Till then take good care of yourself. Bye.