Mailbox Archiving Task - Enable Mailbox stucks

[hil-ger]

Hi!

After the fix of my problems in the threads

https://www-secure.symantec.com/connect/forums/queues-a1-a7-missing-after-creation-mailbox-archiving-task

and

https://www-secure.symantec.com/connect/forums/exchange-archiving-task-gets-stuck-configuremsgservice

i have now a new problem. The Mailbox Archiving Tasks are complete created incl. all MSMQ-queues. That worked with registry key "DS server". Now, i deleted the Registry Key after some Synchronizations and some "Enable Mailboxes".

After i deleted the Registry Key, the following stucks:

- Enable Mailbox (=> No answer at enabling mailboxes for more than 15 min., no errors, no events)
- Synchronization in Mailbox Archiving Task (=> Queue a7 grows up)
- Disable Mailbox (=> No answer at enabling mailboxes for more than 15 min., no errors, no events)

I deleted the Key to reactivate the other Mailbox Archiving Tasks of the other domains/forrests, which would run inot error if the Key

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

is set.

Has anybody an idea to get this to run in a multiple Exchange-, multiple-domain- and multiple forrest-construction?

Regards
Gerrit

[JesusWept3 · Accepted solution]

for that other domain you may have to create a new EVAdmin for the site unfortunately.

So you may have the following

EVAdmin is a user in DomainA

DOMAINA -> All Exchange Server tasks work
DOMAINB -> All Exchange Server tasks work
DOMAINC -> All Exchange Server tasks do not work

If you use DS Server pointing to a GC in DOMAINC, the Exchange Server Tasks in DOMAINC work but DOMAINA\DOMAINB both fail....

So what you would do is the following
1, Create a new EVAdmin in DOMAINC
2. Give it the same permissions as DOMAINA\EVAdmin had on all the exchange servers (Send As etc)
3. Make the DOMAINC\EVAdmin a local admin on the EV Servers
4. Log on to the EVServer as DOMAINC\EVAdmin
5. Create an outlook profile to the DOMAINC Exchange Servers system mailbox for EV
6. Create the DS Server registry key pointing to the DOMAINC Global Catalog
7. Change the DOMAINC exchange server tasks to Run as the DOMAINC\EVAdmin identity

The reason this would work is that the DS Server is an HKEY_CURRENT_USER registry key which is tied to the user , where as HKEY_LOCAL_MACHINE is a machine wide setting that would affect everyone.

The Tasks do allow for different users to run them, so in this case you would leave all the tasks for DomainA and DomainB alone, and DomainC would run as an EVAdmin within that domain, then when the task runs, it runs as DomainC\EVAdmin, within that user profile it will read the DS Server registry key and connect to the specific Global Catalog.....the other domains will run as a different EVAdmin and not connect to that specific GC

[KarlW]

Just a quick question - When talking about Domains, are these actually different Forests (and Exchange Organizations) or is it all one forest, multiple domains.

If possible could you share the AD / Exchange topology and whether or not you have any Exchange 2010 servers?

Regards

Karl

[hil-ger]

These three domains are also in three different forrests. That are historical grown three different Exchange-systems:

Domain A (fff) : Domain/Forrest in 2003-Mode, Exchange 2007, EV 8.0.4

Domain B (mmm): Domain/Forrest in 2003-Mode, Exchange 2003

Domain C (ddd): Domain/Forrest in 2000-Mode, Exchange 2003

Trusts:

Domain A-B: cross-forrest-trust

Domain A-C: 2 unidirectional connects with sid-filtering off

Regards
Gerrit

[KarlW]

As you don't have Exchange 2010 (some configurations currently require DS Server to be set) another option would be to upgrade to EV 9.0.  EV 9.0 should be able to archive from the different forests without the requirement on DS Server.

As ever I would recommend validating in a test environment that matches your own before upgrading the production set up.

Regards

Karl

[JesusWept3]

Karl,
Just as a matter of interest what has "Changed" between Enterprise Vault 8 and Enterprise Vault 9 that would be more robust against multiple domains/forests when targeting Exchange 2003 and Exchange 2007?

As far as i'm aware the achilles heel that is DsGetDcName is still used to determine GC's and such as well as issues seen within ConfigureMsgService. In our environment where some servers archive from five domains we still have issues from time to time where ConfigureMsgService will throw out the MAPI_E_NETWORK_ERRORS, and the GCOverrides will only take us so far etc.

[KarlW]

I think you've already worked it out.  In 9.0 if ConfigureMsgService fails when talking to the Exchange Server we retry using a GC instead.  This is feasible because ConfigureMsgService is making an NSPI and a GC supports this end point (Exchange 2003, 2007 proxy the request to a GC anyway).

You're right there are sometimes issues around GCs and DsGetDCName.  We've seen in some circumstances that the Windows API calls don't always return a GC even when explicitly requested - this can cause problems, also the GC returned by these calls may not be available and that can cause us problems.

Before EV 9.0 GC lookup and use (including GC Override) was never used for this purpose and and no relationship to MAPI profile / session creation.  If using GC override as long as it is available and truely a GC you should not have issues.

Thanks

Karl

[hil-ger]

Hi @ all!

Thanks, JesusWept2, for your hint.

We tried it out, and it works. But we needed some more configurations to get this to run:

- Settings in Local Security Policy:

Security Settings - User Rights Assignment -

1. Log on as a service
2. Replace a process level token

In both i had to add the User DOMAINC\EVAdmin.

Also it is important to set the HKEY_CURRENT_USER/Software/Microsoft/Exchange/Exchange Provider/DS server = DC of DOMAINC (FDN)

Not to forget the settings on the Exchange-servers in DOMAINC and to add the DOMAINC\EVAdmin to the EV-Role "Power Administrator".

The Registry Key "Closest GC" was not used.

Up to now we tested if we can disble/enable mailboxes of DOMAINA, DOMAINB and DOMAINC. That works and looks fine. Now we will test the normal operation of the DOMAINA and DOMAINB in the coming up night. Tomorrow we will know more.

But i looks really really goooood! :)

PS: This would be a fine TECH-Doc... ;)

Regards
Gerrit

[JesusWept3]

ah crap yeah, i'm sorry i missed those points but good job on getting it going :)

[hil-ger]

Thanks a lot JesusWept2 !

I will place the results of our intensitive testing in the next days here.

Regards
Gerrit