Enhanced Session Mode in Client Hyper-V

Hyper-V’s Enhanced Session Mode technology is available for both the standard Hyper-V editions and Client Hyper-V. I’d argue that it’s far more useful for Client Hyper-V. The only common use case involving users interacting directly with the console of a server Hyper-V guest is VDI, and that does not involve Enhanced Session Mode. Enabling Enhanced Session Mode for a server’s guest would be somewhat exceptional. Client Hyper-V reverses that convention. It is normative to directly interact with locally-hosted virtual machines. Therefore, Enhanced Session Mode is preferred for Client Hyper-V.

What is Enhanced Session Mode?

From a technological standpoint, Enhanced Session Mode ties the VMConnect.exe application into the Hyper-V host’s VMBus component. If you’re not familiar with VMConnect.exe, this is the application that you use any time you connect directly to the console of a [Client] Hyper-V guest (ex: clicking Connect on the context menu of a virtual machine in Hyper-V Manager). This allows some communications between the operating environment that you’re connecting from and the guest operating environment that you’re connecting to. Furthermore, VMConnect.exe employs several technologies from the Remote Desktop Client.

Notable capabilities enabled by Enhanced Session Mode:

• Making local resources, such as printers, disk drives, and USB devices, available to the guest through the console connection.
• Copy and paste of files to and from the connecting system and the target guest system.
• Additional screen resolutions and full-screen mode.
• Smart card logins.

To state it simply, Enhanced Session Mode transforms the VMConnect.exe experience to match the Remote Desktop Client experience.

What are the Use Cases for Enhanced Session Mode in Client Hyper-V?

In general, I think it’s fair to say that if you’ve got a Client Hyper-V virtual machine that you use on a regular basis, you want Enhanced Session Mode. If you’re just testing something out quickly and only need to pop in and out of a particular guest operating system, it’s not that critical. If you’re using something for long periods of time, the small window and walled garden of a virtual machine without an enhanced session will eventually feel restrictive.

I could take the easy way out in this session by enumerating the common reasons for Client Hyper-V, such as development and testing environments, then tack on some blurb about how Enhanced Session Mode would make all of that better. You can probably figure all of that out on your own. Instead, I want to paint a very stark picture that contrasts a standard session against an enhanced session. We’ll do that through two use case scenarios.

Client Hyper-V, Enhanced Session Mode, and Security: The Sandbox Use Case

A user forwards an e-mail to you that they receive from someone that they trust, but it has an attached file. The user also says that the phrasing of the message just doesn’t feel right. So, you pop the attachment into your virtual machine to open it in a contained environment. Pop quiz: should you use Enhanced Session Mode with that virtual machine or not?

The answer might surprise you. If you said, “Do not use Enhanced Session Mode”, then you get high marks for thinking securely, but I must deduct points for not having thoroughly done your homework on Enhanced Session Mode.

Let’s start with why you would not want to use Enhanced Session Mode for poking at potential malware. Without Enhanced Session Mode, that virtual machine is essentially a walled garden. Hyper-V isolates its operating environment from the host’s operating environment naturally. Files and data cannot be transferred out of the guest to the host by any means other than a network connection, which is very easily locked down by simply not connecting the virtual machine to a network. You could place the suspect file into a VHDX, attach the VHDX to the virtual machine, and open it up without ever placing any other machine, including the host, at risk. Well done!

But, you worked harder than you had to.

These are the exact steps to accomplish the same feat using an Enhanced Session Mode guest in Client Hyper-V:

1. In Hyper-V Manager, take a checkpoint of the virtual machine. Optionally, give that checkpoint a descriptive name.
   

   Checkpointing in Client Hyper-V

    

2. Disconnect the virtual machine from the network, if it’s connected.
   

   Disconnected VM

    

3. Copy and paste the file from your desktop into the virtual machine’s desktop. This will only work if Enhanced Session Mode is enabled.
   

   File Pasted from Host to Guest

    

4. In the VMConnect console pane, click the Basic Session button.
   

   Basic Session Button

    

   Alternatively, click View and Enhanced Session to uncheck it.

5. Your VMConnect session will end and immediately reconnect. Some guest operating systems will lock your session when this happens, causing you to need to log back in. Do so.
6. Test the file with whatever tools you have available in the guest operating system.
7. Once your testing is complete, revert the checkpoint. This irrevocably discards everything that was done in the virtual machine since the last checkpoint was taken.
   

   Revert Checkpoint in Client Hyper-V

    

8. Delete the checkpoint.
   

   Delete Checkpoint in Client Hyper-V

    

9. Clean up by deleting any remnants of the file in your desktop operating system and performing any necessary reporting on your findings.

The next time you connect to the virtual machine, the host’s normal Enhanced Session Mode setting will be in effect. That means that if it was enabled when you started this procedure, it will be enabled the next time that you connect.

The purpose of this exercise is to show you that Enhanced Session Mode can be toggled off and on easily. You can use the same virtual machine with an open copy/paste and device configuration, then switch to the isolated walled garden at a moment’s notice.

Client Hyper-V, Enhanced Session Mode, and Security: The Administrative Privileges Use Case

A common security best practice for administrative staff is to maintain separate administrative logins and non-administrative logins. You should conduct your menial, yet dangerous activities in a non-privileged session. Those activities include e-mail and web browsing. Administrative duties, such as Active Directory tasks, can be carried out either by Run As or inside an administrative session. There are problems with the traditional techniques.

The Problems with Common Approaches to Session Isolation

The oldest technique involving this separation is secondary logon, or Run As.The Run As approach has multiple problems. For one thing, it’s not all that well-implemented. I have problems with several applications and secondary logins. Somewhat embarrassingly (for them), most of those applications are made by Microsoft. Another problem is that Run As crosses an administrative login with an active non-administrative login. That opens up a path, however narrow, for malware to compromise the administrative session by way of the non-administrative session.

To address this, some administrators have begun using virtual machines. That allows them to have two well-isolated sessions running side-by-side. That approach has merit, but, as we’ve discovered over time, most of us do it wrong. We log in to our root session (the one that the hardware boots to) as a non-privileged user, then spin up a virtual machine running an administrative session. That makes sense on the surface, because the root partition usually provides a superior user experience for the applications that we use most, such as e-mail clients and web browsers. From a security perspective, that’s bad.

What’s wrong with it? Well, a compromised host equals a compromised guest, that’s what’s wrong with it. Consider this:

1. I’m running my desktop Win10 as a low-privilege user and a Win10 guest as a high-privilege user.
2. I open an e-mail with a malicious attachment, which infects my machine.
3. The attacker uses a system exploit and gains root access to my desktop.

What’s part of my desktop? That virtual machine with the privileged session, that’s what. The attacker now owns both of my sessions. What we’ve done is grant the low security session a control link over the high security session, which is an immediate security no-no.

That’s not the only problem. With Client Hyper-V, you need to run Hyper-V Manager and/or VMConnect with administrative privileges, or you can’t even connect to your virtual machines. If you sidestep that with another desktop hypervisor, you’re still going to be at least occasionally doing things via Run As. There’s just no way to avoid being an administrator in the root console. What to do?

Solving Session Isolation Problems with Client Hyper-V

Since you can’t avoid being an administrator in the root session, don’t try. Log on to the root hardware as administrator. What!?! No, I’m not crazy. However, this practice requires discipline:

• Never surf the web in an administrative session
• Never use e-mail in an administrative session
• Never run untrusted or unknown applications in an administrative session
• etc.

With proper discipline, your management environment should never be at meaningful risk of compromise because you never expose it to such risks.

I have no doubt that you’re thinking, “easier said than done”. I agree. Let Client Hyper-V help.

1. Log in to your root operating system as an administrative account and set it up with all of your fancy administrative tools. Enable Hyper-V, etc.
2. Create a virtual machine.
3. In the virtual machine, install all of your day-to-day “unsafe” applications that you use, like Outlook and Word and your music app. Leave Enhanced Session Mode on.
4. Log on to the virtual machine as your non-privileged account.

In this configuration, the high security environment has control over the low security environment, as it should be. Do you need to download a file for use in the administrative session? Fine. Download it in the low security virtual machine, verify it there, then copy/paste it into the high security session. If your root operating system is compromised, it has the same net effect that it would if you were doing things the other way around. If your non-privileged guest is compromised, then trash it and start over. You lose nothing and stand to gain much security.

The remaining problem in this use case is, of course, usability. That’s where the rest of Enhanced Session Mode comes in to play.

Enabling Enhanced Session Mode in Client Hyper-V

Enhanced Session Mode is on by default in Client Hyper-V, so you should not need to do anything. To verify it, right-click on the local system in Hyper-V Manager and click Hyper-V Settings. Verify that both of the indicated locations in the screenshot below are enabled.

Enhanced Session Mode Configuration

If these are set, any time Client Hyper-V is able to detect that the guest operating system supports Enhanced Session Mode, it will be active.

Video Enhancements in Enhanced Session Mode

If you’re balking at doing your daily operations like web browsing in a Client Hyper-V virtual machine because you do that sort of thing much more often than you work in your administrative session, this is one of the mitigating points. Make your non-privileged guest full screen. When you connect to a guest in VMConnect and it detects that Enhanced Session Mode is available, you’ll get this (unless it has a RemoteFX adapter):

Enhanced Session Mode Video Options

If you drag that slider all the way to the right, it becomes Full Screen. Then it looks a lot like when you use Remote Desktop Connection. Do your work in that full screen session, and minimize back to your primary desktop if you need to. You can also “Restore” it and becomes a very large window that you can move around. Double-click on its title bar to return it to Full Screen mode.

Audio, Printers, and USB Devices in Enhanced Session Mode

For me, audio rounds out what I want in my non-administrative session. I work in an environment with lots of people which means lots of distracting noise. Noise-cancelling headphones and a solid playlist constitute the thin wall that keeps me in the land of sanity. Client Hyper-V doesn’t let me down.

In that connect dialog that you saw in the previous section, click the down arrow next to Show Options, then switch to Local Resources.

Client Hyper-V Local Resources

Most things that you’ll want to connect can be found on this dialog. One thing to note is that sounds in the virtual machine will be transmitted back to the host by default, but your connected microphones do not transmit into the guest by default. To change that, click the Settings button in the Remote audio section and select Record from this computer under Remote Audio Recording.

Client Hyper-V Remote Audio

You can see the Printers and Clipboard checkbox in the first screenshot. Those are selected by default, so copy/paste and printers should already be functional from the first time that you connect. Printers aren’t perfect, especially with networked printers. For those, I just connect to them as though I were using a physical system and all is well.

But, there are other devices that you might want to use. From that first dialog, click the More button to be greeted with a dialog similar to the following:

Additional Devices in Client Hyper-V

I don’t have any USB devices to speak of, so nothing appears here for me. If you have a special USB device, this is where you’ll go to enable it. If you don’t see it, make sure to check Other supported Plug and Play (PnP) devices and Devices that I plug in later. That’s your best bet to getting that device to work.

In my case, I like to share files between host and guest without copy/paste (be mindful of the potential security risks with that and maintain discipline — execute unknown/untrusted files in the low security environment only). I have a storage disk that I map. In the above image, that’s Storage (D:). In the guest, it looks like this:

Client Hyper-V Mapped Drive

It’s more easy to bulk-manage files using a mapped drive as opposed to host/guest clipboard copy/paste.

What’s Not Available in Enhanced Session Mode?

For a work environment, there aren’t many drawbacks to Client Hyper-V aside from the cost to properly license each guest. Aside from a natural human reluctance to change long-standing practices, it’s a winning solution.

Home users, though, even home users like me that still try to practice safe computing, face a problem. You’re not going to be doing any serious video gaming in a Client Hyper-V guest. HTML and Flash games, sure. Java games, maybe. AAA games? Absolutely not. Not even with RemoteFX. Maybe in the next version.