none
Beware the Office File Validation Add-In for Office 2003 and 2007

    Question

  • The Office File Validation Add-In for Office 2003 and Office 2007 has appeared on Microsoft Update (KB 2501584) as an important update. It has a disastrous effect on opening large XLS files from network shares using Excel 2003. Some large files we have open in a second before the add-in is installed and take 10 minutes afterwards. The same file copied to the local drive will open in a second again.

    This is more or less admitted in KB 2501584 under known issues: "Opening files from a network share that have many charts or points of data will take longer to open in Office 2003".

    Office File Validation can be turned off on a per user basis in the Registry: http://technet.microsoft.com/en-us/library/gg985445(office.12).aspx, but if you have large XLS files on network shares and still have some Office 2003, you might find it easier not to let this beast install.

    I really don't understand why this was allowed out with these "known issues".

    Wednesday, June 29, 2011 6:10 PM

Answers

All replies

  • Yes, I second this completely. Beware of this update! We are having the same thing happening - opening large XLS files from network shares with Excel 2003 are not only taking way longer than they did before update KB 2501584, but most of the time Excel hangs and needs to be closed through the Task Manager.
    Thursday, June 30, 2011 1:10 PM
  • Any chance of a sample registry key for an Office 2003 to remove this validation thing? Had 3 calls already today about excel hanging.
    Thursday, June 30, 2011 1:46 PM
  • Windows Registry Editor Version 5.00

    [HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Excel\Security\FileValidation]
    "EnableOnLoad"=dword:00000000

    This solved the issue for the Excel files in my case.

    • Proposed as answer by BenSBB Monday, June 10, 2013 8:14 PM
    Thursday, June 30, 2011 3:38 PM
  • Neil,
    You are dead on correct with this update, MS released it without properly testing it. Every one of my users that uses their Excel files over the network (which is all of them) is now having very long delays and hangs when trying to access those files after applying this update. I did the registry fix recommended in the technet article that you linked to above and it appears to have fixed the problem. What concerns me even more is that you can't remove this update, you can only tell it not to scan the files. Microsoft needs to release a fix for this issue or a better way to turn it off, other than a registry fix. Thanks for posting the information above as it was very helpful.
    Thursday, June 30, 2011 6:42 PM
  • Scorch -

     

    I was able to remove the update - went through "Add or Remove Programs" on Windows 7; I agree it wouldn't let me remove the update through the normal remove update process.

    Thursday, June 30, 2011 11:20 PM
  • For Windows XP/Office 2003, KB 2541025 is related to this.  This is the update I had to remove to be able to open Excel files in timely manner off of network share on one of our workstations.
    Monday, July 04, 2011 9:33 AM
  • Yep, same problem here and I even anticipated it and tried it on a few excel files, however didn't try it on some of the larger ones and they take forever to open.  Thank you Microsoft for another dud update for Microsoft Office 2003.
    Monday, July 04, 2011 2:53 PM
  • Is this patch related to kb2541763? Our Users are experiencing the same issues you are mentioning in this thread after installing this patch.
    Tuesday, July 05, 2011 7:56 AM
  • I have the problem here also with around 200 restricted users.  I have the registry key that will Disable it but when it is added to the startup script the restricted users do not have access to edit that part of the registry. Is it possible to put it in HKLM instead of HKLU? What is the best way to apply this regedit?  Or better yet ... has anyone figured out a way to uninstall it via script to every PC in the network?

    Let me know,

    CoderXMan


    Tuesday, July 05, 2011 8:54 PM
  • Are you in a Windows domain? Then you can use Group Policies to distribute the Registry entry. With Windows 2008 R2 you can even enter the registry value directly without creating an adm file first.

    The uninstall string is

    MsiExec.exe /I{90140000-2005-0000-0000-0000000FF1CE}

    You can run it via computer startup script or with psexec.

    Tuesday, July 05, 2011 9:46 PM
  • I am in a Server 2003 domain.

    I ran the uninstall string (logged in as Administrator on an WinXP PC) you supplied and it went through the motions but the MS Office File Validation Add-In is still listed in the add/remove programs on the machine.

    Wednesday, July 06, 2011 3:31 PM
  • It seems Microsoft left the wrong uninstall string in the Registry. Try

    MsiExec.exe /X {90140000-2005-0000-0000-0000000FF1CE} /qn

    Thursday, July 07, 2011 7:47 AM
  • Come on Microsoft! We are not paying the money for this kind of trouble~ You may add-on more security but please do preserve the performance!

    Friday, July 08, 2011 3:53 PM
  • It seems Microsoft left the wrong uninstall string in the Registry. Try

    MsiExec.exe /X {90140000-2005-0000-0000-0000000FF1CE} /qn


    In a WSUS scenario, has un-approving the update removed it properly, or do we have to run the command above to fix this in any scenario?
    Monday, July 11, 2011 6:38 PM
  • Thanks, Alexander! That helped immensely. I wrote the following group policy template and applied to all users in an OU, seems to have corrected the problem for everyone.

    CLASS USER

    CATEGORY !!LocalHack
     KEYNAME "Software\Policies\Microsoft\Office\11.0\Excel\Security\FileValidation"
     POLICY !!EnableKB2541025
      #if version >= 4
       SUPPORTED !!SUPPORTED_WindowsXPSP1
      #endif
      EXPLAIN !!Why_Enable_KB2541025
      VALUENAME "EnableOnLoad"
      VALUEON  NUMERIC 1
      VALUEOFF NUMERIC 0
     END POLICY
    END CATEGORY

    [strings]
    LocalHack="Home-brewed modifications"
    EnableKB2541025="Disable KB2541025 (Excel File Validation)"
    SUPPORTED_WindowsXPSP1="Requires XP SP1 or higher"
    Why_Enable_KB2541025="KB2541025 is enabled by default, but dramatically slows opening Excel files. Disable to speed file opening."

    Tuesday, July 12, 2011 2:07 AM
  • Scorch,

    What Update number did you remove and did it correct the problem?

    Wednesday, July 13, 2011 12:04 PM
  • You can't unapprove it in WSUS, the solution I implemented was just to remove the update manually for those users who regularly use large excel files across network shares.  Obviously if you've got hundreds of people that won't work.
    Wednesday, July 13, 2011 3:11 PM
  • I've got this issue also now.

    The only fix that works is to actually add the registry entry while logged in as the user.

    All the other fixes here don't work because they need access to HKCU and as I understand permissions in GPOs etc, this simply isn't possible. The reason the fixes above have worked for some people is because it appears in those scenarios, the users effected with the users are actually part of the administrators group on the local system, so they can freely interact with HKCU. But if like me you only assign "User" level permissions to everyday users, then your S.O.L

    If anyone has an automated (Scripted) solution that works regardless of the permission level of the currently logged in user, please post it!


    Wednesday, July 13, 2011 10:42 PM
  • It is possible to set this entry not as a policy:

    [HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Excel\Security\FileValidation]
    "EnableOnLoad"=dword:00000000

    The normal user has write access to this. So you can import a reg file during logon or write the entry with vbs code.

    Thursday, July 14, 2011 1:07 PM
  • Just to correct the above, the first time you posted the key, it was correct - there should be a "\Policies\" in the above key.

    [HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Excel\Security\FileValidation]
    "EnableOnLoad"=dword:00000000

    Other than that, it worked correctly and solved a big on-going head-ache for me - so thanks for the help all!

    By the way, I am not as comfortable working in the group policy, so I handled this by manually entering the key on my PC, then exporting it to a .reg file and then I emailed that to all users (there are only 35 of them so if they complain that it is still slow, I can ask "did you run the fix I sent?").

     

     

    • Proposed as answer by Eric G-S Thursday, April 19, 2012 2:21 PM
    • Unproposed as answer by Eric G-S Thursday, April 19, 2012 2:21 PM
    Thursday, July 14, 2011 7:08 PM
  • Excel searches for both entries.

    HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Excel\Security\FileValidation and HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Excel\Security\FileValidation

    Thursday, July 14, 2011 7:27 PM
  • I'll say it again - A user that logs onto a computer that is only part of the "Users" group does NOT have write access to the HKCU key. None of the automated fixes stated in this thread will work. Perhaps it will work if the user is part of the 'power users' group. I can definitely say it doesn't work if you're a mere user.

    I've resorted to fixing this case by case now.
    Thursday, July 14, 2011 7:36 PM
  • A user that logs onto a computer that is only part of the "Users" group does NOT have write access to the HKCU key


    The default permissions for a new user hive are taken from USERS\.DEFAULT:

    "D:P(A;CI;GR;;;BU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;CO)" according to defltbase.inf

    CO is Creator/Owner which becomes the user itself. The permissions are the same as for SYSTEM (SY) and the built-in Administrators group (BA). GA means "Generic All", which is Full Access.

    Otherwise no single application could ever store its settings in the user specific registry.

     

    Friday, July 15, 2011 2:09 AM
  • Interesting. Any ideas why I can't modify the registry through regedit.exe when logged in as a user?
    Friday, July 15, 2011 3:08 AM
  • It is possible to prohibit the use of registry editing tools. Or someone modified the default permissions or a behavior blocker application is active. There can be many reasons.

    Friday, July 15, 2011 7:32 AM
  • I just created a user account that's only member of the "Domain User" group in my test environment. The test environment consists of a 'fresh install' 2008 R2 domain with all settings in default; There are no restriction applications at all.  I then logged said user into a Windows 7 desktop computer, and tried to create a new registry key under

    HKEY_CURRENT_USER\Software\Policies\Microsoft\

    And this is what I got:

    Regerror

    This is the whole point of having user roles... if the user roles didn't restrict stuff like this, there would be no point to it, and then people belonging to the user group could do whatever they like with the systems, such as installing applicatoins etc. Why is this so hard to understand? I'm not lying - this really is making this office validation issue I'm having very difficult to fix. If you have a solution that doesn't involve adding people to the administrators group on the machine, let me know.

    I suppose I could always deploy the Microsoft Fix It via group policy...


    Friday, July 15, 2011 7:53 AM
  • The Policies tree has special permissions. You should try HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Excel\Security\FileValidation. It works the same.

    If you have a 2008 R2 domain, then you can distribute Registry settings via Group Policy:

    User Configuration\Preferences\Windows Settings\Registry


    Friday, July 15, 2011 8:45 AM
  • Here is a "Fix-it" msi file that MS has sent out.  http://support.microsoft.com/kb/2570623
    Friday, July 15, 2011 5:41 PM
  • Thanks for all of your efforts on this.

    Thanks for Neil sharing this issue and the workaround.

    Thanks for Alexander's kindly sharing and helping.

    Thanks for Magicshoot sharing the Fix provided by MS.

     

    I'm sorry for the trouble and the inconvenience you've met with. At least we get an fix from the KB Magicshoot provided. Hope it will work for you.


    Sincerely,

    Max Meng
    Forum Support


    Come back and mark the replies as answers if they help and unmark them if they provide no help.
    • Proposed as answer by wolfeee99 Wednesday, July 20, 2011 11:17 AM
    • Unproposed as answer by wolfeee99 Wednesday, July 20, 2011 11:17 AM
    Monday, July 18, 2011 6:28 AM
  • Uninstall fixed it for me:  Start\run
    msiexec / x {
    90140000-2005-0000-0000-0000000FF1CE} (choose yes to uninstall)

    or if you want to set it up to run silent:
    msiexec / x {
    90140000-2005-0000-0000-0000000FF1CE} / quiet

    • Proposed as answer by wolfeee99 Wednesday, July 20, 2011 11:20 AM
    Wednesday, July 20, 2011 11:20 AM
  • If you are in AD environment, and user have no rights to aply the Fix you can use wmic to uninstall this update from one or more pc's.

    1. Start cmd with privileged user rights

    2. input wmic in command line

    3. for one computer:

    /node:NAME_OF_PC product where name="PRODUCT NAME as it appears in add/remove programs" /nointeractive call uninstall
    4. for a list of computers:
    /failfast:on /node:@"c:\computers.txt" product where name=" PRODUCT NAME as it appears in add/remove programs " call uninstall /nointeractive

    where

    • /failfast - if error occurs or requested program is not present, skip to next
    • /node: - flag for the name of computer or list of computers
    • c:\computers.txt is flat text file with list of computers from wich to uninstall
    • /nointeractive - to skip request for confirmaion to uninstall

    This work for me and I uninstall OFV from 60 PC's in AD at once

    Friday, July 22, 2011 5:32 AM
  • All that MSI does is fiddle with the registry, doesn't actually fix the fault itself.
    Tuesday, July 26, 2011 3:49 PM
  • Thanks for all of your efforts on this.

    Thanks for Neil sharing this issue and the workaround.

    Thanks for Alexander's kindly sharing and helping.

    Thanks for Magicshoot sharing the Fix provided by MS.

     

    I'm sorry for the trouble and the inconvenience you've met with. At least we get an fix from the KB Magicshoot provided. Hope it will work for you.


    Sincerely,

    Max Meng
    Forum Support


    Come back and mark the replies as answers if they help and unmark them if they provide no help.


    Thanks Max,

    Unfortunately the fix provided by Magicshoot address Excel only. This issue effects all office app's.

    • Proposed as answer by soheilbashiri Thursday, December 15, 2011 9:19 PM
    Friday, October 28, 2011 2:57 AM
  • No one really knows why microsoft does half the stuff it does... I don't know much about networking but we had all XP machines at work and saving files to a server so someone else's pc could grab them from the server wasn't an issue with XP.  Now the IT guy is baffled as we have some windows 7 machines and when the XP MACHINES save a file to the server it takes about 20min for the Windows 7 machine to "SEE" that file that the XP machine saved to the server however the XP machine sees it anytime after saving it.  I laugh in disgust and say what did microsoft due to their new OS?? XP worked fine... then they had to "FIX IT" and come out with VISTA.... cough?!?!?.... then WINDOWS 7 ....... THEY NEED TO MAKE XP-II where everything JUST WORKS!!!!
    Saturday, December 17, 2011 5:46 AM