Problems Accessing Windows 2008 TS Gateway RemoteApp from Windows 2003 Server RRS feed

  • Question

  • Hello,

    I'm experiencing issues accessing a providers RemoteApp from a Windows 2003 Terminal Server. The provider is running a TS Gateway on a Windows 2008 R2 server.

    After entering the https:// address I could not get past the installation of the addon of the Terminal Services ActiveX Client and could not see the RemoteApps. I was able to fix this by running an install of RDP 6.1 using Windows XP compatibility mode.

    Now when I attempt to launch an app I get the error "This computer can't connect to the remote computer because the Terminal Services Gateway server address requested and the certificate subject name do not match."
    The provider is using a wildcard certificate. They have supplied me with the certificate which I have installed to the Trusted Root Certification Authority and the automatic assigned location without success.

    I have no issues connecting to the remoteapps via a Windows XP or 2008 R2 machine so I wonder if this setup will even work and if I'm just wasting my time.

    Thanks in advance,


    Monday, March 21, 2011 3:10 AM

All replies

  • I found a forum thread with a similar issue to me

    The fix was to have a default gateway on the NIC. We already have this in place.


    Monday, March 21, 2011 11:53 PM
  • Hi,



    Have you imported this certificate into the trust root on the Windows Server 2003 (Computer Account)? And what version of RDC client you are using on the Windows Server 2003?


    Furthermore, if you find any more event log when this issue happens, please let’s know for the further research.







    Tuesday, March 22, 2011 6:34 AM
  • Hi Alan,

    Yes I have imported the certificate into the Trusted Root Certification Authority using the instructions below.

    No errors logged in eventvwr


    Install the TS Gateway Server Root Certificate on the Terminal Services Client

    Your computer must verify and trust the identity of the TS Gateway server before you can send your password and logon credentials securely and complete the authentication process. To establish this trust, the clients must trust the root of the server’s certificate. That is, clients must have the certificate of the certification authority (CA) that issued the server certificate in their Trusted Root Certification Authorities store. You can view this store by using the Certificates snap-in.

    This procedure is not required, for example, if a VeriSign or other non-Microsoft trusted public key infrastructure (PKI) certificate is installed on the TS Gateway server, and the Terminal Services client computer trusts the certificate.


    Do not install certificates from any untrusted sources or individuals.

    To install the TS Gateway server root certificate, do the following on the Terminal Services client.

     To install the TS Gateway server root certificate on the Terminal Services client


    1.   Open the Certificates snap-in console. If you have not already added the Certificates snap-in console, you can do so by doing the following:

    ·      Click Start, click Run, type mmc, and then click OK.

    ·      On the File menu, click Add/Remove Snap-in.

    ·      In the Add or Remove Snap-ins dialog box, in the Available snap-ins list, click Certificates, and then click Add.

    ·      In the Certificates snap-in dialog box, click Computer account, and then click Next.

    ·      In the Select Computer dialog box, click Local computer: (the computer this console is running on), and then click Finish.

    ·      In the Add or Remove snap-ins dialog box, click OK.

    2.   In the Certificates snap-in console, in the console tree, expand Certificates (Local Computer), expand Trusted Root Certification Authorities, right-click Certificates, point to All Tasks, and then click Import.

    3.   On the Welcome to the Certificate Import Wizard page, click Next.

    4.   On the File to Import page, in the File name box, specify the name of the TS Gateway server root certificate, and then click Next.

    If you created a self-signed certificate as described in Appendix A of Windows Server “Longhorn” Community Technology Preview (August 2006) Release TS Gateway Server Step-By-Step Setup Guide and installed this certificate on the client, the name of the root certificate that appears in this list would be <COMPUTERNAME> Test Root.

    5.   On the Password page, if you specified a password for the private key associated with the certificate earlier, type the password.

    6.   On the Certificate Store page, accept the default option (Place all certificates in the following store -Trusted Root Certification Authorities), and then click Next.

    7.   On the Completing the Certificate Import Wizard page, confirm that the following certificate settings appear:

    ·      Certificate Store Selected by User: Trusted Root Certification Authorities

    ·      Content: Certificate

    ·      File Name: FilePath\<Root_Certificate_Name.cer>, where <Root_Certificate_Name> is the name of the TS Gateway server root certificate.

    8.   Click Finish.

    9.   After the certificate import has successfully completed, a message appears confirming that the import was successful. Click OK.

    10. With Certificates selected in the console tree, in the details pane, verify that the root certificate of the TS Gateway server appears in the list of certificates on the client.

    Thursday, March 24, 2011 2:04 AM
  • And we are using RPD 6.1 on the Windows 2003 server. I installed the KB952155 by changing install to Windows XP compatibility mode.

    Thursday, March 24, 2011 2:06 AM
  • Does this issue happen on your internal network when using Windows Server 2003 to access to the application on the RD Web page?


    Also, do you use the FQDN which completely matches certificate name to access to the application?






    Friday, March 25, 2011 2:27 AM
  • Hi Alan,

    The application is external to our network. Hosted by another vendor.

    The certificate uses a wildcard. So the certificate is for * and the server hosting the application is called

    This is not the real certificate/host names. Just using as an example.



    Friday, March 25, 2011 3:18 AM
  • Hi Darren,

    I'm having exactly the same problem. Have been looking for the solution a while now but so far no luck. Continue to do so but would like to know did you ever find a solution?

    Thanks B

    Tuesday, December 18, 2012 11:10 AM