Because every network has different priorities every migration will be a little bit different. With that in mind, this blog is written for the purpose of helping your organization plan your on premise Windows domain controller and file server migration to the cloud using TrueStack Direct Connect, with little or no disruption to your end-users.
TrueStack Direct Connect is a VPN management server made to connect Windows and Mac computers to Windows domain controllers and files servers in the AWS and Azure clouds.
A detailed explanation of the Windows DC and file server migrations steps are posted here.
Please read this document before you start to help you better prepare your network and plan your migration.
Slowness is generally related to computer performance, cloud server performance or bandwidth. Before you migrate, plan carefully, especially in these 3 areas.
Slowness is generally not related to managing Active Directory computers with a cloud Windows domain controller, unless your domain controller is using WSUS, SQL or other client server software or scripts that use up resources on the cloud server and on the client.
Organizations whose end-users access files on cloud Windows server network shares may experience slowness also due lack of resources in one of these three areas. See about cloud file access below.
About cloud file access:
- For organizations who use TrueStack Direct Connect to connect their end users to cloud Windows file servers, browsing files will be noticeable slower on Windows 7 computers vs. Windows 10 computers.
- If you are using Office 2010 or an earlier version of office to access files on a cloud Windows file server you will notice lag times in file access. We recommend Office 2013 or later.
- Access to files on a cloud Windows file server will be much faster if your on premise computers use Windows 10 with SSD drives.
- PDF files on the cloud Windows server will open faster with newer versions of Adobe Reader or Adobe Acrobat. Large graphic or design files will open slower if the files are on the cloud Windows server. See pictures, PDFs and Videos below.
System Requirements: Windows 7, 8, 8.1,10, 32 bit or 64 bit. Administrator rights are required for TrueStack Direct Connect client installation.
For the best performance we recommend: Windows 10 Pro, i5 (or equivalent), 8GBs memory, SSD, Microsoft Office 2016
Cloud Server Performance:
Below are general recommendations for server performance.
Free Space: Windows servers may run slower when there is less than 20% free space on the root hard drive. You can increase the size of the root hard drive in AWS or Azure. We recommend shutting down your server and making a snapshot of the drive before you increase the size.
Updates and Restarts: Updating and restarting your Windows server regularly will also increase server performance. We recommend putting your server on a schedule to restart at least once a week after hours.
Server Usage: When choosing the size of your servers consider it’s use. For example, SQL servers need more VCPUs, IOPS and memory. Servers that are used for heavy file access of pictures, large PDFs and large videos will also require more VCPUs, memory, IOPS and bandwidth (see Pictures, PDFs and Videos below).
Separate Hard Drives: We recommend that Windows storage drives used for file access in the cloud, are SSD and are separate drives from the root. This will make it much easier to upgrade your OS in the future (see upgrades below). It will also make it easier to backup and restore (see backups below) and easier to increase the size of the drive if needed without affecting the OS.
IOPS (Input/Output Operations per second): Monitor your server’s performance and IOPS usage to determine your organization needs. In cloud servers, IOPS is often the determining factor as to the speed of your server and cloud network throughput.
TrueStack IOPS: In general TrueStack Direct Connect servers use very few IOPs. You will find that the IOPS credits are very stable and it rarely has to be restarted or upgraded to a faster server.
We do not recommend restarting the TrueStack Direct Connect server on a schedule. A restart will disconnect all of your computers. After a restart, some computers may not reconnect correctly. If a computer has a connection issue, restart the TrueStack service on the computer or restart the computer instead of restarting the TrueStack Direct Connect server.
In AWS, IOPS are determined by the server version and the size of the hard drive. The larger the hard drive or server the more IOPS credits you accumulate. T2 instances are burstable. This means that they may run out of credits. When you run out your Windows server will run very slow. If you find that your Windows server slows down in the middle of the day, consider increasing the size of the root hard drive. For Windows, we recommend starting with a 60GB SSD then increase it up to 200GBs or larger. You can also increase your VCPUs and memory by upgrading to a faster server. If you start with a T2 Micro instance and you’re seeing slowness, upgrade to a T2 Small or T2 medium and increase the size of your root drive.
You can monitor your IOPS credits on the monitor tab of your instance. If it shows close to 0 credits the server will be very slow. In general you’re credits should be around 150 – 300 or more. Regular restarts of your Windows server improves IOPs performance and credits. We recommend scheduling your Windows server to restart at least once a week. We do not recommend scheduling a restart of your TrueStack Direct Connect server. Servers running SQL will require more VCPUs and IOPS. If you are running WSUS, monitor your credits throughout the day and upgrade as needed.
You can upgrade the size of the hard drive or upgrade to a faster server without loosing data. As a precaution, we recommend that you shut the server down then snapshot the drives before you upgrade.
Use the AWS Calculator to determine the IOPS per hard drive size. 1TB = 3000 IOPs for an SSD drive. Be aware that different regions charge different rates. Because of this, for example, it may make more economic sense with little performance difference to put your servers in US West Oregon, instead of US West California.
Azure also uses IOPS and has burstable Virtual Machines, but the VMs package in the root hard drives which includes caching (similar to a page file) so it’s not always so easy to determine the size of the root drive before launching a VM.
We don’t recommend using burstable Virtual Machines in Azure for Windows servers or TrueStack Direct Connect. In general the equivalent Azure B series VMs run much slower than the AWS T2 series. We recommend starting with the D2 series VMs which aren’t burstable. With this in mind you’ll notice that AWS has much better pricing than Azure, however you may be able to reduce your hosting expense by bringing your own Windows licenses and paying for reserved instances. Nonprofits can also benefit from Azure if they are eligible for $5000 in Azure credits through Techsoup. See Cloud pricing below.
Azure sets the size of the hard drive plus temporary storage used for caching when you choose a VM size. In general we recommending using their default sizes then increase to a faster VM as needed.
See the Azure Pricing Calculator.
AWS Server Size Recommendations:
Recommended: 1- 10 connected devices
TrueStack Direct Connect server: T2 Nano, 8GB SSD
Windows Server: T2 Micro 60GB SSD
10 – 20 connected devices:
TrueStack Direct Connect server: T2 Micro, 8GB SSD
Windows Server: T2 Small 100GB SSD
25 – 50 connected devices:
TrueStack Direct Connect server: T2 Micro, 8GB SSD
Windows Server: T2 Medium 200GB SSD
50 – 100 connected devices:
TrueStack Direct Connect server: T2 Micro, 30GB SSD
Windows Server: T2 Large 200GB SSD
Azure Server Size Recommendations:
Recommended: 1 – 10 connected devices
TrueStack Direct Connect server: Standard Tier, DS2v1 3.5GB RAM, 50GB Temporary Storage
Windows Server: Standard Tier, DS2v2, 2 cores, 7GB RAM, 100GB Temporary Storage
10 – 25 connected devices:
TrueStack Direct Connect server: Standard Tier, DS2v1 3.5GB RAM, 50GB Temporary Storage
Windows Server: DS3v2, 4 Cores 14GB RAM, 200GB Temporary Storage
25 – 75 connected devices:
TrueStack Direct Connect server: Standard Tier, DS2v1 3.5GB RAM, 50GB Temporary Storage
Windows Server: DS12v2, 4 Cores, 28GB RAM, 200GB Temporary Storage
75 – 100 connected devices:
TrueStack Direct Connect server: DS2v2, 2 cores, 7GB RAM, 100GB Temporary Storage
Windows Server: DS13v2, 8 Cores, 56GB RAM, 400GB Temporary Storage
The amount of bandwidth your organization needs depends on what type of load you are putting on your server. Here are our general recommendations based on 1 Windows DC and file server with 1 TB of Storage, using a cable connection. In this scenario users generally access Microsoft Office and PDF files on cloud Windows shared folders For some organizations a dedicated synchronous connection may be preferred.
1 – 10 connected devices: 50 mpbs/down – 10 mbps/up
10 – 50 connected devices: 100 mbps/down – 20 mpbs/up
50 – 100 connected devices: 200 mbps/down – 50 mpbs/up
Client/Server line of business applications
In general, client server applications like Quickbooks database manager or Sage Accounting or custom multi-user Microsoft Access databases, will not run at speed across the TrueStack Direct Connect VPN. Here are some alternatives:
- Move to a web-based application.
- Use Microsoft remoteapp in the cloud to stream the application to the user. We’ve written a blog explaining how to do this in AWS. How to Set up Windows Remoteapp in AWS.
- Set up a Remote Desktop Gateway server and RDP server.
- Use Parralels in the cloud or another remote streaming app to stream the application to the end-user.
- Put the application on a local member server or computer. We don’t recommend this solution unless there is no other alternative. Here’s why:
- You will need to maintain an onsite/offsite backup solution for the onsite member server.
- The client Windows computers onsite will need to be able to find the onsite member server by DNS or IP. By default the TAP adapter will register an IP for the member server in the 188.8.131.52/20 network. The onsite clients will not be able to communicate with the member server with this IP. They will only be able to communicate with the local IP, for example 192.168.1.2. So you will have to update the DNS address that the clients get. The easiest way to do this is to un-check the “Register this connection’s address in DNS” checkbox on the DNS tab of Advanced TCP/IP Settings for the TAP network adapter.
After that ensure that the local IP address of the member server appears correctly in Windows DNS on the cloud Windows DC. Another way to update DNS is to set the IP for the member server in the local host file of the client computers. One problem with this method is that if you Un-register DNS for the member computer then the Windows DC won’t be able to send Group Policy information and other commands to the member server because the Windows DC can’t communicate with the local IP. To update the member servers policies you will have to temporarily register it’s TAP adapter in DNS. This is why host files might work better.
DNS and DHCP
After migration ensure that Windows DNS and DHCP is set up correctly. If DNS isn’t working correctly your connected devices will take longer to find the correct UNC paths for shared folders and may not receive their group policies. If DHCP isn’t working correctly your computers may still be searching for the on premise Windows server instead of the cloud Windows server.
- On premise DHCP should be giving out DNS IPs of your gateway or your ISP or 3rd party DNS servers. If they are giving out the DNS IP of your old on premise Windows server you will need to change it so you’re computers will find the cloud server instead of looking to the old on premise server for DNS.
- If you had previously used your on premise DHCP server to give out IPs change DHCP to your router.
- Ensure your TrueStack Direct Connect VM or instance has a cloud static IP.
- Private IPs are inherently static. But they aren’t set at the cloud network adapter, they’re set by AWS or Azure. Public IPs that aren’t set static will change after a restart, unlike prviate IPs. In fact, do not set a static IP on the cloud network adapter of the VM or Instance, you may loose complete access to the server!
- In AWS be sure to add a route for 184.108.40.206/20 and in Azure be sure to add route table for 220.127.116.11/20. Both of these are required in order for the Windows DC to be able to access the client computers. Follow the Additional Required Steps in the step by step configuration to add these routes. https://truestack.com/truestack-direct-connect-aws-setup
- In AWS, be sure to Disable Change Source/Dest. Check for the TrueStack Direct Connect server. Follow the directions in initial configuration for AWS to make this change. https://truestack.com/truestack-direct-connect-aws-setup
- On the cloud Windows DC, ensure that the DNS address for the network adapter is set to 127.0.0.1 or the Private IP of the Windows server, for example 10.0.0.5.
- In the TrueStack Direct Connect interface ensure connected computers show the private IP of the Windows DNS server in the DNS server IPs section.
- In the Windows firewall for the client and the server open file and print sharing for the domain only, so you can access the clients by UNC path and ping them by DNS name to see if DNS is working correctly.
- Some DNS servers provided by your ISP may block some DNS traffic going across port 1194. In these cases the Windows server won’t be able to access the client. You will know that this isn’t working because you won’t be able to ping the client by DNS name from the cloud Windows server and the client’s TAP adapter icon in control panel will show “Unidentified network” under the adapter name, instead of your Windows domain name.
You can test this by changing DNS on the network adapter of one local client to an external DNS server, for example use Google’s 18.104.22.168 or 22.214.171.124. If you’re ISP is causing this DNS issue then you will see that your domain name immediately appears on the client’s TAP adapter.
This should be a rare situation, however, in this case you have a few options:
- Change DHCP on your on premise router to give out the IP of your gateway or a 3rd party DNS, such as Google’s DNS servers – 126.96.36.199 or 188.8.131.52
- Note: the client’s local area adapter or wifi adapter should not show your domain name. It should either show “Network #” or the Wifi name. If it is showing you’re domain name, it’s probably because you’re router is giving out the old on premise server’s IP for DNS or DNS is set static on the adapter with your old server’s DNS IP. This should be removed.
Minimize Disruption – Rename your Cloud Server:
The best way to minimize disruption to your end-users during migration is by removing the on premise server and renaming the cloud server to the same name the on premise server had. If you install the TrueStack Direct Connect client on their computers and restart the computers after you’ve removed the on premise server and renamed the cloud server to the same name the on premise server had, then your end-users will log on as normal and be able to access their network shares as normal after migration. If the Overall Performance is well tested (see section Overall Performance) then you’re end-users shouldn’t even notice that the server is out of the closet.
During migration, If you do not completely remove your on premise server from the cloud Windows domain, even if DNS and DHCP are set correctly, your on premise computers may still look for the old on premise Windows server for authentication and DNS. After you have migrated all of the FSMO roles, data and applications, then demote your on premise Windows DC and then remove it from the Windows domain, rename it and delete all entries for the server in AD Sites and Services and in DNS. Restart the server. Then after installing TrueStack Direct Connect on the client computers and restarting the computers, they will find the new Windows cloud server for authentication and DNS.
We recommend that you snap shot the server before you rename it.
- Use Branch Office Printing for capable printers. Here’s a explanation of Branch Office printing from Microsoft. If you rename the server to the same name your old on premise server had and ensure your shared printers have the same name they had before, then your end-users will be able to continue to print as normal after migration.
- Some printers, especially those that require print codes, may not work well with Branch Office printing. For those printers see this link to use a GPO to install the printers locally.
- Branch Office Printing does not work on Windows 7 computers. Printers on Windows 7 computers will have to be installed TCP/IP locally or installed through a GPO.
- Some printers that are capable of using DNS and Branch Office printing may connect very slowly. The end-user may feel like their entire computer is running slow because these printers are associated with the main applications they frequently use, like Microsoft Office. In these cases we recommend testing with different print drivers. Be aware that different print drivers will act differently on different Operating Systems. If there aren’t any print drivers that connect at normal speed on all computers with Branch Office printing, we recommend installing these printers TCP/IP locally instead of using Branch Office printing or use a GPO.
- Some networks require USB connected printers to be shared. In these instances, because the computers cannot communicate with each other through the TrueStack Direct Connect VPN, we recommend setting the computer with the connected USB printer to a static IP. Other users can then access the local shared printer by UNC path – for example \\192.168.0.25\printer
- If you have been using scan to file, we recommend switching to scan to email. If you have O365 or Gsuite you can may be able to use these accounts for SSL/TLS relay through their SMPT servers. You can also use a 3rd party SMTP relay server or set up a SMTP rely in the cloud.
- If you need to use scan to file you will be required to either have an on premise file computer or member server that you’re client computers can use to access a shared folder for scans or you will need to set the computers with a static IP so the scanner can find the computers by IP across the network.
- You can also use a USB scanner connected to one computer.
TrueStack Direct Connect uses ports TCP 80, 443 and UDP 1194. These ports should be left open in cloud AWS or Azure firewalls.
- Port UDP 1194 is used for client/server VPN traffic.
- Port 80 redirects to port 443.
- Port 443 is used for the TrueStack Direct Connect interface and updates. It’s also used for authentication of the client installer and to certify that the TrueStack Direct Connect is a valid AWS or Azure server.
- In AWS add an ALL Traffic entry in the Security Group. The Type is All Traffic and the Source is your subnet. Type the name of your security group for the subnet. See additional required steps in the step by step configuration. https://truestack.com/truestack-direct-connect-aws-setup
- You do not need to open a ports on the Windows firewall of the on premise computer. See Windows firewall section below.
Here are some of our recommendations for backing up the cloud server.
- If you have shared files that need to be backed up nightlly, add an additional hard drive to the cloud server and use Windows backup to backup to that drive. In AWS you can use a less expensive Cold HDD (sc1) and in Azure you can use a less expensive HDD.
- Periodically snapshot the server.
- In Azure you can use Azure backup.
- For a backup DC, add an additional Windows DC in a different region and use TrueStack Direct Connect to connect the DCs.
- If you have available Microsoft volume licenses or if you can use SPLA licenses set up a Microsoft DPM server for backup.
- Use a 3rd party solution such as Cloudberry to S3.
- Consider using Volume Shadow Copy. This will require more storage and more system resources.
TrueStack Direct Connect does not require any ports to be open for the cloud server on the Windows firewall or on the client Windows firewalls.
We do recommend opening File and Print sharing on the cloud Windows server so the computers can access network shares on the server. You can also open file and print sharing for the domain for the on premise Windows computers so the Windows DC can access the computers by UNC path.
Future Operating System Upgrades
- Keep your root drives and shared storage drives separate. That way, if for any reason you need to move a hard drive to another server you can easily move it by disconnecting it from the base server and reconnecting it to another server.
- Both AWS and Azure make it easy to expand any hard drive, including root drives. Snapshot the drives before expanding them.
- You can easily migrate to the a new Windows server operating system by installing the OS on a new VM, then adding it to the domain, promoting it as a DC and migrating the FSMO roles. After that move the hard drive to the new DC and set the share and NTFS permissions.
- You can then demote the old Windows server, remove it completely from the domain and rename it, then name the new Windows server the same name that the old server change the private IP to be the same IP the old server had. By doing this last step the new server will emulate the old one and the on premise computers will direct to the new server.
- If the cloud storage drives were a separate drive you can move them over to the new server.
- Snap shot all drives before doing migration.
Pictures, PDFs and Videos
- We recommend using Adobe Acrobat Reader DC or newer on Windows 10 computers for PDF viewing. Reader DC caches pages better than previous versions. This means that if your bandwidth is adequate (see section Bandwidth) a large PDF over 100 mbs in size will download quickly and open the first few pages quickly. While the user is viewing the first few pages, the rest of the pages will download to the computer. Windows 10 is better at this PDF caching than Windows 7.
- Pictures that are 1 – 2mb will open at normal speed. These generally have .gif, .jpeg and .PNG extensions. Programs that are used to edit pictures, like Photoshop, Illustrator or InDesign use much larger files. These files may open slow across the VPN.
- We recommend that graphic design stations open their design files locally on their computers especially if they are editing large pictures and video. They can periodically upload the copies or final editions to the Windows server.
- Some designers may require saving a shared folder on a computer or member server that is regularly backed up to the cloud.
- Other options include setting up a dedicated cloud hard drive for the design files or using faster servers with better throughput and more IOPS on the hard drives used for design files. You could also consider setting up a remote desktop server dedicated for a design user. However, we’ve found that none of these options work as well as opening the files locally on the design computer and periodically uploading them to the server or using a local network share that’s backed up to the cloud.
- When using the AWS Calculator notice that different regions charge different rates.
- Un-check the Free Tier Usage checkbox in the upper right-hand corner to find out what your expenses will be once your Free Tier expires.
- There is no cost for Static IPs (Elastic IP) as long as they are in use. You will be charged for use of the Static IP when the server is turned off. You do not need a Static IP for your Windows server since it is only accessed by the private IP.
- If you decide to use a Reserved Instance you will have to pay for 1 year up front. You can upgrade at any time, but you will have pay the difference.
- AWS assumes there are 730 hours in a month.
- The Azure Calculator is difficult to use and confusing. You can also get pricing by choosing a VM in your account and viewing the price before you purchase. If you create a VM in your account to check the price Azure may require you to create a Resource Group. We recommend deleting this to make sure you aren’t charged for anything, after you check the price.
- Not all VMs are available in every region and different regions charge different rates.
- The Azure calculator shows prices based on 730 hours in a month, but your account pricing is based on 744 hours a month.