Well, it has been a fun week of migrating our Symantec AntiVirus servers from old, dying Dell 5th-gen PowerEdge servers onto bleeding-edge ESX virtual machines. Here are some of the highlights:
In moving the servers, we had to assign new IP addresses in our protected 102.0 subnet. Thus, I had to research the firewall exceptions required for access to the servers. It seems the two required ports are:
TCP port 2967 (Inboud) – for Symantec AntiVirus service (RtVscan.exe), for AV definition push updates, and client monitoring
UDP port 38293 (Inbound) – for Intel PDS service (pds.exe), allows retrieval of AV policy settings
(initial rules were not correct, resulting in clients falling out of the mangement cycle)
I have been wanting to change the address of our internal LiveUpdate server for awhile… we are now using http://liveupdate.uvm.edu as the primary distribution server, with http://norton1.uvm.edu, http://norton2.uvm.edu, and http://liveupdate.symantecliveupdate.com as backups. “liveupdate.uvm.edu” is a round-robin record that alternates between norton1 and norton2. We are considering a load balancing implementation instead, but this probably is unnecessary given the presence of “backup servers” in the liveupdate.hst file distributed to clients.
The only real problem here was that many of the file types in the LiveUpdate download directory were not of recognized “MIME Types” (i.e. they were not html, xml, zip, txt, audio/video, or MS Office files). I had to add the following extensions to the IIS configs before clients could successfully retrieve updates:
.x00, .ieg, .m25, .ia64ap, .x86, .lin
Once these MIME types were added and I had run an “iisreset”, LiveUpdate started to function normally.
Migration of reporting services is a total PIA. I am trying to migrate the back-end database to an external SQL 2005 server from SQL 2000 in addition to re-installing the Reporting Services binaries on the new Norton2 server. Here are the steps taken so far:
- detach the SymReport database from the old server, copy the files to the new server and attach
- change ownership of the database back to its original setting
- change the compatibility level of the database to “9.0″ (SQL 2005)
- install the new SQL native client on the SAV hosts
- launch the Reporting services installer setup.exe. Note: do not launch from the autorun setup menu on the SAV CD! You must use the reporting services setup.exe or the advanced install options that we need will not be available.
- supply the credentials necessary to connect to the new SQL 2005 DB. Also, specify alternative credentials for the db user, datasource name, and db name. Use the DB name that was imported into the SQL 2005 server, and get the username that was previously used from the DB security tabs.
- After install, the reporting server should smoothly reconnect to the existing DB. You can check that this is happening in the SQL activity monitor pane.
Unfortunately, ran into some problems with the Reporting Agent on the primary SAV server (it is running a remote agent). The agent slowly hogs up all the memory on the box and is creating a CPU-bound condition (very bad news on an ESX host). I has no success trying to troubleshoot the situation, and I was not having fun… Using sysinternal tools I was able to watch the ReportingAgentLauncher thrash the heck out of some temp files that it was creating, but it never did anything with these files. I believe there must have been some bad configuration information being fed to the SAV server from the reporting database, and that this was creating a loop. So untimately I fixed the situation with the following “solution”:
- Uninstall reporting services
- Reinstall with a new database (thus abandoning old report data)
Voila… reporting services are running normall, we have our first production SQL 2005 database, and our second set of production ESX guests.