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.

Migrating by department. BION, somoene's doing it.

In the several hundred migrations we've done over the last decade we've adopted as an article of faith that the right way to move meetings is as a Big Bang. It preserves the connections among all the users you migrate and it's not hard to explain to end users. A win-win for the community, an intense time for the administrators, but they get the win-win for the community.

We've always told you though that if your user community mainly consisted of "islands" who tend to only meet internally you could get away with migrating a department (or island) at a time.

But nobody took us up on it.

UNTIL a university in upstate New York said "OK -- we'll try that."

Russ and Zyg sucked in their breath and said "All right then. But if things are not going well after the first few we're going to re-evaluate this, right?"

THREE separate group migrations into it, they seem to be going all right.

There's a few more to go and we're still looking at it, but the results so far are good and we want to give you a preliminary read on how they did it and what's making it work. We're also giving them the opportunity to add anything they want to share in this post.

1. It's relatively small (about 500 users).


2. They are able to identify very specific groups that meet together. The MM / Exchange administration team are doing this on their own without intense database analysis from us (which has helped keep their costs down).


3. Once the island is migrated those users are removed from the Meeting Maker user list. Since they're islands, this isn't usually a problem. As Russ put it, "They burned their bridges after they crossed over."


4. The migration team at the university gained experience early on in mapping users and after a proof of concept migrating their internal team they then proceeded to two other islands. Again, their motivation and competence here was key in keeping costs in control.


5. After three separate island migrations things are looking good to complete the rest on a staggered schedule.
6. The university adds that advance testing and end-user expectation communication made things go better.


7. We at Sumatra are happy to give credit whenever our clients are more clever than we are.

So our moral: It is possible, but start small and keep an eye on it as you move forward.

What's this look like from an end-user's perspective? The same as it would in a full migration. They walk in one morning and user Meeting Maker. They walk in the next morning and they're on Exchange. BUT: Any MM users not in the migrated group are now not on their guest lists. That's the price you pay for this staggered approach. In the immortal acronym of Robert Heinlein as morphed by Milton Friedman, TANSTAAFL.

Blast from the past

Look what Zyg found in the basement.

Meeting Maker 1.5 diskettes (DISKETTES!), back when it was Macintosh only. The video comes from a few years later after a bunch of est-heads (no joke) bought the company and decided to align themselves to the up-and-coming software powerhouse -- Novell.