Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

EV9 Cross-Forest Implementation

Created: 13 Dec 2012 • Updated: 12 Mar 2013 | 7 comments
This issue has been solved. See solution.

I realize I will eventually involve Professional Services with this architectural scenario, but wanted to briefly explain our migration scenario. In advance, I appreciate any insight.

Two companies, two separate forests. ForestA and ForestB have a forest-level, bi-directional transitive Active Directory trust. ForestA/DomainA has Exchange 2007. ForestB/DomainB has Exchange 2010. Our migration effort is to move all DomainA mailboxes to DomainB.

Our current environment - Exchange 2007 and EV v9 - are in a domain of ForestA. The AD user accounts in DomainA are mailboxes. Associated EV Vaults are attached to this mailbox. Already-existing user accounts in DomainB are mail users.

After the migration of mailboxes from DomainA to DomainB, the user account in DomainA becomes a mail-user. The user account in DomainB is a linked mailbox associated with the DomainA Active Directory account. The mailbox moves from DomainA (EX2007) to DomainB (EX2010)

Post-migration, Enterprise Vault in DomainA can no longer perform the archiving or provisioning tasks because, naturally, it cannot see the mailbox any longer. With the assistance of technical support, we've tried several things:

  • Added the new EX2010 mailbox servers in DomainB to EV in DomainA and assigned archiving and provisioning tasks.
  • Added an additional two-way, external trust between DomainA and DomainB, although probably redundant and unnecessary due to the forest-level trust.

The provisioning task and archiving task doesn't see the mailboxes that are moved to DomainB. The Event logs are filled with permissions woes.

I know this is an atypical EV implementation; I'm just wondering if anyone has had any experience with this sort of migration.

Discussion Filed Under:

Comments 7 CommentsJump to latest comment

JesusWept3's picture

OK So this is basically a resource domain that you have now right?

i.e.
Domain A = Users
Domain B = Mailboxes attached to disabled user accounts

DOMAINA\User1 has Mailbox Owner on DOMAINB\Mailbox1 correct?

And in the VAC you are targeting Exch2010-1.domainB.com and are provisioning against DomainB correct?

What are the exact permission errors you are seeing?
You ran the permissions script as an Exchange Admin specifying the EVAdmin, correct?
And the EVAdmin has a mailbox on Exchange 2010 that you are targeting?

Is the EVAdmin in DomainA or DomainB?
and its mailbox is on Exchange 2010 as well correct?

Jeff Shotton's picture

"Added an additional two-way, external trust between DomainA and DomainB, although probably redundant and unnecessary due to the forest-level trust."

This can in fact cause permission problems due to name suffix routing (this happened at my last similar engagement where the AD engineers configured the trusts incorrectly). You might want to read the following:

http://blogs.technet.com/b/askds/archive/2009/04/1...

As you have a forest level trust, you need to check the name suffix routing at that level in active directory domains and trusts.

Regards,

Jeff

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

NaturesRevenge's picture

JW3: Thank you for your time!

OK So this is basically a resource domain that you have now right? Correct

i.e.
Domain A = Users
Domain B = Mailboxes attached to disabled user accounts Yes this is accurate.

DOMAINA\User1 has Mailbox Owner on DOMAINB\Mailbox1 correct? Yes, DomainA\User1 has FullAccess and ExternalAccount permissions.

And in the VAC you are targeting Exch2010-1.domainB.com and are provisioning against DomainB correct? Yes this is correct. In DomainA, the primary EV mailbox archiving server has a new Archiving Task and Provisioning Task for the EX2010 servers in DomainB. (Also created is a new Exchange target, for DomainB.) There is an EVAdmin service account created in DomainB, with permission script successfully ran. This service account is what the archiving and provisioning tasks are attempting to run as.

What are the exact permission errors you are seeing? Errors dealing with "managed folders" or that the credentials for the DomainB service account are invalid, which they are not.
You ran the permissions script as an Exchange Admin specifying the EVAdmin, correct? Yes.
And the EVAdmin has a mailbox on Exchange 2010 that you are targeting? Correct.

Is the EVAdmin in DomainA or DomainB? DomainB.
and its mailbox is on Exchange 2010 as well correct? Correct.

NaturesRevenge's picture

@Jeff, thank you for this insight. I believe this is enough justification to remove the otherwise redundant domain-level trust!

Jeff Shotton's picture

Possibly....probably. Certainly just creating trusts across all domains without regard to how authentication works is not the best of ideas :)

Im assuming that you therefore have a separate vault service account and an account for running the archiving task in the remote domain?

Since you are using a remote account for running the task you are essentially going to have to give this account the same rights as when the vault service account was set up...i.e access to the enterprise vault server as an 'administrator' (so that it can log on as a service/log on locally etc etc) and rights to the EnterpriseVaultDirectory database.

Are the tasks actually starting properly for the exchange 2010 domain, or do they start and go to 'failed' after a short time?

I've also noticed in these kind of environments that when a service account is in the remote domain, impersonation does not work properly when creating MAPI profiles for certain functions, such as manual synch etc - although automatic synch is fine.

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

TypoProne's picture

Hey Nature.....

Just wanted to follow-up and see if you had this resolved, if Jeff or JW fixed this for you, or if you had a differnt solution. Regardless... can you please note it accordingly or update us as to what happeend so that resources seeking to help can find those in need.

Many thanks!!
 

Regards.

NaturesRevenge's picture

Yes, sorry for the delay!

I ended up opening a support case with Symantec support. This cross-forest configuration ended up being pretty tricky and overwhelming, but in the end, it came down to proper service account permissions within SQL. I appreciate everyone's attention and recommendations!

SOLUTION