SCOM: Monitoring Windows Event Logs Using SCOM

Problem



Step: 1 Create a Monitor
Open “Authoring” Pane, select “Monitors”


Right click on “Monitors”, choose “Create a Monitor” and choose “Unit Monitor”

Expand “Windows Events” then expand “Simple event detection” and choose “Manual Reset” then choose you management pack where you are planning to save this “Monitor”

Type “Name” for this Monitor i am using “failure of Differential backup” and write a brief “Description” and in “Monitoring Target” i am choosing “Windows Server Operating System” because in my environment “Symantec backup exec” in installed on windows 2003 and 2008 servers, not click Next

choose the “Log Name” where your application write “event logs” in my case “Symantec Backup Exec” writes event in “Application Log” that’s why i choose “Application” now click on Next

Now we need to provide the Event ID and Event Source in Expression Builder so that is any event log matched this criteria created SCOM can alert us. In My case “Event ID is 34113” and Event Source is “Backup Exec” , now click on NEXT

Now we need to “Configure Health Conditions” so If “Event is Raised” then the status is “Warning” otherwise it is “Healthy” now click on “Next”

We need an alert when is Event is Created , so click on “Generate Alerts for this Monitor” and click on “Create”


Step: 2 Create a subscription
I am creating a New Subscription for it so that whenever this Event ID creates or Backup Job Fails then it should send an alert "our “Backup Administrators”
Click on “Administration” and Select “Subscriptions”

Right click on “Subscriptions” and choose “New Subscriptions”

Now Type “Subscription Name” and Description and click Next

In “Subscription Criteria” click on “Created by Specific rules or Monitors” and choose our previously created “Monitor” “Failure of Differential backup” and click on Next

Add users which intended to receive the alerts, after adding users click on NEXT
 
Choose Channels by which you are going to send an alerts, in my case I am sending alerts using an email. click NEXT

Click on “Enable this notifications subscription” and click on Finish.


Step: 3 Testing
Now its time to test the monitor, I used Logevent.exe to create an demo alert in window Application Log. See this link to know more about Logevent utility.


Step: 4 Result
Bingo !!! It shows warning in SCOM Alert window.

and it also send me an email about this alert :-)

SCOM: "Failed Accessing Windows Event Log" Error

Hi All,

Few days back I imported the DHCP Management Pack for SCOM. After importing I start getting Failed "Accessing windows Event Log" errors on Alert View of SCOM.





I Google and search internet and found that this is a BUG in DHCP Management Pack. In Monitored computer it shows the event ID 25002 and 25004

Thanks to Kevins Post who guide us what to monitor and what not to monitor on DHCP Servers
: Kevin Holman


To stop these error you need to Disable this alert using overrides.

To Override:  Right Click the Monitor, click on Properties .
click on Overrides and select "For all objects of class: health Service"

Choose Destination Management Pack. and change the value from "True" to override value "False"

 

and click on APPLY


















Now you can see that it disabled the monitoring of the Windows Event Log.

I hope this Helps

SCOM: How to Backup System Center Operations Manager 2007 R2

HI All,
Yesterday I was working on “How to Backup System Center Operations Manager 2007 R2”. I go through different document and posts and read few documentations and I think I should also share this information with you.
Our first step is to plan what to backup. So here is the list

1. Note down SCOM servers IP Address, Subnet, Gateway
   
2. Note down the Location of System Center Operations Manager Installation Path
   
3. Backup SCOM Databases
   1. OperationsManager (Operational Database)
      
   2. OperationsManagerDW (Dataware house Database)
      
   3. OperationsManagerAC (Audit Collection Server Database)
      
   4. ReportServer (Reporting Server Database)
      
   5. ReportServerTempDB (Reporting Server Temporary Database)
      
   6. Master (SQL Server Master Database)
      
   7. MsDbData (Msdb database)
4. IIS 6.0 Metabase or IIS 7.0 configuration
   
5. Root Management Server Encryption Key
   
6. Create List of All Management Pack Installed
   
7. Backup of Unsealed (customised) Management packs
   
8. SCOM Registry Keys
   
9. Backup your files

Let’s Start

1. I have noted down the IP-Address of SCOM including Subnet mask, Gateway IP and DNS Entries.
   
2. I noted down the location where is my SCOM in Installed, in my case it is installed on “C:\Program Files\System Center Operations Manager 2007”
   
3. Backup Databases

Operations Manager Operational Database (OperationsManager) 
The OperationsManager database contains almost all of the Operations Manager environment configuration settings, agent information, management packs with customizations, operations data, and other data required for Operations Manager to operate properly.
Note:     If your backup procedure sets the OperationsManager database to be offline during backup, Operations Manager caches incoming data, and then, after backup is complete, Operations Manager stores that data in the database.
Open “Microsoft SQL Server Management Studio” , Expend the “Database” , Right click on “OperationsManager”, choose “Tasks” and click on “Backup”

For now, I am choosing “Backup type = Full” and Name of the Backup and Backup Destinations, (for now I am backing up the data in to my network folder (Click on “ADD” to define the location of where you want to keep your backup”) and click on “OK”

After “Backup” process finish , you can see the data on your backup destination folder.


Do the same for all SCOM Databases ( OperationsManagerDW, OperationsManagerAC,ReportServer,ReportServerTempDB,Master,MsDbData)

• Reporting Databases (just a brief intro)

Operations Manager Reporting uses the following databases:
· Operations Manager 2007 data warehouse (OperationsManagerDW)
· SQL Server Reporting Services databases (ReportServer and ReportServerTempDB)
The OperationsManagerDW database contains all of the performance and other operational data from your Operations Manager environment. SQL Reporting Services then uses this data to generate reports such as trend analysis and performance tracking.

• ACS Database (just a brief intro)

The Audit Collection Services (ACS) database, OperationsManagerAC, is the central repository for events and security logs that are collected by ACS forwarders on monitored computers.
The OperationsManagerAC database can grow significantly depending upon how many ACS forwarders send events to the ACS database and the filters configured to control what events are written to the database.

• Master Database (just a brief intro)

The master database is a system database, which records all of the system-level information for a Microsoft SQL Server system, including the location of the database files. It also records all logon accounts and system configuration settings. The proper functionality of the master database is key to the operation of all of the databases in a SQL Server instance.

• MSDB Database (just a brief intro)

The MSDB database, Msdbdata, is a SQL system database, which is used by the SQL Server agent to schedule jobs and alerts and for recording operators. The proper functionality of the MSDB database is key to the operation of all the databases in a SQL Server instance.

Backup IIS Metabase
My SCOM installed on “Windows 2003 server”  so I am using IIS 6.0. To backup IIS 6.0 metabase, Go to RUN (windows key + R) and type “%systemroot%\system32\inetsrv\iis.msc” and hit OK

Right click on your “Computer Name” and then click on “All tasks” and choose “Backup/Restore configuration”

Click on “Create Backup” and then type the “Configurations backup Name” and then hit on “OK”

By Default all Metadata are stored in “%systemroot%\system32\inetsrv\MetaBack”


Backup Root Management Server Encryption Key
To restore SCOM from scratch we need “RMS Encryption Key”. You must backup “RMS Encryption Key” and store it on secure locations.
To backup an Encryption Key go to “C:\Program Files\System Center Operations Manager 2007” double click SecureStorageBackup.exe

When you double click “SecureStorageBackup.exe”, an “Encryption Key Backup and restore wizard” Open, click on NEXT

in “Select Action” choose to “Backup Encryption Key” and click on “NEXT”

Now “Specify the location of Backup File” where you want to save your encryption key, name it and click Next

Specify the password to protect the key and SCOM will ask for this password when we restore it after restorations after failure.

Click on “Finish”


Create List of All Management Pack Installed
It is handy to keep the latest list of all “Management Pack” installed in SCOM. The list will helps us to download or restore them. To create an List of All Management Packs, open “Operations Manager Shell” and type :
“Get-ManagementPack | Export-csv c:\ManagementPackList-May-2011.csv”


this will export all management packs in to .CSV file which we can import to excel and see the list of sealed and unsealed Management Packs
for example : Import the CSV file in to Microsoft Excel and create a filter on Data and the you are view list of All management packs by “sealed” or “Unsealed”


Backup of Unsealed (customised) Management packs
Open “System Center Operations Manager Console” click on “Monitoring” , click on “Management Packs” and sort the Management Packs by “Sealed” or “Unsealed”, choose the “Management pack” which you want to export, then right click it and choose “Export management pack”

choose the location where you want to save “Management Pack” and click on “Ok”

Exported “Successfully” , do the same for every unsealed Management Pack


Backup SCOM Registry Keys
I read on some posts that we need to backup SCOM registry Keys and it seems a good backup practice. so open “Registry editor" navigate to “My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\” and export the whole key.

Right Click on “Microsoft Operations manager” ,Click on “Export”

Choose the location where to save registry keys, and choose the file name make sure you have selected (Selected branch), and click on “Save”


Backup your files
The last thing to backup is your installation folder. :-).

As per Microsoft documentations when you restoring your folder make sure you don’t restore the “Heath service State” folder.

That’s all :-)
Hope it helps someone

Inbox Folders in Configuration Manager 2007

Inbox Folders

\Auth

This folder and its subfolders are used by Configuration Manager 2007 sites, management points, and clients. Configuration Manager 2007 uses these folders to temporarily store hardware, software, and discovery data records (.ddr files).

\Auth\dataldr.box

This folder stores .mif files that represent hardware inventory data for Configuration Manager 2007 client computers. This folder also stores IDMIF files for custom architectures. A backlog of files can indicate problems accessing the site database. Examine the status messages for the Inventory Data Loader for possible problems. You can also examine the Dataldr.log file for errors or additional information.

 

\Auth\dataldr.box\process

This folder stores .mif files that are in process. A backlog of files can indicate problems accessing the site database. Examine the status messages for the Inventory Data Loader for possible problems. You can also examine the Dataldr.log file for errors or additional information.

\Auth\ddm.box

This folder temporarily stores .ddr files after a client or server agent generates a discovery record. Examine the status messages for the Discovery Data Manager (DDM) for possible problems. You can also examine the Ddm.log file for errors or additional information.

\Auth\ddm.box\BAD_DDRS

This folder stores .ddr files that are corrupted. A backlog of files can indicate a network corruption problem or a problem with the DDM. Configuration Manager 2007 automatically deletes .ddr files that are older than 25 hours. Examine the status messages for the Discover Data Manager component for possible problems. You can also examine the Ddm.log file for errors or additional information.

\Auth\sinv.box

This folder stores client software inventory files (.sic and .sid files) that are copied from the management point. A backlog of files can indicate that the Software Inventory Processor cannot connect to the site database or that too many files were received. Examine the status messages for the Software Inventory Processor for possible problems. You can also examine the Sinvproc.log file for errors or additional information.

\Auth\sinv.box\Orphans

This folder stores hardware and software inventory that cannot be processed. Inventory files that are moved to this folder are retried later. A backlog of files can indicate problems with specific clients, with management points, or with the network that could cause data corruption. Examine status messages for the Software Inventory Processor for possible problems. You can also examine the Sinvproc.log file for errors or additional information.

\Auth\statesys.box

This folder stores information related to state messages. For more information about state message backlogs, see Troubleshooting State Message Backlogs.

\Compsumm.box

This folder contains component status summary messages from child sites. A backlog of files can indicate that the Component Status Summarizer cannot process the volume of messages. Examine status messages for the Component Status Summarizer for possible problems. You can also examine the Compsumm.log file for errors or additional information.

\Dataldr.box

This folder stores .mif files that represent hardware inventory data for Configuration Manager 2007 client computers. This folder also stores IDMIF files for custom architectures. A backlog of files can indicate problems accessing the Systems Management Server (SMS) database. Examine status messages for the Inventory Data Loader for possible problems. You can also examine the Dataldr.log file for errors or additional information.

\Dataldr.box\Badmifs

This folder stores corrupted .mif files for hardware inventory or custom IDMIF files. A backlog of files can indicate a bad custom MIF file or that a client computer cannot transfer the file correctly. Configuration Manager 2007 automatically deletes all files in the \Badmifs folder that are older than 14 days. Examine status messages for the Inventory Data Loader for possible problems. You can also examine the Dataldr.log file for errors or additional information.

\Ddm.box

This folder temporarily stores discovery data records (.ddr files) after a client or server agent generates a discovery record. Examine status messages for the Discovery Data Manager (DDM) for possible problems. You can also examine the Ddm.log file for errors or additional information.

\Ddm.box\BAD_DDRS

This folder stores .ddr files that are corrupted. A backlog of files can indicate a network corruption problem or a problem with the DDM. Configuration Manager 2007 automatically deletes .ddr files that are older than 25 hours. Examine status messages for the DDM for possible problems. You can also examine the Ddm.log file for errors or additional information.

\Despoolr.box\Receive

This folder stores the data that is received from a child site or a parent site. Typically, files are processed and moved as soon as Configuration Manager 2007 receives the instruction file (.ins file). Examine status messages for the Despooler for possible problems. You can also examine the Despool.log file for errors or additional information.

\Inventry.box

This folder temporarily stores hardware inventory files from management points after clients transfer their hardware inventory to the management point. The Inventory Processor converts the .nhm file to a binary .mif file and then moves the file to the \Dataldr.box folder. Examine status messages for the Inventory Processor for possible problems. You can also examine the Invproc.log file for errors or additional information.

\OfferSum.box

This folder receives summarization messages (.sum files) for advertisements from child sites and processes the files to the site database. A backlog of files can indicate a performance problem that is caused by a large number of messages. Examine status messages for the Offer Status Summarizer for possible problems. You can also examine the Offersum.log file for errors or additional information.

\policypv.box

This folder temporarily stores policy changes for the Configuration Manager 2007 components. Whenever the policy of Configuration Manager 2007 components change, a notification file appears in this inbox, causing the policy provider to regenerate the policies. A backlog of files in the policypv.box folder indicates that the policy provider component is not running. The policy provider component might not be able to read the site control file, or the component cannot write to the database. You can examine the Policypv.log in the \Logs folder on the site server for errors or additional information.

\Replmgr.box\Incoming

This folder receives files from the SMS despooler after processing files from other SMS sites. The SMS Replication Manager determines whether the file is transaction-oriented and then verifies that the serial numbers are correct. If the file is not transaction-oriented, no additional verification is performed. The Replication Manager transfers the file to the recipient component for final processing. Examine status messages for the Replication Manager for possible problems. You can also examine the Replmgr.log file for errors or additional information.

\Replmgr.box\Outbound

This folder temporarily stores files that are destined for another site. This folder also contains three outbox subfolders that correspond to the priority of the files. For example, this folder can contain \High, \Low, and \Normal folders. When the Replication Manager detects files in one of the outbound directories, the Replication Manager waits for additional files before moving the files to the \Process subfolder and then to the \Ready subfolder. Examine status messages for the Replication Manager for possible problems. You can also examine the Replmgr.log file for errors or additional information.

\Replmgr.box\Ready

This folder stores files that are compressed for transmission to remote sites. The files are moved to the Scheduler for transmission. A backlog of files can indicate that the Scheduler is backlogged or is already processing files of the same priority. In this scenario, the Scheduler has to wait for the transmission to complete. Examine status messages for the Replication Manager for possible problems. You can also examine the Replmgr.log file for errors or additional information.

\Schedule.box

This folder stores mini-job files (.job files) that were created by the Replication Manager. The Scheduler turns the .job files into Sender jobs. A backlog of files can indicate that the Sender cannot connect to or cannot transfer data to another site. A backlog can also indicate that the Scheduler cannot process the mini-job files because files are missing from the \Schedule.box\Uid folder. Examine status messages for the Scheduler for possible problems. You can also examine the Sched.log file for errors or additional information.

\Schedule.box\Outboxes

This folder contains the outbox folders for each installed sender. In the sender's outbox folder, you can find send request files (.srq files) or send request status files (.srs files). A backlog of .srq files indicates that the sender cannot process the number of jobs scheduled for that sender or that the sender cannot connect to or transfer data to another site. Examine status messages for the Scheduler for possible problems. You can also examine the Sched.log file for errors or additional information. Also examine the sender log file (Sender.log) for any errors when it tries to communicate to the remote site.

\Schedule.box\Requests

This folder stores the initial send request files before the Scheduler transfers the files to a sender. This folder also stores send request files that are returned when the sender cannot connect to the target site. Examine status messages for the Scheduler for possible problems. You can also examine the Sched.log file for errors or additional information. Also examine the sender log file (Sender.log) for any errors when it tries to communicate to the remote site.

\Schedule.box\Tosend

This folder stores package and instruction files before they are transferred to another site. Package and instruction files start with .p00 and .i00 file name extensions, and the file name extensions increment numerically. The files are removed after the sender has copied the files to the remote site. A backlog of files can indicate that many send requests are not completed or that the Scheduler has not yet deleted the files. Examine status messages for the Scheduler for possible problems. You can also examine the Sched.log file for errors or additional information. Also examine the sender log file (Sender.log) for any errors when it tries to communicate to the remote site.

\Sinv.box

This folder stores client software inventory files (.sic and .sid files) that are copied from the management point. A backlog of files can indicate that the Software Inventory Processor cannot connect to the site database or that too many files were received. Examine status messages for the Software Inventory Processor for possible problems. You can also examine the Sinvproc.log file for errors or additional information.

\Sinv.box\BadSinv

This folder stores corrupted software inventory files. A backlog of files can indicate problems with specific clients, with management points, or with the network, causing data corruption. Make sure that there is not a backlog of zero-byte files in this folder. If zero-byte files exist, manually delete them. Examine status messages for the Software Inventory Processor for possible problems. You can also examine the Sinvproc.log file for errors or additional information.

\SiteStat.Box

This folder receives summarization messages (.sum files) for site system status from child sites before the files are processed to the SMS site database. A backlog of files can indicate a performance problem. Examine status messages for the Site System Status Summarizer for possible problems. You can also examine the Sitestat.log file for errors or additional information.

\Statmgr.box\Futureq

This folder stores status messages (.svf files) from remote systems (clients or site systems) if the date and time of the message is in the future compared to the site server's clock. The Status Manager does not process these messages until the computer clock matches the date and time when the status message was created. The date and time when the status message was created might be different from the date and time stamp of the file. A backlog of files can indicate that some site systems' clocks are not synchronized with the site server. Examine status messages for the Status Manager for possible problems. You can also examine the Statmgr.log file for errors or additional information.

\Statmgr.box\Queue

This folder receives status messages from SMS Executive components on the site server if the in-memory queue is not available. A backlog of files can indicate a problem with the Status Manager or that the component is trying to process too many messages. Examine status messages for the Status Manager for possible problems. You can also examine the Statmgr.log file for errors or additional information.

\Statmgr.box\Retry

This folder stores status messages that could not be processed to the site database. A backlog of files can indicate problems with the connection to the computer that is running SQL Server. Examine status messages for the Status Manager for possible problems. You can also examine the Statmgr.log file for errors or additional information.

\Statmgr.box\Statmsgs

This folder stores status messages from site systems and from Configuration Manager 2007 clients before the messages are processed by the Status Manager. A backlog of files can indicate a problem with the Status Manager or that the Status Manager is trying to process too many messages. Examine status messages for the Status Manager for possible problems. You can also examine the Statmgr.log file for errors or additional information.

\swmproc.box

This folder and its subfolders are used to temporarily store software metering information from Configuration Manager 2007 clients. A backlog of .sum and .sur files can indicate that the Software Metering Processor component cannot connect to the SMS database. Examine the status messages for the Software Metering Processor component for possible problems. You can also examine the Swmproc.log file for errors or additional information.

ConfigMgr Client IP Check Script

Troubleshooting client agent health issues at my current customer, I wanted to eliminate all of the stale systems from AD so I didn’t waste my time on them (and of course the customer was no real help here). I decided to write a script to take a list of systems, check if a forward and a reverse DNS entry exists and also compare the DNS reverse entry (if it exists) to the name of the system as specified in the list. Using these checks, I can now identify systems that probably don’t exist anymore and can be deleted from or disabled in Active Directory thus allowing ConfigMgr to be cleaned up.

Sample output:
Name           IP                  Reverse             Status
----           --                  -------             ------
xyz1           10.1.0.1            abc5                IP registered to another system
xyz2           -                   -                   Could not Resolve IP
xyz3           10.1.0.3            xyz3                OK
xyz4           10.1.0.4            -                   IP Address not found in reverse zone

Actual/exact interpretations of each of the categories is possibly subjective and based on the configuration of a particular environment but in general, IP registered to another system and Could not Resolve IP are indicative of stale systems. Recall that AD System Discovery also does a forward DNS lookup on systems before it creates a DDR on them so this script follows similar logic as the discovery; however, once the system is discovered, AD Discovery won’t remove it and thus this script. Also, AD discovery doesn’t do a reverse lookup because this may or may not be configured in any given environment.

The script is a PowerShell script and can be run on any system that can query the internal DNS. By default, it pulls the names of systems to check from a file called sys.txt in the same directory as the script; place each system name to query on a separate line.

And then, run it from a PowerShell command prompt. To output the results to a CSV, pipe the output of the script to the Export-Csv commandlet; e.g., .\IPCheck.ps1 | Export-Csv c:\IpCheckResults.csv

Download: IPCheck.zip

ConfigMgr Client Hotfix Queries

Client hotfixes in ConfigMgr has become an often discussed topic as of late mainly because of the pre-R3 hotfix (977384) required on all managed systems. Microsoft recently published a good KB on this titled System Center Configuration Manager 2007 Hotfix Installation Guidance. Near the bottom of this KB they added this small query to help build collections to target the client hotfixes:

select * from SMS_R_System
inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE 
on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId
where SMS_R_System.ClientType = 1 
and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Name = "CcmFramework" 
and (SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version < "4.00.6487.2012"

Unfortunately, this query is not specific to any particular hotfix and the hotfix KBs themselves do not list which component that they update – although they do list version numbers if you know what to look for.

So my task was clear, figure out what components get updated version numbers. First, I used this little query to pull back all of the component versions in the environment I am currently working in:

SELECT
    AC.Name0, AC.Version0
FROM
    dbo.v_GS_SMS_ADVANCED_CLIENT_STAT AC
GROUP BY AC.Name0, AC.Version0
ORDER BY AC.Name0

And from there I was able to put together this little table for the following three client hotfixes (there aren’t a whole lot of client hotfixes so the table is short, but worth documenting and thus this blog post):

KB	Component	Version
977384	SmsPowerManagement	4.0.6487.2157
978754	SmsOSDeployment	4.0.6487.2115
2444668	SmsInventory	4.0.6487.2161

If you review the list of files affected in each of the above KBs, you will find the version numbers listed there although they are associated with files and not components in the KB.
Note that SmsPowerManagement does actually exist on the clients even if you haven’t installed 977384. This is because R3 functionality was actually shipped in SP2 and installing R3 merely enables it.
Clients with 977384 also have two other components bumped up in version:

Component	Version
CcmFramework	4.0.6487.2155
SmsSoftwareDistribution	4.0.6487.2154

I can’t find the above version numbers publically documented anywhere though.
Using this info and the query you (and I) can now target or report on client hotfix deployment.

ConfigMgr 2007 Post-SP2 Hotfixes

Hotfixes, bug fixes, patches, or whatever you want to call them are an inevitability with any size of software project and ConfigMgr is no exception – if anyone disagrees then they have never written a line of code in their life. Here’s my current list of notable post SP2 hotfixes for ConfigMgr 2007:

KB Number	Title
977203 1	User state migration fails on a SCCM 2007 SP1 client or on a SCCM 2007 SP2 client after you install security update 974571
977384 2	Prerequisite hotfix for System Center Configuration Manager 2007 R3
978021	The Distribution Manager that is in System Center Configuration Manager 2007 SP2 does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings
978754 2	You cannot import a driver into an OSD image if the driver is signed for only the Windows 7 operating system in SCCM 2007 SP2
978757	The second Search paths may not discovered when you enable the Active Directory System Discovery method or the Active Directory User Discovery method that runs on a System Center Configuration Manager 2007 SP2 site server
980270	The computer associations are not created by the import computer information wizard in SCCM 2007 Service pack 2
981640	The "Backup ConfigMgr Site Server" task fails on a ConfigMgr 2007 site server
981797	The handle count and memory usage of Smsexec.exe keeps increasing in System Center Configuration Manager 2007 SP2
982399	A System Center Configuration Manager 2007 SP2 site server randomly stops processing status messages
2213600	You cannot import a driver package into a System Center Configuration Manager 2007 SP2 site if one or more driver files in the package are already imported into the site
2345551	The Active Directory system discovery process cannot detect a client if the DNS suffix of the client differs from its DNS domain name in System Center Configuration Manager 2007 SP2
2444668 2	Hotfix rollup for Asset Intelligence compatibility issues with new products in System Center Configuration Manager 2007 SP2: November 2010

¹ 977203 is superseded by 977384 but you still may need the certfix tool from 977203: KB977384 Supersedes KB977203.

² Also has a client component

You must download each of the above updates directly from Microsoft via the hotfix request system; there are no direct links to them. Each KB contains a link near the top that takes you to the hotfix request page for that particular hotfix.

 

When I run updates on a site system, I always run them from a command-line for two reasons:

1. UAC. Using UAC on a server is very debatable but if it is on, the only way (that I know of) to install an MSI elevated is to run an elevated command-prompt and then execute the MSI from there. Note that although you can (shift-)right-click on an MSI and get the Run As options, these don’t actually effect the execution of msiexec.
2. To enable logging. I always watch the log while installing updates because each update shuts down services including ConfigMgr services, WMI, and other dependent services (each update shuts down slightly different things). Sometimes, the services can’t be stopped for whatever reason. I have seen WMI fail to shutdown and then immediately re-run the update and it shuts down fine. I have also seen dependent services fail to be shut down and have to be manually “killed”; most notably Trend Micro anti-virus. Without watching the log (using Trace32 of course) I wouldn’t know why the update is getting stuck. The command-line for this is simply the following:

msiexec /I filename.msi /l*v filename.log /q

On new installations, I place all of the updates into a single folder and use a script (run from the same folder as the hotfixes) to kick each one off and then kick off trace32 automatically:

@ECHO OFF
FOR /f "tokens=*" %%G IN ('dir /b *.msi') DO (
ECHO %%G
start /D %~dp0 /B msiexec /I %%G /l*v %%G.log /q
ping 127.0.0.1 -n 1 -w 1000 > nul
"C:\Program Files (x86)\ConfigMgr 2007 Toolkit V2\Trace32.exe" "%~dp0%%G.log"
)

The script iterates over each MSI in the folder and does the following (for each):

1. Echoes the MSI name
2. Runs the MSI in a separate, new command shell and creates the log file
3. Waits for 1 second (there is no batch file wait or sleep command but the ping command does the trick nicely)
4. Launches trace32 automatically loading the log file from the current MSI so that you can watch it (make sure that you modify the path of for Trace32 for your installation)
5. Waits for trace32 to exit before it goes to the next MSI

To my knowledge, all of the above updates are completely independent of one another and have never found a reason to order them any particular way during installation; the script will run them in normal command-shell directory sort order.