In this video demonstration we will see how to enable remote desktop feature (RDP) in Windows Server 2012 R2, as well as we will see how to connect Windows S. For months I was unable to Remote into one Server 2012r2, and followed your advice to look at Windows Firewall, Advanced Settings, and then enable the Remote Desktop rules for User Mode (TCP-in), User Mode (UDP-in) and Shadow (TCP-in).
- Windows Server
- Windows Server 2012 R2 Download Iso
- Windows Server 2012 Remote Desktop Services
- Windows Server Remote Desktop Licensing
Working in a Windows Domain environment, whether it is in the larger campus size enterprise environments or the small medium business markets, it is likely you will come across Remote Desktop Services. Remote Desktop Services rely on having a valid certificate being used by all the services on all servers, or to have a self-signed certificate that is pushed to all workstations that will be used so the connection is trusted. If the Remote Desktop Services are only utilized with internal infrastructure, then using a Windows Certificate Authority may be the best option, but as more and more employees start to work remotely to connect in a signed certificate from a globally trusted platform like Entrust, Thawte, DigiCert or GoDaddy will need to be purchased. This hammer is not geared towards code or automation, so do not expect script blocks or code to follow.
Many monitoring services available are not designed to monitor the certificate being used on many Windows services, and unfortunately many certificates are only purchased or signed for a year so every year there is a half day or more where Remove Desktop Services become unavailable until a new certificate is put in place. Whether you let the certificate lapse or you are the proactive Server or Systems Administrator you are, the same process applies. There are currently no pictures, if that is what you were hoping for. With enough requests we will update this post with some imagery generated by the fine Techs with their Hammers. This hammer is geared more to a server admin with at least some experience maintaining a Windows environment as a tier 1 help desk analyst should not be
Here at Tech With a Hammer we are geared to the small and medium business size markets, and as such many business either will not have the resources available or no need to have an on-premises Windows Certificate Authority so we will be covering the signing SSL signing process at online Certificate Authorities with a generated Certificate Signing Request, and how to utilize this certificate in Microsoft Remote Desktop Services. The To re-iterate, the process is the same for a new or renewed certificate.
High availability for the RD Connection Broker is also improved in Windows Server 2012 Remote Desktop Services. Part one: Breaking down RDS roles. What's remote access? Simplifying VDI deployment with RDS. What a VMware pro thinks of RDS and RemoteFX. Quiz: How much do you know about Windows Server 2012 RDS? 2: Domain Controller, Print server, WSUS server. 3: Remote Desktop Services. Users do not have admin rights. We run IE, Chrome, Firefox for browsers, plus Office 2016. At any one time, I'll see 4-6 users logged in during business hours. Server specs: Dell Poweredge 2950. Dual Quad Core Xeons at 3.16 GHz. 64 GB ram on the host.
For a Globally Trusted Certificate Authority
For this example, GoDaddy will be used as much of our work is aimed at the small-medium business markets so they will not be willing to buy spend 4x the money or more at Thawte or Entrust. The process is similar, though where they need you to verify ownership of the domain the process will be slightly different though each certificate authority has clearly defined processes in place and how to documentation which we would highly recommend following as that process can and will change after this post is published to the Internet.
In GoDaddy, when you purchase an SSL certificate it is not assigned to a domain or keyed at the time of purchase. This is all done after the initial purchase is created. So, purchase your new certificate, whether it is a new or renew it is the same process. Once purchased you will need to generate a Certificate Signing Request.
To generate the Certificate Signing Request multiple tools can be used, OpenSSL being open source and used almost everywhere, Certificate Management Console built into all Windows operating systems, or the easiest being Internet Information Services which is installed with the Remote Desktop Services role set on your server. This hammer will cover the process through IIS due to easy of use for single name certificates, though if requiring additional names as subjectAltNames then either OpenSSL or the Certificate Management Console will be needed.
On the Remote Desktop Service server running the Connection Broker service open up the IIS Management console, under the page for the server name select Server Certificates and then under actions click on Create Certificate Request. The common name, or subject name, is the FQDN of the domain name used to connect. Common domains are remote.domain.tld, secure.domain.tld, service.domain.tld, while you can have your user connect to hammer.domain.tld or whaleblubber.domain.tld if you want to practice security by obscurity (as everyone knows security by obscurity works). For all information be as accurate as possible, if you are renewing a cert that has been issued stick with the same information used for all other parts as the old cert unless they need to be updated.
We have used the information in the figure below for this post only, so all details pertaining can be safely ignored but enter in the information as accurately as possible.
The Country needs to be in two letter international format, you may need to look up your country code if you do not know it.
Upon clicking next you will notice you have a few options with your algorithm and key size, we here at Tech With a Hammer would recommend choosing elliptical duffie-hillman with a keysize of at least 4096 bits, but unfortunately Microsoft services do not work with the elliptical keys yet so sticking with Microsoft RSA is sufficient. We have found that there have been compatibility issues when selecting anything higher than 4096 bit key length, some online certificate authorities are unable to accept anything larger, as well some older software or operating systems are unable to use keys larger than 4096; though we have questions as why you would be still letting Windows XP without a service pack installed connect to your network.
To finish off the CSR process you will need to save the request to a text file, save this request to a secure location on your server, the larger the keysize the longer it will take to generate the request. It is highly recommended that this folder is not on a network share, with the default NTFS ACLs adjusted so only the user account being used to maintain the certificates can access the folder. The contents of the file will be used to sign the certificate from your online Certificate Authority. If you look at the file you will notice it is just a couple of flags to denote beginning and end of the certificate, and then a blob ob base64 encoded text, should look similar to the following blob.