Symantec has updated their secret decoder ring that deciphers version builds to version names. They have also begun including both in the endpoint client which is incredibly helpful when looking for matching upgrades. In the SEP 12.1 RTM build as well as prior versions the client reported the following type of version information:

In the latest releases of SEP 12.1, the version name is included with the version number (finally).

From the link below, this Symantec page tracks the name, version, and release date of every version of SEP since 2007. Find what build you’re on, where you need to go, download the upgrade bits.

SEP EE 12.1.x
Name	Version	Release date (English)
RTM	12.1.671.4971	Jul 2011
RU1	12.1.1000.157	Nov 2011
RU1 MP1	12.1.1101.401	May 2012

 

SEP Versions and names: Link

SEP upgrade binaries: Link

I had my first ever need to put a call into Symantec enterprise support for a SEP client that just would not install on one of my corporate Win7 desktops. This particular problem proved troublesome to figure out but with Symantec’s help we got there. I also learned a few other tricks along the way that will help with troubleshooting regular enterprise client installs.
After trying multiple installation methods that usually work, all we would get was an ultimate failure with “error status 1603” logged in the application events.
Looking through the SEP installer log in c:\windows\temp\sep_inst.txt, we noticed that the installer was failing to access the network location for %APPDATA%.
Hmmm, ok let’s check the registry and see what’s up. Navigate to HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. Notice how the value for AppData doesn’t look like the others? It should be prefixed with a %USERPROFILE% wildcard value but isn’t. The installer can’t find %APPDATA%.
This is the proper value that should be here:
The tech mentioned that they had this problem in Vista but had not seen it in 7. This particular user could be running some ancient software that changed this value, I really don’t know. This is the only box I’ve seen this happen on.
Another trick I learned along the way is how to get around the pesky reboot requirement before you can install the SEP client. To do this, simply delete the following items in the registry. Note the key paths at the bottom of each window:
Once the registry edits have been made you can rerun your client install without having to reboot. One other thing the tech had me do was export my enterprise install package to expose all the bits. This is done via the Endpoint Protection Manager Console. Navigate to your client install packages under Admin\ Install Packages, choose the package you want to export, right-click, choose export.
Select a location for the dump to go, UNcheck “create a single .EXE…”, choose your customized installation settings and features, then select the top level “my company”. The other defaults are fine. This will take a few minutes.
Once the export is complete you will see the contents of your deployment package. Install Live Update first (LUSETUP.exe) then run the installer MSI (Symantec AntiVirus.msi). This is the full non-silent yet customized client install so you can see every step. You AV client should now be installed with no problems.
References:
Symantec KB103109

(**Updated for SEP 12, see here: LINK**)

I’m a big fan of the SEP AV product but keeping up with which build number = which version description is a pain. Unfortunately you have to do this to keep the product updated as Symantec only references the version descriptions on their download site.  The client itself only references the build number. For example, build 11.0.6100.645 = Release Update 6a + Maintenance Patch 1 (RU6 MP1). So in order to update your client from 11.0.6005.562 to 11.0.6100.645 you would need to know that you are currently running Release Update 6a (RU6a) and need to update to RU6 MP1.

Maintenance Release 4 + Maintenance Patch 2 (MR4 MP2)
Client and Manager:
11.0.4202.75
Release Update 5 (RU5)
Client and Manager
11.0.5002.333
Release Update 6 (RU6)
11.0.6000.548 (Windows)
11.0.6000.0162 (Macintosh)
Release Update 6a (RU6a)
11.0.6005.562 (Windows only)
Release Update 6a + Maintenance Patch 1 (RU6 MP1)
11.0.6100.645 (Windows)
11.0.6100.0179 (Macintosh)

Additional links:
SEP patches and upgrades
SEP security updates (“DATs”)
SEP Intelligent Updater

In my previous anti-virus review for SEP11, I briefly touched on NOD32 and its underground fame among some IT enthusiasts on the web. Because NOD32 is an impressive personal scanner, I wanted to seriously consider ESET’s enterprise offering and possibly dethrone Symantec as my favorite enterprise AV solution. Through the use of numerous daily virus definition updates and a very aggressive heuristic scanning engine, NOD32 has managed to stay on top of the VB100 list by not missing any threats since 2002.

There are 3 installation components to the enterprise NOD offering: The NOD client, the ESET Remote Administrator Server (ERAS), and the admin console (ERAC). All 3 parts should be installed on the server to manage the environment, the console can be installed on an admin workstation for remote management. Component versions as tested are 4.x upgraded from 3. Licensing is per installed client enforced via a license file and ESET requires a username and password to pull virus definition updates from their servers. The client comes in both x86 and x64 flavors while the management components are x86 only. I had no trouble at all installing all components on Server 2008 R2.

When first launching the ERAC, it connects to the configured server on tcp/2223, by default, and asks for login credentials which can be optionally cached by the administrator.

At first glance the layout seems daunting.

The console can be customized in number of ways including column, color, and highlighting options for almost every piece of the layout. (Tools—>Console Options)

The next logical step is to configure virus definition updates and the other applicable global options. Under Tools—> Server Options, a number of things can be configured including passwords and access management for the ERAC, logging and DB maintenance, the update username/password and update interval, along with SMTP and optional upstream NOD server replication. As is the case with any enterprise technology, RTFM, but I really disliked the update setup requirements. The mandate of a username and password just to pull definitions is annoying and the “update mirror” setup used for definition storage is hardly intuitive. The mirror settings should come pre-defined in a base installation allowing further refinements if needed.

The performance statistics displayed on the General tab in Server Options is a nice touch albeit a bit out of place in a global configuration dialog.

Notification options seem robust and plentiful, at first glance. A number of pre-defined notification rules can be tweaked with HAS, HAS NOT, and IS types of filter parameters along with a number of wildcard fields that you can expose. Some of the default descriptions include wording that leaves much to be desired like “Primary clients with a non-cleaned infiltration during the last computer scan” instead of a much simpler “New threat detected.” Notifications also fall short in information richness. You can be notified that a “non-cleaned infiltration” was detected but you will have to log into the ERAC to find out exactly what that infiltration was. You cannot have the name of the detected threat included in the notification email.

We experienced a great deal of frustration surrounding alerting with this product. Server based alerting was slow and unpredictable at best leaving us to configure policies that enabled clients to send administrators SMTP alerts directly so we at least knew what was going on. Not good.

Policy management, again, seems very rich and robust, at first glance. NOD employs the traditional parent/child inheritance model making it easy to create and deploy child policies to specific machine categories such as department or function. Each policy can be edited/viewed individually or in a merged state to display the effect of parent policies.

Configuring policies themselves can be a daunting task with hundreds of stacked options available to you. While I would normally find this level of control of positive thing, it’s implementation here is very user UNfriendly. Although the search feature works fine here, trying to pinpoint and enable or disable a very specific behavior can be very challenging [and frustrating].

Another problematic behavior of this policy model is that it follows an append behavior by default. So any policy changes you make will simply be tacked on to the client’s existing policy, not changed or deleted. First level ESET support told us this was by design (bad) although level3 ESET support tells me there is a way to flag a policy item as delete so the client will remove it. Going back through the dialogs now I don’t see that option anywhere. If it exists it should have been made plainly clear in the Policy Manager console. Scanning profiles are used to control on-demand scans and configured via policies then deployed to clients. We had a hard time making these profiles “stick” after any policy change. We kept wondering why clients weren't running their weekly full scans, it was because the scanning profile dropped and the weekly's never kicked off!

The level of configurable policy detail is immense, but most notably lacking is the ability to modify a client’s Scheduler/Planner settings, namely startup scans. By default the NOD32 client will initiate a scan each time a user logs in (even workstation unlocks) and when the virus definitions are updated. The logic behind this is understandable which is to ensure maximum protection, but it comes at a hefty, and annoying, performance penalty. Add in the complete inability to centrally control and you have a very large annoyance. Tasks can be added to the Scheduler/Planner via Policy Manager but not deleted.

ThreatSense is the heuristic scanning engine that makes the product look good in virus tests and marketing materials but those of us in the trenches know good and well that this is a slippery slope. I always disable heuristic scanners because they are too difficult to control and often block perfectly legitimate applications from operating properly. ThreatSense is no exception. In our tests it seemed to haphazardly block legitimate operations even after allowing them to run a few times before, such as application deployment via our KBox. So much so that we started looking to NOD first when any application wasn’t functioning correctly. Settings for ThreatSense are controlled outside of the normal real-time AV rules. My advice, disable ThreatSense during the installation just like you would in any other AV product, the headache is not worth it!

Scheduled scans are also configured in policies (buried under ESET Kernel\Scheduler/Planner) but we found the execution to be sometimes unpredictable. Instead of firing at the specified times, these scans seemed to kick off when they wanted to even though they were expressly set.

Remote client installation from the server works well enough but clients reporting into the ERAC is somewhat unpredictable. The display is only updated periodically so it is hard to tell if a client is really out of date or disconnected just from looking at the console. Requests to update individual clients from the ERAC also seem to go by unanswered.

Other pain points include the lack of fine-tuned resource throttling for scans actively running on machines with other workloads. The NOD client will simply take as much of the CPU as it wants to even though the scanning profile is set to run background scans with low priority. All you can do is to stop the scan, which in and of itself is sometimes difficult to do. ESET touts it’s low resource utilization which may be true for real-time AV protection but I beg to differ on full scanning operations.

There is a lot to like with the NOD client itself, however. It is clean, un-intimidating, and tells you exactly what you need to know. It will even turn red in the system tray to warn you when new Windows updates are detected, overkill yes but it wants you to be secure.

The full advanced configuration dialog is accessible via the client in a much more condensed, clean and user-friendly form. It is very clear that ESET has spent a great deal of time and effort developing their client.

Working with this product for awhile now it is clear that ESET built a very good AV client then bolted an attempted enterprise management piece on top of it (ESET support confirmed this). In version 4 of the enterprise platform I expected much more, especially after upgrading from version 3. While clunky and very unrefined in spots, if you have the time to mess with it, this solution should work for very small environments, even though you will spend much more time here configuring and tweaking.

There are a few key points that make the enterprise solution a complete deal-breaker for me in its current state. Notification options/behavior, predictable manageability, and policy behavior are bad enough, in my opinion, that I cannot recommend the product. In my conversation with ESET’s level 3 support, he acknowledged many of my concerns and remarked that the development group that works on the enterprise piece is not exactly steeped in what a real enterprise requires, being a very small dev shop themselves. Would I run NOD32 at home? Sure, but that is where my recommendation ends. For your SMB+ sized enterprise you would be much better served implementing a tried and true solution built for the enterprise market.

According to most industry comparative sources, two of the top 10 enterprise antivirus products are EndPoint Protection by Symantec (SEP) and NOD32 by Eset. These products often occupy the top two positions, again depending on your source. Av-comparatives.org gave its product of the year award to Symantec for 2009 and NOD32 has earned back-to-back VB100 awards since 2002. Personally, I have been well protected using SEP, formerly SAVCE (Symantec Antivirus Corporate Edition), for over a decade but am always open to better solutions if they exist. NOD32 is well-known on the internet by PC-enthusiasts as a purportedly bullet-proof AV scanner, so the enterprise solution must be as equally impressive right? I decided to find out. Having recently gone through a new enterprise antivirus rollout, I thoroughly vetted Nod32 v4 and SEP 11. I’ll share my review of NOD32 for the enterprise in another posting.

First up the incumbent, SEP, which has seen many changes since the days I first started using SAVCE, back when client management was NetBIOS dependent. AD-integration is now seamless, Server 2008 R2/ Windows 7 are fully supported, and the legacy requirements of WINS are long gone. Installation of the the management server piece is still as easy as it was years ago, all controlled from a single media source where the client bits also live. Setup allows you to launch the server or client installs from the installation media. Simple.

The SEP manager component is web-based now with a Java front end so you will need to install the JRE on your server. The manager runs happily in IIS which will be configured for you during setup, assuming you have the role and requisite services installed.

 

By default the server is setup to use tcp/8443 for the server port and tcp/9090 for the web console port. 8443 is what is used when logging into the manager console itself while 9090 hosts links and the download for the Manager console.

Once logged in, you are immediately presented with a well laid out dashboard that includes risk detections, client definition status, as well as the current Symantec ThreatCon level and links to pertinent info.

Let’s start at the bottom with the Admin tab and work up. Here you choose which components to work with, assigning admin rights, domain and server management, and manipulation of installation packages. In the domains section, by default, there is only a single domain defined called Default. Any deployment packages you created during the server install will assign clients here. You can manage multiple domains if you have a disparate environment but if not I recommend you disable the Default domain and add your own right away. To switch between domains you need to select the domain at the top and click the Administer Domain button down below. Now only the clients and policies assigned to the active domain will be displayed under those tabs. If you need to move clients between management domains at some point you can either uninstall/reinstall the client that points to the correct domain, or run the sylink drop tool which can move an existing client from one domain to another. If you use AD-integration your clients will show up only in their real OUs on the Clients tab.

 

Also within the Admin tab you can set the console administrators, control SEP server options like mail and directory servers, and create client install packages. Install packages consist of 3 main parts:

• the base client package itself (x86/ x64)
• Install settings: silent or interactive installation, upgrade settings
• Install feature set: which components of the client to actually install

Once the install settings and feature sets are defined, custom clients can be pushed from the console or migration wizard, or exported from the install packages screen.

On the clients tab you will see any non-AD SEP folders you created as well as the currently active domain under My Company. The functionality here is logical but not as useful as it could be. There is no consolidated client view here, you have to drill down into each OU to see your clients or run a “search clients” operation to pull the entire list broken out into several pages. Green bubbles mean that a client is online and communicating with the server. Important to note is that if a client is a member of the actively managed domain, it cannot live outside this structure in a non-AD SEP group.

The policies client tab show everything active for a given container. Here you can see that all policies are inherited and which are currently applied to this OU.

Important to note here is the “Communications Settings” button whose contents are inherited from the parent My Company. At the parent level you can change the method in which clients communicate with the server. By default Push mode is used which keeps an open channel between clients and the management server so that policy changes can be quickly propagated. Running a netstat –an on the management server will reveal every open TCP session to all connected clients.

The policies tab provides access to control policies for all installed components in your client. Multiple policies can be created and assigned at different levels either to local SEP groups or OUs in your AD. LiveUpdate is set to run on the management server every 4 hours by default but make sure to assign a LU policy to your clients.

All fields in each component of the client can be clearly and easily set in a policy along with line item lockout so the item can’t be changed by the end-user. This is extremely straight forward, as it should be.

Centralized exceptions can be set either through administrative policy or as user-defined. We obviously don’t want users excluding potentially unsafe items so you can lock them out from this. In previous builds of SEP you could open the AV client on a user’s PC and see the admin-defined exceptions but this has since been removed, by customer request according to Symantec. You have to look at the policy serials numbers, as reported by your clients, and trust that these exceptions are making it in as all that is visible from the client is the user defined exceptions.

Reporting is robust, beautiful and can be created ad-hoc or on scheduled a basis. Detailed break-outs of risks, compliance, and status (among others) are all available.

 

 

Environment monitoring is further detailed in the Monitors tab which provides summary pie charts, access to logs, the status of any commands issued in the console,  and notification options. Every condition you would expect to want to be notified about is available and configurable here.

Add-on security components like firewalls and heuristic scanning usually result in problems so I don’t install anything but anti-virus and malware protection in my environments. There are posts all over the internet of people looking for help on how to remove these products and clean up from their aftermath.

All things considered I give SEP 11 a solid 9 for the enterprise. It works exactly how I expect my corporate AV solution to. Despite a few configuration items being somewhat hard to find and buried in the GUI, the functionality is fantastic and features a true “set it and forget it” type of system. The architecture features classic web and data tiers for management and a full featured client capable of much more than I will use it for. Client management, reporting and alerting are robust which are absolute requirements. It would be nice if there was a consolidated client view that displays all clients and their status regardless of which OU they live in. Currently you have to either drill into each OU or run a search. Either way is functional but undesirable. It would also be nice to be able to optionally view administratively-defined centralized exceptions on the clients themselves.