Logs of an SMS Administrator at myITforum.com

I won't bother regurgitating the details on this problem as we've all probably experienced it. Here are the links: (Updated May 22, 2007)

http://support.microsoft.com/kb/927891

http://support.microsoft.com/kb/932494

http://support.microsoft.com/kb/916089/

The Microsoft Update Sync Tool is installed on a client computer you define. On a schedule you can also define, the Sync Tool will have the client connect to Microsoft and download the latest WSUSSCN2.CAB file. It then compares this file to the same file on the Site Server housing the ITMU. If the files are different, it copies the file from the Sync client to the Site Server, updates the distribution points and updates the site catalog. There will eventually come a time when you are forced to manually update the WSUSSCN2.CAB file within SMS. Here are a couple of ways to manually update this file.

1. Go to a command prompt
2. Switch to the directory where the Microsoft Update Tool is installed. By default it should be in C:\windows\system32\VPCache\[Package ID] where PackageID is the SMS-defined numeric ID for your Update Tool package.
3. Type the following command at the command prompt and press ENTER: Syncxml.exe /s /unattend /site SiteServer /code SiteCode /package PackageID /target PackageSourceFolder where SiteServer is the name of the Site Server, SiteCode is the Site Code of the Site Server which owns the Windows Update Tool package, PackageID is the SMS-defined numeric ID for your Update Tool package and PackageSourceFolder is the path to the Update Tool source files. (By default this path is C:\Program Files\Microsoft Updates Inventory Tool\PkgSource and it is shared as PackageSrc so the path would be \\[SiteServerName]\PackageSrc)

You can watch the progress of the update process by checking out WUSSyncXML.log file on the Sync Client computer.

This log was taken from an automated sync, but the manual sync will look similar: (Check the comparison line in bold.)

Initialized log file - SyncXML started at 5/22/2007 11:18:30 AM 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 613 (0x0265)
Sync task started with command-line = /s /site [SiteServer] /code [SiteCode] /package [PackageID] /target \\[SiteServer]\PackageSrc 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 613 (0x0265)
User Account: [UserAccount] 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
User Profile: C:\Documents and Settings\[UserAccount] 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Command line specified folder to update as \\[SiteServer]\PackageSrc. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Command line specified package to update on DPs as [PackageID] 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Command line specified site code: [SiteCode]. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Command line specified site server: [SiteServer]. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Download completed - http://go.microsoft.com/fwlink/?LinkID=74689 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Download completed successfully. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Trying to calculate hash on C:\DOCUME~1\SMSSER~2\LOCALS~1\Temp\wsusscn2.cab. Software Updates Scan Helper 5/22/2007 11:18:49 AM 788 (0x0314)
Trying to calculate hash on \\[SiteServer]\PACKAGESRC\wsusscn2.cab. Software Updates Scan Helper 5/22/2007 11:18:49 AM 788 (0x0314)
C:\DOCUME~1\[UserAccount]\LOCALS~1\Temp\wsusscn2.cab and \\[SiteServer]\PACKAGESRC\wsusscn2.cab were found to be different. Software Updates Scan Helper 5/22/2007 11:19:02 AM 788 (0x0314)
Copied C:\DOCUME~1\SMSSER~2\LOCALS~1\Temp\wsusscn2.cab to \\[SiteServer]\PACKAGESRC\wsusscn2.cab. Software Updates Scan Helper 5/22/2007 11:20:32 AM 788 (0x0314)
Updating Distribution Points for Package: [PackageID], Site: [SiteServer], SiteCode: [SiteCode], Source dir: \\[SiteServer]\PackageSrc 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Distribution Points updated successfully. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Checking if patch preapprovals are supported by site [SiteServer] 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Patch preapprovals are supported by site [SiteServer], proceeding with catalog updates 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Updating site catalog: CATALOG="\\[SiteServer]\PACKAGESRC\wsusscn2.cab" TYPE="Microsoft Update" SERVER=[SiteServer] SITE=[SiteCode] PACKAGE=[PackageID] LCID=1033 MAXAGE=0 ADDLOC= LOGFILE="C:\WINDOWS\system32\CCM\Logs\WUSSyncXML.log" VERBOSE=2 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:35): Processing security catalog \\[SiteServer]\PACKAGESRC\wsusscn2.cab ... 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:35): Connected to \\[SiteServer]\root\sms 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:36): Connected to \\[SiteServer]\root\sms\site_[SiteCode] 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:36): SMS_ApplcableUpdatesSummaryEx class does not support ScanPackageID property, link records will be inserted separately 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:37): Loading updates cache from database 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:41): Loaded cache with 2742 updates from database 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:20:41): Initializing catalog \\[SiteServer]\PACKAGESRC\wsusscn2.cab for synchronization. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:21:17): Synchronizing updates from the catalog to the database. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:24:51): Parser summary: 14685 processed, 1767 matched, 0 outdated, 0 updated 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:24:51): Database summary: 0 writes requested, 0 inserted, 0 updated 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
UpdateWUSCatalog(11:24:51): Processing time: 0d 00h 04m 16s 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 5429368 (0x52D878)
Loaded "C:\WINDOWS\system32\CCM\smscstat.dll"; the module handle is 0x188A0000. Software Updates Scan Helper 5/22/2007 11:24:52 AM 788 (0x0314)
CreateSMSStatusMessage() succeeded; the status message object handle is 0x01A2F7E8. Software Updates Scan Helper 5/22/2007 11:24:52 AM 788 (0x0314)
ReportSMSStatusMessage() succeeded. Software Updates Scan Helper 5/22/2007 11:24:53 AM 788 (0x0314)

Should the scan files be the same on the Sync client and the Site Server, the following two lines will be located directly after the file comparisons:

C:\DOCUME~1\[UserAccount]\LOCALS~1\Temp\wsusscn2.cab and \\[SiteServer]\PACKAGESRC\wsusscn2.cab were found to be same. Software Updates Scan Helper 5/21/2007 10:00:22 PM 1608 (0x0648)
Distribution points will not be updated. 
Software Updates Scan Helper 1/1/1601 12:00:00 AM 1608 (0x0648)

Another method to accomplish this manually is: (you will not be able to watch the process and will have to manually compare the files on the Sync Client and the Site Server.)

1. Download the WSUSSCN2.CAB file from http://go.microsoft.com/fwlink/?LinkID=74689
2. Copy this file into the PackageSrc folder on the Site Server owning the Microsoft Update Tool package.
3. Within the SMS Console, update the distribution points for the Microsoft Update Tool package

I hope this helps some people.

 Update: This tool has had a name change to SMS Client Center. It has new features and now adds itself to your SMS console right-click drop-downs, if you have the console installed.

 I would say this is perhaps one of my most used tools. There are a multitude of tasks which can be fired off from the GUI and several status reports which are quite useful. I've been able to repair many clients right from this tool without any manual intervention.

I'd say this is a must for anyone who has to deal with the wonderful SMS client on a daily basis.

http://sourceforge.net/projects/smsclictr/

If you have ever run a particularly time-consuming SMS Web Report, you have probably run into the problem where IIS times out during the report. The error indicates that the ASP script has timed out.

The default timeout value is set to 90 seconds. You can increase this value within IIS Manager:

• Open IIS Manager
• Expand Web Sites
• Right-click on SMSReporting_SiteCode and select Properties
• Within the Virtual Directory tab, click on the Configuration button
• Within the Options tab, enter the desired timeout value in the ASP Script Timeou field (shown in seconds)
• Click OK, Click OK, then close the IIS Manager

This may take a few configurations to get the timing correct for your report, but it's well-worth the few seconds it takes to change it.

In our environment, we use (most of the time) a single workstation image and then layer applications based on the division or department. Our imaging department creates these images, then uploads them to a central Ghost server for disbursement among the remote sites. On occasion, technicians in the remote sites fail to confirm the time zone information during setup. Kerberos security will prevent any remote administration of a machine which has its time information off by a significant amount. Typical symptoms of this include, but are not limited to:

• Cannot UNC into the affected machine by NetBios name, but can via IP.
• Cannot remote into the affected machine via DameWare, Radmin, etc.
• Cannot run remote batch or VBScripts on the affected machine.

This also will affect the operation of remote SMS 2003 operations, such as using the SMS Tools option kit, but the client workstations will still check into their assigned sites and pick up policies and thus will "seem" to operate normally. I discovered the time zone/sync problem in our environment when a couple of imaging workstations were joined to the domain and left on the network during the SMS discovery process, and thus had the SMS client installed. Within a week or so, machines from incorrect locations started populating the two sites where images are created. When I began to force site assignment changes, I received MANY "access denied" errors through the SMS Tools "Reassign Site Code" function. After conversing with local technicians from the affected sites, it was discovered that the time information was way off on these machines from which I received the "access denied" errors.

 Considering the number of machines which were affected, manually adjusting the time information and reassigning the assigned site was out of the question. After reviewing the logs of one machine, I noticed that from an SMS perspective, everything seemed to be functioning normally. i.e. Packages were being deployed, etc. So I created collections which grouped the affected machines by correct site (they are named so I can do this) and created these four packages to deploy.

Time and Zone Sync Batch Files:

TZ_Arizona.bat

control.exe timedate.cpl,,/Z (GMT-07:00) Arizona
NET TIME /SET /YES
exit

TZ_Central.bat

control.exe timedate.cpl,,/Z Central Standard Time
NET TIME /SET /YES
exit

TZ_Eastern.bat

control.exe timedate.cpl,,/Z Eastern Standard Time
NET TIME /SET /YES
exit

TZ_Pacific.bat

control.exe timedate.cpl,,/Z Pacific Standard Time
NET TIME /SET /YES
exit

I set these up as download and distribute and our problems were corrected immediately on those machines which received the advertisement.

With fairly large SMS 2003 web reports, I've received memory errors. Although I had increased the number of rows necessary to produce the correct records, (see http://myitforum.com/cs2/blogs/mlucero/archive/2007/05/17/sms-2003-configuration-increasing-rows-past-10-000-in-web-reporting.aspx), I still could not view the report I had created. This will be most noticeable in larger SMS environments but may occur in smaller situations, depending upon the size of the web report. The following resolution is from Microsoft:

"You might need to adjust the AspBufferingLimit setting. The AspBufferingLimit property sets the maximum size of the ASP buffer. The default is approximately 4 MB. To change the default, open %WindowsRoot%\System32\InetSrv\MetaBase.xml and search for “AspBufferingLimit”. Adjust the setting to allow for 1 MB per 1000 records. You can make changes to the MetaBase.xml file while IIS is running only if the edit-while-running feature is enabled. Otherwise, you must stop IIS before editing the MetaBase.xml file.

For more information about writing changes to MetaBase.xml, see “Configuring the Metabase” in the Server Administration Guide on Microsoft TechNet."

The section of the MetaBase.xml file you need to find is: </IISFtpServer>

Then, search for the value: AspBufferingLimit="[some number]"

I changed the value in our MetaBase.xml file to 80194304 and it works just for for all our reports. As a reference we have 13,000+ clients. I hope this is helpful to other folks. Here is the link to the Q & A: http://www.microsoft.com/technet/sms/2003/library/techfaq/tfaq10.mspx

It is inevitable that every SMS Administrator runs into a web report which will not yield the total of the query's request, giving only 10,000 rows of information. Here is the resolution for this from Microsoft:

"You can change the limit by modifying the registry on the reporting point machine. Under the HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Reporting key, add the DWORD value Rowcount and assign it the value for your desired maximum limit. The maximum row count in decimal is 32767. If you need to return more than 32,767 records, you can set the row count to 0xffffffff hexadecimal, which will return all rows. However, this significantly increases the workload on the SMS site database. If you experience problems displaying the values in reports, add the Values Rowcount registry key by using the same settings as above.

Be aware that if you increase this value, you might also need to adjust the AspBufferingLimit setting. For more information about changing the AspBufferingLimit setting, see the FAQ “When my Web reports contain a column that has more than 5,000 records I get an IIS error 500 on my IIS 6.0 reporting point. How do I fix this?” earlier in this document."

I've changed mine to FFFFFFFF and it works fine, albeit it somewhat slow, as indicated above. Here is the link to the Q & A:

http://www.microsoft.com/technet/sms/2003/library/techfaq/tfaq10.mspx

This is a very handy tool written by Mark Nunn will allow you to take a text list of hostnames and add them to a collection. One of it's better features is that you enter in your site server information and it will query, then list that server's collection in the window below, making it much easier to find the collection ID.

Enter in the collection ID, then the path to the text list and bingo!

As a side note, I generally make a new collection for these types of tasks, since they are generally "special order." That way I don't have to manually delete the machines from the collection properties later... just delete the entire collection.

http://myitforum.com/inc/upload/8510Collection%20Adder.zip

Enjoy!

(Originally posted November 29,2006)

1. Within (Site Settings in the console) Client Agents > Software Inventory Client Agent > Properties
2. Add a new file type *.sys
3. Set the Path to a “Variable or path name” = %windir%\system32\drivers\ and Search subdirectories
4. Make sure all Excludes are unchecked
5. Make sure File details and Product details are checked
6. Refresh machine policies on all sites where changes are made
7. Initiate Software Inventory on all sites where change are made
8. Wait for the data to flow up to your reporting sites
9. Within (Reporting Website) Software – Files > Computers with a specific file
10. Enter the filename for which you are searching. (i.e. for Broadcom wireless – BCMWL5.sys
11. When the report is produced, sort by file version and export this report to an Excel spreadsheet
12. Eliminate all rows which have a version which is compliant with the new standards
13. Create a text file with the list of machine names and eliminate all spaces (reports tend to put spaces in strange places)
14. Create a collection with the tool “Collection Adder” with the test file you just created
15. Deploy your update to this collection. (each different driver will require a separate collection and deployment of course.)

I hope this helps others trying to tackle this problem.

If you have ever run a particularly time-consuming SMS Web Report, you have probably run into the problem where IIS times out during the report. The error indicates that the ASP script has timed out.

The default timeout value is set to 90 seconds. You can increase this value within IIS Manager:

• Open IIS Manager
• Expand Web Sites
• Right-click on SMSReporting_SiteCode and select Properties
• Within the Virtual Directory tab, click on the Configuration button
• Within the Options tab, enter the desired timeout value in the ASP Script Timeou field (shown in seconds)
• Click OK, Click OK, then close the IIS Manager

This may take a few configurations to get the timing correct for your report, but it's well-worth the few seconds it takes to change it.

(Originally posted February 22, 2007)

When encountering software distribution problems, the SMS client log files are key in the troubleshooting process. Four client log files come to mind when thinking about how to go about resolving software distribution problems: LocationServices.log, CAS.log, Execmgr.log and ContentTransferManager.log. Each has its own purpose and contains information valuable to tracking down the source of a software distribution problem. In this article, I'm going to focus on the CAS.log and review some details about the information which it contains.

The CAS.log (Content Access Service) is typically used to find the status of the local package cache. It shows the success, or lack thereof, of the client's attempts at accessing content on its Distribution Point. Containing valuable distribution information, the CAS.log can be an asset to SMS administrators attempting to deduce various software distribution problems.

Let's take a look at a CAS.log containing the successful access of a software package which has been advertised to a client. This particular advertisement is set to run from the distribution point. I have omitted time stamp information from the log displayed here to save space.

Requesting content Z00000FD.1, size(KB) 1164, under context System
LS job {78C2DCAB-26A0-43BF-A1A1-11263440625B} submitted to get DP locations for content Z00000FD.1
Successfully created location request {EA8DD5F0-964D-4B0D-B116-8BC84EDD4F42} for content Z00000FD.1
Location update from LS for content Z00000FD.1 and location request {EA8DD5F0-964D-4B0D-B116-8BC84EDD4F42}
Matching DP Location found 0 - \\IOWACSMSPRIM01\Z20_DP_SHARE$\SMSPKG\Z00000FD\
Canceling LS Job {78C2DCAB-26A0-43BF-A1A1-11263440625B} for content Z00000FD.1

You can follow the process in the log and see the subsequent successful location of the content on a reachable DP. Considering this is not a "download and run" advertisement, the logging for this content ends a the job cancellation. You can pick up the rest of the process in other client logs which will be discussed in future articles.

Now let's look at the CAS.log of the same package advertised to a client where there is no available Distribution Point containing the package.

Requesting content Z00000FD.1, size(KB) 1164, under context System
LS job {5B0BBB9F-89A1-45E2-AC50-02C0921F4B47} submitted to get DP locations for content Z00000FD.1
Successfully created location request {837B5728-D4CB-4C25-BD35-A39ECBAC5110} for content Z00000FD.1
Location update from LS for content Z00000FD.1 and location request {837B5728-D4CB-4C25-BD35-A39ECBAC5110}
No matching DP Location found
Location update from LS for content Z00000FD.1 and location request {837B5728-D4CB-4C25-BD35-A39ECBAC5110}
No matching DP Location found

(These last two message repeat until a failure is determined at which time the following messages occur.)

Failed to get DP locations from LS for content Z00000FD.1 and location request {837B5728-D4CB-4C25-BD35-A39ECBAC5110}
Releasing content request {837B5728-D4CB-4C25-BD35-A39ECBAC5110}
Canceling LS Job {00000000-0000-0000-0000-000000000000} for content Z00000FD.1
CancelLocationRequestfailed

The failure notifications will be easy to locate in the CAS.log using SMS Trace as the "Failed to get DP location..." message will be in yellow and the "CancelLocationRequestfailed" message will be flagged in red.

Hopefully this will help some with the visual on how the CAS.log works with non-downloaded content. In a future article I will discuss and demonstrate the workings of the CAS.log in reference to downloaded content. There are differences between the logging of the two types of content requests which are significant enough to document and demonstrate.

Recently I was asked to provide some SMS web reports for upcoming budget planning sessions. Specifically, managers wanted computer model reports for machine refresh expenditures. I created a few reports, but these four have proven very useful and were well-received. Perhaps some of you may find these reports useful. I have attached the MOF files for importing. There are four reports supplied here. I hope others find these useful.

Count all Computer Models:

SELECT     Model0, COUNT(Model0) AS Expr1
FROM         v_GS_COMPUTER_SYSTEM
GROUP BY Model0
ORDER BY Model0

Count Computer Models by Selection:

SELECT     Model0, COUNT(Model0) AS Expr1
FROM         v_GS_COMPUTER_SYSTEM
WHERE Model0 = @variable
GROUP BY Model0

     Prompt:

SELECT DISTINCT Model0 FROM v_GS_COMPUTER_SYSTEM
ORDER BY Model0

Count Computer Models by Selection (Detail View):

SELECT     v_R_System.Name0, v_GS_PC_BIOS.SerialNumber0, v_GS_COMPUTER_SYSTEM.Manufacturer0, v_GS_COMPUTER_SYSTEM.Model0,
                      v_R_System.Operating_System_Name_and0
FROM         v_R_System INNER JOIN
                      v_GS_COMPUTER_SYSTEM ON v_R_System.ResourceID = v_GS_COMPUTER_SYSTEM.ResourceID INNER JOIN
                      v_GS_PC_BIOS ON v_R_System.ResourceID = v_GS_PC_BIOS.ResourceID
WHERE     (v_GS_COMPUTER_SYSTEM.Model0 = @variable)
ORDER BY v_R_System.Name0

    Prompt:

SELECT DISTINCT Model0 FROM v_GS_COMPUTER_SYSTEM
ORDER BY Model0

Count Computer Models by Site (AD Boundaries Only):

SELECT     v_SiteBoundary_ADSite.SiteCode, v_GS_COMPUTER_SYSTEM.Model0, COUNT(DISTINCT v_GS_COMPUTER_SYSTEM.ResourceID) AS Count
FROM         v_GS_COMPUTER_SYSTEM INNER JOIN
                      v_R_System ON v_GS_COMPUTER_SYSTEM.ResourceID = v_R_System.ResourceID INNER JOIN
                      v_SiteBoundary_ADSite ON v_R_System.AD_Site_Name0 = v_SiteBoundary_ADSite.ADSiteName
WHERE     (v_SiteBoundary_ADSite.SiteCode LIKE @variable)
GROUP BY v_SiteBoundary_ADSite.SiteCode, v_GS_COMPUTER_SYSTEM.Model0

    Prompt:

SELECT SiteCode, v_Site.SiteName FROM v_Site

If you've recently upgraded your SMS infrastructure to SP2, you may have encountered repeating 4918 errors within the SMS_SITE_COMPONENT_MANAGER component. Here is a brief of how the error would read:

<<>>
Message ID: 4918

Systems Management Server cannot update the dNSHostName property for the existing object "cn=SMS-MP-Z13-LWSMSLWPRIM" in Active Directory. This property is used to publish fully qualified host names in Active Directory.

Possible cause: The Active Directory schema has not been extended with latest version of the SMS Active Directory classes and attributes.
Solution: Ensure the schema has been extended with the latest version of the SMS Active Directory classes and attributes. The schema can be extended with the tool "extadsch.exe" from the SMS directory on the SMS Site server that reported this message.
<<>>

The resolution presented is correct in this situation. SP2 for SMS 2003 has an added feature of utilizing the Site Server FQDN's within Active Directory. To use this function, you must extend the Active Directory Schema. The tools you need are provided with the SP2 upgrade files. You can extend the schema using extadsh.exe or with the provided LDIF file using ldifde.exe. I've provided links to explanations for both methods, but I prefer using extadsh.exe.

*** It should be noted that it is NOT necessary to extend the schema for SP2 if you do not plan on taking advantaged of the extended features. These errors are not malicious and will not affect the operation of your site.

I had spent some time yesterday (May 2, 2007) researching and correcting an IIS-related issue with my MP on a particular Site Server. Another issue was present on which I had found some information, but had not found a resolution. Again, within the Application Event log on the Site Server, the following errors were showing:

Event_ID: 47

WMI ADAP was unable to retrieve data from the PerfLib subkey: SYSTEM\CurrentControlSet\Services\mssindex\Performance\Library, error code: 0x80041009

Event_ID: 47

WMI ADAP was unable to retrieve data from the PerfLib subkey: SYSTEM\CurrentControlSet\Services\MSSGTHRSVC\Performance\Library, error code: 0x80041009


Event_ID: 47

WMI ADAP was unable to retrieve data from the PerfLib subkey: SYSTEM\CurrentControlSet\Services\MSSGatherer\Performance\Library, error code: 0x80041009


Event_ID: 47

WMI ADAP was unable to retrieve data from the PerfLib subkey: SYSTEM\CurrentControlSet\Services\MSSEARCH\Performance\Library, error code: 0x80041009


Event_ID: 47

WMI ADAP was unable to retrieve data from the PerfLib subkey: SYSTEM\CurrentControlSet\Services\Autocat\Performance\Library, error code: 0x80041009


The research I performed indicated there were some additional permissions which needed to be made - and these were already present when I checked the various areas listed. But, to my surprise, these errors disappeared after my re-installation of IIS yesterday. All Event Logs were clear of the problems reported yesterday.

I will still research this, but for the time being, I'm going to attribute yesterday's problems to a corrupt IIS installation. If anyone has had these issues and found an alternate solution, please post a comment.

This morning (May 2, 2007) greeted me with an error message I had not seen in quite a while. As I was going through my normal "morning check" of our various SMS sites, I noticed one particular site was lit up like a Christmas tree. Both the OS Application Event log and the SMS_MP_CONTROL_MANAGER had multiple errors displaying:

SMS_MP_CONTROL_MANAGER:

Message ID: 1020

SMS Site Component Manager failed to reinstall this component on this site system.

Solution: Review the previous status messages to determine the exact reason for the failure. SMS Site Component Manager will automatically retry the reinstallation in 60 minutes. To force SMS Site Component Manager to immediately retry the reinstallation, stop and restart SMS Site Component Manager using the SMS Service Manager.

Message ID: 4963

MP Control Manager detected MPsetup has failed to create the CCM_Incoming Virtual Directory.

Possible cause: The IIS IWAM account has expired, been disabled, or has invalid or too restrictive logon hours. You may verify this information by running the net user command line for the IWAM account. (i.e.: “net user IWAMMachineName)
Solution: Use the output to verify that the account is enabled, and logon is possible during the time of installation. Note: You can use “net user” to modify the account properties.

Possible cause: The IIS IUSR account has expired, been disabled, or has invalid or too restrictive logon hours. You may verify this information by running the net user command line for the IUSR account. (i.e.: “net user IWAMMachineName)
Solution: Use the output to verify that the account is enabled, and logon is possible during the time of installation. Note: You can use “net user” to modify the account properties.

Possible cause: The Default Web Site is disabled in IIS.
Solution: Verify that the Default Web Site is enabled, and functioning properly.


Application Event Log:

Event_ID: 10005

Product: SMS Management Point -- Error 25006. Setup was unable to create the Internet virtual directory CCM_System
The error code is 80020009


MPSetup.log: (at the tail end of the MP installation log)

<05-02-2007 09:57:45> Setup was unable to create the Internet virtual directory CCM_System
The error code is 80020009
<05-02-2007 09:58:00> MP.MSI exited with return code: 1603
<05-02-2007 09:58:00> Backing up MPMSI.log to E:\SMS\logs\MPMSI.log.LastError
<05-02-2007 09:58:00> Fatal MSI Error - MP.MSI could not be installed.


I've had this error before, generally after a site reset required after an upgrade. In the past I've tried recommended fixes of starting and stopping services, rebooting, etc., etc. But, none of these methods ever worked consistently from one time to the next. Following is how I solve this problem and it has worked for me 100% of the time:

- Remove the MP role from the Site Server. Watch the MPSetup.log to ensure that the removal is complete.
- Uninstall the IIS component from the OS of the Site Server.
- Reboot the Site Server.
- Run ccmdelcert.exe from the SMS Toolkit.
- Reinstall the IIS component (with BITS) on the OS of the Site Server.
- Go into the IIS manager and allow WebDav.
- Add the MP role to the Site Server. Watch the MPSetup.log to ensure that the installation completes correctly.

Again, in my experience, I've never had this method fail, nor hork up any other process on the Site Server. Other experiences may vary, but I can only speak to my own. I hope this helps someone out there.

*** Update: (May 17, 2007) Scott Ewing emailed me the following which may help others: "I ran into this error yesterday after installing SMS 2003 SP 3 on one of our primary site servers. I installed the fix for KB913441, restarted the server, and then the MP installed without any problems." Thanks Scott!