Today, I was troubleshooting a problem with Symantec Antivirus. Specifically, I was trying to stop a monthly scan that had been running for more than 24 hours, and was having an issue with quarantined items in the “xfer” folder.

My problem: Even though the scan settings were configured to allow me to stop/pause/snooze scans, I could not find a method of doing so. The Scan Progress dialog was not up, and I could not bring it up using the product GUI.

I tried using the “/admin” switch to connect to the server in question, I did not see the scan dialog on the screen as expected.

However, since this was a virtual server, I tried another angle. I used the VMware Infrastructure Client to look at the ACTUAL DESKTOP of the server, which was not logged in.

When it logged in, it showed me the scan dialog and I was able to stop/pause/snooze the scan.

Curious, and wanting to understand more about what happened, I then connected again with the /admin switch, without having logged off of the actual desktop. It locked the desktop I was looking at in the VI Client, and it showed me the scan dialog.

So I have learned something new about RDP today. Session 0, or “the console session” is NOT actually quite the same thing as the actual desktop of the server. If the actual desktop is logged off, you don’t get things, even with the /admin switch, that you do when “standing in front of the server” or viewing the console with VMware Infrastructure Client.

I’ll have to file this one away for future reference. When wanting to make sure I catch console pop-ups, make sure the actual, real desktop of the server is logged on if possible.

Tags: /admin, /console, desktop, RDP

You can configure a setting called “SCL” (Spam Confidence Level) in the SMSMSE console. This corresponds to a setting in the Intelligent Message Filter in MS Exchange System Manager. Using these two settings, you can more finely control which messages get sent to the Junk E-mail folder based on Symantec’s rating of the message.

Changing the Store Action Threshold in Symantec Mail Security for Microsoft Exchange:
Grabbed from here.

Question/Issue:
This page describes how to control the Store Action Threshold (SAT) in Microsoft Exchange 2003. The SAT works with the Spam Confidence Level (SCL) that you specify in Symantec Mail Security for Microsoft Exchange to determine which messages are sent to the users’ Junk E-mail folders. By default, the SAT value is null. The null SAT forces all messages with an SCL value of 1 or greater to the user’s Junk E-Mail folder. You installed one of the following versions: -Symantec Mail Security 4.6 for Microsoft Exchange -Symantec Mail Security 4.5 for Microsoft Exchange -Symantec Mail Security 5.0 for Microsoft Exchange
Solution:
To change the Store Action Threshold

In the Exchange System Manager window, in the left pane, under Global Settings, right-click Message Delivery -> Properties.
In the Properties dialog box, on the Intelligent Message Filtering tab, on the Store Junk E-mail Configuration drop-down list, click the appropriate level.
Click OK.
Close the Exchange System Manager window.
——————————————————————————–
Note: You cannot set the store threshold higher than the gateway threshold.

After you have configured the global settings in the Message Delivery area, you need to enable Intelligent Message Filtering on the Default SMTP Virtual Server properties. Intelligent Message Filtering is installed by default as part of Exchange SP2, but it is not enabled. To enable it:

In the Default SMTP Virtual Server properties, on the General tab, click Advanced.
Select the IP address (or “All Unassigned” and click the Edit button.
Check the box for “Apply Intelligent Message Filter” and click OK.

If you want to verify the SCL rating on a message in Outlook, here is how to do it. This article was written for Outlook 2003. It will probably work in 2007, but the menus will probably be different.

Tags: Exchange, Intelligent Message Filter, Junk E-mail, SCL, Spam, Symantec Mail Security

I am rolling out Symantec Endpoint Protection, and have noticed a strange situation. It is possible that my experiences are abnormal, and not reproducable, but I thought I would make myself a note about it anyway, and maybe it will help someone else having similar results.

I installed the SEP Management Console, and created two deployment packages – one for servers, and one for workstations. Then I went into the MC and set up policies, exceptions, assigned things, disabled things I didn’t want, etc.

When it was time for rollout, I logged into the first server (using mstsc /admin), browsed to the deployment package (single EXE), and ran it. It installed successfully, but the green dot never appeared on the yellow shield, indicating that it did not check in with the management console. I rebooted a couple of times, and then let it sit for 30 minutes. Nothing. Right-clicking on the shield did not reveal the “Update Policy” option that should be there on a managed client installation. 

The second server I did this on was the same OS and SP level, but it was set up for Terminal Services. This one installed, got the green dot, etc. All was good. The third one was very similar to the first, and had the same result – no green dot. I used the Deployment Wizard to push the installation to the remaining two servers, and that worked fine – the green dot appeared.

Going back to the first two servers, I uninstalled SEP, rebooted, and then pushed the client with the Deployment Wizard. Both servers installed successfully, green dot appeared.

I have not had these results on workstations. Workstations consistently seem to work properly, even when the setup is run manually.

I don’t know if this is a normal thing, or if Terminal Services had any impact on it regarding the server that did work with a manual install.

What I DO know is that there are a LOT of Google results for issues concerning servers not checking in with the console, and if there are answers out there, they are not easy to find. This worked for me. Maybe it will work for you.

Tags: Deployment Wizard, Green Dot, Symantec Endpoint Protection