The essential component to a well-performing hierarchy is a good design. Without a good design, you can find yourself having issues in your environment, such as under- or over-utilized resources or an environment that does not meet the initial requirements. The design should be a single point where everyone can look and see how the hierarchy should be built, operated, and maintained.
In this chapter, we will explore many components that make up a good design. We will be covering the following topics:
How to make sure you select the appropriate site system server
How to design fault tolerant environments
How to properly back up and restore a Configuration Manager site
How to design for multiple trusted forests
How to design for nontrusted forests
A working design scenario example
As we already know, a Configuration Manager hierarchy starts with either a central administration site and a primary site in a hierarchy or just a single standalone primary site. Unlike in Configuration Manager 2012 RTM, in Configuration Manager 2012 SP1 you cannot add a central administration site later; you can do this in the R2 version. It should be noted though that you cannot remove a central administration site later on with any version of Configuration Manager 2012. This means you no longer have to make any large assumptions about the size of your hierarchy years down the line.
It is important to mention at this point that the central administration site is not a direct replacement for the old central site in the previous versions. The way the hierarchy works is different from the previous versions, so it would be difficult to compare the two. In Configuration Manager 2012, the central administration site is used as a central location for both administration and reporting. While some site system roles can be deployed to the central administration site, you cannot assign clients to the central administration site.
In the previous versions of Configuration Manager, we used a central site to address many issues, such as:
Splitting the management of servers and client machines
Segregating permissions between sites
Applying different client settings to servers and client machines
Internal political reasons
Configuration Manager 2012 has gone a long way in answering many of these points, meaning that we can now deploy a single-flat hierarchy, which is both easy to manage and gives us the flexibility to delegate the management of different environments or devices to our support teams as well as properly define permissions for the whole hierarchy rather than at a single-site level.
Tip
If you are coming away from a Configuration Manager 2007 environment, think about the reasons you may have had to deploy multiple sites in Configuration Manager 2012. Those reasons have probably gone.
Now, the golden rule for a central administration site is that if you are managing more than one primary site, then you require a central administration site to manage them both centrally. For this reason, most of you will not require a central administration site. This is because a standalone primary site can support up to 100,000 clients.
It should also be noted that the design should be as simple as the requirements allow and that a central administration does not provide high availability, which is a common misconception.
To give you an idea in terms of supported numbers of clients, when you are supporting Windows Server, Windows Client, and Windows Embedded operating systems as well as Linux and UNIX clients, then a standalone primary site will support up to 100,000 clients.
Devices that are managed by Windows Intune or the Exchange Server Connector will support up to 50,000 clients and finally, mobile devices enrolled by Configuration Manager, mobile device legacy clients, such as WinCE 5.0, WinCE 6.0, WinCE 7.0, and Windows Mobile 6.0 and Mac OS X clients can support 25,000 clients.
While it is important that you do not over specify the site, it is also important that the site is designed fit for this purpose. Try to move away from the design rules that were used in the previous versions of Configuration Manager; while those designs will still be valid, it may not be the correct way to do it anymore.
In the largest hierarchies, it is not uncommon to see multiple primary sites. We have just seen how, technically, you don't need to deploy multiple primary site servers if you are not managing over 100,000 clients. Designing Configuration Manager in the most technically sound way every time will end up causing you potentially more problems than you would like.
Tip
Always take into account the business requirements of your organization and make sure you understand the strategy your business is taking; this may mean that you have to break the best technical design.
Some common reasons for not deploying a technically sound solution would be as follows:
Legal reasons
Internal political reasons
Regulatory reasons
From experience, it is not uncommon to have to put in multiple primary sites when one would have done the job. While it is always great to design a solution that does the job without spending lots of money, always remember that functionality and flexibility should come first; however, for legal and regulatory reasons, this may not be possible. If this is the case, make sure this is highlighted in the design.
If you know your company is flexible in the way they work, for example, offices that appear and disappear quickly, often with large numbers of employees and equipment that need to be managed, then make sure the hierarchy you design can accommodate this solution and is flexible enough to support those requirements. This example is a fairly common one in the construction industry where project offices pop up and pop down at a moment's notice.
In this scenario, the most technically sound design would mean you having to admit that your hierarchy cannot support these clients properly without some re-design; this is not a situation you want to be in.
For a long time, secondary sites in Configuration Manager have been seen as a bit of a dark art. You shouldn't think of them like that. With the release of Configuration Manager 2012, it is not uncommon that you can just replace your existing secondary sites with distribution points.
The reason for this is that in Configuration Manager 2007, a secondary site would commonly be used because of the sender, which provided throttling, scheduling, and compression of the traffic, if required. However, these capabilities have been added to the distribution point in Configuration Manager 2012.
Secondary sites do still have their place though. In Configuration Manager 2012, secondary sites take part in replication just like the central administration site and the primary site. Portions of the database are not replicated down to the secondary site from the primary site; the replication that is used makes this a highly efficient process. By default, a secondary site installation will automatically deploy SQL Server Express unless you specify an installation of the SQL Server you have already deployed.
The replication that is used in Configuration Manager 2012 is not the native SQL Replication that we are used to. Instead the replication is taking advantage of the SQL Server Broker Service. The broker is a native SQL functionality, which supports messaging and queuing. This is known as the Data Replication Service (DRS).
When you are looking at your network topology and deciding if you should place a secondary site at that location, ask yourself the following questions:
Does this location have more than 500 clients and less than 5,000 clients?
Do I need to compress the traffic going to the site?
Do I need to control the flow of traffic flowing up the hierarchy?
Do I need a local management point?
Do I need a local Software Update Point?
If you can look at a specific location and answer any of those questions as yes, then you will probably need to deploy a secondary site. Let's dig into the preceding questions a little more; this should give us some pointers to help make our decision.
The number of clients you intend to support is a really important factor. The main reason is that the secondary site supports communication from up to 5,000 clients. If you have more than 5,000 clients at one location, then regardless of network connectivity, you will potentially want to look at putting a primary site here anyway rather than using a secondary site.
Another question for client count is to ask yourself if you want 500 clients getting policy over the network to a remote location? The content can be addressed with distribution points; what we are attempting to address in this scenario are too many clients communicating with a management point over the WAN.
Tip
Information on the estimation of client network traffic can be found in a very useful TechNet article at http://bit.ly/1sZTHfY.
Do you have enough physical network bandwidth to support this amount of traffic? This is the question we are asking here. This will determine if we need to compress or control the flow of traffic that is heading up the hierarchy.
Regardless of the number of clients communicating, we do not want to saturate the network with the management traffic.
Unlike the distribution point, we cannot control which management point the clients report to at a primary site, when we have multiple management points. For this reason, the only way we can control this is by using a secondary site. The same would go for the Software Update Point; this is another service of the hierarchy like the management point. We are unable to control which Software Update Point the client will use at any given time.
After applying the rules set out in the preceding section, we might still be unsure about whether or not we will need a secondary site. One of the great things about Configuration Manager is the simplicity and ease with which we can deploy and modify the hierarchy from within the console.
In today's world, the systems we design and deploy are under more pressure than ever. We are expected to design systems with less money to implement, which can lead to design mistakes or errors in judgment. One area that usually suffers from this is the design of fault tolerance or disaster recovery. In a legacy world, Configuration Manager has been seen as a tool only used by IT departments to manage machines and has often given little business benefit. With the new wave of mobile devices, tablet devices, and other scenarios, such as bring your own device, Configuration Manager has suddenly become a critical application that is used to manage all these devices from one single pane of glass.
It is no secret that true fault tolerance in the form of clustering is something missing from Configuration Manager but that does not mean we still cannot produce a design that is able to switch to a disaster recovery scenario or provide a fault-tolerant service.
The central administration site, primary site, and the secondary site are all site systems. These themselves cannot be part of a cluster or any type of load balancing. What we can do though is make the database that stores our entire configuration, inventory, and other information highly available.
This can be done in a number of ways, for example, we can provide high availability using a traditional SQL cluster service. Both of these configurations allow us to make the database highly available.
Back to the site systems, if we are deploying our site system servers as virtual machines, then we can take advantage of replica in Hyper-V or similar technologies in VMware. This will make our site system server switch, should the workload need moving in the event of a failure. In this scenario, if you are deploying the site system server on the same server where SQL Server is deployed, then we might not need to worry about making the database highly available.
Any other service you deploy in Configuration Manager, such as the management point, distribution point, and fallback status point, to name a few, is known as a site system role. In some instances, we can create multiple instances of these roles to create tolerance but not in the sense of a cluster.
Some site system roles you can only deploy as one instance per hierarchy, for example, this is true of the Endpoint Protection Point where you can only deploy one instance of the role per hierarchy.
The management point is a good exception to this. While we cannot pick and choose which management point a client will communicate with in a primary site, we can deploy multiple management point servers to provide options to the client. If our hierarchy is running in an HTTPS configuration, then management points that are HTTPS enabled will be ordered above any HTTP management points by the client while it is selecting a management point to use.
The same can be said for the distribution point: we can deploy multiple instances of the distribution point to give the clients options when deciding which to use for downloading content. Software Update Points can be added to an NLB cluster, for example, which must be configured using PowerShell. However, they can also, with newer versions of Configuration Manager, have multiple instances in the same hierarchy without the need for an NLB cluster.
Depending on the requirements of the design and how important Configuration Manager is in terms of its role in the recovery of a data center is the driving factor for building fault tolerance at the site system role side of the picture.
As with fault tolerance, incorporating information for the backup and recovery of any Configuration Manager site is an important subject. It is vital that this is designed properly; should the worst happen and you need to recover the site at any point, then the planning work you have done at this stage will be invaluable in ensuring the successful recovery of the site in a timely fashion.
Configuration Manager provides two backup options; the first is the easier of the two to implement and makes use of the built-in maintenance task called the Site Backup task, which is responsible for creating a backup of the site. The backup can be run at the central administration site and the primary site but not at the secondary site or any site system roles. A third option is also possible, which is the only backup of SQL.
The backup engine follows the instructions defined in the backup control file (<Install Directory>\Inboxes\Smsbkup.box\Smsbkup.ctl). You can modify this file to control how the backup runs.
In addition to this service, if you run System Center 2012 Data Protection Manager (DPM), you can use it to back up Configuration Manager if you are running at least Service Pack 1. To enable this, create a new protection group in DPM for the site database server. When you are on the Select Group Members page of the wizard, select the SMS Writer service from the data source list and then select the site database as the member.
Note
Configuration Manager does not support backup for a SQL Server cluster using a named instance when using DPM. However, it does support this when using the default instance.
When you recover the site from a DPM backup, in the setup wizard of Configuration Manager, select the Use a site database that has been manually recovered option to use the backup from DPM.
It is best practice for any infrastructure service to keep multiple backups. Various reasons exist for this; however, I will not go into many details here. By using the default backup site server task in Configuration Manager, the first time a maintenance task runs, a snapshot is created. The next time the backup runs, another snapshot is taken and the previous snapshot is overwritten. As a result of how the backup maintenance task works, you only have the most recent backup and have no way of recovering an earlier snapshot.
Thankfully, you can use a batch file, AfterBackup.bat, which is automatically run following the completion of the maintenance task. You must manually create this file if you need it at <Install Directory>\Inboxes\Smsbkup.box. If this file exists, then it will be automatically executed.
The file is a regular batch script so you can perform any actions you wish here. You can verify the completion of the maintenance task, which includes the execution of AfterBackup.bat from the Component Status node in the Monitoring workspace. Look for the SMS_SITE_BACKUP component and you should see a status message with an ID of 5040.
While the backup maintenance task takes care of much of the site information and the database, it does not take care of everything. One example of this is that any custom reports that you create needs to be backed up manually.
The same is true for content files, which are part of applications and packages. The content library needs to be restored before you can redistribute any content to the distribution points. When the distribution manager starts to distribute content, it is copied from the site server to the distribution points. You must ensure that your backup solution includes both the content library and the package and application source locations for the site server.
Custom software updates that may have been published using System Center Update Publisher 2011 (SCUP) must also be backed up. These are also not included as part of the backup maintenance task. SCUP uses a database to store the repository so it is also important to make sure this database is included in your backup plans. It should be noted that the database file for SCUP is located in each user's profile.
Finally, the user state migration data is also not included. This is information that may be used during operating system deployment to back up and restore user state from one machine to another during either a refresh or a replace scenario. You must manually back up the folders that are specified in the Folder details section of the General tab in the State Migration Point properties.
Unlike the previous versions of Configuration Manager, you can no longer use the Recover a site option from the Start menu on the site server. You can only start the recovery wizard from the installation media. The wizard is available in the regular setup.
Note
If your site was using database replicas on management points, before you can use them again, you must configure each replica. This includes both the publications and the subscriptions.
Once the setup has begun, you have the following two options that are available for the recovery of the failed site:
Recover the site server using an existing backup: This option should be used if you have a backup of the Configuration Manager site, which was created as part of the Backup Site Server maintenance task.
Reinstall the site server: This option is used when you have no backup available. Use the same site code and site database name as when the initial setup was performed; you will have to configure your site again like a normal installation.
For the site database, the following options are available as part of the recovery:
Recover the site database using a backup set: This option should be used when you have a valid backup created by the maintenance task.
Create a new database for this site: This option should be used when you do not have a site database backup available.
Use a site database that has been manually recovered: This option should be used when you have already recovered the site but the database has been backed up using another method. For example, you would use this option when restoring from a DPM or SQL backup.
After the site and the database have been recovered, any password for accounts that are set up in Configuration Manager will need their password re-entered. Thankfully, the accounts that require this action to be performed are listed on the Finished page of the setup wizard after the recovery is complete. This information is also saved to C:\ConfigMgrPostRecoveryActions.html on the recovered site server.
Any Windows Server hotfixes that have been applied to the server will also be listed on the Finished page of the setup wizard and also in the preceding referenced file.
Configuration Manager supports the deployment of site servers, such as the primary site and the secondary site across different forests when two-way trust is established between the two forests.
When you want to support multiple forests and a two-way trust exists, Configuration Manager does not require any additional configuration provided any firewalls have the appropriate ports opened and name resolution works between the forests. By default, Configuration Manager, even in this scenario, will configure the database replication between the sites and also the intersite file replication.
If you do not require a site system in the other forest, then Configuration Manager also supports the placement of site system roles in these environments. It may be overkill to provide the services of a primary site in another forest. When this situation arises, use the same rules to determine if you place a distribution point or a secondary site out in that forest; just because it's a different forest, it doesn't change how you treat that environment.
Additionally, with Configuration Manager 2012 R2, you can add multiple network access accounts, which can help with the support of trusted forests.
When clients are not in the same forest as the site server, Configuration Manager supports the following scenarios:
The two-way forest trust exists between the site server and the forest of the client
The site system role is located in the same forest as the client
The client is on a workgroup computer
Clients that are members of an Active Directory domain can use Active Directory for service location when the site is published to their Active Directory forest. You can also publish site information to untrusted forests. Additional forests can be specified in the console other than the forest where the site server is installed. This can be done from within the Active Directory Forests node in the Administration workspace. Any forests that you specify in this node will be picked up by the Active Directory Forest Discovery Agent if it is enabled.
In addition to supporting communication from clients that are in trusted forests, Configuration Manager also supports communication from clients that are in an un-trusted forest from the site server.
Configuration Manager will support the installation of site system roles in another nontrusted forest with two exceptions. The first is the application catalog web service point and the other is the out of band service point. Both of these roles must be installed in the same forest as the site server.
When you are deploying a management point in an un-trusted forest, it is very important that you configure a connection account to enable the management point to obtain information from the database. Make sure the domain account has permission in the database. This is the same for the enrollment point as well. You must also ensure that you use an account that has administrative permissions on the target server in the target domain to complete the installation.
You cannot deploy site systems, such as the central administration site, primary site, and secondary site across un-trusted forest boundaries. Only site system roles can be deployed in un-trusted forest scenarios.
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 |
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
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.
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 |
|
|
Content between London and New York will consume more bandwidth than what is desired and must be controlled |
|
|
Address the requirement to manage bandwidth for client information sent from New York |
|
|
The company standard set of client settings must apply to all clients |
|
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.
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.
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.
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.
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.
In our opening chapter, we have learned how the Configuration Manager sites interact with each other and how implementing sites in different scenarios can have an impact on the hierarchy. We have also seen how you can manage multiple forests, which are both trusted and un-trusted in an effective and secured manner.
To finish off, we also looked at an example design scenario and went through the steps involved in making sure our design is fit for purpose, is scalable, and is also highly available. In the next chapter, we will take our hierarchy one step further and look at securing the environment using certificates.
