New definitions

  • Thread starter Thread starter Trish
  • Start date Start date
5737 is available.

Okay. I just tried it again, and this time 5737 "stuck".

What was the problem? I have three different computers
that have been trying to upgrade 5735 to 5737 for a few
days now (each time it said it downloaded and installed
5737, but a manual check showed 5735 still installed and
it tried 5737 again - been doing that several times on
three different computers, all with build 615).

-Kerry-
 
Kerry said:
What was the problem? I have three different computers
that have been trying to upgrade 5735 to 5737 for a few
days now (each time it said it downloaded and installed
5737, but a manual check showed 5735 still installed and
it tried 5737 again - been doing that several times on
three different computers, all with build 615).

You must empty your Temporary Internet Files (or any other web cache) before
trying the definitions update.
 
You must empty your Temporary Internet Files (or any
other web cache) before
trying the definitions update.

Oh really?

1. I've never done that before (been using MSAS for about
4 months now). Until 5727 there was never a problem with
web cache and MSAS AutoUpdates. Never. Ever. Not once.

2. I DID clear the cache last night around 8:30pm
(Central) and tried an update agin, and it did not work.
(In fact, I tried for about another hour after that with
no success)

3. After Trish posted the note late last night that 5737
defs were available, I tried it again, this time with
success (did NOT clear the cache again, though by then
there was surely lots of temp content there again).

4. After Trish's note, I went to a second computer that
was having the SAME def update problem (in fact, I have
three computers that all had the same problem) and tried
the update, and it worked at that time. I did NOT clear
any cache on that computer at all, and in fact the cache
has not been cleared on that one in over six months.

5. Tried the update on my third computer after that, and
it also worked.

6. Bottom line: 3 computers, all couldn't update to 5737
from 5735 (though it looked like it did, every time).
Two with full web caches last night, one with a cache
that was starting to fill back up again. The update
worked on all three after Trish's post. NONE of them
updated (for several days) BEFORE that note.

Tell me again it was a "web cache" problem, Randy. I
don't think so.

-Kerry-
 
You must empty your Temporary Internet Files (or any
other web cache) before
trying the definitions update.

Robin, you posted this in the "General" section under a
similar thread:
When MSAS asks for the definitions .gcz and .cat files,
the request is diverted to the world-wide server farm
operated by Akamai on behalf of Microsoft. This server
farm does not update itself as fast as the central
spynet server can change the definitions version
number. It takes time for all the Akamai servers to
get updated with the new definitions .gcz and .cat
files.

This was obviously a synch problem between Spynet and
Akami, NOT a local web cache problem on my computer(s).
 
Kerry said:
Oh really?

1. I've never done that before (been using MSAS for about
4 months now). Until 5727 there was never a problem with
web cache and MSAS AutoUpdates. Never. Ever. Not once.

You've been lucky, then, or you have a small MSIE cache size. I have
verified by direct experiment that MSAS can fetch stale definitions files
from the MSIE cache. The cache has to be large enough (and other traffic
low enough) to preserve the stale files for long enough, then there is a
risk of this effect. It might not have affected you, but in principle it
can affect others. That's why I post this advice in response to people who
do not make it clear that they have already done that.
 
Kerry said:
This was obviously a synch problem between Spynet and
Akami, NOT a local web cache problem on my computer(s).

I'm glad you got it sorted. You did not have the local web cache problem,
but in principle others can have. It is difficult to distinguish the two
cases, without packet-sniffing to see what is on the wire.
 
I'm glad you got it sorted.

Thanks for the details on the way the update process
works behind the scenes. Wouldn't have known what in the
world was going on without your insights re:
Spynet/Akami. But this is the first time I have seen
updates fail over a period of two or more days (could
have been three or four days, didn't write down when the
symptoms started). I think there was more going on with
the def files behind the scenes than just a synch issue
between Spynet and Akami, though I don't doubt that may
have been a major factor.

Also, I apologize for coming across in my posts as a
grumpy sourpuss, but that's pretty much what I am late at
night after a long day and after several days of errors
trying to get the 5737 update to "stick".
 
FWIW, I'm seeing the same behavior today on several machines.

I'm on the latest build .615.

I've blown away, by hand, at the command prompt, both TIF and several TEMP
locations.

I've even, on one machine, deleted the definition files themselves. a
Repair operation brought them back to the base number for the build, but the
update still wasn't happening.

Hmm - both machines are behind the same ISA server.

OK--I'll dump the cache on that later tonight and retry.

--
 
Did you upgrade from the previous versions? If so your
problems could lye w/ the gsuncompress.dll file...this
file is located in windows/system32, if you delete this
file then uninstall and reinstall you MS Anti w/ the
latest build this should fix your problems...The
gsuncompress.dll file does not get updated w/
the "upgrade" but will get installed if it is deleted w/
the new install.

It worked for me...
 
Correction...the files name is gcUnCompress.dll...
-----Original Message-----
Did you upgrade from the previous versions? If so your
problems could lye w/ the gsuncompress.dll file...this
file is located in windows/system32, if you delete this
file then uninstall and reinstall you MS Anti w/ the
latest build this should fix your problems...The
gsuncompress.dll file does not get updated w/
the "upgrade" but will get installed if it is deleted w/
the new install.

It worked for me...
late
.
 
-----Original Message-----
Did you upgrade from the previous versions? If so your
problems could lye w/ the gsuncompress.dll file...

Did that weeks ago. This was a different issue. Thanks.
 
Boberuski said:
Did you upgrade from the previous versions? If so your
problems could lye w/ the gsuncompress.dll file

No, that file is no longer a problem with Build 615, which the poster said
they were using.
 
That problem shouldn't exist with build 615, and I've checked it on the two
machines affected. (still haven't gone back and looked after dumping the
ISA cache, though.)

--
 
And, by Tuesday, the behavior had gone away. I believe this was probably
due to the ISA Server's transparent web proxy and cache.

--
 
Back
Top