SCCM Installation/Deployment -> Easy as A B C D – What! no screen shots?

You have the DVD and a project deadline now where do you start?

The aim of this article is to provide a general process for deploying a new SCCM site. This process can also be applied to an upgrade (I always view upgrades as an opportunity to improve, so much the same as a new site).

This is a supplement to the extensive resources available and as a result, does not aim to repeat the online documentation and training material available. I will place links to other resources I found useful in, planning and successfully deploying SCCM sites.

We will first cover the tasks to consider and perform before you start the installation (do this before clicking setup.exe and Next Next …..)

Active Directory Tasks

Schema Extension and AD publishing security rights for your site:

This process is recommended if you are deploying SCCM to an Active Directory environment. Ensure you engage with the department/team that owns Active directory schema extension as early as possible. Typically schema extensions require careful planning and have wider implications outside SCCM deployments.

The detailed steps are covered in the online documentation (How to Extend the Active Directory Schema Using ExtADSch.exe). A summary of what is required is:

Run the schema extension utility from the installation media – Requires a user with schema admin rights
Use ADSIEDIT.MSC (available from the Operating System support files) to create the System Management container under the target domain partition that the SCCM site would be installed in.
Create a group for the site server computers that would host the provider role (e.g. DomainXSCCM Site provider servers).
Grant the new group rights to the System Management container and all its child objects. A group is recommended for easy of administration and will mean that, new site servers only need to be added to the group to complete future delegation.
Note that if you are using groups as described above a reboot of the site server would be required to complete the group membership process.
I would also recommend creating a separate group for site system servers (e.g. SUP servers, Distribution point servers). This would give you better flexibility in configuring security at the operating system level

The above would prevent one of the more common AD publishing errors seen in SCCM post site install. This would also impact your client deployments as correct registration of SCCM objects in AD aids in the site discovery and assignment process.

Boundary – Site Scope Tasks

One of the critical areas of your SCCM site is the configuration of site boundaries. Site boundaries basically tell your clients whether they belong to your site or not from the network layer. It is critical that you work with your network team to understand how subnets are assigned to your clients.

Failing to plan and configure site boundaries properly would impact your client deployment (discovery and assignment post installation). Though AD sites can be used, I would only recommend its use in the following scenarios:

The AD sites are configured to support SCCM (e.g. remote offices have dedicated AD sites)
The SCCM admin is aware of changes to AD sites or is the same person making the changes (In this case a process can be setup to keep SCCM in sync with any changes)

Our experience shows that using Subnets gives the SCCM admin more control and is a better practice. In some cases your SCCM site may span multiple domains and also include DMZ clients/workgroup clients.

Before installing your sites, get a list of all the subnets in use for all clients within the scope of deployment.

Work with your network admin team – they have better insights into VLAN configurations etc
Check with the DHCP admin – This would give you a logical view of your IP network configuration
Remember that the clients subnet mask plays a critical role in which subnet the client actually belongs to (evaluation is done on the client side not your SCCM site)
Use the description field in SCCM boundaries to document boundary information.

Using subnets takes a bit of time to setup but will save you a lot of pain in the long run.

Create Groups – Security Tasks

I am in favour of careful planning to reduce the amount of times I have to repeat a task. One of the big challenges in SCCM is role based security out of the box. I know this is coming in SCCM Vnext (saw the demo at MMS 2009). In the meantime here is the budget version of how to achieve a form of role based security.

Create AD groups in advance for the roles of the users who would access your SCCM console.

Example Groups	Description
DomainXSCCM Global Admins	Full access to the SCCM site
DomainXSCCM Full Admins	Full admin rights except site settings – Boundaries etc
DomainXSCCM Report Viewers	Permissions to only view reports
DomainXSCCM Report Admins	Permissions to create Reports
DomainXSCCM SUM Admins	Software update permissions only

The first task you should perform after the installation is, copy the rights of the user who installed the site. In my scenario, I use the SCCM Global Admins group.
Take time to configure the permissions for the other groups which you create to reflect the roles of users accessing the console (Takes time, however this should be a one off exercise)
Setup a process to add users to the groups as and when access is required.
Get yourself a coffee/tea or cold drink.

Deployment steps – No screen shots

This section provides high level steps to follow and should act as a to do list in your SCCM deployment.

Central Site – Reporting only

This is deploying a site that would act as a repository/roll up site for your hierarchy (the old Central site concept from SMS 2003)

Install SCCM
Remove the management point role
Enable and configure the reporting point and or SRS reporting point roles
Configure Object security permissions

Primary (Deployment) Site – Clients assigned