Norton1 LiveUpdate server complaints

LiveUpdate complaints from the end-users… cannot run LiveUpdate, LiveUpdate logs indicate a specific file was “unavailable on the server”.

FTP into does reveal that the file is not actually there. The quick fix here is to resynch the LiveUpdate directory from SYmantec. To do this:

  1. On Norton1, Launch “LiveUpdate Administration Utility”.
  2. Go to Tools>Options, then select “Retrieve new and previously downloaded updates”, then “ok”.
  3. Click “retrieve”, wait for the process to complete.
  4. Change the previously set option back to “New updates only”.

Now test out LiveUpdate to see if the missing file has been restored.

Frank's Deep Thought of the Day

Men die earlier than women because they want to.

Changing WX Client Modes

WebXtender has two modes: Interactive (IRC), or “Thin Client”. Interactive requires IE 6 with ActiveX controls, wheras “Thin” does not, but has fewer features.

To set the mode for users, you must enter the “User Profile Administrator” program that installs with XS Admin. You can change the global default, and/or the default for specific users (but not for Groups???!!!). Without further configuration, this option becomes fixed, and the user cannot change it.

However, in App Gen (part of a Full ApplicationXtender install), you can set a global option per-user or per-group called “Configure WS”. Once set, this allows the user to change ALL WebXtender user-configurable options, including the client mode.

Note: Setting this option in AppGen does not enable it for the user automatically! You must restart the WX service in order for the change to take effect! AARGH! (Recommended approach is to run the “Component Setup Wizard” which ships with XS Admin).

Oracle Instant Client, continued

To simplify installation of the OC, I wrapped the files into a MSI using “Advanced Installer” v2.6.4 from Caphyon Software.

To accomplish this, I just needed to follow the previously documented manual installation routine, and take note of what changed on the system (specifically, I had a look at the REG text files generated by the ODBC installation script).
Advanced Installer lets to specify source files from ANY location, to be installed to a specified Program Files target. You also can specify Environment variables and Registry settings that you want performed during the install.

I just shipped the Install Directory to “University of Vermont\Oracle 10g Client”, and added an “admin” subdirectory for the TNSNAMES.ORA file. Then I set the PATH, SQLPath, and TNS_Admin environment variables. Finally, I specified the required ODBC registry changes, and built the MSI.

Since doing the build, a new version of OC 10g Instant Client has become available (v10.1.0.4). I have updated the installer to use these files instead. Making this change is fairly simple. All you have to do is open the original Adv Installer package specification file (.AIP), take note of the location of the source files, then drop the updated files into that location. If there are any new files, or files that are no longer present, you need to update the AIP to reflect these changes. Change the package version number, then rebuild… easy.

Packaging ApplicationXtender

After some fine head-banging, I have figured out how to package the ApplicationXtender 5.25 .MSP (patch) file into the original 5.20 installer. We just need to follow the standard “administrative installation point” routine:

  1. At the command line, go to the AX 5.20 installation directory.
  2. Run
    msiexec /a AxSetup.msi TARGETDIR=[working directory]
  3. Assuming the MSP file is in the same directory, run
    "msiexec /p /a [working directory]\AxSetup.msi"
  4. Now just zip the working directory into a single file.

We do have some other options that may help with deployment:

  1. The “XSCM.Config” file from “\Documents and Settings\All Users” into the final archive directory, along with a script that drops this file into place on the target system. This will save installation staff the need to locate the setup file on first run of the application
  2. The install directory can be added to a self-extracting zip, which calls the SETUP.EXE.
  3. SETUP.EXE has command-line support, documented in the AX Installation guide. Essentially, we would run
    SETUP MsiExec.exe /i "AxSetup.msi" /QB INSTALLLEVEL=[install_level]
    where [install_level] is a number from 1 to 3. 1=Retrieval install, 2=Scan, and 3=admin install.

SAV 10.0.1 – building client installers

Symantec just extended us the honor of downloading SAV v10.0.1 (Maintenance Release 1 for SAV 10). This build is supposed to fix a bunch of performance complaints. Now that we have it, I suppose we should think in earnest about getting clients to install the new version.

I have been concerned about the apparent need to provide two installers… one for upgrades, and one for new installations. This is an issue that came up with SAV 9, mp2. Fortunately, I was able to find a decent thread on installation techniques at Novell “Cool Solutions”:

I have changed our installed to run the installer using “setup.exe” (an install shield program), instead of “msiexec”. When using setup.exe, the installer appear to deal well with existing installations.

I have also added an additional .bat to the installer script… RemoveStartupScan.bat. This runs “reg.exe” to import a .reg file obtained from Symantec. The reg settings included disable the startup “quick scan” (DoScan.exe) that has been irritating Symantec clients since the release of 10.0. Symantec says that DoScan has been “fixed” with 10.0.1, but I still do not like it.

Finally, I am allowing installation of the Pop3Smtp component, although I suspect that we will just have to rip it out again in the near future. I thought we might give it a chance for now.

Filesystem reports

Doug asked me to let him know how many Lotus Approach DBF and APR files are present on our file servers at present. He was hoping that the report might be something that he could “save to file”.

After a lot of mucking around with gnuwin32 tools, I decided that the best “quick fix” was to do the following. The Windows Server Recource Kit is required:

  1. As someone with read access to the entire filesystem, run:
    dir /s /t:c \\files\shared | qgrep /y -E “.dbf .apr” > dbreport.txt
    alternatively, one could use the gnu “ls” command to get similar output in a slightly ritcher format.
    the /t:c switch forces dir to display the last-changed timestamp rather than the default last-accessed. The /y performs a case insensitive grep. -E parses results on the end of the line only.
    note as a fun side project, I had to disable viewing of the ~snapshot directories on our NetApp filer while the query was running, as the dir command insisted on parsing through all of the snapshot directories. Aargh!
  2. next, I import the txt file into excel. I used the “Data->Filter->Advanced Filter” menu to mask the many duplicate records in the sheet, then past the filtered view into a new sheet.
  3. To get a better grip on the actual number of production Approach databases, I saved the filtered sheet to a new text file then ran the following command:
    type dbreport-filt.txt | qgrep -y -E “.apr” > dbreport-apronly.txt
    this generates a list of only the *.apr records in the file. I then re-import into a new Excel sheet. All three sheets have been shipped off to Doug for digestion.

Doug has asked for a new report. I thought I would try doing it with “POWERSHELL” this time:

gci \\files\shared -recurse -include *.apr,*.mdb -exclude ~snap* | Select-Object LastWriteTime,Length,Name | export-csv dbhunt.csv

We are using the “get-childobject” (alias “dir” or “gci”) to get a recursive (-recurse) directory listing of \\files\shared. We are excluding those pesky ~snapshot directories (-exclude ~snap*), and filtering for only APR and DBF files (-include *.apr,*.mdb – (NOTE: I got the expression via trial-and-error… I cannot find a good reference on PowerShell regular expressions and wild card matching. I would have thought “$\.apr|$\.dbf” would work, but it did not.)). We the pipe (|) to select-object and choose only the LastWriteTime, Length, and Name attributes of the listed files. Finally we pipe to “export-csv” to sent the search results to a csv file.

I am using the PowerShell 1.0 RC1 refresh for this report. Note that I am able to catch both APR and MDB file types in a single pass, and also I am able to filter the output to include only the attributes that I want. Finally, I can export directly to a CSV file for import into a spreadsheet. I suppose I could also have used the “sort” features in the pipeline to segregate the APR and MDB files to the top and bottom of the output file, but I will just do that in the spreadsheet. Another sort option would be to “remove duplicates”, but this could result in some data loss as many DBs may have the same name, but with different content. Somthing I could not figure out how to do in the time available how to auto-format the “Length” data in Megabytes… I know I saw this in a PowerShell demo, but I cannot find my notes, and I can’t glean this from the online documentation).

Ooh! Even better:
gci \\files\shared -recurse -include *.apr,*.dbf,*.mdb -exclude ~snap* | Select-Object DirectoryName,Name,Extension,Length,CreationTime,LastWriteTime | sort DirectoryName | Export-Csv \\files\flex1$\qtree-home10\d\dsv\winhome\dbhunt.csv

In this pass, I have added additional properties to the “select-object” command which I want exported to my CSV report. These properties are the “DirectoryPath” to the file, in addition to it’s creation time. Also, I have a separate field for “extension” to ease in reporting later on. I also have added a “sort” command to the pipeline so that the output file will already be sorted by DirectoryName.

I think this will take about 3 hours to run, so I am just going to dump the report straight to Doug’s home directory. Huzzah!

SAV10 migration steps

Starting the SAV10 server infrastructure process…

  1. Download and install LU Admin v1.5.4, required to fetch SAV10 updates for our internal LiveUpdate FTP server. Installed over existing version, purged and re-downloaded alll current SAV/NAV related files, and also updates for Symantec products commonly used at UVM. note: needed to set the LU Admin tool to “download previously retrieved updates” during the initial download… otherwise it refuses to get new definitions!
  2. Uninstall Quarantine, Quarantine Console, and Symantec System Center on Norton1, Norton2.
  3. Attempt to run SAV installer by running setup.exe at the root of the SAV10 CD… setup appears to run, but all it actually does is remove files from the server! Aargh! Attempt to use the “Server Deployment” tool to push updates to Norton1 and Norton2… the wizard forces me to re-create the “UVM Antivirus 1″ group, and to specify a username/password for the group… I do this. The wizard then copies installer files to the hosts, and then hangs for half an hour. I am forced to cancel the installation.
  4. reboot both systems, then attempt to run the regualr installer again. This time, the installer works (although SAV is now installed in the default “%systemdrive%\program files\Symantec AntiVirus” folder, instead of the original folder from the SAV 9 install. Hmmm….
  5. install Central Quarantine on Norton1. Install system center and quarantine console on norton1 and norton2
  6. Upon launching SSC, there are now two “UVM AntiVirus 1″ groups, each with one of the NORTON parent servers. The group with NORTON1 is non-functional, as it reports that NORTON1 is DOWN (even though Norton1 appears to be running all of its Symantec services). Aargh!
  7. Fix hangs when attempting to view NORTON1 history files by archiving old (and probably corrupt log files. To do this, I stop the SAV service, then remove all files from c:\documents and settings\all users\application data\symantec\symantec antivirus corporate edition\7.5\logs.
  8. SSC listing of NORTON1 system status as “down” could be the result of server overload… see symantec KB article:

    nope… that did not help at all…

  9. called Symantec tech support. They speculated that the upgrade of the “UVM AntiVirus 1″ server group was botched. The workaround was to first move the functioning “Norton2″ server to a new, separate server group. Next, we remove the HKLM\software\intel\landesk\virusprotect6\domaindata registry key (after backing up the registry). This effectively lobotomizes Norton1, and makes it forget that it is the primary server in the AV group. After a reboot, the UVM AV 1 group is again accessible via SSC. We re-promote NORTON1 to primary server of the group, and move Norton2 back in. Our AV group policies are totally shot, so I need to rebuild all policies. Joy.
  10. Scheduled tasks on the operating systems have stopped running. Reason is that path to .exe files changed with the upgrade. I have updated all of the executable paths.
  11. Roaming services have been implemented… this will allow SAV 9+ clients to load balance between NORTON1 and NORTON2 parent servers.
  12. Important SAV10 server settings… new feature is “performance tuning”… I needed to activate management of back-level SAV clients. Also, I set options to skip over clients that are not checking in with the parent server. This will allow faster push of updated definitions as they become avialable.

Norton1 – service crash… fixes and post-crash changes

Norton1 shut itself off late last week. Stefanie had a look at it and managed to get it back on it’s feet:

  • SYSTEM volume was almot full on Norton1. Stef found scads of MSFTPSVC log files and deleted them.
  • SAV service would not restart… apparently due to corrupt virus definitions. Repaired by following advice at Symantec KB:
  • We set the IIS service to keep it’s logs on the D: (vol1) drive instead of SYSTEM. Geoff will work on a script to purge logs >1 week old
  • We set the FTP service idle connection timeout from 900 seconds to 120 seconds to cut down on hacker locking FTP service connections.

RESOLVED that we need to look at changes to services on Norton1/2:

  • auto purging to old quarantine files
  • auto purging of AV service events for faster loading of log viewers
  • load balancing of client across Norton1/2 for better performance/reliability
  • potential benefits of upgrade to SAV 10.0

Legato License Service: RPC Port

I wonder if port of the problem I have been having connecting to the AX applications on IMGX owing to some sort of Firewall problem.

The only service that has been installed on any of the imaging servers that appears to be of any potential relevance is the “Legato Licensing Server” on DOCIMG1. Netstat -ano reveals that this service is listening at port 9152… this port is not available through the internal firewall.

I will switch this server to port 6252 (currently port of the 100-port range for RPC’s made available through our internal firewall). This setting is made in the registry at:
HKLM:\SOFTWARE\Legato\License Server\RPC\
REG_SZ Value: TcpIpEndPoint
After restarting the service and running another Netstat -ano, I now see that the license service is listening at port 6252. Yeah!

Update: Last week our WX instance broke… EMC support blames this on the port change. I have reverted to port 9152, and will need to get this exempted on the firewall.