SCP bypass for Outlook 2010 (Office 365 staged migration)

Hi, currently performing a staged migration in which we have Exchange 2010 and are running a 10 user test pilot. Office 365 is all working fine, I can login to webmail and send and receive email fine (we are using target address redirection). I can set the client up manually on outlook 2010 and again it also works fine.

The issue is I can't seem to bypass the SCP so that it automatically sets the clients up. I've tried the registry entry's to try bypass this but it doesn't work. If I go into ADSI.edit and remove the SCP from there, then it sets the client up fine, but unfortunately I can't remove this for good. Autodiscover cname is pointing to

Anyone got any other ideas at all ?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Ninja2k4Author Commented:
Weird thing I have noticed though, If I re-direct IIS autodiscover directory to - then it sets the account up, but an on site account then takes ages to configure itself.
Vasil Michev (MVP)Commented:
The CNAME needs to point to your on-prem endpoint when in hybrid. But that shouldnt be the issue here, if I remember correctly your problem was that it didnt return the redirect.

Regardless of which method the client is getting the xml with (even the SCP), the server *should* return the redirect. In your case, it looked like you were getting the xml for a normal mailbox, not MEU. Can you test it with a 'normal' mail-enabled user, not something that was moved to EO?
Ninja2k4Author Commented:
Not doing a hybrid migration, doing a staged one.

With a normal user, it just picks up the SCP and first point of autodiscovery and that is it.

If I remove the SCP, then the redirect gets picked up,  but then setting up an internal on site mailbox takes forever. Unfortunately this is a customer we have taken over and it's a bit of a mess.

Just making sure their autodiscovery is correct as they were using a self signed cert which has now been changed for a 3rd party one.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Vasil Michev (MVP)Commented:
OK, so you have the SCP pointing to on-prem, and you have the CNAME pointing to EO? The only logical explanation I can think of is that the mailbox on-prem still exists (i.e. NOT converted to MEU as described in Step 6 here: In this case, on a domain joined machine it will always return the local autodiscover WITHOUT the redirect. Outside of the network (or if you disable SCP so it progresses until the CNAME lookup) it will return the EO autodiscover info, which is what you want (but there will be no redirect).

Are you actually seeing the REDIRECT in the response, or you simply mean that it gives you the info from the correct server (EO)? It doesnt make sense to not see the redirect when using the SCP but see it with the CNAME, if anything it should be the other way around. Here's what the redirect should look like:


Open in new window

Btw if you have mailboxes both in the cloud and on-prem using the same namespace, autodiscover needs to point to the on-prem server. Converting the mailboxes to MEU and having their targetaddress populated correctly will make sure they get the correct autodiscover info.
Ninja2k4Author Commented:
Hi, I reconfigured autodiscover from scratch as there was definitely a problem with this as users were getting authentication prompts when setting up internal accounts. Since doing that, all is working fine.

I still have to use the registry entry ExcludeScpLookup=1, but this bypasses the SCP then the redirect URL works.

The process for the staged migration I did was:

1)       Configure Office 365
2)       Configure vanity domain
3)       Installed DirSync on prem, and the User object flow was modified to remove the MSExchRecipientDisplayType and MSExchMailboxGuid attributes. This prevents Office 365 from detecting that users in the cloud have mailboxes onprem, and treats them like normal users.
4)       Users have been sync’d from on prem AD.
5)       The CM365 XML config was created and tested,
6)       Mailbox enabled every user in the cloud that has a mailbox on prem
7)       Mail flow is in place between on premises and office 365
8)       Test pilot users data has been migrated to the Office 365 mailboxes
9)       Domain Redirection working with SCP reg excluded

So yeah, all working. I really do appreciate you taking the time to respond though :)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ninja2k4Author Commented:
Self fix.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.