It's probably the DMS integration that's suppressing the execution of the
AutoOpen macro - kind of like setting macro security in Word to 'High'. In a
DMS like iManage the integration is usually provided through a global
template(called "iManO2K" in most cases) which does all sorts of stuff like
intercept the File | Save, load toolbars, etc. Your DMS techical guys (NOT
the sales guys - they won't know anything) should be able to tell you what
happens when a document is opened from within the DMS environment. Ask them
what else the DMS tells Word on an "Open" event - if anything.

Note that you may also encounter problems if you try to use an AutoNew macro
in a template under certain DMS configurations. If the template is stored in
the DMS and functionality is provided to create a new document based on this
template from within the DMS, the AutoNew macro probably won't fire either.
This is because many DMSs don't actually create a new document using Word
processes (i.e. execute a Documents.Add event). Instead the template (which
isn't _really_ a template - the DMS stores it as a .doc but calls it a
template) is copied within the DMS document repository, and then this copy is
opened. This usually happens when the DMS is set up to 'pre-profile'
documents and is designed to ensure that no documents can be created which
aren't stored in the DMS. And as discussed above, even using an AutoOpen or
AutoExec macro is no substitute because the DMS may block the code execution.

The best solution is to do all of your document creation processes in the
Word environment and then 'post-profile' the document when it's saved.
However, the decision to pre- or post-profile is usually made some policy
w.nk who doesn't have any technical nous. Consequently, you end up getting
caught by conflicting requirements: the template _must_ have code in it but
all documents _must_ be created in the DMS environment and the DMS won't let
the code run - and of course the DMS guys won't change their system to
accommodate the requirements, and the policy w.nk won't change the
requirements...

If you are dealing with sort of situation I suggest that you make a strong
case for going away from pre-profiling. You can write code that forces the
user to save the document as soon as it's created - well, not exactly
"forces" but certainly "strongly encourages". Just make the last line of your
code 'ActiveDocument.Save' and let the DMS take over from there.

You can also be a bit trickier about this. Usually the concern about
creating documents outside of the DMS environment is that the users will save
the document someplace other than the DMS or that they'll print the document
and then close it without saving. The DMS integration can handle the first
scenario by taking away the ability to save the document locally. However,
you can write code to address the second situation.

Create a procedure called 'FilePrint', which will intercept Word's File |
Print command. In this procedure just look at the Saved property of the
document and don't let the document print if it hasn't been saved - and of
course it can't be saved anywhere but into the DMS. You'll also need to
fiddle with the Print button on the Standard toolbar so it executes your
FilePrint macro.

Anyway, good luck in what I suspect will be a protracted battle. Hope you win!