1

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 [email protected] had a mailbox on Exchange 2010 server.

Bob now has a new mailbox on a different Exchange forest ([email protected]).

Bob wants his old email forwarded for [email protected] to [email protected].

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 [email protected] who used the Scheduling assistant and typed in "[email protected]" 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 [email protected] and he accepts, it shows up on his awesome.com calendar as it should. But Sally sees the request still sent to [email protected] in the scheduling assistant as he is free but [email protected] 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 [email protected] 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 [email protected] on Exchange without having a mailbox for him and then re-route it to [email protected]?

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!

5
  • 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, 2013 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, 2013 at 19:28
  • In that case I think SMTP namespace sharing will do the trick.
    – joeqwerty
    Jan 7, 2013 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, 2013 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, 2013 at 17:29

3 Answers 3

1
+50

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

1

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.

3
  • We've got calendar syncing working fine between the orgs using federation. The issue is in bold at this point.
    – TheCleaner
    Jan 9, 2013 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... Jan 11, 2013 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, 2013 at 23:04
0

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([email protected]) and hid his existing mailbox ([email protected]) from the GAL (which does not hide free/busy info on his mailbox). Then you set the forwarding address on his [email protected] mailbox to forward to [email protected].

When Sally goes to set up a meeting with Bob, she resolves his [email protected] 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 [email protected] in the GAL. This will break the e-mail forwarding for [email protected] > [email protected], 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 [email protected]'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 [email protected] contact.
3
  • 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, 2013 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 [email protected] in when booking him. Again though, calendar issues aside, really just looking to accomplish the bolded parts at this point.
    – TheCleaner
    Jan 7, 2013 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, 2013 at 19:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .