Migrating email server from sbs2008 to Office 365 only but keep the SBS2008 as file server
I have 25 users in the SBS2008 using server1.name.local as domain name. I am planning to migrate all emails to Office 365 and then stop the Exchange in SBS2008 and keep the SBS2008 as file server and RWW use as stage 1. When our accounting software comes with a cloud version, we will move everything to the cloud as stage 2. Is it possible to do that?
ASKER
Jose, thanks for your suggestions.
Here is what I think after getting the 25 license for o365, moving all exchange emails, and pointing the MX record and auto-discovery to the o365 new IP address:
1. I have 12 fields guys who just need company emails on iPhone and Outlook anywhere in laptop so they can reconfigure Mail on their iPhone and install Outlook 365 in laptop for getting emails through o365.
2. The other 13 internal users will continue to connect their workstations inside the office to SBS2008 (server1.companyname. local) server and accessing shared drives and accounting software. I will install the new outlook 365 on their workstations and connect it to O365.
3. If they need to remote access their workstations from home, they keep logging in https://remote.companyname.com/remote for using the RWW.
What I think the o365 will use a new IP address for MX record and auto-discovery; the remote.comapnyname.com has the old IP address for outside users. Will it be workable on these 3 points?
Here is what I think after getting the 25 license for o365, moving all exchange emails, and pointing the MX record and auto-discovery to the o365 new IP address:
1. I have 12 fields guys who just need company emails on iPhone and Outlook anywhere in laptop so they can reconfigure Mail on their iPhone and install Outlook 365 in laptop for getting emails through o365.
2. The other 13 internal users will continue to connect their workstations inside the office to SBS2008 (server1.companyname. local) server and accessing shared drives and accounting software. I will install the new outlook 365 on their workstations and connect it to O365.
3. If they need to remote access their workstations from home, they keep logging in https://remote.companyname.com/remote for using the RWW.
What I think the o365 will use a new IP address for MX record and auto-discovery; the remote.comapnyname.com has the old IP address for outside users. Will it be workable on these 3 points?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Great, thanks for your reply so I can have a peace of mind to proceed the migration.
Would you mind directing me the next steps (any instructions or steps by steps guide) to proceed the migration of email server from sbs2008 to o365. Thanks again.
Would you mind directing me the next steps (any instructions or steps by steps guide) to proceed the migration of email server from sbs2008 to o365. Thanks again.
There's no such a thing as sbs2008 to o365 bud, there is exchange 2010/2013/2016 to o365.
I think that exchange version is 2010.
Maje sure to have 2010 sp3 and use this link
https://technet.microsoft.com/en-us/office/dn756393.aspx
I think that exchange version is 2010.
Maje sure to have 2010 sp3 and use this link
https://technet.microsoft.com/en-us/office/dn756393.aspx
ASKER
The exchange server comes with the sbs2008 is Exchange 2007. Are there any instructions for that? Thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can remove exchange server after migration, yes and keep it as a File server, yes but it won't work well that way since those you moved into o365 will use Cloud Identity instead of your AD.
So the way to go here is to do a hybrid configuration, migrate all the mailboxes, decommission exchange server and left the synchronization tool on premises, this manner they all will be synchronized with your internal infrastructure and will be able to keep using your AD for authentication.
If you do it the way you wanted (without any synchronization) you will have two different identity management for the same domain, and that's a problem since cloud system doesn't know a thing about internal authentication.