Hello World,
We are still working on our nice and lovely RDS and RemoteApp infrastructure project. This is a great product and we were able to develop an interesting concept for our customers using such technology. In this post, we will be describing a “strange” behaviour that occured at one of our customer premises.
This post is actually completing our series of article about possible problematic situation that can happen when using RemoteApp and RDS technologies. If you want to have a look at our previous posts about issues with RDS, please have a look at
- RDS 2012 R2 – Access is Denied While connecting – Issue 1
- RDS 2012 R2 – Account Restrictions are preventing to signing in – Issue 2
- RDS 2012 R2 – Access is Denied While connecting to remoteApp- Issue 3
- RDS 2012 R2 – Access is denied – Issue 4
- RDS 2012 R2 – DMZ and failing connections
The Situation
We had established a RemoteApp infrastructure with one of our customers. This customers had a complex AD topology. Multiple forests were available within the organization. One forest needed to access resources in the forest hosting the remoteApp infrastructure. No Trust was available between these two forests.
So, no problem, we had created a user account in the resource forest and asked the user from the other forest to try to access the web interface and launch the required application. The user was able to login into the web page and could see the published applications made available to him. When the user tried to launch an application, the following error message appeared
Your computer can’t connect to the remote computer because an error occured on the remote computer that you want to connect to. Contact your network administrator for assistance
Click on picture for better resolution
Based on google research, the most frequent reason for such error was related to the version of the remote desktop client. In our case, this was clearly not our scenario. Both environment were using the latest version of the rdp client.
Troubleshooting Process
After ensuring tha the firewall was not causing an issue, we needed to move forward and see what was happening. The customer was using a RD Gateway infrastructure to make the connection to the RD Session host servers.
So, we went to the RD Gateway server and start reading the Event Viewer messages available over there. Looking into the event viewer, at the Applications and Services Logs > Microsoft > Windows >TerminalServices-Gateway node, we were able to retrieve the connections steps we were performing.
As you can see, the connection to the RD Gateway was indeed initiated (Event ID 312/313) but never acknowledged by the server.
Click on picture for better resolution
During the sequence, we can see that the event ID 200 is generated and it’s telling me that the user is authorized to access through the RD Gateway and that authentication method is NTLM
Click on picture for better resolution
So, at this stage, we were able to assess that a connection between the client and the RD Gateway was performed. However, connection between the RD Gateway and the RD connection broker was not going through.
So, we decided to have a look at the security log and there we found out that audit failure were registered at the same time of the connection. We tried again and found out that indeed, when trying to perform the connection, the Event ID 4625 was registered. The message was quite clear. An account failed to logon.
Click on picture for better resolution
So, yes, we had an authentication issue there.
The solution
It took us some time to find out that the LAN Manager settings between the forests were not set to the same level. This was actually causing the authentication issue.
After some research, we found out that the NTLM settings in the resource forest and the one where the computer trying to connect to our infrastructure were not the same. By default, Windows 2012 R2 (and even windows 7) are using the NTLM v2 for authentication process.
The client and the server were not talking the same language. In the forest where the client computer was located, the sysadmin had lowered the NTLM Security level while the server was still using the default version (i.e. NTLMv2)
The client computer had the following settings applied via the GPO. You can see that the option for the LAN Manager authentication setting on this computer was set to Send LM & NTLM – use NTLMv2 security if negotiated.
Click on picture for better resolution
On the server side, the same settings is by default set to not defined which means that the default will be used (i.e. Send NTLMv2 Response Only.).
Click on picture for better resolution
You can confirm that this is the default settings by looking at the explanation of the Group policy settings
Click on picture for better resolution
So, to resolve this issue, we had to set on the client computer the LAN Manager authentication level to Send NTLMv2 Response Only. After a restart of the machine and having the gpo applied, the user was able to perform the remote desktop connection and start using our lovely RemoteApp Infrastructure.
The funny thing is that you would expect that the option Send LM & NTLM – use NTLMv2 security if negotiated would be enough. Indeed, the description of this settings says that the client will try to use NTLMv2 if the server support this. Apparently, this is not working. You need to set the value to NTLMv2 Response only
IMPORTANT NOTE :
You need to restart the machine to have the GPO applied correctly. A GPUPDATE might not be sufficient. If after the restart, you notice that this is not solving your issue, you might need to reset your NTLM settings manually by deleting the following registry key :
HKLM\System\CurrentControlSet\Control\lsa
Click on Picture for better Resolution
You will need to delete the lmcompatiblitylevel key and this one will be recreated automatically when restarting or when the gpo will apply.
Final Notes
This error was a difficult one. We had to look at multiple things before thinking of NTLM authentication level. So, if you encounter such situation and that you see that your RD Gateway server is throwing eventid 200/312/313 and nothing happens, you should start checking your Security logs for event id 4625. So, if you see all these Event Id, you might be in the same situation as we were and you might need to adapt your NTLM Settings….
That’s it for me for today…
Till next time
See ya
Thanks for this article. You saved me hours of research. This was the same issue I was experiencing.
THANKS just THANKS
hello there,
No problem at all. I can tell you that I ve been through the same hassle with this issue but we found the solution : )
Till next time
See ya
what if i dont want to edit the client machine? we have home users that connect via VPN to our network, then launch remote app via rdweb. we get this error when launching anything (wordpad, paint doesnt matter)
is the vpn causing the problem?
@Todd,
the vpn is not causing the problem. Have you read the article fully ? are you getting the same symptoms when trying to connect….If yes, you have to adjust your NTLM settings as described in the post….
Till next time
See ya
Hi Griffon,
In my case, users have reported the similar message and they get this message at a specific time interval (morning 7-11). After that they are able to connect to the RDSH servers. I am also able to replicate the same issue at my end and there is no gateway in picture in our scenario. Also, as per the information, not all users get this error in that time interval, only few different set of users everyday .
Where could be the issue?
Could the RDSH servers be unloaded during that time due to high number of users or resource utilization? As I have checked the same thing during the weekend and it works fine during that time period and rest of the day as well.
@Rohan,
I would start collecting some logs/check eventviewer…your problem does not seems to be related to the post (NTLM authentication)..
I’m assuming that your system is also up to date (latest Windows Update installed on your RDS Farm)
how many RDHS server do you have ? are they really showing high usage ? have you configured load balancing settings if you have multiple ones….
need more info to provide better answer
Hope this help
till next time
See ya
Hi,
Today only I found out that it is not related to any particular time. I have faced this issue today, outside of the time mentioned earlier. The error is similar to the one when I put my servers to not allow new connections or in citrix terms unload the servers. It simply means that my RDSH servers stop accepting the connections randomly at any time of the day and irrespective of the load. And then they again start working
I have found few errors in the logs, not sure if it is related – “Remote Desktop Services failed to join the Connection Broker
Error: Current async message was dropped by async dispatcher, because there is a new message which will override the current one.”
“Information – Remote Desktop Services successfully left a farm on the Connection Broker server”
“Information- Remote Desktop Services successfully joined a farm on the Connection Broker server”
I am thinking of rejoining the server to the RDS farm manually… thoughts?
@Rohan,
I do not have all the info here but as a first guess, I would check the Licensing aspect of your installation. do you have a licensing server present in your org ? have you enough CAL for your users/devices ? Have you installed the RDS Licensing diagnoser MMC console. This could provide you with a little bit more info….Even if you have activated your licensing servers, this behavior can time to time popup
Open also the RDS licensing manager and check for any warning or error messages over there and proceed in order to fix them
Hope this help
Till next time
See ya
Okay, I will check however I doubt any issue with the license server as we have so many other session host servers running with consistent performance. Also, I don’t see any errors related to licensing on the 2 problematic session host servers.
Any idea, where/how can we check if RDSH server is out of capacity or load to accept more new connections?
Regards
Rohan
This works, thanks for that.
Problem is though the company I work for have a third party company that need to use remoteapps, I dont the idea of advising them to change the NTLM settings on their domain, any suggestions on how to get this working without altering clients?
Thanks
@EP,
I’m not sure I understand your question….
If you are asking if we can centrally set the modification in an easy way, then the answer is : the third party company can create a group policy with the proper NTLM level and you do not need to visit all the clients, the settings will be implemented automatically
If you asking me, can the third party company keeps their current settings, You can try to lower the security on the domain hosting the RemoteApps (via a group policy) taking into account that security is weaker in such situation + I never tested this configuration …
Hope this help
Till next time
See ya
Thank you very much for this article it has saved me quite some time 🙂
@Eddie,
No problem, we know the feeling when a really tiny setting can make life difficult…. 🙂
Thank for the visit and the feedback… see your arround
Till next time
See ya
Thank you this post save my life. After hours of research I found this post and I can resolved this problem.
@Griffon Very Thank for help.
@Leonardo,
Not a problem…We are happy to see that our blog is definitely useful to people
Thank you for sharing your experience and providing positive feedback
🙂
Till next
See ya
Hi.my other win7 pc can connect to RemoteApp Server. But the other PC cant…!!same settings from the other workstation I made. What should be the prob?
@Rich,
I have no clue…there not enough info for us to debug and investigate…Check your Event viewer to see if you can find more information about the issue you are encountering
Hope this help
till Next time
See ya
Hey thank you for this article, I’m having the exact issue however there is an strage situation, this is happening from LAN users, Internet Users. Nevertheless is not happening from one specific public network, when I connect from that network connection passes and remote app opens, but when I move to another network it fails with the same error. I have spent 5 days trying to success this with no success.
Infra estructure:
PFSENSE firewall in the middle with NAT 1:1 from public port 45137 to 3389 (Private machine with Remote APP).
REVERSE PROXY receiving all https traffic and forwarding it to the RDGateway machine according to its URL.
https RDGateway URL works and authenticates correctly users, this error comes when the app is clicked and the it request again the authentication for the user, and the it fails telling “Desktop can connect to the remote computer”. That message emerges because connection never triggers the Remote work resources connection on the clock bar icon.
When I check the event logs… shows the same as you. But as I said… when I go back to the other network this works without performing anything.
I have reviewed firewall on windows, on pfsense… and nothing shows any blok or drop of packages… Nither is configurated any regional or IP specific rule for that access… Thank you for all the help you can provide!
@Brian Otero,
No clue what could be the problem right away…
First thing that would pop into my mind is Firewall (because it s working from one location and not the other location)
Second have you check that the LM Compatibility settings are set accordingly on Server and on clients and proceed with your tests
Firewall aspect
Have you tried to remove the firewall from the picture and see if you can indeed connect…If this is the case, the problem is definitely Firewall configuration and you might need to open some ports (or allow traffic from specific subnet)
Maybe this post could help (http://c-nergy.be/blog/?p=8266). You need to ensure that traffic between RD Gateway and RD host servers are configured properly if you have placed your RD Gateway in the DMZ zone….(we do not know your RDS architecture…)
Client/Server Settings
Check Client/Server settings on the working network and compared that to client/machines located in the non working network
Use network monitoring tool to trace traffic and see where a failure could occur
Give it a try and keep us in the loop so we can monitor progress and try to help a step further….
Hope this help
Till next time
See ya
This article was great and really helped up troubleshoot an issue.
We did find a follow up KB article that looks similar including a reg entry you can do on your Terminal Server vs setting the client to run NTLMv2
https://urldefense.proofpoint.com/v2/url?u=https-3A__support.microsoft.com_en-2Dus_kb_2903333&d=DwMF-g&c=dyyteaO_66X5RejcGgaVFCWGX8V6S6CQobBcYjo__mc&r=xHRlcRlP_tcNe63tkryjurmvsMF06ymntJsZORyrLa8&m=Ba3ZHJMd4DEvHicFPpKjryAVnava8U5jN5XY26ir3Ws&s=4WOdajDQJGM5ZXBqr1M6wjJvR37Sg9DOM1b_276s6R0&e=
Thanks again!
@Jeff;
Thank you for your visit and your contribution… The link seems indeed indicate that some registry tricks can be applied..
People can have a look to the kb and evaluate if this would be an option for their network
Till next time
See ya
GREAT article! Worked for me.
Greetss
@Robert,
Thank you for the visit and the feedback about this post. This give us the willing to move forward and provide more useful tips and tricks
Till next time
See ya
Yo, real talk son, you done did helped me out wit this. Good god damn good job!
@Big Joe,
Thank for the feedback and for the visit our blog. Good to see that this post is useful
Till next time
See ya
Hi,
I applied the above mentioned fix in my 2016 RDS gateway, both did not work for me. I checked the registry key in 2016 we have an key”lmcompatibilitylevel” dword set as 3. Is this key cause issue in 2016 RDS server. I am still getting event ID 312 in 2016 RDS gateway server. Any thoughts please share
@Austin Jose,
the fix is not to be applied on the RDS Gateway but on the RD Session Host servers….
Till next time
See ya
Oh man, you saved me. I’ve gone through this issue and looked into this for a week till I found this article. Glad the changes on the client side resolved the issue. You rock Man.
@Furqan,
Thank you for visiting our blog and providing positive feedback. Thank you for providing this feedback, we are always happy when we can help people out there
Till next time
See ya