An Internal Error Has Occurred Remote Desktop
- An Internal Error Has Occurred Remote Desktop Connection Windows 2012 R2
- Remote Desktop Windows 10 Pc Internal Error
- Remote Desktop Protocol Error
Nov 20, 2018 - May be a bit late but this worked for me, credit to Elton Saul. Create the DWORD below and set to 10000 My next task is to find out why it has. One done with the protocol enable, restart the server and you will be good to connect to your server remotely. Remote desktop connection will start working without any problem. Security hack, not recommended. Use this method for last option. 1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy. Windows 7 Forums is the largest help and support community, providing friendly help and advice for Microsoft Windows 7 Computers such as Dell, HP, Acer, Asus or a custom build.
I just installed the latest Windows update (NSA vulnerability patch tuesday) and now I cannot connect to remote desktop.
- The server is remotely hosted. I don't have physical access. Server 2012 R1.
- Fortunately all web sites are running ok after reboot.
- I have not yet tried a second reboot because I'm a little scared to.
- When I try to connect I immediately get this message:
- 'Remote Desktop Connection : An internal error has occured'
- Have tried from multiple clients. They all fail - including an iOS app which in addition gives me a 0x00000904 error.
- If I run
telnet servername 3389
then it does initiate a connection, so I know the port is open. - I can connect just fine to other servers from my Win 10 (unpatched) machine.
- I cannot connect from my second laptop either, which is Win 10 Creators edition.
- Cannot find anything useful in Event Viewer.
- I've even tried wireshark which didn't show me anything useful.
- The best I have to diagnose is the ability to upload an ASPX page and run it.
I understand that the recent 'NSA edition' patch roundup had some RDP fixes - but I can't find anyone else who suddenly had issues hit week.
I want to have an idea what the problem is before I contact the hosting company, which is why I'm posting here.
Update:
While I still don't have physical server access I remembered I have a Windows 7 VM hosted on the server itself. I was able to get into this and open the server certificates snap-in by connecting to the 10.0.0.1 local IP.
An Internal Error Has Occurred Remote Desktop Connection Windows 2012 R2
This is showing that the RDP certificate is indeed expired - although I get no errors when connecting that suggest as such. I certainly have been connecting daily and since it expired 2 months ago my guess is that some kind of security update removed whatever other certificate was in the Remote Desktop store and it did not renew itself.
So trying to figure out a way to install a different cert here now.
Update 2
Finally found this in the event log under 'Administrative Events' (by connecting remotely via the VM) :
'The Terminal Server has failed to create a new self signed certificate to be used for Terminal Server authentication on SSL connections. The relevant status code was Object already exists.'
This seems helpful, albeit a slightly different error. Can't reboot tonight though so will have to check again tomorrow.
3 Answers
The solution is basically here
This helped too:
Assuming you have already verified that the certificate listed under Certificates > Remote Desktop > Certificates isn't valid ..
Note: I took this screenshot after I fixed everything - so this expiration date is the newly created cert that it did all by itself.
You basically then need to rename or delete this file - and then it will recreate it:
Remote Desktop Windows 10 Pc Internal Error
'C:ProgramDataMicrosoftCryptoRSAMachineKeysf686aace6942fb7f7ceb231212eef4a4_a54b3870-f13c-44bb-98c7-d0511f3e1757'
This is a well-known filename beginning in f686aace
. Then restart the Remote Desktop Configuration
service and it should recreate it. (Note: it may actually not be necessary to restart the service - just wait to see if it is recreated with the same filename for a minute).
It may take some messing around with permissions and you may need to take ownership of the file and then in addition apply permissions. Note: Ownership doesn't imply permissions. You must add permissions after taking ownership.
As I said I don't have physical access to the server - if you do then the above should suffice.
I was fortunate to be able to connect remotely via another machine on the same local networkand change the registry.
I wanted to DISABLE authentication so I could connect and gain access remotely. The registry entries to do this are HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
Set the existing keys SecurityLayer
and UserAuthentication
to 0
Create an RDP file (open mstsc and click Save after entering the servername) and in notepad add the line enablecredsspsupport:i:0
somewhere. This disables the expectation of security.
When you then run the RDP file it should allow you to UNSECURELY connect and gain access to your server.
As soon as you connect change these two registry entries back and then go ahead and delete the f686..
file..
These settings fixed my issue:
1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2.In Local Security Settings, expand Local Policies, and then click Security Options.
3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled. In my case it was disabled. So I just enabled it and issued the under listed command.
- Run gpupdate /force
Another option which will solve this problem:
The protocols were not enabled on the server. I used IIScrypto and enabled TLS1.2 and everything started working
Hello everyone in my environment this was caused when a new self signed certificate was generated TLS 1.0 is either disabled in the registry or does not exist in the registry and the new self signed cert was not in the trusted root certification authorities store.
You can prove this two ways before editing the registry. download IIS Crypto and see what is enabled and disabled in Protocols, Ciphers, Hashes, and Key Exchanges.
Sometimes though IIS Crypto will show that TLS is enabled even though it is not enabled in the registry just an FYI.
Your next option is to turn on FIPS in Local group policy this forces TLS 1.0, 1.1, and 1.2 to be turned on and used. Turn on FIPS and then try to RDP into your machine it will work this time even if TLS is disabled in the registry. You don't want to use FIPS permanently though this is just for troubleshooting so disable it on the server and head to the registry.
Head to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL
and under Protocols add three new keys title them TLS 1.0
, TLS 1.1
, and TLS 1.2
then create two sub keys under each TLS entry Title them Client
and Server
.
Inside the Client
and Server
keys create two 32bit DWORD entries one titled DisabledByDefault
with the Value
set to 0 and Enabled
with the value set to 1.
Once you do this and your self signed cert is not expired and in the correct stores you will be able to RDP into your server again.
Mr ShunzNot the answer you're looking for? Browse other questions tagged rdpwindows-terminal-services or ask your own question.
Remote Desktop Protocol Error
A heads up for anyone relying on Remote Access via RDP to hosts that are being updated to 1809;
My Canary Targeted Update host came back online after the WU pushed 1809 update and reboot cycles, but clients wont connect via mstsc, only showing a black screen post log-in with an error prompt saying 'an internal error has occurred'.
Physical login to the same hosts works without any issues.
I manually updated another host to 1809 - With the same result.
The error is present across all Client Devices (mstsc on 1803/1809 + iOS/Android).
0014Is 0014anyone else seeing this behaviour?
0014
EDIT FIX :
The error only affects Hosts where Hardware Encoding and enforced AVC:444 mode is enabled through LocalDomain Group Policy. Disabling the custom GPO setings fixes the error, but naturally disables any Hardware Encoding.