BUGFIX: Norton Internet Security and-or Norton SystemWorks loses Activation after install of Septemb

B

Bill Drake

OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user contact
Symantec Customer Support.

Restoring the Client's Ghost Image from the day before Patch Tuesday,
then completely updating Norton Internet Security and SystemWorks
and then reinstalling the Microsoft Patches would solve the problem for
24 hours. However - regardless of the successful repair of the problem
by the use of Ghost - Norton Internet Security Activation would be lost
the next time Symantec Live Update brought down and installed new
Virus Definitions on the Client's machine.


Symantec Customer Support recommended a complete uninstall and
reinstall of both Norton Internet Security and Norton SystemWorks
Premier as a possible solution to the problem. After doing as requested,
I found this did not work - as the problem recurred exactly as it had with
the use of Ghost as detailed above.

Symantec Customer Support then tried to tell me this problem was
related to the installation of Roxio EZ-CD Creator software. They
told me this problem occurred with all versions and that the only
solution was to remove EZ-CD Creator, install the Norton Software
and then reinstall EZ-CD Creator.

At this point I ran out of patience. I re-explained (for the 8th time)
that this installation HAD RUN SUCCESSFULLY FOR 6 MONTHS
and had spontaneously deactivated. I insisted that they check the
Activation database count for this Client's Product Keys for both
Norton Internet Security and Norton SystemWorks. The products
(which had only been installed on this Client's System) showed
multiple installations. I insisted that the Activation database counts
be reset. Product Support accepted my request and the fresh reinstall
of the product - done at Symantec's request - which up to that point
had stubbornly refused to Activate - magically activated.


Now *here* is where it gets interesting:

After successfully Activating the product, the usual round of Live
Updates is required to bring the product up-to-date. However,
unlike installations done previous to the install of Microsoft's
September updates - this *new* install promptly failed its
activation immediately after the install of the *next* set of
Symantec Updates.

It was necessary to re-activate the product a *second* time,
immediately after the second round of Symantec Live Update
installation procedures. Because the Activation database
count had been reset - this time the *second* activation was
successful and the update installed correctly.

From the above, I suspect that something in the September
Microsoft Updates interacts with the information Symantec's
Live-Update uses for Symantec's own Product Activation Key
reporting.

This data shows up *differently* between the Product
Activation that occurs when using the original CD-ROM
and the information returned to Symantec after the first
time Live-Update is used. Because of the interaction,
the Symantec Server interprets the changed info as a
*new installation* even though the product installation is
an existing installation that has not changed at all. As
a result, a *second* activation process is required.


The crucial factor here is that if the user has had to
reinstall the product for any *other* reason (such as
a virus infection or any one of the other reasons that
Symantec requests the user reinstall the product)
then the install-count kept on the Symantec Server
for that product key will exceed the number that
Symantec considers abuse of the product - and the
user will be branded a pirate. As a result, that
*second* activation will be refused and the user is
stuck in activation hell until they call Symantec and
get the install-count reset on the Symantec Server
so their update can proceed to completion correctly.


So - from what I can make out - what *looks* like a
Symantec problem is actually a changed response
for Symantec's Product Activation routines that occurs
as a consequence of a MICROSOFT update.

Therefore, please be aware that as a result of the
security updates released by Microsoft on Patch
Tuesdays - your Product Activation on other
software may be SPONTANEOUSLY REVOKED
and you will have to contact that software
manufacturer's technical support and have them
manually clean up the mess before your previously
working installations of non-microsoft products will
work properly again.


Needless to say, I am underwhelmed by the shoddy
industry-cross-cooperation the above debacle implies.

Once again, Microsoft's quality-control is shown to be
sorely lacking or non-existent. This is unacceptable.


Best I can do for now. <tm>


Bill
 
A

Antioch

I cannot help thinking that the answer to the problem was in updates all the
time.
Download to disk/desktop/file to whatever preference - with or without any
antivirus running and certainly not Norton.
Disconnect from the net - disable all security progs and anything not
required to run - then install updates.
And dont cough - with the apparent instability of MS updates at the moment,
anything could cause a failure at any point in the process.
Rgds
Antioch
PS Thanks for the info - almost forgot.
 
M

MowGreen [MVP]

Bill,

Let me state this as clearly as possible. Although you've done a fine
job deducing what the issue stems from, suggest you visit the Windows
Update newsgroup and see how many Users have issues accessing Windows
Updates and installing Critical updates due to the presence of Symantec
software "products".
NAV, NIS, and NSW are NOT fit to use with Windows OS'. Period.
Check this study out :
http://www.thepcspy.com/articles/other/what_really_slows_windows_down

Especially this comparative: Results and Conclusions
http://www.thepcspy.com/articles/other/what_really_slows_windows_down/5

The above is for performance issues. The following is on how well AV's
perform :
Comparative tests of antivirus programs
http://www.virus.gr/english/fullxml/default.asp?id=82&mnu=82

I've participated in the WU NG for over 5 years. There is NO other AV or
security suite that causes more issues with OS' than the ones from Symantec.

So, the ball is not in Microsoft's court, rather, it's up to Symantec to
be able to produce software that functions with Windows.
And, they do NOT.

None of my systems have ever had Norton anything installed on them.
If my clients' systems had any Symantec "software" installed, I've
uninstalled them, and replaced "it" with either free or paid for AV's.

None of them have had any performance, updating, nor malware issues due
to the installed AV.

So, if the fault lies with MS, then why do the above systems not
experience Activation, performance, updating, or malware issues ?

MowGreen [MVP 2003-2006]
===============
*-343-* FDNY
Never Forgotten
===============

p.s. I have beta tested for Symantec, therefore I can not discuss
anything concerning their bringing a product to market. Suffice it to
say, their method is *not* working. They depend on OEM's to foist said
"software" onto unsuspecting Users' systems.
 
B

Bill Drake

Mow, I am not going to argue with you about the suitability
of Symantec products or not. The issue is moot. There are
*tons* of people out there running Symantec product - whether
you like it or not. This post is relevant to THEM.

It is Microsoft's responsibility to regression-test their patches
such that the patches do NOT produce errors in already
existing products. This is not debatable.

As you have mentioned, I presented evidence of an interaction
caused solely by the presence of one or more of the updates
released in the September set of Microsoft Updates - which
INDUCES the problem discussed in my report. This is obviously
a regression issue and needs to be addressed as such.


Furthermore, I understand you have an opinion about Symantec
Products. I have seen your posting history on the subject and
it is not pretty. It comes across as if you have an axe to grind.

Please note that I have an opinion about irrational, bigoted and
brainless hatred of *any* product - whether from Microsoft,
Apple, Symantec or whoever. I am not interested in discussions
of those types.

What I DO want is results, a consistent dedication to workability,
and a reliable program suite that works as designed. I don't care
who produces that. However, I do object most strongly when a
third-party product that is working as designed magically STOPS
working as designed due to OS manufacturer monkeydiddling.

And I have said so.


EOT


Bill



Bill,

Let me state this as clearly as possible. Although you've done a fine
job deducing what the issue stems from, suggest you visit the Windows
Update newsgroup and see how many Users have issues accessing Windows
Updates and installing Critical updates due to the presence of
Symantec software "products".
NAV, NIS, and NSW are NOT fit to use with Windows OS'. Period.
Check this study out :
http://www.thepcspy.com/articles/other/what_really_slows_windows_down

Especially this comparative: Results and Conclusions
http://www.thepcspy.com/articles/other/what_really_slows_windows_down/5

The above is for performance issues. The following is on how well AV's
perform :
Comparative tests of antivirus programs
http://www.virus.gr/english/fullxml/default.asp?id=82&mnu=82

I've participated in the WU NG for over 5 years. There is NO other AV
or security suite that causes more issues with OS' than the ones from
Symantec.
So, the ball is not in Microsoft's court, rather, it's up to Symantec
to be able to produce software that functions with Windows.
And, they do NOT.

None of my systems have ever had Norton anything installed on them.
If my clients' systems had any Symantec "software" installed, I've
uninstalled them, and replaced "it" with either free or paid for AV's.

None of them have had any performance, updating, nor malware issues
due to the installed AV.

So, if the fault lies with MS, then why do the above systems not
experience Activation, performance, updating, or malware issues ?

MowGreen [MVP 2003-2006]
===============
*-343-* FDNY
Never Forgotten
===============

p.s. I have beta tested for Symantec, therefore I can not discuss
anything concerning their bringing a product to market. Suffice it to
say, their method is *not* working. They depend on OEM's to foist said
"software" onto unsuspecting Users' systems.


Bill said:
OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user
contact Symantec Customer Support.

Restoring the Client's Ghost Image from the day before Patch Tuesday,
then completely updating Norton Internet Security and SystemWorks
and then reinstalling the Microsoft Patches would solve the problem
for 24 hours. However - regardless of the successful repair of the
problem by the use of Ghost - Norton Internet Security Activation
would be lost the next time Symantec Live Update brought down and
installed new Virus Definitions on the Client's machine.


Symantec Customer Support recommended a complete uninstall and
reinstall of both Norton Internet Security and Norton SystemWorks
Premier as a possible solution to the problem. After doing as
requested, I found this did not work - as the problem recurred
exactly as it had with the use of Ghost as detailed above.

Symantec Customer Support then tried to tell me this problem was
related to the installation of Roxio EZ-CD Creator software. They
told me this problem occurred with all versions and that the only
solution was to remove EZ-CD Creator, install the Norton Software
and then reinstall EZ-CD Creator.

At this point I ran out of patience. I re-explained (for the 8th
time) that this installation HAD RUN SUCCESSFULLY FOR 6 MONTHS
and had spontaneously deactivated. I insisted that they check the
Activation database count for this Client's Product Keys for both
Norton Internet Security and Norton SystemWorks. The products
(which had only been installed on this Client's System) showed
multiple installations. I insisted that the Activation database
counts be reset. Product Support accepted my request and the fresh
reinstall of the product - done at Symantec's request - which up to
that point had stubbornly refused to Activate - magically activated.


Now *here* is where it gets interesting:

After successfully Activating the product, the usual round of Live
Updates is required to bring the product up-to-date. However,
unlike installations done previous to the install of Microsoft's
September updates - this *new* install promptly failed its
activation immediately after the install of the *next* set of
Symantec Updates.

It was necessary to re-activate the product a *second* time,
immediately after the second round of Symantec Live Update
installation procedures. Because the Activation database
count had been reset - this time the *second* activation was
successful and the update installed correctly.

From the above, I suspect that something in the September
Microsoft Updates interacts with the information Symantec's
Live-Update uses for Symantec's own Product Activation Key
reporting.

This data shows up *differently* between the Product
Activation that occurs when using the original CD-ROM
and the information returned to Symantec after the first
time Live-Update is used. Because of the interaction,
the Symantec Server interprets the changed info as a
*new installation* even though the product installation is
an existing installation that has not changed at all. As
a result, a *second* activation process is required.


The crucial factor here is that if the user has had to
reinstall the product for any *other* reason (such as
a virus infection or any one of the other reasons that
Symantec requests the user reinstall the product)
then the install-count kept on the Symantec Server
for that product key will exceed the number that
Symantec considers abuse of the product - and the
user will be branded a pirate. As a result, that
*second* activation will be refused and the user is
stuck in activation hell until they call Symantec and
get the install-count reset on the Symantec Server
so their update can proceed to completion correctly.


So - from what I can make out - what *looks* like a
Symantec problem is actually a changed response
for Symantec's Product Activation routines that occurs
as a consequence of a MICROSOFT update.

Therefore, please be aware that as a result of the
security updates released by Microsoft on Patch
Tuesdays - your Product Activation on other
software may be SPONTANEOUSLY REVOKED
and you will have to contact that software
manufacturer's technical support and have them
manually clean up the mess before your previously
working installations of non-microsoft products will
work properly again.


Needless to say, I am underwhelmed by the shoddy
industry-cross-cooperation the above debacle implies.

Once again, Microsoft's quality-control is shown to be
sorely lacking or non-existent. This is unacceptable.


Best I can do for now. <tm>


Bill
 
F

FeMaster

Bill Drake said:
I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user contact
Symantec Customer Support.

As a side note, I am Running Norton Internet Security 2005 Antispyware
Edition, and SystemWorks 2005 Premier on my system. Only difference is I am
running Windows XP SP1. I have had no issues with the September updates,
nor any other updates, so far. It may just be an isolated incident with
this person's system. Of course, it could just be Windows 2000 as well.
 
M

MowGreen

EOT

Fair enough. One point, though. It may come across as a biased flame
against Symantec because of all the difficulties I've witnessed Users
having to go through due to it's lack of functionality with Windows.
So be it.

If the issue lies with Windows, then why do other AV's rarely have
issues with Windows ?

EOT

MowGreen [MVP 2003-2006]
===============
*-343-* FDNY
Never Forgotten
===============



Bill said:
Mow, I am not going to argue with you about the suitability
of Symantec products or not. The issue is moot. There are
*tons* of people out there running Symantec product - whether
you like it or not. This post is relevant to THEM.

It is Microsoft's responsibility to regression-test their patches
such that the patches do NOT produce errors in already
existing products. This is not debatable.

As you have mentioned, I presented evidence of an interaction
caused solely by the presence of one or more of the updates
released in the September set of Microsoft Updates - which
INDUCES the problem discussed in my report. This is obviously
a regression issue and needs to be addressed as such.


Furthermore, I understand you have an opinion about Symantec
Products. I have seen your posting history on the subject and
it is not pretty. It comes across as if you have an axe to grind.

Please note that I have an opinion about irrational, bigoted and
brainless hatred of *any* product - whether from Microsoft,
Apple, Symantec or whoever. I am not interested in discussions
of those types.

What I DO want is results, a consistent dedication to workability,
and a reliable program suite that works as designed. I don't care
who produces that. However, I do object most strongly when a
third-party product that is working as designed magically STOPS
working as designed due to OS manufacturer monkeydiddling.

And I have said so.


EOT


Bill



Bill,

Let me state this as clearly as possible. Although you've done a fine
job deducing what the issue stems from, suggest you visit the Windows
Update newsgroup and see how many Users have issues accessing Windows
Updates and installing Critical updates due to the presence of
Symantec software "products".
NAV, NIS, and NSW are NOT fit to use with Windows OS'. Period.
Check this study out :
http://www.thepcspy.com/articles/other/what_really_slows_windows_down

Especially this comparative: Results and Conclusions
http://www.thepcspy.com/articles/other/what_really_slows_windows_down/5

The above is for performance issues. The following is on how well AV's
perform :
Comparative tests of antivirus programs
http://www.virus.gr/english/fullxml/default.asp?id=82&mnu=82

I've participated in the WU NG for over 5 years. There is NO other AV
or security suite that causes more issues with OS' than the ones from
Symantec.
So, the ball is not in Microsoft's court, rather, it's up to Symantec
to be able to produce software that functions with Windows.
And, they do NOT.

None of my systems have ever had Norton anything installed on them.
If my clients' systems had any Symantec "software" installed, I've
uninstalled them, and replaced "it" with either free or paid for AV's.

None of them have had any performance, updating, nor malware issues
due to the installed AV.

So, if the fault lies with MS, then why do the above systems not
experience Activation, performance, updating, or malware issues ?

MowGreen [MVP 2003-2006]
===============
*-343-* FDNY
Never Forgotten
===============

p.s. I have beta tested for Symantec, therefore I can not discuss
anything concerning their bringing a product to market. Suffice it to
say, their method is *not* working. They depend on OEM's to foist said
"software" onto unsuspecting Users' systems.


Bill said:
OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user
contact Symantec Customer Support.

Restoring the Client's Ghost Image from the day before Patch Tuesday,
then completely updating Norton Internet Security and SystemWorks
and then reinstalling the Microsoft Patches would solve the problem
for 24 hours. However - regardless of the successful repair of the
problem by the use of Ghost - Norton Internet Security Activation
would be lost the next time Symantec Live Update brought down and
installed new Virus Definitions on the Client's machine.


Symantec Customer Support recommended a complete uninstall and
reinstall of both Norton Internet Security and Norton SystemWorks
Premier as a possible solution to the problem. After doing as
requested, I found this did not work - as the problem recurred
exactly as it had with the use of Ghost as detailed above.

Symantec Customer Support then tried to tell me this problem was
related to the installation of Roxio EZ-CD Creator software. They
told me this problem occurred with all versions and that the only
solution was to remove EZ-CD Creator, install the Norton Software
and then reinstall EZ-CD Creator.

At this point I ran out of patience. I re-explained (for the 8th
time) that this installation HAD RUN SUCCESSFULLY FOR 6 MONTHS
and had spontaneously deactivated. I insisted that they check the
Activation database count for this Client's Product Keys for both
Norton Internet Security and Norton SystemWorks. The products
(which had only been installed on this Client's System) showed
multiple installations. I insisted that the Activation database
counts be reset. Product Support accepted my request and the fresh
reinstall of the product - done at Symantec's request - which up to
that point had stubbornly refused to Activate - magically activated.


Now *here* is where it gets interesting:

After successfully Activating the product, the usual round of Live
Updates is required to bring the product up-to-date. However,
unlike installations done previous to the install of Microsoft's
September updates - this *new* install promptly failed its
activation immediately after the install of the *next* set of
Symantec Updates.

It was necessary to re-activate the product a *second* time,
immediately after the second round of Symantec Live Update
installation procedures. Because the Activation database
count had been reset - this time the *second* activation was
successful and the update installed correctly.

From the above, I suspect that something in the September
Microsoft Updates interacts with the information Symantec's
Live-Update uses for Symantec's own Product Activation Key
reporting.

This data shows up *differently* between the Product
Activation that occurs when using the original CD-ROM
and the information returned to Symantec after the first
time Live-Update is used. Because of the interaction,
the Symantec Server interprets the changed info as a
*new installation* even though the product installation is
an existing installation that has not changed at all. As
a result, a *second* activation process is required.


The crucial factor here is that if the user has had to
reinstall the product for any *other* reason (such as
a virus infection or any one of the other reasons that
Symantec requests the user reinstall the product)
then the install-count kept on the Symantec Server
for that product key will exceed the number that
Symantec considers abuse of the product - and the
user will be branded a pirate. As a result, that
*second* activation will be refused and the user is
stuck in activation hell until they call Symantec and
get the install-count reset on the Symantec Server
so their update can proceed to completion correctly.


So - from what I can make out - what *looks* like a
Symantec problem is actually a changed response
for Symantec's Product Activation routines that occurs
as a consequence of a MICROSOFT update.

Therefore, please be aware that as a result of the
security updates released by Microsoft on Patch
Tuesdays - your Product Activation on other
software may be SPONTANEOUSLY REVOKED
and you will have to contact that software
manufacturer's technical support and have them
manually clean up the mess before your previously
working installations of non-microsoft products will
work properly again.


Needless to say, I am underwhelmed by the shoddy
industry-cross-cooperation the above debacle implies.

Once again, Microsoft's quality-control is shown to be
sorely lacking or non-existent. This is unacceptable.


Best I can do for now. <tm>


Bill
 
D

DL

My two pence worth;
I gave up on NIS 2005 about a year ago, having used Norton products for some
years without any real problems.
On two PC's NIS would constantly deactivate, this didn't coincide with any
MS update and was completely random. - I had a volume licence for NIS, but
didnt install it on the other PC's
Norton support, over some period, could'nt help other than suggesting
uninstall/completely remove/clean reinstall - I got fed up running this
procedure - and I wasnt about to format / clean install as they suggested

Bill Drake said:
Mow, I am not going to argue with you about the suitability
of Symantec products or not. The issue is moot. There are
*tons* of people out there running Symantec product - whether
you like it or not. This post is relevant to THEM.

It is Microsoft's responsibility to regression-test their patches
such that the patches do NOT produce errors in already
existing products. This is not debatable.

As you have mentioned, I presented evidence of an interaction
caused solely by the presence of one or more of the updates
released in the September set of Microsoft Updates - which
INDUCES the problem discussed in my report. This is obviously
a regression issue and needs to be addressed as such.


Furthermore, I understand you have an opinion about Symantec
Products. I have seen your posting history on the subject and
it is not pretty. It comes across as if you have an axe to grind.

Please note that I have an opinion about irrational, bigoted and
brainless hatred of *any* product - whether from Microsoft,
Apple, Symantec or whoever. I am not interested in discussions
of those types.

What I DO want is results, a consistent dedication to workability,
and a reliable program suite that works as designed. I don't care
who produces that. However, I do object most strongly when a
third-party product that is working as designed magically STOPS
working as designed due to OS manufacturer monkeydiddling.

And I have said so.


EOT


Bill



Bill,

Let me state this as clearly as possible. Although you've done a fine
job deducing what the issue stems from, suggest you visit the Windows
Update newsgroup and see how many Users have issues accessing Windows
Updates and installing Critical updates due to the presence of
Symantec software "products".
NAV, NIS, and NSW are NOT fit to use with Windows OS'. Period.
Check this study out :
http://www.thepcspy.com/articles/other/what_really_slows_windows_down

Especially this comparative: Results and Conclusions
http://www.thepcspy.com/articles/other/what_really_slows_windows_down/5

The above is for performance issues. The following is on how well AV's
perform :
Comparative tests of antivirus programs
http://www.virus.gr/english/fullxml/default.asp?id=82&mnu=82

I've participated in the WU NG for over 5 years. There is NO other AV
or security suite that causes more issues with OS' than the ones from
Symantec.
So, the ball is not in Microsoft's court, rather, it's up to Symantec
to be able to produce software that functions with Windows.
And, they do NOT.

None of my systems have ever had Norton anything installed on them.
If my clients' systems had any Symantec "software" installed, I've
uninstalled them, and replaced "it" with either free or paid for AV's.

None of them have had any performance, updating, nor malware issues
due to the installed AV.

So, if the fault lies with MS, then why do the above systems not
experience Activation, performance, updating, or malware issues ?

MowGreen [MVP 2003-2006]
===============
*-343-* FDNY
Never Forgotten
===============

p.s. I have beta tested for Symantec, therefore I can not discuss
anything concerning their bringing a product to market. Suffice it to
say, their method is *not* working. They depend on OEM's to foist said
"software" onto unsuspecting Users' systems.


Bill said:
OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user
contact Symantec Customer Support.

Restoring the Client's Ghost Image from the day before Patch Tuesday,
then completely updating Norton Internet Security and SystemWorks
and then reinstalling the Microsoft Patches would solve the problem
for 24 hours. However - regardless of the successful repair of the
problem by the use of Ghost - Norton Internet Security Activation
would be lost the next time Symantec Live Update brought down and
installed new Virus Definitions on the Client's machine.


Symantec Customer Support recommended a complete uninstall and
reinstall of both Norton Internet Security and Norton SystemWorks
Premier as a possible solution to the problem. After doing as
requested, I found this did not work - as the problem recurred
exactly as it had with the use of Ghost as detailed above.

Symantec Customer Support then tried to tell me this problem was
related to the installation of Roxio EZ-CD Creator software. They
told me this problem occurred with all versions and that the only
solution was to remove EZ-CD Creator, install the Norton Software
and then reinstall EZ-CD Creator.

At this point I ran out of patience. I re-explained (for the 8th
time) that this installation HAD RUN SUCCESSFULLY FOR 6 MONTHS
and had spontaneously deactivated. I insisted that they check the
Activation database count for this Client's Product Keys for both
Norton Internet Security and Norton SystemWorks. The products
(which had only been installed on this Client's System) showed
multiple installations. I insisted that the Activation database
counts be reset. Product Support accepted my request and the fresh
reinstall of the product - done at Symantec's request - which up to
that point had stubbornly refused to Activate - magically activated.


Now *here* is where it gets interesting:

After successfully Activating the product, the usual round of Live
Updates is required to bring the product up-to-date. However,
unlike installations done previous to the install of Microsoft's
September updates - this *new* install promptly failed its
activation immediately after the install of the *next* set of
Symantec Updates.

It was necessary to re-activate the product a *second* time,
immediately after the second round of Symantec Live Update
installation procedures. Because the Activation database
count had been reset - this time the *second* activation was
successful and the update installed correctly.

From the above, I suspect that something in the September
Microsoft Updates interacts with the information Symantec's
Live-Update uses for Symantec's own Product Activation Key
reporting.

This data shows up *differently* between the Product
Activation that occurs when using the original CD-ROM
and the information returned to Symantec after the first
time Live-Update is used. Because of the interaction,
the Symantec Server interprets the changed info as a
*new installation* even though the product installation is
an existing installation that has not changed at all. As
a result, a *second* activation process is required.


The crucial factor here is that if the user has had to
reinstall the product for any *other* reason (such as
a virus infection or any one of the other reasons that
Symantec requests the user reinstall the product)
then the install-count kept on the Symantec Server
for that product key will exceed the number that
Symantec considers abuse of the product - and the
user will be branded a pirate. As a result, that
*second* activation will be refused and the user is
stuck in activation hell until they call Symantec and
get the install-count reset on the Symantec Server
so their update can proceed to completion correctly.


So - from what I can make out - what *looks* like a
Symantec problem is actually a changed response
for Symantec's Product Activation routines that occurs
as a consequence of a MICROSOFT update.

Therefore, please be aware that as a result of the
security updates released by Microsoft on Patch
Tuesdays - your Product Activation on other
software may be SPONTANEOUSLY REVOKED
and you will have to contact that software
manufacturer's technical support and have them
manually clean up the mess before your previously
working installations of non-microsoft products will
work properly again.


Needless to say, I am underwhelmed by the shoddy
industry-cross-cooperation the above debacle implies.

Once again, Microsoft's quality-control is shown to be
sorely lacking or non-existent. This is unacceptable.


Best I can do for now. <tm>


Bill
 
J

Jeremy C B Nicoll

Bill Drake said:
It is Microsoft's responsibility to regression-test their patches
such that the patches do NOT produce errors in already existing
products.

Surely that's only true for their products? Why should MS be expected
to ensure their patches don't affect other people's products?
 
R

Rock

OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Bill, this is a problem with a machine running windows 2000. Why are you
posting this to an XP newsgroup? As a side note we see more problems in XP
from systems running Symantec / Norton products. Users are better off
without it.
 
A

antioch

FeMaster said:
As a side note, I am Running Norton Internet Security 2005 Antispyware
Edition, and SystemWorks 2005 Premier on my system. Only difference is I
am
running Windows XP SP1. I have had no issues with the September updates,
nor any other updates, so far. It may just be an isolated incident with
this person's system. Of course, it could just be Windows 2000 as well.
Re the above I am prompted to ask if you would get the same KB numbered
updates on your XP SP1 as I get with XP SP2?
Rgds
Antioch
 
C

cquirke (MVP Windows shell/user)

On Thu, 28 Sep 2006 00:22:06 -0700, "Bill Drake"
What I DO want is results, a consistent dedication to workability,
and a reliable program suite that works as designed. I don't care
who produces that. However, I do object most strongly when a
third-party product that is working as designed magically STOPS
working as designed due to OS manufacturer monkeydiddling.

In the past, I was fairly agnostic about Norton AV; I just considered
it a waste of money if you were eligible to use a free av that the
retail sales driod wouldn't have told you about, and I thought it was
too big, bloated and invasive for taste.

But I now have a stronger dislike for the product, and for exactly the
same reason I have a dislike for malware - and which would be the
reason for buying an av in the first place.

Namely, I don't like software that pursues an agenda hostile to my
interests, and that attempts to hide this fact.

See: http://cquirke.blogspot.com/2006/08/why-i-avoid-norton-av.html

This problem arises because Norton is deliberately playing
silly-buggers behind your back, fussing about whether it's properly
licensed or not. Norton's deep integration can be brittle at the best
of times, but when this subsystem breaks, it amounts to a DoS attack.

It's particularly a problem in the context of an AV, because often you
will have to go hand-to-hand with undetected malware using manual
tools such as HiJackThis, or manually clearing out hi-risk locations
such as Temp, TIF, etc. But because Norton is itself running some
sort of covert system, every time you find unfamiliar files hiding
about, you have to ask; is this part of the malware, or part of
Norton's hidden DoS payload? If I clear these files, am I cleaning
the system, or disabling one of its defenses?

Normally, if your paid-for product doesn't work, you can trust their
tech support to be on your side in trying to help you get it to work
again. But can you trust Norton's tech support for straight answers,
when it comes to code they've added to the product that is there to
act against you, and to be kept hidden from you?

Is this the sort of vendor you want to pay and support?


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
 
A

Admiral Q

Bill Drake said:
OK, I have been battling this one for several weeks now - I've
finally gotten to the bottom of the problem.

I have a Client running Windows 2000-SP4. He runs both Norton
Internet Security 2005 and Norton SystemWorks 2005 Premier
(which has Ghost 2005 bundled with it). This installation is about
6 months old and ran fine up until recently.

Starting just after September's Patch Tuesday - his machine would
spontaneously lose its Activation for Norton Internet Security 2005.
Attempting to Re-Activate would fail - requesting that the user contact
Symantec Customer Support.

Restoring the Client's Ghost Image from the day before Patch Tuesday,
then completely updating Norton Internet Security and SystemWorks
and then reinstalling the Microsoft Patches would solve the problem for
24 hours. However - regardless of the successful repair of the problem
by the use of Ghost - Norton Internet Security Activation would be lost
the next time Symantec Live Update brought down and installed new
Virus Definitions on the Client's machine.


Symantec Customer Support recommended a complete uninstall and
reinstall of both Norton Internet Security and Norton SystemWorks
Premier as a possible solution to the problem. After doing as requested,
I found this did not work - as the problem recurred exactly as it had with
the use of Ghost as detailed above.

Symantec Customer Support then tried to tell me this problem was
related to the installation of Roxio EZ-CD Creator software. They
told me this problem occurred with all versions and that the only
solution was to remove EZ-CD Creator, install the Norton Software
and then reinstall EZ-CD Creator.

At this point I ran out of patience. I re-explained (for the 8th time)
that this installation HAD RUN SUCCESSFULLY FOR 6 MONTHS
and had spontaneously deactivated. I insisted that they check the
Activation database count for this Client's Product Keys for both
Norton Internet Security and Norton SystemWorks. The products
(which had only been installed on this Client's System) showed
multiple installations. I insisted that the Activation database counts
be reset. Product Support accepted my request and the fresh reinstall
of the product - done at Symantec's request - which up to that point
had stubbornly refused to Activate - magically activated.


Now *here* is where it gets interesting:

After successfully Activating the product, the usual round of Live
Updates is required to bring the product up-to-date. However,
unlike installations done previous to the install of Microsoft's
September updates - this *new* install promptly failed its
activation immediately after the install of the *next* set of
Symantec Updates.

It was necessary to re-activate the product a *second* time,
immediately after the second round of Symantec Live Update
installation procedures. Because the Activation database
count had been reset - this time the *second* activation was
successful and the update installed correctly.

From the above, I suspect that something in the September
Microsoft Updates interacts with the information Symantec's
Live-Update uses for Symantec's own Product Activation Key
reporting.

This data shows up *differently* between the Product
Activation that occurs when using the original CD-ROM
and the information returned to Symantec after the first
time Live-Update is used. Because of the interaction,
the Symantec Server interprets the changed info as a
*new installation* even though the product installation is
an existing installation that has not changed at all. As
a result, a *second* activation process is required.


The crucial factor here is that if the user has had to
reinstall the product for any *other* reason (such as
a virus infection or any one of the other reasons that
Symantec requests the user reinstall the product)
then the install-count kept on the Symantec Server
for that product key will exceed the number that
Symantec considers abuse of the product - and the
user will be branded a pirate. As a result, that
*second* activation will be refused and the user is
stuck in activation hell until they call Symantec and
get the install-count reset on the Symantec Server
so their update can proceed to completion correctly.


So - from what I can make out - what *looks* like a
Symantec problem is actually a changed response
for Symantec's Product Activation routines that occurs
as a consequence of a MICROSOFT update.

Therefore, please be aware that as a result of the
security updates released by Microsoft on Patch
Tuesdays - your Product Activation on other
software may be SPONTANEOUSLY REVOKED
and you will have to contact that software
manufacturer's technical support and have them
manually clean up the mess before your previously
working installations of non-microsoft products will
work properly again.


Needless to say, I am underwhelmed by the shoddy
industry-cross-cooperation the above debacle implies.

Once again, Microsoft's quality-control is shown to be
sorely lacking or non-existent. This is unacceptable.


Best I can do for now. <tm>


Bill



I'd suggest posting in one of the many Win2k newsgroups. They are more
likely to have a solution for a Win2k problem than all the XP newsgroups you
cross-posted to.
 
A

antioch

cquirke (MVP Windows shell/user) said:
On Thu, 28 Sep 2006 00:22:06 -0700, "Bill Drake"


In the past, I was fairly agnostic about Norton AV; I just considered
it a waste of money if you were eligible to use a free av that the
retail sales driod wouldn't have told you about, and I thought it was
too big, bloated and invasive for taste.

But I now have a stronger dislike for the product, and for exactly the
same reason I have a dislike for malware - and which would be the
reason for buying an av in the first place.

Namely, I don't like software that pursues an agenda hostile to my
interests, and that attempts to hide this fact.

See: http://cquirke.blogspot.com/2006/08/why-i-avoid-norton-av.html

This problem arises because Norton is deliberately playing
silly-buggers behind your back, fussing about whether it's properly
licensed or not. Norton's deep integration can be brittle at the best
of times, but when this subsystem breaks, it amounts to a DoS attack.

It's particularly a problem in the context of an AV, because often you
will have to go hand-to-hand with undetected malware using manual
tools such as HiJackThis, or manually clearing out hi-risk locations
such as Temp, TIF, etc. But because Norton is itself running some
sort of covert system, every time you find unfamiliar files hiding
about, you have to ask; is this part of the malware, or part of
Norton's hidden DoS payload? If I clear these files, am I cleaning
the system, or disabling one of its defenses?

Normally, if your paid-for product doesn't work, you can trust their
tech support to be on your side in trying to help you get it to work
again. But can you trust Norton's tech support for straight answers,
when it comes to code they've added to the product that is there to
act against you, and to be kept hidden from you?

Is this the sort of vendor you want to pay and support?



Drugs are usually safe. Inject? (Y/n)

Very interesting - I think I read earlier this year that their products were
found to contain those 'rootkits' - a bit like the Sony incident and MS for
that matter.
Antioch
 
C

cquirke (MVP Windows shell/user)

Surely that's only true for their products? Why should MS be expected
to ensure their patches don't affect other people's products?

Because they are an OS vendor, not an application vendor.

An application vendor may write a program that can mess up others if
run at the same time as them, and that's tolerable if the application
is not running all the time.

But an OS exists purely to run 3rd-party applications, with no
preference to those written by the OS vendor themselves.

That is why, yes, an OS vendor does have to test with all those
applications out there, and not screw up.

OTOH, OS vendors publish recommended practices for application
vendors, so the latter can be confident that their apps will still
work as the OS is changed across patches, SPs and versions.

The advice generally boils down to: "Use the API, Luke".

Norton. OTOH, wants to go deep into the system's innards - partly
because it has a ton of malware after its ass (as the "tallest poppy"
av, it's bound to get the most detailled attention when it comes to
malware counter attack) but also because it has its own malware to
hide; all that "you must re-activate" nonsense.

That is why I hold MS generally responsible for not breaking apps, but
have rather less sympathy with Norton in this particular case.


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
 
F

FeMaster

antioch said:
Re the above I am prompted to ask if you would get the same KB numbered
updates on your XP SP1 as I get with XP SP2?

From what I understand, most are common to both Service Packs, but there are
a few that are specific to each one...
 
J

Jeremy C B Nicoll

Because they are an OS vendor, not an application vendor.
An application vendor may write a program that can mess up others if
run at the same time as them, and that's tolerable if the application
is not running all the time.
But an OS exists purely to run 3rd-party applications, with no
preference to those written by the OS vendor themselves.
That is why, yes, an OS vendor does have to test with all those
applications out there, and not screw up.

How can MS possibly test their OS with "all applications"? There will
be more of those out there than they know of.

Why should they? Any vendor could write any old bit of code that makes
invalid assumptions about the way Windows currently works, let alone
how it might develop.

It's like saying that a car maker should guarantee their car will
continue to work no matter what additional hardware a user, however
inadvisedly, bolts onto the engine.

I'd have thought MS would be limited to being expected to make sure
their APIs work as documented.


In my years as a mainframe systems programmer we never ever expected
IBM to make sure that fixes to bugs in their software didn't affect
software from other vendors or software we'd written ourselves. That's
not to say that we'd not expect them to co-operate with other software
vendors in tracking down causes of conflicts.

OTOH, OS vendors publish recommended practices for application
vendors, so the latter can be confident that their apps will still
work as the OS is changed across patches, SPs and versions.
The advice generally boils down to: "Use the API, Luke".

Ah, we agree then. This is not what you said originally.
Norton. OTOH, wants to go deep into the system's innards

In which case all bets are off, but faults are Norton's problem. Their
code should be written in a much more defensive manner so it doesn't
harm a system it is installed in even if that underlying system no
longer works quite as they expect.
 
C

cquirke (MVP Windows shell/user)

Because they are an OS vendor, not an application vendor.
[/QUOTE]

Consider also the monopoly/trust issues implied by "fixing the OS so
that MS apps work, but not testing for other vendor's apps".
How can MS possibly test their OS with "all applications"? There will
be more of those out there than they know of.
Why should they?

Because their product is an OS, that has to work with apps.

Normally, that's easy; the OS is the given state that apps are written
for and tested against. The problems arise when MS pushes changes
into the OS, to fix earlier product defects.

How can an app vendor test their app for OS code that does not yet
exist? That's why if MS pushes changes, they have to test those
changes on all apps. We'd much rather thay didn't push changes at
all, i.e. that they wrote defect-free code in the first place.
Any vendor could write any old bit of code that makes invalid
assumptions about the way Windows currently works, let alone
how it might develop.

Yep. That's the reason why app vendors are encouraged to use the
approved APIs, and not make use of "undocumented" Windows features.
The controversy there has been that in the past, MS resorted to such
"undocumented" features to get MS Office running more efficiently.
It's like saying that a car maker should guarantee their car will
continue to work no matter what additional hardware a user, however
inadvisedly, bolts onto the engine.

Not really, no. More like a container ship is built to carry goods
containers... the OS exists purely to act as a platform for apps
written for it, whereas a car is not built purely as a platform for
add-on engine components.
I'd have thought MS would be limited to being expected to make sure
their APIs work as documented.

Now we're getting somewhere ;-)
Ah, we agree then. This is not what you said originally.
In which case all bets are off, but faults are Norton's problem. Their
code should be written in a much more defensive manner so it doesn't
harm a system it is installed in even if that underlying system no
longer works quite as they expect.

I agree with you, up to a point - the problem is that what Norton AV
tries to do, requires it to go deeper than the malware it is trying to
fix. That means intruding into unexpected spaces, just as malware is
likely to do. What is unacceptable is that Norton includes their own
hidden malware designed to hide from the user, and when this is the
cause of the problem, then it's a problem the user need not have had.

The original Peter Norton team were brilliant in the DOS era, because
they leveraged a deep knowledge of the system to create new types of
utilities that never existed before.

That changed when Windows came along, because Windows changed the
relationship between OS and application.

In the DOS era, the OS merely launched an app, got out of the way, and
stayed out of the way unless the app called it to perform a service.

In the Windows era, the OS was to remain in full control of the system
at all times, and would call into the various running programs as and
when it saw fit. Almost everything the program wanted to do on
screen, it was expected to do by asking Windows to do it.

The initial 16-bit Windows used co-operative multi-tasking, where apps
were supposed to "let go" so that Windows could regain control and
allow other apps to run for a while. This was the same multitasking
model used by MacOS until comparitively recently.

All too often "co-operative" multitasking really meant competitive
multitasking, because if you give app programmers a choice between
letting other apps run faster at the expense of the speed of their own
app, or hogging the processor so their app looks fast but everything
else is slow, guess what they'd do?

So 32-bit Windows (NT and native Win9x apps) used pre-emptive
multitasking, where the OS would step in and yank control away from
the app, whether it wanted to "let go" or not.

Norton didn't adapt to this - they still tried to do everything the
old way, duplicating most of the OS functionality rather than using it
as the new app philosophy would have expected. So we had large and
cumbersome Norton Desktop for Win3.yuk, and the large and cumbersome
Norton Utilities for the original Win95.

While Win95 was being developed, Norton had an inside track; the beta
of 95 and Norton-for-95 ran in synch, with the goal that on release,
there would be a dedicated Norton Utilities ready for it - and that's
what happened. Win98 came and went, and I guess Norton did what most
vendors would do; pore over the resource kit to get it right.

Then WinME came out with no resource kit and much chest-thumping from
MS about how Win9x was a dead end and that devs should switch to NT
instead. So those apps that worked deep within the system expecting
this to be unchanged from Win98, were in for a shock; they clashed
with new-fangled deep subsystems such as SR and SFP.

By now, "Norton" is just a brand name for Symantec. It's an odd
choice of name for an av, given that Peter Norton was one of the last
to acknowledge the existances of viruses when they first came out.


------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top