Designing a sample hierarchy

We are going to finish off this chapter by looking at a scenario, which is fairly common. This example will use some of the rules that we have seen throughout this chapter and put them into practice. We will also see how the working of Configuration Manager 2012 helps in addressing some business requirements and look at our design decisions throughout the process and wrap up with how the design brings business benefits.

Our customer is currently running Configuration Manager 2007 to manage around 25,500 clients over three physical locations. The current hierarchy consists of one central site and four child primary sites; the company's headquarters are located in London with offices in New York and Chicago.

After a meeting with a customer, they have provided the following information to us about their current deployment of Configuration Manager 2007:

Location	Site type	Details
London	Central site	19,500 clients, configuration is using the company standard settings
London	Child primary	500 clients used by finance where different agent settings are specified
New York	Child primary	4,000 desktop clients, using the company standard settings
New York	Child primary	500 servers, inventory, and remote control are disabled
Chicago	Child primary	1,000 clients using the company standard settings

Business requirements

With any design, it is vital to capture the key business requirements not just from the technical members of the project team, but also from people like Service Managers and the CIO who may be closer to the business than you are and can provide valuable insight into key decisions that may affect your design.

In our example, a number of requirements have been captured:

• Provide centralized management of the hierarchy from the London office even for regional IT departments
• Regional IT departments outside of London must only be able to see and manage clients in their specific locations
• Unless other requirements dictate, all clients should have a default client settings policy applied
• Any member of the HR team must have remote control disabled on their device at all times
• Servers in New York and London must have inventory collected every four days
• Bandwidth between London and New York must be controlled because the network link is slow
• The amount of infrastructure for managing the hierarchy must be reduced from what is currently used
• It has also been requested that where possible, licensing costs be cut down

Design assumptions and risks

As many of you will no doubt have experienced, it is not uncommon to have an uncompleted set of requirements, which often mean you need to make assumptions in your design. Often these can come back to bite you later down the line. It is always important to make sure that you note down these assumptions and make sure you discuss them with the relevant people.

Make sure they understand the implications of the assumption and what might happen if the assumption is incorrect. Once you know this information, write it into your design and ensure you get the relevant people to sign off the design to make sure they are happy with your decisions and that they accept the assumptions you have made.

The exact same can be said for risks, these are as if not more important than assumptions. It is not uncommon to have risks on your deployment based on another project. For example, a risk might be that you cannot start your deployment until a new virtualized environment is deployed. The risk is that the environment is not ready in time to start your Configuration Manager deployment.

For our design, we have made some assumptions; you can see these listed out:

• Client numbers are constantly changing as projects are started and finished in different continents
• English will be the only language that is deployed to client workstations and servers
• All systems will be virtualized rather than using physical servers
• London, New York, and Chicago all contain local administrators
• Software update integration is not required in this phase of the project

It is important to understand that as the company starts new projects, this can mean new temporary locations of anything up to 10,000 clients, so it is important we provide flexibility.

Planning the new hierarchy

One of the big changes from Configuration Manager 2007 to Configuration Manager 2012 is the ability to deploy settings policies on a per collection basis rather than in Configuration Manager 2007 when they applied on a per site basis. With the information we have collected, this is going to come in very handy when we look at the final design.

The ability to also define security in a more granular way using role-based administration to give people access to perform set actions and then scoping their access down to Security Scopes will help with some of the defined requirements.

Not every design decision is black and white; sometimes we can have multiple options available to us for our design, and we need to make sure we pick the right option and justify that decision in our documentation.

Our design is no different, we have multiple options and considerations we need to look at to make the right decision. The following table lays out some of the options available to us when we look at addressing some of the challenges that we are facing:

Challenges	Design options
Centrally administering the site in London	Deploy one standalone primary site in London to centrally manage all clients Deploy a primary site at each location and then a central administration site in London
Content between London and New York will consume more bandwidth than what is desired and must be controlled	Deploy distribution points with bandwidth control enabled Enable Windows BranchCache
Address the requirement to manage bandwidth for client information sent from New York	Allow clients to transfer their data unmanaged Deploy a secondary site or primary site in New York to manage the bandwidth
The company standard set of client settings must apply to all clients	Deploy a default set of client settings and override where applicable

Directly addressing the stated requirements

Now that we have looked at some of the challenges we are facing, we need to make decisions on each of the requirements. This will start forming the basis of the design that we will prepare.

First of all, we need to decide on the top of the hierarchy. With the information we have been provided, a central administration site will be the best fit. This addresses the requirement that the site should be centrally managed from one location. We could also have provided a standalone primary site, which would have achieved the same result; however, this restricts our hierarchy in terms of what we place at sites lower down the hierarchy. This is because if we place a secondary site in New York, which would be the preferred technical solution, this means we cannot expand late. Remember that we might suddenly have to manage two more offices with 10,000 clients at each location. At this point, we don't need to pay much attention to the ability to segregate management of systems to regional departments, as no matter how we design the site, this functionality will be available.

Next is the ability to control traffic between London and New York. First of all, we need to deploy a single primary site as part of our hierarchy, which is also in London; this will be connected to our central administration site. This primary site will service the 20,000 clients that are located in London and combine down two existing sites, the old central site and child primary site. We cannot assign clients to the central administration site so we need a primary site in the hierarchy.

For New York, we will also place a primary site. This configuration has been chosen for the following reasons:

• Site-to-site configurations can address the bandwidth control requirements to transfer content from London
• Settings are managed centrally so we only need to deploy a single primary site, which is joined to the hierarchy
• As the link is slow, we do not want the 4,500 clients in New York sending their inventory and policy requests over the network to London
• Any future growth can be handled by implementing a primary site today rather than a secondary site or site system roles

Finally, in Chicago we deploy a secondary site that is hanging off the New York primary site. We do this because although the links between Chicago and New York are fast, this site has 1,000 clients. Additionally, from an administrative point of view, it makes logical sense to create the secondary site off the other site in North America, rather than creating it from the primary site in London.

The following diagram shows how the core of our hierarchy will look with this configuration:

Tip

Don't just let technology dictate your decisions we have just made a decision based on both technology and logical thinking. This is as important as making decisions for technical reasons.

High availability of the database or fault tolerance is not stated in the requirements but it is good practice to include a plan on how you would include this functionality, unless it has been explicitly excluded from the scope of the project. For our customer, they have not stated either way if this is or is not a requirement. For this reason, we will make some recommendations on high availability and fault tolerance.

Licensing is also a stated requirement, in that, if required, we should reduce it where possible. While we usually cannot do much in this area, System Center 2012 is one area where this can be addressed by looking at the SQL Server licensing.

You are allowed to deploy the SQL Server Standard edition with any System Center 2012 component provided it is the only SQL instance and no other databases are served out of the same server. For this the SQL Server Standard license cost will be included in the System Center 2012 license.

With this information, we need to now look at our usage of SQL Server and how the edition we select impacts our hierarchy. When we are deploying a hierarchy, the edition of SQL Server we deploy on the central administration site is the one that will determine how many clients our hierarchy can support.

When we deploy SQL Server Enterprise or Datacenter edition, the hierarchy can support a combined total of 400,000 devices. The Standard edition limits us to 50,000 clients; in this scenario, although SQL supports an in-place edition upgrade from standard to enterprise, Configuration Manager does not support this due to the way in which the database is partitioned. A primary site or secondary site in a hierarchy is not affected by the edition of SQL Server that is used for that site. However, a primary site with a SQL Server installed locally is limited to 50,000 clients; the limit with a remote SQL Server instance is 100,000 clients.

Planning for the SQL Server configuration

The information we have on how the SQL Server edition that we select affects the hierarchy and licensing presents us with a few choices for the configuration of SQL Server. We have four configuration options, which are laid out here:

• Deploy all site servers with SQL Server Enterprise edition
• Deploy all site servers with SQL Server Standard edition
• Deploy the central administration site with SQL Server Enterprise edition and all other sites with SQL Server Standard
• Deploy the central administration site with SQL Server Enterprise edition, all primary sites with SQL Server Standard, and use SQL Server Express for the secondary site

Now that we have several options available to us, we need to look at which is the best option. The first option is to deploy all site servers with the Enterprise edition of SQL Server. While this would be the most flexible option, it would also be the most expensive one as we would need four SQL Server enterprise licenses.

The next option is to deploy every site with the standard edition of SQL Server. This would be the most cost-effective option as it provides our whole hierarchy with SQL Server licenses, which are covered under the deployment of System Center 2012. However, it does leave the hierarchy restricted. This means that because we are deploying the standard edition of SQL Server on the central administration site, we can never have more than 50,000 clients in our hierarchy.

As we are already managing half of that limit, it would not be good planning once we add growth figures on for the hierarchy to leave it potentially short for the future.

The third option is much more attractive as this does not place a limitation on the size of our hierarchy, except for the 400,000 limit. What it means is that we only need one Enterprise edition license and the rest is covered under our existing agreement. This may seem perfect but what about the secondary site? A secondary site can run under SQL Server Express edition; better yet, this can be used all the way up to the 5,000 client limit of a secondary site.

Now that we know this, we can see that the most sensible option for scalability and cost is a balance between two of the options that we have. For our customer, we will recommend the fourth option as their SQL Server editions.

Planning for fault tolerance and high availability

One of our requirements is to reduce the server infrastructure used for the deployment of the hierarchy. Given this is a requirement, it would not be advisable to design our high availability around the database service, as this would introduce the need for a cluster, which would require additional servers.

In our customer's environment, as they are using a virtualization environment, it would make much more sense to make use of their existing replication technology or cluster. We will put our intent to use their existing infrastructure for our solution. This is also important as we want to make sure the correct amount of capacity is available.

Defining the business benefits

While infrastructure design documents are technical documents and in many cases very technical, they are often looked over by decision makers in both IT and finance. It is important that the top of your document includes a statement of what problem this design fixes and what business benefits it brings to the table.

Including this information at the top, from experience, gives the nontechnical readers of the document all the information they need to either sign off the design and provide the financial backing for the project or ask you to provide more information.

For our example customer, we have the following great benefits to add into the documentation, including the fact that we are answering all of the stated requirements:

• We have reduced the amount of infrastructure required to manage the same amount of clients
• Administration is much simpler with all administrators pointing to one single secure console where they can only see the objects in their department
• Administrators in London maintain full control over the full hierarchy and all of the clients within it
• We have provided a solution to manage the traffic between sites to address the speed of the link between London and New York
• Custom client settings can be easily deployed and managed from one single site rather than administering many sites
• We have provided an acceptable solution to enable the site to continue working if the virtualization host fails
• Then, finally, by looking at the licensing of SQL Server, we have saved a considerable amount of money required to license the SQL Server

When you write the business benefits in a document, remember who will read it. Try and put the financial benefits before and process or technical benefits as these will satisfy the reader of the document without them having to read much.

Delivering the design documentation

Now that we have decided on our design, we need to make sure our design is documented. Every design document is different based on the requirements but a few headings are listed, which will give some direction on the layout of the document:

• Project overview
• Requirements
• Risks
• Assumptions
• Solution overview
  • Physical network topology
  • Active Directory Domain environment
  • Server environment
  • Configuration Manager Architecture
  • Disaster Recovery
  • Sizing requirements
• Licensing overview
• Appendix: Licensing overview
• Appendix: Security accounts required
• Appendix: Anti-virus exclusions
• Appendix: Firewall port requirements

This will give you a good high-level design document with all the information that people need, including the decisions you have made to reach the design that you are setting out in the document. Consultancy companies as well often deliver detailed design documents, which include much more information and more detailed diagrams.

Design diagrams

Now that we have prepared our design documentation, we need to prepare our diagrams so people can see how our solution is put together at a graphical level. Diagrams can take many forms and be drawn up in many ways. The following diagrams are included with our design:

• General overview showing how the solution looks
• A diagram showing the solution with the components it interfaces with (for example, hypervisor, storage, network, Active Directory, and firewalls)
• A diagram showing policy, content, and database traffic flow between each site server and site system