Resource Forest Redux

We just re-wrote the sections on our migration manual dealing with Resource Forests in Exchange 2007/2010 -- here's the early version

• The "User Forest" - I started with an existing AD 2003 Domain - ad03.herring.sumatra.local (windows server 2003)
  
  • Create a user account "Blarney Stone", alias = bstone in the herring.sumatra.local domain
    
• The "Resource Forest" - a new VM: "Resource" forest domain called Sherwood: ex07res.sherwood.sumatra.local. The CAS server is "ex07res"
  
  • In AD Domains & Trusts:
    
    • Ensure DOMAIN AND FOREST levels are windows 2003
      
    • Created a TWO-way: forest trust between the Resource & User forests (Sherwood to Herring) Note: A resource forest trust is a configured ONE-way trust between the Resource & User domains. If you do this, the service account won't be able to see AD, and thus won't be allowed to access anyone's mailbox.
      

Example of the TWO-WAY forest trust between the resource (Sherwood) and the user forest (Herring) (Shown from Active Directory Domains and Trusts)

• In AD Users & Computer on the RESOURCE FOREST ("sherwood"):
  
  • Added the computer ex07res to built-in group windows authorization access group
    
  • Create a service account deleg8 in the resource forest (A new USER account).
    
• Use Exchange Management Console to:
  
  • Create LINKED mailboxes "Blarney Stone" alias = bstone (in sherwood.sumatra.local) Linked to bstone (in herring.sumatra.local)
    
  • Remember to reconfigure IIS to use SSL and have OWA default site property (in the server configuration) to use forms-based authentication
    
• In AD Users & Computer on BOTH the RESOURCE FOREST ("sherwood") AND on the USER FOREST (herring):
  
  • Right-hand click on the domain, get properties, and in the security tab Grant Deleg8 FULL ACCESS to AD. You'll have to go into advanced and set these permissions "for this object & all child objects". If you don't see the security tab, turn on Advanced Features under the View menu.
    

Example of granting FULL Control to this object & all child objects (Deleg8 on Sherwood

(Shown from Active Directory Users & Computers)

• In Exchange Management Shell, on the Resource Forest (sherwood), run this against your CAS server, "ex07res"
  
  • Add impersonation between the (resource forest) service account AND the user account:
    
    • Add-AdPermission -Identity (Get-ExchangeServer -Identity "ex07res").Identity -User sherwood\deleg8 -ExtendedRights ms-Exch-EPI-May-Impersonate, ms-Exch-EPI-Impersonation, send-as, receive-as -accessrights genericall -inheritanceType All
      
    • Add-AdPermission -Identity "Blarney Stone" -User sherwood\deleg8 -ExtendedRights ms-Exch-EPI-May-Impersonate, ms-Exch-EPI-Impersonation, send-as, receive-as -accessrights genericall -inheritanceType All
      
  • Grant Full access to the (resource forest) service account AND the user account:
    
    • Add-MailboxPermission -Identity "Blarney Stone" -User sherwood\deleg8 -ExtendedRights fullAccess -InheritanceType All
      

      
      

• In the Sumatra UI on a 32-bit machine:
  
  • Run the code as the resource service account (sherwood\deleg8)
    
    • I assume you've already granted that account local login rights, and made it a local administrator so you can read/write from the disk)
      
  • The forest: "herring.sumatra.local"; the SMTP domain: "sherwood.sumatra.local"
    
  • CAS server: ex07res (https://ex07res/ews/exchange.asmx)
    
  • Access calendar using: IMPERSONATE
    
  • Test user: bstone (SMTP address: bstone@sherwood.sumatra.local)
    

    
    

• Other Notes and Deviations from the Sumatra documentation:
  
  • Something changed between Exchange 2007 RTM and SP1/SP2. we've had to change our process.
    
  • Microsoft's David Sterling said that EWS expects there to be some sort of AD object in the resource forest to represent the cross forest account, and unfortunately, a foreign security principal is not enough. He wrote out instructions here: http://msexchangeteam.com/archive/2008/04/18/448727.aspx. BUT it doesn't work because he recommends duplicating a SID between the User and Resource forests. That generates lots of AD errors for that service account, and breaks OWA access (as that service account).
    
  • The tool to set permissions on the RESOURCE forest (Sherwood) MIGHT cause you problems because it does not explicitly set permission inheritance. So the permissions might allow you to validate against the mailbox, but NOT insert calendar data. Here was the tool: http://msexchangeteam.com/files/12/attachments/entry447730.aspx
    

• Use the Get-Mailbox -resultsize unlimited add-mailboxpermission to set permissions for all accounts, e.g., Get-Mailbox -resultsize unlimited Add-AdPermission -User sherwood\deleg8 -ExtendedRights ms-Exch-EPI-May-Impersonate, ms-Exch-EPI-Impersonation, send-as, receive-as -accessrights genericall -inheritanceType All
  

  PowerShell example of using get-mailbox (you might see warnings if you've already applied the ExtendedRights to some mailboxes.
  

  
  

• We set AD access on both the RESOURCE and the USER forests
  
• We were able to add a test item using impersonation. Delegation was not working.
  
• After the migration:
  
  • Remove the service account's full access permissions in AD
    
  • Set the trust back to a one-way trust
    
  • Remove the service account
    

• Other fun facts about resource forests:
  
  • Full Disclosure: I am not a fan of Resource Forests. Yes, they offer additional security. At the cost of 4x the complexity. I apologize to you who have implemented them successfully and are happy Exchange Admins. I'm not alone in that opinion. How a resource forest can make you cry is Vermyndax's rant.
    
  • It's easy to implement the Resource Forest in a way that causes the end user's lots of pain. For example:
    
    • Every time the user logs in to Exchange, they have to enter their resource forest credentials. That's almost as bad as my car: it automatically locking the doors once the car starts moving. Great for safety. But, every time I want to exit the car, I either have to either unlock the door before I can open it, OR pull the door handle twice – the first time UNLOCKS the door, the second time OPENS the door. Great security design. Miserable user experience. But I digress. The way around this, by the way: You have to assign the account in the USER forest these additional rights:
      
      • "Read Permissions",
        
      • "Full Mailbox Access", and
        
      • "Associated External Account"
        
    • We had problems when some DELEGATES tried to access their boss' calendars and could not. We discovered those delegate mailboxes did not reside on the same server as their boss's mailbox. The solution: move the delegates mailbox!
      
    • There were access problems for customers who have public folders (you need them if you have Outlook 2003, or if your organization uses public folders). I couldn't figure out how to solve the access problem. Thankfully Jim McBee "Mostly Exchange Web Log" AND Jesper Bernle's Exchange Server blog wrote about how to solve it. Jim McBee found and fixed issues with permissions and delegate mailboxes.