NO!! It is not this kind of farm!
Background story (that you can safely ignore)
One of my side gigs is at a 501(c)(3) Non-profit organization. It is never easy for Non-profit and we are always trying to save a few bucks here and there. We have been using Quickbooks online to deal with our accounting needs, but that is costing more than $1,000 a year. In searching for a cheaper solution, here is a guide created for this purpose and probably could save us that $1,000 each year. But you can use this guide to setup RDWeb for your home lab or any company.
If you are willing to sacrifice speed and performance, this setup can be free for the first year and then less than $50 the years follow. (As long as AWS does not increase their prices) (To keep it free, you will probably need to shut down the servers during off business hours to keep the usage within the 750 hours /month limit) On the other hand, if you have the 501(c)(3) status, you can join Techsoup.org and get products/services at a discounted price. Upgrading to Techsoup Boost (for the price of $79 / year) will get you Quickbooks Premier 2019 for free, as well as a bigger discount on AWS credits. You can get $2,000 AWS credit for just $80. Techsoup Boost sent me a $25 promo code to use for my first purchase, making it $79 + $80 – $25 = $134 for this whole setup, and I can use the $2,000 credits to size up my instances on AWS.
I am setting up RDWeb to launch Quickbooks to make it easier for our accountant to access the desktop version. For RDweb, we will also need to purchase 1 RDS CAL license if we end up going with this approach. Another option is to have them RDP to the AWS instance directly. If that’s the case, you can just get a AWS workspace instance and install Quickbooks Desktop version there. If you do not mind the RDP approach, it will give you a bigger saving / better performance if you just use a single instance of AWS workspace.
Requirements:
- AWS account. You can register for a free tier, and apply the $2,000 AWS credit. (if you are a nonprofit)
- 3 windows EC2 instances. I built my environment with the free tier (t2.micro with 30 GB of storage). I will probably resize the Session host for better performance.
- A 3rd party SSL Certificate (I did not get this)
- RDS CAL Licenses
1st EC2 instance (TESTDC01) – We will use the Server 2019 Base AMI (t2.micro with 30GB storage to keep it free) and install the Active Directory Domain Services role. Since we only have 3 servers, we will also use the DC for RDS licensing. After configuring this server as a Domain Controller, we will create a new forest. I will call this forest corp.rdtest.com for the purpose of this guide. In a real life production environment, you may want to separate the DC and the Licensing, but putting them together will do for my case.
2nd EC2 instance (TESTQB01) – We will again use the Server 2019 Base AMI (t2.micro with 30GB storage) and join to the corp.rdtest.local domain. This will be the session host server for our Quickbooks application.
3rd EC2 instance (TESTRD01) – We will again use the Server 2019 Base AMI (t2.micro with 30GB storage) and join to the corp.rdtest.local domain. This will be our Connection Broker + RD Gateway + RD Web Access server. If you are accessing this externally, you will want to assign an Elastic IP from AWS so that it won’t change when you reboot it.
*For a deployment that is targeted for more users, you will want to add a SQL server to handle the database instead of using the windows internal database.
Step by Step guide – Part 1
- We will go ahead and install RD Licensing Server role and activate the License server first, so we can be done with the DC and do not have to come back to this step later. RDP to TESTDC01 and open up Server Manager.
This role does not require a restart. You can also do this with PowerShell. I will skip the PowerShell equivalent for the remaining of this guide and put together a PowerShell only guide for the same deployment shown here.
Once the role has been installed, you can look for “Remote Desktop Licensing Manager” from your Administrative Tools menu. Alternatively, you can type in “LicMgr” to search for it.
Right click on the Server’s name and choose to “Activate server”. Follow the prompt and fill in the information to activate the Licensing Server.
If you have the licenses available, you can go ahead and add them now, or just close it and come back later when you are ready.
Our Licensing Server is now activated and ready to use.
Unfortunately, it looks like you can only do this step from the GUI and not with PowerShell. Please let me know if you know of a way to do this from PowerShell. I wonder what people should do if they have a Server Core installed. (Starting in Server 2019, we can no longer switch between Core and GUI!)
- Next, we will go to TESTRD01 – our Remote Desktop Gateway and Connection Broker. We will need to add all three servers to Server Manager first so that TESTRD01 can install the roles and features on the other two servers remotely. Right click on “All servers” and choose to add servers. Add TESTDC01 (Domain Controller/Licensing Server), TESTQB01 (Session Host) here so we can manage them from TESTRD01.
We will then start the add roles and features wizard and choose “Remote Desktop Servies installation”.
We will choose “Standard Deployment” for this guide.
We are not deploying a VDI farm here, so we will choose “Session-based Desktop Deployment”.
We will add our TESTRD01 as the RD Connection Broker.
TESTRD01 is also our “RD Web Access Server”, so select TESTRD01 again and add it to the right.
TESTQB01 is where our Quickbooks application is installed and will be our Session Host Server for this deployment. Select TESTQB01 and add it to the right.
Confirmed the selections and check the box to restart the remote servers automatically after installing the roles.
After the installation succeeded, we will be left with two roles to configure to complete the RDS deployment. They are “RD Licensing” and “RD Gateway”. Click on “RD Licensing” to being the configuration.
Select TESTDC01, our licensing server, and add it to the right.
Confirm the selection and click on “Add” to finish adding the licensing server.
As you can see, “RD Licensing” is now grayed out and TESTDC01 appear on the right pane as RD Licensing. We are now left with only “RD Gateway” to configure.
Select TESTRD01 and add it to the right.
For it to work internally in an Intranet setting, a self-signed SSL certificate is sufficient. However, if you are going to allow external access to your RDWeb, you will either need to allow users to download the Self-Signed SSL and import the certificate to the Trusted root Certification Authorities of the client machines themselves, or you can purchase a signed SSL from a trusted 3rd party, or in some cases, you may be able to request one from your service provider.
I will use a self-signed SSL certificate for the purpose of this guide. I will name this “remote.rdtest.com”. I can later direct traffic to this subdomain to the public IP of my Remote Gateway so that when people type in https://remote.rdtest.com, they will be redirected to TESTRD01. If you choose to purchase a signed SSL certificate, you can purchase one with a wildcard, so you can reuse it for different projects. *.rdtest.com will work for remote.rdtest.com and if I have a another project, I can reuse this SSL certificate for project.rdtest.com
Lastly, we will be finishing off our deployment. We can leave the RD Gateway configuration as is for now. Go on to “RD Licensing” and select “Per User”.
Leave “RD Web Access” at default. At “Certicates”, we will need to create new certificate and select this same new certificate to apply it to all four places.
Select to “Create new certificate”. Again, we will name this certificate remote.rdtest.com. Put in a password, you will need this password again to import it to the other three services, and also when you import it to the “Trusted root Certification Authorities” of the client machines.
Hit apply and the state will change to “Success” and Status “OK”. For the next three services, we will choose “Select existing certificate” and provide the path to the .pfx file and import it by typing in the password.
Since this is a self-signed SSL, this will show as “Untrusted”. If you purchase a signed SSL, you can select that one instead and it should show “Trusted”.
As we completed our configuration for the RD Deployment, all our components are now greyed out! Our deployment is now finished. We will work on setting up the remote applications and also deploying our self-signed SSL to our internal clients so that they do not have to download and install the certificate themselves.
KennyL System Admin 