Cleanup EV database probs..
Hi folks,
We're on 7.5 SP4
We're getting a 41126 error logged in the Event Viewer everytime the provisioning task runs - 'The Exchange mailbox provisioning task found some mailboxes that are not eligible for processing by this task.'
Found the following knowledge base article which seemed to describe the problem exactly:
http://seer.entsupport.symantec.com/docs/290576.htm
So worked through that, and the first few solutions weren't happening for me so finially decided to go with the final option listed in the article - delete the rows from the SQL2005 database...
So did that for a couple of our entries as specified in the provisioning task 'full log' (the 2 I deleted were actually the very first 2 in the table, probably cronologically the oldest entries..?), closed off management studio etc and ran the provisioning task in report more again to see if the bad mailboxes were now being ignored..
Unfortunately, the provisioning task now appears to be crashing out with a 41110 error as below.
Bit stuck on this one unfortunately, any help would be appreciated
Cheers,
ianG
Event Type: Error
Event Source: Enterprise Vault
Event Category: Exchange Provisioning Task
Event ID: 41110
Date: 21/10/2009
Time: 10:06:33
User: N/A
Computer: ---
Description:
The Exchange mailbox provisioning task failed during provisioning group processing. The task has stopped.
Task: Exchange Provisioning Task
Domain: ---
Provisioning group: <none>
Group member: <none>
Error: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Trace: at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
at System.Data.SqlClient.TdsParserStateObject.ReadByteArray(Byte[] buff, Int32 offset, Int32 len)
at System.Data.SqlClient.TdsParserStateObject.ReadString(Int32 length)
at System.Data.SqlClient.TdsParser.ReadSqlStringValue(SqlBuffer value, Byte type, Int32 length, Encoding encoding, Boolean isPlp, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.ReadSqlValue(SqlBuffer value, SqlMetaDataPriv md, Int32 length, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ReadColumnData()
at System.Data.SqlClient.SqlDataReader.ReadColumn(Int32 i, Boolean setTimeout)
at System.Data.SqlClient.SqlDataReader.GetString(Int32 i)
at KVS.EnterpriseVault.ExchangePolicySync.ExchangePolicySyncTaskProcessor.ProcessUnprovisionedMbxs()
at KVS.EnterpriseVault.ExchangePolicySync.ExchangePolicySyncTaskProcessor.RunTask()
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
Comments
Hi Ian, I had something
Hi Ian,
I had something similar, a few weeks ago, but I was getting 41129 errors. The issue I found was that we had 'leavers' included in one of our provisioning groups, whose accounts had finally reached expiry. I removed those users from the provisioning group (their mail archives remain in place) and re-started the provisioning task, outstanding new users were successully provisioned.
Hope that helps ?
B.
Unfortunately that didnt work
Unfortunately that didnt work for me B - neither did 'zap'g the offending mailboxes I'm afraid
Either way, that particular problem has to take the back seat for the time being, while the possibly bigger SQL mess is about!
iG
Hi I would recommend running
Hi
I would recommend running a dtrace and monitoring the following process
http://seer.entsupport.symantec.com/docs/276120.htm
set evexchangepolicysynctask v
If you log to a file, you can then step through and find 41110, which should fine the event you mention and then step backwards from there and possibly see whats failing just before the error.
If you feel this is a solution please mark it as such.
TIA Paul
https://www-secure.symantec.com/connect/downloads/...
https://www-secure.symantec.com/connect/downloads/...
Thanks for your reply
Thanks for your reply Paul
Was surprised to find the problem seems to have resolved itself over night - scheduled run at 19:00 ran without problems, as did the manually initiated 'to good to be true' one I did just now..
Thanks for your help lads - I'll go with the dtrace should this reoccur
iG
Would you like to reply?
Login or Register to post your comment.