Entourage 2004 / Dell Switch / Networked Home Folder

[hschickel]

I'm running a number of users w/ the following attributes:

Mac OSX.3.3 / .4 Clients
Mac OSX.3.3 Server
Entourage 2004
Networked Home Folders

Users run off networked home folders. These were flaky but working. On the same weekend I upgraded the users to exchange via webdav (a very nice improvement over IMAP) and a Dell Powerconnect managed switch.

After the upgrades the flaky Entourage has gone from flaky and requiring a periodic restart to outright unusable. I get constant 16008 errors and the database could not be used please rebuild errors.

Rebuilding shows no errors. When I use the database locally I get no errors. Downgrading back to IMAP lessens the problem somewhat but not enough to use. Local homes w/ remote authenication solves the problem but eliminates roaming users and creates hassles w/ backups.

I suspect this is a networking issue with the settings on the Dell. I've disabled spanning tree (a bane for AFP networks). Downgrading the Dell is really not an option. It has vastly improved the overall networking environment in the office.

Has anyone else seen anything like this? How did you solve it?

Thanks,
Hugh

[Brian Reichow]

I had a similar problem today:

Customer migrates from Office 2001/Mac OS 9 to Office 2004/Mac OS X 10.3.4. Server is running 10.3.4 and hosts network home folders.

Entourage 2004 SUCCESSFULLY imports the old identity and opens the mail browser window. You can do anything you want - read mail, check mail, whatever - until the application is quit for the first time. From the second launch onward, it perceives the mail database - if it's located on a network home folder - to be damaged beyond repair. Move that same database to a local user home folder, the problem goes away. On launch, Entourage either registers a 16008 error OR simply indicates there is damage to the mail database and fires up Database Utility, offering to repair the file.

(Yes, I reimported the data - 6 or 7 times. Yes, I attempted to do the import on a different machine. Yes, I reinstalled the entire Office suite clean. Yes, I tried rebuilding the database - repeatedly.)

I've run Entourage X on home folders hosted on MOSXS 10.2.x with both 10.2.x and 10.3.x clients, without issue, at other clients, and Entourage 2004 on home folders hosted on MOSXS 10.2.x. This specific issue appears to be specific to 10.3.x client + 10.3.x server + Entourage 2004.

So, I called Microsoft technical support. I believe someone in New Delhi answered the phone. They spent a fair amount of time investigating the problem, but ultimately fell back on the crock-of-crap party line that "we don't support network home folders. Since a server is involved, you'll have to deal with our Very Expensive Enterprise Support Team, and fees are involved." Gee, thanks.

Your post was the only other reference to this problem I could find. Obviously, my temporary workaround is a local user home folder. I have something like 5-6 multiple-station OS X transitions scheduled over the next three weeks and will run into this issue again and again. I've posed this problem to the Apple Consultants Network listserv and the Mac OS X Server Administrators listserv; if I hear anything useful I'll post it here.

Brian Reichow
ACTC
Escape - Minneapolis

[hschickel]

Brian,

I'm glad I'm not the only one. Please post if you learn anything. I'll do the same.

Thanks,
Hugh

[reeserv]

I'm not sure where I read it, but I remember reading somewhere, that after an install of Office X that opening up Excel first and then a Word document would aleviate those problems. That is if my memory is holding. Being on vacation for the last three weeks has dulled my mind.

[reeserv]

Here is what I remembered reading:
The core issue is that the Microsoft Office applications are CFM carbon apps. The Visual Basic libraries that are called during macros, add-ins, etc. are not "aware" of any other location for prefs OTHER than local. This is why deleting the file can help when launching, but then re-launching fails.

The final solution is this (other than MS re-coding VB implementation):

1. Create (or use) a LOCAL Mac OS X user.
2. Login as that user and open an Office app, then close all MS apps.
3. Navigate to ~/Library/Preferences/Microsoft/
4. Copy the 'Carbon Registration Database' preference file to a network volume.
5. Logout.
6. Login as the NETWORK user.
7. Copy the 'Carbon Registration Database' preference file from the local user to the same location for the network user. (~/Library/Preferences/Microsoft/).
8. Launch away.

Hope this helps.

[fragerybou]

I'm getting the same problem on my end as well. I'm also using networked home folders, but they're not your standard AFP shares. Due to some constraints with AD, I have the share set up as a group share, with login hooks creating a home folder for the user as a symbolic link in /Users/<username> to the networked drive. A fresh install of Entourage resulted in the same corrupt database error.

I tried the above tip, with the Carbon Registration Database preference file, however, it did not exists on my local account. So, I copied the entire preferences folder over, including the OLE Registration Database. No luck. Any ideas?

[mac_man_luke]

Did you login as the local user first?

[finne]

We got exactly the same problem.

Solution might be (untested):

http://groups.google.com/groups?q=mi...INVALID&rnum=1

(basically quit the MS DB daemon before logging off)

[the_tallman]

Setup: Entourage 2004 - Exchange Server using WebDAV - OS X via Netboot

None of the afore mentioned solutions have worked for me so I did some research of my own.

The root of the problem seems to be centered around the fact that Exchange 2004 will not keep the Microsoft Database Daemon alive when reading/writing to a netbooted home drive. Watching top or Activity Monitor while Entourage crashes illustrates this nicely.

First, I tried writing an applescript app that would co-launch the database daemon and Entourage. Entourage would then successfully open but after a varying length of time, the daemon decided to quit bringing Entourage with it.

I then came up with the current working solution:

1. Copy the "Microsoft User Data" folder located in the netbooted ~/Documents folder to a locally mounted drive.

2. Move or rename the original "Microsoft User Data" folder on the netbooted home drive so Entourage doesn't find it.

3. Make an alias of the local copy of the "Microsoft User Data" folder in its new location and move that alias back to the netbooted ~/Documents folder, taking care to rename the alias "Microsoft User Data".

So far, Entourage has behaved itself.

Although this works, it negates some of the benefits of netbooting as you have to go to each workstation and manually set this up. Outside of having Microsoft fix this, I think the best solution would be to have a a watchdog process automatically relaunch the Microsoft Database Daemon whenever it exits. However, I haven't found anything usable like that.

Any *NIX geeks out there know of something that would keep that daemon afloat? I know Panther Server has the aptly named Watchdog process that does this but it doesn't seem to be available for Panther client.

Thank you for your help,
Ivan

[Ralphonse]

wouldn't an applescript solve the problem? first start the daemon, then start entourage?

(try with this)

tell application "Microsoft Database Daemon"
activate
end tell
tell application "Microsoft Entourage"
activate
end tell

[ukrycrofti]

You also have to be aware of key commands not working in CS unless you tell the application to remember your password. if you manually enter in your password then you may find that the space bar doesnt work anymore within illustrator!

I am not too sure if the deamon actually falls over if you use the script above. the only reason it fell over on me was the fact that i had the old entourage deamon running and somehow they corrupted each other or something.
If it does fall over, then i might have to look at some sort of watchdog on the entourage daemons, because on OSX server you can have a watchdog on certain daemons and if they fall over then it will restart them, and you never know.

There could be some way of ripping out the code off the server edition and putting it into the client OSX?????

not sure but there could be a program out there as well!!!

[ukrycrofti]

Set up a schedule where you run an applescript every one min with this apple script

tell application "Microsoft Database Daemon"
activate
end tell

it then runs this script so hopefully before anybody knows it has fallen over it has restarted the database!

And run the script that is two posts above as your way into entourage, instead of double clicking on the app, double click on that script!!!

hope this works!!!

[SteveH1352]

My late thank to "The Tallman". This workaround works great! We are running
10.4.8 clients and servers, with network user accounts, and have plagued by this issue since day one. It would appear this has been a long running problem that Microsoft has refused to address. Hopefully as more users switch to OD or AD servers, they will decide to correct this problem.

Thank again