Computer could not be contacted

Hi,

You don't mention the OS of the endpoints you are trying to protect.  There are a few additional requirements for Windows 7 for example over XP.

Maybe this post will help you:

/search?q= 7013

If not:

/search?q= 3170

might give you a few things to try,

Regards,

Jak

The machines getting that error are Windows 7

HI,

If the posted links didn't shed any light on it and you've managed to protect some of your Windows 7 machines from SEC: I suspect this is a problem which I've been told will be addressed in SEC 4.7.  Apparently there is a new Microsoft API for creating scheduled tasks in the newer Windows operating systems but the older API as used by SEC should also work and it clearly has worked on a few of your Window 7 machines, so it's a bit mysterious as to know why some of the machines behave differently?  Are they different variants of Windows 7?

From what I know the scheduled job file gets created but then doesn't run.  Is this what you see?  

For example if you check the clients directory:

\windows\tasks\

and ensure it's clear of Sophos install job files and then protect the machine again from SEC, does the job file get created but doesn't run?  I would expect if you manually run it, it works?

If it creates the job file, at least you know the machine is set-up correctly to receive and create it and you myst be suffering this problem on the machines it doesn't run on.  If so, for the short term I would suggest taking the deployment string by copying it from the job file and run it on the remaining machines either using: AD start-up scripts, maybe login scripts if the users have admin rights, PSEXEC to remotely deploy or another application you might have such as SMS to run the command.

As it should be a one time task hopefully you haven't got many machines with this problem at least until SEC 4,7.

Regards,

Jak

Well, I had an XP machine do it this morning. I'm going to look over the articles you posted again, and see if I missed something.

I had an XP Pro SP3 machine give me a 0000003b error code this morning. In the Sophos knowledgebase (http://www.sophos.com/support/knowledgebase/article/16307.html) it seemed to group the 0000002e message with this one, so my fix might help you. Sorry if it doesn't! I only had to carry this out on a single machine, but you should at least be able to check user access rights through AD.

1.       On the client machine, open Local security settings by going to Control Panel > Administrative Tools

2.       Expand Local policies > User rights management

3.       Double-click the setting Access this computer from the network and add the account that you have been using to deploy installations remotely (most likely your network admin account)

Once I did that, I tried to protect the computer again through the Enterprise console and it came back with a different error. This time it couldn't see the shared folder on the machine that it was trying to contact. I then went back to the client machine and made sure the local disk had an administrative share:

1.       Right-click the local disk (normally C: drive) and click Properties

2.       Click Sharing

3.       Create a share with the name c$ and give the administrative account you've been using full permissions to this share

I then went back to the console to protect the computer and it worked.

make sure Remote Registry Service is running:

http://support.gfi.com/manuals/en/esm7/esm7manual-1-100.html

After having this same issue with a number of XP computers, I found the following solved it once all the other recommended steps had been completed: Change the scope of the File And Print Sharing port 445 to allow all computers.

Once changed, the new install went through without issue. You can then change the scope back if you like and it does not effect the computer's ability to update or to contact the server as far as I can tell.