C
Cory Bosley
We have run into this bug:
http://groups.google.com/group/microsoft.public.mac.office.word/browse_threa
d/thread/78feb803f7b93202/ea663014dff78f62?tvc=2&q=%22object+library+not+reg
istered%22+%22office+2004%22
We have also found a workaround.
First, some background information. We have been having this issue for
quite some time at our site, even before I started. So far as we know, it
affects Office 2004 on Panther and Tiger with NFS home directories, and
probably also Office vX. What happens is that after the first run of Word
or Excel (or probably any Office 2004 product), we don't see any items in
the "Object type:" list for "Insert" -> "Object...".
On the first run, we do see items: "Microsoft Equation", "Microsoft Graph
Chart", etc. This can be worked around by deleting the user's
~/Library/Preferences/Microsoft/Office Registration Cache 11 after each run,
but that workaround is pretty annoying (it only works for one run).
The other problem we're seeing is "Object library not registered" in Excel
when we select "Analysis Toolpak" and "Analysis Toolpak - VBA" from "Tools"
-> "Add-Ins...". This has the same (poor) workaround as the other problem.
Thus, they have the same root cause; I am inclined to believe that there are
other problems we haven't seen that have the same root cause.
By the way, it's not just NFS home directories; we also tested using a UFS
formatted USB flash drive as a user's home directory (i.e. no resource fork
support on the filesystem) and Office had the same issues. This leads to my
hypothesis: Office 2004 can't handle having home directories on filesystems
that don't support resource forks. It seems that the Office Registration
Cache 11 file gets corrupted. Sure, the documentation states that the drive
it's installed on must support HFS+, but it doesn't say anything at all
about where home directories should be stored.
Fix the code or fix the documentation, Microsoft. At least give us an
option somewhere to not create or use the Office Registration Cache 11 file;
how hard can it be? Can it really be taking more than a year to fix this?
Anyway, 'nuff said there. Now for the (fairly good) workaround:
This must be done for each user's home directory (we'll call it
$USERHOMEDIR). You might have to be root on the fileserver itself, or a no
root squash machine. You should make sure these changes don't break
anything else:
1. cd $USERHOMEDIR/Library/Preferences
Make sure you're in the right place for what we're about to do.
2. chmod 700 .
We're about to open up the user's ~/Library/Preferences/Microsoft folder, so
we need to lock down the user's ~/Library/Preferences/ folder first.
3. chmod 1777 Microsoft
Give the user's ~/Library/Preferences/Microsoft folder permissions like
/private/tmp: anyone can create a file, but only the user that created a
file can rename or delete it. See sticky(8).
4. chown 0:0 Microsoft
So why do we have to do this to work around a Microsoft bug? Well, if the
directory is owned by the user, they can delete any file underneath it, even
if they don't own it. We don't want them to be able to delete and recreate
the "Office Registration Cache 11" file, which is exactly what Office 2004
will do if you make it a symlink to a file on an HFS+ volume, or if you even
if you make it root owned and chmod it 0.
5. cd Microsoft
Into the belly...
6. chown 0:0 "Office Registration Cache 11"
Make root own the file, so the user can't delete it.
7. chmod 0 "Office Registration Cache 11"
Now make it so that the user can't read or write to it.
Now what? The user can run Excel and Word and do insert object, etc, and it
all works. The only bad thing? You have to do that stuff up there for each
user (script it), and you get a few seconds delay each startup because there
is no cache.
We also tried symlinking the user's ~/Library/Preferences/Microsoft file to
a folder on an HFS+ volume, but Office wasn't interested in any of that.
If anyone comes up with a workaround for AFS we'd love to know, since we had
this issue on AFS as well. Microsoft, are you listening? Please fix this
bug or provide a better workaround.
Best regards,
Cory Bosley
Student System Administrator
University of Kansas Mathematics Department
(785) 864-7116 Fax: (785) 864-5255
1460 Jayhawk Boulevard
Lawrence, KS 66045-7523
http://groups.google.com/group/microsoft.public.mac.office.word/browse_threa
d/thread/78feb803f7b93202/ea663014dff78f62?tvc=2&q=%22object+library+not+reg
istered%22+%22office+2004%22
We have also found a workaround.
First, some background information. We have been having this issue for
quite some time at our site, even before I started. So far as we know, it
affects Office 2004 on Panther and Tiger with NFS home directories, and
probably also Office vX. What happens is that after the first run of Word
or Excel (or probably any Office 2004 product), we don't see any items in
the "Object type:" list for "Insert" -> "Object...".
On the first run, we do see items: "Microsoft Equation", "Microsoft Graph
Chart", etc. This can be worked around by deleting the user's
~/Library/Preferences/Microsoft/Office Registration Cache 11 after each run,
but that workaround is pretty annoying (it only works for one run).
The other problem we're seeing is "Object library not registered" in Excel
when we select "Analysis Toolpak" and "Analysis Toolpak - VBA" from "Tools"
-> "Add-Ins...". This has the same (poor) workaround as the other problem.
Thus, they have the same root cause; I am inclined to believe that there are
other problems we haven't seen that have the same root cause.
By the way, it's not just NFS home directories; we also tested using a UFS
formatted USB flash drive as a user's home directory (i.e. no resource fork
support on the filesystem) and Office had the same issues. This leads to my
hypothesis: Office 2004 can't handle having home directories on filesystems
that don't support resource forks. It seems that the Office Registration
Cache 11 file gets corrupted. Sure, the documentation states that the drive
it's installed on must support HFS+, but it doesn't say anything at all
about where home directories should be stored.
Fix the code or fix the documentation, Microsoft. At least give us an
option somewhere to not create or use the Office Registration Cache 11 file;
how hard can it be? Can it really be taking more than a year to fix this?
Anyway, 'nuff said there. Now for the (fairly good) workaround:
This must be done for each user's home directory (we'll call it
$USERHOMEDIR). You might have to be root on the fileserver itself, or a no
root squash machine. You should make sure these changes don't break
anything else:
1. cd $USERHOMEDIR/Library/Preferences
Make sure you're in the right place for what we're about to do.
2. chmod 700 .
We're about to open up the user's ~/Library/Preferences/Microsoft folder, so
we need to lock down the user's ~/Library/Preferences/ folder first.
3. chmod 1777 Microsoft
Give the user's ~/Library/Preferences/Microsoft folder permissions like
/private/tmp: anyone can create a file, but only the user that created a
file can rename or delete it. See sticky(8).
4. chown 0:0 Microsoft
So why do we have to do this to work around a Microsoft bug? Well, if the
directory is owned by the user, they can delete any file underneath it, even
if they don't own it. We don't want them to be able to delete and recreate
the "Office Registration Cache 11" file, which is exactly what Office 2004
will do if you make it a symlink to a file on an HFS+ volume, or if you even
if you make it root owned and chmod it 0.
5. cd Microsoft
Into the belly...
6. chown 0:0 "Office Registration Cache 11"
Make root own the file, so the user can't delete it.
7. chmod 0 "Office Registration Cache 11"
Now make it so that the user can't read or write to it.
Now what? The user can run Excel and Word and do insert object, etc, and it
all works. The only bad thing? You have to do that stuff up there for each
user (script it), and you get a few seconds delay each startup because there
is no cache.
We also tried symlinking the user's ~/Library/Preferences/Microsoft file to
a folder on an HFS+ volume, but Office wasn't interested in any of that.
If anyone comes up with a workaround for AFS we'd love to know, since we had
this issue on AFS as well. Microsoft, are you listening? Please fix this
bug or provide a better workaround.
Best regards,
Cory Bosley
Student System Administrator
University of Kansas Mathematics Department
(785) 864-7116 Fax: (785) 864-5255
1460 Jayhawk Boulevard
Lawrence, KS 66045-7523