One of the last tasks in my CTO tenure at ShareSquared was to move us fully to Azure. Like many SoCal organizations, we had a data center location in Los Angeles with a couple of racks of equipment.
This included several large machines for running our virtual environments with SharePoint and 3rd party products. As part of another separate goal, I was able to get Sharesquared to Gold cloud partner and that gave us $12K in yearly spend for an Azure subscription. This means we can do many of the things we were doing in the data center via IaaS in Azure.
The data center included the following:
- ForeFront TMG for data center firewall
- Domain Controllers
- ADFS (serving our O365 logins)
- Misc servers to support development (SharePoint, SQL Server, TFS, etc)
Moving the Domain Controller:
We wanted to have a backup strategy in case we ended up needing to fail back to ADFS. The only way that would work is to have a domain controller in Azure with ADFS enabled. There are some issues with doing this of course. The first is you can’t simply make one of your current domain controllers a VHD and upload it. Azure VMs need lots of “agents” to support all that fancy security and configuration. Therefore, I had to make a DC in the Azure tenant. This meant I had to create a VPN from our data center to the Azure VM.
Creating a VPN connection to Azure isn’t totally straight forward, but luckily Apple iOS already forced me to move to L2TP and SSL VPN end points. Unfortunately, Azure only supports SSL VPN connections directory from the VMs.
Setting up the VPN:
ForeFront TMG was out gateway firewall. TMG has many cool features even for how old it is. Originally I wanted the VPN traffic to go straight to the DC with RAS but that proved to be difficult with the whole SSL VPN configuration. If I had been able to use L2TP or PPTP then life would have been a breeze. But its not, so had to fall back to SSL VPN that terminated at the ForeFront device. The TMG software is very flexible, probably too much so. After some serious testing/configuring, I was able to setup and connect to the SSL VPN from the Azure VM. Unfortunately, TMG puts everything into “virtual networks” so I ended up having to create firewall rules between VPN clients, local network, internet for every possible path, that took the most time of the entire migration.
Creating the Domain Controller and Moving the Roles
Once the VPN was working and all the firewall allow rules were setup I was able to promote the Azure VM to a DC. Once that once done I was able to move all the DC roles to the Azure VM.
I also installed the Azure AD Connect client and had it take over as the primary replication services.
Unfortunately, running a DC in Azure comes with some price when you don’t do things quite right, hey, you live an learn! What I will simply say is…
- Understand how to do authoritative restore (the whole D3 method) aka DFS sucks
- Back up your sysvol in case you need it later – for us this wasn’t as important as we didn’t need to apply GPO or run any login scripts anymore
Similar to Active Directory Domain Controller, ADFS has a primary server and secondary servers. You can’t really configure a second ADFS server and have your external services point at it. You have to make the ADFS server a part of the ADFS farm, then make it the primary server. The old ADFS will still work and accept traffic, but the UI will only work on the primary.
Breaking the links
At some point you have to break the linkage. That means demoting the DCs in your data center and breaking the ADFS secondary link. Additionally you will need to make sure your ADFS login\DNS is switched to point to your new Azure ADFS server.
Be sure that you put some effort into your Network Security Groups for your virtual network! PAW machines are your friend! And spend the extra money for Azure Security Center. Your machines are going to get hammered.
Testing the changes
#1 – Doing One user (Me)
Before I broke all the linkages I wanted to test moving my account to “Cloud Only”. This was pretty much a disaster so my account ended up in deleted limbo hell over and over. Why? Well, you have to move your account out of the AD Connect Sync set, this will cause it to get “deleted” from Azure AD (at least it goes into a “Deleted” state). After this happens you should be able to restore it from deleted and then clear the “ImmutableId”. Unfortunately, this does not work and nothing I did would allow me to clear it. So I decided to change my email alias away from the email@example.com to firstname.lastname@example.org. This worked to get me away from any time of account deletion every sync, but it came at a big price:
- Delve page broke with a correlation error
- Project Server broke because it couldn’t match me to my enterprise resource or email alias, so I couldn’t submit time or see any tasks – this was a big ouch!
Once I determined that the final product would not produce the weird errors above we picked a weekend for me to do the migration. It was incredibly easy once all the plumbing was setup. I ran a few commands to break the federation and boom, all done. The Azure AD Connect was still running with password write back so we had a working fallback just in case we decide later to move to a full Azure AD environment. But with the progress on the new Active Directory Services in Azure, that seems like a 0% chance.
The last gotcah was that I put the Azure VM in our non-gold partner subscription (the one with $12K to use), mainly because we didn’t have it setup at the time. Moving the VM was a bit painful (hint, you do not need to download the VHD, let Azure move it directly between subscriptions). But once I successfully moved it, it fired up, but I had to do the authoritative restore again (seems like you should be prepared to do this often in Azure).
ShareSquared is moved fully to Azure IaaS and PaaS. No more monthly fee from a co-lo. And we are utilizing out IUR for Azure for being a Gold Partner saving us quite a bit every month!
If you need help moving your organization fully to Azure, I’m always available to help!