Usually the cause of documents being slow to open in Word is when the attached template is missing – especially when the template is located on a network. Turns out with Word 2010 there can be another reason.

We had a client where some documents were taking between 25 and 30 seconds to open, but only for some users. Word displayed Validating. Press Esc to Cancel in the status bar, but pressing Escape didn’t help.

A bit of research about what the validation process does led me to this article http://blogs.technet.com/b/office2010/archive/2009/12/16/office-2010-file-validation.aspx.

I then found that disabling the validation process by setting the following registry value made the documents open instantly.

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileValidation]
“EnableOnLoad”=dword:00000000

Interestingly the offending documents appear in the list contained in the HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileValidation\FailedFiles key, so there is something up with them, but we won’t go into that.

Now the other point the article made was that the process only runs on untrusted documents. This turned out to be the key. I re-enabled validation, and added the path to where the attached template was located as a trusted location, and voila, the document opened quickly.

In the end the problem turned out to be a group of users who weren’t getting their Workgroup Template path set correctly, so therefore the network templates were not being trusted.

I’m spending a lot of time in issues lists at the moment, and so many issues are very poorly logged, with no details or steps on how to replicate the problem. Well that’s where the Problem Steps Recorder in Windows 7 comes in very handy.

Get the users to type in PSR into the search box in the Start Menu and hit enter – this will run the Problem Steps Recorder.

Now all they need to do is hit the record button, go through the steps to replicate the problem, hit stop, save the zip file and then email it to you. Simple. And you get a detailed log of what they did, including screenshots so you can see exactly what happened. Much easier to debug your issues now!

Occasionally we come across issues when moving databases from one SQL server to another.  One of the most tricky situations is when you cannot get access to the applications configuration settings for the database you are required to move.

This can be for various reasons, like forgotten passwords, poor application design or where the configuration settings are hard coded into the application itself.

For situations like these you need to think outside the box, especially if there are time constraints involved.

There is a little known tool that comes with Windows called the SQL Server Client Network Utility.  One of the handy things this tool allows you to do is register SQL server instances as aliases.

Therefore you can force all SQL traffic for a particular SQL server instance to another SQL server instance for the server hosting the application.

Please note, I think this tool should only be used only as a last resort when you cannot configure the application through the normal method.

To configure a SQL server instance as an alias, please follow the steps below:

    1. Log onto the server hosting the application as an administrator
    2. Stop any relevant services
    3. Start > Run > cliconfg
    4. Click on the Alias Tab > Click Add

    1. Under Server alias enter the old SQL server instance
    2. Under Server name enter the new SQL server instance
    3. Uncheck Dynamically determine port and enter port 1433 (or an appropriate SQL port if changed from standard)
    4. Click OK

The alias screen should then look similar to the following.  

  1. Click Apply>Click OK
  2. Start any appropriate services
  3. Test the application that it is using the new SQL server via the activity monitor
© Copyright - Mosmar