SCP bypass for Outlook 2010 (Office 365 staged migration)

Posted on 2014-08-05
Last Modified: 2014-08-11
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 ?
Question by:Ninja2k4

    Author Comment

    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.
    LVL 38

    Expert Comment

    by:Vasil Michev (MVP)
    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?

    Author Comment

    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.
    LVL 38

    Expert Comment

    by:Vasil Michev (MVP)
    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.

    Accepted Solution

    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 :)

    Author Closing Comment

    Self fix.

    Featured Post

    What Security Threats Are You Missing?

    Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

    Join & Write a Comment

    Learn more about how the humble email signature can be used as more than just an electronic business card. When used correctly, a signature can easily be tailored for different purposes by different departments within an organization.
    We are happy to announce a brand new addition to our line of acclaimed email signature management products – CodeTwo Email Signatures for Office 365.
    To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
    To add imagery to an HTML email signature, you have two options available to you. You can either add a logo/image by embedding it directly into the signature or hosting it externally and linking to it. The vast majority of email clients display l…

    745 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now