About: The purpose of this document is to detail a problem that should rarely be encountered under normal circumstances (unlikely to manifest in non-highly restricted environment), but which is annoying enough, and difficult enough to troubleshoot, that it merits having its own dedicated page.

The problem and its context: Establishing an RDP connection takes some 15-20 seconds; that is, after the point were the credentials are provided to, and accepted by, the remote server and before being presented with the remote desktop session, during which time the RDP client's status messages are of the

Securing remote session...

and

Configuring remote session...

variety. Subsequent connections are slightly faster in establishing. The problem manifests in the context of the source system not having access to update.microsoft.com and the target server employing a self-signed certificate for securing its RDP connections - it turns out that, in such a situation, the source system will time-out attempting to contact Windows Update, to interrogate it about the existence of the "apparent CA" that has signed the target server's certificate, or perhaps to simply check if a newer variant of the Root CA store exists, which would possibly include this "new CA" (this appears to be a failure in logic on the part of the code responsible for the behaviour, as it does not capitalize on the difference between a self-signed certificate and one signed by an actual third party Certification Authority).

For an exact description of the problem, see KB2915774; for more details about the described mechanism, see this Technet article section and this Technet description of the CAPI 2 source's EventID #8.

Solution: The quick fix to the problem is to disable the mechanism responsible with interrogating Windows Update when encountering a certificate which cannot be validated based on the system's current Root CA store, which can be achieved by using the Local Policy Editor (gpedit.msc), navigating to Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings\Turn off Automatic Root Certificates Update and enabling the policy in question.

Corollary: The proper fix for such an issue, especially in a production environment, is using certificates issued by a proper third party CA and making sure that the system initiating the connection has the CA's certificate(s) installed in its respective certificate store(s).