Planning

Figure 2 illustrates the primary tasks accomplished during the Planning Phase.

Figure 2. Planning phase activities

For more information about the planning phase in a DCM solution project, read the “Planning” section in the Desired Configuration Monitoring Planning and Installation Guide.

On This Page

Roles and Responsibilities
Establishing the Lab
Developing the Solution Design
Identifying Configuration Items
Monitoring Deployment Servers
Monitoring Deployed Desktops
Verifying the Solution Infrastructure
Milestone: Infrastructure Ready

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 1 lists those roles and defines the focus areas for each role cluster. For more information about MSF Team Model role clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 1. Roles and Responsibilities During the Planning Phase

Role	Focus
Product Management	Input into conceptual design Business requirements analysis Communications plan
Program Management	Conceptual and logical design Functional specification Master project plan and master project schedule Budget
Development	Technology evaluations Logical and physical design Development plan and schedule Establishment of the lab
Test	Testing requirements definition Test plan and schedule
User Experience	Usage scenarios and use cases User requirements Localization and accessibility requirements User documentation Training plans Schedules
Release Management	Design evaluation Operations requirements Pilot and deployment plan and schedule Network discovery Application and hardware inventory Interfacing with IT Operations and the Security feature team

Establishing the Lab

If the Desired Configuration Monitoring feature team does not already have one, it is advisable to establish a dedicated and isolated lab environment for use in developing and testing the solution. The lab should mirror the production environment as closely as possible to ensure that all aspects of the production environment can be accounted for in the development process.

At a minimum, the lab should include:

• A Microsoft Active Directory® directory service domain (Windows Server 2003 or Microsoft Windows 2000 Server) with administrative privileges.

• Windows Server 2003 with Service Pack 1 (SP1).

• SMS 2003.

• SQL Server 2005 or SQL Server 2000.

• SQL Server 2005 or SQL Server 2000 Reporting Services.

• MOM 2005 (optional).

• Microsoft Virtual Server 2000 or later (optional).

• Dynamic Host Configuration Protocol (DHCP) services.

• Domain Name System (DNS) services.

• Windows Internet Naming Service (WINS) (optional).

• Internet access for downloading updates, files, and so on.

• Test computers and servers that accurately reflect production computers.

• Software library, including the Windows operating system, Microsoft Office 2003 or the 2007 Office system, and any applications for which CIs will be created.

Developing the Solution Design

The solution design is the first comprehensive design document and is part of the functional specification. This design prepares the team members for their responsibilities during the Developing Phase. It builds upon the vision the team developed and upon technology information the team gathered during the Envisioning Phase, and it sets forth the conceptual, logical, and physical solution designs. Think of the processes that produce these designs as three overlapping stages of a design process that begins before the Envisioning Phase and continues throughout the project and afterward, with the project itself being only a component of a larger technology life cycle management process.

Conceptual Design

Conceptual design involves understanding the business requirements and defining the features and functions users need to do their jobs. The Product Management Role Cluster takes the lead in creating the conceptual design, which begins during the Envisioning Phase and continues throughout the Planning Phase. The conceptual design of this project should include:

• Design goals that describe the objectives of the project in ways that address the problem statements and business opportunities identified in the Vision and Scope document.

• The list of features and functions that the solution comprises. The conceptual design typically states this list in terms of the computer profiles, hardware settings, operating systems settings, and applications settings that are to be monitored.

• Usage scenarios that anticipate the ways in which different types of users will implement, administer, and use the solution. Revisit the user profiles defined in the Vision and Scope document and describe how the types of users identified will work with the solution. Tasks to document can include administering the distribution architecture, installing and configuring the solution on new computers, configuring DCM for first use, and using different components of the solution to implement business objectives.

Logical Design

Logical design uses the conceptual design and the current state of the technology infrastructure to define the new architecture at a high level. The logical design of this project should include:

• A high-level definition of the DCM architecture that the Deployment feature team will use to begin the deployment process on each affected computer as well as the configuration and placement of distribution points. This definition does not necessarily include the exact physical location of each distribution point but should outline the rationale behind choosing the desired locations.

• A high-level definition of the CI files to be created as well as a description of the software tools the team will use to prepare the CIs (typically, regmon and filemon).

Physical Design

Physical design goes into greater detail about the desired architecture, and it defines the hardware configurations and software products to be used. The physical design of this project should include:

• Specifications for the hardware configurations included in the scope of the project.

• Specifications for the software to be installed.

• The tools to be used for project development.

As a general rule, the solution design should contain enough detail to enable the team to begin work on the project plan. The team should complete the conceptual and logical designs by the end of the Planning Phase. The physical design is baselined to draft the solution design, but it continues to be refined throughout the remainder of the project, changing as the team makes and revises development and deployment decisions.

Identifying Configuration Items

The DCM Comparison Engine reads CI files and checks the computer for the presence of the settings listed in each CI. Because different systems in the organization will have a different hardware platform and will use distinct software, the Desired Configuration Monitoring feature team will require multiple CI files to monitor the BDD 2007 environment. The team will most likely have a set of CI files for monitoring the deployment servers and another set of CI files for monitoring the deployed client computers.

Monitoring Deployment Servers

The Desired Configuration Monitoring feature team can use DCM to monitor settings for the deployment servers necessary to maintain a BDD 2007 infrastructure. To learn more about the different servers used by a BDD 2007 solution, see the Zero Touch Installation Guide and the Deployment Feature Team Guide.

SMS

The BDD 2007 Zero Touch Installation (ZTI) deployment uses the SMS Operating System Deployment (OSD) Feature Pack to deploy computers over the network. The Desired Configuration Monitoring feature team can use DCM to monitor the settings on the computers running SMS that this solution uses. Table 2 shows a list of settings to monitor for this scenario.

Table 2. List of Settings to Be Monitored on Computers Running SMS

	Settings to be monitored on computers running SMS
	Distribution Points
	The Desired Configuration Monitoring feature team can use the SMS_DistributionPoint class in the root\sms_site code Windows Management Instrumentation (WMI) namespace to verify package settings on an SMS server.
	Advertisements
	The Desired Configuration Monitoring feature team can use the SMS_Advertisement and SMS_AdvertisementInfo classes in the root\sms_site code WMI namespace to verify advertisement settings on an SMS server.
	Services
	The Desired Configuration Monitoring feature team can use the Win32_Service class in the root\cimv2 WMI namespace to verify whether the different SMS services are available and running on an SMS server.

To learn how to create a CI with the above settings, read the “Building Configuration Items” section in the Desired Configuration Monitoring Planning and Installation Guide.

To learn how to deploy a CI for computers running SMS, read the Desired Configuration Monitoring Server Configuration and Deployment Guide.

Windows DS and RIS Servers

For BDD 2007 implementations that use Windows DS—the new version of RIS—use DCM to monitor Windows DS settings to ensure that the Windows DS server remains functional. Table 3 shows a list of settings to monitor for Windows DS and RIS.

Table 3. List of Settings to Be Monitored on Windows DS and RIS Servers

	Settings to be monitored on Windows DS and RIS servers
	Active Directory Computer Account Creation disabled in the Microsoft Windows Preinstallation Environment (Windows PE) image
	Use a File System data source to read settings from the Ristndrd.sif file in Windows DS and ensure that the ImageType setting in the [OS Chooser] section is set to WinPE.
	Windows PE logging
	Use a File System data source to check whether the Setupapi.log file is set to read-only in the Windows PE image used in RIS.
	Registry settings
	Use a Registry data source to verify the existence and value of the LogLevel DWORD registry entry in the TemporaryHiveName\Microsoft\Windows\Currentversion\Setup key described in the “Modifying the Registry Settings in the Windows PE Image” section of the Lite Touch Installation Guide.
	Tools.osc and Tlchoice.osc (RIS only)
	Use Files System data sources to verify the settings in these files according to the “Modifying Tools.osc and Tlchoice.osc Files” section of the Lite Touch Installation Guide.
	Login.osc , Welcome.osc , Install.osc , and Oschoice.osc
	Use Files System data sources to verify the settings in these files according to the “Modifying Tools.osc and Tlchoice.osc Files” section of the Lite Touch Installation Guide.
	Services
	Use the Win32_Service class in the root\cimv2 WMI namespace to verify whether the RIS or Windows DS service is available and running on the deployment servers.

To learn how to create a CI with the above settings, read the “Building Configuration Items” section in the Desired Configuration Monitoring Planning and Installation Guide.

To learn how to deploy a CI for computers running SMS, read the Desired Configuration Monitoring Server Configuration and Deployment Guide.

BDD 2007 Deployment Server

After BDD 2007 is installed, a set of files and settings are generated on the BDD 2007 deployment server and on an optional computer running SQL Server. The Desired Configuration Monitoring feature team can monitor these settings to ensure that they are not changed and that the deployment server continues to be operational. Table 4 shows a list of settings to monitor for deployment servers.

Table 4. List of Settings to Be Monitored on BDD 2007 Deployment Servers

	Settings to be monitored on deployment servers
	ZeroTouchInstallation.vbs
	Use a File System data source to read settings from the ZeroTouchInstallation.vbs file and to verify that changes affecting the functionality of the installation process have been made. For more information on the ZeroTouchInstallation.vbs file, read the Zero Touch Installation Guide.
	Litetouch.wsf
	Use a File System data source to read settings from the litetouch.wsf file and verify that changes affecting the functionality of the installation process have been made. For more information on the litetouch.wsf file, read the Lite Touch Installation Guide.
	Customsettings.ini
	Use a File System data source to read settings from the Customsettings.ini file and verify that changes affecting the functionality of the installation process have been made. For more information on the Customsettings.ini file, read “Appendix A: Customsettings.ini Reference” in the Deployment Configuration Guide.
	Admin DB
	Use a SQL Server data source to read settings from the ZTI Administration Database (Admin DB) and verify that changes affecting the functionality of the installation process have been made. For more information on Admin DB, read “Appendix B: Admin DB Database Schema Reference” in the Deployment Configuration Guide.

Monitoring Deployed Desktops

The Desired Configuration Monitoring feature team can use DCM to monitor the settings of computers deployed through BDD 2007. The following sections describe some settings that the team can monitor.

Components

The Desired Configuration Monitoring feature team can use the CI file to verify that the components listed in Table 5 are not installed in Windows XP and the components listed in Table 6 are not installed in Windows Vista. These components are examples from the default Unattend.txt file that the Computer Imaging System creates for each build.

Table 5. Windows XP Components

ID	Setting
CMP-01	Freecell
CMP-02	Hearts
CMP-03	Minesweeper
CMP-04	Pinball
CMP-05	Solitaire
CMP-06	Spider
CMP-07	Zonegames

Table 6. Windows Vista Components

ID	Setting
CMP-01	Chess Titans
CMP-02	FreeCell
CMP-03	Hearts
CMP-04	Inkball
CMP-05	Mahjong Titans
CMP-06	Minesweeper
CMP-06	Purble Place
CMP-07	Solitaire
CMP-08	Spider Solitaire

The Desired Configuration Monitoring feature team can create CI rules to verify the existence of components in the monitored computers. These rules can use a WMI data source that consumes data from the Win32Reg_AddRemovePrograms class in the root\cimv2 namespace.

For more information on how to create WMI rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

Drive Mappings

The Desired Configuration Monitoring feature team can create CI rules to verify the existence of mapped drives in the monitored computers. These rules can use a WMI data source that consumes data from the Win32_MappedLogicalDisk class in the root\cimv2 namespace.

For more information on how to create WMI rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

Environment Variables

The Desired Configuration Monitoring feature team can create CI rules to verify the existence of environment variables in the monitored computers. These rules can use a WMI data source that consumes data from the Win32_Environment class in the root\cimv2 namespace.

For more information on how to create WMI rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

File Associations

The Desired Configuration Monitoring feature team can create CI rules to verify file association settings in the monitored computers. These rules can use a Registry data source that connects to the HKEY_CLASSES_ROOT registry subtree.

Table 7 describes file associations that a CI can monitor for Windows XP and Windows Vista alike. The file associations defined in Table 7 are not related to BDD 2007. They are examples that show how the customer can monitor a computer for changes to file associations, which can indicate a new program installation or a hijacked file association.

Table 7. Windows XP File Associations

ID	File extension	Association
FA-01	.htm	htmlfile
FA-02	.html	htmlfile
FA-03	.url	InternetShortcut
FA-04	.vbs	VBSFile
FA-05	.js	JSFile
FA-06	.wsf	WSFFile

Note   Users can be prevented from accidentally launching certain types of files by severing their file associations. Then, the Desired Configuration Monitoring feature team can use the DCM to monitor that these file associations stay severed.

For more information on how to create registry rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

Internet Explorer

The Desired Configuration Monitoring feature team can create CI rules to verify Windows Internet Explorer® settings on the monitored computers. These rules can use a Registry data source that connects to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer subkey.

For more information on how to create registry rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

Service Startup

The Desired Configuration Monitoring feature team can create CI rules to verify the existence and startup settings of different desktop services available to Windows XP and Windows Vista. These service settings are configured in setsvc.bat, which is a default action in the Computer Imaging System. Some of these services are listed in Table 8.

Table 8. Service Startup

ID	Service	Start mode
SSU-01	Alerter	Disabled
SSU-02	AppMgmt	Automatic
SSU-03	TrkWks	Automatic
SSU-04	LicenseService	Disabled
SSU-05	Messenger	Disabled
SSU-06	Mnmsrvc	Disabled
SSU-07	NetDDE	Disabled
SSU-08	NetDDEdsdm	Disabled
SSU-09	RSVP	Disabled
SSU-10	RemoteAccess	Manual
SSU-11	T1ntSvr	Disabled
SSU-12	MSIServer	Automatic
SSU-13	Wmi	Automatic

The Desired Configuration Monitoring feature team can create CI rules to verify the existence of components in the monitored computers. These rules can use a WMI data source that consumes data from the Win32Reg_AddRemovePrograms class in the root\cimv2 namespace.

For more information on how to create WMI rules, read “Building Configuration Items” in the Desired Configuration Monitoring Planning and Installation Guide.

Miscellaneous Settings

The Desired Configuration Monitoring feature team can use CI rules to verify other settings. Table 9 describes various unrelated settings that can be included in a CI.

Table 9. Miscellaneous Settings

ID	Setting	Notes
MISC-01	System Restore	Enabled
MISC-02	Remote Desktop	Enabled

Verifying the Solution Infrastructure

While the Desktop and Server Configuration feature teams are identifying the computer profiles and CIs, the Deployment feature team can start to verify the solution infrastructure against the existing IT infrastructure.

The following list shows the necessary components for a DCM solution:

• SMS site server and distribution point

• SQL Server 2005 or SQL Server 2000 Server Reporting Services

• MOM 2005 (optional)

• A computer running Windows XP and/or Windows Server 2003 with the Microsoft .NET Framework 1.1 or later

Keep in mind that SMS will be used to created software distribution packages to collections that will map to the computer profiles that the computer and server configuration teams will create. These packages will contain the CI and DCM Engine files. These files will not be smaller than a couple of megabytes. Therefore, traffic that software distribution generates will not be a major problem.

The information above is necessary to determine which distribution points to use to store the software distribution packages that the team generates. Data that monitored computers generate will vary according to the amount of settings being monitored, the monitoring frequency, and the configuration changes being made to the systems. However, this should account for just a few kilobytes of data unless there are some extremely non-compliant systems on the network, in which case, the Desired Configuration Monitoring feature team should make changes to such systems (or their CIs).

SQL Server 2005 or SQL Server 2000 Reporting Services is used to generate reports on the basis of the data that the DCM Engine collects and stores in the SMS database. Although not required, study the need for a high-availability solution for SQL Server 2000 Reporting Services based on the customer’s need to access the reports. The same should be considered for the SQL Server system hosting the SMS database.

MOM 2005 can be used to create alerts and respond to events as they occur on some monitored systems. If MOM 2005 is part of the solution, document which computer profiles MOM will monitor and check the current MOM infrastructure to verify which systems MOM currently monitors.

Finally, a computer system running the different operating systems and applications to be monitored should be available for developing and testing. Install and use the DCM Authoring Tool on this system. The Authoring Tool requires Microsoft .NET 1.1 or later.

Milestone: Infrastructure Ready

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

At this milestone, shown in Table 10, the development environment has been prepared.

Table 10. Deliverables

Deliverable ID	Description
Infrastructure Ready	The necessary servers and client systems are ready for the development team to create CI files.

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions