Determining Which Template is Attached to a Document?

[Guest]

Hi All

We have recently moved where we stored a number of organisational templates
from one server to another. Users will generally access these templates by a
mapped drive which is setup via their login script and even though the
templates were moved to a different server the drive and path were kept the
same.

However, we have since had users experiencing a problem whereby when then
try and open some word docs it can hang for up to 5 minutes before the
document opens.

This happens when the document has a UNC path in Tools, Templates and
Add-Ins eg \\servername\winword\templates as opposed to the shared drive. We
suspect that some staff have had a shortcut on their desktop and have
accessed the templates from their rather than by the mapped drive. At this
stage we don't really have an idea of how many documents are affected - we
have a few helpdesk calls logged and mainly for older documents. However we
have a lot of areas and a lot of documents!

So...my question is - is there anyway we can run a 'scan' (via a VB script?)
across all our shares and get a print out of which documents will have the
UNC path set as opposed to the drive letter in Tools, Template and Add-Ins?

Many thanks
Mark Jones

 

[Jezebel]

This is technically feasible, but not straightforward particularly if you
are not familiar with writing scripts of macros (and presumably, if you
were, you wouldn't have posted in the first place). Might be simpler to
rename your shared template folder then wait to see who screams.

 

[Guest]

Thanks Jezebel

If we renamed the shared templates folder everyone would be screaming!!

I suppose we are just trying to get an idea of the scale of the problem as
most of ones we have tested so far (which has only been 1 sections work
area)are ok ie they point to the template with a drive letter -
J:/winword/templates, as opposed to the UNC path \\server\winword\templates.
Plus it is very easy to fix - after the doc has opened 5 minutes later though!

Cheers
Mark

 

[Jezebel]

So let them scream . The cacophony will be a lot less than you'll get if
you try to write some code that opens documents on other people's computers.
(Believe me, you will NEVER hear the end of it if you try that...)

Send an email explaining how to fix it, and let them do the work.

 

[Guest]

Hi Mark,

Have a look at this MS KB article to see if it helps.

http://support.microsoft.com/kb/830561

Regards.

Ed

 

[Guest]

Thanks Ed

This looks as if it may help to fix the problem. I will ask some of our
guys here to see if they modify the script to see if we can actually get a
list of the documents which are affected before we make the change.
Unfortunately, we are a large educational institution with many different
sections and potentially affected documents are scattered across literally
hundreds of folders.

Cheers
Mark

 

[Guest]

Hi Mark,

I don't know of any quick way to do it :-(

As you know, one of the issues you'll have both when you search for the
documents and when changing them is that the affected ones will take a long
time to open. One of our guys here has suggested that you *might* be able to
enable them to open more quickly by (temporarily for the duration of the
search or the change) turning off a particular network setting.

On my WinXP PC I can do this as follows:

Right-click My Network Places and choose Properties.
Right-click Local area connections and choose Properties.
Select Internet protocl (TCP/IP) and click the Properties button.
Click Advanced.
Select the WINS tab.
Select the Disable NetBios over TCP/IP radio button.

The idea is that you disable NetBios, run the program, and enable it again
at the end. It might be worth running this by your techie people to see what
they think.

Cheers.

Ed