Running Office for users with directories not on startup volume (ref:KB322237)

[Chuck Wade]

There appears to be a problem with running MS Office for users
whose home directory is *not* located on the startup volume. This
problem prevents running Visual Basic Applications (VBA) within
any Office Application, and also interferes with macro execution.
While this problem has been noted for a while, it has not been
fixed with any of the updates issued by Microsoft (up through
10.1.5) nor is it resolved by running the latest version of Mac
OS (10.3.2).

If anyone reading this newsgroup has any recommendations for how
to work around this problem, I would be very grateful for any
insights or suggestions. This is a very unfortunate limitation in
Office. For the record, I have not had this problem with any
other commercial software, and I use a lot of different
applications in my work.

By way of background, I've provided below a couple of references
to this problem that I've been able to track down:

Microsoft's Knowledge Base article # 322237 describes a problem
where Visual Basic will not run properly when the user
directories are not located on the startup volume. The URL for
this article is:

http://support.microsoft.com/default.aspx?scid=kb;en-us;322237

There was also an instructive thread on this newsgroup in
November of 2002. A URL for this thread is:


http://groups.google.com/groups?hl=...*&selm=ObBuFOZiCHA.1688%40tkmsftngp08&rnum=24

For the record, I tend to agree with Corentin's point of view in
this thread.

If anyone is curious, Apple's "NetInfo Manager" utility can be
used to place user home directories on disk volumes other than
the startup volume. Depending on one's configuration and security
profiles, there can be very good reasons to have user directories
off the startup volume.

 

[Chuck Wade]

A workaround has been found! (Sometimes, you just have to know
the right question to ask.) The solution involves placing a valid
"Carbon Registration Database" in the Microsoft preferences
folder for each user whose home directory does not reside on the
startup volume.

Unfortunately, starting MS Office from a user account where the
user's home directory is not on the startup volume will result in
a crippled Carbon Registration Database.

However, if you start up MS Office from a user account with its
home directory on the startup volume, then a proper Carbon
Registration Database file will be created in the Microsoft
preferences folder for that user, e.g.,

~/Library/Library/Preferences/Microsoft

This file can then be copied to the corresponding location in
each user's home directory. (An easy way to do this is to copy
the CRD file to the public drop folder for every user that does
not reside on the startup volume.) It might be a good idea for
every user to keep a backup copy of this file around. In fact,
keeping a backup of the entire "Microsoft" folder from the
Preferences folder is probably a good precautionary practice.

With a valid version of the CRD file in a user's MS preferences
folder, it looks like all MS Office applications work as
expected, and macros correctly load and execute. Note this is
important for some add-ons, such as those provided with Acrobat 6
and EndNote.

For the curious, I got my first clue by comparing the Microsoft
preferences directory listing between a user account residing on
the startup volume and one residing on another volume. While the
Carbon Registration Database (CRD) file existed in both
preferences folders, the version on the startup volume was
substantially larger. With this information, I did a new search
on the archives of this newsgroup, and found several references
confirming that problems with the CRD file caused the problems I
was having, and also that moving a correctly built version of
this file to the user's MS preferences folder would solve the
problem (Thanks, Corentin!).

It sure would be nice if Microsoft would post a knowledge base
article describing this problem and suggesting the workaround.
Hopefully, this will be fixed a bit more elegantly in Office 2004.

Let me also offer a bit of advice to anyone else who would like
to move user home directories to another partition or disk drive
(i.e., not the startup volume). It is actually quite important to
maintain at least one admin account with its home directory on
the the startup volume. This would probably be the primary admin
account for this Mac system.

Ideally, all software should be installed with this admin account
(although I've encountered a couple of specialty applications
that need to be installed from the user account where they will
be used). Note that user accounts (including your own if you
operate a single-user machine) can (and perhaps should) be
"standard" accounts (i.e., not admin). Users can be created using
Apple's "System Preferences" application and the "Accounts"
panel. The user directories created under "Users" on the startup
volume can then be copied to another volume (preferably under a
"Users" folder on that volume). The "NetInfo Manager" utility can
then be used to change each user's default home directory to
reside on the other volume.

However, the primary admin account should continue to reside on
the startup volume. Not only does this allow for workarounds to
problems such as this one with MS Office, but it also allows
utility operations to be performed on the volume(s) where other
user directories reside (e.g., running disk repair under the
first aid tab of "Disk Utility").

While most users will have no need for anything more than a
single volume, there are plenty of situations where multiple
volumes are a necessary fact of life, and where the ability to
locate user directories on any appropriate volume is vital.

I hope this information is useful to others who follow this
newsgroup.

 

[Corentin Cras-Méneur [MVP]]

Hi Chuck,

A workaround has been found! (Sometimes, you just have to know
the right question to ask.) The solution involves placing a valid
"Carbon Registration Database" in the Microsoft preferences
folder for each user whose home directory does not reside on the
startup volume.

The bug (and the workaround) are known )

Unfortunately, starting MS Office from a user account where the
user's home directory is not on the startup volume will result in
a crippled Carbon Registration Database.

However, if you start up MS Office from a user account with its
home directory on the startup volume, then a proper Carbon
Registration Database file will be created in the Microsoft
preferences folder for that user, e.g.,

You can copy this CRD to the pref folder for the other user (the one
which has the use folder located on another partition) and the problem
should disappear for him/her.


The problem is that when the user fodler is not located on the boot
volume, the Office apps fail to generate a proper CRD the first time
they are launched.
The CRD contains the information about the location of all external
components the Office apps need (eg the VBA runtimes).
If the CRD is corrupted, the applications crash on trying to use any of
the external components (including VBA).

Copying a properly generated CRD from another account fools Office and
it doesn't try to re-create it (and corrupt it).

Corentin

 

[Corentin Cras-Méneur [MVP]]

Let me also offer a bit of advice to anyone else who would like
to move user home directories to another partition or disk drive
(i.e., not the startup volume). It is actually quite important to
maintain at least one admin account with its home directory on
the the startup volume. This would probably be the primary admin
account for this Mac system.

You don't really need to. If you really need to access a user account on
the boot volume, you can always create a temporary account and delete it
later.

Ideally, all software should be installed with this admin account
(although I've encountered a couple of specialty applications
that need to be installed from the user account where they will
be used).

Idealy, all applications should be installed in /Applications (from any
admin account). This allows the apps to be shared amongst all users on
the Mac. I'm not sure why you'd actually need to install the apps
specifically from an admin account located on the boot volume... Could
you tell me more ???

Note that user accounts (including your own if you
operate a single-user machine) can (and perhaps should) be
"standard" accounts (i.e., not admin). Users can be created using
Apple's "System Preferences" application and the "Accounts"
panel. The user directories created under "Users" on the startup
volume can then be copied to another volume (preferably under a
"Users" folder on that volume). The "NetInfo Manager" utility can
then be used to change each user's default home directory to
reside on the other volume.

Yep. Some people use symlinks instead but I prefer using the NIM and do
it the way the system is actually designed to do it. In the past (and
especially with previous versions of the system) I've had a few problems
with apps that were not fully NIM compliant and I decided to back up
this setup by also creating a symlink in /Users for every relocated user
account. It usually did the trick and fooled the applications.

Some applications are reluctant to comply though.
For instance, if you install Acrobat Distiller 6.0.1 on a different
partition than the boot volume, most of the time the applciation won't
launch :-<

I suspect that in the case of the problem you described here with
Office, the CRD uses absolute, hard coded path (eg: Macintosh
HD:Users:<you>) instead of relative paths that would have been NIM
compliant (eg: ~/). Let's hope the issue will be fixed in a future
release :-\


Corentin