0

I have a small network that consists of 1xSBS2008 (Exchange with about 50 mailboxes, Great Plains SQL, File Shares, Printer Shares, DNS,DHCP, GPOs, etc) and 1xWin2k8 (SQL Server). There are about 10 users at Head Office and then we have links to 5 remote locations with between 3 and 6 PCs each. The remote locations are not AD joined and it is not in the plans to do it anytime soon due 3rd part software/user limitations. I am researching the option of migrating/replacing both servers to Azure. I will be migrating emails to Office365. File access needs to remain in file shares/mapped drives. Internet connectivity at Head office is 20/20. My plan is to create 3 Azure VMs: 1xAD DC (this is a VM not Azure AD) 1xGreat Plains SQL / File Server 1xSQL Server for their LOB custom app At Head Office I would then set up a VPN to Azure via the existing Endian firewall and change the existing remote site VPN to link directly to Azure. The Endian would also become DHCP and DNS, so no DC on premises. The DHCP options will have the Azure DC as its primary DNS with the Endian as its secondary. Eventually I will probably move all workstations to an Azure RDS.

Does anyone see any problems with this? Should I have a RODC on prem or a DFS replica? Remote sites only transmit small amounts of data (retail stores) so I am confident this would work for them, but not so much for Head Office. How are you upgrading your SBS environments when customers want just a cloud solution without on prem hardware?

0

I've tested a similar configuration, focusing on network latency (on limited consumer broadband). Latency is the key here. Good news is that browsing folders etc was boosted with the "new" network stack in Vista and later. However, file download/upload is still affected. Most file server activity is reads. I used BranchCache to accelerate this - hosted branchcache on a Microserver (maybe also a RODC if that is possible) would be ideal.

The other thing you need to consider is performance of your SQL application. Is the client web based or on the PC? If it's on the PC, have a look at using RemoteApp to run the client in the cloud. Heck, you might like RemoteApp so much that you put all apps in the cloud and don't need to look at BranchCache at all because of client/server traffic would stay in Azure.

The other consideration is availability sets. Azure, etc, were designed for big "designed for the cloud" services. When MSFT does a patch cycle, everything in a fault/update domain is powered down for a short time. That means your services would have downtime. The scehdule is announced as something like "you'll see downtime sometime between Thursday and Sunday". They way around this is to create highly available services that are spread across fault domains using Availability Sets. That's easy with a DC (maybe 2 Basic A2s), but much harder and more expensive with traditional workloads like file servers.

  • Thanks Aidan, I am not too concerned about latency on the SQL app. The way it works is a Master PC caches SQL data from the server and it only gets synced every so often. It has been working fine on ADSL (8/1). I am concerned about Great Plains though. I may have to try backing up and restoring to azure and then testing access. – Cristian Feb 4 '16 at 9:41
  • I like the idea of a Branch Cache with a RODC. You wouldn't RAID this would you, or even worry about backing it up? I could invest that money on SSD drives instead. I mean if it breaks it is just a cache of what is in Azure. – Cristian Feb 4 '16 at 9:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.