Mixed Office365 and Exchange enviornment?



  • Where I work we like to slowly ease into things, I was wondering if it is possible to keep our exchange 2010 environment up and running while having around 10 users on Office 365 hosted exchange?



  • I know that we have done hybrid setups so that the migration can happen slowly. I will ping one of my team as I have never done a hybrid migration. @alexntg can you provide some guidance here?



  • @Minion-Queen said:

    I know that we have done hybrid setups so that the migration can happen slowly. I will ping one of my team as I have never done a hybrid migration. @alexntg can you provide some guidance here?

    Certainly! If you need to have some users onsite and some hosted, you can use a hosted deployment. How many users are you looking at in total?



  • @alexntg said:

    @Minion-Queen said:

    I know that we have done hybrid setups so that the migration can happen slowly. I will ping one of my team as I have never done a hybrid migration. @alexntg can you provide some guidance here?

    Certainly! If you need to have some users onsite and some hosted, you can use a hosted deployment. How many users are you looking at in total?

    The idea is to start with about 15 people on the hosted exchange with office365 and then through time slowly move people over from our current exchange to the hosted.



  • I replied on SW as well. I recommend heavily against going hybrid for this reason. Hybrid is not designed for a transition state. It is designed for a permanent state. Binding you internal AD to Azure is non-trivial and is a decision that you will be stuck with for a long time.

    Going this route will also send costs through the roof. This isn't an "easing" or a conservative process. There is so much more work and danger in doing this that jumping directly into Office 365 could be described as "easing" towards hybrid.

    If the goal is to be safe and make things easier, this does the opposite.



  • We have a total of about 220 current exchange users.



  • @scottalanmiller said:

    I replied on SW as well. I recommend heavily against going hybrid for this reason. Hybrid is not designed for a transition state. It is designed for a permanent state. Binding you internal AD to Azure is non-trivial and is a decision that you will be stuck with for a long time.

    Going this route will also send costs through the roof. This isn't an "easing" or a conservative process. There is so much more work and danger in doing this that jumping directly into Office 365 could be described as "easing" towards hybrid.

    If the goal is to be safe and make things easier, this does the opposite.

    I had a funny feeling that this wouldn't be recommended . Thanks for you help everyone!



  • It's a good theory 🙂 and if it didn't require the AD bonding commitment I would be all for it. But that just makes the overhead and risk too much.

    With a normal migration you can just "fall back", nice and safe. Your old environment can remain intact. With hybrid, you give up that protection and add a lot of extra management to run two systems.

    Best bet is a single, big and painful weekend migration and be done all at once.



  • @scottalanmiller said:

    I replied on SW as well. I recommend heavily against going hybrid for this reason. Hybrid is not designed for a transition state. It is designed for a permanent state. Binding you internal AD to Azure is non-trivial and is a decision that you will be stuck with for a long time.

    Going this route will also send costs through the roof. This isn't an "easing" or a conservative process. There is so much more work and danger in doing this that jumping directly into Office 365 could be described as "easing" towards hybrid.

    If the goal is to be safe and make things easier, this does the opposite.

    Hybrid deployments no longer require ADFS, so the risk of ADFS is now mitigated. However, one still needs to keep an onsite Exchange server around afterwards for management.



  • @lance said:

    We have a total of about 220 current exchange users.

    With an environment of that size, a cutover migration would work best. If you have Outlook Anywhere deployed, the cutover migration tool that MS provides works well. You can, however, do an O365 trial for users to get a feel for it and see if it'll be a good fit. That includes up to 25 users.
    *Edited for spelling and grammar



  • @alexntg said:

    @lance said:

    We have a total of about 220 current exchange users.

    With en environment of that size, a cutover migration would work best. If you have Outlook Anywhere deployed, the cutover migration tool that MS provides works well. You can, however, do an O365 trial for users to get a feel for it and see if it'll be a good fit. That includes up to 25 users.

    Sounds good, I will have to keep looking into this. You mentioned you have to keep a onsite Exchange server around, is there a point where we would be able to get rid of it or will we always have to have one.



  • @lance said:

    @alexntg said:

    @lance said:

    We have a total of about 220 current exchange users.

    With en environment of that size, a cutover migration would work best. If you have Outlook Anywhere deployed, the cutover migration tool that MS provides works well. You can, however, do an O365 trial for users to get a feel for it and see if it'll be a good fit. That includes up to 25 users.

    Sounds good, I will have to keep looking into this. You mentioned you have to keep a onsite Exchange server around, is there a point where we would be able to get rid of it or will we always have to have one.

    You'd have to keep it around as long as you have hybrid mailboxes, so pretty much forever. You can still use DirSync to synchronize your users and passwords while keeping the hosted management aspect of it.



  • What's so bad about ADFS?



  • @Dashrender said:

    What's so bad about ADFS?

    Risk and complexity. You are tied to Azure. You lose a lot of flexibility. Even Microsoft recommends it only when necessary.



  • @Dashrender As Scott says its risk and complexity. If your connection to ADFS goes (ISP failure, maintenance works etc) your users lose connectivity to 365 services. To have failover you are relying on low TTL DNS change/propagation or an expensive failover DNS solution.

    Plus the cost of Windows licensing for proxy and ADFS devices, resources on the VM host or physical hardware. Then the cost of the same at your failover site

    Removing it was one of my happier days...



  • All that makes me wonder if/when we can have AD in the cloud, either fully or hybrid, and be safe.



  • @Dashrender said:

    All that makes me wonder if/when we can have AD in the cloud, either fully or hybrid, and be safe.

    That's been available for a while. But the federation limitations remain. There is both traditional AD in the cloud (NTG runs that way) and Azure's cloud AD service. It is that cloud service that is being discussed binding to.



  • @Dashrender said:

    What's so bad about ADFS?

    When you enable ADFS, Office 365 passes authentication requests to your infrastructure. It isn't a sync or cache. If your infrastructure is down, your clients can't authenticate. Sure, you can set up a multi-site cluster for ADFS to mitigate that issue, but the effort doesn't match the reward in most cases. Using DirSync, you can sync users and passwords from your AD environment with 365, so that users can login with the same username and password, though it isn't true SSO.



  • @scottalanmiller said:

    @Dashrender said:

    All that makes me wonder if/when we can have AD in the cloud, either fully or hybrid, and be safe.

    That's been available for a while. But the federation limitations remain. There is both traditional AD in the cloud (NTG runs that way) and Azure's cloud AD service. It is that cloud service that is being discussed binding to.

    What about doing something crazy like setting up an RODC in Azure or AWS, and put ADFS on that? or skip ADFS altogether and use something like Pertino for logons.

    the purchase of my question is more: What is a good way to have a distributed AD authentication scheme for a spread out network of mobile users? or if not mobile, in a setup where you don't want to pay for an onsite server (though if you're small enough, an on site small HP would be much cheaper in the long run, of course, not as protected as one in the Azure or AWS network)



  • @Dashrender said:

    @scottalanmiller said:

    @Dashrender said:

    All that makes me wonder if/when we can have AD in the cloud, either fully or hybrid, and be safe.

    That's been available for a while. But the federation limitations remain. There is both traditional AD in the cloud (NTG runs that way) and Azure's cloud AD service. It is that cloud service that is being discussed binding to.

    What about doing something crazy like setting up an RODC in Azure or AWS, and put ADFS on that? or skip ADFS altogether and use something like Pertino for logons.

    the purchase of my question is more: What is a good way to have a distributed AD authentication scheme for a spread out network of mobile users? or if not mobile, in a setup where you don't want to pay for an onsite server (though if you're small enough, an on site small HP would be much cheaper in the long run, of course, not as protected as one in the Azure or AWS network)

    Pertino can't help you extend to Office 365, not can a hosted AD somewhere. None of those solutions do anything but deploy more of what you already have. Office 365 needs a federated Azure instance and none of those address that, they are all just normal, every day AD.



  • @Dashrender said:

    the purchase of my question is more: What is a good way to have a distributed AD authentication scheme for a spread out network of mobile users?

    For that, unrelated to Office 365, we use Pertino and it works pretty well and gets better all of the time.



  • With all that in mind, would it better the just not worry about the logon syncing between your inhouse AD and O365, treat them as two separate things with two different logons?



  • @Dashrender said:

    With all that in mind, would it better the just not worry about the logon syncing between your inhouse AD and O365, treat them as two separate things with two different logons?

    No, just use DirSync instead of ADFS. All of the benefits, none of the risk.



  • @Dashrender said:

    @scottalanmiller said:

    @Dashrender said:

    All that makes me wonder if/when we can have AD in the cloud, either fully or hybrid, and be safe.

    That's been available for a while. But the federation limitations remain. There is both traditional AD in the cloud (NTG runs that way) and Azure's cloud AD service. It is that cloud service that is being discussed binding to.

    What about doing something crazy like setting up an RODC in Azure or AWS, and put ADFS on that? or skip ADFS altogether and use something like Pertino for logons.

    If you're considering this from a DR perspective, a regular DC in a hosted environment would make sense. That way, if your on-premise infrastructure is unavailable, you can carry on as usual. I use AWS for my geographically distributed AD in my test lab, I have a DC on each side of the country.

    the purchase of my question is more: What is a good way to have a distributed AD authentication scheme for a spread out network of mobile users? or if not mobile, in a setup where you don't want to pay for an onsite server (though if you're small enough, an on site small HP would be much cheaper in the long run, of course, not as protected as one in the Azure or AWS network)

    What are you currently using for VPN?

    Azure AD at this point isn't the full AD that you're familiar with. It's a platform to connect applications to. If you want to use Azure and use it for full AD, you'll need to spin up a Windows Server instance on Azure and set it up as a DC.


Log in to reply