Adding Microsoft Cloud to a Small-to-Medium Business

cloud-computing-hands-hero
There’s lots of talk about cloud and what it can do for your business. But with so many offerings, even from one vendor such as Microsoft, it can be confusing to determine what’s the best way forward. I thought that with this post, I would talk about what I’ve done with my employer, a business with under 50 employees and a small Hyper-V cluster.

A Small-to-Medium Enterprise

The common definition of a small-to-medium enterprise (SME) or a small-to-medium business (SMB) is between five and 250 users. In terms of IT, that business might be server-less, which is increasingly common thanks to Software-as-a-Service, or it might have one server or virtualization host, or it might have a two to three small node virtualization clusters.
My employer, a technology distributor or wholesaler, falls into the SME bracket. We have less than 50 employees, and we run a two-node Hyper-V cluster. In terms of server applications, we have many common requirements:

  • Windows Active Directory
  • File and print
  • Customer relationship management (CRM)
  • Accounting

But we also have a few server applications that you won’t find in many companies because of our automated integrations with some of our suppliers. But like most SMEs, these machines are critical to our business.
As a Microsoft value-added distributor, we are in the position of leading the charge on Microsoft cloud computing in our market. We don’t just sell the technology; we believe in it. And that’s why we’ve been in the process of using the technology more and more over time.
You might think that I’m the IT guy — I’m not. It’s a role that a few people do when they have time; something you find to be quite common in the SME. Most of my time is spent learning new technology and sharing that knowledge with our customers. But I do get involved when things break or there’s a piece of project work that has to be done.

Azure Active Directory

To make the most of any of Microsoft’s cloud services, you need to use Azure Active Directory (Azure AD). Whether you know it or not, you are using the service once you start to create user accounts in Microsoft’s enterprise cloud services.
The design that I came up with was not necessarily the best one for a short-term vision, but we had a long-term vision where our network would be extended into the cloud. We deployed a pair of Basic A series virtual machines in an availability set in a single Azure virtual network. A site-to-site VPN connects our company’s firewall to a gateway on the Azure virtual network, extending our network into the Azure network. The Azure virtual machines were promoted to be domain controllers in our on-premises AD domain and configured in a new AD site with a site link enabling replication between our office and the Azure AD site every 15 minutes.
AzureADConnectDesign
We verified our domain name, which is a simple process via the DNS domain hoster, and decided to use DirSync to synchronize user accounts to the cloud. DirSync was once the preferred method to copy users to the cloud, but I found it to be a troublesome product. Eventually Microsoft replaced DirSync with Azure AD Connect, and as you might have read recently, I upgraded this to the latest version (1.1); this now allows replication between our in-Azure domain controllers and Azure AD every 30 minutes.
There are a few reasons why I opted to implement this design instead of using Azure AD Connect on-premises:

  • Availability: If we lose our office, we still have Active Directory that’s operational. We plan to use Azure Site Recovery (ASR) to replicate virtual machines to Azure, and we will need our AD to authenticate machines, services, and users.
  • Azure: Our developers are working on applications that will run in Azure virtual machines instead of on-premises.

Microsoft Intune

The first cloud service that we started to use at work was Intune. We deployed the agent to our PCs using Group Policy, and we manage Windows Updates via Intune. We have anti-virus protecting our machines and they provide centralizes alerts, which turned out to be pretty important for some of our staff that must browse sites in some interesting countries to search for new brands.
We haven’t started to manage mobile devices yet, and software distribution has been very lightly used, but that’s something we want to start doing in the future.

Office 365

Our company ran Exchange on-premises for many years. I ranked that virtual machine as the single biggest risk to the business. No one in the company knew Exchange well enough to troubleshoot it. I haven’t worked with the product since the very early days of Exchange 2003, and my troubleshooting was to reboot it. That worked for a few years until I started having nightmares.
We deployed an Office 365 subscription (an E3 plan) to the business over a year ago. The initial requirement for some of us was to start using Lync Online, which is now called Skype for Business. No matter where any of us are, we are in touch with each other. I’ve found Skype for Business invaluable — I’m on the road, and I work from home quite a bit, but I can stay in touch with my colleagues and our partners without sacrificing anything.
More recently, our sales team needed a way to collaborate on documents. SharePoint Online was deployed and they took to it like ducks to water.
It’s not all success though; we tried to use Yammer. Our staff are young enough to understand social media so that wasn’t an issue — it’s just that no one really felt the need to use an internal social media service. Yammer was tried within our organization, but it burned out.
Eventually management agreed that Exchange had become a risk to the business. It was decided that we should migrate our Exchange server to Office 365. We opted to do a cutover migration using a migration service from SkyKick. Let me remind you that I am far from an Exchange expert. I was … nervous (I’d use stronger and more descriptive language, but our editors like us to be polite). But I was walked through a migration setup by SkyKick, and I felt comfortable. We scheduled the cutover migration a few months ahead of time and waited. Then one Friday at 17:00, the switch happened. We modified our DNS settings, made some changes on the Exchange Server, Outlook profiles were updates (mostly automated by SkyKick), and on Monday, everyone was using Office 365 for email. The Exchange virtual machine is now turned off.
What about backup? Office 365 does not have backup. The marketing arm of the product group might dispute that, as Office 365 does have recycle bins. But we wanted true backup. Once again, we turned to SkyKick. I created a storage account in Azure, supplied the details of that to SkyKick via portal, and a few minutes later we were protecting all of our Exchange mailboxes, SharePoint sites, and OneDrive for Business accounts.
Admission: My employer distributes SkyKick, so we had the licenses for free… but so do many Microsoft partner companies.

Azure Backup

We have been using one of the legacy backup products for many years, but it has held us back on adopting newer software and services. The decision was made to replace the old server hardware that our Windows Server 2012 Hyper-V cluster was running on. I built up a new Windows Server 2012 Hyper-V cluster and migrated our DataOn JBOD (Storage Spaces) storage to it. There were a few more steps, but that’s the short version!
We took an older server and decided to re-commission it as our backup server. It was configured with some cheap RAID5 storage, which would allow me to perform disk-to-disk backup — no more tapes! Next, I configured a backup vault in Azure and downloaded the free Azure Backup Server and installed it on the server. About 30 minutes later, agents were deployed onto the new Hyper-V cluster, and I was able to test backup and restore of virtual machines. We now had disk-to-disk-to-cloud backup:

  • We perform daily backups of nine virtual machines to local disk at 13:00 and 18:30.
  • Seven days of retention are kept on that local storage.
  • At 21:00, recovery points of seven virtual machines, which have over 700 GB of VHDX on the cluster, are sent to the Azure backup vault.
  • We keep 30 days of recovery points in Azure.

After just seven days, we have had successful backups every day (except for the first where there was a small bit of human error by me), and we are using just 336 GB of storage in Azure. I estimate that we’ll have no more than 450 GB in Azure after one month — and that the service will have cost the company just over $91. Ask your boss if they’d like backup for that much per month!

Azure Site Recovery

The next step will be to deploy Azure Site Recovery (ASR) to give the business a disaster recovery solution. A recovery vault is ready in Azure, and the ASR provider has been installed on our Hyper-V hosts. Those seven virtual machines that are being backed up will also be replicated to Azure (backup and DR are two different problems and solutions). The two virtual machines that we are not replicating are the domain controllers that are running on-premises.
In the event of a disaster, we will use a recovery plan to automate the failover of those seven replicated virtual machines to Azure. The Windows domain will already be present thanks to the two Basic A-series virtual machines that are running as domain controllers in the domain. So everything AD and DNS will be consistent after the failover.
I haven’t discussed business continuity planning (BCP) yet, but I suspect that I will use Azure Automation to deploy Azure RemoteApp in the ASR recovery plan to provide easy access to our services in the event of a disaster.

What I Haven’t Covered

The other services that we have access to and I haven’t planned yet are Azure AD Premium and Azure RMS. I’m not sure if we will use Azure RMS, but some of our staff members and directors probably have content that should be tightly controlled.
Our usage of cloud services is mostly Microsoft-centric, but I’m sure that if I used our Azure AD Premium benefit, Cloud App Discovery, I could find some shadow IT lurking on the network that should be brought under the control of single sign-on. We might also want to deploy multi-factor authentication (MFA) for when Office 365 is being access outside of the office.

Reasons to Adopt Cloud Services in Your Organization

The solutions that we have deployed are starting to creep in the SME market. I’ve discussed my situation, the SME, for two reasons:

  • Obviously, I’m familiar with it.
  • SMEs are much more agile and faster to use (note the careful selection of the word “use”) cloud services than large enterprises.

The technologies and solutions I’ve shared solve common problems for SMEs:

  • Reduce risk and end the era of accidental IT company
  • Increase collaboration and communications
  • Embrace cloud computing, but under the control of the company
  • Take control of end user security and experience
  • Reduce the pain and cost of backup
  • Make business continuity a possibility
  • Extend existing investments in IT
  • Non-threatening to IT staff

What are you doing with the cloud now? Is your approach different to mine? Do you have any opinions on the matter? We’d love to hear — so comment below!