Planning

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

Figure 2. Planning phase activities

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 Roles and Responsibilities
Establishing the Lab Establishing the Lab
Developing the Solution Design Developing the Solution Design
Identifying Configuration Items Identifying Configuration Items
Monitoring Deployment Servers Monitoring Deployment Servers
Monitoring Deployed Desktops Monitoring Deployed Desktops
Verifying the Solution Infrastructure Verifying the Solution Infrastructure
Milestone: Infrastructure Ready 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 http://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

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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.

 

SE_SQRBULLET01.GIF

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