Cain Manor » Symantec

Considerations when moving SAV CE v10 from UNC to HTTP updates

Greg Cain — Mon, 09 Jun 2008 20:17:07 +0000

I didn’t see this documented anywhere, but you have to create the following MIME types on your web server when you move to HTTP updates as your transport.

IS Manager -> -> Default Web Site -> Your Directory -> properties.

Go to http header -> MIME Types. Add

.m25 application/binary (for v10)
.x86 application/binary (for v8 & v9)

Some quick SQL tips for myself

Greg Cain — Mon, 07 Apr 2008 22:28:04 +0000

osql -E- Login with your Windows credential

to change your authentication mode to Mixed Mode (meaning you can use both local password such as sa, and Windows Credentials), change…

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\LoginMode from 1 (default) to 2(mixed).

Now that you have mixed, mode you can change the sa password..

osql -E

sp_password NULL,””,sa

SAV Client Rescue

Greg Cain — Wed, 13 Feb 2008 18:52:41 +0000

Last week I did an upgrade to our SAV server that failed. This failure resulted in the SAV server being unable to talk to the clients. The new server install laid down a new PKI folder, which is the public key for the server. Once I recovered the old PKI file, the old clients were able to talk to the new server. However, a few boxes were built during that time, and expected the temporary PKI folder that had been replaced. This is how to fix the issue. This procedure should also help you migrate from an old server to a new server (other things being equal.)

From your server, copy c:\program files\Symantec AntiVirus\grc.dat to C:\Documents and Settings\All Users\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\ on your client. Within 20 seconds, that file will disappear (Magic!!) You Now need to copy over the correct root certificate. On the server, it lives in c:\Program Files\Symantec AntiVirus\pki\roots, and the name is a long string of numbers, followed by .servergroupca.cer. Note that this file may live underneath \SAV instead of \Symantec AntiVirus. Copy the file from the server to the same folder in the client (be is SAV or Symantec Antivirus)

Stop and restart the Symantec Anti-Virus service on the client. This forces the client to talk to the System Center Console (SSC). Your may not see the client immediately on your SSC, but should within a few minutes. You can check the last time a server talked to the client by using the Default Console View (under View -> Default Console View.)

The only variation I’ve had from these steps is that I have needed to stop and start the services to get the grc.dat file to disappear.

A fix for multiple Symantec AntiVirus x64 clients not updating correctly

Greg Cain — Tue, 12 Feb 2008 18:22:08 +0000

We had a major issue where Symantec Anti-Virus would not update some (but not all) 64 bit clients. To make a long story short, it ended up being corrupt files that had previously been downloaded by Live Update, and lived in the LiveUpdate directory on the server. To clear up the problem we had to…

In LiveUpdate Administration Utility ( v1.5.7.19 )

Tools – select “Clean Up Download Directory.”
Options – select “Retrieve new and previously downloaded updates.”

Go into your LiveUpdate folder and make sure all the files are gone (delete any that are still there.)

Back in the LiveUpdate Administration Utility click “Retrieve” on the top right corner.

Symantec AV CE 10 x64 Live Update debug mode

Greg Cain — Fri, 08 Feb 2008 17:53:14 +0000

To turn it on, change the key of Debug to REG_SZ of “all”. Make the field empty to turn it off. The key lives in

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\LANDesk\VirusProtect6\CurrentVersion\ProductControl

This will create the text file C:\Program Files (x86)\Symantec AntiVirus\vpdebug.log. When you start Live Update, a dos window will pop up. After you run Live Update, change the key from all to null (leaving an empty key.)