SBS2011 Exchange Migration to Office365
Looking to migrate SBS2011 to Office365.
Just email to start with, I will need to keep the server for a couple months, until I can complete the data migration to OneDrive and SharePoint.
I am attracted to the Hybrid/Remote Move method, as I will not need to touch any end user OUtlook configuration, which surely is of huge benefit to anyone doing these migrations?
It is surprising then, that the documentation to achieve this is so lacking, and in a lot of cases conflicting.
My understanding is that Hybrid Migration is possible with Exchange 2010 (and therefore, SBS2011?)
Why is this not the primary migration method then, if it does better than 3rd party paid services, in terms of end user automation etc?
Anyone able to help me with some specifics on how to achieve this, please? The docs I have found, entail setting up a separate 2013 Exchange server, which as far as I can tell, should not be necessary?
Many thanks in advance
Just email to start with, I will need to keep the server for a couple months, until I can complete the data migration to OneDrive and SharePoint.
I am attracted to the Hybrid/Remote Move method, as I will not need to touch any end user OUtlook configuration, which surely is of huge benefit to anyone doing these migrations?
It is surprising then, that the documentation to achieve this is so lacking, and in a lot of cases conflicting.
My understanding is that Hybrid Migration is possible with Exchange 2010 (and therefore, SBS2011?)
Why is this not the primary migration method then, if it does better than 3rd party paid services, in terms of end user automation etc?
Anyone able to help me with some specifics on how to achieve this, please? The docs I have found, entail setting up a separate 2013 Exchange server, which as far as I can tell, should not be necessary?
Many thanks in advance
If you want to do a hybrid migration from SBS 2011, I would suggest moving to a DC and an Exchange Server (running Exchange 2013), decomissioning SBS, and then running the hybrid migration.
Other options fopr email migration
Cutover migration.
3rd party Migration tools
it depends on how many users you have, and how much bandwidth you have. A cutover migration means each user needs to have a new Outlook profile with a new offline cache, and downloading the initial offline cache can be an issue.
3rd part Migration tools allow one to create the O365 mailboxes and migrate the contents for each user, and changeover each user as convenient, some have tools to manipulate profiles, most still require downloading a new .ost, downside is these tools are not free.
There has always been "fun" when migrating SBS, hence my suggestion to migrate to a normal DC and Exchange before migrating.
Other options fopr email migration
Cutover migration.
3rd party Migration tools
it depends on how many users you have, and how much bandwidth you have. A cutover migration means each user needs to have a new Outlook profile with a new offline cache, and downloading the initial offline cache can be an issue.
3rd part Migration tools allow one to create the O365 mailboxes and migrate the contents for each user, and changeover each user as convenient, some have tools to manipulate profiles, most still require downloading a new .ost, downside is these tools are not free.
There has always been "fun" when migrating SBS, hence my suggestion to migrate to a normal DC and Exchange before migrating.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I am not suggesting the recommendations won't work but there is a huge caveat - SBS is not like a typical infrastructure - it is designed to work as a standalone system and is wizard driven.
It is very particular with regards to licensing - adding a second domain controller, for example, used to be fine, but you couldn't move any FSMO roles - that would breach the licensing and effectively cause the shut down of SBS.
SBS has a load of specific add-ons you wouldn't find in a typical environment and as such, directing the OP to generalised, generic, guides to just Exchange/AD etc aren't necessarily the most trustworthy sources.
Liekwise, with Arne's suggestion - that seems like the logical approach, but it will, in all likelihood, break SBS effectively during the migration and his suggestion to decommission SBS is the most likely to succeed, but per my original comment, SBS has many other tools built in (a version or RDWeb/RDS for example). It's a funny little beast.
It is very particular with regards to licensing - adding a second domain controller, for example, used to be fine, but you couldn't move any FSMO roles - that would breach the licensing and effectively cause the shut down of SBS.
SBS has a load of specific add-ons you wouldn't find in a typical environment and as such, directing the OP to generalised, generic, guides to just Exchange/AD etc aren't necessarily the most trustworthy sources.
Liekwise, with Arne's suggestion - that seems like the logical approach, but it will, in all likelihood, break SBS effectively during the migration and his suggestion to decommission SBS is the most likely to succeed, but per my original comment, SBS has many other tools built in (a version or RDWeb/RDS for example). It's a funny little beast.
The limits of SBS2011 should not impact hybrid setup. You can definitely add another DC as long as you don't move roles. Moreover, SBS offers a migration mode which is used to migrate to other SBS or to normal AD.
That said, apart from the wizards that are used to configure SBS, the Exchange 2010 part of the setup is pretty standard so you can setup an hybrid or use cutover.
That said, apart from the wizards that are used to configure SBS, the Exchange 2010 part of the setup is pretty standard so you can setup an hybrid or use cutover.
The limits of SBS2011 should not impact hybrid setup
Can you provide a citation from Microsoft for that statement?
Disclaimer: I am not affiliated with SkyKick and receive no benefit from this post. I am strictly recommending them based on my personal experience with the product.
Personally, I did a decent sized migration (non-SBS), used SkyKick and cannot imagine doing it without. If you look at https://www.skykick.com/migrate/migrate-exchange-to-office-365/, they support SBS and their tools (even 3+ years ago) were amazing. I know there is a cost but their assistance was invaluable. I would at least give them a call. If there are as supportive of SBS as they were with the migration I did, I would definitely go with their migration offering.
Personally, I did a decent sized migration (non-SBS), used SkyKick and cannot imagine doing it without. If you look at https://www.skykick.com/migrate/migrate-exchange-to-office-365/, they support SBS and their tools (even 3+ years ago) were amazing. I know there is a cost but their assistance was invaluable. I would at least give them a call. If there are as supportive of SBS as they were with the migration I did, I would definitely go with their migration offering.
@Tony Johncock
That is not the correct approach. For instance, you say that an hybrid cannot be implemented on SBS 2011?
Can you provide a citation from Microsoft for your statement?
No, you cannot because we are not talking about plugs that are compatible or not, we are talking about a products bundle (SBS) which packages different software pieces (AD, Exchange, SQLServer, whatever).
We need to identify the components of a hybrid setup and check the prerequisites of each one. For instance let's check AADConnect prerequisites, required for an hybrid setup:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisite
AADConnect cannot be installed on a SBS DC. But can be installed on a member server so this prerequisite is satisfied.
Then check if Exchange 2010, which is packaged in SBS 2011, does support ah hybrid setup. It turns out it does, given the correc updates are applied (see here: https://docs.microsoft.com/en-us/exchange/exchange-hybrid)
This approach is implicitly confirmed by Microsoft approach regarding support lifecycle of SBS package.
Can you provide a citation from Microsoft for that statement?
That is not the correct approach. For instance, you say that an hybrid cannot be implemented on SBS 2011?
Can you provide a citation from Microsoft for your statement?
No, you cannot because we are not talking about plugs that are compatible or not, we are talking about a products bundle (SBS) which packages different software pieces (AD, Exchange, SQLServer, whatever).
We need to identify the components of a hybrid setup and check the prerequisites of each one. For instance let's check AADConnect prerequisites, required for an hybrid setup:
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisite
AADConnect cannot be installed on a SBS DC. But can be installed on a member server so this prerequisite is satisfied.
Then check if Exchange 2010, which is packaged in SBS 2011, does support ah hybrid setup. It turns out it does, given the correc updates are applied (see here: https://docs.microsoft.com/en-us/exchange/exchange-hybrid)
This approach is implicitly confirmed by Microsoft approach regarding support lifecycle of SBS package.
The support date for this product package is determined by its individual component product’s respective lifecycles.from https://support.microsoft.com/en-us/lifecycle/search/1167
[That is not the correct approach. For instance, you say that an hybrid cannot be implemented on SBS 2011?
Can you provide a citation from Microsoft for your statement?]
I don't believe I actually said the word "cannot?" I have tried to qualify all of my answers with stating that there are no specific, simple, answers that I can find.
You're taking the support statement out of context - SBS is not a normal implementation and that support statement is designed to refer to e.g. patches and SP's from Microsoft.
SBS is not just server and exchange bolted together - there are many nuances and if you don't specialise in it, non-SBS specific information is potentially dangerous to the implementation and you're guilty of treating SBS's implementation of Exchange as a standalone implementation.
ASKER
Thanks for all of your input.
Unfortunately this thread is a replica on the confusion of this topic on the wider internet!
To answer some questions - I don't think the number of users really should come into the decision on this. For the record, it is a fairly low figure of 30 - but they are lawyers with a very small appetite for any disruption and downtime.
As far as I am aware - a hybrid migration allows for an Office365 migration, with next to no user disruption, bar having to restart outlook. Isn't that what we all want, never-mind how many users there are? Most are IT professionals I assume, aren't we looking to be more efficient with our projects?
I am aware of 3rd party tools out there - and I am familiar with SKykick - thanks for the plug - but that tool is really expensive! And (provided the process documentation from MS was sufficient) totally unnecessary, given the simplicity and end user non issue, that Hybrid Remote Move provides...
Ah well, rant over I guess - I will probably have to do a cutover and manually migrate outlook user profiles, wait for OST sync, and migrate the autocomplete. Just frustrating thats all, we should be doing better than this. :)
Unfortunately this thread is a replica on the confusion of this topic on the wider internet!
To answer some questions - I don't think the number of users really should come into the decision on this. For the record, it is a fairly low figure of 30 - but they are lawyers with a very small appetite for any disruption and downtime.
As far as I am aware - a hybrid migration allows for an Office365 migration, with next to no user disruption, bar having to restart outlook. Isn't that what we all want, never-mind how many users there are? Most are IT professionals I assume, aren't we looking to be more efficient with our projects?
I am aware of 3rd party tools out there - and I am familiar with SKykick - thanks for the plug - but that tool is really expensive! And (provided the process documentation from MS was sufficient) totally unnecessary, given the simplicity and end user non issue, that Hybrid Remote Move provides...
Ah well, rant over I guess - I will probably have to do a cutover and manually migrate outlook user profiles, wait for OST sync, and migrate the autocomplete. Just frustrating thats all, we should be doing better than this. :)
ASKER
Also for reference, I have read this link, thank you Michaelangelo for posting it.
"Setting up an hybrid is possible, see here (BTW, one of the best sources I have)
http://www.itpromentor.com/migrate-2010-to-365/"
I see some shortcomings in this though. He mixes up SBS2008 and 2011, providing instructions for:
1. Setting up a separate VM
2. Installing Exchange 2013
3. Creating new SSL certs (UCC is not a requirement in SBS, we only use standard SSL certificates) so this section is not going to work, unless purchasing a separate certificate for this)
and lastly, I find the removal/decommisioning details quite vague.
All of this additional work, it seems is to provide for SBS2008 (ie Exchange 2007) incompatibility with Hybrid Remote Move. SBS2011 is a different platform with a supported version of Exchange, so it really needs its own dedicated, specific process.
Is that too much to ask for, Microsoft? :)
"Setting up an hybrid is possible, see here (BTW, one of the best sources I have)
http://www.itpromentor.com/migrate-2010-to-365/"
I see some shortcomings in this though. He mixes up SBS2008 and 2011, providing instructions for:
1. Setting up a separate VM
2. Installing Exchange 2013
3. Creating new SSL certs (UCC is not a requirement in SBS, we only use standard SSL certificates) so this section is not going to work, unless purchasing a separate certificate for this)
and lastly, I find the removal/decommisioning details quite vague.
All of this additional work, it seems is to provide for SBS2008 (ie Exchange 2007) incompatibility with Hybrid Remote Move. SBS2011 is a different platform with a supported version of Exchange, so it really needs its own dedicated, specific process.
Is that too much to ask for, Microsoft? :)
I must have pasted the wrong link, sorry. The Number of users does come into play mainly because
- it is used by Ms documentation to advise you on what method is best, starting with cutover migration because it's the simplest one and they say it's doable up to 2000 users (but I would plan carefully if going that way with 2k users because sync times may be long)
- it is really a hassle setting up an hybrid just for 30 users, and keep an exchange and an aadconnect doing basically nothing on prem or have to remove.them altogether.
- it is used by Ms documentation to advise you on what method is best, starting with cutover migration because it's the simplest one and they say it's doable up to 2000 users (but I would plan carefully if going that way with 2k users because sync times may be long)
- it is really a hassle setting up an hybrid just for 30 users, and keep an exchange and an aadconnect doing basically nothing on prem or have to remove.them altogether.
@zimboman
From my very first reply, I said I don't believe you can run the version of Exchange 2010 in Hybrid mode on SBS because the Hybrid Exchange tool will attempt to create a trust between Azure AD and your on-premise AD which the AD in SBS won't support.
You cannot install AAD Connect on SBS either, so a directory sync would require a second server to be stood up but even if you were to add an additional DC, since you cannot move the FSMO roles, you're still stuck with not bieng able to install the Hybrid Exchange tool.
It's been a long while since I worked directly with SBS but I've always found it a source of uneasy amusement that IT pro's that have never used it assume it's "just Windows and Exchange" but it's so much more and so much more difficult to migrate from/manage.
I think the URL that Michelangelo may have meant to provide was this one: https://www.itpromentor.com/365-cutover/
I would personally ensure that everything is backed up, fully patched to the latest MS Service Packs and Hotfix levels that are available and then look to use that link to move the mailboxes.
You're still going to be left with the tricksy issues of SharePoint, file shares, AD and if you have them/premium add-ins, SQL etc. Also, do you host your website on SBS? All things to think about.
It shows how to do a cutover migration from on-premise to Hosted Exchange in O365 including with SBS.
From my very first reply, I said I don't believe you can run the version of Exchange 2010 in Hybrid mode on SBS because the Hybrid Exchange tool will attempt to create a trust between Azure AD and your on-premise AD which the AD in SBS won't support.
You cannot install AAD Connect on SBS either, so a directory sync would require a second server to be stood up but even if you were to add an additional DC, since you cannot move the FSMO roles, you're still stuck with not bieng able to install the Hybrid Exchange tool.
It's been a long while since I worked directly with SBS but I've always found it a source of uneasy amusement that IT pro's that have never used it assume it's "just Windows and Exchange" but it's so much more and so much more difficult to migrate from/manage.
I think the URL that Michelangelo may have meant to provide was this one: https://www.itpromentor.com/365-cutover/
I would personally ensure that everything is backed up, fully patched to the latest MS Service Packs and Hotfix levels that are available and then look to use that link to move the mailboxes.
You're still going to be left with the tricksy issues of SharePoint, file shares, AD and if you have them/premium add-ins, SQL etc. Also, do you host your website on SBS? All things to think about.
It shows how to do a cutover migration from on-premise to Hosted Exchange in O365 including with SBS.
It's been a long while since I worked directly with SBS but I've always found it a source of uneasy amusement that IT pro's that have never used it assume it's "just Windows and Exchange" but it's so much more and so much more difficult to migrate from/manage.
I think the URL that Michelangelo may have meant to provide was this one: https://www.itpromentor.com/365-cutover/"
Tony, you started saying that you're not an SBS expert, yet you're just assuming what others think and know and advising OP on what to do. Either you know the subject or you do not. I find it amusing.
For instance
- you do not need a DC to install AADConnect - matter of fact, you should not install it on a DC but on a member server. With SBS you can join a second DC AND you can join a member server on which to install AADConnect.
The hybrid I'm referring to is minimal hybrid. The blog post I was referring to is of course not the one you cited because cutover migration IS NOT hybrid migration
The post is this one
https://www.itpromentor.com/365-express-migration/
And yes, you need an exchange working as a bridge.
I'm not sure why you're taking what I am saying personally or out of context as if my comments were somehow aimed directly at you. They weren't, but never mind, ad hominem away. I apologise that you're taking them personally.
I've been trying to assist the OP to help them avoid being sent down the usual route that occurs because people do not actually understand the complexites of SBS by trying to do something that breaks the functionality of the product.
And I can cite examples you yourself have made such as the MS support statement - taken out of context it can give people a false sense of security that MS mean the products in SBS can be handled as if they were standalone installations, but as I pointed out, that is not the case - it simply means you can use standard MS service packs and hotfixes that are released by MS for the individual components.
Your last links were more useful than any of the previous ones posted including the one I posted that you took such offense to, which was in reply to the OP saying that they believed the link was incorrect - again though, it was intended to assist not as an attack, and I again apologise for your not understanding that.
I've been trying to assist the OP to help them avoid being sent down the usual route that occurs because people do not actually understand the complexites of SBS by trying to do something that breaks the functionality of the product.
And I can cite examples you yourself have made such as the MS support statement - taken out of context it can give people a false sense of security that MS mean the products in SBS can be handled as if they were standalone installations, but as I pointed out, that is not the case - it simply means you can use standard MS service packs and hotfixes that are released by MS for the individual components.
Your last links were more useful than any of the previous ones posted including the one I posted that you took such offense to, which was in reply to the OP saying that they believed the link was incorrect - again though, it was intended to assist not as an attack, and I again apologise for your not understanding that.
I'm not taking anything personally. I am convinced, once again, that you should not begin with 'I'm no expert, I cannot advise', then go on trying to find weak spots in other experts advices without adding real value.
This sentence is not quite clear. Actually the OP wanted to go the hybrid way while I advised him to choose cutover for a number of reasons.
I suppose others and I should be the 'people who do not understand the complexities'? While you do? And what should be 'the usual route'?
It seems to me you are advising not to do something (which the OP has been already advised not to do because it is an hassle basically) because in your opinion it may be tricky and because you just know better.
And note that it's a bit unfriendly you saying that you find amusing other IT expert not understanding complexities, and you may get this fact pointed out, but that does not mean one takes things personally just because does not agree with you
"I've been trying to assist the OP to help them avoid being sent down the usual route that occurs because people do not actually understand the complexites of SBS by trying to do something that breaks the functionality of the product"
This sentence is not quite clear. Actually the OP wanted to go the hybrid way while I advised him to choose cutover for a number of reasons.
I suppose others and I should be the 'people who do not understand the complexities'? While you do? And what should be 'the usual route'?
It seems to me you are advising not to do something (which the OP has been already advised not to do because it is an hassle basically) because in your opinion it may be tricky and because you just know better.
And note that it's a bit unfriendly you saying that you find amusing other IT expert not understanding complexities, and you may get this fact pointed out, but that does not mean one takes things personally just because does not agree with you
And again I do not believe I have tried to "point out weak spots". You're very quick to point the finger at mex whilst completely overlooking your own misinformation.
However all of this detracts from the question so I'll disengage from the discussion and allow you to continue completely unchallenged, since it seems to upset you so much and you have an apparent desire to overlook friendly conversation with your need to be 100% right.
Good luck with the migration, zimboman.
However all of this detracts from the question so I'll disengage from the discussion and allow you to continue completely unchallenged, since it seems to upset you so much and you have an apparent desire to overlook friendly conversation with your need to be 100% right.
Good luck with the migration, zimboman.
ASKER
Thanks for all your input. I thought it best to summarise my situation, I am almost done with the migration and I am happy with the route that I took.
1. Thanks to Michaelangelo for the https://www.itpromentor.com/migrate-2010-to-365/ link. This formed the main part of my method, with some slight changes.
2. Hybrid was the method I used. This really should be the primary method for any it professionals looking to migrate a local exchange server. Having users cutover with only a password entry and an OK button to click, is invaluable, for them and me.
3. Yes I had to setup a Server2016 VM and install Exchange 2013. This is needed regardless of the SBS2011 source platform - all SBS migrations will need a separate (domain joined only) 2016 server, as a VM or whatever works for you. I did not need to pay for licenses for Exchange, MS provide a Hybrid license for this specific purpose. This license is activated during the configuration of the Hybrid Configuration Wizard.
4. I did not need a UCC certificate, I just got a cheap wildcard cert, and loaded onto both servers. Worked fine.
The rest of the link documents the process quite well, once I had find out specific pre-requisites.
So all good, didn't mean to cause a $&%# fight, but appreciate the input all the same.
Happy migrating people.
Cheers,
ZM
1. Thanks to Michaelangelo for the https://www.itpromentor.com/migrate-2010-to-365/ link. This formed the main part of my method, with some slight changes.
2. Hybrid was the method I used. This really should be the primary method for any it professionals looking to migrate a local exchange server. Having users cutover with only a password entry and an OK button to click, is invaluable, for them and me.
3. Yes I had to setup a Server2016 VM and install Exchange 2013. This is needed regardless of the SBS2011 source platform - all SBS migrations will need a separate (domain joined only) 2016 server, as a VM or whatever works for you. I did not need to pay for licenses for Exchange, MS provide a Hybrid license for this specific purpose. This license is activated during the configuration of the Hybrid Configuration Wizard.
4. I did not need a UCC certificate, I just got a cheap wildcard cert, and loaded onto both servers. Worked fine.
The rest of the link documents the process quite well, once I had find out specific pre-requisites.
So all good, didn't mean to cause a $&%# fight, but appreciate the input all the same.
Happy migrating people.
Cheers,
ZM
SBS is very pernickity about additional domain controllers.
And as if that weren't enough of a blocker, SBS 2011 doesn't allow you to have forest trusts or child domains.
Edit: I've just done some quick googling and there seems to be a split between what I said about and others saying it can work and yet others saying it will work but you will subsequently break other functionality in SBS
Honestly the lack of documentation from MS on this one is dissapointing and I'm sorry I can't give you a definitive answer.