Testing
You
will want to establish a lab environment and implement ConfigMgr in a
completely isolated lab scenario. Labs return large amounts of ROI to
those organizations that use them. Using a lab allows IT administrators
to work with, experiment, and learn new technology, configurations, and
scenarios needed in a production environment, while mitigating the risk
by isolating the lab environment from those systems that could cause a
loss in revenue or service if an outage occurred. In short, labs should
mirror a production environment as closely as possible, have no risk
associated with their use, and be able to be reset to allow for quickly
repeating a process or testing a given scenario.
Using a lab allows
several options that build on each other to guarantee the success of the
ConfigMgr implementation. With a lab, you can implement ConfigMgr
without interference of network devices such as firewalls, routers, IDS,
and IPS. If resources allow, you can scale the solution in the lab to
validate the expected performance and behavior of the design destined
for the production environment.
Your ConfigMgr test
plan should validate the overall solution design from client settings
through site-to-site communications. This does not have to be a complete
test of every ConfigMgr function, although the more thorough the test
is, the more comfortable everyone on the team will be with the solution
and the more prepared the team will be for the deployment. There has to
be a testing balance because the sheer size of the ConfigMgr solution
could take months to test feature by feature. Before piloting the
ConfigMgr solution, administrators should develop a test plan specific
to the features they have chosen to implement and the design components
questioned during the envisioning and designing phases. Table 1 illustrates a sample test plan.
Table 1. ConfigMgr Deployment Test Plan
| Task# | Pilot Testing Tasks | Complete (Yes/No)? | Results/Comments |
|---|
| 1. | Determine test client group and create collection with direct rule name mapping | | Allows ConfigMgr deployment team to positively identify the client involved in the test. |
| 2. | Verify discovery and install ConfigMgr client on test computers with manual push installation | | In
the ConfigMgr console, under Collections, find the target computers,
right-click a computer, choose All Tasks, Install Client. |
| | | | Upon success, enable the client push installation. |
| 3. | Verify automated push installation | | Validate a client system receives the ConfigMgr client. |
| 4. | Verify inventory | | Using the ConfigMgr console, verify that the newly installed client shows hardware inventory information. |
| 5. | Verify client agent settings | | Validate remote control works and prompts the user. |
| 6. | Verify BITS downloaded package | | Create
a small test package. Ensure that all test DPs are used. Advertise it
to the test computer. Ensure that the advertisement is downloaded from
the assigned DP and then installed. Verify that the test computer
receives the package and installs correctly. |
| 7. | Verify reporting | | Connect to http://BLUEBONNET (for the SCCMUnleashed.com environment) and verify that web reporting is operational. |
| | | | Run the All Software Companies report from within the ConfigMgr console Reporting node. |
| 8. | Verify security | | Validate that ConfigMgr administrators with limited rights can only perform the tasks approved. |
Technologies
such as Microsoft Virtual PC, Microsoft Virtual Server, Hyper-V, and
VMware’s ESX, Server, and Workstation allow ConfigMgr administrators to
implement, test, validate, and roll back design features in minutes
using a minimum of hardware. Third-party solutions for these products,
as well as some crafty use of Microsoft Server and Microsoft Routing and
Remote Access Service (RRAS), allow simulating individual network
segments as well.
Once
the ConfigMgr solution design is validated in a lab environment, keep
the lab for long-term use and testing of packages, scripts, service
packs, changes to the site settings, use of new roles, and so on. Using
the lab will lower the overall effort associated with management of the
ConfigMgr solution, provide its administrators with experience and
confidence, increase productivity, and lower the chances of problems in
the production environment.
Stabilizing During the Pilot
Piloting
leverages all the information and lessons learned in the design and
testing phases while incorporating the communication plan and
implementing the solution in the production environment to a limited
number of systems. Piloting the ConfigMgr solution initially lets the
project team validate its design and the network infrastructure, and
measure the load the solution places on the infrastructure.
Tip: Piloting Target
As a rule of thumb, use a
percentage of the environment as your pilot so the project team can
handle any issues that arise and the pilot does not go as expected. 1%
is a good quick pilot where the audience can provide direct feedback to
the project team. Once success is met, then move to a larger 5%–10%
pilot group. It is also a good idea to select users or systems from
dissimilar regions or departments, to ensure the pilot accurately
represents production and keeps the pilot as informative as possible for
the team.
The pilot is the first
actual test of the communication plan, the network infrastructure, and
the user’s response to the deployment. Feedback from pilot users is
valuable for the project team, who should address the items raised so
the production deployment goes smoothly.
The ConfigMgr project
team should focus on items questioned in the design or test phase. Those
site roles you plan to implement should exist in the pilot; it is much
easier to fix or even redesign a system where there are no other systems
dependent on its use! Test each of the functions you expect to use on
the various site systems and roles. If you will be using protected DPs,
verify they are working correctly and clients are not pulling packages
across a WAN because the local DP has boundaries defined incorrectly.
Tip: Pilot Deployment
Most problems with
ConfigMgr deployments are associated with the network infrastructure or
client-based security software such as client firewalls. Testing will
validate the solution works as expected. Piloting should uncover these
issues and allow ConfigMgr administrators the ability to develop
solutions.
The pilot phase of the
project is usually one of the longest phases. This is due to the issues
that arise, the efforts required to resolve them, and the processes that
may have to be followed. This phase will usually point out issues in
the production environment that were going unnoticed. The closer the lab
environment is to the production environment, the smoother the pilot
will be. Labs that accurately depict the production environment are
unfortunately rare and ultimately the pilot phase becomes a long and
costly one.
Tip: Package Failures
The lack of
time synchronization is frequently identified as the root cause of why
packages are not running at their advertised time.
Release clients the
exact same way you would for the production release. It is important to
follow the release plan to validate the overall solution design.
Deviating from the plan may lead to results that are incorrectly
positive. Verify the same features are enabled, collect the data from
the pilot deployments and tests, evaluate the data, and update the
solution design if needed. If the project team decides a ConfigMgr
feature needs to be changed from how it was originally architected,
testing and piloting that agent or feature should be started over to
validate the change did not cause a negative impact elsewhere or cause a
requirement to no longer be met.
Changes may be required to
the ConfigMgr solution at an agent, site, or hierarchy level to
accommodate needs discovered only through piloting the solution. Become
familiar with the Windows Event Logs and Performance Monitor tools.
Antivirus
software is frequently lacking in a lab environment due to the isolation
of the lab and the fashion in which it is built. When the ConfigMgr
solution is placed into production, antivirus and other management
agents are typically loaded on the system. You will want to exclude the
ConfigMgr site server inboxes, logs, and client cache locations. Exclude
the following list of file extensions from your antivirus software:
| adc | box | ccr |
| cfg | cmn | ct0 |
| ct1 | ct2 | dat |
| dc | ddr | i |
| ins | ist | job |
| lkp | lo_ | log |
| mif | mof | nal |
| ncf | nhm | ofn |
| ofr | p* | pcf |
| pck | pdf | pkg |
| pkn | rpl | rpt |
| sca | scd | scu |
| sha | sic | sid |
| srq | srs | ssu |
| svf | tmp | udc |
Deploying
The
deployment phase should be one of the easier phases in the project life
cycle. If tests were conducted in a legitimate fashion and pilot
scenarios were indicative of real-world conditions, deploying the
finalized solution should have no surprises. If there was no pilot
phase, and the production implementation is the first actual instance of
ConfigMgr in production, care should be taken to make sure no negative
impacts occur to production. Three critical tasks need to be monitored
when implementing ConfigMgr:
Agent rollout
Distributing of packages to distribution points
Advertisements targeted to systems where reboots may occur, such as patch packages
Depending on
the roles previously implemented, the scope of the pilot activities may
require reimplementing site servers and/or site systems. When utilizing
this model of test/pilot/production, it is important to validate the
consistency of the site server and site systems implementations.
Overlooked items can produce skewed results, disqualifying all other
tests performed in the given stage or scenario. If this approach is
desired, consider utilizing a scripted implementation of the specific
system.
Note: ConfigMgr Scripted Installations
Unattended setups using the /Script
command-line option are only supported on new installations of primary
sites, secondary sites, and Configuration Manager consoles.
Because you can deploy
ConfigMgr in a large variety of configurations, the technical ability
required for a successful implementation of Configuration Manager 2007
is greater than average. Knowledge of basic concepts is critical, and
collaborating with existing IT groups such as networking, security, and
database administration will likely be key success factors. Although
Microsoft provides a familiar wizard-based experience to implement the
ConfigMgr site server, much of the configuration and deployment tasks
occur outside this initial implementation experience.
By the time ConfigMgr
is deployed into production, the ConfigMgr project team will know the
permissions required to push agents, will have validated that time
synchronization is successful, will know the settings to deploy at
specific sites, will understand the network impact on given segments,
and will have a solid concept of the site systems in the hierarchy,
their roles, and the expected user experience.
After
ConfigMgr is rolled out, the ConfigMgr team, which may be different
from the project team, should take ownership and responsibility of the
day-to-day operations and maintenance of the solution.
