Oops, we couldn t connect to Session Desktop sign in failed

Hi maybe you have some cached credentials for the rdweb portal?
Best,
Sean

meuchel wrote:

We are able to connect to the service and see the apps but when we launch them it says: Your computer was unable to connect to the remote computer. Try to reconnect. If the problem continues, contact the owner of the remote computer or your network administrator.

Are you connecting via FQDN? If so, try the IP instead.

seannoy2I looked in the credential manager and there is nothing for the RDweb. Is there another place it caches creds?

DragonsRuleI am using the FQDN but it is resolving properly and making a connection to the remote server the issue is when the apps try to launch.

Are you thinking change the FQDN to the IP in the .rdp file?

In windows 10 there is a remoteapps control panel that establishes the connection to the feed and setup up the apps in the start menu but they still don't launch.

I was going to try to change the computer name to see if that does anything but not sure.

• DragonsRule

  Pure Capsaicin
• seannoy2

  Cayenne

I would change it to IP both in the initial connect and also anywhere it's located in the RDP file. Just because you get the initial connection doesn't mean the software will properly resolve the names every time.

We are having the same issue and found it be related to the workspace id. We have a ticket with microsoft for it but do not have a resolution yet. I can respond once I hear from them.

I can log in with the ip to the web portal but I am assuming the .rdp files are hashed because when I change the IP in them it corrupts them.

I also tried renaming the computer.

This is driving me nuts.

meuchel wrote:

I can log in with the ip to the web portal but I am assuming the .rdp files are hashed because when I change the IP in them it corrupts them.

AFAIK that's not possible. The RDP file is just a text file. If it was anything else your local PC's RDP client wouldn't be able to read it.

Maybe the editor you used is the issue?

We've just started having the same issue on two Windows 10 machines. There are no error logs on either the server or the clients, no cached credentials, no missing/extra certificates, same updates as all other computers, no new updates on the server or clients - everything is the same. The client does not even appear to be contacting the server at all, there is no record of it. One of the clients is on prem, so its not even using the gateway at all. Both clients can connect to the server via manual RDP setup, just not through remote apps and not through RD Web access. Such an annoying issue, and, per usual, Microsoft's response is "reinstall Windows". No, I'm not going to reinstall Windows.

I'm going to start rolling back updates on both the clients and the servers and see if I can get these clients connecting again. Very annoying.

So been on phone all day with Microsoft support getting bounced from team to team and still no answer. They have no idea whats causing this. We are seeing this on about 20 out of about 3,000 units so sporadic but once it happens to that station it doesn't go away. Will keep posted as I work this with MS Support.

I tried notepad.exe and notepad++ any edits cause corruption.

There is a signature as the last setting.

The host says it isn't even hitting the server logs.

If you remove the signature completely from the file when your editing it, you should be able to edit it fine, or at least that's what I've been doing.

wesleyfoxARourke

Hey you guys find any updates that hit it lately?

All my machines seemed to be fully patched but only some are having problems.

• ARourke

  Poblano
• wesleyfox

  Sonora

wesleyfox

OK so I took off the signature and it let me play with the file.

I deleted the workspace id: option and BOOM! I was in!

I don't know who to give credit to but I will mark you all for helping now.

• wesleyfox

  Sonora

Same boat as you. The machines that are having the issue, I started with a system restore as far back as I could and then ripping patches and have not found anything yet.

• meuchel

  Jalapeno

Exactly the same as me. Microsoft team can't seem to explain it to me and have been bounced to 5 different teams today. So much for partner support.

edit: referring to workspace id issue

Well I am happy to have a work around.

I didn't want to format a computer for 1 silly line of code.

But it would be nice to have a fix!

Hi Meuchel, I'm abit late for the party but had some thoughts that maybe can help:

1. make sure date/time on client computer is in sync

2. try disabling NLA on the remoteapps see if that helps

3. what certificate do you use in your farm? maybe its missing or invalid on the client?

4. do you configure work resources using GPO? if not - try configuring it under: User config - Policies - Admin Temp - Windows Components - Remote Desktop Services - RemoteApp and Desktop Connections - Specify default url connection: should be something like

//your.farm.com/rdweb/feed/webfeed.aspx

best,

Sean

Unfortunately those did not assist for ours.

1] verified time between session host, connection broker, and gateway with the workstation

2] Negative disablg changed nothing

3] We use wild card cert and installed it on workstation and all servers

4] Good thought, and thought you might be onto something but after trying it still failed, and we use the default url connection string.

• seannoy2

  Cayenne

Just got off the phone with Microsoft support again. They are escalating this ticket one more time to get a hotfix/patch made for it. They estimated a few business days till they have something. I will keep you posted.

Nothing done on the workstation changed anything.

I do not have access to the server as it is a hosted platform and they are claiming that since this is not affecting all machines there is no problem.

This is not a problem with connectivity to the RDweb service it has something to do with how the client is accessing the workspace or how the server is creating it.

Most systems are able to translate the workspace id and some are not.

I would think this issue is at the gateway because removing the option allows the session to complete.

I will wait on your response from Microsoftwesleyfox

If it helps I can provide you with more information to add to your ticket from my client privately.

I am severely disappointed in the host for not wanting to cooperate with us on this issue.

• wesleyfox

  Sonora

Out of curiosity, what OS are you seeing this on? Does it seem to only affect Windows 10? If so, what version[v1607, v1703, v1709...]?

Just wondering if this is limited to latest v1709, we plan to roll out this version shortly at one of our clients who is a heavy [2012R2]RemoteApp user. PCs are currently running 1703 and previously on 1607 and 1511 and we have not run in to this issue across hundreds of PCs.

I'm actually in the opposite boat as you Meuchel. We are the host and trying to resolve for the clients. You are not alone in this. Working with Microsoft it doesn't sound to be a gateway issue either but rather a remote desktop serivce issue. For example if you download and install the windows 10 remote desktop app from the app store it can access the apps. The terminal services on the client desktop are having an issue but I believe it is because of an update of some kind. One thing I was able to try that you may not since we are the host is we have multiple separate deployments with their own networks, firewalls, connection brokers, session hosts, and gateways. A machine that is having the issue has it with all the deployments. However, those same deployments work fine on a majority computers. Something else interesting is when using netmon we found if the workspace id line is in the handshake to the server is never initiated, it fails before even doing a handshake. If you remove the workspace id the handshake and packets happen as expected.

• meuchel

  Jalapeno

Weird, we are on Windows 10 1709 on all machines with the latest patches with and without issues.

It happened after our 4-11 patch cycle.

KB4093112 is the only patch that was installed that has any association to RDP.

I rolled it back but it doesn't change anything.

mstsc.exe

msrdpwebaccess.dll

wksprt.exe

wkspbroker.exe

All these are the same version from 9/29/17 on all pc's.

The mstsc app seems to not even launch the connection broker it IMMEDIATELY says it cannot connect to the computer.

I made the same discovery as you both yesterday regarding the workspace id parameter. When I removed this from the rdp files in Notepad++, the clients could connect again without issue. Interestingly, I didn't have to remove the signature line for this to work [clients connected with no additional errors or prompts]. We had a third workstation start to do this today and it is running Windows 7, so I don't think this is a Windows 10 issue. This particular client just experienced this issue for the first time this morning - the last time his computer was updated was on 4/11, so I don't think this is related to Windows updates either.

I'm also using a wildcard certificate and my RDSH has different external and internal FQDNs. Maybe this is related to the issue?

I look forward to Microsoft resolving this issue. Could you mention to them that this is also happening in Windows Server 2016? That's what we're using.

• meuchel

  Jalapeno
• wesleyfox

  Sonora