Beware the Office File Validation Add-In for Office 2003 and 2007
-
Wednesday, June 29, 2011 6:10 PM
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".
Answers
-
Friday, July 15, 2011 5:41 PM Here is a "Fix-it" msi file that MS has sent out. http://support.microsoft.com/kb/2570623
- Marked As Answer by Max MengMicrosoft Contingent Staff, Moderator Monday, July 18, 2011 6:28 AM
All Replies
-
Thursday, June 30, 2011 1:10 PMYes, 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:46 PMAny 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 3:38 PM
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Excel\Security\FileValidation]
"EnableOnLoad"=dword:00000000This solved the issue for the Excel files in my case.
-
Thursday, June 30, 2011 6:42 PMNeil,
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 11:20 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.
-
Monday, July 04, 2011 9:33 AMFor 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 2:53 PMYep, 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.
-
Tuesday, July 05, 2011 7:56 AMIs 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 8:54 PM
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 9:46 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.
-
Wednesday, July 06, 2011 3:31 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.
-
Thursday, July 07, 2011 7:47 AM
It seems Microsoft left the wrong uninstall string in the Registry. Try
MsiExec.exe /X {90140000-2005-0000-0000-0000000FF1CE} /qn
-
Friday, July 08, 2011 3:53 PM
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!
-
Monday, July 11, 2011 6:38 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? -
Tuesday, July 12, 2011 2:07 AM
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." -
Wednesday, July 13, 2011 12:04 PM
Scorch,
What Update number did you remove and did it correct the problem?
-
Wednesday, July 13, 2011 3:11 PMYou 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 10:42 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! -
Thursday, July 14, 2011 1:07 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:00000000The 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 7:08 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:00000000Other 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?").
-
Thursday, July 14, 2011 7:27 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:36 PMI'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. -
Friday, July 15, 2011 2:09 AM
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 3:08 AMInteresting. Any ideas why I can't modify the registry through regedit.exe when logged in as a user?
-
Friday, July 15, 2011 7:32 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:53 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:
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 8:45 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 5:41 PM Here is a "Fix-it" msi file that MS has sent out. http://support.microsoft.com/kb/2570623
- Marked As Answer by Max MengMicrosoft Contingent Staff, Moderator Monday, July 18, 2011 6:28 AM
-
Monday, July 18, 2011 6:28 AMModerator
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. -
Wednesday, July 20, 2011 11:20 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
-
Friday, July 22, 2011 5:32 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
-
Tuesday, July 26, 2011 3:49 PMAll that MSI does is fiddle with the registry, doesn't actually fix the fault itself.
-
Friday, October 28, 2011 2:57 AM
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
-
Saturday, December 17, 2011 5:46 AMNo 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!!!!
.png){kind=spacer}
