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.

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

(more…)

Reading a Microsoft blog post recently, I was reminded of a customer request from late 2002.  The emailed request was something like this:

Had to use the generic Win NT4 install on a Toshiba laptop yesterday.  There were some issues.

No network adapter is installed at the time of the Win NT4 installation.* This causes an error with the installation of eTrust and the CA UniCenter software.  It also means that networking component needs to be manually installed AND Error 7001 is also written to the system log.
To fix the Error 7001, we need to reinstall Service Pack 6a.

My suggestion is that you install the Microsoft Loopback Adapter during the installation, as it will solve the build issues we’re finding.

This was a brilliant suggestion as it turns out.  We would occasionally see build failures due to our NT4 build not having the network card drivers for the newer network cards.  Older versions of SQL (SQL 2000?) also needed a network card to be installed, so SQL would install properly.
The loopback adapter was a suitable work around for those issues.

These days, I would only use a loopback adapter with virtual machines (think VMware/VPC) IF the host machine didn’t have a physical network connection.
A loopback adapter will give you a working TCP/IP stack.

On Windows 7, it’s not obvious or easy to add a loopback adapter.  But Cesar de la Torre tells you how, on his MSDN Blog.

“ In any case, if you want to run the Wizard where you can manually add hardware, you need to start it from the COMMAND PROMPT:

1. Run cmd, but do it like: “Run as Administrator”
2. From the command prompt, write down “hdwwiz.exe” and execute it. Then, the “Add Hardware Wizard” will be launched.
3. Select: Install hardware manually –> Network Adapters –> Microsoft –> Microsoft Loopback Adapter.

You can read more info about it (step by step) in the following URL:
How to install a Loopback Adapter in Windows 7 (Windows Reference site) “

~~~

* – Network adapters WERE installed for supported desktops & laptops.  The customer had an unsupported laptop.

With eTrust 8, those pack of clowns at Computer Associates seem to think it’s a good idea to distribute eTrust Anti-virus system file updates via the automated virus signature update process.

So, in the past, you as an eTrust AV admin might have distributed DRVUPDi.exe updates manually (or not at all).  CA  now forces that update out.

So why is that a problem?

• An update requires a reboot.  The update includes the INO_FLTR.SYS & INO_FLPY.SYS files which hook into the file system.  Which requires a reboot.
• When you reboot, say as part of regular maintenance, or a scheduled change, CA throws you a curve ball because they’ve changed something without telling you.
• Yes, it truly is a problem.  Back in April 2004, a faulty INO_FLTR.SYS caused Citrix desktop clients to take 25 minutes to boot up.

Conclusion: CA are a pack of bastards.

So if you need to debug ino_fltr.sys
You use DebugView to capture what’s going on with INO_FLTR.SYS.

1. Set the following registry key:
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\INO_FLTR\Setting]
”DebugOption”=dword:0x20400D
2. Restart the PC.
3. Run the Sysinternals DebugView tool to capture the output.