Migrating to Office365 and all that jazz..

  • Last Post 21 August 2015
kebabfest posted this 20 August 2015

Right I am in the process of migrating a company to Office365.Currently there Exchange Environment 2010 is on SBS 2011 Server. (This is being decommissioned)They also use a 3rd Party SPAM Tool which the MXRecord is pointing at.In order to migrate them and ensure administration is straightforward after I was going to do the following.

  • Set up ADFS and ADFS Proxy DONE
(3rd Party SSL installed and Configured)
  • Setup Office365 Account DONE
  • Setup Azure Account DONE
  • Setup Single Sign-on (How can I do this in a controlled way ? )
  • Setup AD Synch

Now due to the companies reliance on mail I was going to adopt the Hybrid Approach and move users which are grouped together by shared mailboxes.Also there are some applications which will need altering , but I will worry about that when I have finished the user migration However I am scratching my head in terms of how to go about this in order to minimise disruption and ensure I can decommission the Exchange 2010 on SBS 2011.I was thinking of setting up a new Exchange 2010 and then removing the Exchange from the SBS Server.Overall I think I am struggling with how to set up the Federated Trust, (somebody put up a post about it earlier)Anyhow apologies if this appears rambling,  Any advice/things to watch out for or issues with my approach then please drop me a line.

Order By: Standard | Newest | Votes
BrianB posted this 20 August 2015

I am not an Exchange admin but I do run our ADFS environment and was responsible for setting up the DirSYnc with office 365. It is my understanding that you will

need a Hybrid Exchange server role set up to move users to and from office 365. You can set up the federation pretty easily and it is well documented on for office 365 using federated identities docs on Technet. You do not have to manually set up the federated

Relying party as this is done via Microsoft scripts. User will still be able to use their on-prem exchange until such time as you move them to office 365. Since you have a Hybrid Exchange server role and ADFS setup then will be able to use on Prem AD creds

to log into their office 365 email and you can move them to the cloud fairly transparently. Maybe a blip of an interruption. But if you use test identities you will get a feel for what the “blip” will be and can notify the staff of what to expect.


Brian Britt.





kebabfest posted this 20 August 2015

Thanks for that Brian. That is really helpful.


kevinrjames posted this 20 August 2015

Federation may be ‘interesting’ depending upon that SBS environment. Typical SBS environments have a single public IP with 443 forwarded to the SBS server for Exchange/Outlook. ADFS will need its own public IP forwarded SSL connection. – See where this is going.  :0 Probably “offtopic” or borderline. /kj 


kebabfest posted this 20 August 2015

HI Kevin,
The first point of contact is their external anti spam provider which I cant remove from the equation. Do I add a txt record to the mx record for adfs ip address ?


ThomasVuylsteke posted this 21 August 2015

What number of users are we talking here? Do you know that ADFS is not a requirement for O365? You can also just have “DirSync” (Azure AD Connect) and synchronize

passwords from local AD to Azure AD. That way you users have to sign in, but they can use the same credentials.



kebabfest posted this 21 August 2015

It is only about 100 or so.
Can dirsync handle single sign on ?


ThomasVuylsteke posted this 21 August 2015

I asked for the number of users just to get an idea of the size of your org. It’s not that there’s a rule 0-500 users use Sync, 500+ ADFS. It’s just the fewer

the user the more managing your ADFS cost per head. If that’s an argument.


Typically for smaller environments I propose to drop ADFS. If you do it right you need 1 ADFS Server and 1 Web Application Proxy server to expose your ADFS

to the internet. Unless you got some other reverse proxy that can do that. If you want redundancy, but that’s only valid if you got more than 1 domain controller (which you should, but in an SBS you’ll only have 1) you need 2 ADFS + 2 WAP. And then you wonder..

Pfft 4 servers? For what?




ADFS gives

you single sign on.

DirSync + Password Sync gives you

same sign on. Meaning you’ll be prompted, but you can enter the same credentials as you use against AD.


But there’s nuances that convince me that ADFS isn’t that necessary:


If you got many mobile/users authentication from home/on the road > they’ll be facing the ADFS proxy page and will have to authenticate never the

less (in case of ADFS)


Outlook will prompt, with both ADFS or Password Sync (forgetting ADAL here for a minute)


If you visit O365 related web apps, you’ll logon on once (password sync), but other visits during that same session are authenticated automatically


So, all in all, I’m not always blindly suggesting ADFS…


Check this as well:

https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/  It explains in great detail the various models/options.



kebabfest posted this 21 August 2015

You are quite right. That is too much infrastructure for such a small network. However my remit is to decommission the    sbs server and add 2 virtual dcs instead. 
The business wont accept anything less than sso, so I think it will have to be adfs I reckon with web proxy.


pjbryant posted this 21 August 2015

My 2d’s worth – had this a couple of times.  SSO (single) is very nice and desirable, but for an infrastructure of that size disproportionate

and still trebles your server count to achieve a resilient setup.  If the business really wants SSO do they know the S as single or same anyway?



Also, I’d suggest they consider not only the cost of the kit, licences and management to achieve single SO, but the impact and disruption

of failing to manage that well.  Same Sign On will achieve so much of what they would like to see, have a pretty similar user experience for so much less effort and cost (capital and expense).


I know some orgs that are small to not even bother with Same Sign On.  Users are pretty used to different credentials for different

things and with a sensible password manager can cope seamlessly with different sign on for their O365 needs and very quickly don’t even notice that it’s different.  Important, when you consider that the best password is one you don’t remember anyway!


P J Bryant

My First World War Project:

FWW: On this day



mtopper posted this 21 August 2015

Using SSO also removes one of the big selling points of Office365, especially for small environments.  One big thing they like is “you can still sign in and get

email if your building burns down” and introducing ADFS/SSO brings you right back to “you can’t sign in if your building burns down”.



Matthew Topper



kebabfest posted this 21 August 2015

Some interesting points. The building burning down one non techy people can relate too.
I did think that even with sso setup users could log directly into their cloud account too. Is this wrong ?


michael1 posted this 21 August 2015

You can also put ADFS in Azure.



kebabfest posted this 21 August 2015

That would make the dr setup straightforward.
Plenty of food for thought.
Gonna do my 1st synch on Tuesday nite, pilot testing the test of the week and all going well spend the next week migrating the small user base.
Thanks everybody for your input and have a great weekend.


kevinrjames posted this 21 August 2015

..And a DC in Azure as well. That would alleviate the on prem SSL conflict with the SBS server as well. It becomes a bit more expensive, but more durable. Will need an Azure virtual network (S2S VPN) too, but shouldn’t be a showstopper given a reasonable on prem router/gateway device.  /kj