none
An authentication error has occured (Code: 0x607) RRS feed

  • Вопрос

  • Hi all,

    This one is driving me NUTS! The problem itself is when I go to connect to a session host using a web access server I get the error in the title.  This is only happening to some of my session hosts and not all.  I have compared them and can't find a single difference.  I also cant find anything useful in the event logs about this.  Below is my setup.

    A full RDS environment using all Windows Server 2012 Data Center.  Nothing 2008 R2.  All Clean installs.

    I have 6 servers a VM's split evenly between 2 ESXi 5.1 Hosts.
    1. MP-RDP-CB1.inucoda.net (Connection Broker 1)
    2. MP-RDP-CB2.inucoda.net (Connection Broker 2)
    3. MP-RDP-GW1.inucoda.net (Gateway Server 1)
    4. MP-RDP-GW2.inucoda.net (Gateway Server 2)
    5. MP-RDP-WA1.inucoda.net (Web Access Server 1)
    6. MP-RDP-WA2.inucoda.net (Web Access Server 2)

    inucoda.net is an network that is the Domain that all servers are joined to via 2 Domain Controllers splits between each ESXi Host.
    My outside domain that you can get to from the web is ucoda.net

    The connection brokers have all servers used including session hosts added to the server pool and are configured in HA mode. They use a SQL Server 2012 Fail-over cluster that is on a separate set of VMs for their database and the DNS is configured as round robin. MP-RDP-CB.inucoda.net.  There are two entries of this each with one of the two IPs of the CB1 and CB2 servers.

    On each CB server there is a RDS License server role installed with CALs installed and activated/registered. Both LIC servers have been added to the RDS deployment properties.

    The GW servers each have the NLB role installed with an extra network adepter for NLB use. There is a DNS name of MP-RDP-GW.inucoda.net that points to the NLB IP of the GW Cluster.  Also both GW servers were added to the GW Server Farm part of the the GW properties.  

    The WA servers are also in a NLB Cluster with an extra adapter and a DNS of MP-RDP-WA.inucoda.net pointing to the NLB IP.

    Up steam from our inside Windows Domain at our ISP level there is a DNS entry of MP-RDP-WA.ucdoa.net and it points to the NLB IP of the WA NLB Cluster.  (This is not a public IP, we require you be on our VPN to be able to access the IP).

    For certificates we have a Comodo issued wildcard of *.ucoda.net with the corresponding Comodo Root Trust and Intermediate Certs. We also have a wildcard *.inucoda.net created by our inside CA.

    The *.inucoda.net cert is used for the CB SSO, CB Publishing, and GW while the *.ucoda.net cert is used for the WA.

    All session hosts have been configured to use the *.inucoda.net for their RDP sessions.

    I can confirm that the *ucoda.net cert is used for the WA part and all other parts are reporting the *inucoda.net, all with no errors or warnings.

    For each session collection only one session host is used with no apps, (just RDP).  Security is set to only use NLA, SSL 1.0, High.

    On each session host I have verified that the *inucoda and *ucoda certs are installed and the internal CA and Comodo CA/Intermediate CA is installed in the correct stores.  I have also verified that COM Security has the domain\TS Web Access group set with full perms for the Access and Launch/Activation. Also for WMI  Root\CMIV2\TermicalServcies Security has the domain\Ts Web Access group set with full perms. Lastly each group/user that has access to RDS is listed in the Remote Desktop users.

    I've checked that both WA servers are listed in the TS Web Access group.

    The GW servers RAS/RAP policies are set to be pretty open for testing with using any port, any network resource, and Domain Users and Domain Admins listed.

    I have been trying to connect with Windows 8 and Windows 7 clients as the domain\administrator account.  Some of my session hosts connect fine and other don't .  It's always the same ones that connect and don't connect.  I can't find any difference  between the.   I've also blown away my entire RDS and started over with just a 3 server single node model with no NLB or RR DNS and the same exact error happens on certain servers.  I have sense gone back to the 6 server setup described here and again the same error on the same session hosts.

    I have also tried Negotiate and RDS Compatible and disabling NLA only for security.  No change.  Now here is the interesting part. If I remove GW servers from RDS by just saying not to use them (not actually uninstalling them or anything), all session hosts connect just fine every time.  When I first did my RDS setup I got he same error with code 0x607 for every connection attempt and found i had to set the RAS/RAP to use any network resource instead of Domain Computers.  However, it is currently set like that and some still don't connect.   So it works with out the GW servers just fine.  It also works without them in the 6 node setup as well as the 3 node setup. 

    I don't want to use it without the GW servers because since I am using all inside subnets with a VPN I have to add the CB IP/Name to my host file or it will not resolve and give an error about reaching the Connection Broker. Because I want to use a HA setup this is no good as there are two servers for it.  That's why I use the NLB IP of the WA and publish it with outside DNS with our ISP. 

    Any ideas at all??

    Thanks,
    Chris

    4 декабря 2012 г. 2:30

Все ответы

  • Hi,

    Thanks for your post.

    In order to troubleshoot, you may enable event log to record RD gateway connection status. Location is Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\. For more detailed information, you may refer to the following article. Hope it helps.

    Specify Remote Desktop Gateway Events to Log

    http://technet.microsoft.com/en-us/library/cc772215.aspx

    Monitoring a Remote Desktop Gateway Server for Connection Status and Reporting

    http://technet.microsoft.com/en-us/library/cc772447.aspx

    Best Regards,

    Aiden

    If you have any feedback on our support, please click here


    Aiden Cao
    TechNet Community Support

    5 декабря 2012 г. 5:23
    Модератор
  • Hi,

    Thanks for the help in locating logs related to the Gateway and other TS stuff.  I tried to connect to one of my session hosts that does not work and after the error I checked the logs on Gateway, Connection Broker, and Session Host servers. 

    On my Gateway I see the following:

    The user "INUCODA\Administrator", on client computer "192.168.100.5", met connection authorization policy requirements and was therefore authorized to access the RD Gateway server. The authentication method used was: "NTLM" and connection protocol used: "HTTP".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", met resource authorization policy requirements and was therefore authorized to connect to resource "MP-RDP-CB.INUCODA.NET".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", connected to resource "MP-RDP-CB.INUCODA.NET". Connection protocol used: "HTTP".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", connected to resource "MP-RDP-CB.INUCODA.NET". Connection protocol used: "UDP".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", successfully connected to the remote server "MP-RDP-CB.INUCODA.NET" using UDP proxy. The authentication method used was: "Cookie".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", met resource authorization policy requirements and was therefore authorized to connect to resource "192.168.180.4".

    The user "INUCODA\Administrator", on client computer "192.168.100.5", connected to resource "192.168.180.4". Connection protocol used: "HTTP".

    The IP 192.168.100.5 is my DHCP VPN IP for the client system that I was trying to connect to a session host. The 192.168.180.4 is the IP of session host.   S to me everything looks good there.  I was able to access the Gateway, Connection Broker, and the Session Host.

    The logs form the Connection Broker are as follows:

    Remote Desktop Connection Broker Client received request for redirection.
    User : INUCODA\Administrator
    RDP Client Version : 5

    Remote Desktop Connection Broker Client successfully redirected the user INUCODA\Administrator to the endpoint MPCA.INucoda.net.
    Ip Address of the end point = 192.168.180.4

    RD Connection Broker successfully processed the connection request for user INUCODA\Administrator. Redirection info:
    Target Name = MPCA
    Target IP Address = 192.168.180.4
    Target Netbios = MPCA
    Target FQDN = MPCA.INucoda.net
    Disconnected Session Found = 0x1

    Again everything looks good to me here.  It correctly accepted and redirected the the RDP to the Session Host.  I looked at the logs for the Web Access Server and Session Host and both were worthless.  I could not find anything that showed the connection being made or any errors/warring about anything.  The security log for the Session Host shows some normal Audit Success logs with the inucoda\administrator user.  Nothing that looked bad.  From the logs that I have found everything looks like it is working fine, but yet it is not

    Thanks,
    Chris

    9 декабря 2012 г. 2:37
  • Update on the issue.  I have been using my Windows 8 PC with newer RDP 8.0 for testing as a client.  I tested on a Win 7 SP1 RDP 7 (mstsc.exe 6.2 i think) and it works fine.  No errors getting to any session host.  After do a win update to RDP 8.0 it gets the same authentication error.  So I know it is related to RDP 8 while 7 is working.

    Chris

    11 декабря 2012 г. 2:02
  • Hi,

    Thanks for your update.

    Check to see if anonymous authentication is disabled for the default website on RD gateway? If so, re-enable it and test.

    Best Regards,

    Aiden

    If you have any feedback on our support, please click here


    Aiden Cao
    TechNet Community Support

    11 декабря 2012 г. 2:36
    Модератор
  • Hi,

    I checked and it is currently enabled. 

    Thanks,
    Chris

    13 декабря 2012 г. 22:01
  • I'm very confused about 2012 RDSH.  I have an rd gateway that is also running rdweb and rdcb.  I then have a 2012 session host with a published desktop.  On a Windows 8 client I can connect without any certificate mismatch squawking (even though the rd.domain.local name of the server appears in the RDC window).  But on a Windows 7 machine I get multiple cert squawks and have to enter my credentials an extra time despite having already authenticated via rdweb.

    I followed the instructions to change the rd cert to my external wildcard cert (same one on the rd gateway) but now I can't connect from any client getting the 0x607 error.  I must be missing a step.

    Why didn't microsoft do it like citrix where the client simply authenticates to the gateway and the gateway in turn authenticates to the internal servers behind the curtain?

    16 декабря 2012 г. 20:06
  • Well I believe in theory that is what it's suppose to do and behave like.  Letting the Gateway handle all the inside authentication.  I have also noticed that I get two login prompts when I'm using a Win 7 client.  Only the Win 8 client goes through with just one.  But for me I get the mysterious 0x607 error that seems pretty much undocumented right now when using any Win 8 client or Win 7 with the newer RDP update.  

    As far as the cert warning you need to set the cert for each component under development options (Gateway, Web, and two diff ones for CB).  They need to match the domain name.  I assume your external domain name is different from your internal windows domain name (like my setup).  If so then a cert with the external name needs to be used for the Web Access and then a cert with the internal name for all other components.  I use a wild card from a commercial CA for my external and a wild card from my internal CA for my inside domain.  However, there is a warning about only using the same cert for both Rd Web and Gateway if the roles are installed on the same system like yours.  That means you cant use the external cert for the RD Web and the internal cert for the Gateway. (I have no idea why!) It will let you but warns against it. So you're stuck using one for both and that will cause a cert mismatch at some point. It should let you connect but issue a warning.  In the end that is why I separated all my roles to individual VMs.  Of course we don't all have the luxury to setup 40 million serves just to manage and authenticate RDP!!!

    As for the authentication error.  I found that for me I had to modify the default RAP and RAS policy on the Gateway server to allow Any Network Resource.  I think the default is any Domain Computer.  I had to change it because our clients connecting do not sit inside the windows domain and are on a VPN to connect to the IPs of the RDS stuff.  The VPN issues a DHCP IP address of 192.168.100.0 to the clients and that subnet does not exist in the domain so you have to say allow any network resource. 

    So far I'm still stuck with my 0x607 error on any Win 8 or updated RDP client and a double login for Win 7. 

    17 декабря 2012 г. 22:23
  • Double login sounds like SSO is not working or you are directed to the web server and needing to re-authenticate. Have you checked logs on win 8 client machine to see if it complains about security settings connecting to Webserver. http usually isn't using a cert. Sounds like the client itself is causing the issue and not the servers, windows 7 just auth twice but gets through? is there a way you can change rdp 8 to use a less secure connection? double auth usually means your hitting a server authenticating then being redirected to another session host server... 
    18 декабря 2012 г. 1:05
  • The Win7 clients are getting double Auth and get through just fine.  The Win 8 only get one Auth but fails.  I recently just did all available updates to each RDS server.  Now Im getting a new error from both Win 7 and 8.  The logs on the GW show it authenticating ok and allowed to access the requested resource and then connecting to the CB.  The CB has an event error:

    Event 1296.

    Remote Desktop Connection Broker Client failed while getting redirection packet from Connection Broker.
    User : INUCODA\Administrator
    Error: Remote Desktop Connection Broker is not ready for RPC communication.

    Ive tested ping and nslookup for everything and its fine.  So now im lost again.  Thinking about scrapping it all and starting over.

    There are no other error in the event log, just this during a redirection attempt. 

    Chris

    18 декабря 2012 г. 2:39
  • Bruce, why would Win7 clients (and mac with itap client) get prompted to auth again, when windows 8 and windows RT clients don't?
    And why are Win7 clients seeing the cert mismatch on the internal RDSH server, when win8/RT do not?
    • Изменено Wes Wes Wes 18 декабря 2012 г. 17:01
    18 декабря 2012 г. 17:00
  • I followed the steps here to assign my wildcard cert to the RDSH server: http://blog.skadefro.dk/2012/08/windows-server-2012-server-8-remote.html

    Now win7 clients (although still getting prompted to auth a 2nd time) can get in without the cert squawk... but win8 clients get the 0x607 error again.  Ugh.  Can't win.

    18 декабря 2012 г. 17:57
  • I followed the steps here to assign my wildcard cert to the RDSH server: http://blog.skadefro.dk/2012/08/windows-server-2012-server-8-remote.html

    Now win7 clients (although still getting prompted to auth a 2nd time) can get in without the cert squawk... but win8 clients get the 0x607 error again.  Ugh.  Can't win.

    That's a good guide, I found it when I did my setup as I was baffled on how I no longer could set the cert for the session host like you can in 2008/R2.  I had to do that on each session host. 

    Well here is an update to my situation.  After my recent set of windows update to all related RDS servers I got that new error I mentioned on the CB server not redirecting anything.  I decided to scrap it all and I removed every RDS role from every system and started over.  I left my NLB stuff alone.  This time around with the exact same setup as my first post I am now able to login just fine with my Win 8 clients.  No more stupid 0x607 error.  I did not change anything and this is my third scrap and redo of it all.  The only thing different is on the third redo all the servers had a series of new updates that were not installed during the first two attempts.  

    For Win 7 clients I do a windows update to get the two updates related to the newer RDP version that Win 8 uses and they work just fine with SSO now.  So in the end I'm not sure what fixed it besides the possibility of the latest updates on the server side.

    Chris

    18 декабря 2012 г. 21:04
  • So I should be able to simply change the cert on all my RDSH servers to my wildcard *.domain.com certificate and it should work?  I don't have to do anything else?
    18 декабря 2012 г. 21:07
  • So I should be able to simply change the cert on all my RDSH servers to my wildcard *.domain.com certificate and it should work?  I don't have to do anything else?

    That is what I did to get rid of the cert mismatch warnings.  Otherwise it uses a default computer name cert.  As long as your wildcard cert matches the domain name that the RDSH servers are on then it should be good.  As for the 0x607 error I never really figured out what fixed it for me. Could be a combination of my windows updates and scraping and redoing the RDS environment.  I imagine if you run the windows updates for RDP on your Win 7 clients updating them the Win 8 version that it will resolve the 2x auth issue but then you will probably get the 0x607 error.  That's what happened to me until i did my updates and redo and now it all magically works.

    It's been a real pain!

    18 декабря 2012 г. 23:38
  • We have updated (installed all Windows Updates) our environment last Monday. Since then about 5% of our customers are unable to connect to the RDS farm.

    They all get the error 0x607. All of them use Windows 7. From clients using Windows XP we did not get complaints.

    But not all clients using W7 are unable to connect. On my computer there is no problem. I also have installed all updates.

    It is also not a problem of only one Web Access Server or Gateway. A customer gets the error while I can connect over the same server without problems.

    I think it is a combination of server updates/client updates and client configuration.

    Did anyone have the same problem and knows how to solve it?

    Thank you very much!

    20 декабря 2012 г. 10:24
  • Update: A customer has told me that he has installed all optional Windows updates. After a restart, he could connect. At this time I do not know if it's a temporary problem or if it's fixed because of the updates.
    20 декабря 2012 г. 13:13
  • Pesospesos, well I would think windows8 clients aren't getting past the first sign on as win8 rdp client is probably set to not connect and not warn if cert does not match. I've seen this where rdp clients are set to either connect without warning about cert mismatch or another selection to not connect at all..... they sign in to GW server which directs them to CB then CB directs them to RDSH server of choice. Win 8 clients I believe are signing in to GW server but find a cert mismatch and drop connection while win7 clients are allowed to connect if cert mismatch.
    21 декабря 2012 г. 18:19
  • Hi Bruce, that's fine - but the fact remains that we need this to work on xp/vista/win7/win8.  Why would microsoft break downlevel clients?  I understand them not getting to take advantage of performance features, remotefx, etc...  But the very basic connectivity needs to be there.  This is a big mess and appears to be very poorly documented thus far...
    21 декабря 2012 г. 18:22
  • Pesospesos,

    I agree with you the documentation is flawed and does not work as it is written. Have you checked event logs on client machines when they fail? I am curious to see what the client has to say about the failed connection.

    Have you setup SSO on the RDSH servers?

    To implement single sign-on functionality in Remote Desktop Services, ensure that you meet the following requirements:

    • You can only use single sign-on for remote connections from a computer running Windows 7, Windows Vista, or Windows XP with Service Pack 3 to an RD Session Host server running Windows Server 2008 R2 or Windows Server 2008. You can also use single sign-on for remote connections from one server running Windows Server 2008 R2 or Windows Server 2008 to another server running Windows Server 2008 R2 or Windows Server 2008.
    • Ensure that the user accounts that are used for logging on have appropriate rights to log on to both the RD Session Host server and the client computer.
    • Your client computer and RD Session Host server must be joined to a domain.

    To configure the recommended settings for your RD Session Host server, complete the following steps:

    • Configure authentication on the RD Session Host server.
    • Configure the client computer to allow default credentials to be used for logging on to the specified RD Session Host servers.

    Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.

    To configure authentication on the RD Session Host server
    1. Open Remote Desktop Session Host Configuration. To open Remote Desktop Session Host Configuration, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.

    2. Under Connections, right-click the appropriate connection (for example, RDP-Tcp), and then click Properties.

    3. In the Properties dialog box, on the General tab, verify that the Security Layer value is set to either Negotiate or SSL (TLS 1.0).

    4. On the Log on Settings tab, ensure that the Always prompt for password check box is not selected, and then click OK.

    After you configure authentication on the RD Session Host server, you must allow default credential usage on the RD Session Host server by using Group Policy. The Group Policy settings can be found inComputer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security and can be configured by using either Local Group Policy Editor or the Group Policy Management Console (GPMC).

    What do the GW and CB have in the event logs for the failed connections? all info you have can help to resolve this, I had a 2008 r2 RDSFarm setup with SSO, they used a wildcard cert that had all farm members local fqdn's and the FARM fqdn in the cert (this cert was installed in the trusted certificate store on the client systems), My CB was installed on one of the Farm members and this member did client redirection for me, I gave it a relative weight of 50 and the second RDSH server 100 weight, you would allow all connections on the CBRDSH server and allow reconnections on the second rdsh server. Make sure all users are on both servers local remote desktop users and remote desktop is enabled on the computer properties, allow less secure connections, and make sure your policies are not checking health of the clients, and allow all connections. Try again and please post logs from the client, CB, GW, and RDSH if they log anything. We can get this !!! :_) 

    21 декабря 2012 г. 19:15
  • Thanks Bruce :-)  Trying to free up more time to spend on this project - so much going on at the moment.  Just to be clear, my servers are all 2012.

    I guess I don't understand why the client has to see/know about the RDSH at all.  Isn't the whole point of the gateway to obfuscate that from the client and keep things secure/simple?

    21 декабря 2012 г. 19:18
  • You are correct the client should not know about the RDSH server, however if you want a secure connection to the RDSH server that is able to encrypt and compress data across the wire a Certificate with the required settings is your only way. Remember you want the SERVERFARM.domain.com and all RDSH local fqdn remote1.domain.local, remote2.domain.local names that will be hosting remote sessions for the clients. Make sure you also have this cert imported from the RDS GW configuration settings as well as iis and local cert stores. 

    To install a certificate on the Remote Desktop Gateway server
    1. On the RD Gateway server, open Remote Desktop Gateway Manager. To open Remote Desktop Gateway Manager, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Gateway Manager.

    2. In the Remote Desktop Gateway Manager console tree, right-click the local RD Gateway server, and then click Properties.

    3. In the Properties dialog box for the RD Gateway server, on the SSL Certificate tab, click Import a certificate into the RD Gateway<RD Gateway Server Name> Certificates (Local Computer)/Personal store, where <RD Gateway Server Name> is the name for the computer on which the RD Gateway server is running.

    4. Click Browse and Import Certificate.

    5. In the Open dialog box, click the certificate that you want to use, and then click Open.

    6. In the Enter Private Key Password dialog box, in the Private key password box, enter the password for the certificate, and then click OK.

    7. In the Certificate Import dialog box, click OK.

    8. Click OK to close the Properties dialog box for the RD Gateway server.

      If this is the first time that you have mapped the RD Gateway certificate, after the certificate mapping is completed, you can verify that the mapping was successful by viewing the RD Gateway Server Status area in Remote Desktop Gateway Manager. Under Configuration Status and Configuration Tasks, the warning stating that a server certificate is not yet installed or selected and the View or modify certificate properties hyperlink are no longer displayed.

    The client should not know about the local rdsh server but connect to the rdsfarm (rds farm name not the local rdsh server name) which is published in dns as round robin. I am pretty sure you have this setup but make sure to check all rdsh services and see if they are running along with rpc services, check your rdp ports are opened on the firewall, and that the certificate is on the clients store as a trusted certificate. I'm curious if you ping your CB's, GW's and WA servers what type of replies you are getting. How are you handling ip addressing for the clients. Check the ping setup see if you can hit ip and fqdn, then see which server from the ha's reply, try connecting to the server that replied and see if this server is the one that accepts all incoming connections on all adapters. I haven't even touched the vpn connection you have setup, are you able to resolve fqdn's on the vpn? how is vpn authenticating? do you have a local radius server? I guess I will wait for the first set of questions to be answered before I start a book of questions for your holiday vacation :P   Good luck and hope to hear soon....

    21 декабря 2012 г. 21:32
  • I am having the same problem as the original poster and have had no luck configuring a Windows RT tablet to work with our infrastructure.

    I have an external endpoint, I shall call it rd.example.com for which we have acquired a valid SSL/TLS certificate from a CA.  We have a single server running the Connection Broker, Web Access and Gateway roles accessible via rd.example.com, with two NICs on that server, one exposed to the public and one internally, and the firewall configured to allow RD Gateway and RD Web Access through publicly.

    When attempting to connect to a Remote Desktop Session Host, with an internal name of rdsh.example.com, the windows RT client receives the 0x607 authentication error when connecting via RD Web Access, and a more generic error when connecting through the Windows Store "Remote Desktop" application.

    I have verified that the client is connecting on the gateway, and the connection negotiation seems to work fine up until some very last steps, it determines the quality of the connection and other things, then suddenly stops.

    I have also tried to set the Remote Desktop certificate of rdsh.example.com to the same certificate on rd.example.com, but this did not resolve the issue. (I had to use wmic to set the certificate.)

    4 января 2013 г. 19:51
  • Well, it's back!!!  My 607 error was resolved by just re doing the whole thing.  Now its back and happening on every RDSH.  Again I can connect with Win7 using two login prompts ok but Win8 or updated RDP on Win7 always fails with 0x607 error.  Nothing in event logs that help.  I'm about ready to contact MS pro per incident support on this.  If I get anywhere with that I will post updates to a solution.

    5 января 2013 г. 9:00
  • I've followed this thread with interest because we’ve had the problem with the 0x607 error too. But now I think it finally has been resolved. At least it hasn’t appeared anymore for more than a week.

    For us the problem was with the certificate on the session host servers. I’m not sure why it should make problems, because it should be enough for the clients to communicate with the gatewayserver.

    First we started out with nothing but default certificate on the session host servers. Then we tried with a certificate from a CA. It was installed ok, but had only the collectionname (e.g. collectionx.dot.com) as common name.

    After I ordered and installed a new certificate from a CA for the session host servers with both the collection name and subject alternative name (e.g. collectionx.dot.com, collectionxserver1.dot.com, collectionxserver2.dot.com, collectionxserver3.dot.com, ..) there were no more 0x607 errors.

    To install the new certificate I used mmc.exe - Certificates to copy the certificate to Remote Desktop on each session host server and followed the instructions from

    http://serverfault.com/questions/444286/configure-custom-ssl-certificate-for-rdp-on-windows-server-2012-in-remote-admini to configure a custom certificate.

    ($path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path

    Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="THUMBPRINT"})

    Hope this can be of some help.

    22 января 2013 г. 10:28
  • Hi All,

    I'm the original poster and if you have been following this I was never fully able to get things working.  Sometimes it would just work and other times it would just fail with the 607 error.  I have finally got it all working for over a week now with multiple systems using it!  Below is a rather large explanation of what I had to do and what I learned about RDP.   I've included links to guides that helped a lot. 

    First a small recap of my environment.

    Using all windows server 2012.
    Using two Gateways, Connection Brokers, and Web Access servers.
    Two domain names, ucoda.net for external connection via web to web access servers and inucoda.net to inside windows domain that all servers are members of.
    No external client systems are domain members, all just workstations.
    Using two wildcard *.domain certs for both domain names.
    External wildcard cert is from Comodo CA and internal wildcard cert is from my internal CA.

    Now for how I setup the RDS environment.

    I used this guide for setting up high availability of the connection brokers. 
    http://blogs.msdn.com/b/rds/archive/2012/06/27/rd-connection-broker-high-availability-in-windows-server-2012.aspx

    I used a back end SQL Server 2012 that was configured in a two node failover cluster for maximum HA.  As you can see by the guide it uses round robin DNS for load balancing the two CBs and does not require any hardware or software NLB.  

    For both the two gateways and web access servers you need to use some kind of NLB.  You can use the MS NLB to create a virtual Cluster IP and set a DNS record for you gateway and web access name to point to that cluster IP. HOWEVER!  If you are in a virtualized vmware environment as I am then you have some other things to do.  I can not comment as to Hyper-V setups, only vmware on ESXi-5.1.  If you use MS NLB then you must use it in Multicast mode and not Unicast. You must also setup static ARPs on your Layer 3 router/firewall and Layer 2 switches.  The static ARP should match the NLB cluster IPs to the NLB Cluster MAC address.  Below are the guides for a Cisco Cat switch and ASA firewall.

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006525
    http://www.cisco.com/en/US/docs/security/asa/asa84/asdm64/configuration_guide/mode_fw.html#wp1224694 see adding a static arp section.

    Now in the end I still was not fully happy with MS NLB as it is not Layer 7 aware and can only check the network health.  So I ditched my MS NLB for a linux solution. HAProxy.  It is a software NLB that is Layer 7 aware and easy to setup. I used two Ubuntu Server 12 VMs with 1 GB RAM, 8GB HDD, and 1 vCPU each.  I also used Keepalived to setup virtual cluster IPs for HAProxy to use with failover.  so the HAProxy NLB is in high availability mode as well.

    Setup HAProxy on Ubuntu
    http://www.networkinghowtos.com/howto/compile-haproxy-from-source-on-ubuntu/

    Configure HAProxy and Keepalved
    http://leowadsworth.com/blog/2012/02/21/high-availability-load-balanced-web-servers-using-ubuntu-10-04-haproxy-keepalived-apache/ Skip the install part and see just the config parts for HAProxy and Keepalived. 

    Now once NLB is done and you have DNS pointing to it you need to add both Gateways to a Gateway Web Farm.  Not required for the Web Access Servers only the Gateways.  for the Web Access server you only need NLB with a common DNS.  

    Setup Gateway Farm
    http://technet.microsoft.com/en-us/library/cc732370.aspx

    Also as my client systems are not a part of the domain and have different subnets I needed to set the gateway RAP and CAP to allow users to connetc to any network resource.

    Now that the main configuration was done and running I had to fix/fine tune/and mess with a bunch of other things!

    There should be a domain user group account called TS Web Access Computers.  It should be populated with the Web Access server computers.  However in my deployment it was empty! great.  However, I also found other documentation that states it should be populated with the Gateway servers.  So for me I added both Gateways, Web Access, and Connection Broker Servers.  I figured it can't hurt.

    Now this group account needs to be added to COM security and WMI security for terminal services.  Below is a guide for both of these. I applied this configuration to every single system including all session hosts. 

    http://technet.microsoft.com/en-us/library/ee891251%28v=ws.10%29.aspx

    Now something interesting. Most of my systems were all server 2012 but a few were 2008R2 that had been upgraded in place to 2012.  For these systems the above config is till needed but you will find on the local systems user groups a TS Web Access Computers group.  This is not in the local groups for 2012 but got merged over from 2008 R2.  So for it I also added the domain\TS Web Access Computers group to the local TS Web Access Computers group and added the local one to COM and WMI security as well.

    Further into local user groups. On all systems in the deployment there is a local RDS Management Server group and it should have both Connection Broker servers listed.  I found this to be true on all my session hosts but on the Connection Brokers them self they only have their own server listed but not the other connection broker server.  I added both to each.  I also found a few of my systems had a third ? SID account listed that was no longer was a real account in the domain.  I removed it. Possibly from how many freaking times I had to re do my setup. 

    Now on the Connection Brokers local group accounts there is a RDS Remote Access Servers group.  It should have all the Gateway and Web Access Server listed here.  In my setup I found only the Web Access Servers were listed and no Gateways.  GREAT! This only needs to be populated on the Connection Broker Servers. There is also a RDS End Point Servers group and it should have every Session Host server listed.  Again only needed on the Connection Brokers.

    That concludes user accounts/groups.

    Now onto the fun land of Certs!

    Something you need to make sure works is Revocation Checks!!!!!! It needs to pass from both the external client systems and internal server systems.  I had two certs used.  I used my *ucoda.net (external) for my Web Access Server Deployment and my *inucoda.net (Internal) for The Gateway and both Connection Broker parts. 

    My external was issued by Comodo so it passed rev checks just fine.  While my internal was issued from my internal CA and needed some work.  For the internal servers it could pass a rev check fine as it used the LDAP path in the CRL CDP part of the cert.  However my clients are external and not part of the domain.  So it can't use LDAP.  To check rev checks I used:

    certutil -f –urlfetch -verify <your_certificate>.cer

    You can download it for Windows 7 and 8 systems from:
    http://www.microsoft.com/en-us/download/details.aspx?id=7887 win 7 
    http://www.microsoft.com/en-us/download/details.aspx?id=28972 win 8

    To get it to pass on my client systems I had to add a CRL CDP http point that they could access instead of the LDAP point. In short on you internal CA you need to add a CRL that uses the FILE path to publish rev lists to a file share.  The file share is located on a server that has IIS and public access.  You then create a virtual directory with read rights to the that share in IIS and add a CRL HTTP point using the external FQDN of public web server for the CRL site.  Below is a guide to do all of this.

    http://blogs.technet.com/b/configmgrteam/archive/2009/05/01/how-to-publish-the-crl-on-a-separate-web-server.aspx

    Now once this is done you need to re generate a new cert and apply it to your RDS environment so it has the updated CRL CDP.

    Now after this I was able to pass using certutil tool.  But! wait there's more!  When I tried to connect to a server using normal RDP (not the full web access and gateway deployment), just direct to the end server I still got the warning about a rev check fail! I just didn't get it!  After a ton of researching it appears that RDP will only use LDAP and OCSP CDPs and not HTTP.  Great!  So while it passes the rev check from the tool it still fails for RDP. 

    So next was to add a OCSP CDP and Online Responder.  I chose to add the Online Responder role to my public web server where I had just added the HTTP CRL CDP.  Below are a few guides about setting this up and configuring your CA to use it.

    http://www.windowsitpro.com/content1/topic/online-certificate-status-protocol-ocsp-in-windows-server-2008-and-vista--103523/catpath/security
    http://blogs.technet.com/b/askds/archive/2009/06/24/implementing-an-ocsp-responder-part-i-introducing-ocsp.aspx
    http://www.sysads.co.uk/2012/10/install-and-configure-ca-online-responder-ad-cs-part3/

    I fond all helpful.  Now here comes a part that drove me NUTS!.  All these guides show that after installing the Online Responder role it automatically adds a ocsp webapp to IIS!  This is to be the CDP point you add to the CA. THIS IS NOT TRUE FOR 2012!  It does not add the IIS config what so ever.  Luckily I manged to find this:

    certutil -vocsproot  

    You need to run that command on the web server where you installed the Online Responder role.  It will add the IIS config and app pool!

    Now once this is all done and tested you need to re issue the cert again so it has the new OCSP CDP in it and install it in RDS deployment.

    Finally after this I received no rev check errors for RDP!

    Some more things on certs.

    For all my servers I installed the internal and external cert to their computer personal store and made sure the corresponding root and intermediate root certs were installed in the correct stores.  I also did this on my external client systems.  Be sure to add your internal CA's root cert to the trusted root store of you client systems or again the certs generated from it will not pass fully as the client system will not know to trust the CA that issued the cert.

    Now you also need to install a cert for each session host to use for RDP.  I really recommend wildcards as it much easier to just use a *domain cert for RDS deployment and install it on each session host for RDP than to have unique ones for each session host.  You use to be able to easily add a RDP cert in 2008R2 to a session host.  This is now gone in 2012.  So to do it you need to use the power shell.  Below is  guide on how to do this.

    http://blog.skadefro.dk/2012/08/windows-server-2012-server-8-remote.html

    Now I also used a little utility to help check that my certs were installed on each server correctly. I found on a few of my servers where one of my certs was missing the private key or had other problems.  This free tool from DigiCert can help and can also be used to test certs for rev checks.

    https://www.digicert.com/util/

    Lastly there is the issue of what RDP version you are using.  For me my systems they are all server 2012.  I found the only way to get SSO to fully work without a 2nd login prompt was to update all my Windows 7 RDP clients to the latest RDP. 

    http://blogs.msdn.com/b/rds/archive/2012/10/23/rdp-8-0-update-for-windows-7-sp1-released-to-web.aspx

    Well after all that I was able to access every RDSH in my environment without a single error!  It has been a ridiculously long and pain full journey.  I think MS needs to do more work and documentation of  2012 RDS as it's changed so much, needs a better way to issue session host certs for RDP instead of just the power shell, and needs more documentation and clarity on RDP rev checks.   I hope this helps others and if anyone wants to see what my configs look like for HAProxy if they decide to use it feel free to ask.

    Thanks and Good Luck!
    Chris


    • Изменено sparticus13 4 февраля 2013 г. 8:59
    4 февраля 2013 г. 8:58
  • Hi!

    I had same issue, i spent week solving this issue, even i cross checked with all links u have given, still couldn't find exact solution.

    But, i have found solution but its not the correct way i would say. Edit the session collection properties and in "security" change "Encryption level" to low. and save session collection. And try to access that session collection from win 8 or win7 sp1, voila, it solves issue except one warning.


    SaM

    • Предложено в качестве ответа Anton Karlan 26 июня 2013 г. 5:36
  • For RDP 8.0 client, you need to make sure that your client PC has: "Network security: LAN Manager Authentication level to Send NTLMv2 response only". This will resolve the problem.

    You can run gpedit.msc to make the change, if your GPO set it something else, you may need to update your GPO. For test, you can change registry

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]

    "lmcompatibilitylevel"=dword:00000003

    and test it before new GPO update happen.

    Jibin


    Jibin Peng

  • Any updates about 607 issue?

    Now we temporary set Encryption level to Low in our collection Security settings, but another warning appeared. It's not good!

  • Any updates on 0x607 issue?
    We seem to have it aswell, but only for external usage and the common OS is Win8.

    Some Win7 have 0x607 issue aswell.


    Regards

    8 июля 2013 г. 14:42
  • Hi everyone.

    Here's what worked for me (in 0x607 scenario with remote apps launched through RD web). I hope it helps someone.

    (But first let me vent some of my accumulated frustration by noting that any previous experience in deploying and administering remote desktop environments, managing SSL certificates, group policies and such on OS-es older than Windows Server 2012 seems to be a major hindrance.)

    In my setup everything works just fine for remote apps launched through RD web (with encryption intact, no warnings, no 0x607, different internal and public domain name) if RD session host uses a self-signed SSL certificate automatically created when deploying RD session host role.

    This is what I did to get RD session hosts bugged with 0x607 to work:

    • removed RD session host from collection,
    • deleted certificates from computer personal store on RD session host (this was plausible in my scenario),
    • removed RD session host role,
    • redeployed RD session host role from central RD administration.

    This created a fresh self signed SSL certificate for internal RD session host FQDN and assigned it to RDP-tcp. Interestingly, that certificate doesn't even appear in RD session host personal certificate store...

    (When accessing full desktop of RD session host - through RD web or by local RDP file - there is a warning that certificate was not issued by a trusted authority but the connection succeeds. This is not an issue for me as only administrators access RD session host full desktop.)

    And here is some additional background that may help you decide if this is applicable to your situation.

    My problems started when I upgraded a small group of Windows Server 2008 R2 machines to Windows Server 2012 R2 (this is not relevant by itself).

    The group consists of one machine acting as RD gateway, RD session broker and RD web, and two machines acting as RD session hosts configured in a farm. My external and internal domain names are not identical but I previously managed to configure all servers (and all RD roles) with a single public name SSL certificate issued by GeoTrust (no wildcard, no SANs, just a single name - this only required some well documented internal DNS tweaks). Session hosts served remote apps to end users with no issues whatsoever regarding encryption or SSL certificate. Session hosts were accessed directly (full desktop session) by their internal names only for administrative purposes in which occasions name mismatch warning between computer name and farm name in SSL certificate presented no problem.

    However, after the upgrade all my remote apps were plagued by 0x607 on Windows 8 clients if encryption was enabled on RD collection. As these servers are accessed by various external users over the internet I couldn't mandate placing my internal CA into every client Trusted Root CA store. I started considering renaming my domain internally from internal to public name and using a wildcard certificate from trusted CA. Last step before that was somewhat desperate as I was tinkering with alternate computer names on additional virtual RD session host I set up for testing. At one point I used netdom to make the alternate name into primary which went so bad that I had to remove this machine from domain, rename it and rejoin it, remove all certificates from it and redeploy RD session host role. At that point 0x607 suddenly went away for that machine...

    Note: If you try to configure RDP-tcp properties with certificate issued for RD session host internal FQDN by your internal CA - you will also get 0x607 unless you import your internal CA certificate to Trusted Root CA store on all clients and make certificate revocation information publicly available (which weren't acceptable options for me).

    Regards,
    Tomislav


    • Изменено Tomislav Š. _ 31 января 2014 г. 2:37 Minor correction of environment description
    • Предложено в качестве ответа Gorokhovsky 20 октября 2015 г. 8:55
    31 января 2014 г. 2:31
  • There was another forum that had a similar situation and proposed solution that worked for me. After looking and thinking about it, I was able to offer up an explanation. This solution is applied to the second server in the farm.

    "The reason this happens and partly why the solution was to change values or delete keys is probably something along these lines. When I followed Loin75's suggestion of deleting a key

    "ISSUE: Users unable to connect externally when session lands on session host 2 , it gives error 0x607

    RESOLUTION: HKLM/SYSTEM/currentcontrolset/control/terminalserver/winstations/RDP-TCP , removed SSLBinding"

    I took a look at the key that was being deleted since I was having a user with the same issue. The SSL binding that is attached to the registry is a SHA-1 binding. As we have seen of late, SHA-1's are now being rejected by modern Web Browsers so when a user uses Google Chrome or Mozilla Firefox for instance, that web browser using the web feed hits the server that has the SHA-1 registry entry and you end up with the authentication error. We have SHA-2 certs for our site so I am wondering if this is something that Microsoft does when setting up the host farm. This seems like a more logical conclusion then it is a known issue."


    • Предложено в качестве ответа SpiffyIT88 15 сентября 2015 г. 21:07
    • Изменено SpiffyIT88 15 сентября 2015 г. 21:07
    15 сентября 2015 г. 21:07
  • Sad story, struggled with your (exact) problem for weeks. We are a CSP partner with a lot of support options and none delivered. I just found out what goes wrong with the 0x607 error is actually due to certificates being present in the personal store @ computer level. 

    Delete your wildcard and/or local certificates from that store that involve RDSH servers. Problem instantly goes away (and can be reproduced). Mostly has something to do with how the certificates got added, doing a simple thing as a manual import can screw up your RDSH. 

    Hope this helps, problem (my side) has vanished with this fix 11 servers that had this problem. Problems remaining : 0

    Good luck !


    A ounce of prevention is better then a pound of cure.

    16 июня 2016 г. 15:51
  • Sad story, struggled with your (exact) problem for weeks. We are a CSP partner with a lot of support options and none delivered. I just found out what goes wrong with the 0x607 error is actually due to certificates being present in the personal store @ computer level. 

    Delete your wildcard and/or local certificates from that store that involve RDSH servers. Problem instantly goes away (and can be reproduced). Mostly has something to do with how the certificates got added, doing a simple thing as a manual import can screw up your RDSH. 

    Hope this helps, problem (my side) has vanished with this fix 11 servers that had this problem. Problems remaining : 0

    Good luck !


    A ounce of prevention is better then a pound of cure.

    This issue has caused me much weeping and gnashing of teeth over the past few days. I wish I came across this note earlier and glad I got to the end of this thread to find it. Thank you for posting!!
    30 ноября 2016 г. 3:58
  • Sad story, struggled with your (exact) problem for weeks. We are a CSP partner with a lot of support options and none delivered. I just found out what goes wrong with the 0x607 error is actually due to certificates being present in the personal store @ computer level. 

    Delete your wildcard and/or local certificates from that store that involve RDSH servers. Problem instantly goes away (and can be reproduced). Mostly has something to do with how the certificates got added, doing a simple thing as a manual import can screw up your RDSH. 

    Hope this helps, problem (my side) has vanished with this fix 11 servers that had this problem. Problems remaining : 0

    Good luck !


    A ounce of prevention is better then a pound of cure.

    Brillant!!!!

    You save my life today.

    I can confirm that as soon as the cert is removed from "Personal" Store all is going fine again.

    Thank YOU!

    30 марта 2017 г. 9:18
  • I've found this has to do with bad time on the thin clients in one environment. For whatever reason the machine wasn't checking NTP and the time was off by two days. After I set the time properly the machines started connecting up with no issues.

    Hope this helps.

    7 декабря 2017 г. 20:37
  • Thank you so much, your solution fixed the issue on our RDS 2012 R2 farm.   

    OSubhash

    26 июля 2018 г. 21:59