Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Here's an interesting one that I can't figure out. I was about to call MS, but figured I'd check here first.

Scenario:

Two Exchange 2010 forests federated with GAL Sync.

User Bob@domain.com had a mailbox on Exchange 2010 server.

Bob now has a new mailbox on a different Exchange forest (Bob@Awesome.com).

Bob wants his old email forwarded for Bob@domain.com to Bob@Awesome.com.

So...easy enough right? Create a contact in the domain.com Exchange server and set the forwarding on the mailbox and for grins hide the mailbox from the address books. Done, right?

Wrong (sort of)...because (note: I have federation and GAL sync allowing free/busy across forests):

Bob is getting auto-forwarded meeting requests from Sally@domain.com who used the Scheduling assistant and typed in "bob@domain.com" and saw that he's available. He gets the calendar forward and says "Um...Sally...I'm booked at that time" to which she replies "not from what I see".

Now if Bob is available on bob@awesome.com and he accepts, it shows up on his awesome.com calendar as it should. But Sally sees the request still sent to Bob@domain.com in the scheduling assistant as he is free but bob@awesome.com is coming to the meeting.

SO...basically users in the domain.com organization can still see free/busy details on the old calendar for the mailbox bob@domain.com even though the mailbox is hidden from the GAL.

THE QUESTION:

Since I can't create a contact and then forward that contact....is there any way around the above? I don't think I can remove a calendar from a mailbox. I considered removing all calendar permissions but wasn't sure if that was the right path to go down or not.

OR even better: Can someone tell me how to accept email for bob@domain.com on Exchange without having a mailbox for him and then re-route it to bob@awesome.com?

UPDATE: I have figured out how to handle the calendar with removing the default permissions...it's an ok fix. The BOUNTY will be for the "OR EVEN BETTER" question in bold. If it isn't possible, then that doesn't count as BOUNTY worthy. :) Thank you!

share|improve this question
1  
Are both orgs under your purview? If not, do you have cooperation from the other org on this issue? If so, you can configure SMTP namespace sharing to easily accomodate this scenario. –  joeqwerty Jan 7 '13 at 17:49
    
Yes, they are both under my control. They are both internal to our company now and there is a transitive trust between us. –  TheCleaner Jan 7 '13 at 19:28
    
In that case I think SMTP namespace sharing will do the trick. –  joeqwerty Jan 7 '13 at 19:32
    
@joeqwerty - I figured that might be the next path, but I was hoping not to go down the path of setting up connectors directly, etc. I'll look more into this though and if that's the path taken I'll update here and have you create an answer that I'll accept. –  TheCleaner Jan 7 '13 at 19:35
    
@joeqwerty - it looks like namespace sharing is the trick here for us. MS confirmed it and we are gathering the details to implement it into production. If you'll create an answer I'll accept and then we can wipe out these comments. –  TheCleaner Jan 11 '13 at 17:29

3 Answers 3

up vote 1 down vote accepted
+50

The solution is to set up SMTP namespace sharing between the two Exchange servers.

share|improve this answer

I would usually use the targetAddress on the user object via adiedit to forward email during migrations, but that doesn't take care of calender sync.

How about a transport rule ?

I've also used Quest Migration Manager for Exchange for syncing free/busy information between Exchange orgs.

share|improve this answer
    
We've got calendar syncing working fine between the orgs using federation. The issue is in bold at this point. –  TheCleaner Jan 9 '13 at 14:17
    
I thought that federation provided free-busy lookup, not sync between calendars. To forward an email address between orgs without using a mailbox or a contact, you could use a mail enabled public folder... –  shouldbeq931 Jan 11 '13 at 22:44
    
nice idea on the public folder - might help someone else. Maybe I confused you, we weren't looking to actually sync bob's 2 forest calendars. When I said sync I meant free/busy and cross-forest delegation works fine. The root issue was with Exchange not taking email only for someone. But the public folder idea is a good one, and if it weren't for smtp namespace sharing I would have used your idea. +1 –  TheCleaner Jan 11 '13 at 23:04

Since Bob is actually part of a different Exchange forest, Sally can't see Bob's free/busy information at all in the other Exchange org (and vice versa). If I am reading what you did correctly, you essentially created an external contact for Bob for his new Exchange org(Bob@awesome.com) and hid his existing mailbox (Bob@domain.com) from the GAL (which does not hide free/busy info on his mailbox). Then you set the forwarding address on his Bob@domain.com mailbox to forward to Bob@awesome.com.

When Sally goes to set up a meeting with Bob, she resolves his Bob@domain.com account and it shows that he is free which is true since, according to his @domain.com mailbox, he is.

There are several different ways you can try to resolve this, but nothing really cut and dry. One of these methods may work for you based on your requirements:

  1. Tell Sally that Bob doesn't live in the domain.com domain anymore, and she can't see his free/busy info to reliably schedule meetings with him. She can continue to send meeting requests to his domain.com account, but has to accept that she can't see if he is actually busy or not. This is fine if Sally and Bob are the only users involved with this problem, but doesn't work if you have 1/2 your users split between Exchange orgs and the domain.com users aren't sure which are in the awesome.com org.

  2. Remove Bob's free/busy permissions on his domain.com mailbox so when Sally (or any other domain.com user) tries to schedule him, he shows up with no free/busy info and Sally can't claim that he appeared to be free on her end. From what I've gathered, you would do this either using the Set-MailboxPermissions cmdlet or by opening up Bob's domain.com mailbox directly in Outlook and setting the calendar permissions for "Default" to None.

  3. Remove Bob's domain.com mailbox and only leave the external contact for Bob@awesome.com in the GAL. This will break the e-mail forwarding for bob@domain.com > bob@awesome.com, which may be an issue for Bob, but people will soon realize that he doesn't live at domain.com anymore when they get NDRs and ask questions, figure out his new address when they call him up and ask him about it, etc... If Bob no longer even needs to login to the domain.com domain you can remove his entire AD account.

  4. If you have access to both Exchange orgs (domain.com & awesome.com), you can set them up to share Free/Busy information between them. I personally have never done this, but doing some quick googling found this technet article from MS on setting it up at a high level with links to the more detailed steps. Like many technet articles, there may be more caveats to it than what the article itself covers.

At my company, we have users in 2 different locations that primarily use one or the other Exchange org for e-mail, but we do not have a unified calendar scheduling capability since we don't control the other Exchange org. We just forward messages to the other org if the user says they are primarily using that one for e-mail or don't forward if they primarily use ours. Over time our users have just gotten to remember to use our domain's e-mail or the external contact for sending mail ("Let's see... that person is at the other location so I don't e-mail their domain.com account, I use the external contact..."). It isn't easy to manage, but either somehow seems to work for them or they have just accepted the fact that they can't see the other org's scheduling info for meetings.

Update for the OR even better scenario (disclaimer - untested):

  1. Remove Bob@domain.com's mailbox and create a contact with the same e-mail address.
  2. Configure a transport rule to redirect messages sent to Bob's domain.com contact to the bob@awesome.com contact.
share|improve this answer
    
Sorry August...that's a lot of typing you had to do just to find out that we have cross-forest federation in place with a GAL sync. Calendar free/busy isn't really the heart of the issue. It's having an email address in domain.com forward to awesome.com without keeping all the other things like calendar/contacts on the old domain mailbox. –  TheCleaner Jan 7 '13 at 19:31
    
Additional for you: Bob has a mailbox in both domains. He only checks one of them though, his awesome.com one. Sally is in the old domain and is used to typing bob@domain.com in when booking him. Again though, calendar issues aside, really just looking to accomplish the bolded parts at this point. –  TheCleaner Jan 7 '13 at 19:33
    
@TheCleaner - no problem. It's good for me to think through different scenarios anyway that I may not encounter to try and come up with a solution. Who knows? Maybe all that typing will help someone else... –  August Jan 7 '13 at 19:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.