Administrator cannot update [Resolved]

[Guest]

[vjk]

v4.23 (and v4.22)  Win2K + NOD32 + SpywareBlaster+Sygate v5.5
BOClean announces:

"ERROR!!!  UNAVAILABLE! Check connection or firewall settings, site might be down." or 
"ERROR!!!  NOT connected. Check connection or firewall settings."

- when in fact it should be checking for and downloading an update. This is an old issue that goes back to October of 2006. When a manual update is attempted - 4.23 throws the analogous Comodo branded error message.

As far as I can tell, neither is a valid error message, as the program never attempts to connect - which can be verified by the firewall logs. At the same time, you can download psc-exam.exe from ftp://ftp.nsclean.com/pub/psc-exam.exe - so FTP is not being blocked. Sygate does not have the application blocked or a rule in place to prevent access.

If connected as a user - there are no issues. Checks and updates both via autoupdater and manually via the tray menu. You can browse the net with Firefox 2.0.0.4. regardless of user name.

This makes working as administrator to reconfigure or update a box extremely difficult, as BOClean pegs the CPU at 100% as it tries and fails to make a connection, which effectively makes the box unusable until BOClean releases the CPU.

Help in resolving this would be nice.

[Jbob]

Fwiw if I block the BOC updater(4.23) at my firewall(ZA) I get this message:

"ERROR!!!  NOT connected. Check connection or firewall settings."   so that appears to be a valid message.

I'll repeat here basically what I said over at Securecomp, try another Admin profile and not just the default Administrator profile created during the Win2K install.  Although you didn't mention Win2K in this post.  And just for grins I'd try it by turning off Sygate.

[Little Mac]

Comodo uses different servers, and at points it may update via a different address.  If you have set the IP to a specific one in your firewall (and note, 4.23 is not from the old nsclean servers, but I believe 4.22 still is), this may play into it, and it is just happenstance that it does this when the Admin logs in.  Not saying that's it, but it's something to keep in mind.

LM

[Jbob]

LM  The OPs issue is not one of not being able to update but updating while logged in as Administrator.  The update works ok as a User but not while logged in as Admin.      

[Little Mac]

I saw that, Jbob.    Other users have reported similar issues; some apparently have come from directing the application to a single set IP in their FW; sometimes it would be blocked, sometimes it wouldn't.  Would probably be too much coincidence in this case, but you never know...

Also, vjk, You may want to post in this thread to let Kevin know http://forums.comodo.com/index.php/topic,8915.0.html in case he needs/wants some other info from you.  He's requested all "odd" things be reported to him there so he can just keep an eye on one single thread...

LM

[Jbob]

That's interesting about the single set IP.  Incidentally the OP has posted on another forum that creating a new Admin profile has solved the update issue.  Of course that doesn't answer why it is the default Admin profile that has the issue.  Maybe this will be another clue for those that are having updating issues.

I'm wondering Sygate?

[Little Mac]

I should probably clarify about the IP thing... I don't mean sometimes the FW blocks the IP and sometimes it doesn't.  I mean that sometimes the update server is that IP and sometimes it's a different one.

Comodo confirms that they are using a number of different servers and hosting companies due to the volume against their system (ain't public demand great?), and frequently drop various ones from rotation.  They advised against users setting a single address for updates, as it may not be "live" at any given time.

The DNS records for the servers are in the format:
<continent><number>.download.comodo.com
Ex: eu1.download.comodo.com

  They went on to say that thus, using download.comodo.com will guarantee a live, local server.

So that's what I'm getting at.  Glad that creating a new Admin account resolved the issue; it would be good for Kevin to know, so that can be taken into account (if it's an issue he's not aware of).

LM

[vjk]

The new user with administrator rights did *not* resolve any issue - it's a work-around and nothing more.
It simply shows that the problem is that BOClean cannot deal with the *default* user in Win2K and that changing the configuration of the default Administrator account can stop BOClean from updating itself. No update - no protection. It aint rocket science and it aint Sygate even if you really really want it to be.

[~cat~]

Sounded to me like the image you're restoring from may have issues, a corrupted admin account perhaps?
Try it with a fresh install from a MS disk and see.

[vjk]

Sounds to me like corruption is a real stretch.

First off, you have 3 machines for which autoupdate does not work - period - and all three exhibit slightly different symptoms for the manual update. On one of the machines, is what appears to be BOClean attempting to download via FTP using notepad - which Sygate than flags and asks if it should be allowed. Sygate logs all the manual updates but there is nary a whiff of any attempts by the auto updater.

And this problem was documented more than 8 months ago with a detailed trouble report.

I think the gruntwork has been done on this puppy, and I am not about to start rebuilding a box from scratch because someone may want to believe 3 default administrators on three different machines are corrupted, when all the evidence points to sloppy code and there are the screen shots to prove it.

[Little Mac]

vjk,

If you have not done so already, please let Kevin know by posting in this thread:  http://forums.comodo.com/index.php/topic,8915.0.html

A brief scenario and link to this topic should be sufficient.

Tnx,

LM

[~cat~]

I think the gruntwork has been done on this puppy, and I am not about to start rebuilding a box from scratch because someone may want to believe 3 default administrators on three different machines are corrupted, ...

I'm sorry, I thought you stated either  here or at Securecomp that all 3 boxes were installed from the same image.

[jasper2408]

I'm sorry, I thought you stated either  here or at Securecomp that all 3 boxes were installed from the same image.

I'm not saying that you didn't do this as this is just a suggestion to look at and it may not be the problem, but, if the boxes are all on the same network(using the same DNS server)were installed from the same image then did you run sysprep on the boxes before putting them on the network?

I have seen that small detail cause some very weird problems with permissions and DNS servers. The same SID on all the boxes is not good. Sometimes the problems won't show up til weeks later.

jasper

[vjk]

I'm sorry, I thought you stated either  here or at Securecomp that all 3 boxes were installed from the same image.

We restore from a known good Acronis image of an individual installation. Each machine has a current image and archive - and the images are usually done in 1 month increments - roughly in sync with the MS patch cycle. We typically retain 3-6 months of images for each machine. When something like this comes up, it is relatively easy to isolate a "culprit" by restoring a previous image. If I recall correctly, that was what was done when this first came up - and it was determined that that the issue did not exist prior to 4.22.002. The issue has remained the same since then. The images for the three boxes we are testing here are totally unrelated to one another - they are exclusive to the machines they image. Your point on corruption is well taken, but it would likely have to be a systemic MS thing - maybe related to their patches - and in that case could therefore be found on all three boxes. That, however, would not be related to the imaging process.

[Kevin McAleavey]

Definitely one of the stranger ones I've heard of. One of our (former) customers contacted me and said that he'd been through this a while ago and offered this advice that might be the solution for you. Normally the only thing that would cause that problem is the connection being blocked by a firewall. But there's one OTHER thing that could do that and that was what I was reminded of since I'd never seen that one.

If either Outlook Express or Internet Explorer is placed into "offline mode" and left that way, that would cause what you describe under Win2000 ... in order to reduce the amount of code and ensure compatibility with so many different firewalls with different interpretations of what is "safe" and what isn't, we designed the autoupdate (and the manual one as well, it's the same code) to use the WININET library in Windows (since you can't remove it and it's there anyway). And to further ensure compatibility no matter what's thrown our way, the ftp download is done using whatever is PRESET for IE/Outlook Express because some firewalls required odd settings in those as well. By doing things this way, then whatever was required externally would simply be picked up by BOClean's updater and used with no further complications.

 UNLESS perhaps on those machines in question, either IE or Outlook Express was put into "offline" mode and left that way. So give that a shot, it's the only thing I can think of if everything else is working and there's no firewall or other configuration blocking FTP ...

[Tags:]