This one will be short. Management Points have their own set of log files in addition to the log files that are included on all site systems. So when you look in the Logs directory on a Management Point, you can expect to see these log files:

MP_Ddr.log – As XML.ddr records that have been delivered from client systems are converted and sent to the site server, this log records the activities and results of the conversion.

MP_GetAuth.log – This log records the status of the Management Point.

MP_GetPolicy.log – As policies are created, the information about the policies is recorded in this log.

MP_Hinv.log – As hardware inventory is delivered from clients, the information about the conversion and the delivery of the converted information to the site server is recorded in this log.

MP_Location.log – As the Location Manager performs tasks, the results of those task activities is recorded in this log.

MP_Policy.log – Policy communication is recorded in this log.

MP_Relay.log – This log records the status of collected file copy tasks from the client to the Management Point

MP_Retry.log – Whenever a hardware inventory cycle is in a retry state, the status is recorded in this log.

MP_Sinv.log – As software inventory is delivered from clients, the information about the conversion and the delivery of the converted information to the site server is recorded in this log.

MP_Status.log – As clients send status messages to the management point, the results of the conversion of these files and the copy tasks as the converted files are sent to the site server are recorded in this log.

In part three of my log listings, I am going to detail the log files that can be found on the client machines. These log files are buried a little deeper in the file system than the log files that are located on the site systems. When looking for these log files, open the directory where you installed the operating system. If the operating system is located on the C: drive and the directory is Windows, then expand C:\Windows\System32\CCM\Logs. If you are running a 64-bit operating system, you will need to open the SysWOW64 directory instead of the System32 directory.

Once you have the Logs directory open, you should find the following log files:

CAS.log – This log is used to record information from the Content Access Service. As local packages are created and managed, the results of those actions are recorded here.

CcmExec.log – This log is used to record any processing activities related to the SMS Agent Host service on the client.

CertificateMaintenance.log – As certificates are managed on the client, all of the activities surrounding the certificates are recorded in this log.

ClientIDManagerStartup.log – When the GUID is created or manipulated on the client, the actions, and results of those actions, are recorded in this log.

ClientLocation.log – This log is used to record activities concerting the client’s site assignment.

ContentTransferManager.log – As a scheduler requests a package to be retrieved from a distribution point or shared location, this log records the results of the download request.

DataTransferService.log – Whenever the Background Intelligent Transfer Service is used to download policy or packages, this log is used to record the results.

Execmgr.log – This log records information about advertisements as they are processed by the client.

FileBITS.log – When SMB is used to access a package, the information about the access is recorded in this log.

Fsinvprovider.log – Whenever the software inventory is collected by the Inventory Client Agent, this log is used to record the results of the software inventory and file collection processes.

InventoryAgent.log – When DDRs are created and hardware and software inventory are processed, the results of the processing are recorded in this log.

LocationServices.log – As a client searches for and discovers Management Points and Distribution Points, the results of the search activities are recorded in this log.

Mifprovider.log – When MIF files are used with hardware inventory, this log is used to record the actions that are taken against the MIF files.

Mtrmgr.log – As software metering is performed, this log is used to record all software metering activity.

PolicyAgent.log – When the Policy Agent requests policies, the results of the actions of the Policy Agent and the data returned by the Data Transfer service are recorded in this log.

PolicyAgentProvider.log – All policy changes are recorded in this log.

RemoteControl.log – When the remote control component is initiated, the start and stop times are recorded in this log.

Scheduler.log – Whenever a client task is scheduled, this log records the actions performed and the details of the actions.

Smscliui.log – Each time the Configuration Management control panel utility is accessed, the access is recorded in this log.

StatusAgent.log – All status messages that are created by the client components are recorded in this log.

SWMTRReportGen.log – All usage data from the software metering agent is recorded in this log.

In this second installment, I am going to take a look at the log files for Operating System Deployment. If you are thinking about using OSD for deployment of your computer images, these log files can go a long way to helping you figure out where you may be having problems.

CCMSetup.log – As actions are performed on client operating systems, the results of those actions are recorded in this log.

CreateTSMedia.log – When task sequence media is created from the Administration Console, information about the media, and the results of the ISO file creation, are recorded in this log.

DriverCatalog.log – When device drivers are imported into the driver catalog, the results of the import are recorded in this log.

MP_ClientIDManager.log – Found on the Management Point, this log is used to record Management Point responses when boot media or PXE devices request Client ID information.

MP_DriverManager.log – When an Auto Apply Driver task sequence is initiated, the response from the Management Point is entered in this log. Found on the Management Point.

MP_Location.log – This log, found on the Management Point, is used to record responses from a Management Point when a Request State Store or Release State Store request is made for the State Migration Point.

Pxecontrol.log – PXE Control Manager information is recorded in this log.

PXEMsi.log – When the PXE Service Point is created, this log records the installation.

PXESetup.log – When the PXE Service Point is created, this log records the installation.

Setupact.log – This log is used to record Sysprep and Setup activity information.

Setupapi.log – This log is used to record actions performed by the Sysprep and setup APIs.

Setuperr.log – This log is used to record errors that occur during Sysprep and Setup.

SmpIsapi.log – Records the responses from the State Migration Point when clients requests are initiated.

Smpmgr.log – As State Migration Point health checks are requested, and changes are made to the State Migration Point, the results are recorded in this log.

SmpMSI.log – Records the installation information for the State Migration Point.

Smsprov.log – Records activity concerning the SMS Provider.

Smspxe.log – Records activity performed by the PXE Service Point.

SMSMPSetup.log – Installation information about the State Migration Point is included in this log.

Smsts.log – This log is the default log for OSD and Task Sequence activity.

TaskSequenceProvider.log – This log records creation, import, export and modification to Tasks Sequences.

USMT Log loadstate.log – Records activity pertaining to User State Migration Tool when restoring user state data.

USMT Log scanstate.log – Records activity pertaining to User State Migration Tool when capturing user state data.

Are you ready for a boring topic? I know, great way to start a blog entry. Not many going to read this one…

As you have probably already discovered, there are a LOT of log files that make up the Configuration Manager Log directories. The Configuration Manager site server and site systems have quite a few, and the clients have several also. So what are all of them for? How do you know which log files to look at? This blog entry is the first of several that will cover the log files and their use. We’re going to start with the log files that reside on the Site Server itself. You will find them in the installation directory within the LOGS directory.

Ccm.log – Client Configuration Manager tasks are reported here. As you deploy clients to systems, the configuration information and installation results appear here.

Cidm.log – As changes to clients are made by the Client Install Data Manager, they are recorded here.

Colleval.log – As collections are created, manipulated or changed, the actions and results of the actions are recorded in this log.

Compsumm.log – As data is summarized by the Component Status Summarizer, the tasks that are performed, and the results of those tasks are recorded in this log.

Csnfsvc.log – Whenever the Courier Sender is used to transport information between systems, the tasks and results are recorded in this log.

Dataldr.log – As Hardware Inventory and Management Information Format (MIF) files are processed, the processing information and results are recorded in this log.

Ddm.log – Discovery Data Manager processing and results are recorded in this log as DDR records are created and entered into the database.

Despool.log – As data is delivered to a site, the Despooler processes the data and records all of the actions in this log.

Distmgr.log – As packages are transferred to the Distribution Points, all package creation, compression, replication and updates are recorded in this log.

Hman.log – As configuration changes are made within the site and information is delivered to Active Directory, this log is used to reflect those changes.

Inboxast.log – As files are moved from the Management Point to the associated SMS\Inbox folder, this log records the move.

Inboxmgr.log – As files are processed within the inboxes, this log records the results of the processing.

Invproc.log – As client inventory MIF files are processed by the Dataloader component, this log records the results.

Mpcontrol.log – Records Management Point registrations with WINS. Also reports on the availability of the Management Point every 10 minutes.

Mpfdm.log– Records the movement of files from the Management Point to the corresponding SMS\Inboxes folder.

MPMSI.log – Records the installation of the Management Point when the MP.msi installer file runs.

MPSetup.log – Records the results of MPSetup.msi.

Ntsvrdis.log – Records results from discovery processes.

Offermgr.log – As advertisements are created and updated, this log is used to record the actions.

Offersum.log – Records the results when advertisement status messages are summarized.

Policypv.log – As client policies and advertisements are modified, the updates are recorded in this log.

Replmgr.log – Records the details of replication between site server components and the Scheduler.

Rsetup.log – Records the results from the installation of Reporting Points.

Sched.log – Site-to-Site job and package replication results are recorded to this log.

Sender.log – Records the files that are replicated to parent and child sites.

Sinvproc.log – Records the results of software inventory processing.

Sitecomp.log – Maintenance performed on installed components are recorded in this log.

Sitectrl.log – Records any changes that are made to the Sitectrl.ct0 file.

Sitestat.log – Records all of the monitoring results when monitoring site systems.

Smsdbmon.log – Records any changes made to the Site Database component.

Smsprov.log – Records when the WMI provider accesses the site database.

SMSReportingInstall.log – Records what happens when the Reporting Point is installed.

Srvacct.log – When the site is in Standard Security mode, any maintenance that is performed on accounts is recorded in this log.

Statmgr.log – Records all status messages are written to the database.

Swmproc.log – Records results of software metering.

Wondering what it is going to take to make your Windows Server 2008 systems act as Distribution Points, Management Point or one of the other roles that requires IIS? It’s no secret that Windows Server 2008 has a different security model that what has been seen in the past. Not only is the system locked down tight from the start, there are several services that are not installed by default. To complicate things even more, IIS 7 does not boast the same feature sets that IIS 6 did. IIS 7 is stripped of some of the features that you need to run many of the Configuration Manager roles.

With that being said, you can still use Windows Server 2008 for the same roles that you currently run on Windows Server 2003. You will have to perform some additional work to get the roles up and running, but the steps are not that difficult. I am going to provide a checklist of the steps that you will have to perform. Hopefully this will become an easy way for you to get your Site System roles up and running.

Add the following features:

• BITS Server Extensions – Add all role services
• Remote Differential Compression
• Web Server (IIS)
  • Install ASP.NET -Add all role services
    
  • Windows Authentication
    
  • IIS 6 Metabase Compatibility
    
  • IIS 6 WMI Comptibility

Install WebDAV for IIS 7

In Server Manager, open Internet Information Services (IIS) Manager and configure the following:

• On the Default Web Site (or SMSWEB if you are using a custom web site), double-click WebDAV Authoring Rules
• On the Actions pane, click Enable WebDAV
• Add the following Authoring Rule:
  • Allow Access To: All Content
    
  • Allow Access To This Content To: All Users
    
  • Permissions: Read
    
• Configure the Following WebDAV Settings
  • Allow anonymous property queries: True
    
  • Allow Custom Properties: False
    
  • Allow Property queries with infinite depth: True
    
  • If BITS-enabled Distribution Point – Allow hidden files to be listed: True
    
  • Click Apply to enforce the settings

Modify the requestFiltering section of applicationHost.config file

• Open %windir%\System32\inetsrv\config\ applicationHost.config
• Find the <requestFiltering> section
• Review the file extension list and change only those file types that will be used in packages to “true”

For more information, and a detailed step-by-step to perform these actions, see this page.

When deploying operating systems, you may not always have the opportunity to pre-stage computer names based upon the MAC address or BIOS GUID. New in System Center Configuration Manager 2007 is a nice new feature called Unknown Computer Support. Essentially, you are allowing a computer that is foreign to your network and allowing it to be loaded with your corporate image. The typical precautions need to go out when you start thinking about providing this functionality. Computers that successfully PXE boot on your network could have an operating system loaded without your permission. Most companies that want to provide this type of functionality will have a network segment that is dedicated to building new systems, and that network segment is not available to users, only the technicians that are imaging new systems.

For information about the prerequisites and how to enable Unknown Computer Support, see this page.

For more information on how to deploy an operating system using Unknown Computer Support, see this page.

When a computer PXE boots and Unknown Computer Support is enabled, you could run the risk of destroying the information stored on an already imaged system. For this reason, the ‘imaging’ network should be isolated from the rest of the production network. If that is not possible for some reason, you can safeguard systems that should not be allowed to PXE boot by creating an exclusion list. This is a list of MAC addresses from machines that you do not want to accidentally reimage.

For more information on how to configure the exclusion list, see this page.

One of the cool features that you will find with System Center Operations Manager 2007 R2 is the ability to use multicasting with operating system deployment. Multicasting gives you the ability to send out the bits that make up the operating system one time while several systems receive the bits and load the operating system. Why is this so cool, you ask? Simply put, you can save a lot of valuable bandwidth by sending the image one time.

For example, let’s say the total size of the operating system that you are deploying is 500 MB. You need to deliver that operating system image to 10 computers. In the traditional operating system deployment scenario, you would send 10 unicast sessions, each consuming 500 MB, so essentially pushing out 5GB of data. Using multicast, you will typically only send the 500 MB of data one time. That is an impressive savings in network bandwidth.

There are some caveats though, you need to have the distribution point that is using multicast installed on a Windows Server 2008 system. There are also some configuration settings that need to be in place.

For information on the Configuration Manager and multicast requirements, see this page.

For information on the Distribution Point settings, see this page and this page.

For a description of the settings that can be configured for the Distribution Point, see this page.

In addition to operating systems, packages can be distributed in this manner also. A new checkbox appears on the package properties that allow the package to be deployed via multicast. There is a limitation to this however. Multicasting only works with the WinPE environment at this point. Traditional advertising of packages will not take advantage of multicasting, only task sequences used with OSD.