I would tend to agree with your replication assumption, or some other "NT isn't updating something quick enough" answer, especially if it's only on newly created objects (I have a similar problem with Exchange 5.5 - where creating a scheduled task to re-run the mailbox creation 10 minutes later always works).
As well, this (NT is still updating this object) might explain why it causes the 80070005, as opposed to something like a 80072030 (Object not Found), 8002802b (Member Not Found), or any of the other similar errors that this condition might produce. A "sleep 5;" before the CreateMailbox might mask this type of situation from happenning, but maybe you've already tried this. Have you enabled auditing of Account Management Events, and looked at the Event log for errors/warnings during the period you have experienced this anomoly? Steven -----Original Message----- From: Stum, Matthew J. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 8:16 AM To: [EMAIL PROTECTED] Subject: Occasional error with $ADobject->CreateMailbox($storeDN); I've got about 27,000 Exchange mailboxes and 49,000 total users with a 10,000 user turn-over every year. Needless to say I've written some Perl modules to automate the management of AD, Exchange, IIS, SQL, etc. And it all works pretty slick 99% of the time... However.... recently I've noticed every once in a great while I'll get the following error when calling the CreateMailbox() method on a user object: ------------- OLE exception from "<Unknown Source>": Access is denied. Facility: Win32 ID no: c0070005 Microsoft CDO for Exchange Management Win32::OLE(0.1501) error 0x8000ffff: "Catastrophic failure" in METHOD/PROPERTYGET "CreateMailbox" ------------ If I wait a few minutes and try again (same object, same parameters) it works just fine. This happens with both newly created objects as well as objects that have been around awhile. Otherwise I would suspect a replication problem, which in general is a major pain in my arse! But that's another story/thread altogether... The only semi-related reference to c0070005 I could find at Microsoft's Support site is a permission problem with a couple of registry entries. However, I would think this would be an all-or-nothing situation. The code is being run through a service app which is always running under the same user id. Any thoughts? Anyone else run into this? Matt Stum Ball State University _______________________________________________ Perl-Win32-Admin mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs _______________________________________________ Perl-Win32-Admin mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs