Endpoint Protection

I have several Windows XP SP3 workstations that fail to install the latest client with a message like those for Vista.  I have reboot the systems repeatedly and followed the threads for clearing the error for Vista but the registry locations are not the same in XP although some are similar.  Any thoughts on getting the workstations to accept the new SEP client?  None of the workstations have ahad other AV clients except for SEP 11 (the first version).  I am working on testing and rollout of SEP MR4 MP1.

Paul Taylor

What's the error message that you see ? 

I am presuming but if it's "Symantec EndPoint Protection has detected that there are pending system changes that require a reboot."  then go for this:

 Take a backup of and delete the contents under the following key:.

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations 

 Make sure that your user account has permissions to this key.

Can you try to clean uninstall SEP and then do a fresh install on the client?

In answer to Paul Mapacpac: I have uninstalled the previous SEP Client then done the manual removal of all components and registry entries as noted on Symantecs FAQs and continue to get the error.  On my first post I attached a screen shot of that error.  So that workstation is currently unprotected.  My other two I have left alone (they still have the old client updating through the old SEPM server) since I suspect the same problem might occur.  However, I have 4 other machines with XP SP3 and similar software packages that upgraded fine without an uninstall.  They now receive updates from the new SEPM server and reside in the groups I have created.

In response to RickJDS:  I have checked the registry as indicated in the forums and do not find this key
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" .

I have the following key:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\FileRenameOperations.
The only string under that key is Name: (Default) Type: REG_SZ Data: (value not set).
I have backed up the key, renamed it to something else and deleted it to no avail.  I restored the key since it appeared to not be involved in the problem.

I also have a ControlSet001, ControlSet002, and a ControlSet003 but they also lack the key or have empty FileRenameOperations string.

I have also checked for the Winsxs folder (as noted for Vista) and it appears under my profile in the Documents and Settings folder not under the Windows Folder as noted for Windows Vista.  However, the Temp folder is not present nor  is the Pending.xml file.

I have about 50 to 60 workstations and servers that will be managed and another 10 to 15 that will be unmanaged as the users are remote consultants and communicate back primarily through e-mail.  So I would like to resolve the problem on the three that are failing before rolling out more clients as I can forsee this coming up on additional machines.  I predominantly have Windows XP SP3 environement but due to some lab equipment, I have several Win2K boxes and Win NT4 boxes remaining in the mix.

Paul Taylor

Have you tried using Microsoft Cleanup utility?

No I have not looked into that option.

Thanks
Paul Taylor

I have installed the utility but it seems like resorting to a brain transplant as it states that all MS Installer based apps will need to be reinstalled.  If this were a clean install I would be more apt to give it a shot, but all three affected workstations have a number of apps to reinstall.

While this may solve the problem, I would like to better determine the root cause.  Essentially, I could revert to the image of the workstation at its initial setup since I will be reinstalling all of the apps anyway.

I would like other options for setermining which registry key or windows folder might have something that to Endpoint Protedtion appears to require a reboot.  I can install other applications on my workstation (one of the three Win XP SP3 known affected) and none of them failed to install with a reboot required error lie SEP MR4 MP1a.

Paul Taylor

We are having the same problems with SP3 too, ill let you know what happens.

Well, its nice to know I'm not alone.  I'll keep digging to see what I can find.  Since  I am testing Hper V, I will set up a New XP SP3 VM and see if the trouble occurs on a clean install or begins after installing MS Office or other such components.

The three machines on which I am currently having trouble are physical boxes not VMs.

Paul Taylor

brightspot, please download and run the SEP Support Tool: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008071709480648

Part of its checks are pending reboots, it should give us an indication of where the problem lies

Hi brightspot, I did some testing on WinXP SP3 clients, and it was successful, just needed a restart. But I noticed that some components on Outlook generated errors, but only occurs on the first run, after its ok.

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" .

Either delete or rename it..
here PendingFileRenameOperations is Value so highlight Session Manager and you will see this value on the right hand.

I ran the support tool and checked the information flagged.  In the first run indeed Simple File Sharing was enabled.  I disabled it and verified that File/Print Sharing protocol was active.  I have a dual nic system (Intel Pro 1000).  The nics are link aggregated to give 2 Gbps, but the actual nics have file sharing disabled as well as many other protocols.  Instead the aggregated nic has all regular networking protocols running as one would expect for a typical nic. .  As of writing this, I am able to access the Internet and a colleague was copying a file via the network to an active share on my workstation.  So the network error should not be causing a problem as one nic has all of the required protocols for network access and file sharing enabled.

After running the utility, I still get the Reboot message and SEP fails to install either as stand-alone or managed.  The Management server pushed the install package to a Temp Folder in C: but once the

I ran the support tool and checked the information flagged.  In the first run indeed Simple File Sharing was enabled.  I disabled it and verified that File/Print Sharing protocol was active.  I have a dual nic system (Intel Pro 1000).  The nics are link aggregated to give 2 Gbps, but the actual nics have file sharing disabled as well as many other protocols.  Instead the aggregated nic has all regular networking protocols running as one would expect for a typical nic. .  As of writing this, I am able to access the Internet and a colleague was copying a file via the network to an active share on my workstation.  So the network error should not be causing a problem as one nic has all of the required protocols for network access and file sharing enabled.

After running the utility, I still get the Reboot message and SEP fails to install either as stand-alone or managed.  The Management server pushed the install package to a Temp Folder in C:.

ok, do you have a file called SEP_INST.LOG in C:\WINDOWS\TEMP ?

If so, open it up... have a search through for "return value 3" and then please post the previous ten lines of text.. there may be more than one instance

Paul Murgatroyd,

Yes, I do indeed have the Sep_Inst.Log file and the 10 lines preceeding Retun value 3 are as follows:

MSI (s) (F4:B8) [07:34:42:375]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'IsRebootRequiredOSAutoUpdate.B754A361_3344_430B_92FF_8F9A227A6B9'
MSI (s) (F4:F4) [07:34:42:391]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIB.tmp, Entrypoint: IsRebootRequiredOSAutoUpdate
Action start 7:34:42: IsRebootRequiredOSAutoUpdate.B754A361_3344_430B_92FF_8F9A227A6B9.
MSI (s) (F4:B8) [07:34:42:703]: Skipping action: iNoClientTypeDefined.9DDC0E81_9620_4441_B4F7_FD077F55D6D2 (condition is false)
MSI (s) (F4:B8) [07:34:42:703]: Doing action: LaunchConditions
Action ended 7:34:42: IsRebootRequiredOSAutoUpdate.B754A361_3344_430B_92FF_8F9A227A6B9. Return value 1.
Action start 7:34:42: LaunchConditions.
MSI (s) (F4:B8) [07:35:21:375]: Product: Symantec Endpoint Protection -- Symantec Endpoint Protection has detected that there are pending system changes that require a reboot. Please reboot the system and rerun the installation.

MSI (c) (E0:B8) [07:34:42:703]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

Symantec Endpoint Protection has detected that there are pending system changes that require a reboot. Please reboot the system and rerun the installation.
Action ended 7:35:21: LaunchConditions. Return value 3.


Paul Taylor

Hi, I'm also trying to fix the installation on our site. The only problem I see in the log files are as follows:

MSI (s) (34:A4) [21:50:41:833]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI11D.tmp, Entrypoint: SetInstallStateFailed
Action start 21:50:41: SetInstallStateFailed.1CBEC0D3_E547_4E51_828B_44B9C47C0EA5.

And this is the one at the end:

MSI (s) (34:C0) [21:55:42:986]: Product: Symantec Endpoint Protection -- Installation operation failed.

MSI (s) (34:C0) [21:55:42:986]: Cleaning up uninstalled install packages, if any exist
MSI (s) (34:C0) [21:55:42:986]: MainEngineThread is returning 1603
MSI (s) (34:FC) [21:55:42:986]: Destroying RemoteAPI object.
MSI (s) (34:A8) [21:55:42:986]: Custom Action Manager thread ending.
=== Logging stopped: 4/14/2009 21:55:42 ===
MSI (c) (DC:D0) [21:55:43:002]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (DC:D0) [21:55:43:002]: MainEngineThread is returning 1603
=== Verbose logging stopped: 4/14/2009 21:55:43 ===

Symantec Endpoint Protection has detected that there are pending system changes that require a reboot. Please reboot the system and rerun the installation.

https://www-secure.symantec.com/connect/forums/cant-install-sep-client-vista-os?sym=TRUE

SAV to SEP,

I have already checked this line, I do not have the Key mentioned in that thread or many others.  I have a similar Key which I have renamed and later deleted.  It has not changed my error or installation ability.  I have also looked at the Wiinsxs folder and not found the noted files there that some threads have mentioned. 

My system does not have the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
It has a similar key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\FileRenameOperations

This has a single line value with the following: Name: (Default)  Type: REG_SZ  Data: (value not set).  Neither renaming or deleting the line under the key or the entire key had any positive outcome on whether SEP MR4 installed.

Paul Taylor

mon_raralio,

I also get a similar code 1603 as noted below:

MSI (s) (F4:B8) [07:35:21:438]: Product: Symantec Endpoint Protection -- Installation operation failed.

MSI (s) (F4:B8) [07:35:21:438]: Windows Installer installed the product. Product Name: Symantec Endpoint Protection. Product Version: 11.0.4014.26. Product Language: 1033. Installation success or error status: 1603.

MSI (s) (F4:B8) [07:35:21:454]: Cleaning up uninstalled install packages, if any exist
MSI (s) (F4:B8) [07:35:21:454]: MainEngineThread is returning 1603
MSI (s) (F4:D8) [07:35:21:454]: No System Restore sequence number for this installation.
=== Logging stopped: 4/15/2009 7:35:21 ===
MSI (s) (F4:D8) [07:35:21:454]: User policy value 'DisableRollback' is 0
MSI (s) (F4:D8) [07:35:21:454]: Machine policy value 'DisableRollback' is 0
MSI (s) (F4:D8) [07:35:21:454]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (F4:D8) [07:35:21:454]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (F4:D8) [07:35:21:454]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (F4:D8) [07:35:21:454]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (F4:D8) [07:35:21:454]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (F4:D8) [07:35:21:454]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (F4:D8) [07:35:21:454]: Restoring environment variables
MSI (c) (E0:44) [07:35:21:454]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (E0:44) [07:35:21:454]: MainEngineThread is returning 1603
=== Verbose logging stopped: 4/15/2009 7:35:21 ===

It would appear that we are having a similar issue based simply on the errors noted in the installer logs.

Paul Taylor

First to check registry .Then run registry mechanic .You can run combofix also to solve the problem

Hi, what are the components added on your install package? Can you try AV and AS only?

Here are some of my suggestions.

1. Can you do a windows update before you install sep? see what happens
2. Try this procedure below

a) uninstall the Symantec EndPoint client (if installed)
b) Restart the computer
c) Run the Cleanwipe utility
d) Restart the computer
e) Push the Symantec EndPoint client to the targer computer
f) Restart the computer

Just to make sure that its not a permission issue, I would run all the instances of msiexec under the System account.

1) Goto Cmd prompt and type
at 11:11 /interactive cmd.exe

2) Goto c:\windows\tasks
and right click on the created task and run. A new cmd prompt window should open under the LSA. You can verify that in the task manager.

3) Drag and Drop the MSI to this new black window and execute.

Any difference?

Paul Mapacpac,

I did not have a client installed in your previous post but I did run Nonav.exe to ensure that any previous installations were gone.  I pushed a client with only AV and AS from the SEPM but it failed with the same "Pending system changes" message.

I can post the entire SEP_Inst.log file if that might be of use.

Paul Taylor

Sandeep Cheema,

I created the job as per your post.  The job created without errors and I was able to run the CMD from the job without problems.  However,  when I pulled the SEP installer msi file to the window, it loaded like a push or install from the setup.exe and failed with the same error as other attempts.

Paul Taylor

Paul Mapacpac,

I fogot to mention in my previous post.  As of Friday April 17, 2009, all of the outstanding updates for my system were instlled including the .Net 3.5 installation.  I am running Office 2k7 Pro and its updates were installed as well.  One thing I had forgotten since I don't usually sit and watch my workstation unless I am looking for something specific and do an interactive boot, my system is a dual boot to Windows Vista (32-bit).  I use Vista essentially never.  A year and a half ago, I needed to test several of our lab equipment apps to determine if they were compatible (they are not) and have not removed the dual boot status from my workstation.  Could this be related to the problem?

I have checked the Winsxs folder now under the Vista install, it is clean.  I fully patched and updated the Vista install Saturday so it should have no outstanding reboots.    XP is the default OS and loads from a 4 disk SATA Hardware RAID 5 array with 500 GB storage. Vista is installed on its own 500 GB SATA drive (not part of the RAID 5 array or a partition of it) so it does not share drive space with the XP install.

Sorry to have omitted this piece of information but I just spaced it off completely since I have not used Vista on this machine in about a year.  I will try to unplug the cable for the SATA drive which holds the Vista install to see if that changes anything.

Paul Taylor

Removing the Vista drive did not make any difference on the ability to install SEP MR4 either.  On that note, I will try to install SEP MR4 on the Vista install to see if that will work, at least I know what registry items to look for under Vista.  Both OSes were able to take the first release version without incident.  It has been on XP on my workstation for about two years and I installed it on  Vista as the first applivation after Vista setup was complete.

Paul Taylor

 

Symantec Tech,

I installed and ran Registry Mechanic, it found 996 errors.  I am relucatant to purchase a copy as nothing to this point has solved the problem.  I ran ComboFix as it is free and it found 2 errors which it corrected.  I rebooted and attempted to install SEP and the infamous "SEP has detected changes that require a reboot" error is still present.  I guess purchasing the PCTools Registry Mechanic won't break the bank, I just don't like to spend money on a potential fix unless I know it will truly fix the problem.  It appears the the "free" fixes aren't getting the job done though.  I don't like to be without AV protection for any length of time either.

Paul Taylor

We ran into the same issue on a Server 2008 machine.  The fix was to install Windows installer 4.5, and run the update found here http://www.microsoft.com/downloads/details.aspx?FamilyID=e0735d57-03cc-42e5-823e-60c9efe74aac&displaylang=en   After it was installed and rebooted the upgrade went with no issues.

D.

Thank you all for your assistance in tracking down the problem.  Indeed the problem turned out to be related to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations. Unfortunately for me, that value was hidden in the registry.  The file listed in that key was "\??\C:\WINDOWS\Temp\logishrd\LvPrcInj01.dll".  The key showed up after 31/2 passes of ComboFix (one pass didn't finish and blue screen my system).  After each pass I searched the registry again for PendingFileRename with out success.  Following the 4th pass, the search found the value, which I deleted and attempted to run setup from the C:\TEMP\Clt-Inst folder from one of the failed push attempts and it ran to completion. 

The LvPrcInj01.dll is supposed to be a support file for Logitech webcams.  It would appear that something tried to hijack the file or that some process attempted to rename or remove the file and failed to finish the job.  It does not report as if it is infected with a virus.  Usually when I see instances of hidden registry values it is due to a trojan or some form of RootKit. 

Upon rebooting the system following the successful install of SEP, I found one interesting side effect of deleting the PendingFileRenameOperations, the PendingFileRenameOperations value is back but it is now pointing to "\??\C:\WINDOWS\Temp\logishrd\LvPrcInj02.dll".  I searched the C drive for LvPrcInj*.dll and found the three following files:

1. LvPrcInj01.dll (the original file that casued my uninstall issue, still in "C:\Windows\Temp\logishrd")
2. LvPrcInj02.dll (the new file noted in PendingFileRenameOperations Key, also in "C:\Windows\Temp\logishrd")
3. LvPrcInj.dll (Located in "C:\Program Files\Common Files\logishrd\LVMVFM")
4. LvPrcInj01.dll (located in "C:\Qoobox\Quarantine\C\WINDOWS\Temp\logishrd", the ComboFix Quarantine folder)
5. Scanning these files with SEP does not report an infection. 

If you have any thoughts on LvPrcInj*.dll or experience with it, let me know.  I have several other users who have Logitech webcams, which we use occaisnally to conference with off-site consultants.  So when I push SEP MR4 to them, I will just check for this before trying to push SEP as it will probably save me a lot of time and frustration. 

Thanks again to everyone who contributed.
Paul Taylor

Thnks for the solution. It helped me a lot as I was facing the same problem with SP3.

Nice, will bookmark this post.

brightspot, based from the logitech website, LvPrcInj01.dll or LvPrcInj.dll is Logitech Video is the Logitech Video Effects library and they admit that they produce unexpected behavior or crashes with certain applications.

They recommend to use UMVPLReg tool found on their site to disable or enable this libraries/modules.

Paul Mapacpac,

Thanks for the additional info on the LvPrcInj*.dll.  I have already seen the problem again on one of the other computers to which I wanted to push SEP.  Fortunately I had the tools and trench experience to check first since I saw the Logitech Webcam setting on the monitor.  This one did not have the PendingFileRenameOperations key hidden though.  The only thing that might make a difference is that this one I built and installed the OS from the domain instead of it coming preinstalled from the vendor.  Thus the domain admins was the "local" admin (might make a difference on ownership of items and registry entries).

Paul Taylor

Is the logitech preinstalled on by the vendor too?

Thanks brightspot for additional info.

Paul Mapacpac,

No Logitech Webcams were added after the fact using either the accompanying software CD or in my case a download of the latest software for my older webcam.  The original drivers were not supported in Win XP SP2 or above and caused various errors with other programs and drivers.  As I recall, the older software lacked the new LVPrcInj.dll as that was needed to support some of the newer camera features and/or software features.

Paul Taylor

Hi   I Guess

This issue is related to inows and u should run Windowss update and  thoush u have alreay installed the product try to unsintall completely using Removall, like Cleanwipe and re-install it.

This could happen due to the regestry still contains some Symantec file in it.

Take a backup of and delete the contents under the following key:.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Make sure that your user account has permissions to this key.

Restart the machine and then try to install.

How is your solution different from my post or brightspot's post about his solution?

Can you run the SEP Support Tool to diagnose the system.. This gets more and more complicated..

As already discussed above Its PendinfFileRenameOperation ket that we have to either delete ,Rename or the best give permission to.
But why its not a problem with LvPrcInj*.dll .It can happen with any software even with Winddows updates.

When a software is installed it is always advised to restart the computer...because of Pending File Rename Operation and many more..
But if it is not restarted then issues like this happen.Its very common in Vista /2008/Win7.These OS will not let you install any software without rebooting after a successful/Failed install.

Sometimes even when the computer is rebooted the file is not renamed and remains pending.
The main reason for this is Registry permissions.If registry does not have enough permission to rename the file it will keep sitting there.
Unless it is manually deleted or given permission to.

Regards,
Vikram Kumar

I have pushed SEP MR4 to two other clients with newer Logitech webcams.  One of the systems had no issues, the push from the server went smoothly following which I rebooted.  SEP started normally with all three components up-to-date and showing normal status.  The second was just like my machine except that the PendingFileRenameOperations key was not hidden and was found simply doing a search in Regedit.  I deleted the key and the following attempt to push out SEP went without a hitch. 

I suspect that there may be some virus or other malware out that attempts to hijack the LvPrcInj.dll file since on my machine (the machine that prompted this thread) the PendingFileRenameOperations key was hidden, effectively hiding it from me and the domain admins account.  One root kit detector (RootKit Revealer) was not able to see the hidden key.  However, the Sophos AntiRootKit program saw it but at this point I was able to delete the key in Regedit.  In retrospect probably should have run Sophos AntiRootKit from the beginning.

The bottom line is that even when for me it appeared the the pendingFileRenameOperations was not the culprit, it was but the key was hidden and the problem appeared to be unrelated to previous installs of SEP although a number of you out there have had problems with installations over previous versions of SEP.

I have successfully pushed out SEP MR4 to 10 computers with previous versions of SEP without any problem, 3 computers that required a complete removal (used NoNav.exe to clean up previous installs) of the previous version(s) (bear in mind, these three have had Norton AV Corp Edition 8, 9, and 10 and SEP MR1 prior to SEP MR4), and three computers with an issue related to the LvPrcInj*.dll where LvPrcInj*.dll [LvPrcInj01.dll or LvPrcInj.dll] was noted in the PendingFileRenameOperations registry key which was deleted allowing the install to run normally.  Don't rule out the possibility that the PendingFileRenameOperations is there just because you can't see it or find it in a registry search, It may well have been hidden.  For me scanning with ComboFix made the key viewable in Regedit again.

Paul Taylor

having same issue

I'm having same issue installing SEP using Windows Vista home premium 32 bit OS on an Acer Aspire laptop model 4730Z.
  getting error message: 
"Symantec Endpoint Protection has detected pending system changes that require a reboot.  Please reboot the system and rerun the installation." 

I opened registry and went to,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ 
I hight lighted Session Manager and deleted the "PendingFileRenameOperations" key on the right hand side.
(How do  correctly backup and save this value?)

I do not see this same key in,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet001\Control\Session Manager\PendingFileRenameOperations

The installation gets partly through the install shield wizard and then rolls back actions. Tthe blue status bar runs backwards and I get this message,
"The wizard was interrrupted before Symantec Endpoint Protection could be comeletetly installed. Your system has not been modified. To complete installation at another time please run setup again." 
 

I have installed this on an XP machine without any problems.
Any ideas as to  the cause of this error?  Thanks

 http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007121609023348