Publishing Remote Desktop Services on UAG

by Shijaz Abdulla on 22.02.2010 at 22:22

If you’re trying to publish Remote Desktop Services or RemoteApp on Microsoft Forefront Unified Access Gateway 2010, and if you encounter the following error, read on:

“Your computer can’t connect to the remote computer because no certificate was configured to use at the Remote Desktop Gateway server. Contact your network administrator for assistance”.


Before we look into how to fix this, we need to understand how RDS publishing works with UAG:

  1. A UAG client accesses a Forefront UAG portal using a Web browser and evaluating the endpoint compliance and session access policies defined on UAG by the administrator.
  2. The end user launches a Remote Desktop application in the portal. The portal uses the RDS ActiveX component to activate the RDC client software running on the endpoint. If the ActiveX component doesn’t exist, it is installed.
  3. The RDC client on the endpoint initiates an RDP-over-HTTPS connection with the Forefront UAG server.
  4. The HTTPS connection terminates on the Forefront UAG server. Forefront UAG uses its integrated RD Gateway to handle the connection. Forefront UAG verifies that the user logged on to the portal successfully, and was authenticated using a session cookie, and then enforces the endpoint access policies.
  5. An RDP session is established from Forefront UAG to the backend RDS hosts.

As you can see in step 3 and 4, the HTTPS connection terminates on the Forefront UAG server, which also acts a Remote Desktop Gateway. The error appears because no SSL certificate is configured by default on the RD Gateway running on the Forefront UAG computer.

The Solution

  1. On the computer running UAG, open the RD Gateway Manager (Administrative Tools > Remote Desktop Services > Remote Desktop Gateway Manager)


  2. You will see that “A server certificate is not yet installed or selected”. Click on View or modify certificate properties

  3. Choose the option Select an existing certificate from the RD Gateway <computername>. Click the Import Certificate button.
  4. Choose the certificate that matches the public DNS name of your UAG portal. In my case it is – this is the URL that users connecting from outside your organization will type into the browser to get into the UAG portal. It can be the same certificate that you are using on your HTTPS trunk.


  5. Click Import and OK.
  6. Try to connect to the RDS Session Host from the UAG portal. It should work (if you have configured the application and your endpoint is compliant with the endpoint security policies that you defined).

“RPC Server is unavailable” error when requesting a certificate

by Shijaz Abdulla on 06.02.2010 at 00:29

While trying to request a certificate using the Certificates MMC snap-in on a computer running ISA Server, Threat Management Gateway (TMG) or Unified Access Gateway (UAG), you may encounter the following error:

“The RPC Server is unavailable”


This may be caused due to the RPC Filter in ISA Server/TMG. The RPC filter ensures security by monitoring RPC traffic flowing through the firewall. DCOM traffic is also dropped by this filter. However, DCOM is required to request a certificate.

To workaround this problem, disable strict RPC compliance setting on ISA Server/TMG. Here’s how to do it:

  • Right click on Firewall Policy and choose Edit System Policy .
  • Under Authentication, select Active Directory configuration group
  • Uncheck the Enforce Strict RPC Compliance option.


  • Click OK and apply your changes.

Of course, you will also need to create a firewall policy rule to allow all traffic from Localhost to Internal. Once you have requested the certificate you can revert these changes.


You can now request certificates from your ISA Server/TMG computer!

Internal transport certificate expired

by Shijaz Abdulla on 27.01.2009 at 16:47

January 27, 2009

The internal transport certificate is automatically generated at the Exchange Server 2007 hub transport server and is usually valid only for one year. Once the certificate expires, you will receive continuous event 12019 errors in your Edge transport servers that are subscribed via Edgesync.

Event Type:      Error
Event Source:    MSExchangeTransport
Event Category:  TransportService
Event ID:        12019
Date:            1/27/2009
Time:            4:46:34 PM
User:            N/A
Computer:        EDGETRANSPORT
The remote internal transport certificate expired. Certificate subject: CN=<hub transport server>.

You can generate a new SMTP transport certificate on the Hub transport server by running the New-ExchangeCertificate cmdlet with no arguments.


This will automatically generate a new certificate. You then need to restart the Microsoft Exchange Edgesync service so that the Edge transport servers will be informed of the change.

Certificate name mismatch in Outlook while running Exchange Server 2007

by Shijaz Abdulla on 10.04.2008 at 13:56

If you have installed Exchange 2007 Client Access Servers in your organization, and if you have installed your SSL certificates (even commercial ones) on IIS, Outlook MAPI users may receive ‘Security Alert’ messages similar to the above in Outlook.

The name on the security certificate is invalid or does not match the name of the site.

This is because of the certificate that you have installed on IIS. Outlook 2007 MAPI clients use Client Access Servers for the Autodiscover service. The Autodiscovery web service (a virtual directory on the Client Access Server) is used for automatically finding the mailbox server for a given user. When the Autodiscover service is accessed by Outlook, and the name on the security certificate installed in IIS doesn’t match the internal FQDN of the Client Access server (CAS), this error results.

Suppose your company’s public domain name is You may have obtained a certificate for and installed on the IIS of your Client Access Server. This is correct because users on the internet will type the public name.

However, the same IIS on the CAS is hosts the Autodiscover virtual directory as well and this certificate applies. Your internal domain name might be mycmpny.local and the client access server FQDN might be CAS1.mycmpny.local. Outlooks 2007 uses this internal name to connect to Autodiscovery, and hence the mismatch error.

To fix this problem, open Exchange Management Shell and type the following commands:

Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri

Set-WebServicesVirtualDirectory -Identity “CAS1EWS (Default Web Site)” -InternalUrl

Set-OABVirtualDirectory -Identity “CAS1oab (Default Web Site)” -InternalUrl

Set-UMVirtualDirectory -Identity “CAS1unifiedmessaging (Default Web Site)” -InternalUrl

Pay attention to the text in red, you will need to change it to reflect your server’s running parameters. Recycle the MSExchangeAutodiscoverAppPool. Your users should no longer receive the security alert.

Crash-proofing the Enterprise Root CA

by Shijaz Abdulla on 08.04.2008 at 07:24

Your enterprise root CA is an important piece of your enterprise network. Especially if you issue a lot of certificates for a wide variety of purposes to your users.

A root CA also needs to be highly secured, both physically and over the network, because it contains the private key. A downtime on the root CA is seldom noticed because there is minimal need for using the server – except while issuing or renewing certificates. In fact, the Microsoft best practice is to power down your root CA when not in use.

Now, what to do if your enterprise root CA crashes? Information about the enterprise root CA is written on the Active directory, in the registry of the Windows Server hosting the CA, and most important of all, the private key is also stored on this machine.

Quite obviously, In the event of a total failure, a backup is required. Taking a backup of the root CA is often neglected. Believe me, it takes virtually no time to take a backup and it’s the only way to restore your CA with all private keys intact.

Microsoft KB Article 298138 explains how you can backup your CA and move it to separate hardware. The procedure is also applicable if the hardware running your root CA crashes totally and you want to set up the same CA on a new server hardware.

In this post, I will explain how you can automate a backup of the CA. Restoration can be done as per the article mentioned above. Write a script “backupCA.bat” with the following code:

certutil -backup D:backup
certutil -backupkey D:backup
certutil -backupdb D:backup
reg export HKLMSYSTEMCurrentControlSetServicesCertSvcConfiguration D:backupregbackup.reg

Make sure the D:backup folder is picked up by your centralized tape backup solution. Be extra careful with the tape because this contains the private key of your CA. Your organization should have the handling of tapes included in the security policy.

Internet Explorer 7: Re-release

by Shijaz Abdulla on 05.10.2007 at 12:49

Microsoft has re-released Internet Explorer 7.0 yesterday. The added features include:

  • The Menu bar will be turned on by default (thankfully)
  • Removed the Windows Genuine Advantage validation requirement for expanded availability to Windows PC users (legal copy of Windows… or otherwise)
  • For first time users, the first-run experience includes a new, easily accessible overview
  • For all users, the online Internet Explorer 7 tour has been updated to include how-to’s on great new features like tabbed browsing.
  • Microsoft has also included a new MSI installer for enterprises that simplifies deployment for customers. IT Administrators can tailor to their organization’s needs by using the Internet Explorer Administration Kit (IEAK) and deploy the package to relevant units within their organization using e.g. Group Policies or Systems Management Server (SMS).

Microsoft takes its commitment seriously in helping protect the entire Windows ecosystem. Security enhancements to Internet Explorer 7 include a built-in Phishing Filter that prevents an average of 900,000 visits per week to known phishing Web sites!

Additionally, Internet Explorer 7 is the first and only browser to natively support Extended Validation SSL Certificates to help prevent online fraud.

How can I get it?

Wildcard Certificates: My frivolous antics

by Shijaz Abdulla on 01.10.2007 at 09:31

A client wanted to publish two web services on SSL using ISA Server 2006: Outlook Web Access and Sharepoint Portal Server.

We know that ISA Server can only bind one SSL certificate per socket. This translates to one HTTPS URL/website per socket. What does this mean? Lets say I have my OWA at and I have an SSL certificate issued to I also have my Sharepoint portal at for which I have acquired a certificate with common name

While publishing, I can have only one web listener per socket and a web listener can accept at most ONE SSL certificate. If I apply the certificate on my web listener, OWA will work fine, but users browsing to will get a certificate warning/error. If I apply the certificate, users browsing to will get a certificate warning/error.

So what’s the solution? Wouldn’t it be great if we could order a certificate with common name * and use the same certificate for both (or more) websites? Yes, you can! That’s called the WILDCARD Certificate!

Ordering a wildcard certificate is fairly simple, if you know how to order a normal SSL certificate. While generating an SSL request, simply enter * as the common name for the new certificate.

Wildcard certificates have a limitation that they are not available in 128-bit SGC and available only in standard encryption. The encryption level is decided by the user’s browser, rather than the certificate. So, if you’re securing a electronic payment website or a finance-related website, a wildcard certificate may not be what you should be looking at.

Publishing internal file servers through OWA

by Shijaz Abdulla on 24.08.2007 at 13:46

Outlook Web Access (OWA) on Exchange Server 2007 now supports direct file access, which means users can connect to internal file servers over the web using the standard OWA interface.

Readers of my earlier posting on Intelligent Application Gateway 2007 will agree that, if SSL is configured on Outlook Web Access (OWA) with internal file server access enabled, and it is published using ISA Server 2006, this gives you the equivalent of a browser-based SSL-VPN connection to the file server! Think about it.

This is good news for organizations who want to publish their file servers securely for home users but cannot afford a secure VPN solution.

Similarly, users can access internal Sharepoint sites from OWA if this is enabled on Exchange Server 2007. Certainly good news for organizations that tried to publish both OWA and SharePoint server over SSL on the same ISA Server installation — and then daunted away because it meant replacing the SSL certificate a wildcard certificate (which offers weaker encryption than a normal SSL certificate).

For step-by-step instructions on how to configure direct file access, see my article Configuring direct file server access from Outlook Web Access in Exchange Server 2007

Digitally sign your email for free

by Shijaz Abdulla on 03.07.2007 at 10:05

Thawte gives away free personal email certificates at their website.

A thawte Personal E-mail Certificate in conjunction with the thawte Web of Trust allows you to secure and guarantee authorship of your e-mail communications by digitally signing and encrypting your e-mails.

IN SHORT: A personal email certificate lets you digitally sign all your outgoing email so that the recipient knows that you sent it!

Click here to get a certificate.

A word of caution here, read everything carefully whilst you apply for digital certificate. Remember the password and the question-answer pairs otherwise you will *never* be able to get another certificate for the same email ID. Also keep your password totally secret – a recipient can take you to court for documents that appear to be digitally signed by you, but was in reality signed in your name by an identity thief!