Days since Exchange mailboxes scanned for new items

[shampoo]

We 've got a stubborn critical status in our environment. Eventid 41291

It is more than 2 days since any archive-enabled mailboxes on Exchange Server 'SERVERNAME' were scanned for new archive eligible items. Date of last scan: 27-5-2011 20:59
	Mail is not being archived from the mailboxes. There is likely to be a build up of unarchived mail that will increase the mailbox sizes. The unarchived mail is not available to discovery applications. The problem is most likely to be that Enterprise Vault cannot access Exchange Server.

Our EV is not archiving anymore. This event is also the only warning in eventviewer. We've had this problem before and after Symantec Support couldn't help us anymore we went for a rebuild. After the rebuild of the server it ran for 1 day again. The Deployment scanner gives no warnings either. The Exchange mailbox archiving task and exchange provisioning task are running fine. Users can pull arhives out of their mailboxes and can archive manually. There are no new mailboxes that can be enabled, so all mailboxes ARE enabled. The task can be synronised so I guess there's no problem communicating with exchange. MSMQ's are empty.

However, I find it strange I cannot browse for a systemmailbox in the Mailbox Archiving Task properties (settings tab) anymore. It's filled in properly but browsing hang-ups the EV9-console mmc. How will I get EV9 archiving again?

EV9.02
Exchange all in one. (2003 sp2)

[shampoo]

Could it be that my VaultSystemMailbox account is corrupt? The AD object of the VaultSystemMailbox has got strange characters in the CCMAIL,MS and X400 field. (E-mail Addresses tab)

8D806D2B-7F0B-47A5-9 at domain, mailbox and surname name respectively. Only SMTP is correct.

Can I change it or recreate that account without any trouble? Please advise.

[GertjanA · Accepted solution]

;)

Yes. Stop and disable the archiving task.

Create a new EV-systemmailbox, and Use the installation and configuration guide to grant the correct permissions to it. Verify (logging in as the Vault Service Account, open the EVSystemMailbox, sent an email) that that is setup correct. This will also 'create'  the systemmailbox immediately, instead of waiting for a while.

You now might want to delete the old system mailbox, or keep it to be sure.

When created and verified, open the task again, and change the systemmailbox to be the new one. start the mailbox archiving task. Verify eventlog to see if no issues occurr related to the new system mailbox. when ok, delete the old systemmailbox.

You might be able to delete and recreate the account, but I would make a new one to be sure.

[shampoo]

Thank you.

I tried to recreate the task but browsing for (my new) systemmailbox account fails like I previously mentioned. CPU is stuck @ 100%. I've noticed a large number of TIME_WAIT sessions to our domain-controller (msft-gc port) is being built up during this act.

Stopping the creation of this task kills the TCP sessions as well. Bear in mind that syncronisations and mail-enable handlings on our exchange server do work. Why won't it browse all of a sudden?

Select the existing system mailbox you want to use. Click Browse to select the mailbox from a list of those available. You must be using an account that has permission to list the mailboxes.

I can not browse.

[MarkBarefoot]

Grab a DTRACE of the MMC process.

Open a CMD prompt

Browse to the EV installation folder

type DTRACE

type 'set mmc v' (without the ')

type 'log c:\sysmbx.log' (without the ')

repeat the action

when you've repeated the issue, go back to DTRACE, type EXIT and then post the log here

[MarkBarefoot]

21 minutes seems a hell of a long time to enumurate a list of mailboxes. This mya be of some assistance in checking your GC performance - http://technet.microsoft.com/en-us/library/aa996442(EXCHG.80).aspx

[shampoo]

I've recreated the systemmailbox and created a new task. When browsing to this mailbox within the new task it again took some time. 21 Minutes this time. Is that normal?

I've dtraced but not posting that here. Just some fragments:

766 11:14:41.304  [1376] (mmc) <5068> EV:M Getting 500 results at a time from: LDAP://dc.domain.com/CN=Mailbox Store (EXCHSRV),CN=First Storage Group,CN=InformationStore,CN=EXCHSRV,CN=Servers,CN=DOMAIN.COM,CN=Administrative Groups,CN=DOMAIN.COM,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DOMAIN,DC=COM
767 11:14:41.304  [1376] (mmc) <5068> EV:M Listing mailboxes in range: homeMDBBL;Range=0-499
768 11:14:41.335  [1376] (mmc) <5068> EV:M   Processing result row 1 of 1...
------ ----
6125 11:35:29.286  [1376] (mmc) <5068> EV:M Current number of mailboxes in list: 549
6126 11:35:29.286  [1376] (mmc) <5068> EV:M Leaving ListMailboxesInMailboxStore() with status: Success 

Just one GC server. Pointed it to GC in registry even. All on the same subnet.

Everytting is archiving again though! That's good news.

[shampoo]

Hmm need some assistance on that. As far as I can tell I don't have any performance gc issues. However the query slowly completes with every 2 seconds one mailbox (orso)

1141 11:16:41.273  [1376] (mmc) <5068> EV:M       Leaving ProcessObjectAttributes()
1142 11:16:41.273  [1376] (mmc) <5068> EV:M     Examining mailbox 54 of 500 in current row - DN: CN=CRMSystem,OU=SUBOU,OU=SUBSUBOU,DC=DOMAIN,DC=COM
1143 11:16:41.273  [1376] (mmc) <5068> EV:M       Binding to: GC://dc.domain.com/CN=CRMSystem,OU=SUBOU,OU=SUBSUBOU,DC=DOMAIN,DC=COM
1144 11:16:43.523  [1376] (mmc) <5068> EV:M       Entering ProcessObjectAttributes()
1145 11:16:43.523  [1376] (mmc) <5068> EV:M         Found distinguishedName: CN=CRMSystem,OU=SUBOU,OU=SUBSUBOU,DC=DOMAIN,DC=COM
1146 11:16:43.523  [1376] (mmc) <5068> EV:M         Found displayName: CRMSystem
1147 11:16:43.523  [1376] (mmc) <5068> EV:M         Found mailNickname: CRMSystem
1148 11:16:43.523  [1376] (mmc) <5068> EV:M       Leaving ProcessObjectAttributes()
1149 11:16:43.523  [1376] (mmc) <5068> EV:M     Examining mailbox 55 of 500 in current row - DN: CN=John Doe,CN=Users,DC=DOMAIN,DC=COM
1150 11:16:43.523  [1376] (mmc) <5068> EV:M       Binding to: GC://dc.domain.com/CN=John Doe,CN=Users,DC=domain,DC=nl
1151 11:16:45.789  [1376] (mmc) <5068> EV:M       Entering ProcessObjectAttributes()
1152 11:16:45.789  [1376] (mmc) <5068> EV:M         Found distinguishedName: CN=John Doe,CN=Users,DC=DOMAIN,DC=COM
1153 11:16:45.789  [1376] (mmc) <5068> EV:M         Found displayName: John Doe
1154 11:16:45.789  [1376] (mmc) <5068> EV:M         Found mailNickname: Johnd 

-Again, mailbox synchronization "queries" go fast.
-LDAP policies are default.

Policy                          Active (new)

MaxPoolThreads                  4
MaxDatagramRecv                 1024
MaxReceiveBuffer                        10485760
InitRecvTimeout                 120
MaxConnections                  5000
MaxConnIdleTime                 900
MaxPageSize                     1000
MaxQueryDuration                        120
MaxTempTableSize                        10000
MaxResultSetSize                        262144
MaxNotificationPerConn                  5
MaxValRange                     0 

-Netdiag & DCdiag passed.

//edit:

You can Dtrace MMC.exe - the
You can Dtrace MMC.exe - the VAC is binding to each user (in AD) from the Exchange server to read the properties it requires before displaying the list, in a slow environment you may see it take upto 2 seconds per user (normally it should be in the order of ms).

I believe this has been addressed in the next major release.

Regards

Karl

So no worries there.

[shampoo]

Missed this topic completely: https://www-secure.symantec.com/connect/forums/browse-select-systemmailbox-extremely-slow 

But Karl sais this. The long wait is a bug kinda.

You can Dtrace MMC.exe - the
You can Dtrace MMC.exe - the VAC is binding to each user (in AD) from the Exchange server to read the properties it requires before displaying the list, in a slow environment you may see it take upto 2 seconds per user (normally it should be in the order of ms).

I believe this has been addressed in the next major release.

Regards

Karl

 So no worries for me anymore. This is in line with my findings.