To use TS Gateway properly, the following prerequisites must be met:

You must have a server with Windows Server 2008 installed. You must be a member of the Administrators group on the computer that you want to configure as a TS Gateway server. An external trust SSL certificate must be obtained for the TS Gateway server if it has not already been obtained. By default, on the TS Gateway server, the RPC/HTTP load balancing service and the IIS service use Transport Layer Security (TLS) 1.0 to encrypt communications over the Internet between clients and the TS Gateway server. To use TLS properly, an SSL certificate must be installed on the TS Gateway server. Note If you can use other methods to obtain externally trusted certificates that meet the requirements of TS Gateway, you do not need to deploy a certification authority (CA) infrastructure in your organization. If your company does not have an independent CA or an enterprise CA, and you do not have a compatible certificate issued by a trusted public CA, you can create and import a self-signed certificate for the TS Gateway server for technical evaluation and testing. The certificate must meet the following requirements: Unless you are using a wildcard certificate or the SAN attribute of the certificate, the name in the subject line of the server certificate (Certificate Name, or CN) must match the DNS name used by the client to connect to the TS Gateway server . If your organization issues certificates through an enterprise CA, you must configure the certificate template to provide the appropriate name in the certificate request. This is not necessary if your organization issues certificates through an independent CA. The certificate is a computer certificate. The designated use of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1). The certificate has a corresponding private key. The certificate has not expired. We recommend that certificates be valid for one year from the date of installation. Certificate Object Identifier (also known as OID) 2.5.29.15 is not required. However, if you plan to use a certificate that contains object identifier 2.5.29.15, you can use the certificate only if at least one of the following key usage values ??is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE. For more information about these values, see Advanced Certificate Registration and Management (). The certificate must be trusted on the client. That is, the public certificate of the CA that signed the TS Gateway server certificate must be in the Trusted Root Certification Authorities store on the client computer. For more information about the certificate requirements for TS Gateway and how to obtain and install the certificate if you have not already done so, see the TS Gateway Step-by-Step Guide.

Also, keep the following considerations in mind:

TS Gateway transmits all RDP traffic (which would normally be sent over port 3389) to port 443 by using an HTTPS tunnel. This also means that all communications between the client and the TS Gateway are encrypted when transmitted over the Internet. For proper use of TS Gateway, several role services and features are required to be installed and running. When you use Server Manager to install the TS Gateway role service, the following additional role services and features are automatically installed and started if they are not already installed: Remote Procedure Call (RPC) over HTTP Proxy Web Server (IIS) [Internet Information Services 7.0] . IIS 7.0 must be installed and running for the RPC service on the HTTP proxy to function properly. Network policy and access services. You can also configure TS Gateway to use a Terminal Services Connection Authorization Policy (TS CAP) stored on another server that is running the Network Policy Server (NPS) service. You can use this NPS server (formerly known as the Remote Authentication Dial-In User Service (RADIUS) server) to centrally store, manage, and authenticate TS CAPs. If you already have an NPS server deployed for remote access scenarios (such as VPN and dial-up networking), you can improve your deployment by using this existing NPS server for the TS Gateway scenario as well. However, in this configuration, the NPS server is still required on the TS gateway server to act as a proxy server for the central NPS server.