Sophos Support

6_21_05

Can't install sophos on some win9X computers

Error Message :
Exception Caught infindIDEfiles ()
MD5calc Crypto;: MDscalcCrypto() Failed to aqire cry to Context

Fix

delete the contents of the win9X folder and under the central installation folder right click on the coresponding folder and update cid checksum all files.

Please quote [SEW-UAPR-KLKH] in the subject line of any further
correspondence related to this query.
Error 1327 - SAV/RMS Failing to install via Sophos
AutoUpdate/Deploy failing - explanation and test

This article is designed to test why the install is failing,
what follows is a short explanation of the install/deploy
process for SAV5/RMS/SAU and an explanation of why we suspect
the install/deploy/update is failing
(Please note if SAU is failing to install due to error 1327 then
a similar approach is needed but the explanation is different.)

Outline:

Sophos AutoUpdate (SAU) is installed on a target machine by a
particular user, this user will be an administrator of the
machine in most cases.
Once SAU is installed it then downloads the relevent components
to its local cache (autoupdate\cache\)
If this process completes the install phase is intiiated, the
install will be run as SYSTEM, ie not a logged on user

Explanation of Error 1327:
Part of the MSI installation process for SAV/RMS checks for
system variables, if any of these cannot be found the install
will fail with the error, closer examination of the Sophos
Anti-Virus Install Log.txt will show which variable this failed
on.
The error may be in the EventLog, it may be in the AutoUpdate
log or it may pop up on the screen, in any case the text will be
similar to the following:
Error 1327.Invalid Drive: J:\
This means that SYSTEM was attempting to read from drive J and
failed as J does not exist.



Test to see if this is the case:

To test if this is the case it is possible to map the missing
drive for the SYSTEM user,
--- PLEASE ONLY USE THIS AS A TEST, DO NOT ENCOURAGE CUSTOMERS
TO MAP DRIVES FOR SYSTEM AS A PERMANENT SOLUTION ---

Step 1 Create a share for the drive to map to:
Create a folder on the local machine called SOPHTEMP
Share folder on local machine as SOPHTEMP
(you can use any name I just added one here for completeness of
the guide)

Step 2 Create a batch file to map the drive:
Create a new text file and add the following two lines to it:
net use DRIVELETTER: \\COMPUTERNAME\SOPHTEMP
net use >> C:\SOPHLOG.TXT
Save this file as "mapsoph.bat"
(Ensure file is saved with .bat extension to make it executable)

E.g. if Drive J is the drive you wish to map to do the following:
net use J: \\COMPUTERNAME\SOPHTEMP
net use >> C:\SOPHLOG.TXT

Step 3 Using the batch file to map the drive for SYSTEM via a
scheduled task
Run the following from a command prompt
at TIME "Path to batch file"
eg: at 09:05 c:\mapsoph.bat
(The time should be set for asap, usually a minute or two in the
future, when the task runs a file call SOPHLOG.TXT should be
created in the route of C).
Open the file SOPHLOG.TXT, you should see the output of the net
use command which shows the drive letter is mapped succesfully.

Step 4 Run an update to test if this is the case
Now run another update, if any errors are encountered check
again if they are Error 1327, I suspect they will not be, most
of the time SAV and RMS will install at this point.

What next?

Okay so we have proven that the problem was due to the above,
but the next stage is ascertaining why SYSTEM is looking for the
particular drive letter.
This problem is likely to be seen when the customer has user
profiles that are not held locally and that a policy/registry
entry/something else is telling the operating system to search
for the shell folders at the mapped letter.    The next stage is
for the customer to understand why System is not finding

Where to look:
Open up the succesful installation log of Sophos Anti-Virus
(Generally in C:\%WINDIR%\temp) and search for DRIVELETTER:\,
e.g if drive was J, search for J:\
You can also search the registry for the same, if there are
entries in the registry they will likely be in the shell
folders, see here:


A quick "worth a try" suggestion that has helped me before:

1. Find or browse to the following pairs of locations:
(you can find them by searching the customer's registry for "
nethood ". The hits below are relevant, the other hits you can
ignore)

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explo
rer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explo
rer\User Shell Folders

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Exp
lorer\Shell Folders
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Exp
lorer\User Shell Folders

HKEY_USERS\S-1-5-21-1574557677-3491378025-665780942-7913\Software
\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_USERS\S-1-5-21-1574557677-3491378025-665780942-7913\Software
\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

2. Look at the surrounding entries for standard folders (such as
my documents) to see if they list the "abnormal" location
causing the msi to fail
3. If a remote location is given, explain to the customer that
this is likely to be the cause of the error. Ask the customer if
they know of a reason why the mapping is as it is (e.g. did they
make a group policy specifying it, and if so, why?). Take the
usual care before editing the registry (i.e. backing it up) if
you and the customer agree that's what is best to do.
4. Continue searching the registry (hit F3) as there are other
similar sections after the first instance.