Having trouble a with FileSite view in Outlook 2010? Is it repeatedly garbled (e.g. Outlook flag column included)? Perhaps it’s not available, instead showing the error message “Outlook cannot display this view”. In this article, I’ll provide a few troubleshooting tips, and what you may find is a decent fix.
If you’re having similar troubles with a different version of Outlook, perhaps without even FileSite, read on as well for links to other Outlook troubleshooting tips in this topic.
FileSite works with Outlook’s personalization infrastructure, to store how a particular user has modified the layout of a particular folder or view. This infrastructure sometimes gets garbled by ‘bad Outlook citizens’ that don’t follow the correct Microsoft integration protocols. Because FileSite ‘lives in’ Outlook, FileSite’s views are sometimes innocent victims of some other Outlook add-in’s overruns.
Sadly, I can’t provide you a recipe to isolate which part of an Outlook ecosystem is overrunning a FileSite view, but I can help you to confirm that this is the trouble in a particular case.
This is a description of the application functionality starting with the most generic and moving to the per-user, per-folder modifications.
As of WorkSite 8.5 and later, Outlook’s FileSite views are defined in vdm files. As part of installation on a given machine, these five files are stored in the program folder, e.g. C:Program FilesInterwovenWorkSiteiOutlook. Never delete these files. Their names and uses are:
When a particular user first launches FileSite, these five files are copied to that user’s profile folder. That’s where you located the views.vdm during the earlier troubleshooting: “Documents and Settings\<username>\Application Data\iOutlook”.
As long these local vdm copies exist, FileSite uses them instead of referring back to the main program folder. If/when you delete them as part of troubleshooting, a fresh copy will be taken from the program folder. When the user visits a container for the first time on this machine, Outlook learns that the view’s layout is defined by the appropriate vdm file for that container type according to FileSite. In concrete terms, when visiting a folder with an email address, FileSite tells Outlook to use NRTEmailView.vdm.
Any/all user changes to a view on a specific folder, e.g. a WorkSpace search folder or the FileSite Document Worklist View, this change is stored in the views.vdm file.
As I said, don’t delete the main copies of the vdm files stored in the program folder.
If you’ve found that deleting only the views.vdm fixed the problem, then it was something either user-driven or a misbehaving Outlook add-in.
If the problem was resolved after deleting views.vdm and the five iManage vdms, then likely the unwanted view layout had been saved inadvertently to the user’s local copy of that vdm.
If the problem recurs frequently and you can determine that it’s not the user’s <ahem> fault, then ping us at Cersys and/or contact iManage support.