1. RDWebAccess.Config
and
by default, the “Remote Desktop” will connect to FQDN of the local RD Server.
Category Archives: Terminal
LAB–Remote Desktop SSO with RDGW
==================================================================
http://blogs.msdn.com/b/rds/archive/2009/08/11/introducing-web-single-sign-on-for-remoteapp-and-desktop-connections.aspx
Web SSO with RD Gateway
Web SSO also works when RemoteApp programs are set to use RD Gateway regardless of whether RD Web Access accesses RemoteApp programs in RD Session Host mode or RD Connection Broker mode.
The configuration of Web SSO for RD Gateway assumes that:
- an RD Gateway is deployed
- a ‘Connection Authorization Policy’ is set to use password for the users connecting
- and the RD Gateway server is used by RemoteApp programs
More details on how to configure a ‘Connection Authorization Policy’ on RD Gateway can be found here.
The step below is needed regardless of the mode RD Web Access is configured. In case of RD Connection Broker mode, the step needs to be performed on each RD Session Host server which is added as a RemoteApp Source on RD Connection Broker Server.
Membership in the local Administrators group (or equivalent) on the RD Session Host server that you plan to configure is the minimum requirement to complete each of the following steps.
- On the RD Session Host server, open RemoteApp Manager. To open RemoteApp Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click RemoteApp Manager.
- In the Actions pane of RemoteApp Manager, click RD Gateway Settings. (Or, in the Overview pane, next to RD Gateway Settings, click Change.)
- Select the Use these RD Gateway server settings.
- In the Server name box, click the FQDN of the RD Gateway server.
- In the Logon box, select the Ask for password (NTLM).
- Select the Use the same user credentials for RD Gateway and RD Session Host server check box.
- Click OK to close the RemoteApp Deployment Settings dialog box.
Web SSO in Windows Integrated Authentication
If RD Web Access is configured to use Windows Authentication, which is the Windows Server 2008 mode, instead of the default Forms Based Authentication (FBA), users will be prompted for credentials twice: once for the Windows Integrated Authentication for RD Web Access and again on the launch of the first RemoteApp in the RemoteApp and Desktop Connection. Thereafter on subsequent RemoteApp launch, SSO will work as it works in the FBA mode.
==================================================================
http://blogs.msdn.com/b/rds/archive/2007/05/04/single-credential-prompt-for-ts-gateway-server-and-terminal-server.aspx
LAB–Remote Desktop Per User CAL Revoke
官方講了這篇，per user CAL 不可revoke
http://technet.microsoft.com/en-us/library/cc732416.aspx
非官方的說可以改attribute 
2.495 Attribute msTSExpireDate
http://msdn.microsoft.com/en-us/library/cc220557(v=prot.13).aspx
LAB: RemoteDesktop–Script to Generate Per User CAL Report
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/567c380e-4d2f-4cb4-8df5-34575669d6d7
When a person leaves your company if you delete their AD user account the count of Per User RDS CALs in use will decrease automatically.
A RDS Per User CAL expires after 60 days of not being used. What this means is that if you have a user account that has not logged on to one of your RDSH servers in the last 61 days they will not show up on the Per User CAL Usage report.
The above are implementation details of Per User RDS license tracking. I will leave it up to you to decide what complies with the license agreement. For example, what is the definition of permanently? If an employee switches departments, does not use your RDSH servers for a year, and then starts using them again did you violate the EULA (assuming you reassigned the CAL)? Perhaps you would say no in this example. What about if the same thing happens for only a month duration? Or a week? Or a day? At some point a reasonable person would say that you did not permanently reassign the license.
Just food for thought. I would not worry about it much if you are not frequently reassigning CALs from one user to another and then back again. Maybe the definition of permanently is at least 60 days? By the way, Permanent Per Device RDS CALs are valid for 52-89 days, perhaps that is the definition.
http://blogs.msdn.com/b/rds/archive/2009/11/09/per-user-cal-reporting-script.aspx
http://gallery.technet.microsoft.com/ScriptCenter/9739eaee-fb8a-4cb8-8456-7f138d175934/
When to use this script
1. For a Windows Server 2003 Terminal Server, there is no issuance of Per User (PU) CALs. Hence the customers also have no idea about the number of PU CALs to be purchased. Also, they are not aware of the number of users that have logged in to a given terminal server over a period of time. This script will help them address these needs.
2. For a Windows Server 2008 Terminal Server or a Windows Server 2008 R2 Remote Desktop Session Host Server, the inbox License Manager PU reporting feature only shows CALs that are currently valid. It does not give any data about the PU CALs which were issued earlier but now expired. This script helps the admin track expired CALs as well.
3. For a license server running Windows Server 2008 or Windows Server 2008 R2, there is a bug causing PU reporting with ‘All Trusted Domain’ scope to fail even if one of the domains in the trusted domain list is unreachable. This script will report the PU CAL usage for all the reachable domains.
4. For a license server running Windows Server 2008 or Windows Server 2008 R2, the admin cannot get the PU CAL usage report for a list of domain(s). This script enables admins to enter a number of specific domain name(s) and generates CAL usage details for those domain(s).
Usage of the script
cscript PerUserCALReport.vbs <option> [DomainFQDN1] [DomainFQDN2] [DomainFQDN3] …
Where ‘option’ can be either of the following –
/W2K3 – for tracking usage trend of Windows Server 2003 Per User (PU) CALs for a given domain(s)
/W2K8 – for tracking both valid & expired Windows Server 2008 PU CALs for a given domain(s)
/All – for combined details of both the above
‘DomainFQDN’ – optional switch – should be in the format of mytestdc.nttest.microsoft.com. If no parameter is specified, the current domain is assumed.
Here is the usage of the script for the common scenarios it addresses:
(1) Tracking the users connecting to a terminal server running Windows Server 2003 for a given domain(s).
To get the details of the users connected to the terminal servers running Windows Server 2003 in a given domain(s) at a given instant, use this script with /W2K3 option.
cscript PerUserCALReport.vbs /W2K3 [DomainFQDN]
(2) Tracking of total usage of Windows Server 2008 PU CALs issued (both valid & expired) for a given domain(s).
cscript PerUserCALReport.vbs /W2K8 [DomainFQDN]
(3) Tracking of CALs in specified domains (e.g. in a trust of 20 domains, you want to know the CAL usage in only 2 of them).
cscript PerUserCALReport.vbs /All [DomainFQDN1] [DomainFQDN2]
(4) Tracking of CALs across multiple domains where some of them could be unreachable (e.g. in a trust of 20 domains, out of which 5 are unreachable and you want to know the usage in the rest of the 15 domains which are reachable).
cscript PerUserCALReport.vbs /All [DomainFQDN1] [DomainFQDN2] … [DomainFQDN20]
Sample Output
cscript PerUserCALReport.vbs /ALL
For Domain: TS-A25D.cotoso.corp.com – Number of W2K8 CALs – Valid: 3 Expired: 2 Total: 5
For W2K8 User details of domain: TS-A25D.cotoso.corp.com please refer to the file TS-A25D.cotoso.corp.com.W2K8UserDetails.csv saved in the current directory.
For Domain: TS-A25D.cotoso.corp.com – Number of W2K3 Users – Active: 4 Stale: 0 Total: 4
For W2K3 User details of domain: TS-A25D.cotoso.corp.com please refer to the file TS-A25D.cotoso.corp.com.W2K3UserDetails.csv saved in the current directory.
Limitations
(1) This script cannot distinguish between valid and expired Windows Server 2008 Per User (PU) CALs issued to a Windows Server 2003 user object.
(2) In case of tracking Windows Server 2003 PU CAL usage trend, the result provided by this script might deviate +/- 10% from the actual result, depending on the frequency and interval with which it is scheduled.
(3) In a heterogeneous deployment of terminal servers running both Windows Server 2003 & Windows Server 2008 (or Windows Server 2008 R2), there could be users who might need to connect to both types of terminal servers. A user having Windows Server 2008 PU CAL is authorized to connect to a terminal server running Windows Server 2003 as well. In that case, the list of users (who have connected to a terminal server running Windows Server 2003) provided by the script, might contain some users, who have been already issued a Windows Server 2008 PU CAL & therefore don’t need to purchase a Windows Server 2003 PU CAL. To identify whether a given user has already a Windows Server 2008 PU CAL issued or not, you need to run the script with /W2K8 option for the domain, which the user belongs to.
LAB: Modify RD web desktops.aspx
Change default RDWeb to RemoteDesktopConnection instead of RemoteAPP
change default.aspx to desktop.aspx from login.aspx
remove computer name
before – const string L_DefaultComputerNameValue_Text = "Computer Name";
after – const string L_DefaultComputerNameValue_Text = "";
before – type="text" onkeydown="jscript:checkKey(this);" onkeyup="jscript:checkLen(this, 1);" />
after - type="text" onkeydown="jscript:checkKey(this);" onkeyup="jscript:checkLen(this, 1);"value="rd.msft.com" />
before – <button type="button" id="ButtonConnect" name="ButtonConnect" disabled class="formButton" onclick="BtnConnect()" accesskey=<%=L_ConnectAccessKey_Text %>><%=L_ConnectLabel_Text %></button>
after – <button type="button" id="ButtonConnect" name="ButtonConnect" class="formButton" onclick="BtnConnect()" accesskey=<%=L_ConnectAccessKey_Text %>
change default.aspx to desktops.aspx
Ticket: RemoteAPP certificate revocation check error
.
certutil -f –urlfetch -verify <your_certificate>.cer
From internet client (Win7 ultimate x64)
Issuer:
CN=TWCA Secure CA -Evaluation Only
OU=SSL Certification Service Provider-Evaluation Only
O=TAIWAN-CA INC.
C=TW
Subject:
CN=deep2.msft.com
OU=ITS
O=Msft Corporation
L=Taipei
S=Taiwan
C=TW
Cert Serial Number: 04bd
dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
——– CERT_CHAIN_CONTEXT ——–
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
CertContext[0][0]: dwInfoStatus=2 dwErrorStatus=1000040
Issuer: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
NotBefore: 6/20/2011 2:03 PM
NotAfter: 7/19/2011 11:59 PM
Subject: CN=deep2.msft.com, OU=ITS, O=Msft Corporation, L=Taipei, S=Taiwan, C=TW
Serial: 04bd
bb 06 52 a5 52 b1 62 b4 8d 2c e4 e3 75 56 a1 10 d4 61 c7 95
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
—————- Certificate AIA —————-
No URLs "None" Time: 0
—————- Certificate CDP —————-
OK "Base CRL (099c)" Time: 0
[0.0] http://sslserver.twca.com.tw/sslserver-test/revoke11_test.crl
—————- Certificate OCSP —————-
No URLs "None" Time: 0
——————————–
Issuance[0] = 2.16.886.3.1.3.999
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
bb 06 52 a5 52 b1 62 b4 8d 2c e4 e3 75 56 a1 10 d4 61 c7 95
Missing Issuer: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
Issuer: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
NotBefore: 6/20/2011 2:03 PM
NotAfter: 7/19/2011 11:59 PM
Subject: CN=deep2.msft.com, OU=ITS, O=Msft Corporation, L=Taipei, S=Taiwan, C=TW
Serial: 04bd
bb 06 52 a5 52 b1 62 b4 8d 2c e4 e3 75 56 a1 10 d4 61 c7 95
A certificate chain could not be built to a trusted root authority. 0x800b010a (-2146762486)
————————————
Incomplete certificate chain
Cannot find certificate:
CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
Cert is an End Entity certificate
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
CertUtil: -verify command completed successfully.
=====================================================
Another result from Remote Desktop server with Trusted root & Intermediate Certification Athorities
Issuer:
CN=TWCA Secure CA -Evaluation Only
OU=SSL Certification Service Provider-Evaluation Only
O=TAIWAN-CA INC.
C=TW
Subject:
CN=deep2.msft.com
OU=ITS
O=msft Corporation
L=Taipei
S=Taiwan
C=TW
Cert Serial Number: 04bd
dwFlags = CA_VERIFY_FLAGS_ALLOW_UNTRUSTED_ROOT (0x1)
dwFlags = CA_VERIFY_FLAGS_IGNORE_OFFLINE (0x2)
dwFlags = CA_VERIFY_FLAGS_FULL_CHAIN_REVOCATION (0x8)
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
——– CERT_CHAIN_CONTEXT ——–
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
NotBefore: 6/20/2011 2:03 PM
NotAfter: 7/19/2011 11:59 PM
Subject: CN=deep2.msft.com, OU=ITS, O=msft Corporation, L=Taipei, S=Taiwan, C=TW
Serial: 04bd
bb 06 52 a5 52 b1 62 b4 8d 2c e4 e3 75 56 a1 10 d4 61 c7 95
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
No URLs "None" Time: 0
—————- Certificate CDP —————-
Verified "Base CRL (099c)" Time: 0
[0.0] http://sslserver.twca.com.tw/sslserver-test/revoke11_test.crl
—————- Base CRL CDP —————-
No URLs "None" Time: 0
—————- Certificate OCSP —————-
No URLs "None" Time: 0
——————————–
CRL 099a:
Issuer: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
e0 b8 a7 68 72 d9 7f b7 5a 04 90 c0 ae b0 f4 bb 0e 79 7d 35
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
NotBefore: 12/9/2010 1:49 AM
NotAfter: 10/1/2016 12:47 AM
Subject: CN=TWCA Secure CA -Evaluation Only, OU=SSL Certification Service Provider-Evaluation Only, O=TAIWAN-CA INC., C=TW
Serial: 072744b8
23 f2 70 6a 7f 72 ce 49 73 9c fb e1 fa ae c5 ad fc a3 64 97
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
No URLs "None" Time: 0
—————- Certificate CDP —————-
Verified "Base CRL (a2)" Time: 11
[0.0] http://cdp1.public-trust.com/CRL/Omniroot2025.crl
—————- Base CRL CDP —————-
No URLs "None" Time: 0
—————- Certificate OCSP —————-
No URLs "None" Time: 0
——————————–
CRL a2:
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
e3 19 28 54 52 08 45 e0 2f 8a 76 3f 58 d2 bc 95 f9 20 be dd
Issuance[0] = 1.3.6.1.4.1.6334.1.0
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.4 Secure Email
CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
NotBefore: 5/13/2000 2:46 AM
NotAfter: 5/13/2025 7:59 AM
Subject: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Serial: 020000b9
d4 de 20 d0 5e 66 fc 53 fe 1a 50 88 2c 78 db 28 52 ca e4 74
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
No URLs "None" Time: 0
—————- Certificate CDP —————-
No URLs "None" Time: 0
—————- Certificate OCSP —————-
No URLs "None" Time: 0
——————————–
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.4 Secure Email
Exclude leaf cert:
5f 6d 29 1d d5 15 be a1 ce e4 ff 97 7b 60 33 1b 49 41 64 63
Full chain:
ed ab 08 78 02 67 e4 57 65 13 f0 38 43 e5 a0 4e e9 04 09 26
————————————
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
========================================================
KB931125：根憑證更新 [2011 年 3 月]
http://www.microsoft.com/downloads/details.aspx?FamilyID=3a027078-4cd7-4b27-9837-3d7e58dd5a89&displayLang=zh-tw
更新根憑證
此功能的作用
更新根憑證功能會連絡線上 Windows Update 服務，查看 Microsoft 是否已新增憑證授權單位至其信任授權單位清單，不過只有在程式提出由非直接受信任的憑證授權單位 (未儲存在電腦信任憑證清單中的憑證) 所發出的憑證時才會進行。 如果憑證授權單位已新增至 Microsoft 的信任授權單位清單中，則該憑證授權單位的憑證將會自動新增至電腦上的信任憑證清單中。
收集、處理或傳輸的資訊
更新根憑證會將要求傳送到線上 Windows Update 服務，要求取得 Microsoft 根憑證計劃目前的根憑證授權單位清單。 如果清單中列出不受信任的憑證，更新根憑證會從 Windows Update 取得該憑證，並將其放在電腦上的信任憑證存放區中。 所傳輸的資訊包括根憑證的名稱和密碼編譯雜湊。Microsoft 不會使用此資訊來識別您的身分或連絡您。
如需 Windows Update 和隱私權的詳細資訊，請參閱 Update Services 隱私權聲明。
使用資訊
Microsoft 會用這些資訊更新電腦上的信任憑證清單。
選擇與控制
更新根憑證預設是啟用的。 系統管理員可以設定「群組原則」來停用電腦上的更新根憑證功能。
其他資訊
如果您提交了一份由未直接信任的根授權單位所發出的憑證，而且電腦上並未安裝更新根憑證元件，此時您將無法完成驗證所需的動作。 例如，您可能無法安裝軟體、檢視已加密或以數位簽署的電子郵件訊息，或使用瀏覽器來進行加密的工作階段。
================================================
How to refresh the CRL cache on Windows Vista
http://blogs.technet.com/b/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx
Certutil –urlcache crl
Certutil –getreg chain\chaincacheresyncfiletime
certutil -setreg chain\ChainCacheResyncFiletime @now
================================================
Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1)
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d
===============================================
Manual update CRL on Windows 7 client, failed
============================================
Final solution
http://support.microsoft.com/kb/2203302/en-us
Consider the following scenario:
- You have a computer that is running Windows 7, Windows Server 2008 R2, Windows Vista or Windows Server 2008.
- You try to establish a Remote Desktop Protocol (RDP) connection to a terminal server on this computer.
- The RDP connection is configured to use Secure Socket Layer (SSL) authentication and Credential Security Support Provider protocol (CredSSP).
In this scenario, the RDP connection fails.
Notes
- This issue occurs when the server certificate on the terminal server is issued by an intermediate certification authority (CA) without the authority information access extension.
- In Windows 7 and Windows Server 2008 R2, the "Terminal Services" is renamed as "Remote Desktop Services."
Back to the top
The CredSSP protocol does not provide the certificate chain information that is embedded in the server certificate. This problem occurs if the following two conditions are true:
- The server certificate is issued by an intermediate CA that is embedded in the root CA.
- The server certificate does not contain authority information access extensions that enable dynamic download of the chain information.
In this situation, the CertGetCertificateChain function cannot retrieve the full certificate chain of the server certificate. Therefore, the RDP connection fails.
================================================
Disable-WSManCredSSP
http://technet.microsoft.com/en-us/library/dd819469.aspx
C:\PS>Disable-WSManCredSSP -Role Server
LAB: Server 2008 R2 Remote Desktop–SSO between RDWA & RDSH
The quest for Remote Desktop Services Web Access Single Signon
Introducing Web Single Sign-On for RemoteApp and DesktopConnections (Terminal MSDN)
Enable RDC Client Single Sign-On for Remote Desktop Services (only for RDC)
Single sign-on between RD Session Host and RD Web Access
Single sign-on allows customers the ability to enter their user name and password only once when connecting to a RemoteApp program by using RD Web Access.
Why is this change important?
Prior to Windows Server 2008 R2, when a user connected to a RemoteApp program by using RD Web Access, the user was prompted for credentials twice. One set of credentials was used to authenticate the user to the RD Web Access server and the other set was used to authenticate the user to the RD Session Host server hosting the RemoteApp program. Asking for the same user credentials twice led to a bad user experience. In Windows Server 2008 R2, you are only prompted once.
.gif)
Important
Single sign-on requires that your RDP files are digitally signed by a trusted publisher. The certificate used to sign the RemoteApp programs must be present in the Trusted Root Certification Authorities store on the client computer.
Are there any dependencies?
To take advantage of the new single sign-on features, the client must be running Remote Desktop Connection (RDC) 7.0.
Ticket: RDP An Error occurred in the Licensing Protocol
Vista Home or other version can’t connect BQT-TS01 (TS 2000),
But can connect to BQT-TS03 (server 2008 R2 Remote Desktop)
"遠端電腦中斷的工作階段的連線,
因為授權通訊協定發生錯誤,
請試著在連線到遠端電腦一次"
http://support.microsoft.com/kb/187614/en-us
Backup then delete below key
Thirty-two bit RDP clients store their license under the key
HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing.
After delete whole MSLicensing , can connect BQT-TS01, but BQT-TS03 can’t.
After reboot, TS 2000 worked.
LAB: Remote Desktop Serve 2008 R2– WIN7 Starter Client
Install Root_CA
LAB: Remote Desktop Serve 2008 R2– WIN7 Pro Client
WIN7_PRO_X64_ENG
====================================================
After change certificate of RDSH to default generate
==================================================== ![image_thumb[55]](http://lh6.ggpht.com/_2UAd2Gdlq7Y/TdSKBOEt1kI/AAAAAAAAOcw/yRWdNli2JeE/s1600-h/image_thumb553.png "image_thumb[55]")
====================================================
RDC without RootCA
Johnnyyao WorkSpace Backup Site 