3 Replies Latest reply on Nov 28, 2011 2:28 PM by bluenotefan

    VSE 8.8 Install Error



      I've been deploying VSE 8.8 across my organization, and for the most part have run into very few problems. However, there are a handful of machines returning the "Event ID: 10005

      McAfee VirusScan Enterprise does not function if there are UNC shares included in the PATH environment variable" error. I understand the reason for this error and the reason McAfee doesn't support the use of UNC paths in the environment variable.


      What I don't understand is why I'm receiving this error on a handful of machines that do NOT have a UNC path in the environment variable.


      This is the data in the environment variable from a Windows XP SP3 machine that is failing to install with the above error message:



      %SMS_System_Path%;C:\Program Files\Common Files\OTG;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Prog ram Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\BEA Systems\MessageQ\Bin;C:\Program Files\Attachmate\EXTRA!\;C:\Program Files\Windows Imaging\


      At first I thought that %SMS_System_Path% might resolve to a UNC path, but it resolves to C:\PROGRA~1\Siemens\ACTIVE\OVERRIDE which is a valid directory on the local machine.


      I am at a loss. Any suggestions as to the cause of this problem would be greatly appreciated!

        • 1. Re: VSE 8.8 Install Error

          A shot from the hip: process monitor log might provide further insight, hopefully we can see what the msi installer is doing. Bear in mind that the OS is doing all the work in this case, talking to the msi installer etc.

          • 2. Re: VSE 8.8 Install Error

            Try re-ordering the path statement to start with c:\  Could be VSE is seeing the first entry as a UNC Share and stopping the install at that point.  Or remove the %SMS_System_Path% entry and see what happens.

            1 of 1 people found this helpful
            • 3. Re: VSE 8.8 Install Error

              Figured it out. Turned out it wasn't a path variable that was hard-set in the registry. It was one that was being loaded into memory by a specific application when the app was first run. Hopefully, I will be able to sidestep this by performing the install after the end-user has logged off.


              Thanks for everyone's input.