Exchange Archiving Task gets stuck at ConfigureMsgService

[hil-ger]

At creating a new Mailbox Archiving Task the Task stucks at creating the MSMQ-queues. I tried it a few times and everytime the last line in a dtrace was:

2516    12:54:25.852     [3500]    (ArchiveTask)    <6152>    EV:M    CMailboxHelper::CPAS() - ConfigureMsgService

After that nothing happens, the creation was not finished successfully, but the Task is in "running" state, but i would expect a state like "start pending" or "failed". The dtrace-file is attached.

The Exchange Mailbox Archiving Task is not working.

Please have also a look at: http://www.symantec.com/connect/forums/queues-a1-a7-missing-after-creation-mailbox-archiving-task

Does anybody have an idea?

Regards
Gerrit

[KarlW]

I'm not normally an advocate for Closest GC registry value but given ConfigureMsgService is hanging rather than returning an error you could try setting this registry value.

See either of the following:

http://www.symantec.com/docs/TECH70546

http://www.symantec.com/docs/TECH48537

There are probably other TechNotes that may help too.

Thanks

Karl

[hil-ger]

I checked this option, but it wouldn´t work: The Enterprise Vault server is archiving in total 5 Exchange servers in 3 different domains in 3 different forrests. The Closest GC-Key would kill the connection to the other Exchange servers and domains.

Regards
Gerrit

[JesusWept3]

yeah Closest GC is only good when you have 2 domains max, more than that and as you said it will fail the others.

The thing is, when you did set Closest GC did the ones that weren't doing anything actually work this time?
In past experience when the ArchiveTask gets stuck on ConfigureMsgService its been because the System Mailbox was hosted on a different exchange server.
 

But because you have created the tasks so many times i'm assuming this isn't the case as the system mailbox wouldn't be valid for selection when you created it.

Just as a matter of interest, logged on to the EV Server as the EV Admin account can you connect to evsysmb02@ddd.de without it prompting you for a username and password? and is this an Exchange 2003, 2007 or 2010 exchange server?

Maybe worth running a Deployment scanner to ensure Send As/Receive As permissions are correctly set.

Oh and if that mailbox does prompt you for username and password when logged in as the EVAdmin account, it means that send as/receive as is not set correctly.

One last quick question, what is the level of trust between the domain EV is in and the domain that exchange server is in?

[KarlW]

I did have one weird case where AD was getting in a muddle because the appropriate language packs where not installed (EV was Japanese and AD wasn't configured to accept Japanese clients).

After trying JesusWept2's options my last line of attack would be a network trace on EV and also on the Exchange server if possible.  You could compare good with bad and see where the differences are.

Lastly what version are the Domain controllers - Windows 2008 has a restriction on the number of NSPI calls but you'd normally get a MAPI login error (0x80040111) rather than a hang?

Thanks

Karl

[hil-ger]

Yeah, closest gc will bring you in trouble at the second domain/forrest you want to integrate.

I could login to the systemmailboxes with the VSA-user without prompting for a username/password. That works fine.

The first exchange-system is in the same domain as EV and a 2007 Exchange, the second is 2003 and the last one, which is not working in this case is also a 2003 Exchange.

The deployment scanner results are ok:

- Exchange Server Version: yellow, the for version of the 2007 Exchange server see Compatibility Charts and all 2003 Exchange server are green, also EXSRV01 and EXSRV02, which have this problem.

- Exchange Server Permissions: All green and ok.

The trusts between the domains:

- First domain with 2003 Exchange (ok) is a cross-forrest-trust

- Second domain with 2003 Exchange (failed) are two unidirectional connections, because cross-forrest-trust wouldn´t work, because these domain is on a Win2000 functional level. This is not changeable. The sid-filtering is off.

May this be a problem of the kind of trust between the domains?

Regards
Gerrit

[JesusWept3]

gotcha ok, so quick question, is there a reason for the GC Override GC://dedddw02.ddd.intern?

[hil-ger]

The language packs are all the same: English and German, no Japanese.

All DCs are W2K3 servers.

[sids]

Hil-ger,

Are you facing issue creating Message Queue, Specially Archive Queue??

If Yes, Is it first time you are creating Mailbox Archiving Task or it has worked for you before??

Sids...

[hil-ger]

We discussed the hints and i´m thinking about a possible way to a solution. But i do not know if this could work:

1. Stop all Exchange Mailbox Archiving Tasks of the two working Exchange-systems and domains/forrests

2. Stop all Provisioning Tasks of the two working domains

3. Set Closest GC Key to the GC of the third (not working) domain

4. Keep Provisioning Task of third domain on running

5. Create Exchange Mailbox Archiving Tasks for the two Exchange servers of third domain

6. Check if they are working fine now

7. Restart the Mailbox Archiving Tasks for the third domains Exchange servers

8. If the restart is successful: Delete the Closest GC Key

9. Start the Provisioning Tasks of the first and the second domain

10. Start the Mailbox Archiving Tasks of the first and the second domains Exchange servers

11. Restart of the Provisioning Task of the third domain

12. Restart of the Mailbox Archiving Tasks of the third domains Exchange servers

13. Check out, if all the queues are created, no errors occur and the Tasks are functioning correctly

Could this be a possible way? What is about the risks to damage the Tasks of the other domains? Any comment of Symantec Engineers about this?

Regards
Gerrit

[hil-ger]

It is not the first time creating Mailbox Archiving Tasks in that system. Up to now there are 3 Exchange-servers in two domains/forrests working on that Enterprise Vault server. The 4th and 5th Exchange servers in the third domain have this problem.

[hil-ger]

Reason for the GC Override GC://dedddw02.ddd.intern?

Yes, we had it with the second domain, without this entry there were no chance to configure anything for the second domain. Also this was an advise of a Symantec-consultant to do this in an environment like these.

[JesusWept3]

what version of outlook do you have installed on the machine?
Is it possible you could try a different system mailbox? it shouldn't make a difference but have also seen issues where you just specify any other mailbox on the server (as long as its enabled, not hidden etc) and it all magically seems to work

Also it may be worth having a quick look at the event logs on that other exchange server and just see if its throwing any errors when EV tries to connect to it

[KarlW]

In this scenario EV's GC override isn't coming into play (it would if you were at EV 9.0).  Closest GC doesn't point at a server (it's a 1 or 0).  DS Server is used to point at specific GC's.

It would be an interesting note to see if it can work but beyond that you're going to have an on-going issue as the tasks would not be able to run at the same time.

Since Outlook works and connects OK to the system mailbox I'd consider a NetMon trace of the ArchiveTask starting up and another creating a profile in Outlook manually (ConfigureMsgService call translates to clicking the Check Name button on the new profile wizard).

Regards

Karl

[sids]

I have faced similar issue in my Testing Enviournment and I couldnt figure out, I have checked forum and decided to log a call with Symantec...

Symantec Engineer worked with me for 2 weeks and couldnt figure out, Since It was my Testing Server I decided to Reinstall EV as i had my SQL Database for EV on a Remote SQL Server which made it a little easy to Reconfigure.

Best Part is I have Reinstalled Message Queue and Permission were verified by Symantec Tech and as per them every thing was setup correctly, They Kept checking dtrace and they didnt find any thing suspicious:(..  It was not worth investing time as my Test Enviournment is identical to Production and I had to get EV Server up and Running....

In my Case it was first time where i was setting up mailbox Arching Task and R Queue were getting created where else Archive Queue will not and never worked until i had Reinstall EV completely.

I am very eager to know what else I could have done to fix the issue so i am following Thread:D

Sids...

[PJuster]

i've not seen this exact issue, but this could be worth a try

http://support.microsoft.com/kb/319206 instead of closestgc, can you try "ds server" and put in GC://dedddw02.ddd.intern and restart the tasks.

i'm not sure how this will work with the many forests.

I've seen this work for other customers with a single forest, its not ideal.  I have been told that in 9.0.1 EV has some better logic for connecting to Exchange by trying the exchange server and then the GC (if memory serves me right.)

HTH

Paul

[hil-ger]

Hi!

Here are the answers:

On the EV-server Outlook 2007 (12.0.6535.5005) SP2 MSO is installed.

I meant Closest GC and DS Server Registry Key in one. Both have to be changed.

I will try to set only the DS Server Key and find out if this works.

A new installation ofd Enterprise Vault in this productive environment is no option, because some Exchange server are active archived. But if i new installation helps, which parts were damaged and should be repaired?

Regards
Gerrit

[hil-ger · Accepted solution]

I tried this out:

1. Stop all Exchange Mailbox Archiving Tasks of the two working Exchange-systems and domains/forrests

2. Stop all Provisioning Tasks of the two working domains

3. Set DS Server Registry Key to the GC of the third (not working) domain

4. Keep Provisioning Task of third domain on running

5. Create Exchange Mailbox Archiving Tasks for the two Exchange servers of third domain

6. Check if they are created completly. Yes: All queues (admin, r1, r2, a1, a2, a3, a4, a5, a6, a7) were created.

7. Restart the Mailbox Archiving Tasks for the third domains Exchange servers

8. If the restart is successful: Delete the DS Server Registry Key

9. Start the Provisioning Tasks of the first and the second domain

10. Start the Mailbox Archiving Tasks of the first and the second domains Exchange servers

11. Restart of the Provisioning Task of the third domain

12. Restart of the Mailbox Archiving Tasks of the third domains Exchange servers

I´m still checking out, that no errors occur and the Tasks are functioning correctly. But it looks good so far. I will let you know, when i´m finished with all tests and all Tasks are running fine.

Thanks KarlW and PJuster!

Regards
Gerrit

[KarlW]

Hi Gerrit

I would recommend testing heavily the solution.  In theory whilst it got the third domain up and running now that the DS Server registry value has been deleted the next time the Exchange task for that Exchange Server needs to restart it is likely to have the same fate as previously.

Obviously the simplest way to test this is to now restart the task with Dtrace enabled, and see if it gets beyond the ConfigureMsgService call.

Regards

Karl

[hil-ger]

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider

Value name: DS Server
Data type: REG_SZ (string)
Value data: FQDN of the global catalog server