We recently ran into an issue at my work when using Microsoft Remote Assistance. We’d be able to remote into a user’s PC using Remote Assistance just fine, but then when we ran something that needed admin rights, We’d go from a normal screen to this:

MSRA with UAC Secure Desktop prompt

Well that’s not good. The user would be presented with a normal UAC dialog box with a prompt to put credentials in, but the tech helping them just saw a big black box. This was happening because UAC prompts don’t quite go to the user’s desktop, but rather to something called Secure Desktop. To quote Microsoft:

The Secure Desktop’s primary difference from the User Desktop is that only trusted processes running as SYSTEM are allowed to run here (i.e. nothing running as the User’s privilege level) and the path to get to the Secure Desktop from the User Desktop must also be trusted through the entire chain.”

What this means for those using Remote Assistance to help out a user, is that the UAC prompts can be viewed and interacted with on the user’s console, but not via the Remote Assistance session.

The way to “fix” this issue would be to simply disable Secure Desktop, which would keep UAC on, but now present the UAC dialog box on the user’s desktop (and also on the Remote Assistance session). After reading more about Secure Desktop though I decided the need was too small to justify disabling it, as it significantly weakens UAC’s protections, and most especially since we were able to workaround this issue by simply RDPing in as an administrator. With that warning in mind, here’s how to disable Secure Desktop if you decide that’s what’s needed in your environment:

In Group Policy, go to “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options”, and from there go to the policy “User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop”. From there check off “define this policy setting”, and make sure “enabled” is selected.

I needed to migrate a VM from one ESXi server to another the other day. I figured the best way to do this would be to SCP the VM from the datastore on ESX1 to the datastore on ESX2, and then just register the copied VM in it’s new home on ESX2’s datastore. This’ll be easy! I SSHed into ESX1 and pointed the VM’s directory towards it’s new location on ESX2:

Really? Connection time out? I know I can SSH into both ESXi servers, so it’s not an issue with the SSH service. What then? I remote into the other server and reverse the command to see where that gets me:

Alright I KNOW I’ve SCPed files into this Debian server before. I try SCPing a file from the Debian server to the ESXi host…

touch testfile.txtscp testfile.txt root@ESX2:/vmfs/volumes/datastore1

testfile.txt 100% 0 0.0KB/s 00:00

Success! So far now we have observed the following:

an ESXi host cannot send a file to another ESXi host

an ESXi host cannot send a file to the debian server(that is known to be able to receive files)

an ESXi host CAN receive files from the debian server

From which we can conclude:

the ESXi hosts can receive files

the ESXi hosts cannot send files

What is it then? ESXi’s firewall! It apparently prevents outbound SSH traffic by default, so any attempt to SCP or SSH from it is blocked by its own firewall. VMware even provides a ruleset that defines outbound TCP traffic on port 22 called “sshClient”, so in order to allow outbound SSH, we just have to run the following command:

Posts navigation

Text Widget

This is a text widget. The Text Widget allows you to add text or HTML to your sidebar. You can use a text widget to display text, links, images, HTML, or a combination of these. Edit them in the Widget section of the Customizer.