Installing CM202007

Aidan Finn 14/02/2007
Installing Configuration Manager 2007

An Introdu ction to Sys tem Center Configuration Manager 2007
Abstract This document will introduce you to Co nfiguratio n Manager 2007, it s new features, and design strategies and how to install the core functionality of the product .
Table of Contents
Table of Contents .................................................................................................................................... 2 Introduction .............................................................................................................................................. 4 New Features of CM 2007.................................................................................................................... 5 Security .................................................................................................................................................. 5 The Client .............................................................................................................................................. 5 Network Access Protection ............................................................................................................ 5 Operating System Deployment ..................................................................................................... 6 The Administrator Console ............................................................................................................ 6 Software Update Management ...................................................................................................... 6 Branch Distribution Points ............................................................................................................. 8 Advertisements Not Replicated To Secondary Sites ............................................................ 9 Network Tools ..................................................................................................................................... 9 Product Compliance .......................................................................................................................... 9 Assetmetrix ........................................................................................................................................... 9 Configuration Manager 2007 Architecture ................................................................................ 10 Sites ...................................................................................................................................................... 10 Site Boundaries ................................................................................................................................ 11 Site Services....................................................................................................................................... 12 Site Components .............................................................................................................................. 12 Inter-Site Communications ......................................................................................................... 14 Architecture ........................................................................................................................................... 16 Locating the Site Components .................................................................................................... 16 Site Architecture .............................................................................................................................. 17 Site Scenarios .................................................................................................................................... 18 CM 2007 Requirements ..................................................................................................................... 23
Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/
2 website@highwaycsl.com
The Client ........................................................................................................................................... 23 Client Devices.................................................................................................................................... 24 Site System ......................................................................................................................................... 25 Site Component Requirements .................................................................................................. 26 Site Server .......................................................................................................................................... 27 Some Notes ........................................................................................................................................ 27 Installing CM 2007............................................................................................................................... 29 About This Installation .................................................................................................................. 29 Pre-Installation ................................................................................................................................ 29 Installing the Site Server .............................................................................................................. 36 A Quick Look Around ..................................................................................................................... 43 Configuring the Site ........................................................................................................................ 48 Targeting Clients ............................................................................................................................. 75 Clients and Agents ............................................................................................................................... 82 Configuring the Agents.................................................................................................................. 82 Deploying Clients ............................................................................................................................ 93 Summary ............................................................................................................................................... 107
Introduction
It is expected that in March 2007, Microsoft will release System Center Configuration Manager 2007, the successor to SMS 2003/2003 R2. This document aims to illustrate the new features in CM 2007, document the installation strategies and show an installation of the product. Quite briefly, the history of this product is one of progress. My first exposure to it was SMS 2.0. Colleagues who worked with it had not much good to say about it. Conversation with others led me to believe that it held much promise but it was painful to own. SMS 2003 was a much better product; in fact, I loved how easy it was to deploy and how powerful it was when used in conjunction with Microsoft Operations Manager 2005. Over time, a number of free to download feature packs extended to functionality of SMS 2003 so that it could automate the deployment and management of more and more of the network. SMS 2003 Release 2 (R2) was a minor update. In included SMS 2003 with Service Pack 2 and 2 exclusive feature packs that added the ability to scan security and manage updates for third party and/or in-house developed applications. CM 2007 continues the gradual improvement process that was seen from SMS 2003 to SMS 2003 R2. However, its a much bigger and much more worthwhile leap. This whitepaper will: Document the new features of CM 2007. Explain the basics of CM 2007 architecture. Give examples of deployment scenarios using CM 2007. Present a sample CM 2007 installation.
This is the first in a series of documents based on CM 2007. In the future, you can expect to see documents that drill down into components of the product and provide more detail. This document is based on the Beta 1 Refresh release of CM 2007. Youll notice that the product still refers to things as SMS or SMS v4. This is likely to all change or Configuration Manager and Configuration Manager 2007 before it is released to manufacturing.
New Features of CM 2007

As Ive already mentioned, SMS 2003 R2 was a minor upgrade to SMS 2003. You have no fear of CM 2007 being just a minor upgrade. Administrators of CM 2007 will see that core functionality comfortably remains as it was. However, feature pack technologies have been improved and integrated, new deployment, security and management technology has been introduced and new architectural features have been added.
Security
CM 2007 only supports advanced security. Make sure you are familiar with using ADSIEDIT to create and permission a container.
The Client
There is no more support for the legacy client. There is only the advanced client.
Network Access Protection

NAP is a security policy enforcement feature that integrates CM 2007 with Windows Server Longhorn and Windows Vista. Windows Longhorn introduces a service called Network Policy Server or NPS. NPS allows administrators to define policies for defining what requirements a computer must meet before it can communicate with forest members. If the computer fails to meet these requirements then it will be allowed to communicate with those services which can assist with resolving the outstanding issues. Only until all issues are remedied will the computer be granted a ticket for normal operations. CM 2007 integrates with this quarantining solution to ensure that software updates that are managed by CM 2007 are deployed on client computers. Client computers work with NAP to audit their health and return this information to a System Health Validator (SHV) point, a new function in CM 2007. The SHV is installed on a Windows Longhorn Server that is also running an NPS. The SHV shares audit information with the NPS, thus enabling the NPS to control network access using software update status reports for the updates controlled by CM 2007. It must be noted that NAP and NPS are not intended to replace secure quarantining solutions such as those employed by Cisco at the switch level. These solutions can prevent a computer from even transmitting on a network. CM 2007 NAP and Windows Longhorn NPS are intended to enforce security configuration policies.
Operating System Deployment

The OS Deployment feature pack has been improved and integrated into CM 2007. There is, of course, support for Windows Vista deployment. OSD uses the Windows Image (WIM) format that you may be getting used to with Windows Vista, WAIK and Windows Deployment Services. Using OSD you can: Capture a template(s) PC to an image (WIM). Deploy an operating system image to a bare-metal PC using a CD/DVD/USB client. Upgrade or rebuild an existing PC via the CM 2007 client or agent. Use a sequence of tasks to perform a number of steps during client rebuilds. Capture a User State before you rebuild a client PC, rebuild the PC and then restore the users settings and files.
From this we can see that we can use CM 2007 OSD in some interesting ways: Administrators can centrally control the builds or rebuilds of clients. A client migration or upgrade can be controlled centrally, on a team, department, building or enterprise basis. If a user calls up to report extensive problems with their PC then helpdesk can rebuild it at the users convenience without travelling anywhere.
The Administrator Console

The Administrator Console in SMS 2003 was sometimes a pain to use. It is simple to navigate but dimple tasks like deleting many items at once or dragging and dropping just were not possible. The new console is based on MMC 3.0. Layout and navigation have not changed. However, the administration experience has improved: You can now drag and drop. You can select multiple entries and mass-edit their properties. You can select and delete multiple entries.
Software Update Management

The functionality that was added by numerous Inventory Tool feature packs for SMS 2003 and SMS 2003 R2 have been improved upon, consolidated and integrated into CM 2007.
Why would you consider deploying updates when there are easy to use and free tools such as WSUS (2.0) and WSUS 3.0 is on the way? The SMS 2003 feature packs and CM 2007 offer completely granular control of updates and very specific targeting based on the dynamic and ever changing nature of the client network and the requirements of the organisation. SMS 2003 and CM 2007 also give you the option of undoing an update deployment completely or from specific groups of computers. SMS 2003 and CM 2007 provide complete reporting on updates, update deployments and update deployment failures, including the causes of failures. Personally, Ive preferred WSUS for update deployment but I also have used SMS 2003 to audit the success of WSUS. However, I have found many organisations are unhappy with the control offered by WSUS and have wanted instead to use SMS 2003 feature packs. There were some flaws with the operation of the SMS 2003 feature packs. Deploying updates was a danger to your health. It wouldnt be a surprise is an SMS administrator who was responsible for update deployment would complain of early arthritis in their mouse finger caused by excessive clicking. There were easily 20+ dialogs involved in the update deployment process. Thats been improved upon, drastically. Also, the templates for answering common questions have been improved upon to make them more powerful. The Software Update process is now independent of the Software Deployment mechanism. Software Updates have their own agent on the CM 2007 client. You will also see that advertisements, packages and programs are no longer used. Instead there is a dedicated Update Deployment Package which is a rollup of updates. There is improved software update scheduling. Users of PCs or administrators of servers are made aware of updates when they are made available. After a configurable amount of time, reminders of the need to install the updates increase in their frequency. Users or administrators can initiate the installation at their convenience. Eventually, the update installation will be forced if the user/administrator does not start it by the deadline. Instead of downloading every available update, the Software Updates Agent uses selective downloading to only download updates that are applicable to the computer that has the CM 2007 client installed. Software Update Management is not restricted to the Microsoft security updates catalogue. The SMS 2003 R2 Inventory Tool for Custom Updates introduced us to
the ability to download catalogues from third parties (Citrix and Adobe) so that we could maintain the versions or patch levels of their products. We could also create our own catalogues for maintaining home-built or other 3rd party applications at the component level. Why reinstall a complete product when we can update a file or a registry setting via a patch? This custom catalogue feature allows us to do this with CM 2007. As I mentioned earlier, the Software Update Agent can be integrated with NPS in Windows Longhorn to quarantine clients that do not meet update requirements. A client that fails to meet requirements will be given permission to communicate with CM 2007 servers. Using Software Update Management, the client can update and then meet the requirements, thus permitting it to communicate with other forest members.
Branch Distribution Points

Any organisation with many branch offices (retail, banking, etc) that have looked at SMS in the past have had to consider very complex site architectures. Do you place traditional distribution points in every branch, thus making your sites span the WAN and increasing WAN traffic? Do you place a secondary site server in every site? Do you need to manage the span-out of secondary sites beneath your central site by introducing intermediate primary sites? Isnt the ideal way to deploy branch office computing to minimise the number of servers on the WAN? Do you employ a 3rd party solution such as 1E SMSNomad in the branch offices so that a normal SMS client (PC) can become an elected distribution point caching/proxy? There was no native solution in SMS for a large branch office network or for eliminating servers from the WAN. CM 2007 changes this by introducing the Branch Distribution Point. The BDP can be placed on a Windows computer (desktop or server) in the branch office and will act as a caching/proxy for the CM 2007 sites traditional distribution points. A client in the branch office will attempt to communicate with the distribution point via the Branch Distribution Point. Administrators can either preload the BDP with packages or allow packages to be downloaded on demand. The client in the branch will now only download from a local source and not have to download packages from across the WAN. Note that a BDP that is placed on a desktop computer will be subject to the licensing of that computer, i.e. only 10 concurrent connections can be made to the desktop
versions of Windows. If a branch office more than 7 or 8 computers then you may wish to consider using a server to host the branch distribution point. Solutions such as a Wide Area Data Network, e.g. Riverbed Steelhead, can replace the need for any kind of distribution point in a branch office and will also accelerate other TCP based applications that are centrally located.
Advertisements Not Replicated To Secondary Sites

In SMS 2003, a legacy client could be a member of a secondary site. This is not a possibility with an advanced client, i.e. it must always be a member of a primary site. Because there are no more legacy clients in CM 2007, there is no more need to replicate advertisements to secondary sites. This saves a significant amount of WAN bandwidth.
Network Tools
The network monitoring agent and tools are no longer included in CM 2007. Instead, you can get the complete functionality that was included in the new Network Monitor v3.0.
Product Compliance
Product compliance reporting has been removed from CM 2007.
Assetmetrix
Microsoft acquired Assetmetrix in 2006. This company produced a network auditing solution. Their software auditing solution is being integrated into SMS 2003 SP3 and into CM 2007. No details are available yet. The functionality was not included in the Beta 1 Refresh build. This solution is much more advanced than the existing What is in Add/Remove Programs? or scan every EXE approaches that SMS administrators currently must employ. It will uniquely identify applications based on file attributes and will even be able to identify license types and compliance using a frequently updated software identification database.
Configuration Manager 2007 Architecture

The basics of CM 2007 architecture have not changed very much. You have read some brief information of the changes in the previous section. I am not going to assume that the reader of this document has an understanding of SMS 2003 architecture. I will go though the basics of CM 2007 architecture which will include those components shared by both products. If you are an SMS 2003 administrator who is familiar with this subject then the only new stuff for you will be the Branch Distribution Point. Youll also be glad to hear that Microsoft is currently referring people to the first four chapters of the SMS 2003 Concepts, Planning and Deployment Guide followed by reading about whats new in the product (the previous section).
Sites
SMS or CM 2007 architecture is based on the concept of a site. Similar to an Active Directory site, a CM 2007 site is a collection of well defined networks. We can list each of these networks in the site definition or we can just reuse our Active Directory site definitions, i.e. enter the names of the Active Directory site(s) that the CM 2007 site equates to. There are two kinds of site in an SMS hierarchy. A primary site always exists at the root of the hierarchy. A primary site contains (advanced) client members who will receive the policies as defined by their CM 2007 site servers. The root site can have child sites which can also be primary sites. Any thing done at the parent site (package deployment, software update management, etc) will be inherited by child sites. In turn, the child site sends data back up the hierarchy, e.g. audit data, package deployment results, etc. A child primary site allows administrators of that site to perform their own administration tasks independent of the parent site. These operations will be inherited by their child sites but not back up the hierarchy to the parent site. A secondary site is a site that is used to optimise network bandwidth utilisation with the simplest configuration possible. If you have a branch office with significant numbers of clients then rather than have them communicate with a central primary site server or deploying a child primary site, you can just install a secondary site. A secondary site does not allow for delegated administration like a primary site. A secondary site allows for some limited customisation and allows some site roles to
be located on the local network. This results in reduced WAN bandwidth utilisation, e.g. clients access a secondary site distribution site and clients efficiently feed audit data back to their primary site via the secondary site servers. Unlike a primary site, a secondary site cannot have child sites. You could view a secondary site as being a caching copy of its parent primary site. There is another distinction between primary and secondary sites. A primary site requires a SQL installation for the site database, a SQL license for the SQL installation and a CM 2007 license for the primary site server. A secondary site requires no SQL, no SQL license and no CM 2007 license for the secondary site server.
Site Boundaries
As I mentioned earlier, a site is a collection of well connected networks. In the real world, though, things are not always black or white. We have to be able to deal with scenarios where client computers roam. For example, how do you control software distribution when a Dublin laptop roams from the city centre HQ to a branch office in the suburbs? Do you allow the client to download a software package from the HQ distribution point across the WAN connection, even if it is capable? What do you do if the same laptop travels to the USA office and looks to download the same package over a latent and heavily used WAN connection? We can control these scenarios with site boundaries. A site is a collection of well connected networks. Usually we are talking about LANs or high performing campus networks. We assume that any machine in the site should be able to access any SMS resource within the site without causing excessive network utilisation issues. There should be no problem if a client connects to a distribution point to download and install an application across the sites network(s). A local roaming boundary is a set of networks that are closely linked to a site. In my above scenario, I mentioned that the client laptop roamed from the HQ site to a branch office network in the suburbs. The WAN connection was considered capable of supporting software distribution over the WAN from a nearby office, e.g. the HQ, due to low latency and available capacity. The address ranges or the Active Directory site name of the suburb branch office can be added to the HQ CM 2007 site as local roaming boundaries. We can now define rules on how to treat each software distribution for HQ site members when they travel to the branch office. We have the choice of instructing the client to install the software directly from the
HQ distribution point or do we instruct the client to download the installation package first before starting the install. In the case of our USA branch office, we have the ability to specify its networks as being in the remote roaming boundary of the Dublin HQ CM 2007 site. This allows us to sometimes allow software installation by roaming Dublin clients from the Dublin distribution point when they are in New York. There may be small programs, updates or critical fixes that you need to be able to deploy no matter what the circumstance is. When we are doing software distribution we can specify some rules for clients when they are in the remote roaming boundary. The default is not to run the installation until they are in a local roaming boundary or back in the sites networks. Alternatively we can instruct the client to install the software directly from the distribution point or to download the installation package into the client cache before starting the install.
Site Services
A site will contain a site server running the SMS Executive and the SMS Component Manger services and an optional set of site systems or site components. Site components can be installed on the site server or on other machines depending on the scale of your site. SMS Executive The SMS Executive is the main service that manages all operations of CM 2007. SMS Component Manager The Component Manager is responsible for installing site components and for continually checking that they are executing correctly. Site Database Every primary site requires a site database, running on SQL 2005. This is not a huge database but its location is important. You could install this on another server but Microsoft does recommend that it is placed on the CM 2007 site server. The site database will run a service called the SMS SQL Monitor Service.
Site Components
There are a number of site systems that can exist in a CM 2007 site. Most of these are the same as they were in SMS 2003. But there are a few new ones. In a typical, single SMS server per site scenario, youll find that most, if not all, of these sites systems are on one server. But it a medium to large environment, you may find that
performance or load requirements will require you to separate these roles onto different servers. Server Locater Point The server locator point assists the CM 2007 advanced client to initially detect what site it is in. From then onwards, it helps the advanced client detect the location of client access point. Management Point Advanced clients communicate with CM 2007 through the management point. The client is configured by the management point. A client receives details about software distribution that is intended for the client from the management point. Distribution Point Any thing being distributed to clients is shared to them via a distribution point, which behind the scenes, is actually a file share. Always choose a location that is capable of scaling to store all of your future packages. It is possible to have many distribution points in a site to handle a larger client base. Clients will use the BITS protocol to download packages from the distribution point so that service interruptions can be tolerated. Branch Distribution Point This new feature was added to support smaller branch offices that cannot justify having an SMS primary or secondary site and where it is not feasible to replicate packages to a normal distribution point over the WAN. You can preload a branch distribution point with packages. Alternatively you can configure a software distribution package so clients trigger an on demand download to the branch distribution point. After this, the client downloads the package locally from branch distribution point and it is then available to other local clients. A branch distribution point can be placed on any advanced client. Note that a distribution point that is placed on a desktop operating system is subject to the limit of 10 concurrent connections. The branch distribution point does not optimise CM 2007-Agent management or reporting related communications. You must use a secondary distribution point for this.
Reporting Point The reporting point is a web server that allows SMS administrators and delegated groups to access reports that are based on data generated and gathered by CM 2007. Reports can include software audits, hardware audits, software metering (utilisation), software distribution success/failure reports, etc. The out-of-the-box reports are pretty comprehensive but you can add your own if you dont find what you need. Device Management Point Devices such as Windows enabled PDAs and phones can be managed directly by CM 2007. These devices communicate with CM 2007 via the device management point. The device management point must be installed on the same server as the management point. System Health Validator Point The system health validator point is installed on a Windows Server Longhorn computer that is also hosting a network policy server. This enables the CM 2007 client to share information about software update compliance with the NPS. The NPS can use this information to restrict communications by the client with other forest members until the client reports that it is been updated to a sufficient level. State Migration Point During operating system deployment to upgrade existing PCs it is possible to temporarily gather and store a users settings and personal files from the PC before the OS image deployment begins. Once the OS is upgraded the user state is downloaded back onto the client. The state migration point is the location where this data is stored during the upgrade and for a predefined amount of time afterwards. This location is a file share and should have enough capacity to handle the expected amount of user state data that will be stored at one time.
Inter-Site Communications
Sites need to communicate with each other. This is done using senders and addresses. A sender is configured on the parent and the child site to define a communications protocol. Different senders exist to handle varying scenarios. An address uniquely identifies the endpoint or destination of a sender. An address is sender type specific. Therefore if your site has two methods of communicating with it then it should have 2 addresses. These are the different types of sender that provide connectivity for sites:
Standard Sender: This is the normal sender you will use based on TCP/IP connectivity. Courier Sender: This allows you to communicate with remote sites in the parent-child relationship when there is limited connectivity with them, e.g. a heavily used WAN. Packages can be sent to the destination site by courier, i.e. on CD, DVD, etc. Courier packages are managed (exported and imported) using the Courier Sender MMC in the Start Menu. Asynchronous RAS Sender: To be used over an asynchronous communications link. ISDN RAS Sender: To allow ISDN inter-site communications. X25 RAS Sender: To be used over an X.25 link for inter-site communications. SNA RAS Sender: Used on SNA links between sites.
Architecture
Weve had a look at the various components in an SMS site and the different types of sites that are available. Now we will look at how to deploy them. I have to qualify this section. Accurate recommendations about client numbers in a site, numbers of direct child sites (scale out) or numbers of distribution points in a site have not been released yet.
Locating the Site Components

Typically, all site components will be on one server. When you should move them onto other servers really depends on site scale and performance monitoring of your SMS server. There are no guidelines or even any rules of thumb. Some things to watch out for are: Make sure you have enough disk space for packages on your distribution points. Place branch distribution points on servers if you think that the number of concurrent connections (including non VM 2007 traffic) to the host computer will exceed the limit of 10 for workstations. If you are going through a major client rebuild or migration using CM 2007 then you might consider placing the state migration point onto a dedicated storage server, e.g. a NAS running Windows Server 2003 Storage Server SP1. If reporting is a major function in a very large site hierarchy then you may have a scenario where the reporting point should be located on a dedicated server. You may require a dedicated or even many distribution points when you find that server capacity is being exceeded by the load created by all clients attempting a package installation at the same time. Note that the limitations on the numbers of distribution points were reduced with SMS 2003 SP1.
The key to all of this is that you monitor your SMS site server. When you notice a performance hit then you can trace the bottleneck and take the necessary actions, e.g. the single distribution point is too slow so add another one or. Some situations can be predicted so you can take preventative action, e.g. you are about to start a 200 PC migration so you temporarily move the state migration point to a NAS box.
Clustering Information is limited at the moment but the distribution point, server locator point and the management point can be clustered using Network Load Balancing. Failover clustering of the site database is not supported. Microsoft recommends the use of database replication or log shipping for database fault tolerance.
Site Architecture
There are a number of scenarios to consider. We also have to look at the pros and cons of using the primary sites, secondary sites and branch distribution point (instead of a site). Site Type Primary Site Pros Primary sites can be reconfigured to report to a new parent site, unlike secondary sites. Allow different site settings. Control network traffic between sites using senders. Allow better communication fault tolerance between sites. Secondary Allow different site settings. Site Control network traffic between sites using senders and a proxy management point. Allow better communication fault tolerance between sites. Can be remotely installed using the SMS Administrators console. Less administration. Does not require CM 2007 license. Does not require SQL 2005 license or installation/administration. Branch Flexible. It can be quickly Distribution deployed with little effort. Point Do not require a server operating system. Cons More administrative overhead. Require CM 2007 license. Require SQL 2005 license and installation/administration. Does not allow for remote installation using the SMS Administrator console. Not flexible. A change of parent requires a reinstall. Does not allow direct administration. It is managed via the parent site(s). The site cannot be delegated for administration. Cannot have SMS clients assigned to them.
Does not allow different site settings. Allow minimal control of bandwidth between locations.
Does not require a CM 2007 license. Does not require a SQL license or installation/administration. Will minimise the amount of package download traffic between a branch office and the centrally located site distribution point. Cheap and quick. No additional site administration. Much simpler site architecture for organisations with large branch office networks, e.g. retail.
Reporting, auditing, client management traffic is not minimised. No communications fault tolerance because there are no senders. Only package distribution is optimised. Requires that packages be downloaded and executed on the client. Does not allow programs to be run across the network
Site Scenarios
Single Site - Simple An organisation with several hundred clients wants to deploy CM 2007. It is possible to install a single server with all required site components on the network. Single Site Simple: Complete Desktop Migration The organisation has a single server with all required components on it. They occasionally build/rebuild PCs using CM 2007 as required. The state migration point is on the site server. They are planning a complete rebuild of all PCs over a 1 week period. User state migration is required to retain user settings and data. This will consume more disk space than is available on the site server. They can deploy a dedicated storage server, e.g. a NAS running Windows Server 2003 Storage Server with SP1. The state migration point is moved onto this new server. It will remain there until all PCs have been rebuilt and all state migration data has aged/purged as required.
Single Site Huge An organisation has many thousands of computers to manage via CM 2007. They have found that they need more than one CM 2007 server. There is also a need for fault tolerance where possible. They have a DR site and would like to minimise downtime. The DR site is specified to handle fewer users (a skeleton crew) during invocation. A site server is configured. A number of distribution points are configured on dedicated servers in a network load balanced cluster. A server locator point and a management point are also located on dedicated servers in a network load balanced cluster. The SQL 2005 site database was placed on a dedicated server. Data replication is enabled to replicate the site database to an identically built server in the DR site. The DR site also contains an identically specified server as the site server. Only the server OS is installed. CM 2007 software is downloaded onto the server, allowing for a disaster recovery. CM 2007 site backups are done in the production server and copied to the DR server. In the event of a DR invocation, the site server will be recovered and new site components will be deployed onto the same server. Multiple Branches Small Branches A retail operation has a single headquarters with centralised IT operations and server locations. There are many branches on the WAN with user numbers varying from 3 to 20. The network architecture does not allow for clients to communicate directly with the site distribution point directly. A single site will be configured initially with all site components installed a single site server. Branch distribution points will be deployed to each branch office. Smaller offices (<=7 managed computers) will have their branch distribution point installed on a desktop computer running Windows XP Professional SP2 or Windows Vista. Larger offices (>7 managed computers) will have their branch distribution point installed on a system (possibly a PC or budget server) running Windows Server 2003 or Windows Server Longhorn. Packages will be configured to be deployed to branch distribution points on an on demand basis, i.e. they will only download to a branch distribution point when a client in the branch requires the package. It will be important for the CM 2007 administrators to monitor server load on the central site server. There may be a need to deploy more distribution points in the site to handle branch office numbers (and hence branch office distribution point)
and concurrent connection loads. It will also be important to monitor desktop numbers growth in branch offices. This is because any branch distribution point on a desktop OS will reject more than 10 concurrent connections. This includes non CM 2007 connections. Those affected offices will require the branch distribution point to be migrated onto a server OS. Multiple Sites Medium: Centralised Administration An organisation has a central office with centralised administration. There are 15 medium sized offices with managed computer numbers varying from 20 to 300. There is at least one server in each branch office. Local IT administration (if it exists) handles first level desktop and server operations tasks, e.g. backup management. Cross WAN traffic must be minimised so as to not impact business applications. A single site server is located in the HQ with the centralised IT staff and the computer room. Secondary sites are deployed from a central location to suitable servers in each of the branch offices. No primary sites are required because there is no need or desire to delegate CM 2007 administration to local IT staff. Reporting can be delegated from the central sites reporting point as necessary. A proxy management point is deployed to optimise client-site server traffic because the branch office clients are still members of the primary site. Multiple Sites Huge: Complex Branches with Delegated Administration The organisation has a headquarters located in Dublin. All Irish branch offices are small, with user numbers varying from 3 to 20. European offices are located in London and Munich. They have 300 users but there is no local CM 2007 administration required. There is a North American division with its own child domain in the forest. The NA division is in San Francisco. They require the ability to manage computers in their office but also in large branches in New York and Calgary. They should have no rights over operations in Ireland or Europe. Neither of the NA branches requires local administration. Sounds messy? At first, maybe. But take each part of the problem and consider the building blocks that are available to us to architect a suitable CM 2007 hierarchy. Lets look at Ireland first. We have no idea how big the total organisation is. But, CM 2007 is pretty scalable. It is also pretty flexible as the requirements change. We will start with a single site server (primary site) as our root in Dublin. All site components will be located on this server.
The Irish branch offices are small. They will all be defined as part of the Dublin primary site using the site boundaries. Branch Offices with 7 or less managed computers will have a branch distribution points placed on desktop computers. It is likely that the computer hosting this role will also double as a print server so we need to be wary of the desktop OS limit of 10 concurrent connections. Branch offices with more than 7 managed computers will have a branch distribution point placed on a server. Now we can move onto Europe. We dont need local administration but we do need to be wary of having too much client-site server management traffic. This rules out the use of branch distribution points. London and Munich will each be set up as a secondary site with a proxy management point. North America has a child domain. CM 2007 has no problem with this. In fact, CM 2007 can have sites in different forests. Note that a site cannot span forests. There are also considerations where WINS must be enabled for cross-forest client roaming. A primary site is configured in San Francisco and is configured so that Dublin is its parent site. A single server is all that is required. All tasks that are deployed by Dublin will be inherited by New York, e.g. if Dublin deploys Office 2007 to all desktop operating systems, this will be applied in Dublin, Ireland, London, Munich and the clients that are members of the San Francisco site (and possible child sites). All reporting data will be forwarded back to Dublin. Local Roaming Boundaries and Remote Roaming Boundaries are configured to ensure that Dublin/Irish/European clients can correctly download/install packages (or not) from European distribution points when in North America and vice versa. A secondary site is created in each of the Calgary and New York sites and a proxy management point is deployed. No local administration is required. Now, Dublin and San Francisco administrators can manage these branch offices. Reporting data is stored in San Francisco and forwarded to Dublin so that consolidated and complete reports on the organisation can be generated. Multiple Sites Centralised IT: Complex Branches with Network Optimisation Consider the previous scenario with a Dublin HQ and offices around Ireland, Europe and North America. Many organisations have realised that complex IT deployments (servers, software, backups, DR, staffing, etc) are expensive and provide an ineffective service. They may have looked at Server Based Computing solutions
(Terminal Services, Citrix, etc) because they come with their own costs and problems thus moving the difficulties from the branch to the HQ. An alternative is to use a WAN optimisation solution that allows for complete centralisation and consolidation of server placement. An example of such a solution is the Wide Area Data Network as provided by the Riverbed Steelhead family of appliances. These devices are placed in the HQ and the branch offices. They invisibly intercept and break down TCP traffic into unique blocks that are identified and cached. Further requests for identical traffic no longer need to cross the WAN. Instead the two Steelhead appliances work together to invisibly replay the TCP streams locally on their own LANs. An example is a user in New York opens a file on the Dublin server. The traffic stream crosses the WAN but is broken down by both Steelheads, in Dublin and in New York, and cached. The user closes the file. Another user requests the same file. The Steelheads work together because most of this data has already crossed the WAN. The Dublin Steelhead replays the stream but injects the new users credentials. If this file operation can continue then it works with the New York Steelhead to allow it to replay the stream locally, but it injects the destination users computer into the stream. The result is that instead of the file transferring across the WAN, the user has actually opened a local cached replica. This optimisation even works with files or that are different. A similar file will create a TCP stream of almost identical blocks. These blocks are cached locally and can be replayed. And because the Steelhead is TCP based, it will do the same optimisation with Exchange, SQL, Oracle, HTTP and Configuration Manager 2007. In our scenario, a medium to high spec appliance is placed in the Dublin HQ. Suitably specified appliances are located in each branch office. Each branch is directly managed by the Dublin office over the VPN WAN. A single CM 2007 site server is placed in Dublin with all site roles. All branch office CM 2007 clients communicate directly with the site server in Dublin. This TCP traffic (client deployment, client management, package downloads, reporting, etc) is all optimised at the TCP level by the Riverbed Steelheads. The architecture is much simpler. Weve only got a single CM 2007 site. Weve optimised CM 2007 traffic. Weve also optimised all TCP traffic. This means that we can probably eliminate the need for any servers in the branch offices and relocate all server functions to the HQ assuming there are no regulatory requirements for local retention of business data, e.g. Luxembourg financial regulations require that business data stays in Luxembourg, even for DR scenarios.
CM 2007 Requirements
This section will deal with client and site server hardware and software requirements. If youve dealt with Microsoft requirements before then you know that minimum is just that the bare minimum. It means that, yes, you can install the product but it will probably not be useful in any way. System requirements such as RAM are very hard to predict. There are basic specs that we have learned over time as being a good starting point, but sometimes, they are just starting points and will require future upgrades or site component relocation. If you are budgeting and/or specifying hardware then leave room to spare. Keep some room in the budget. Dont fill all of the RAM slots in your servers. Be flexible and know that not everything can be predicted accurately. The information in this section is Beta 1 information. As such, it may not be accurate. It could also change during the continued beta process, through the release candidate(s) and up to the Release to Manufacturing (RTM).
The Client
We only have advanced clients now. There are no legacy clients so you can forget out of support operating systems such as Windows NT 4.0. Client Hardware The minimum requirements are: CPU: 233 MHz. Basically, any machine capable of being a productive business desktop with Windows 2000 Professional SP4 or higher. RAM: 128MB. Again, any machine capable of being a productive business desktop with Windows 2000 Professional SP4 or higher. Note that a machine that will use CM 2007 Operating System Deployment must have a minimum of 384MB RAM. This could be higher depending on drivers. A modern business desktop should have at least 512MB RAM for Windows 2000 or Windows XP for it to be productive. You will likely need 1GB RAM for a business desktop running Windows Vista for it to be productive. Disk Space: 80MB Free. This amount assumes that there is no cache on the client. The default cache size is 250MB, thus requiring 330MB. If you are deploying products such as Office 2007 via the client cache then you will want a much larger cache. Note: The client cache does not have to be used for software deployment.
Client Operating Systems The operating system requirements are as follows: Operating System X86 X64 IA64 Windows 2000 Datacenter, Service Pack 4 Y Windows 2000 Advanced Server, Service Pack 4 Y Windows 2000 Professional, Service Pack 4 Y Windows 2000 Server, Service Pack 4 Y Windows XP Professional, Service Pack 1 and higher Y Windows Server 2003 Web Edition, Service Pack 1 Y Windows Server 2003 Standard Edition, Service Pack 1 Y Y Y Windows Server 2003 Enterprise Edition, Service Pack 1 Y Y Y Windows Server 2003 Datacenter Edition, Service Pack 1 Y Y Windows Server 2003 R2 Enterprise Edition Y Y Windows Server 2003 R2 Standard Edition Y Y Windows Vista, Business, Enterprise and Ultimate Y Y Windows Server Longhorn" Standard Edition, Beta 2 Y Y Windows Server Longhorn", Enterprise Edition, Beta 2 Y Y Windows Server Longhorn", Datacenter Edition, Beta 2 Y Y Windows Server "Longhorn", Itanium Edition Y Some notes from the Microsoft documentation: Datacenter releases are supported, by not certified, for SMS 4.0. Hotfix support is not offered for Windows Datacenter Server edition specific issues. SMS 4.0 Beta 1 Refresh support for x64 systems will be through 32-bit code running on these 64 bit operating systems.
Client Devices
The following devices are supported by the Beta 1 Refresh release of CM 2007: Windows Mobile Pocket PC 2003 Windows Mobile Pocket PC 2005 Windows Mobile Pocket PC Phone Edition 2003 Windows Mobile Pocket PC Phone Edition 5.0 Windows Mobile Smartphone 2003 Devices Windows Mobile Smartphone 2005 Devices
We can probably assume that the newly released Windows Mobile 6 versions will be supported by the time that CM 2007 is released to manufacturing.
Site System
There are the core functionality of the site system and the optional site system components to consider. Site Server Hardware The following are the minimum requirements as documented by Microsoft: Processor: 750 MHz Pentium III minimum (2.0 GHz or faster recommended). RAM: 256 MB minimum (1024 MB recommended). I personally would start with 2GB because of my personal experience with SQL 2000 on an SMS 2003 server. Free Disk Space: 2 GB minimum (5 GB free recommended if using operating system deployment). This will give you bare functionality. Consider potential disk consumption by packages in your distribution point, state migration point, OS deployment images, software updates, SQL site database files, etc. Do not go cheap on disk.
Site System Operating Systems The below table shows which operating systems are supported for CM 2007 Beta 1 Refresh roles. Sorry about the squashed font and broken text, this is a lot of information to squeeze into a table.
Operating System Primar y Site Server Secondar y Site Server Manageme nt Point State Migratio n Point Distributio n Point Reportin g Point Server Locato r Point SQL Serve r System Health Validato r Point Admin Consol e Y
Windows 200 0 Professional, Service Pack 4 Windows XP Professional, Service Pack 1 and higher Windows Server 2003 Web Edition, Service Pack 1 Windows Server 2003 Standard Edition, Service Pack 1 Windows Server 2003 Enterprise Edition,
Y (1)
Y (1)
Service Pack 1 Windows Server 2003 Datacenter Edition, Service Pack 1 Windows Server 2003 Storage Server Edition, Service Pack 1 Windows Server 2003 R2 Enterprise Edition Windows Server 2003 R2 Standard Edition Windows Vista, Business, Enterprise and Ultimate Windows Server Longhorn" Standard Edition, Beta 2 Windows Server Longhorn", Enterprise Edition, Beta 2 Windows Server Longhorn", Datacenter Edition, Beta 2
Y (1)
Some notes: The distribution points marked as Y (1) refer to branch distribution points. It is very likely that the RTM release of CM 2007 will support all roles on the RTM release of Windows Server Longhorn. There is no support for Windows 2000 Server. Windows 2003 requires SP1 to be installed.
Site Component Requirements

There are a number of different software requirements for each of the site components:
Site Server
All servers hosting CM 2007 roles must be members of an Active Directory domain. A site may not cross forests. All site servers require Internet Explorer 5.0 or later.
Site Database Although the Beta 1 Refresh release supports SQL 2000, future releases including the RTM build will require SQL 2005. MSDE or SQL 2005 Express are not supported. Clustering the site database server s not supported. Administration Console MMC 3.0 must be installed on any machine that will run the console. All admin console computers must have .NET Framework 2.0 installed. Distribution Point A BITS enabled distribution point must have BITS 2.0 installed. This is highly recommended for client-distribution point optimisation. A BITS enabled distribution point must have WebDAV enabled. IIS is required for BITS support. Management Point The management point can be clustered using Network Load Balancing. IIS must be installed. BITS and WebDAV must be installed and enabled. Reporting Point IIS is required. Active Server Pages must be enabled.
Some Notes
Active Directory Schema The schema extension remains non-mandatory. If you have an existing SMS 2003 installation that you will update then you should upgrade these schema extensions for CM 2007.
Workgroup Clients Workgroup clients are supported but there are many negatives. Workgroup clients cannot use Active Directory to look up CM 2007 objects. Client discovery via Active Directory system or group discovery is not possible. It is not possible to target advertisements at users Use of software installation account is not possible Client Push installation is not possible Logon initiated installation is not possible Branch distribution point computers must be members of a domain.
For workgroup support to function, the following requirements must also be met: The server locator point must be published in WINS. This WINS database must be accessible to workgroup client machines; possibly requiring many WINS servers and WINS replication. Software distribution to workgroup members requires using the Network Access Account. CLIENT.MSI (the CM 2007 client installer) must be copied to and installed from the local source on each workgroup client machine. It should be left on the client as a local source for repair. Logged on users must have local administrator rights. The CM 2007 account will use the rights of the currently logged on user on a workgroup client.
Virtual Machines Obviously, a virtual machine can only be managed while it is running and connected to the network. There is support for all supported CM 2007 client operating systems (see client requirements) running on Microsoft Virtual PC and Microsoft Virtual Server 2005 R2 and later. We can assume that Microsoft will add the Windows Server Longhorn hypervisor product to this list. Users of other solutions, e.g. VMware, should note Microsofts support policy statement (http://www.support.microsoft.com/kb/897615) for non-Microsoft virtualisation solutions.
Installing CM 2007
Weve gotten the obligatory whats this all about? stuff out of the way. Now, we can go on and install CM 2007 and see what it looks like.
About This Installation

My Test Environment I am running this test environment on my laptop using VMware. All servers are running Windows 2003 R2, Enterprise Edition. My two workstations are running Windows XP Professional, SP2. All machines are in the same subnet. The CM 2007 server, DUBSMS1 has the following specification: Memory: 768MB Disk: 30GB SQL: SQL 2005
I would not recommend the above (low) specification for a production CM 2007 site server. Aims of the Installation We will be installing a simple, single site. There will be one site server with the ability to deploy software, software updates, and manage software. Required roles will be installed on the single site server and the CM 2007 client will be deployed to all Windows computers. At the end of the installation, the CM 2007 installation will be ready to manage all Windows computers in the single domain. Im not going to go through an SMS 2003 to CM 2007 upgrade in this document. As youve probably noticed, this one is getting pretty long already. Ill save that subject for a later date and another document. It does look like the process will be pretty straight forward, though.
Pre-Installation
Schema Update Well be performing a schema update. Ive never heard of a Microsoft schema update failing or corrupting a forest but anything is possible. I dont like to take chances. Make sure you have a backup of domain controllers in every domain. In my single domain scenario, I could pick one of my DCs, take it offline and perform the update. If the update fails I can bring all other DCs offline and bring my backup
DC online. The result will be that my domain is back up and operational with little downtime. I will have to do a metadata clean up and rebuild of the offline DCs. If nothing goes wrong, I simply power up my backup DC. This is not the only method to do an emergency rollback of a schema update but I like it because I can minimise my service downtime, albeit with a lot of rebuilds if things do go wrong. Advanced Security: New Active Directory Container You will need to create a new container in Active Directory and delegate permissions to it to your CM 2007 servers. You will need to do this with ADSIEDIT.MSC from the Windows 2003 Support Tools. I always urge people to only grant permissions to groups. For delegation, not only do I urge, but I insist on it. I have created a security group in my domain called CM Servers and placed by server, DubSMS1 in this group. Remember to allow Active Directory to replicate the group creation and membership change and then to reboot the computer after adding it to the group!
Launch ADSIEDIT and navigate into Domain\DC=<name>,DC=<name>\CN=System. Right-click on CN=System and choose to create a new object.
Choose container as the type of object as youd like to create.
Name the new container as System Management. That is System and not Systems. I have to admit to making that mistake on a frequent basis.
With this dialog, we only want to click on <Finish>.
Back in ADSIEDIT.MSC, we can see the new container. Right-click on the new container and choose to view its properties.
Click on the Security tab and then click on <Advanced>.
Click on <Add>.
Type in the name of the security group that your new CM 2007 server will be a member of. My group is called CM Servers.
Now we need to grant it some rights over the new container. Grant it Full Control over This object and all child objects.
We can now see the group will have full control.
Return back to the Security tab and click on <OK> once youve confirmed that everything is correct. Windows Pre-Requisites Install the following: IIS BITS 2.0 .NET Framework 2.0
Make sure that the following are enabled in IIS: BITS Active Server Pages
SQL 2005 must also be installed. You only need the database and management software. There is no need for reporting services. I highly recommend that you also install Network Monitor 3.0 on your site servers. Having network traffic analysis is very handy for troubleshooting. Our requirements for CM 2007 advanced security are now met. We are ready to install our first CM 2007 server.
Installing the Site Server

I recommend that you copy the CM 2007 media onto your server. Its pretty important to be able to access the media when you need to do recoveries should everything go *bang*. Load your media on the CM 2007 server and run AUTORUN.EXE.
Click on SMS Version 4 to install CM 2007. This buttons name will change in the future, as will other references to SMS and SMS v4.
Click on <Next>.
The installer knows that you are installing a new site server. Click on <Next>.
Choose to install a primary site. Note you can also install secondary sites with this wizard and you can install the administration tools on a PC with it.
Read the text on this dialog very carefully. Only use an Express setup for basic evaluation work. In SMS 2003, it would do horrible things like install basic security instead of advanced. Thats not a possibility now but we are still supposed to use a custom setup.
Click on <I Agree> and <Next> if you agree with the licensing terms.
You now need to enter the details of your site. Each CM 2007 is uniquely identified by a 3 character code. I am naming my site as Dublin and my code will be DUB.
I am choosing to extend the Active Directory schema. If I dont then I will have to install WINS and maintain a record for my server locator point. Make sure youve prepared for a schema update, e.g. backups, rollback plan, change control, anticipated Global Catalog replication. Try to have the Schema Master nearby and make sure you are a member of Schema Administrators.
These are the default components to install. I personally dont see the need for the Remote Tools. All it does as far as I can see is offer you a way to launch the RDP client from within the CM 2007 administrator console.
We now enter the site database server information. My site server will also be my site database server. Microsoft recommends this. There are occasions, though, where loads may dictate moving the database to another server. Dont rename the database for the sake of it. Keep the default name. It will keep things simpler in the future.
You are asked if you want to allow the installer to create the database. This is a good idea here.
Choose where to create the database. Typically, the site database is not very big nor has a heavy load so a simple deployment is fine. However, in huge networks, database performance may become a bottleneck. You can place the database files on another volume. Later on, you may move the database file and log file onto different RAID arrays for optimal performance.
We now can confirm everything is fine before clicking on <Finish> to start the installation.
The installation runs. This takes a while so its an opportunity to take a break.
Youll hopefully see something like the above if everything installs with no problems.
Open the Start Menu and navigate to Systems Management Server and click on SMS Administrator Console to start the CM 2007 administration console.
Your new MMC 3.0 CM 2007 administration console opens up after a few seconds, now giving you the ability to completely manage the configuration of all computers in your network.
A Quick Look Around

If youre like me, you like to have a good poke around once youve installed something new. So before we do any more work, lets have a quick tour of CM 2007. Im not going into great detail here. Ill delve into some sections when we configure our site and deploy our clients. Other subjects will be covered in future documents.
Under Site Management you can navigate and manage each of your sites. Sites allow you to have custom configurations. These configurations are managed under Site Settings. In here there are a number of controls: Addresses: This is where you configure the addresses that identify destinations of your senders. Client Agents: The piece of software we install onto managed computers is a client. Different functionality is enabled on the client by enabling agents. This is where we enable the agents for the site. Client Installation Methods: This is where we configure push installation of agents, i.e. the CM 2007 server will install the agents onto selected managed computers for us. Component Configuration: This is where we configure the site components, e.g. a distribution point. Discovery Methods: In order to manage computers, we must identify them. We have a number of discovery methods available to us to do this. Senders: This is where we configure our senders so we can have inter-site communications. Site Maintenance: A number of tasks are or can be performed on an automated basis to maintain the site and the site database. This is where they are configured. An example is the CM 2007 backup task. Status Filter Rules: These rules dictate how events are handled in CM 2007, e.g. sent to a parent site, written to a log and purged after a number of days, run a program, etc.
Status Summary: A set of rules that summarize data and forward it to parent sites according to rules. Site System Roles: This is where we deploy the site components, e.g. the distribution point.
Once we have configured a site, deployed site components and deployed our agents, we will want to carry out management and configuration tasks. Computer Management is where we do this: Collections: To perform a task, you need to target users and/or computers, often in large numbers. A collection allows you to identify users and computer and put them into groups that are referred to as collections. A collection is built based on a query, e.g. computers that have 512MB RAM or more, users in the Accounts OU, computers in the Desktop Admin security group. These queries can get quite specific and can utilise data gathered by Cm 2007 client and agent operations. Collections are dynamic, i.e. their query will usually re-run according to a schedule to rebuild the collection membership. A collection is associated with a task to ensure that the task only runs for users or computers that meet specific criteria. Packages: A package is the unit that is used for software deployment. A package consists of the installation files and programs. A program is an instruction that tells the CM 2007 agent how to use the installation files, e.g. perform a silent installation for the computer or perform a normal uninstall for a user. Advertisements: An advertisement associates a package, a package program and a collection with a schedule and some other instructions. The
advertisement is what tells an agent (defined in the collection membership_ that it must perform the program for a package at a certain time and according to certain rules. Software Metering: Using metering, we can tell when software is being used or when it was last used. This is done on a per executable basis using some rules to identify the file. Using metering, we can identify software that can be removed from PCs. An example is Project. It is not normally installed on every PC and requires an expensive license. We can install it for a user who requests it, wait X days after they last used it, uninstall the license and return it to a pool for future reuse. This will save on future licensing costs, i.e. the norm is that the license stays on the PC and the application is possibly never used again. Reporting: This is where we can create, modify, delete or manage reports. Queries: We can create queries that will be reused by collections. This can be a time saver when you have a large and complex collection structure. Software Updates: We manage catalogs and software update deployment in this section. Network Access Protection: By combining software update management with Network Protection Services from Windows Server Longhorn we can quarantine managed computers if they do not meet update requirements. Operating System Deployment: This is where we manage our images and tasks to deploy an operating system onto managed or new computers.
System Status is the first section you should visit after installing CM 2007. You need to make sure the installed system is running correctly, e.g. is your System
Management container set up correctly. You should make it a point to revisit here every now and then and after you make a site configuration change. Your revisits can be minimised if you manage CM 2007 using Microsoft System Centre Operations Manger 2007 (OM 2007) or MOM 2005 using a management pack. Advertisement Status: This is a summary showing the deployment status of all advertisements. Package Status: This is a summary showing the status of packages being replicated to distribution points in your site. Site Status: This is a key place to visit. This shows the status of site components and site systems in the site. The status messages provide a lot of information about the problem, possible causes and possible solutions. Do not ignore any warnings you find in here. Status Message Queries: These are a set of predefined queries for looking at status messages. You can extend this set with your own custom queries.
Security Rights is where we define permissions for classes and instances within the CM 2007 site. Youll need to go back to your object oriented theory to remember what a class and an instance is. A class is a description for a type of object. An instance is an example of a class. For example, Collections is a class. All Windows XP Systems is an instance of that class. Default permissions grant full control to domain administrators and to local system. You can delegate rights to classes or instances as you are required. For example, you may create a collection for desktops. You could then give permission to your
desktop administrators to this collection instance and to the class of advertisements and programs. Your desktop administrators could now manage software deployment on desktops without being able to affect servers or having any control over the other CM 2007 site settings. Another use is to delegate rights of report instances to non-IT staff, e.g. auditors can run reports on software update status and accounts can run reports on deployed hardware and software assets.
In Tools we can launch the SMS Service Manager. This allows us to manage the status of services or components of the site. The Online Library allows us to view the online reading materials. This doesnt appear to work in the Beta 1 Refresh build.
Configuring the Site

We have installed a CM 2007 site server. Can we start using it? Sure? What can we do with it now? Not much. We have to configure the site and deploy site components before we can do anything of much use with our site server. Check Your Status There is no point in us doing any work if the site is not healthy after the installation. Navigate into Site Status - <Site Name>.
Open Component Status. You should see lots of entries in there. Hopefully, if its like mine, its all green. If its not, theres a summary on the right (scroll over) that displays the count of errors and warnings.
If you need to see the events for a component then right-click on it and select Show Messages. You can view all messages, errors, warning or informational messages.
The Status Message Viewer opens up. You can now double-click on messages to view the problem, description and maybe a possible solution. At this point in the installation and configuration, usual suspects will be a poorly configured System Management container or missing required Windows components.
The site system status should also be visited. You can view messages here the same way as you did with the components.
Delegating Rights As I mentioned in the quick tour, only the default domain administrator (I was logged in as a domain admin during the installation for the schema update) and local system have been granted rights on my CM 2007 server. Thats fine for now but not for the future. Best practice is to minimise domain administrator account and group membership and account usage. It is likely that in a medium to large organisation that the CM administrators will not be domain administrators. To facilitate this, we need to delegate some rights within CM 2007. I have created a security group called CM Administrators. Any CM 2007 administrator will have their user account added to this group. I will delegate complete CM 2007 administration rights to this group. The first step is to give them local administrator rights (and hence local logon and RDP access) to the CM 2007 server. If youre reading this document then you should already know how to do those steps. Make sure you repeat these tasks for any other server in the site that will host a CM 2007 component. Well now grant rights to CM 2007. Navigate into Security in the administrator console. Were going to do this the easy way by copying the CM 2007 rights of the default domain administrator account and giving them to the CM Administrators.
Right-click on Security Rights and then click on Manage SMS Users.
This dialog is symptomatic of something I dont like in CM 2007. These welcome screens always appear and offer nothing to anyone who has seen them before. In SMS 2003, we could disable them after the first viewing. Click on <Next> to continue.
Select the group that you want to grant new rights to. Please do not grant rights to specific users. Its really bad practice, messy and leads to future wasted effort.
Choose to Copy rights from an exiting SMS user or user group.
In the drop down box, select the user you are copying from. In this case, its the default domain administrator account.
You are presented with a listing of the rights that the template user (the default domain administrator) has. If this is not enough then you can add extra rights. There are no other rights in this scenario. You could also add rights from another user. Were just going to select The listed rights are sufficient.
We get a summary. Click on <Next> to continue or <Previous> to make changes.
The task completes and hopefully youll see lots of green check marks.
We return to Security Rights and can see that our security group (and hence its members) have been given complete control over this CM 2007 site and all of its components and functions.
Site Maintenance Its a good idea to make sure our maintenance tasks are configured to meet our requirements before we go any further and add data to the site database. Navigate into Site Settings Site Maintenance Tasks.
You will see a number of tasks that CM 2007 can do to manage the data in the site database. I think they are all pretty self explanatory. The aims of the tasks are to purge aged data and to summarise or condense aged data. Usually, the default settings will be fine, but there is one exception to that: the Backup SMS Site Server task. This task needs to be enabled if you want any fault tolerance for your site server. The recovery process of CM 2007 requires a backup to be available. This task runs a backup and stores the backup as a file on a file system. You can store this locally or on a file share. An ideal solution if you have a DR site and a machine for CM 2007 DR (no CM 2007 installed!), is to save the backup on a file share on that machine. With this done, you can invoke your DR and repair or recover CM 2007 on that machine with the backup that you saved there. We will enable the backup task. Double-click on it to view its properties.
Youll get used to the red ! marks on dialogs. They indicate a mandatory field. In this example, enter the path, either local or UNC, to the folder where you want to save your backups. You should also enter the schedule that dictates when the backup will run. If your CM 2007 site is pretty busy then its a good idea to do this on a frequent basis.
When you save your settings, the folder will be created and a subfolder is also created.
Site Properties We now will look at the properties of the site. Navigate into Site Management, right-click on your site and choose Properties.
At the moment theres not much to do here. Later on, you can set the parent site of this primary site if you need to add it into an existing hierarchy.
In Accounts, we can change the SMS Service Account or the SQL Server account. Normally, you wont do this but you can if you are hardening the environment. You may also choose to use a specific account for the SQL connection if you move the site database onto another server.
We define the boundaries of our site in Site Boundaries. These are the networks that are part of the well connected environment of our office, building, campus, etc. It might not be a bad idea to change the boundary to be your Active Directory site rather than IP Subnet. If extra networks are added, the first thing to be changed to match the new topology is the Active Directory sites definition (subnets). I have a simple 1 subnet network so I know nothing will change.
Roaming Boundaries is where we define our local roaming boundaries and our remote roaming boundaries so we can define when our clients will act when they leave our site boundaries but still have communication with the distribution point(s).
The Ports tab will allow us to configure (on the server end) the ports to use when connecting to clients.
The Advanced Tab has a number of functions. Normally, we will publish data into Active Directory in the System Management container so that clients can find our management point. If we are only managing cross forest or workgroup resources with this CM site then we must rely on WINS for this data. It would not make sense to publish this data in Active Directory because our clients could not reference it. We can disable this publication. Note that you must manually delete this data.
Site Connection gives us two controls. We can prevent unsigned data from SMS 2.0 SP4 and older child sites from communicating with our site if they do not sign data. We can also require SMS 2003 child sites to participate in a key exchange for all communications. Inventory Protection will allow us to force SMS 2003 SP1 advanced clients to sign and/or encrypt data before they send it to the management point. Site System Role Deployment We will now deploy and configure the site roles or components and start their configuration. Navigate to Site Settings Site System Roles - \\<Server Name.
We can see the components that are deployed. Of these, we need to configure the distribution point. Double-click on it so we can set its properties.
Our distribution point has automatically been deployed. Ensure you have installed IS and BITS 2.0 on your server. Once you have, you should enable BITS via the Enable Background Intelligent Service (BITS) tick box. The ability to service clients that are on the Internet is not enabled in the Beta 1 Refresh build. It is something that Microsoft has been running a survey on with beta testers. When you are deploying packages to distribution points, it can be painful when you have many of them and they all need to be selected. You can minimise mouse fatigue by adding your distribution points to groups. We will add this distribution point to a new group called All Distribution Points. Click on the <*> button at the bottom.
Enter the name of the group in the new dialog and click on <OK>.
Click on <OK> and your distribution point is ready to use. You should give it a few minutes and then check the status of the CM components to ensure that everything is working OK. We can now deploy additional components in our site. We will be deploying: A management point. A server locator point. A reporting point.
Still in Site System Roles - \\<Server Name>, click on <New Roles> in the Actions pane.
This launches the New Site Role Wizard. Theres a lot of things in here to digest. To start with we need to enter the fully qualified name of the server that will host the CM site components. Remember that to scale the site, we can host these roles on many servers and even cluster some of them using Network Load Balancing. I have entered the FDQN of my site server because I only want one server to host all of the roles.
We need to decide what credentials to use to install the roles. Because Im one server, the roles will be installed locally so I can use local system. If I decided to place the roles on other servers then I would need to enter administrative credentials for those servers. The distribution point and state migration points can be protected using boundaries (IP subnets). We can enable this protection here and define those boundaries. This will prevent clients that are not in the defined subnets from being able to connect to either of those types of role that we are creating. This should not be thought of as a security boundary.
The next tab allows me to select the types of roles that I am deploying. I have ticked the 3 roles that I want.
This screen configures the management point. The tick box allows us to enable the management point to manage devices. I dont have any so thats why the box is clear. I can always change this later in the management point properties. You should tick this if you do want to manage devices. We can choose to use the site database for the management point database requirements. Alternatively, we can use another database. You will need to enter credentials for this. You would consider this in huge site deployments or for really high security where CM roles cannot completely trust each other. Ive never heard of this being done.
The server locator point can also either use the site database or a dedicated database.
The reporting point is configured in this dialog. The reporting point is a website for accessing our CM 2007 reports. I recommend that you retain the default URL. I dont have any certificates installed so I cannot utilise SSL but I recommend that you do.
Theres a lot to read in this dialog that pops up now. Its got two things to say. First, its telling you to monitor the status of the site to see if the management point installs correctly or not. Secondly, it is telling us that no default management point has been selected. We have the opportunity to select the new point as a default one. We will click on <Yes>.
We get a summary screen.
This screen would lead you to believe that the installation has been completed. In fact, it all happens behind the scenes and you must monitor the progress via the site status.
This is the site status after a successful installation of my 3 new site components. You are now wondering how we can add additional roles of the same type. We must first add an additional server under Site System Roles and then we can rerun the New Site Roles Wizard for that server.
Component Configuration We can now look at how to configure some of the site components. Well only change a few things here but we will also look at what else can be done. Navigate into Site Management - <Site Name> - Site Settings Component Configuration.
Double click on Management Point.
Here we can see we have three choices: No management point in the site. Set a default management point (which we did during the installation). Configure the IP address of the virtual server if we used Network Load Balancing to cluster two management points (requires two servers).
Return to the console and double-click on Software Distribution.
We need to enter the drive where we will locate the SMSPKG folder for our distribution point which will also be shared. I have only one drive, C:\. You can enter credentials for a Client Installation Account. These are used when you place non-default permissions on the distribution point so that neither the logged on user nor their computers account no longer has access to the distribution point share.
If you are using many distribution points then you will probably want to tune how they simultaneously download packages from the site server. This dialog allows you
to do this. The last tick box allows you to instruct distribution points in site hierarchies to download either from the closet site in the hierarchy above it, i.e. try the parent, then the grandparent, etc, instead of just downloading from the originating site and causing a bottleneck.
If you are using branch distribution points then you need to know that: They download from ordinary distribution points. There are probably WAN throttling issues to deal with.
You can throttle the link (which employs BITS) to control download traffic across the WAN from distribution points to branch distribution points. I think the settings are pretty self explanatory. This will apply to all branch distribution points affected. Return to the console and double-click on Status Reporting.
You can control what information is reported in status reporting (in the console) or logged using this dialog. You may wish to log data to file if you wish to proactively save it elsewhere so you can access it in case it is purged from the site database. Data in the reports can be saved off. Return to the console and double-click on System Health Validator Point. I have to admit, this dialog is still new to me but I will come back to it later with another document.
The query interval controls how often we query the global catalog to download security health policy references (which would appear to contain information about
clients and software update requirements policies). Because we are querying the GC, we need to careful about how often this is done in large environments. The Statement of Health validation can be age or timestamp limited, i.e. a SoH must be no older than x hours or must have been created after a certain time. This is done to force clients to produce an up to date SoH or face being quarantined.
The Accounts tab allows us to control how NAP behaves in multiple forest deployments. If you have only a single forest then leave this dialog with the default settings as seen above. If your site is managing NAP for clients in another forest then you will need to: Deploy a System Management container in the root domain of that forest. Deploy a health validator point in that forest on a Windows Longhorn server that runs the Network Protection Service. Supply credentials in the above dialog with sufficient rights to both query SoH data and to publish NAP policy references. This will probably not be necessary if the SoH computer has permission to write to the required locations in Active Directory.
Targeting Clients
User and System Discovery In order to deploy a client to managed computers or users or to perform any management tasks with them, we need to discover them and add them into the management scope of CM 2007. This is done under Site Settings Discovery Methods.
We can see a number of discovery methods: Heartbeat Discovery: It is used to refresh CM client computer discovery data in the site database. It is enabled by default and normally should remain so. Active Directory System Group Discovery: Polls the nearest domain controller to discover computer system groups. Active Directory Security Group Discovery: Polls the nearest domain controller to discover security groups. Active Directory System Discovery: Discovers computers by polling a domain controller. Active Directory User Discovery: Discovers users by polling a domain controller. Network Discovery: Can be used to discover network topology, potential clients and operating systems.
The discovery methods you enable are generally up to you. I will leave heartbeat discovery enabled (as default) and also enable: Active Directory System Group Discovery Active Directory Security Group Discovery Active Directory System Discovery: So I can deploy to computers. Active Directory User Discovery: So I can deploy to users.
First, we will look at the heartbeat discovery. Double click on it.
We can see it is enabled and also runs every week. Pay attention to the note at the bottom. We will now enable the other 4 discovery methods. Double-click on the Active Directory System Discovery method.
Click on Enable. Click on the <*> button.
You have a choice here. Do you want to discover system groups in: The domain that the CM 2007 server is in? The forest that the CM 2007 server is in? Use a custom query to only search for system groups in a particular OU?
I have chosen to search the domain.
As youve probably guessed, this appears to be a small bug. Ive selected to search a domain but Im able to navigate the OUs. If you want to search the domain then make sure you select the domain. Selecting an OU here will only search that OU!
The LDAP path should appear. You can add multiple paths in here, e.g. if you need to search only OUs and have multiple OUs to search.
Click on the Polling Schedule tab. Here we will define how often we will poll a Dc to run our discovery. Click on <Schedule>.
Enter your schedule. Youve got some decision making to do here. If you have a huge Active Directory then doing this very often will impact performance. You may choose to then run the discovery very infrequently. This will mean that newly added objects (in Active Directory) will not be discovered for quite some time. You have got to strike a balance where you discover objects as often as you need to and do it infrequently enough so as not to harm performance. Ive used 1 hour as my frequency in the past with 1000 node networks. Ill use it in this example. I generally set this to 10 minutes or maybe even less for a lab environment where I need things to happen pretty quickly.
When we return to the dialog, enable Run discovery as soon as possible. This will kick off this discovery method as soon as we click on <OK> or <Apply>. This box will be cleared when you return to this dialog later on. You can force a discovery with this tick box whenever you need one.
We now want to ensure that a discovery has taken place. If you have a small environment then you can do this immediately. If you have a large one then you may want to wait a while. Navigate into Computer Management Collections.
You may notice that the only system in the collection membership at the moment is your CM 2007 server. Collections build their membership by running a query according to a schedule. Your newly discovered systems will not appear if the query has not had a chance to run yet. Well look at the scheduling later. For now, well force the query to run. Right-click on the All Systems collection and choose Update Collection Membership.
This dialog pops up. Click on the tick box and then click on <OK>.
We can now see that the collection has been populated. All four computer accounts from my test lab domain have appeared. Note that DUBXP1 and DUBXP2 were actually powered off at this time. We discovered them based on their presence in Active Directory. This means we will be able to take control of them when they do power up. Collections Im not going into any detail here. Im saving that for a document on software deployment using CM 2007 (probably the next document I write). However, you can open the properties of a collection to modify how often its query is executed. This will minimise the amount of times you need to manually force a refresh during normal operations to get software deployment to hurry up.
Clients and Agents

Configuring the Agents
We need to get some terminology clear. The client is the piece of CM software that is installed on a managed computer. An agent is a piece of functionality that allows us to use the client to perform tasks on a managed computer.
You should have a clear plan of what agents you need to deploy before you even install any CM 2007 functionality. Some of them will be critical to you and some of them will be of no use to you. Navigate into Site Management - <Site Name> - Site Settings Client Agents.
We can see all of the available agents that we can enable on our clients. We will look at each one in turn and enable some of them for basic CM 2007 functionality. Double-click on Advertised Programs Client Agent.
This agent is responsible for installing software onto clients, i.e. our advertisements (which you remember, link collections with package programs and a schedule). I have enabled this agent by ticking the box at the top. I have also disabled clients from being reconfigured using the client interface. All configurations will be done by the CM administrator console. Clients poll the management point to find out if there are new advertisements to download. The default polling interval is 60 minutes. You will want to reduce this in a lab or else you will have to force a poll on the client itself. In huge environments you will either need more management points or reduce this setting. Notice that legacy clients are still mentioned here? I suspect that will be gone seeing as there is no support for legacy clients in CM 2007.
In the Notification tab we can provide a user interface for advertisement execution on the client. I have enabled a tick box to display a notification to user for when an application is available. This is handy when you deploy an application, e.g. a compression program, which is not a mandatory install. You give users the right to install it via the CM client. Displaying the notification lets them know the application is available. It is also handy if a program will start to install at a certain time via a mandatory deployment. The user will be able to initiate the installation ahead of schedule if it suits them. I also have provided a visible countdown. The default is 5 minutes. This is a per site setting. Id love to have an option to set this per application but its not available. This gives a user a chance to finish up tasks before a mandatory installation begins. We can also play sounds if we choose I hate sounds in an office environment so I have not enabled that. Return to the console and double-click on the Device Client Agent.
The device client agent also polls the management point assuming it is device enabled. We can control that polling here.
In the Software Distribution tab we can see it was enabled by default. I disabled it because I have no device enabled management points nor devices to manage.
The Software Inventory tab allows us to collect an inventory of files based on filename and location from managed devices on a schedule of your choosing.
The hardware inventory does a hardware audit of managed devices according to a schedule of your choosing.
File collection if enabled will actually gather files that meet naming and location criteria of youre choosing according to a schedule that you set. Ive disabled all device agent functionality in my site. Return back to the console and double-click on Hardware Inventory Client Agent.
I always felt this agent was poorly named. Yes, it does gather hardware data of managed clients (servers, desktops, laptops) but it also returns the entries found in Add/Remove Programs. I always enable this agent because it is vital for building
collections for software distribution and for reporting, i.e. only install Office 2007 on PCs with sufficient hardware resources, only install the OpenXML Translator on PCs with Word XP, 2003 or 2007, report on all machines not able to run Vista with decent performance, etc. We can only gather this data with a hardware inventory. This data tends not to change very often so an infrequent schedule is suitable.
Ill be honest here. I havent used this dialog, ever. By using the Collect IDMIF files entry we can add new architectures that we should collect data on. By using the Collect NOIDMIF files entry we can add additional attributes and classes to existing architectures on a client. Return to the console and double-click on Network Access Protection Client Agent.
This agent is responsible for evaluating software update management compliance on the client. We can enable this agent in this tab.
In the Evaluation tab we can control when evaluation is done.
I didnt install Remote Tools functionality so I cannot enable this agent. I couldnt care less. All I can see that it does for an advanced client is add an alternative way to launch the RDP and Remote Assist clients and give the marketing people an opportunity to cut down more rain forest. Return to the client and double-click on Software Inventory Client Agent.
This agent is pretty crude. I dont use it and I dont recommend that you do either. In fact, software inventory will be changing drastically before this product is released to manufacturing, possibly in the next pre-RTM release. Microsoft acquired a company called Assetmetrix in 2006. This company specialised in inventorying solutions. Their software auditing solution is being integrated into SMS 2003 SP3 and CM 2007. As such, Im going to say nothing else about this agent. Return to the console and double-click on Software Metering Client Agent.
The Software Metering agent allows us to measure when specified executables were last used by a user on a machine. This is very handy for identifying expensive but unused applications that can be uninstalled from PCs so that the licenses can be reused elsewhere. Weve all had the user who demanded to have Visio o Adobe Acrobat installed so that they can draw one diagram. We can allow them to use it and then return the license to a pool so that it is not lost to that PC and never used again. I would recommend that you use this agent if you do have applications and deployments as described above.
The Schedule tab defines when data is collected on the client and when the client should download new metering rules from the management point. Return to the console and double-click on the Software Updates Client Agent
This is a new agent. Before, all software updates (inventory tools) used the advertised software agent to be deployed. This new agent allows better control and a smoother user experience. It is enabled by default. You should disable it if you dont intend to use it.
This tab controls what I think is my favourite new feature in CM 2007. The first part allows you to title any update notifications associate with your software updates. This lets your users know what is coming and who it is coming from. The second part is really nice. When you set up a software update deployment you will define a mandatory installation deadline. Up to that point, there will be a series of notifications or reminders to give server administrators or desktop users a
chance to install updates before the mandatory deadline. You can control the frequency of those reminders.
Another nice feature allows you to rescan the update status of a client. This caters for a scenario where an update is installed and someone uninstalls it for whatever reason. The settings here determine how often a client will rescan for updates that will need to be reinstalled. You will likely want a more frequent scan if security updates are important to you.
Deploying Clients
There are a few ways to deploy the CM client onto machines that you want to manage: Manual Installation: Slow and expensive. Scripted installation: Prone to faults. Pushed deployment: Clean and simple. Not possible with workgroup machines.
It should be clear what my preference is. CM 2007, just like SMS 2003, allows you to cleanly push out the client to all forest members.
Manual Installation You can install the client by running \\<Site Server Name>\SMSClient\i386\CAPINST.EXE. You can also find this installer in C:\SMS\Client\i386. There are a number of flags you can use to control the installation: /SLP=: Provide a server locator computer name. Microsoft recommends using this flag. You must use it if you have not extended the schema because the client will fail to find the server locator point. /SLPPORT=: Provide a port for server locator point communications. The default is 80. /MPPORT=: Provide a port for management point communications. The default is 80. /DC: Install the client even if the computer is a domain controller.
An example of its usage is: CAPINST.EXE /SLP=<server locator computer name> /SLPPORT=8080 /MPPORT=8080 /DC Existing SMS administrators should note that the following flags are no longer valid: /AdvCliCmd: This flag is no longer valid and is ignored. All clients are advanced in CM 2007. /AutoDetect=: This flag is no longer valid.
Script Installation You could use a logon script to install the client if your users have local administrator privileges. Alternatively, you could use a startup script to install the client. Make sure you implement some sort of control to prevent repeat installations. It also makes sense to replicate the client installation to all sites. Consider using something like Windows 2000/2003 DFS/FRS or Windows 2003 R2/Longhorn DFS Namespace/DFS Replication to make the installer available in all sites using one abstracted namespace. You will use the same command and flags to install and control the installation of the client.
Push Installation This is my preferred client deployment method and I am probably safe is presuming the same is true for almost everyone else who is familiar with client installation. A push installation will require administrative privileges on each computer that is to be managed in order to install the client. If you do not supply an administrative account for this then CM 2007 will try to use the site servers computer account to install the client. Therefore, the best solution is to supply an account or set of accounts that has the required rights on the targeted computers. Do not be lazy and use a domain administrator account for client push installation. This is highly discouraged by Microsoft and me. I have created user account called CM. It will be a service account. The account has been given local administrator rights on all of my computers in the domain by using the restricted groups feature in group policy. I could repeat this for child domains by creating users in each domain and populating the local administrator groups of computers in those domains with the same method. We now must configure the push policy. Navigate into Site Management - <Site Name> - Site Settings Client Installation Methods.
Double-click on Client Push Installation.
This dialog is where we enable client push installation and where we can define the types of machines that can be managed. I ticked the Enable Client Push Install to assigned resources box. The below dialog pops up.
It is warning us that for client push installation to work, we must both enable it in this dialog and to ensure that discovery methods are enabled. Click on <OK>.
I want to install the client on all computers: Servers: Any system running Windows Server. Workstations: Any system running a Windows desktop OS. Domain controllers Site systems: this refers to any computer hosting a CM 2007 server component.
The Microsoft documentation warns us that to install a client on domain controllers then we must select both Domain Controllers and Enable Client Push Installation to site systems.
The Accounts tab allows us to provide credentials with administrative privileges on the machines we want to perform a client push install on. With CM 2007, this is not obligatory, as long as the site server has administrative rights on those computers. The best solution as I mentioned before, is to create an ordinary user and grant it the required rights. Click on the <*> button to add each required administrative account. Again, dont use a domain administrator account!
Ive entered my user account (<domain>\<username>) and its password.
Repeat that process for each required user account.
The Client tab allows us to customise the install with installation properties. Theres no documentation available right now but I would presume it hasnt changed much since SMS 2003. You could do things like configure logging level, where to place the client cache, what size to make the cache, etc. Have a look in Appendix I of the SMS 2003 online library for available installation properties.
Set up everything you need and ensure your discovery methods are working. Now, sit back and wait. Your clients should start installing during discovery cycles. You can speed things along. Navigate into a collection that contains the computers that you want to force an agent onto.
Right-click on the computer account and select Install Client.
Click on <Next>.
Choose Install the SMS client and use the default client type. Its likely this box will change completely seeing as there is no support for legacy clients.
I know my targeted machine is just a workstation with no existing client. I have nothing selected here. However, if a client was already installed and faulty, I could force a reinstall (or repair).
Click on <Finish> if you are happy with the summary screen. The agent should install if everything is OK. Ive allowed my agents to install. This can take a while. When you start working with SMS 2003 or CM 2007, youve got to learn patience. Nothing happened straight away. It can be very frustrating at first but you do learn to accept it because it is part of the flexibility and scalability of the product. The single most common problem Ive encountered was in a lab environment. I would set up my policy to configure the local administrators group membership and then rush into client deployment, not letting the policy apply or forgetting to force it. Ive navigated into the All Systems collection to monitor client deployment.
We can see above that all of my computers have received a client by push deployment and they have automatically picked up their site membership as indicated by the site code.
Ive opened control panel on a sample client. We can see four new applets: Program Download Monitor: It does exactly what it says on the tin. It allows us to monitor the download of packages for installation. Remote Control: This is disabled because Ive not installed or deployed Remote Tools on the site. It allows us to monitor and configure remote control.
Run Advertisements: We can force a waiting or non mandatory advertisement to run if it has downloaded. Systems Management: This is the one you will use the most. Well have a better look at it now.
Ive opened the Systems Management Applet.
We can see some configuration and diagnostics information in the General tab.
The components tab lists the installed, enabled and disabled components. We can click on <Repair> to repair the components.
The Actions tab shows the actions that run on a scheduled basis. The one you will use the most is Machine Policy Retrieval and Evaluation Cycle. This forces the client to connect to the management point to download new policies or advertisements. You will initiate this if you wish to hurry up an advertisement execution when testing software deployment in a lab scenario.
The Advanced tab allows is to discover the site the client is a member of and allows us to manage the cache. We can change the size of the cache, change its location and delete its current contents.
Summary
Microsoft System Centre Configuration Manager 2007 looks like a very nice upgrade to SMS 2003. The core functionality has changed very little so that those who have been using SMS 2003 will be able to jump right into CM 2007. However, there are some interesting new architectural features, new and improved functionality that will justify an upgrade of your SMS hierarchy. Hopefully, Ive been able to explain the new features of CM 2007, the basics of CM 2007 architecture and been able to demonstrate how to install a working CM 2007 site. Future documents on CM 2007 will delve into greater detail on different functions of CM 2007 such as: Software deployment. Branch distribution points. Software update management. OS deployment. Network Access Protection once Ive learned a little about Windows Server Longhorn.
More information on and best practices for CM 2007 will emerge as the beta and release candidates emerge. Ill try to keep up with them as time goes by.

Installing CM202007

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Installing CM202007

Uploaded by

Copyright:

Available Formats

Aidan Finn 14/02/2007

Installing Configuration Manager 2007

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

New Features of CM 2007

Network Access Protection

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Operating System Deployment

The Administrator Console

Software Update Management

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Branch Distribution Points

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Advertisements Not Replicated To Secondary Sites

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Configuration Manager 2007 Architecture

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Locating the Site Components

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Site Component Requirements

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

About This Installation

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Choose container as the type of object as youd like to create.

With this dialog, we only want to click on <Finish>.

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Click on the Security tab and then click on <Advanced>.

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

We can now see the group will have full control.

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing the Site Server

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

A Quick Look Around

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/

Installing Configuration Manager 2007 Copyright Aidan Finn 2007 http://joeelway.spaces.live.com/