To prove that your design is
conceptually sound, you will need to implement the essential features of
your solution in a test environment. The primary goals of the POC
include the following:
Providing evidence that the proposed
technical solution is feasible and addresses the business requirements.
It is important to validate your processes and documentation as well as
the technical design.
Furnishing an opportunity for the support team to gain knowledge of the product.
Identifying and addressing any gaps or weaknesses in the original design.
Here are the key requirements for an effective proof of concept:
A POC environment that adequately reflects your production environment.
A test plan that validates each element of your functional requirements.
A
communications plan that allows you to effectively share lessons
learned and applies the results to improving your design, documentation,
and processes.
Microsoft’s frameworks identify four stages of the IT project life cycle:
If you have followed MSF guidance during the planning
phase, you will have several key deliverables that will help with the
POC. As you enter the build stage for your Configuration Manager
deployment project, you should have the functional specification, risk
management plan, master project plan, and master project schedule in
place. These planning documents will help you define clear goals as well
as set entry and exit criteria for the POC. These documents will also
define the requirements for the POC environment and your test plan. The
documents essential to the POC include the following:
The functional specification—
This provides a detailed description of the feature set, and explains
how each feature should look and behave. It also describes the overall
architecture and design of each feature. This document will identify
what ConfigMgr features you need to configure as well as the
infrastructure requirements each feature depends on.
The master project plan (MPP)—
The MPP generally includes a deployment plan, capacity plan, security
plan, and test plan, among other elements. One goal of the POC will be
to validate each element of the MPP. The test plan in the MPP will be
largely carried out during the POC phase.
1. Building the Proof of Concept Environment
Ideally, your POC environment would be an exact
replica of your production environment; however, in practice this is not
feasible. Therefore, it becomes necessary to identify the critical
systems, infrastructure, and activities that adequately represent the
production environment. Organizations using MOF or other Information
Technology Infrastructure Library (ITIL) practices can leverage
information from the enterprise Configuration Management Database (CMDB)
to help identify the relevant configuration items (CIs) that need to be
replicated in the test environment. The CMDB includes details about
both the individual CIs and the relationships between them. You should
review your functional specification and master project plan and use the
CMDB to map the dependencies relevant to the CIs in your Configuration
Manager deployment. Here are a few examples of how you might use the
CMDB to plan your test environment:
The CMDB is the starting point for
enumerating the client configurations you need to test. Although it may
not be possible to test every configuration, your test environment
should include as complete a sample of platforms as possible. At a
minimum, you should include all operating system versions found in your
production environment and the major hardware platforms you will be
supporting. If you plan to use Configuration Manager to manage mobile
devices such as smartphones running Windows Mobile, you should include
devices on each carrier network as well.
Your
MPP calls for ConfigMgr sites in various locations such as Brussels and
Beijing. The CMDB contains information about these sites including
local area network (LAN) and wide area network (WAN) characteristics,
Windows language and locale settings, the number and type of clients
systems, information about the local IT and vendor support
organizations, and possibly legal and regulatory requirements affecting
the sites.
One way to replicate the network
environment of these sites accurately in your POC would be with a
distributed test environment, which would include systems physically
located at these sites. An alternative method is to configure the
physical or virtual network infrastructure to introduce bandwidth
throttling, latency, and transient communications anomalies between
sites to simulate your actual network characteristics and conditions.
Your
functional specification calls for delivering OOB Management to laptop
and desktop computers supporting Intel Advanced Management Technology
(AMT). The CMDB will help you identify all AMT-capable models in your
environment so that you can include them in testing.
Your
functional specification includes a requirement to provide reports on
software license compliance for all your standard desktop applications.
You can use the CMDB to identify those applications you will need to report on and the available license data to incorporate in the reports.
Note: Terms: CMDB and CI
A CMDB is a
repository of information related to all the components of an
information system. In the ITIL context, a CMDB represents the
authorized configuration of the significant components of the IT
environment. A key goal of a CMDB is to help an organization understand
the relationships between these components and track their
configuration. The CMDB is a fundamental component of the ITIL
framework’s Configuration Management process.
CIs form the basis of configuration management solutions. A CI
is a collection or object related to the specific functionality of a
larger system. Examples include requirements, code, documentation,
models, and other files. The term configuration item
and the CI acronym are used with a different meaning in Configuration
Manager Desired Configuration Management (DCM). In DCM, a CI is an
element of the configuration used to assess compliance.
You can carry out a proof of concept in a
physically isolated lab or in a controlled environment with connectivity
to your production network. There are advantages and disadvantages to
each:
Using an isolated lab provides the
greatest safety, and frees you from the need to consider possible impact
on the live environment. However, this can take longer to set up
because you have to duplicate infrastructure services.
Implementing
a POC in a test environment connected to your production network can
save time and money because you can leverage existing infrastructure
services rather than having to duplicate them in the test environment.
The downside is that caution needs to be exercised at all times to avoid
making changes that will affect your live environment.
The following sections discuss each of these environments.
Proving the Concepts in a Pure Lab Environment
Generally,
you will deploy the POC in a lab environment isolated from your
production network. Testing in an isolated lab gives you the freedom to
try things out without having to worry about risks to your production
environment. If your organization does not already have a suitable lab
in place, you should consider building one. The test environment should
mirror your live environment as closely as possible. Here are some
points to keep in mind:
Ideally, you should deploy
Configuration Manager server roles on hardware identical to what you
will use in production. You could accomplish this by “borrowing” the
actual hardware you will use for your production site systems to use as
part of the POC. This approach allows the most realistic testing, but
requires you to tear down at least part of the POC environment when you
move the production hardware to the live environment.
In
general, it is a good idea to keep the POC environment available if
possible. This gives you an environment for future testing of hotfixes,
service packs, upgrades, new packages and operating system (OS) images,
and any additional functionality you may decide to deploy. The POC
environment is also a great place for training and experimentation. If
you decide to use production hardware during the POC, you may be able to
preserve the environment for future use by performing a P2V
(physical-to-virtual) conversion of the site systems before removing
them from the POC environment.
In
addition to the site systems, you should have a mix of clients in the
POC environment representing a cross-section of the hardware, operating
systems, and applications you will encounter in your live environment.
The network infrastructure and core services should also replicate the
essential features of your production environment. Although this may be
expensive, it can save you from greater costs later if you encounter
unexpected problems in the production environment.
A properly designed lab environment allows
development and testing of your solution without affecting production
systems. Everyone working in the lab should understand that test systems
can become unstable and require reinstallation. It is not uncommon for
an unstable lab environment to be a source of frustration, but you
should keep in mind that many of the problems that arise in the lab
would otherwise have occurred in your production environment!
Encountering problems in the lab is actually a good thing, because you
have the opportunity to address them before they affect the live
environment. Because it is often necessary to roll back a test server to
a previous state, you should maintain frequent backups or snapshots of
all servers. Here are a few approaches:
For virtual machines, reverting to a
snapshot of the original build or a more recent baseline snapshot is
generally the most efficient way to roll back to a previous
configuration.
For physical machines, you
may be able to leverage Configuration Manager OSD to capture
configuration baselines and redeploy them as necessary.
To
restore your ConfigMgr site server or other site systems required for
OS deployment, you will need to use other recovery methods. In this
case, you may need to do a bare metal restore or apply a standard server
image and reinstall SQL Server and Configuration Manager. It may be
helpful to maintain images of standard server configurations on
removable media because machines are often “wiped” or reformatted.
Developing scripted installations will help with this process, and you
can use them in your production environment as well.
You can use the test environment to finalize
infrastructure components, including server build specifications,
service configurations, and deployment packages and scripts. You will
want to develop test specifications and test cases around each of the
feature sets you plan to deploy.
|
When designing a test environment, you should
consider the respective advantages of physical or virtual hardware.
Virtualization can dramatically lower the costs of building a test
environment. By running multiple virtual machines on a single physical
host, you can save on hardware, power, and cooling and in some cases on
software licenses as well. Virtualization technology allows you to take
snapshots of a virtual machine and later roll the machine back to the
exact state it was in at the time of the snapshot. Reverting a test
system to a snapshot requires much less time and effort than restoring a
physical machine from a backup. Virtualization enables quick and
efficient provisioning of large numbers of client systems for test
purposes.
If you will be using a clustered configuration
for the SQL Server database server in production, you will want to test
the effects of a cluster failover. For this type of testing, virtual
machines may not accurately represent the functioning of physical
hardware you will have in production.
Similarly, if you are using Network Load
Balancing (NLB) clustering for any of your servers roles, virtual
machines (VMs) sharing the same network interface card (NIC) or sharing a
NIC with other VMs might not adequately reflect the behavior you will
see in the live environment. OS Deployment and OOB Management are
examples of functionality you will need to test on physical hardware. To
test OS Deployment adequately, you should deploy images and task
sequences to hardware that realistically reflect the target hardware in
your production environment.
The standard methods for provisioning virtual
machines and deploying base images to them differ significantly from the
methods used with physical hardware. Adequate testing of driver
installation requires a representative population of physical hardware
devices in the test environment. OOB Management using Intel AMT requires
special hardware support.
Backup and recovery processes are also different for virtual machines
and physical machines. You should make sure the backup and recovery
processes you test are valid for your production environment.
|
An optimum test environment may include both virtual and physical systems:
Use at least one physical server or
server cluster to validate the hardware configuration and site
maintenance procedures for critical site systems, such as the site
server and site database server.
Install client systems on physical hardware to test hardware-dependent functionality such as OS Deployment and OOB Management.
Using
virtual machines allows you to scale your test environment far beyond
the limits your budget would allow if you had to build a separate
physical machine for each test system.
Virtual
machines can allow you to test more scenarios in less time and recover
your test environment to a known-good state more quickly than using a
lab configuration tied to physical hardware.
Configuration Manager 2007 requires certain infrastructure dependencies for installation and for certain features to work.
Active Directory (AD) is a required
dependency for Configuration Manager 2007. The AD environment for your
POC should closely resemble your production AD.
Domain
Naming Service (DNS) is required for AD and for many ConfigMgr
features. Using AD-integrated DNS meets this requirement when you deploy
AD in the POC environment. If you use a non-AD-integrated DNS, you will
need to configure similar DNS servers in the POC environment. If you
want your DNS zones to mirror those in your production environment, you
need to copy and edit the configuration and zone files from your
production DNS. You should refer to the documentation for your DNS
server software for details on completing this task.
Windows
Internet Naming Service (WINS) is required for certain functionality if
you will not be using AD schema extensions or you have clients that
cannot take advantage of AD schema extensions. For information on
feature dependencies and requirements for AD schema extensions, and on
how to use WINS in place of the extended schema.
Public
Key Infrastructure (PKI) is required for Configuration Manager native
mode operation and for certain features such as OOB Management.
You should also deploy any security software
you use in production, such as antimalware and host intrusion detection
software, to the POC environment. Network-based security controls such
as firewalls and intrusion detection systems should also be in place and
configured consistently with those in your production environment.
Active Directory Considerations
Configuration
Manager 2007 is closely integrated with Active Directory, making it
important that your POC AD be as close as possible to your actual AD
environment. You can use several approaches in creating a suitable AD
implementation in a POC environment. The first method is often referred
to as the peel-off method. In this
scenario, you add a domain controller (DC) to each production domain you
wish to replicate in your POC, peel the DC off from production, and
move it to the POC environment.
To essentially clone an AD domain using the peel-off method, perform the following steps:
1. | Add a new domain controller to your production domain. You can add a domain controller using the Dcpromo process, described in http://technet.microsoft.com/en-us/library/cc732887.aspx.
Do not make the new DC a global catalog server. If you are using
AD Integrated DNS, you may or may not want to install DNS, depending on
whether you want a copy of your production DNS in the lab. Your
production DNS may include records such as aliases for Internet-based
systems that you want to preserve. If this is not the case, you may be
better off to start with a clean DNS installation after bringing the DC
online in the lab.
|
2. | Shut down the newly added DC, remove it from the production network, and move it to the lab network.
|
3. | On
one of your production DCs, run the Ntdsutil command-line utility and
use the metadata cleanup option to remove references to the DC you just
removed from the network.
This is necessary to prevent errors that would otherwise occur
when the DC’s replication partners attempt to contact it and when the
Windows components responsible for AD replication attempt to generate a
replication topology. You also need to remove DNS entries for the DC
through the DNS console and use the ADSI Edit Microsoft Management
Console (MMC) snap-in to remove File Replication System (FRS) references
to the DC. This is the same process used after an unsuccessful domain
controller demotion, as described in http://support.microsoft.com/kb/216498.
|
4. | Bring
the DC you moved to the lab environment online, give it a new IP
configuration for the subnet it is on, and perform the same process of
metadata cleanup described in step 3 to remove references to other DCs
in the production environment. Install DNS services on the DC if they
are not already installed, and your lab DCs act as DNS servers.
|
5. | Seize
the domain Flexible Single Master Operations (FSMO) roles on the new
DC. If the domain is the forest root domain, you should also seize the
forest FSMO roles. One way to seize the FSMO roles is to use Ntdsutil,
as described in http://support.microsoft.com/kb/255504.
|
A variation on the peel-off method is to clone
an existing DC instead of actually removing it from the domain and
transferring it to the lab:
Cloning a DC has the advantage of
minimizing the impact on the production environment. In particular, the
metadata cleanup in the production environment described
in step 3 of the preceding procedure is not required, although the
metadata cleanup in the lab environment is still necessary.
To
clone a DC on physical hardware, you may be able to use your backup
software following procedures described in the backup vendor’s
documentation. You may also be able to use imaging software or P2P
(physical-to-physical) migration tools.
If you
have a DC running as a virtual machine, the cloning process may be even
easier. You will probably just need to shut down the DC and use your
virtualization software’s management tools to clone the image. You can
then copy the cloned image to the lab and bring the new virtual machine
online on a host connected to the lab environment.
The major alternative to the peel-off method is
standing up a new AD forest in the POC environment and reproducing the
essential elements of your production AD in the new forest. To
accomplish this you will need to consider the following steps:
1. | Create
a new domain controller in the POC environment as the first domain
controller in a new forest. You can create a domain controller in a new
forest using the Dcpromo process, described in http://technet.microsoft.com/en-us/library/cc732887.aspx, previously referenced in this section.
|
2. | Again using Dcpromo, add any child domains and additional DCs you will need in your environment.
|
3. | Configure
services such as DNS and Global Catalog servers in your new forest, and
assign the FSMO roles to appropriately reflect your production
environment.
|
4. | On a production DC, use the LDIFDE command or other tools to export the objects you need from your production AD.
|
5. | Transfer the output file from step 4 to the DC in the POC environment and use the same tools to import the AD objects.
|
6. | Transfer
any relevant group policy objects (GPOs) from the production
environment to the POC environment. GPOs control many settings that
affect Configuration Manager, such as security and network settings. At a
minimum, you will want to import the default domain policy and default
domain controller policy from your production environment.
You will find the Group Policy Management Console (GPMC)
installed in the Administrative Tools program group on Windows Server
2008 systems when you choose the Group Policy Management role in Server
Manager. You can also download the GPMC from http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en for installation on Windows Server 2003 or Windows XP systems. You can transfer group policy objects using the GPMC as follows:
- a. Expand the Group
Policy Management tree to locate the domain and the GPO you wish to
export. Right-click the GPO and choose Back Up.... Alternatively,
right-click the Group Policy Objects node and choose Back Up All....
Figure 7.1
displays the GPMC with the default domain policy for the sccmunleashed.com domain selected.
- b. Complete the Back Up Group Policy Object dialog box and click Back Up. Figure 2 displays this dialog box.
You can also use scripts to export and import group policy.
Microsoft provides sample scripts for various group policy–related
tasks, including backing up and importing GPOs. You can find these
sample scripts at http://technet.microsoft.com/en-us/library/cc784365.aspx.
If you are planning to use the AD schema extensions for
Configuration Manager, you should include the schema extensions in your
POC environment.
|
Tip: Software Licensing for Your POC
If
you are standing up a separate environment to evaluate Microsoft
software, you may be able to take advantage of free limited-time
evaluation software, or use reduced-cost licensing for full-featured
evaluation software with subscription programs such as TechNet Plus and
MSDN (Microsoft Developer Network). Evaluation software is not licensed
for use in a production environment, and other license restrictions
apply. Carefully review the licensing terms for all evaluation software
before downloading and installing it. Information about evaluation
software and subscription programs is available at http://technet.microsoft.com/en-us/evalcenter/default.aspx.
If your organization provides products,
services, or solutions to customers based on Microsoft technology, you
may also be eligible to receive licensing benefits for internal-use
software by joining the Microsoft partner program. For more information
about the Microsoft partner program and the licensing terms and
conditions under this program, see https://partner.microsoft.com.
Proving the Concepts in an Environment Connected to Your Production Network
Although there are many advantages to having an
isolated lab environment for your proof of concept, you may also
consider doing POC testing on systems connected to your production
network. This approach has the following advantages:
The cost will be lower because you do not need to create a separate network infrastructure.
The
time to deploy the POC environment will be substantially less because
you will typically be able to leverage existing services such as DNS,
WINS, DHCP (Dynamic Host Configuration Protocol), and backup services.
In a lab environment, you would need to install and configure these
services independently of your production deployment.
It
may be difficult or impossible to adequately reproduce certain features
of your environment in a test lab. Enterprise monitoring solutions, PKI
infrastructure, and production security services are examples of
services you may have deployed in production that would be prohibitively
expensive to duplicate in a lab.
If you use a POC
environment connected to production, you will generally need to create a
separate AD environment for the POC. This is particularly true if you
are using the schema extensions to publish site information to AD. You
cannot use the peel-off method in this circumstance, so you will need to
stand up a separate AD forest from scratch. If you have an existing
ConfigMgr 2007 or Systems Management Server (SMS) 2003 deployment in
production, you will also need to make sure that the site boundaries of
your POC ConfigMgr sites do not overlap with the site boundaries of your
production deployment, and that you do not use the same site code for
more than one site!
