Problem with Intelligent Updater file

Continuing from my previous posts... I have been following the situation and have just rechecked the Intelligent Updater page
https://www.broadcom.com/support/security-center/definitions/download/de...

To my horror, the entire fourth entry, ie. the definitions files for legacy software versions 22.6 or earlier, including all the file descriptions, has DISAPPEARED.  What happened?  Is Norton aware of the problem with the previous download 20220324-010-v5i32.exe, and has since worked on to fixed the issue on future defs updates files?  (I just hope they have not given up on all legacy version users like me...)

Meanwhile, I found the Rapid Release Virus Definitions page here
https://www.broadcom.com/support/security-center/definitions/download/de...

There's a definitions file for all legacy software versions dated 3-29-2022, so I downloaded it and tried to install -- but again, to NO avail.  Apparently this file also suffers from the SAME unrar.dll issue, as in the case of 20220324-010-v5i32.exe.

The file in question is
File Name: rapidrelease/symrapidreleasedefscore15-v5i32.exe | HTTP
Creation Date: 3/29/2022    
Release Date: 3/29/2022
File Size: 161.6 MB
MD5 | all: CD78D2B74AD494284336CCF98D68AA50

The logs for this failed definitions updates operation is as follows:
**************************************************************************************************************
Tue Mar 29 14:10:15 2022 : ******************************************************************
Tue Mar 29 14:10:15 2022 :         Starting Intelligent Updater - Version 5.1.8.36
Tue Mar 29 14:10:15 2022 : ******************************************************************
Tue Mar 29 14:10:15 2022 : AUTH SYMSIGNED BEGIN: Started.
Tue Mar 29 14:10:15 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Tue Mar 29 14:10:15 2022 : AUTH SYMSIGNED CLASS3: Finding code signing : TRUE.
Tue Mar 29 14:10:15 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Tue Mar 29 14:10:15 2022 : IU RES SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the iuResource DLL
Tue Mar 29 14:10:15 2022 : IU RES LOAD: Successfully loaded the resource file..
Tue Mar 29 14:10:15 2022 : Identified as 32-bit product installation. Continuing...
Tue Mar 29 14:10:15 2022 : IU MODE: IU is running is FULL mode.
Tue Mar 29 14:10:18 2022 : CONFIG LOAD SUCCESS: Successfully loaded the configuration file: iuConfig.xml.
Tue Mar 29 14:10:18 2022 :     IU INFO: File-name : SARCv5i32.EXE
Tue Mar 29 14:10:18 2022 :     IU INFO: Creation-date : 20220328
Tue Mar 29 14:10:18 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Tue Mar 29 14:10:18 2022 : Entry details:
Tue Mar 29 14:10:18 2022 :     Update-File:             VIRSCAN.zip
Tue Mar 29 14:10:18 2022 :     Update-Desc:             Virus Definitions
Tue Mar 29 14:10:18 2022 :     Auth DLL Name:             SAVIUAuth
Tue Mar 29 14:10:18 2022 :     Auth DLL Location:         local
Tue Mar 29 14:10:18 2022 :     Auth Content-Type:         virus definitions x32
Tue Mar 29 14:10:18 2022 :     Deploy Content-Type:         virus definitions x32
Tue Mar 29 14:10:18 2022 :     Deploy DLL Name:         SAVIUDeploy
Tue Mar 29 14:10:18 2022 :     Deploy DLL Location:         local
Tue Mar 29 14:10:18 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - SAVIUAuth
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG FAILURE: Failed while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - SAVIUDeploy
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG FAILURE: Failed while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : IGNORE ENTRY: Ignoring entry for VIRSCAN.zip because of registry read failure. Error occurred while reading the path for the Authorization DLL from the registry.
Tue Mar 29 14:10:18 2022 : The product corresponding to this entry in iuconfig.xml is not installed on the system.
Tue Mar 29 14:10:18 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Tue Mar 29 14:10:18 2022 : Entry details:
Tue Mar 29 14:10:18 2022 :     Update-File:             VIRSCAN.zip
Tue Mar 29 14:10:18 2022 :     Update-Desc:             Virus Definitions
Tue Mar 29 14:10:18 2022 :     Auth DLL Name:             ISAuthDLL
Tue Mar 29 14:10:18 2022 :     Auth DLL Location:         local
Tue Mar 29 14:10:18 2022 :     Auth Content-Type:         virus definitions x32
Tue Mar 29 14:10:18 2022 :     Deploy Content-Type:         virus definitions x32
Tue Mar 29 14:10:18 2022 :     Deploy DLL Name:         ISDeployDLL
Tue Mar 29 14:10:18 2022 :     Deploy DLL Location:         local
Tue Mar 29 14:10:18 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - ISAuthDLL
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG FAILURE: Failed while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - ISDeployDLL
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG FAILURE: Failed while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : IGNORE ENTRY: Ignoring entry for VIRSCAN.zip because of registry read failure. Error occurred while reading the path for the Authorization DLL from the registry.
Tue Mar 29 14:10:18 2022 : The product corresponding to this entry in iuconfig.xml is not installed on the system.
Tue Mar 29 14:10:18 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Tue Mar 29 14:10:18 2022 : Entry details:
Tue Mar 29 14:10:18 2022 :     Update-File:             VIRSCAN.zip
Tue Mar 29 14:10:18 2022 :     Update-Desc:             Virus Definitions
Tue Mar 29 14:10:18 2022 :     Auth DLL Name:             Norton X32 AuthDLL
Tue Mar 29 14:10:18 2022 :     Auth DLL Location:         local
Tue Mar 29 14:10:18 2022 :     Auth Content-Type:         VirusDefs
Tue Mar 29 14:10:18 2022 :     Deploy Content-Type:         VirusDefs
Tue Mar 29 14:10:18 2022 :     Deploy DLL Name:         Norton X32 DeployDLL
Tue Mar 29 14:10:18 2022 :     Deploy DLL Location:         local
Tue Mar 29 14:10:18 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - Norton X32 AuthDLL
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Succeeded while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - Norton X32 DeployDLL
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Success while opening key
Tue Mar 29 14:10:18 2022 : REG SUCCESS: Succeeded while fetching the path from registry.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED BEGIN: Started.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED CLASS3: Succeeded find the class 3 ID, returning TRUE.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the authorization dll C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Tue Mar 29 14:10:18 2022 : AUTH LOAD SUCCESS: Successfully loaded the authorization dll - C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED BEGIN: Started.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED CLASS3: Succeeded find the class 3 ID, returning TRUE.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Tue Mar 29 14:10:18 2022 : DEPLOY SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the deployment dll C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Tue Mar 29 14:10:18 2022 : DEPLOY LOAD SUCCESS: Successfully loaded the deployment dll - C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Tue Mar 29 14:10:18 2022 : AUTHORIZATION SUCCESSFUL: VIRSCAN.zip is successfully authorized for deployment.
Tue Mar 29 14:10:18 2022 : DEPLOY PATH SUCCESS: VIRSCAN.zip will be deployed at location C:\Program Files\Norton Internet Security\Norton Internet Security\NortonData\21.2.0.38\Definitions\VirusDefs\tmp74fa.tmp
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED BEGIN: Started.
Tue Mar 29 14:10:18 2022 : AUTH SYMSIGNED: Provider is unknown, returning FALSE.
Tue Mar 29 14:10:18 2022 : UNRAR FAILURE: UNRAR DLL is not Symantec Signed.
Tue Mar 29 14:10:18 2022 : ERROR: unrar.dll is not Symantec Signed. IU cannot continue processing. Terminating all IU operations.
Tue Mar 29 14:10:18 2022 : Cleaning up the AuthorizationEngine
Tue Mar 29 14:10:18 2022 : Calling ReleaseInstance() on the object of IIntelligentUpdaterAuthorizationManager2.
Tue Mar 29 14:10:18 2022 : After release
Tue Mar 29 14:10:18 2022 : Done cleaning up authorization engine
Tue Mar 29 14:10:21 2022 : Done with IU Operations
**************************************************************************************************************

Clearly there's a big problem with the UNRAR DLL component that prevents the definitions from success updating.
Can someone at NLL/BC Symantec please investigate and tackle on the issue?
For the record, I have not been able to update my NIS software's defs for more than four days already, and this is deeply concerning!

Can somebody please help??

G, the requested screencap is provided as above.  However, it appears to be irrelevant to the issue discussed here.

I'm pretty sure there's a problem with the UNRAR.DLL component (RAR Decompression Library) in the definitions file packages, and apparently it needs to be fixed by throwing back to a previous version.  Here's what I found:

1. The last good virus definitions update package that could be applied to my product is 20220323-024-v5i32.exe.  The UNRAR.DLL version used is 4.10 with a file size of 180kb;

2. The first defective virus defs update package, 20220324-010-v5i32.exe, contains a newer version of UNRAR.DLL, version 6.11.  The file size is around 277kb;

3. The problem is that version 6.11 of the UNRAR.DLL component is incompatible with the XP environment, due to the fact that RARLabs has discontinued XP support on its WinRAR products starting from version 6.10 (minimal requirement is now Vista). The last XP-compatible WinRAR version is 6.02.
The release notes on WinRAR is here
https://www.win-rar.com/whatsnew.html?&L=0

4. The VIRSCAN.ZIP file inside the updater package in question has no problems whatsoever, and can be extracted with any older version of WinRAR.  It is just that the UNRAR.DLL that is incompatible (with the XP environment) and thus fails to extract the zip file throughout the entire manual updating process.  Had the older UNRAR.DLL version (4.10) been retained in the updater package, the manual updating process would've completed without issue.

Meanwhile, on the Rapid Release Virus Definitions page...
https://www.broadcom.com/support/security-center/definitions/download/de...

The symrapidreleasedefscore15-v5i32.exe (for all legacy product versions, including v22.6) has been updated to March 30 (as we speak).  However, it too contains the newer UNRAR/DLL componnent (6.11) that is causing problems under the XP environment.

So apparently, the fix to the problem, as mentioned above, is to throw back to an older UNRAR.DLL version, prior to 6.02.  Only then would any subsequent IU updater packages be applied to the products concerned (under XP) without issue.

So please take my suggestion and use the older (but correct) UNRAR/DLL component on these manual IU updater packages.  It has been five days since my last IU update and now my NIS keeps saying that my virus defs are outdated.  Please make an effort to help out legacy customers like us!

As of this writing, the problem concerned has still NOT been resolved.  What the heck is happening here NLL?  This is a serious issue, as those having the need to run Intelligent Updater cannot update the definitions files past March 23.  Can someone at NLL please treat this matter with a bit more priority??

@SoulAsylum

The simple answer to your question, is NO -- your suggestion does NOT work (I've already tried, but no dice).

The definitions updater package contains the following components:
- intiupdater.exe
- iuconfig.xml
- iuresource.dll
- unrar.dll
- VIRSCAN.ZIP

The VIRSCAN.ZIP can be locally unpacked using any existing decompressor program in the system, without any issue.  However, this is of NO use because the intiupdater.exe has specific instructions in running the updater operation, and that it needs to run through the UNRAR.DLL check, before using this bundled DLL to unpack VIRSCAN.ZIP, save the contents into a temporary file (of random filename eg. tmpxxxxx), then have the rest of the updater process append the new definitions updates into the product application and complete the update process.  And this process cannot be tempered, AFAIK.  In other words, the updater process will NOT recognize the unpacked VIRSCAN.ZIP contents other than the ones initiated by this very updater process.

Right now I can only determine that the UNRAR.DLL is faulty as it is, per the update logs, "not Symantec-signed" and thus the entire IU operation terminates.  However, it is also highly possible that this new version of UNRAR.DLL (6.11, previously 4.10) has compatibility issues with XP (as WinRAR product support for XP ends after version 6.02), and if this is the case, then Symantec must take steps and revert to a previous WinRAR product (eg. 5.91 or earlier) when prepping and packing the virus definitions files for web download.

And as of this writing, this problem has still NOT been rectified.  I also note that the entire Intelligent Updater scheme was concocted and managed by Symantec during the time when Symantec and Norton were still as a whole.  I don't know if there are any grudges, conflicts between the current state of BC/Symantec and NLL, even though they're still sharing resources like the virus definitions as discussed here.

I did try to contact BC Symantec and sent a message reporting this problem, complete with all the details.  The message went through, but I've still yet to receive any reply (despite having checked the box in the message form asking for a reply).  This is really, really frustrating now.......

@lmacri
Thanks for participating in this thread discussion.  You're mostly correct regarding my situation, as discussed before.

Please read all my previous posts (and all accompanied log lines) on this thread for a better description of the problem I've reported.  I believe I've basically covered everything I know (or learned about this problem).

Now, a few things to add or clarify:

1. The entire Intelligent Updater mechanism has been rendered faulty since March 24, due to the newer UNRAR.DLL (version 6.11) embedded in ALL of the definitions updater executables issued since the said date.  So all users who need to use this manual definitions updating routine will be affected (at least from the XP perspective).

For instance, even if I have NIS legacy version 22.x installed (and running) on XP, if for any reason I cannot run Live Update and have to revert to the manual Intelligent Update routine, then I'll run into the VERY SAME problem of NOT ABLE to update the definitions files.  (Simply put, the IU updater logs do NOT lie.)

So just to reiterate: ALL Norton software versions (legacy pre-22.6 and current post-22.7), as well as certain Symantec Endpoint Protection products, are affected by this UNRAR.DLL (v6.11) fiasco, which has rendered IU operation crippled;

2. I continued to stick with software version 21.7.xx after the events of March 2020 (regarding forced "hijacked" version upgrade via Live Update, without prior notice) because at that point the reputation and usability of NIS v22.x has become highly in question.  Do be reminded that, the problem regarding "Application Memory Error" on XP first occurred since 2015 when NIS v22.x first rolled out.  When I realized the problem was with v22 I quickly ghosted back my system to when v21.7.xx was still in place, and continued to use it, having switched off all user preferences regarding "Automatic Download of New Version" and such.  I also reported the problem to the Forum admin (which happened to be G_R back then), and was instructed to submit data logs regarding those error instances, which I did, but NOTHING had been done afterwards, resulting in the problem having stalled for some SIX years until March 2020, when the problem had to be revisited again after the forced hijacked software version upgrade was rolled out; only this time, the "Application Memory Error" became consistent on various program/application exits.  But even though NLL has announced that they've released a newer legacy v22.x build version to fix the (Application Memory Error) problem on April 2020 (after having submitted additional log data upon request), at that point I simply could not trust them, also having known that v22 has suffered from other performance and stability issues which would further drain my system resources.

As a result, since April 2020 (after suffering from software version v22.x for a month), I've continued to stick to v21.7.x while switching to IU.  I've been downloading the IU updater packages since then, EVERY DAY, to at least keep my virus definitions updated (even though I knew I would be missing other "dynamic" updates, as well as to live with the software product's security vulnerabilities as you've stated).

The other reason I find it extremely concerning on deployment of software version v22.x is the so-called "Silent Upgrade" routine, where upon execution (after running LU), the entire system gets commandeered by the process (Norton Update Agent?) like a virus (you can't even shut down the system).  This involves slowing tearing down the existing software version, bit by bit, then gradually reinstalling with the newer version components, again bit by bit, to the point that the user is prompted to restart.  Then, after a few more updates and restarts, the software v22.x becomes in place.  This entire process could take at least 3-4 hours, perhaps even more.  This was not the case with older versions, where you would simply download the newer version and let the process perform a top-off upgrade and such.  Seriously, why NLL can't present such v22.x upgrade in a more transparent way (or at least, as before) is beyond everyone's understanding;

3. Just to reiterate, the last good IU updates definitions packages that I could apply to my NIS v21.7.x, was dated March 23, where the executable was packed apparently with an older WinRAR version, resulting in an older UNRAR.DLL version (4.10) embedded inside.  But since the 24th, I have NOT been able to do the same update because of the new embedded UNRAR.DLL fiasco.  To be specific, while I was able to download the daily definitions updater executables, I simply COULD NOT apply and append those updates to my NIS product because the problematic UNRAR.DLL (v6.11) gets in the way, thus terminating the entire IU process (refer to the specific log lines from my previous posts for reference);

4. I have not been able to test the definitions updater packages in question on other systems (eg. w7).  However, I do not believe the WinRAR's XP compatibility issue appears purely coincidental.  Also, why Symantec/Norton was sticking to an older WinRAR product (ver 4.x) for so long, then suddenly "migrated" to the newer 6.x while skipping 5.x (5.x has been in place for the past few years)?  Do be reminded that the last XP-compatible WinRAR product is 6.02, but that the UNRAR.DLL embedded in the current updater executable is 6.11.  Could this be the reason why the UNRAR.DLL in question cannot get recognized, resulting in the "UNRAR.DLL not Symanted-signed" status in the updater log?  IMO, had Symantec/Norton migrated to the older WinRAR v5.x for packing the definitions updater packages, then perhaps all these issues might not (and would not) have happened.

And it seems to me that those at Symantec/Norton may have totally missed the WinRAR's system compatibility issue when switching to the newer product version in their workflow (also at an odd time of the month).  That said, I'm NOT all convinced that such action is due to security concerns.  In fact, the Intelligent Updater process appears to be a very secure one, as the UNRAR.DLL inside such updater executable CANNOT be swapped with another one from another definitions updater executable.  In other words, in order for the bundled VIRSCAN.ZIP package to be unpacked and appended to the software product, the IU process needs to go through the bundled UNRAR.DLL and nothing else, and only after the UNRAR.DLL has been authenticated (see log lines from my previous posts regarding the successful instance of UNRAR.DLL authentication).

And since NLL/Symantec are customers of RARLabs and thus have the necessary licenses to run the WinRAR product(s), it is actually not difficult for them to fallback to an older product version (6.02 or earlier), when necessary, to deal with their IU definitions packaging/unpacking workflow;

5. I've mentioned this before, and I'll say this again: the Intelligent Updater scheme was concocted back when Symantec/Norton were still a single entity.  Even though now both brands are separated in some ways, both parties need to be accountable when dealing with crises like this, ie. this IU mishap.  I don't know why this matter has been stalled for so long, but I have a feeling that both current parties are skirting responsibility at some point; as when I tried to contact BC Symantec regarding the issue, at one instance I was asked to refer back to NLL instead, which is ridiculous, as this IU fiasco also affects their products as well (ie. Symantec Endpoint Protection).  Why the current state of BC Symantec and NLL have resulted in so much disharmony (or finger pointing), I have no idea.  I do however believe that, had this problem occurred some ten years back, it would've have been probably resolved within weeks, if not days.

@lmacri
@SA
Many thanks for the BC reference.  Exactly what's been happening all these weeks; everyone in that form thread were dead-on, especially Gino.

What is shocking to hear is from Fred's post, saying:
"Have the same issue with Endpoint Protection 14.2 standalone on Windows Server 2012 R2 (officially supported OS) applying latest definitions file 20220419-003-core15sdsv5i64.exe. "

Glad that other professional customers also found the problem (at the time I did) and were voicing concerns as well, but sadly the BC side has not been enthusiastic (or serious) enough to tackle the issue, which prompts me suspect that BC may be trying to skirt responsibility.

Earlier this month I also tried (again) to contact BC to report on the problem.  The Case # is [Removed].  But the response?
*********************************************************************
"Greetings from Broadcom

This is in regards with Case # [Removed].

We request you to please contact Norton. For more information please check https://support.norton.com/sp/en/in/home/current/contact

Thank you for contacting Broadcom Support

Regards,
Arvind Sharma
Broadcom Customer Assistance"
*********************************************************************

This kind of questionable attitude is ridiculous and should NOT be tolerated.  And especially in this case, both BC/Sym and NLL need to come together to solve the problem.  Only that the NLL side could only do as much, and the rest would be up to BC/Sym to take responsibility for this mess.

[Edit: Removed case ID to conform with the Participation Guidelines and Terms of Service]

@Ronny7
Yes I noticed that as well.  However, it is too early to assume that NLL and BC/Sym have finally realized the problems as discussed throughout this entire thread, and have proceeded to repack all definitions updater packages via the older WinRAR workflow (pre-6.02), as the Rapid Release Virus Definitions page has not been equally taken down for similar maintenance
https://www.broadcom.com/support/security-center/definitions/download/de...

In other words, the definitions updater executable "symrapidreleasedefscore15-v5i32.exe"  from the aforementioned Rapid Release page is still being packed via the newer WinRAR workflow, which is incompatible with XP.

If you have not read this thread completely to understand the scope of the problem, may I suggest that you do that again.  Read EVERY post here and all the provided information and observations, to understand the severity of the problem.

But anyway, here's a recap:

1. The virus definitions updater packages from the Intelligent Updater (IU) page stopped working on XP clients since March 24.  This is due to an improper WinRAR workflow upgrade at NLL/BC Sym that is incompatible with tne XP environment;

2. The virus defs updater packages (executables) from the IU page are currently packed via WinRAR 6.10 or later, with the accompanied Dynamic Library file UNRAR.DLL version being 6.11.  This version of UNRAR.DLL is incompatible with the XP environment as the embedded root certificates cannot be properly interpreted under XP.  As a result, when running IU, this UNRAR.DLL CANNOT be authenticated by the IU process scripts, and thus IU operation terminates without unpacking the bundled VIRSCAN.ZIP archive and appending the contents to the client's software product;

3. In order for IU to be compatible down to XP, an older (fallback) WinRAR workflow needs to be reinstated, ie. earlier than version 6.02 (5.91 recommended) where the UNRAR.DLL version is maintained at 5.10, which is XP-compatible;

4. The botched WinRAR workflow is entirely of NLL and BC/Sym's fault.  In order to resolve the problem, it will be up to these entities to take the initiative to revert to the said older WinRAR workflow, or else the IU will continue to be rendered incompatible with XP environment;

5. This problem affects BOTH consumer customers (from the NLL side) as well as enterprise customers (from the BC/Sym side, who are running Symantec Endpoint Protection software on XP clients);

6. This issue has been elevated to NLL a few times, yet no progress has been reported throughout the past weeks at all.

But that's NOT all.  Apparently, even Live Update (LU) is affected, given the same logic.
Refer to this thread
https://forum-ru--board-com.translate.goog/topic.cgi?forum=5&topic=24492...

... and notice member Strannik06's comment below:
"I'm investigating the problem further, I found that in  
C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\data\liveupdate\LiveUpdateDownloads
 
All databases are downloaded new, in ZIP format.
It turns out that LiveUpdate works fine, the databases are downloaded, but they cannot be installed.
What could be the problem?"

This can be a strong indication that, all ZIP resources deployed via Live Update are also being packed via the newer WinRAR workflow, which, under XP, CANNOT be unpacked via the accompanied UNRAR.DLL (v6.11); as a result, under XP environment, Live Update operation will fail and terminate.

@Matt_Boucher
Please refrain from posting curt and insensitive comments like you did.  Read this entire thread carefully to understand the scope of the problem.  Your comments are of NO help except to result in more customer resentment, and to berate those who are in need of a fix from this very ordeal here.

My problems with NIS/NS 22.x.x on XP dated from mid-late 2015 and continued throughout 2020.   I chose to hang on to NIS 21.7.xx as version 22.x has given me a horrible user experience under XP, and even after NLL claimed they've fixed the problems I've reported since having released a newer legacy v22.x build in April 2020, I simply lost faith with v22.x.  All these have been mentioned from a few other threads in this Community Forum; I suggest that you go research them.

@SA
Sorry but I've been offline from desktop for the past 12+ hours.

Just to clarify, my original issue was supposedly with the update package 20220324-010-v5i32.exe (or similar, issued after the noted date), but that package has been removed from the general IU updater page and replaced with something smaller.  Only upon more digging did I realize it's not just one update package that has been affected, but ALL of them.

Unfortunately the defs update package you've referenced in your post, the "20220614-002-core15sdsv5i32", does NOT work in my case.  This is expected as the UNRAR.DLL involved is still on 6.11 which is incompatible with XP (due to the root certs not properly recognized by the IU scripts process).  The log is as follows:

******************************************************************************

Sat Jun 18 17:33:34 2022 : ******************************************************************
Sat Jun 18 17:33:34 2022 :         Starting Intelligent Updater - Version 5.1.8.36
Sat Jun 18 17:33:34 2022 : ******************************************************************
Sat Jun 18 17:33:34 2022 : AUTH SYMSIGNED BEGIN: Started.
Sat Jun 18 17:33:34 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Sat Jun 18 17:33:34 2022 : AUTH SYMSIGNED CLASS3: Finding code signing : TRUE.
Sat Jun 18 17:33:34 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Sat Jun 18 17:33:34 2022 : IU RES SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the iuResource DLL
Sat Jun 18 17:33:34 2022 : IU RES LOAD: Successfully loaded the resource file..
Sat Jun 18 17:33:34 2022 : Identified as 32-bit product installation. Continuing...
Sat Jun 18 17:33:34 2022 : IU MODE: IU is running is FULL mode.
Sat Jun 18 17:33:36 2022 : CONFIG LOAD SUCCESS: Successfully loaded the configuration file: iuConfig.xml.
Sat Jun 18 17:33:36 2022 :     IU INFO: File-name : 20220614-002-Core15SDSv5i32.EXE
Sat Jun 18 17:33:36 2022 :     IU INFO: Creation-date : 20220614
Sat Jun 18 17:33:36 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Sat Jun 18 17:33:36 2022 : Entry details:
Sat Jun 18 17:33:36 2022 :     Update-File:             VIRSCAN.zip
Sat Jun 18 17:33:36 2022 :     Update-Desc:             Virus Definitions
Sat Jun 18 17:33:36 2022 :     Auth DLL Name:             SAVIUAuth
Sat Jun 18 17:33:36 2022 :     Auth DLL Location:         local
Sat Jun 18 17:33:36 2022 :     Auth Content-Type:         virus definitions core 1.5 sds x32
Sat Jun 18 17:33:36 2022 :     Deploy Content-Type:         virus definitions core 1.5 sds x32
Sat Jun 18 17:33:36 2022 :     Deploy DLL Name:         SAVIUDeploy
Sat Jun 18 17:33:36 2022 :     Deploy DLL Location:         local
Sat Jun 18 17:33:36 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - SAVIUAuth
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG FAILURE: Failed while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - SAVIUDeploy
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG FAILURE: Failed while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : IGNORE ENTRY: Ignoring entry for VIRSCAN.zip because of registry read failure. Error occurred while reading the path for the Authorization DLL from the registry.
Sat Jun 18 17:33:36 2022 : The product corresponding to this entry in iuconfig.xml is not installed on the system.
Sat Jun 18 17:33:36 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Sat Jun 18 17:33:36 2022 : Entry details:
Sat Jun 18 17:33:36 2022 :     Update-File:             VIRSCAN.zip
Sat Jun 18 17:33:36 2022 :     Update-Desc:             Virus Definitions
Sat Jun 18 17:33:36 2022 :     Auth DLL Name:             ISAuthDLL
Sat Jun 18 17:33:36 2022 :     Auth DLL Location:         local
Sat Jun 18 17:33:36 2022 :     Auth Content-Type:         virus definitions core 1.5 sds x32
Sat Jun 18 17:33:36 2022 :     Deploy Content-Type:         virus definitions core 1.5 sds x32
Sat Jun 18 17:33:36 2022 :     Deploy DLL Name:         ISDeployDLL
Sat Jun 18 17:33:36 2022 :     Deploy DLL Location:         local
Sat Jun 18 17:33:36 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - ISAuthDLL
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG FAILURE: Failed while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - ISDeployDLL
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG FAILURE: Failed while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : IGNORE ENTRY: Ignoring entry for VIRSCAN.zip because of registry read failure. Error occurred while reading the path for the Authorization DLL from the registry.
Sat Jun 18 17:33:36 2022 : The product corresponding to this entry in iuconfig.xml is not installed on the system.
Sat Jun 18 17:33:36 2022 : PROCESSING ENTRY: VIRSCAN.zip - Virus Definitions
Sat Jun 18 17:33:36 2022 : Entry details:
Sat Jun 18 17:33:36 2022 :     Update-File:             VIRSCAN.zip
Sat Jun 18 17:33:36 2022 :     Update-Desc:             Virus Definitions
Sat Jun 18 17:33:36 2022 :     Auth DLL Name:             Norton X32 AuthDLL
Sat Jun 18 17:33:36 2022 :     Auth DLL Location:         local
Sat Jun 18 17:33:36 2022 :     Auth Content-Type:         SDSDefs
Sat Jun 18 17:33:36 2022 :     Deploy Content-Type:         SDSDefs
Sat Jun 18 17:33:36 2022 :     Deploy DLL Name:         Norton X32 DeployDLL
Sat Jun 18 17:33:36 2022 :     Deploy DLL Location:         local
Sat Jun 18 17:33:36 2022 : AUTH DLL LOCATION: IU will read the DLL location from registry - Norton X32 AuthDLL
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Succeeded while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : DEPLOY DLL LOCATION: IU will read the DLL location from registry - Norton X32 DeployDLL
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Success while opening key
Sat Jun 18 17:33:36 2022 : REG SUCCESS: Succeeded while fetching the path from registry.
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED BEGIN: Started.
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED CLASS3: Succeeded find the class 3 ID, returning TRUE.
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the authorization dll C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Sat Jun 18 17:33:36 2022 : AUTH LOAD SUCCESS: Successfully loaded the authorization dll - C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED BEGIN: Started.
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED CLASS3 BEGIN: Entering CriticalSection Initialization .
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED CLASS3: Succeeded find the class 3 ID, returning TRUE.
Sat Jun 18 17:33:36 2022 : AUTH SYMSIGNED END: Finished processing. Returns TRUE
Sat Jun 18 17:33:36 2022 : DEPLOY SYMSIGNED SUCCESS: Successfully verified Symantec Signature for the deployment dll C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Sat Jun 18 17:33:36 2022 : DEPLOY LOAD SUCCESS: Successfully loaded the deployment dll - C:\Program Files\Norton Internet Security\Norton Internet Security\Engine\21.7.0.11\NUMEng.dll
Sat Jun 18 17:33:36 2022 : AUTHORIZATION SUCCESSFUL: VIRSCAN.zip is successfully authorized for deployment.
Sat Jun 18 17:33:37 2022 : DEPLOY PATH SUCCESS: VIRSCAN.zip will be deployed at location C:\Program Files\Norton Internet Security\Norton Internet Security\NortonData\21.2.0.38\Definitions\SDSDefs\tmp495c.tmp
Sat Jun 18 17:33:37 2022 : AUTH SYMSIGNED BEGIN: Started.
Sat Jun 18 17:33:37 2022 : AUTH SYMSIGNED: Provider is unknown, returning FALSE.
Sat Jun 18 17:33:37 2022 : UNRAR FAILURE: UNRAR DLL is not Symantec Signed.
Sat Jun 18 17:33:37 2022 : ERROR: unrar.dll is not Symantec Signed. IU cannot continue processing. Terminating all IU operations.
Sat Jun 18 17:33:37 2022 : Cleaning up the AuthorizationEngine
Sat Jun 18 17:33:37 2022 : Calling ReleaseInstance() on the object of IIntelligentUpdaterAuthorizationManager2.
Sat Jun 18 17:33:37 2022 : After release
Sat Jun 18 17:33:37 2022 : Done cleaning up authorization engine
Sat Jun 18 17:33:37 2022 : Done with IU Operations
******************************************************************************

Here's a recap of what the other NLL employee ("dkane") has commented earlier (post removed/not shown here for whatever reason):
**************************************************************************************
15-Jun-2022 | 2:29PM: dkane commented on Problem with Intelligent Updater file

<<Broadcom employee now>>

SoulAsylum is correct about XP support:
Intelligent Updater isn't supported on Windows XP because the patched version of unrar.dll doesn't support the OS.

Separately:
Intelligent Updaters are missing for all Norton clients as of last Friday.

A new SDS engine is being rolled out and we noticed incompatibilities between the old and new engine. We paused the rollout and removed the updaters so people don't get mixed versions. Everyone using automatic LiveUpdate continues to receive the appropriate protection updates. The engine release is expected to resume tonight or tomorrow, pending last-minute testing, and Intelligent Updaters will be published at that time.
**************************************************************************************

To those who were wondering what happened to the IU page where all defs updates packages have been pulled off, the SDS issue fix was why.

But still, no explanation is given on why their WinRAR workflow was upgraded to 6.1+, where previously it was on 4.1.  Just to reiterate, in order for IU (and perhaps even LU) to be compatible with down to XP, the WinRAR workflow would need to be maintained at a version compatible with XP, in this case, Version 5 (5.91 being the final v5 release) where the UNRAR.DLL version is kept at the XP-compatible 5.10.  Yes, I've read about security issues with older WinRAR workflow since v4, but have they actually considered v5?  And, while migrating to v6.1+, have they actually considered the effects on XP compatibility?  It seems to me that, BC/Sym has failed to observe that while hastily doing the WinRAR workflow migration, then realized the XP issue, but that they were brazen enough to stick to the mistake and such and make all sorts of excuses stalling the problem, and not fixing the problem.

On separate note, I was touch-basing with another forum member from the BC/Sym forum side, He told me he still has 100+ w2003 clients to maintain, and this IU problem is bothering him as well.  I'm not going to challenge why he hasn't migrated those clients to a newer OS; every customer has reasons to still maintain legacy OS environments, even though those reasons are often not justified in Forums like here.  But as tech entities (service providers etc.), they need to understand and respect such customers in need and to provide all the support available.  Right now, however, I don't see BC/Sym and NLL committing to that -- especially since NLL has announced back in early 2021 that they'll continue to support legacy XP/Vista clients, noting that there's still a plethora of users (paid customers) that still need to maintain XP clients.

There's now one more concern on my side.  In fact I've been considering upgrading to the legacy 22.x (22.15.5.40?) software version at some point, and let it run on LU.  But now, given the circumstances on the UNRAR/DLL issue, How do I know if I can do so without problem??   Can somebody at NLL answer this question?

I may probably give it another two weeks before I try the v22.6.x upgrade again (even though, I do NOT like NLL's "Silent Upgrade" routine which acts like a virus commandeering the entire OS during the install).  As for the problems with 22.6.x on XP regarding the Application Memory Error issues, we'll see from there, even though NLL has claimed that the updated legacy build version (circa April 2020) has fixed just that, who knows if the problem would return again.

But however that is, if the objective is to support customers down to the legacy XP/Vista then BC Sym and NLL must make sure they'll stick to that promise (at least for the time being).  And thus, instead of updating everything to the next higher number (which is a huge problem within the tech culture), making a small step backwards (plus a little sacrifice) to ensure the legacy compatibility is what they'll need to consider.

I think NLL needs to push this matter harder when they deal with the BC/Sym side.