RDP SHADOW FAILURE: RPC SERVER NOT AVAILABLE.
Following McKnife's extremely helpful guidance a few months back, I had almost no problem setting up 2 machines on my LAN for RDP shadowing
Have just replaced one of those machines and although I believe I've jumped through all the same hoops I did last time, I cannot connect to the new workstation.
I can ping it by both name and ip address, but when I run qwinsta /server:[machine name]
I get
Error [1722] The RPC Servier is Unavailable.
So I searched online for what that meant and followed the guidance I found on multiple pages, all saying much the same thing.
This page is an example
Essentially, I've been through all the advice there and confirmed that my machine was already set up exactly as advised.
Furthermore, thinking it might be a problem with that specific machine (which was identical to the one it replaced), I happened to take delivery of another exact copy a couple of days ago and decided to try RDP Shadowing that one instead. Set up as advised, Results Identical.
I should add that, in order to rule out 3rd party interference or my personal preferences, I conducted these tests in the immediate post installation phase, with windows set up just as Microsoft would like. I even rebuilt the first machine twice; on the second occasion, to eliminate the possibility that it was being caused by some undocumented change within 20H2. Both the new machines arrived with that version of W10 installed, whereas the machines I setup under McKnife's guidance were both v2004. So I rebuilt it to that version. No change.
To summarise:
What I described as remarkably simple for two machines back in January has proved remarkably difficult to repeat with two identical new machines today. I should also point out that one of the two original machines is still linked and remains fully accessible, without any issues (proving that nothing significant has changed on the LAN overall or my main workstation, from which I issue the calls).
Remote Desktop Connection has been allowed
The Policy/Rule under Remote Desktop Services\Remote Desktop Session Host\Connections\Set Rules for remote control (etc) has been set to "Full Control Without Users Permission"
The Firewall shows all apt RDP Rules set to Allow and Enabled
I had changed the RDP port to 40000 but have reverted to the default 3389. (will worry about changing it again, once we get the damn thing working on defaults)
The Registry settings for RpcSs, DcomLaunch and RpcEptMapp were already set to 2 and remain so.
The relevant services (RPC Call) and RDP are running and set to Automatic.
the settings have been tried and failed in both W10 recent flavours (2004 and 20H2)
I've run out of things to check...
Suggestions?
Have just replaced one of those machines and although I believe I've jumped through all the same hoops I did last time, I cannot connect to the new workstation.
I can ping it by both name and ip address, but when I run qwinsta /server:[machine name]
I get
Error [1722] The RPC Servier is Unavailable.
So I searched online for what that meant and followed the guidance I found on multiple pages, all saying much the same thing.
This page is an example
Essentially, I've been through all the advice there and confirmed that my machine was already set up exactly as advised.
Furthermore, thinking it might be a problem with that specific machine (which was identical to the one it replaced), I happened to take delivery of another exact copy a couple of days ago and decided to try RDP Shadowing that one instead. Set up as advised, Results Identical.
I should add that, in order to rule out 3rd party interference or my personal preferences, I conducted these tests in the immediate post installation phase, with windows set up just as Microsoft would like. I even rebuilt the first machine twice; on the second occasion, to eliminate the possibility that it was being caused by some undocumented change within 20H2. Both the new machines arrived with that version of W10 installed, whereas the machines I setup under McKnife's guidance were both v2004. So I rebuilt it to that version. No change.
To summarise:
What I described as remarkably simple for two machines back in January has proved remarkably difficult to repeat with two identical new machines today. I should also point out that one of the two original machines is still linked and remains fully accessible, without any issues (proving that nothing significant has changed on the LAN overall or my main workstation, from which I issue the calls).
Remote Desktop Connection has been allowed
The Policy/Rule under Remote Desktop Services\Remote Desktop Session Host\Connections\Set Rules for remote control (etc) has been set to "Full Control Without Users Permission"
The Firewall shows all apt RDP Rules set to Allow and Enabled
I had changed the RDP port to 40000 but have reverted to the default 3389. (will worry about changing it again, once we get the damn thing working on defaults)
The Registry settings for RpcSs, DcomLaunch and RpcEptMapp were already set to 2 and remain so.
The relevant services (RPC Call) and RDP are running and set to Automatic.
the settings have been tried and failed in both W10 recent flavours (2004 and 20H2)
I've run out of things to check...
Suggestions?
ASKER
greetings McKnife. Was hoping you'd jump in.
Think you're pointing at the right symptom but possibly the wrong cause.
Telnet does indeed fail to connect with the target.
But running netscan -na on the target shows that the port (445) is Listening, so it is definitely open and enabled.
And checking what Apps are allowed through the firewall shows that both Remote Assistance and Remote Desktop are already permitted (both Public and Private, though, if I can get it working, I'll restrict RDP to Private only)
So what else could block telnet access?
Think you're pointing at the right symptom but possibly the wrong cause.
Telnet does indeed fail to connect with the target.
But running netscan -na on the target shows that the port (445) is Listening, so it is definitely open and enabled.
And checking what Apps are allowed through the firewall shows that both Remote Assistance and Remote Desktop are already permitted (both Public and Private, though, if I can get it working, I'll restrict RDP to Private only)
So what else could block telnet access?
What netstat -na shows is on fine, but it does not tell you whether the port is allowed to be used by any IP.
On the target, simply create a firewall rule for port 44 as shown here in the article:
Be aware that the screenshot shows the rule is active for the domain profile, only, so if you set it and telnet still does not connect, you should make sure that the network card is detected as domain connected and not public or private network.
On the target, simply create a firewall rule for port 44 as shown here in the article:
Be aware that the screenshot shows the rule is active for the domain profile, only, so if you set it and telnet still does not connect, you should make sure that the network card is detected as domain connected and not public or private network.
ASKER
hang on, that looks inconsistent with how my existing RDP shadow is working, which is Private only
Are you implying that it will only work with Active Directory (so I can assign the card to a Domain)?
a) I don't use Active Directory so there is no domain option
b) and, as I've said, the workstation on which the RDP Shadow continues to work perfectly is only set to Private.
But when I try to mirror the settings on the other one I can "RPC Server Unavailable".
I don't know whether this will provide a clue.
Initially I switch both on (Domain and Private)
Instead of "RPC Server Unavailable" I got "Access Denied" !
As soon as I switched EITHER off, we reverted to "unavailable"
One way or t'other, it's definitely looking like Microsoft has moved the goalposts
Are you implying that it will only work with Active Directory (so I can assign the card to a Domain)?
a) I don't use Active Directory so there is no domain option
b) and, as I've said, the workstation on which the RDP Shadow continues to work perfectly is only set to Private.
But when I try to mirror the settings on the other one I can "RPC Server Unavailable".
I don't know whether this will provide a clue.
Initially I switch both on (Domain and Private)
Instead of "RPC Server Unavailable" I got "Access Denied" !
As soon as I switched EITHER off, we reverted to "unavailable"
One way or t'other, it's definitely looking like Microsoft has moved the goalposts
No Domain needed.
Use that very firewall rule and make it active for the private profile, then test with telnet again.
Use that very firewall rule and make it active for the private profile, then test with telnet again.
ASKER
OK, the plot thickens
With Private selected, it does now pass the telnet test
but Qwinsta still responds with "RPC Server Unavailable"
With Private selected, it does now pass the telnet test
but Qwinsta still responds with "RPC Server Unavailable"
It should work by default, so after setting the firewall rule, nothing else should be needed. Cannot confirm it at once for non-domain joined machines, but will do later.
Mike, I just found the time to test that:
2 cleanly installed workgroup machines have, by default, no ports open. So I logon to machine 1 as user test and password test, allow only ICMP echo request (ping) and "file and printer sharing (SMB in)" and all just works, qwinsta /server:pc2 returns the expected user name.
Thing is, this all works, because I have both machines set up with the same test user and password.
It does not work when I use different passwords
So unless you use the same passwords and username, this cannot work in a workgroup!
2 cleanly installed workgroup machines have, by default, no ports open. So I logon to machine 1 as user test and password test, allow only ICMP echo request (ping) and "file and printer sharing (SMB in)" and all just works, qwinsta /server:pc2 returns the expected user name.
Thing is, this all works, because I have both machines set up with the same test user and password.
It does not work when I use different passwords
So unless you use the same passwords and username, this cannot work in a workgroup!
ASKER
thanks for your continuing efforts.
However, what you're describing as being prerequisite for success is definitively not true for the two machines I set up back in February, one of which is still connected and working without issue. It has its own strong password and a different username, and it has to be up and running and logged in, with that username and password. But once it is, I can connect it to it, following your instructions (on that original link) without issue.
However, there is no reason I can't set up the rogue machine with the same username and password I'm using on my main workstation. So I tried that. Again, it moved the goalposts. Pinged OK but qwinsta responded with a new message:
error 5 getting session names
Went looking for clues relating to that. Got suggestions for a couple of registry edits. Checked those and where mine weren't already as advised, added or amended those, rebooting after each, no effect.
Even ran SFC/Scannow and a full image repair. Nada
Ran qwinsta /server:localhost on the offending machine and got back
Console, Mike, 1, Active
and rdp-tcp, 65536
exactly the same as I get if I run it on the machine that works (i.e. lets me connect)
To summarise: The following boxes have been ticked:
1 Remote Desktop Connections are allowed
2 Policy to allow "Full Control without User's permission" has been set
3 Firewall permits ping and SMB on Private (SMB port=445)
4 RPC services are running
5 Account in my name and pwd set to match main workstation set and logged in. All stations is same Workgroup.
6 Relevant registry settings comply
7 Telnet and Ping can access the remote system
Finally an interesting (possible) red herring. I wanted to compare the qwinsta localhost response on my working connection with the rogue. So I ran qwinsta remotely to that server and got back the same failure message I was getting earlier on with the rogue: RPC Server Unavailable.
I then connected to it without issue, with the usual
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
so I could run the qwinsta localhost command locally. No problem.
Which tells me that that error message (Server unavailable) is essentially meaningless! For you though, it might be a further clue...
However, what you're describing as being prerequisite for success is definitively not true for the two machines I set up back in February, one of which is still connected and working without issue. It has its own strong password and a different username, and it has to be up and running and logged in, with that username and password. But once it is, I can connect it to it, following your instructions (on that original link) without issue.
However, there is no reason I can't set up the rogue machine with the same username and password I'm using on my main workstation. So I tried that. Again, it moved the goalposts. Pinged OK but qwinsta responded with a new message:
error 5 getting session names
Went looking for clues relating to that. Got suggestions for a couple of registry edits. Checked those and where mine weren't already as advised, added or amended those, rebooting after each, no effect.
Even ran SFC/Scannow and a full image repair. Nada
Ran qwinsta /server:localhost on the offending machine and got back
Console, Mike, 1, Active
and rdp-tcp, 65536
exactly the same as I get if I run it on the machine that works (i.e. lets me connect)
To summarise: The following boxes have been ticked:
1 Remote Desktop Connections are allowed
2 Policy to allow "Full Control without User's permission" has been set
3 Firewall permits ping and SMB on Private (SMB port=445)
4 RPC services are running
5 Account in my name and pwd set to match main workstation set and logged in. All stations is same Workgroup.
6 Relevant registry settings comply
7 Telnet and Ping can access the remote system
Finally an interesting (possible) red herring. I wanted to compare the qwinsta localhost response on my working connection with the rogue. So I ran qwinsta remotely to that server and got back the same failure message I was getting earlier on with the rogue: RPC Server Unavailable.
I then connected to it without issue, with the usual
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
so I could run the qwinsta localhost command locally. No problem.
Which tells me that that error message (Server unavailable) is essentially meaningless! For you though, it might be a further clue...
This cannot work unauthenticated. So looking at your system that works, where you say, you haven't got the same account names and/or passwords - how is that supposed to work? Answer that, please. So if you start the command line, as what user do you start it? If that user is not present on the remote system, that would suggest, that you have saved credentials available for the remote machine. Else, it can definitely not work.
ASKER
Intriguing. I promise you it does work without stored authentication. I'd even be happy for you to log in with a Quick Assist session and show you.
All I do, if I have to reboot the machine is log in with the remote machine's username (which is nothing like the accounts on the machine I access it from) and password (also unique and which, if I'm feeling lazy, I do using Lite Manager, which is installed on the remote and, using AutoHotkey, I can stuff the keyboard buffer and effectively copy and "paste" the password into the standard windoze login screen (which is easier than typing it at the remote keyboard because its a fairly complex password I store in Keepass). Once its fully booted, I just run
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
and I'm in. Frankly, it did disturb me that it was that easy.
At no time was I asked for a username or password and certainly haven't stored one. And it's not as though I'm unfamiliar with "normal" RDP practice. I have a small library of RDP logins for genuinely remote sites where I did indeed have to jump through those hoops and either enter credentials every time or save them. But no such obstacle was presented to me for either of the machines I set up in February. At the time I assumed this was because it recognised that the access was from the LAN, not the WAN and focused on making sure that the RDP access was limited to Private only, but I don't recall that even being mentioned in the instructions.
In case you're unfamiliar with it, I should emphasise that Lite Manager doesn't override or substitute for the Windows Login. It'll get you to the login screen because you can set it as a service to wake up before login, but you still have to provide normal windows credentials to get to the desktop.
And, actually, the RDP Shadow also gets me to the rebooted machine but, instead of presenting the login screen, it just displays a big "pause" sign, which is also visible if the remote machine is locked or goes to sleep. I have to use the keyboard or LM in either of those circumstances. This, I think, also confirms the point that it can't be using a set of stored credentials.
Could it be that those machines have a different version of RDP than standard?
All I do, if I have to reboot the machine is log in with the remote machine's username (which is nothing like the accounts on the machine I access it from) and password (also unique and which, if I'm feeling lazy, I do using Lite Manager, which is installed on the remote and, using AutoHotkey, I can stuff the keyboard buffer and effectively copy and "paste" the password into the standard windoze login screen (which is easier than typing it at the remote keyboard because its a fairly complex password I store in Keepass). Once its fully booted, I just run
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
and I'm in. Frankly, it did disturb me that it was that easy.
At no time was I asked for a username or password and certainly haven't stored one. And it's not as though I'm unfamiliar with "normal" RDP practice. I have a small library of RDP logins for genuinely remote sites where I did indeed have to jump through those hoops and either enter credentials every time or save them. But no such obstacle was presented to me for either of the machines I set up in February. At the time I assumed this was because it recognised that the access was from the LAN, not the WAN and focused on making sure that the RDP access was limited to Private only, but I don't recall that even being mentioned in the instructions.
In case you're unfamiliar with it, I should emphasise that Lite Manager doesn't override or substitute for the Windows Login. It'll get you to the login screen because you can set it as a service to wake up before login, but you still have to provide normal windows credentials to get to the desktop.
And, actually, the RDP Shadow also gets me to the rebooted machine but, instead of presenting the login screen, it just displays a big "pause" sign, which is also visible if the remote machine is locked or goes to sleep. I have to use the keyboard or LM in either of those circumstances. This, I think, also confirms the point that it can't be using a set of stored credentials.
Could it be that those machines have a different version of RDP than standard?
No version conflict possible, no.
Please come back to
"So if you start the command line, as what user do you start it? Is that user present on the remote system, does it have the same password on both systems?
Please come back to
"So if you start the command line, as what user do you start it? Is that user present on the remote system, does it have the same password on both systems?
ASKER
I start as the user on my current workstation and it that user is NOT present on the remote system. The passwords are different on both systems.
ASKER
I should also add that, on the machine we're trying to get to co-operate, I have synchronised the account name and password to be identical to my main machine, in the hope that it would behave as you imply is expected...
That is so weird.
Since I have taken the time to test and it works as expected with minimal effort, I will not invest more time here, sorry.
Since I have taken the time to test and it works as expected with minimal effort, I will not invest more time here, sorry.
ASKER
First, apologies.
I had omitted, in my synchronisation efforts, to change the name of the admin account on the remote, to match my main workstation, so they weren't as synchronised as suggested.
I've just fixed that and the RDP connection now works as it should. So the main problem sorted and you've earned (at least) the full points.
Two remaining issues though.
Most important: I don't really want to have that remote using the same username and password as I do on my main workstation because the latter is heavily defended, while the remote isn't. So I'd prefer to RDP into it with alternative credentials. How do we do that? (eg just set up a "standard" RDP connection?)
And Second, entirely up to you if you wish to pursue it for academic reasons, but given all that we've been through on this thread, the obvious loose end is "how the hell is my other remote RDP working so perfectly?" given that it most definitely IS NOT using the appropriate credentials???
I had omitted, in my synchronisation efforts, to change the name of the admin account on the remote, to match my main workstation, so they weren't as synchronised as suggested.
I've just fixed that and the RDP connection now works as it should. So the main problem sorted and you've earned (at least) the full points.
Two remaining issues though.
Most important: I don't really want to have that remote using the same username and password as I do on my main workstation because the latter is heavily defended, while the remote isn't. So I'd prefer to RDP into it with alternative credentials. How do we do that? (eg just set up a "standard" RDP connection?)
And Second, entirely up to you if you wish to pursue it for academic reasons, but given all that we've been through on this thread, the obvious loose end is "how the hell is my other remote RDP working so perfectly?" given that it most definitely IS NOT using the appropriate credentials???
For shadowing, by default, you need to be admin on the remote machine.
This can be changed and I have used the command to change that, but not in a workgroup.
Let me try tomorrow, I'll share the command after verifying it.
This can be changed and I have used the command to change that, but not in a workgroup.
Let me try tomorrow, I'll share the command after verifying it.
ASKER
I don't mind being admin on the remote. In fact I prefer it. But you asked, earlier, "what user are you logging in as?" as though we could pass parameters; something along the lines of
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt user: Administrator pwd:whatever
c'est possible?
mstsc /v deskmike2 /shadow:1 /control /noconsentprompt user: Administrator pwd:whatever
c'est possible?
Ok, then it's as easy as creating some user for remoting on both machines. Make him admin on the remote end and standard user on your end. From your own account, you could start cmd as him and then run shadowing within that new shell.
runas /user:remotinguser cmd
runas /user:remotinguser cmd
ASKER
hmm... that's a new trick on me. I'm familiar with the option run a cmd window as admin, but never seen an option to run it as another user.
Is your
runas /user:remotinguser cmd
implying that, for example, my modified cmd line would be
runas /user:Mike :mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
(assuming I have an admin user Mike set up on the remote)
Is your
runas /user:remotinguser cmd
implying that, for example, my modified cmd line would be
runas /user:Mike :mstsc /v deskmike2 /shadow:1 /control /noconsentprompt
(assuming I have an admin user Mike set up on the remote)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Brilliant. Spent a good hour trying variations. Inverted commas never occurred to me. Shame they didn't think to include something like that in their examples.
Anyway, now working exactly as I need. Though I'm left mystified by how the other one gave up without a fight!
Wish I could award more points but that's not within my gift.
My gratitude is a poor substitute but I hope you'll accept it.
Anyway, now working exactly as I need. Though I'm left mystified by how the other one gave up without a fight!
Wish I could award more points but that's not within my gift.
My gratitude is a poor substitute but I hope you'll accept it.
Hey, you're welcome :-)
You need to make sure (as written in the article), that port 445 on the target machine can be accessed.
On the machine you come from, install telnet client (->press winkey+r, launch appwiz.cpL and go to "add windows features", there, find "telnet client"). When installed, open a command line and launch:
Open in new window
If the screen does not go black, the port is inaccessible.