3 forests 1 exchange server
Currently I have 3 separate forests. One for the email server (company.local), one for part of the company (companya.local), one for the research part of the company (research.local). None of the forests have trust relationships. I am guessing this was done for security reasons. companya.local will be replaced with a windows 2008 R2 forest shortly. research.local is a windows 2008 r2 sp1 forest. company.local is a windows 2003 with exchange 2003 server. Most of the users use OWA to access their email. I am thinking of replacing the exchange 2003 server with exchange 2010 and putting it in the companya.local forest. This simplifies the login to the email server for the users in the companya.local forest. I would use integrated windows authentication but just having the same username and password would be huge. I realize that I would create user accounts for the researchers in the companya.local forest. These account will have the same username as the research forest but a different password expiration policy and I can live that. I can also deny the research group the ability to login to a companya.local PC. I don't see the researchers using this capability as they have a separate building to themselves. Does this sound like a good plan? Are there other solutions I am not seeing? Something that might allow both groups (researchers and companya) to use their same usernames and passwords to access the email from their respective forest? I have about 100 users in research and 250 in companya. I thought about getting a second exchange server, 1 for each forest, but the cost is a little steep and I am not sure how I would setup each server using the company.com email address. I.e. MX record for company.com points to mail.companya.local. How would mail.companya.local know to forward the researchers email to research.local?
March 29th, 2011 12:54am

Hello, Generally, for the cross-forest with one Exchange situation, the most recommended deployment is Resource Forest Topology: You can refer to the following article to see if this can meet your requirement. http://technet.microsoft.com/en-us/library/aa998031.aspx Hope it helps. Thanks, Simon
Free Windows Admin Tool Kit Click here and download it now
March 29th, 2011 9:46am

I think the Resource Forest Topology is exactly what I want. I will have 1 Exchange 2010 SP1 forest which will non-transitively trust companya.local and research.local. I will still have 3 forests but the username and password problems will go away. There is no worry about researchers using resources in the companya.local forest. No one from the company can use the researchers resources. Users can still email each other using the same global address book. I think this might work great. Will I have to upgrade the schema in the companya.local and research.local forests? Also is company.local still a good name to use for the exchange forest? Thanks,
March 29th, 2011 5:42pm

Hi Jack, We can continue using the previous org name. For more reference about how to deploy the Resource Forest Topology, I would like to share with you the following article: http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/deploying-exchange-resource-forest-part1.html http://www.msexchange.org/articles_tutorials/exchange-server-2007/planning-architecture/deploying-exchange-resource-forest-part2.html Thanks, Simon
Free Windows Admin Tool Kit Click here and download it now
March 29th, 2011 9:47pm

Simon, I must say the articles made for good reading. I do have a couple of questions though: 1) Do I need to extend the schema in the account forests? 2) In the article they use transitive trusts. Why? Non-transitive would be more secure right? 3) Can I assume the procedures outlined in the articles are similar to those needed for Exchange 2010? 4) I was planning on using exmerge to export my users email from Exchange 2003 to pst files and then import the pst files into Exchange 2010. Is this a good way to migrate?
April 1st, 2011 9:34pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics