StevenAhmet
asked on
Exchange 2010 OOF and Free Busy authentication from another domain
Hi,
We're in the middle of a messy migration at the moment. We have purchased another company and have brought them onto our premises. We just basically picked up their whole network and brought it on premises, but they are still in their own little bubble so to speak.
So we have 2 separate networks, with 2 separate Windows 2008 Active Directories, with 2 separate Exchange servers etc.
We have slowly been migrating people across into our environment. Domain A is our environment. Domain B is the company we bought.
We have migrated some computer accounts and domain accounts across to Domain A, whilst leaving their Exchange mailbox in Domain B.
We have also migrated some mailboxes across to Domain A whilst leaving their computer and domain and computer accounts in Domain B.
We weren't going to do a full Federated Trust thing with Cross Forest Migration. We are just exporting their PST from their Exchange 2010 server on Domain B, and importing it into their Domain A mailbox account.
So, the user is logged into a computer that is a member of Domain B, with an AD account that is a member of Domain B. When we configure their Outlook for the Domain A Exchange Server, it prompts for Domain A credentials, and they are good to go. (We have configured them with accounts in both domains).
I've just noticed though that Out of Office is not working, and neither is the Free Busy information.
For people that are logging into their computer using Domain A AD accounts and Domain A Exchange mailboxes, everything works properly. But for people that are logged in as Domain B accounts, this doesn't work.
I've done the Autodiscovery test within Outlook, and I notice that the first thing it does is look for autodiscovery information for Domain B, but then moves onto Domain A and it is successful.
I know this is a messy scenario, but it is necessary for a short period of time until we can sort some things out.
I'm just wondering if it's some sort of permissions thing in IIS for Exchange Web Services, or it's just the fact that this won't work because their AD account is still in Domain B.
I've also tried the registry hack to prefer a local XML file, and used the Autodiscover details for Domain A, but that doesn't work either.
Anyone got any ideas?
Thanks.
Steve
We're in the middle of a messy migration at the moment. We have purchased another company and have brought them onto our premises. We just basically picked up their whole network and brought it on premises, but they are still in their own little bubble so to speak.
So we have 2 separate networks, with 2 separate Windows 2008 Active Directories, with 2 separate Exchange servers etc.
We have slowly been migrating people across into our environment. Domain A is our environment. Domain B is the company we bought.
We have migrated some computer accounts and domain accounts across to Domain A, whilst leaving their Exchange mailbox in Domain B.
We have also migrated some mailboxes across to Domain A whilst leaving their computer and domain and computer accounts in Domain B.
We weren't going to do a full Federated Trust thing with Cross Forest Migration. We are just exporting their PST from their Exchange 2010 server on Domain B, and importing it into their Domain A mailbox account.
So, the user is logged into a computer that is a member of Domain B, with an AD account that is a member of Domain B. When we configure their Outlook for the Domain A Exchange Server, it prompts for Domain A credentials, and they are good to go. (We have configured them with accounts in both domains).
I've just noticed though that Out of Office is not working, and neither is the Free Busy information.
For people that are logging into their computer using Domain A AD accounts and Domain A Exchange mailboxes, everything works properly. But for people that are logged in as Domain B accounts, this doesn't work.
I've done the Autodiscovery test within Outlook, and I notice that the first thing it does is look for autodiscovery information for Domain B, but then moves onto Domain A and it is successful.
I know this is a messy scenario, but it is necessary for a short period of time until we can sort some things out.
I'm just wondering if it's some sort of permissions thing in IIS for Exchange Web Services, or it's just the fact that this won't work because their AD account is still in Domain B.
I've also tried the registry hack to prefer a local XML file, and used the Autodiscover details for Domain A, but that doesn't work either.
Anyone got any ideas?
Thanks.
Steve
ASKER
Using EMC, "new-mailboxexport request" on Domain B mail server, and "new-mailboximportrequest"
One more thing - how exactly you retargeted MS Outlook 2010 on computers of the migrated users? Did you delete the whole profile, of just changed server?
The setting may be cached in the profile.
Try deleting all profile configuration, then creating anew.
The setting may be cached in the profile.
Try deleting all profile configuration, then creating anew.
ASKER
I created a new profile. I'm just having a look at that link you posted now.
ASKER
This looks like it will only work if the domains are federated. Is that true?
You should not need to create a trust between domains at this stage.
Have you created new users in the same manner as "normal" residents of Domain A?
Have you checked the Outlook error log?
http://www.technipages.com/outlook-2010-2007-enable-disable-logging
Have you checked email addresses of migrated users same as residents?
Have you created new users in the same manner as "normal" residents of Domain A?
Have you checked the Outlook error log?
http://www.technipages.com/outlook-2010-2007-enable-disable-logging
Have you checked email addresses of migrated users same as residents?
ASKER
Yes, new users are created in the exact same way.
After enabling Outlook logging, I can see when I try to access Out of Office, I'm getting a HTTP 500 error.
The response says "Unable to access an account or mailbox".
I looked at this;
http://support.microsoft.com/kb/2596516
The hotfix was already installed. I added the Registry entry. I had to create the "Security" key folder, then the WinhttpAuth DWORD, but still no go.
I'm still getting the same error in logging.
After enabling Outlook logging, I can see when I try to access Out of Office, I'm getting a HTTP 500 error.
The response says "Unable to access an account or mailbox".
I looked at this;
http://support.microsoft.com/kb/2596516
The hotfix was already installed. I added the Registry entry. I had to create the "Security" key folder, then the WinhttpAuth DWORD, but still no go.
I'm still getting the same error in logging.
ASKER
Just wanted to make sure I add that;
1) Everything works correctly using OWA, (for all users). I can see Free/Busy info for all users and set OOF correctly.
2) Out of Office/Free Busy works correctly for all users logging into the Domain A domain.
I thought for sure that MS article was going to be the ticket as it describes the situation perfectly......"You open a mailbox profile in Microsoft Outlook 2010 by using credentials that are different to the credentials that you used to log on to Windows."
But still no go. Any further help would be appreciated.
Steve
1) Everything works correctly using OWA, (for all users). I can see Free/Busy info for all users and set OOF correctly.
2) Out of Office/Free Busy works correctly for all users logging into the Domain A domain.
I thought for sure that MS article was going to be the ticket as it describes the situation perfectly......"You open a mailbox profile in Microsoft Outlook 2010 by using credentials that are different to the credentials that you used to log on to Windows."
But still no go. Any further help would be appreciated.
Steve
If you are using an internet proxy AND it is able to reach your CAS role, try removing CAS from proxy exception list.
Try Outlook 2013. Do you have latest patched on Office And Exchange?
Try Outlook 2013. Do you have latest patched on Office And Exchange?
ASKER
No internet proxy.
Office 2010 and Exchange are patched.
We don't have Outlook 2013 anywhere in the organisation so can't try it.
Office 2010 and Exchange are patched.
We don't have Outlook 2013 anywhere in the organisation so can't try it.
ASKER
**Update: I've done another test;
1) Removed the computer from Domain B so it is just in a workgroup. Not added into any domain.
2) Logged in as a local administrator of the computer.
3) Configured Outlook to use the same Domain A mailbox I've been testing with.
Out of Office and Free/Busy both work. Not sure where to go from here now.
1) Removed the computer from Domain B so it is just in a workgroup. Not added into any domain.
2) Logged in as a local administrator of the computer.
3) Configured Outlook to use the same Domain A mailbox I've been testing with.
Out of Office and Free/Busy both work. Not sure where to go from here now.
ASKER
OK, so I added the computer back to Domain B.
Logged in as the Domain B user.
Opened up Outlook again that is configured with the Domain A mailbox.
And now it works!!
I just have to try it now with some user's actual computers.
Logged in as the Domain B user.
Opened up Outlook again that is configured with the Domain A mailbox.
And now it works!!
I just have to try it now with some user's actual computers.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I do not think this was firewall-related.
This is definitely credentials you mentioned.
Outlook+Exchange uses complex combination of protocols to different destinations, and all works great once you are in a trusted domain.
Once you are out of trusted domain, you rely sorely on user's stored or entered credentials for auth to each proto/destination pair.
BUT
not all protocols are able to detect account conditions like : password expiry, password incorrect, account locked etc.
Not all code in Outlook is able to process error codes correctly and raise appropriate GUI warnings/dialogs. Obviously this is the case in OoO and Free/Busy info.
What you found is a good solution, but you should also test what happens if user's password is expired and needs to be changed in Domain A while they are working on PCs in Domain B. Or the incorrect logins leading to account lockouts.
I have had a similar case where domain-based DFS namespace was redirecting non-domain computer/users to different individual servers but users had no stored credentials for those.
The MS DFS code was not handling redirects to file shares in the same user context as for the original DFS namespaces. I had to get rid of DFS and use a simple single file share. Joining domain was not an option since many devices were BYO and had non-Pro Windows 7/8 versions installed.
IMO you ought to focus efforts on completing the migration, at the same time let Domain B users know of possible issues and workarounds.
This is definitely credentials you mentioned.
Outlook+Exchange uses complex combination of protocols to different destinations, and all works great once you are in a trusted domain.
Once you are out of trusted domain, you rely sorely on user's stored or entered credentials for auth to each proto/destination pair.
BUT
not all protocols are able to detect account conditions like : password expiry, password incorrect, account locked etc.
Not all code in Outlook is able to process error codes correctly and raise appropriate GUI warnings/dialogs. Obviously this is the case in OoO and Free/Busy info.
What you found is a good solution, but you should also test what happens if user's password is expired and needs to be changed in Domain A while they are working on PCs in Domain B. Or the incorrect logins leading to account lockouts.
I have had a similar case where domain-based DFS namespace was redirecting non-domain computer/users to different individual servers but users had no stored credentials for those.
The MS DFS code was not handling redirects to file shares in the same user context as for the original DFS namespaces. I had to get rid of DFS and use a simple single file share. Joining domain was not an option since many devices were BYO and had non-Pro Windows 7/8 versions installed.
IMO you ought to focus efforts on completing the migration, at the same time let Domain B users know of possible issues and workarounds.
ASKER
None of the answers provided by the one other expert were helpful in the solution.
I got to the solution on my own.
I got to the solution on my own.
This has nothing to do with Autodiscover, BTW.