Where's the perl script running? NT4 or W2K? I've had similar issues with ADSI and NT4, where an intermittent issue got worse and worse. No matter what I did to intermittently fix the issue at hand, in the long run, it came back to haunt me. I've been running fine on W2K ever since I dumped my NT4/ADSI 2.5 setup.
What I was referring to in the sleep statement was that: -in 2K mailbox creation, you create the user object, set the user attributes, open the Mailbox interface, use the CreateMailbox command, and voila (every now and then) the error occurs. It's possible that NT isn't finished writing the info to the DC that you are connected to, or that something has the account locked exclusively at that point, so it denies access while it does what it wants to the account and then finally finishes and would let you in. This may not be the case, and is just a theory based on the error you are getting, but auditing could help you find out what NT thinks is the problem. As well, after sleeping 5 - 10 seconds ONLY after the error crops up, you could try again to see if you get the same error. Which may tell you what the issue is, but given that you create thousands of mailboxes successfully, I don't think you are combatting a 5 - 10 minute problem, but a 5 - 10 second problem. I hope this helps. (sidenote: How big is your NTDS.DIT file on the DCS? (With all that turnover, is there a ton of fragmentation?) Steven -----Original Message----- From: Stum, Matthew J. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: RE: Occasional error with $ADobject->CreateMailbox($storeDN); I haven't gotten into auditing yet, no. And I haven't tried the sleep solution because 1) it makes my skin crawl, and 2) the required time delay is usually on the order of minutes, not seconds, and users are expecting a fairly immediate response to their web-based request. It's my own fault, really... when I first got here no one batted an eye when it took 24 hrs for operations such as forgotten password resets (for example) to take effect. After re-writing the account management system from scratch I've gotten the university used to a real-time environment with web-based front ends and immediate gratification. Now that we're moving from VMS to Windows (with the replication issues) when I suggest that we ought to move back to a batch-oriented queue-based system that will have no more than a 15-20 minute turn-around time for worst-case scenarios I get laughed out of the room. Sigh. Anyway, back to the problem at hand.... I guess I would figure that if it's truly a replication problem that I wouldn't get an Access Denied error, but rather an Object Not Found error, or something similar. I forgot to mention in my original message, we're in a mixed 2000/NT domain (although NT's presence is minimal at best) with 4 DC's (2000), 3 of which are GC's. We've been in this mode for about a year and I've created thousands of mailboxes with zero incidents... only the last few weeks have I started to see this c0070005 error and even then it's very sparse... nothing I can duplicate on-demand. Matt -----Original Message----- From: Steven Manross [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 11:11 AM To: Stum, Matthew J.; [EMAIL PROTECTED] Subject: RE: Occasional error with $ADobject->CreateMailbox($storeDN); 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
