The WMI fix – which is better?

Back in April, I wrote two posts about fixing a broken WMI.  There was some thought that deleting the WMI Repository WAS A BAD THING.

Well maybe not…

Across 600+ computers, I learnt the following:

  • Not deleting the WMI Repository fixed about half of the computers.  In the computers which were fixed, the SMS client immediately sprung back into action.
  • On the other 300 computers, the WMI fix made NO difference.
    These were the cases where deleting the WMI Repository DID fix the problem.
    BUT the SMS client needed to be woken up by re-running an SMS advertisement on the PCs.

So in summary, for stubborn broken WMI problems, deleting the WMI Repository should resolve the issue, but will require you to do some extra work.

Bookmark and Share

Deleting computers from SMS 2003 (and perhaps SCCM 2007), with a script.

Below is a script which will delete a list of computers from SMS 2003.  And quite possibly SCCM 2007 as well (not tested).  It was originally taken from the SMS 2003 Recipe Book, modified by Paul Town, and further improved by me.
The changes I made were:

  • the script will read a text file of computers to be deleted, and loop though them.
  • ping the computer to be deleted, and if it’s “pingable”, don’t delete it.
  • fixed a bug with the WMI GetObject call.

strSMSServer = "WISEFAQ2003"
strSMSSiteCode = ""

Set objFSO = CreateObject("Scripting.FileSystemObject")
If not objFSO.FileExists("C:\computer_lists\sms_deletion.txt") Then
WScript.Quit(99)
End If

Continue reading

SMS 2003 Server running slow, check your AV exclusions.

sms2003_150x70 We had a problem with one of our SMS servers today, it was not processing DDR records.

All 19,000+ of them.

After some investigation, a co-worker found it was a corrupted DDR record which caused SMS to get stuck. 

After we fixed it, SMS started processing them records at 1 DDR per seconds.
Let’s do the math, 19,000 records at 1 per second, is 60 DDR per minute; and 3600 per hour.  It would take at 5 hours to process all those.
PLUS SMS was adding more DDR records, all the time.

Oh Bother it

Remembering that SMS Primary Sites run SQL Server, I wondered … … did we exclude the SQL Process from our AV program???

In short, no.  Excluding SQLSERVR.EXE made a tiny difference.  Adding SMSEXEC.EXE & CCMEXEC.EXE to the exclusion list made a HUGH difference.

We went from 1 record per second, to 5 records per second being processed.

We’re deploying the change to the rest of the SMS Server fleet, Tuesday.

Bookmark and Share

“The Operating System Image file you have selected is not supported or has an invalid format”

The Operating System Image file you have selectedSMS 2003 produces this error when you have decided to create a new Operating System Package.

The frustrating thing is that it may work on one PC, and not another.

The underlying cause?

Difference versions of OS Deployment Feature Pack were installed.  Version 2.50.3658.1102 caused the error I was having.

The fix to the "… invalid format." error, was to update to version 2.50.3726.2000.

OS Deployment Feature Pack Version 2.50.7326.2000

Bookmark and Share

eTrust AntiVirus, and directories / processes you should exclude from scanning.

Computer Associates used to recommend excluding particular processes and directories from eTrust anti-virus scanning.  This, I found, was very important with Microsoft SQL Server, as it would cause a significant performance hit.
You would do this via setting the following registry keys, under HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\eTrustITM\CurrentVersion\Realtime
szExcludeProcessNames

Reason for exclusion List of processes to be excluded, separated by "|"
Microsoft SQL Server sqlserver.exe  sqlservr.exe
Microsoft Exchange store.exe
Microsoft SMS 2003 SMSEXEC.EXE  CCMEXEC.EXE
  and some others …

Continue reading