The market that I work in is very cloud friendly; Irish value added resellers (VARs) operating in the small-to-medium enterprise (SME) market have made Ireland one of the most successful regions for Office 365, and it’s no surprise that they and their customers are showing a huge interest in adopting Microsoft Azure. SMEs want rid of what’s left of their servers, and oftentimes the remaining machine in the SME space is a file server.
Options for Replacing a File Server with a Cloud Solution
Can you replace a file server with a cloud option? Yes, you absolutely can, but it’s a matter of asking yourself a couple of questions:
- Is the cloud the best route for you?
- What’s the best option for a cloud solution?
The first question is dictated by content in the file server. Several times, I’ve dealt with queries about engineers that use AutoCAD, which relies on huge files. Because of this, this scenario isn’t a great option because storing these files in the cloud often requires expensive appliance solutions. If you needs are appropriate for the cloud, then you have several different options to consider:
- Office 365, SharePoint, and OneDrive for Business. I get consistent feedback that OneDrive for Business is too fragile. I like SharePoint as a means for sharing content, but it requires a lot of user education.
- ExpressRoute. You can lift-and-shift a file server to Azure and use ExpressRoute to access the services. With a modern OS, there was quite a bit of re-engineering of SMB and TCP to optimize activities, such as browsing folders. Without these types of optimizations, metadata operations might have made the user experience intolerable. I’ve tested this option on consumer broadband, and it works well for small data transfers.
- RemoteApp/Remote Desktop Services (RSD). You can deploy an RDS solution in front of your file server, but this requires a certain amount of scale before the cost becomes justifiable. Most of the scenarios that I have encountered have been SMEs, where cloud migrations have left the customer with just a single on-premises server — the file server.
- Dropbox Work Folders. This company-owned Dropbox solution enables users to synchronize their personal folders with their devices. This allows disconnected users to work with their own collection of files. Work Folders also allows companies to control access, quotas, and types, and files that users are synchronizing, something that shadow IT solutions prevent.
- Network appliances. Something like RiverBed can make remote file services, such as Azure, work really well. The appliances are clever, make latency a non-factor over time, and can reduce the impact of bandwidth limitations. My first experience with RiverBed was a proof of concept with AutoCAD file sharing over a site-to-site VPN, where the customer bought the appliances despite the high cost.
- BranchCache: Instead of using a network appliance, you can deploy a solution that can optimize remote access of file, web, and BITS application content. This is the solution that I want to focus on in this article.
File Server without Optimization
The following diagram shows how you can deploy a file server in Azure without any additional optimization.
The servers in Azure are running Windows Server 2008 R2 or later. You might as well use Windows Server 2012 R2 if you’re deploying new VMs in Azure because the OS license is included in the hourly cost of the VM, and you do not require any Windows Server CALs to access Windows Server VMs that are running in Azure.
There is a domain controller and a file server running in an Azure VNET in a single cloud service. It’s up to administrators if they want to open up point-to-site VPN, Windows Server VPN, or Direct Access for roaming user access to services. The file server is a member of the domain, and the domain controller might be used to sync or federate with Azure Active Directory.
The PCs on the customer network are running Windows 7 (or later) Pro (or Enterprise). DHCP runs on the customer site via a network appliance. A site-to-site VPN is configured to connect the office network to the Azure VNET. The DHCP scope configures devices to use the in-Azure domain controller as the primary DNS server. The PCs are members of the in-Azure domain, receiving policy via GPOs.
I tested this scenario out in my lab, using a site-to-site VPN connection over a 12 Mbps ADSL connection with 380 Kbps upload speeds, a connection that is quite modest. I created shared folders on the in-Azure file server with 1600+ small files of different kinds in each. A domain user connects to the file server in the exact same way as they would with an on-premises one. Browsing was without latency and accessing small files was quick. Small files was quick, but what about a bit file? I dropped a 64 MB file into a share and started a download. The file was downloaded in one minute, which is way below what one would expect over a 1 Gbps connection to a local file server.
Windows 7 Enterprise and later includes a feature called BranchCache that is designed to improve the flow of traffic between clients and remote file servers, IIS servers, and applications that use BITS. The Enterprise edition of Windows was once only available via Software Assurance, but customers can now upgrade the OEM installation of Windows Pro to an Enterprise edition using Volume Licensing without Software Assurance.
BranchCache offers a service were previously downloaded content is presented to a client for subsequent requests. The first person to download a file suffers the impact of latency and bandwidth between the remote file server and their local client device. The file is used by the person and cached locally by BranchCache. Subsequent requests by this user or others will cause metadata operations:
- If previously cached blocks of a file are requested, then they are downloaded to the device from a local cache, subject to security permissions on the file server
- If the blocks of a file are not cached, then they are downloaded from the file server across the remote link
Over time, the cache will be populated with frequently accessed content and the overall performance for users will increase.
There are two kinds of cache that can be deployed:
- Distributed Cache: This is where PCs operate a transparent peer-to-peer network bounded by a subnet or VLAN. PCs that require a block will broadcast a request, and any local cache that contains that block will offer it. Note that there is reduced performance when PCs are shutdown or removed.
- Hosted Cache: A Windows Server is designated as a single cache for an office. This can be used by multiple VLANs or subnets and can be pre-seeded to improve performance on day 1.
Using Azure File Servers with BranchCache
One of the perks of BranchCache is that you do not need any new hardware to enable it — although you do need to run the Enterprise edition of Windows on your client devices. I decided to test out the design that I expect will be of most interest in the SME space; customers are asking to be rid of all of their servers so the Distributed Cache model of BranchCache will probably be the one they want to use. You can see how minor the changes were in the design in the below diagram. I simply:
- Added the BranchCache role service on the file server
- Enabled BranchCache on my share (containing all of the folders with individual permissions)
- Used Group Policy to enable the hashing of blocks that make up the BranchCache optimized files on the file server
- Used Group Policy in the domain to enable Distributed Mode BranchCache on the client devices
I logged into a Windows 8.1 Enterprise machine in the local LAN and saw no improvement in browsing folders – this already performed excellently. I then downloaded my 64 MB file from the file server, and as expected the performance was as before. But the second copy was so fast that the progress bar barely flashed on screen; the file was being copied from the cache and became a local copy instead of a remote copy.
BranchCache can make using remote file servers, such as those deployed in Azure, a much more pleasant experience. It’s not perfect; it will take time for the cache to build up (cannot be seeded in Distributed Mode), it does not optimize uploads, and it requires the Enterprise edition of Windows. However, big uploads operations by users are rare. The cache will likely build up quickly in an SME scenario. And the Enterprise edition is no longer locked behind Software Assurance (except the for Windows 10 upgrades) and it offers several other features that should prove quite useful.