About Peter Brown

I am a Senior R&D Manager working in the VMware development offices in London, UK. I am primarily responsible for the team working on USB redirection within the VMware Horizon View product.

VMware Development Labs Sneak Peek: Serial Redirection in Horizon with View

By Peter Brown, Senior R&D Manager, VMware, London, UK


With this blog, we introduce a new series of occasional End-User-Computing blogs called Sneak Peeks, where we discuss features and functionality we are working on in the Development labs. This gives us a chance to share the kinds of things we are thinking about and, in turn, to hear your ideas. We hope you find this new series informative and thought-provoking.

Over the years, I have worked with many devices that were connected remotely to VDI desktops using USB redirection. Some of these devices can be troublesome when using USB with a remote connection—due either to bandwidth requirements (for example, webcams) or latency sensitivity (for example, serial ports).

I am delighted to announce that we have recently been working in the labs on adding serial port redirection to Horizon with View. Similar to webcam redirection, we can solve the problem for serial ports by capturing the serial data at the client side, packaging it and delivering it to the guest, and presenting it back by way of a virtual COM port.

We are progressing well, and the functionality is looking great. We would, however, like to engage with our users, who have real-world experience with serial devices, for their thoughts about this functionality. Some devices are simple (for example, GPS receivers) and periodically send a burst of data to a terminal, whereas others are much more complicated. Many serial devices are quite old, and were designed to be connected by way of a few meters of cable to the computer. They certainly were not designed to be used remotely over tens or hundreds of miles!

Therefore the devices or applications used are often sensitive to the timing of the messages received. Also, many of the applications need bespoke applications that are often tightly coupled with a company’s internal applications and processes (for example, banking systems or production lines), making testing with such devices difficult for VMware engineers. Such devices often also have “dip” switches to change the mode of the device, and, as a result, the VMware solution may also require a number of different configuration settings to enable specific features in certain environments. These would likely be enabled through either the registry or by way of the port properties UI (for example, see the tool tray pop-up UI in Figure 1 which allows the mapping of physical to virtual com ports).


Figure 1: Tool Tray Pop-Up User Interface

Therefore, we would like to hear from you about which serial devices and which applications you would like to use remotely with View desktops. To facilitate this, we have set up a community forum thread on Serial Port Redirection in Horizon with View, where we can discuss some of the devices and apps that you would expect to work with this functionality. We want to do as much pre-validation of such devices and apps as possible so that when the functionality is launched, “it just works”! So, do visit the forum and tell us what you think.

I will keep you updated with progress, and will let you know when we launch this new functionality.

How Bad Is BadUSB with USB Redirection in VMware Horizon with View?

By Peter Brown, Senior Research & Development Manager, VMware, London, United Kingdom

BadUSB has been getting a lot of press lately. For those of you who have not heard, this is a new security threat in which the firmware on some USB devices can be hijacked and replaced with malware. For example, a device can be made to redirect network traffic, or emulate a keyboard and capture keystrokes, or worse. A number of Web pages are talking about BadUSB, for example When Good USB Devices Go Bad, The Unpatchable Malware That Infects USBs Is Now on the Loose, and the original Blackhat presentation, BadUSB—On accessories that turn evil.

Scary stuff, and unfortunately we have no magic cure. We have all been using USB devices for years, and we all probably have many such devices at home and in the office. So how can an enterprise using VMware Horizon with View for VDI protect itself, or what can it do to minimize the risk? This blog post aims to answer those questions!

Disabling All USB Devices

For the ultimate protection, all USB devices should be disabled. This is quite hard to do on desktop machines, especially if the enterprise has a desktop machine on every user’s desk. However, when using View, this is relatively easy to achieve in one of three ways.

Do Not Install the USB Component on the View Agent

You can configure the desktop guest image (in the data center) so that the View Agent has the USB component “not installed.” This entirely prevents USB devices from being used in that desktop image. Then refresh all your desktop images so that the USB component is removed.

Disable USB Devices for Specific Desktop Pools

If you do not want to change the desktop image, from the View Administrator UI, navigate to Desktop Pools and select a specific pool. Next, select Policies within that pool. Finally, select Desktop Pool Policies and click Edit Policies, and disable USB redirection for a specific pool or pools.


You can also apply user overrides to enable or disable USB redirection on a per user basis in a specific pool. This is also done by way of the same View Administrator window, with the User Overrides choice (next to Desktop Pool Policies in the window).

Use GPOs to Disable All USB Devices on the View Agent

Alternatively, you can apply the ExcludeAllDevices configuration option on the View Agent by way of GPO configuration to prevent any devices from being forwarded.

Disabling Specific USB Devices

Disabling USB devices entirely is certainly the best way to completely avoid the risk of BadUSB. In some cases, however, disabling USB devices entirely might not be feasible because you may need specific USB devices to function for your use cases; an example might be doctors using Dictaphone-type USB devices to record patients’ records. In this case, it is not possible to entirely block USB devices, and so the following strategies should be employed to help mitigate the risk.

Educate Employees About Types of USB Devices to Connect

It is important that you completely trust any device connected to your enterprise, regardless of settings, and that includes trusting your supply chain and ideally having some sort of chain of custody as well. You should educate your employees to ensure that they do not connect devices from unknown sources. If possible, try to restrict the devices used in the environment to devices that accept only signed firmware updates, are ideally FIPS 140-3 Level 3-certified, and do not support any kind of field-updatable firmware. These types of USB devices are definitely hard to source and, depending on your specific device requirements, may be impossible to find. This may not be a practical solution to the problem, but certainly worth considering.

Exclude Some Devices Through the Group Policy Editor

You can allow only specific USB devices to be used. Each USB device has its own vendor and product ID that uniquely identifies it to the computer. Rather than allowing View to forward any USB device into the guest virtual machine, you set an Include policy for known device types. Then you can remove the risk of unknown devices being inserted, which might compromise the system. Of course, there will be ways around this, but you do reduce that risk.

Here is an example of how you can configure View to block all devices from being forwarded to the View virtual desktop, except for a known device vendor and product ID (vid/pid = 0123/abcd in this case):

ExcludeAllDevices   Enabled

IncludeVidPid       o:vid-0123_pid-abcd

Note: We should point out that while this sample configuration provides some protection, a compromised device can report any vid/pid, and so there is still a possible attack vector here.

You set these Global Policy Object (GPO) values in the View Agent Group Policy editor.

Note: By default, View blocks certain device families from being forwarded to the View desktop, for example, HID (human interface devices) and keyboards. So with the default filter policy enabled in View, such keyboard devices would be automatically blocked from appearing in the guest. Some of the released BadUSB code targets USB keyboard devices, and this default in View already protects these devices from the malware.

Specific device families can instead be blocked if required. For example, the following GPO value would block all video, audio, and mass storage devices:

ExcludeDeviceFamily o:video;audio;storage

Another configuration example is to block all devices, but only allow a specific device family (whitelist). For example, block all devices, but enable storage devices. This could be done as follows:

ExcludeAllDevices       Enabled

IncludeDeviceFamily     o:storage

Another risk might be someone from outside your office logging in to a desktop and infecting it. Again, this cannot be seen as a complete mitigation, but you can block USB access completely to any View connections that originate from outside the company firewall. The USB device could be used internally, but not externally.

To do this, block the TCP port 32111 from the View security server to the View desktops. Zero clients are slightly different, as the USB traffic for those is embedded inside a virtual channel on UDP port 4172. Because port 4172 is not used only for USB (it also carries the display protocol), it is not possible to block that port. You can disable USB on zero clients if required. Look at the zero client product literature or contact the zero client vendor for specific details.

Blocking certain device families or specific devices can help to mitigate the risk of BadUSB malware, but not completely solve it.

If you want to know more about USB redirection in View, check out my white paper USB Device Redirection, Configuration, and Usage in VMware Horizon with View.

USB 3 Device Redirection Now Available with VMware Horizon with View Virtual Desktops

By Alexander West, Technical Writer, End-User-Computing Technical Marketing, VMware, and Peter Brown, Senior R&D Manager, VMware

We are all familiar with using USB devices on our laptops and desktops. With the USB device redirection capabilities of VMware Horizon with View, end users can use those same USB devices with their View virtual desktops.

But that is old news. Here is the exciting part: In addition to USB 1 and 2 devices, USB 3 devices are now supported with a combination of View Agent 6.0.1 and Horizon Client 3.1.

But before we get to USB 3 device redirection, let us take a look at USB device redirection in View. Continue reading

USB Device Redirection in VMware Horizon with View: White Paper and Video

By Peter Brown, Senior R&D Manager, VMware, London, UK

We are all accustomed to using USB devices with desktop PCs and laptops in the form of mass storage devices, headsets, webcams, scanners, printers, and more. In the virtual world, where your actual desktop may be many miles away from your client device, physically plugging in a USB device is not possible. VMware Horizon with View supports using USB devices in the virtual desktop by using USB device remoting. View 5.1 and later introduced some complex configuration options for the usage and management of USB devices in a View virtual desktop session.

In order to assist users with these remoting options, I have published a white paper that gives a high-level overview of USB redirection, discusses the configuration options, and provides some practical worked examples to illustrate how these options can be used. USB Device Redirection, Configuration, and Usage in VMware Horizon with View is now available. I hope that this white paper will help you navigate some of the difficulties, options, and configurations to maximize the VDI end-user experience.

As a supplement to the paper, I have helped put together a video, Using Composite USB Devices in Horizon View Desktops, which talks viewers through USB-device splitting, and shows a worked example of how to configure splitting for a USB dictation audio-device.

Download the white paper: USB Device Redirection, Configuration, and Usage in VMware Horizon with View

View the USB device-splitting video: Using Composite USB Devices in Horizon View Desktops

If you have any USB-related questions for Horizon with View, please visit our forum to check out other discussions for help, or to post your own questions:

VMware View USB Community

Real-Time Audio-Video Has New Virtual Webcam Driver in Horizon 6.0!

By Peter Brown, Senior R&D Manager, VMware

In my previous blog posts on Real-Time Audio-Video (Part 1, Part 2, and Part 3), I talked about using RTAV on Windows, Linux, and OS X clients. We have had loads of really positive feedback about the functionality, and it has been great to hear how well received the feature is. We did however get some reports that some third-party applications did not work with the virtual webcam driver that we previously released. Typically these were in-house bespoke applications which of course we had been unable to test. Applications such as Skype, WebEx, and Google Hangouts worked very well with the driver, but we also found some web-based applications worked, but not with later versions of Internet Explorer (for example, IE10, IE11) and Chrome with the built-in PepperFlash. Continue reading

Real-Time Audio-Video (RTAV) for Horizon View, Part 3

By Peter Brown, Senior R&D Manager, VMware

In my first Real-Time Audio-Video (RTAV) blog post, I introduced RTAV for Horizon View virtual desktops and discussed configuration primarily on the Windows platform. Then, in my second RTAV blog post, I talked about the added support for RTAV on Linux View Clients in Horizon View Client version 2.2. The new View Client version 2.3 has just been released, and I am excited to announce that we now also support RTAV on the Mac OS X View Client! I want to take this opportunity to provide some details about RTAV with respect to OS X and how it can be installed, used, and configured.

Continue reading…

Real-Time Audio-Video Test Application for Horizon View Released As a VMware Fling

By Peter Brown, Senior R&D Manager, and Tarique Chowdhury, Senior Member of the Technical Staff, VMware

We have just released our Real-Time Audio-Video test application for Horizon View as a VMware Fling. This is a tool that we have used internally during the development of RTAV and which has proven very useful for quick tests, and also longer-term scale-and-performance testing in Quality Engineering. We have also held a number of internal demos and training events, and we have frequently been asked by the Systems Engineers if the application is available for them to use externally either for demos or for customers to use for qualification. As a result of high demand, we decided to release the tool as a Fling!

This application is useful for verifying correct installation and operation of the Horizon View Real-Time Audio-Video functionality. It provides a “player” application which will display the “virtual webcam” feed, and also loop back the audio-in if required. This allows testing to be done without the need for a 3rd-party app (which often requires user accounts to be created such as Skype, WebEx, etc.). The app can also be useful for performing load testing, by forcing the video and audio stream to continuously run (without a 3rd-party app dropping the call or ending it after a period of time). The application can also be used on a Windows Client OS to show that the physical webcam and microphone are correctly configured and installed. (On Linux clients, we used an application called “Cheese” for this purpose.) Note that if you loop back the audio, then the audio and video will not be synchronized. This is expected behavior due to the way the loopback is done. When using RTAV with a real 3rd-party app such as Skype or WebEx, the audio and video are synchronized. It is, however, still useful to have the loopback enabled so that you can verify the bandwidth requirements for a RTAV session in your environment.

The application

  • Displays webcam pictures at 1:1 resolution
  • Automatically starts streaming images, on launching the application (and audio will be looped back, if selected)
  • Loops the audio-in (e.g., from VMware Virtual Microphone) back out to the audio-out
  • Tests RTAV functionality without the need to create user accounts
  • Supports the VMware Virtual Webcam and Physical Webcams
  • Runs on x86 and x64 Windows OSes

Sample screenshot below, with a cheesy still image showing Peter and Tarique!


The application requires that the Microsoft 2008 C++ x86 (SP1) runtime components be installed. These are already installed on a Horizon View desktop, but if you want to run the application on a physical client machine without having Horizon View installed, then you may need to download and install these first. You can get them from the Microsoft Download Center.

Once the runtime components are installed, then the application can be run directly–it is a standalone executable which does not need installing or configuration. This makes it very easy to deploy for quick testing.

If you want to use the RTAV test application, download it from our Flings page.

Real-Time Audio-Video (RTAV) For Horizon View, Part 2

By Peter Brown, Senior R&D Manager, VMware

In my last Real-Time Audio-Video (RTAV) blog, I talked about the support we added for webcams and microphone devices in VMware Horizon View Feature Pack 2. Feature packs are installed alongside the View Agent on the virtual desktops in the datacenter, and View Clients are installed on the devices used to interact with those desktops. Horizon View 5.3, Horizon View 5.3 Feature Pack 1, and the Horizon View Clients version 2.2 have just been released, and with these come support for RTAV in Linux Clients, and also a new Windows Client. I want to take this opportunity to provide some details about RTAV with respect to these new client and feature pack releases.

Linux Support for RTAV

Continue reading

Real-Time Audio-Video (RTAV) for Horizon View

By Peter Brown, Senior R&D Manager, and Tarique Chowdhury, Software Engineer

Webcam support in VMware Horizon View is a feature that has frequently been requested.

It is therefore with great pleasure that we are able to bring you Real-Time Audio-Video functionality. This functionality enables the support of webcams and audio-in and audio-out  in Horizon View, without the need to use USB redirection. Analog audio-in devices are also supported!

This blog gives a quick overview of the Real-Time Audio-Video functionality, along with some quick tips and guidance on its use and configuration. There is also a short YouTube video covering similar topics available here: http://youtu.be/mG0ke377FOw.

Why Were Webcams Not Supported?

It has not been feasible to support webcam functionality via USB redirection – mainly due to the bandwidth that webcams consume. For example, most webcams send uncompressed images over USB at a high frame rate. Tests in our lab show that many cameras consume around 60 to 80Mbps! This is bandwidth consumption which obviously does not scale in a VDI environment.

Audio-in functionality that has been supported in Horizon View was always done via USB redirection. The quality of audio using USB redirection (in or out) depends greatly on network conditions and guest load. Some improvements were made recently in this area which will help some devices – see the Knowledge Base article How to improve audio quality when using USB headsets or speakers with a View desktop.  Audio-in using analog-style devices (e.g., with 3.5mm audio jacks) were not supported at all.

Audio-out (for example, playing music in the guest desktop, but hearing the audio from the local client) via PCoIP audio redirection has been supported in Horizon View for some time, and this gives a much higher audio quality than using USB redirection.

However you can’t split a USB audio device such that the audio-out functionality remains local to the client and the audio-in is redirected. So using a USB headset in a VoIP type application required the entire headset to be forwarded to the guest. Again, the audio quality then greatly depends on network/load. More information about USB forwarding can be seen in USB Device Redirection in VMware Horizon View 5.1 and 5.2.

Overview of Real-Time Audio-Video

Real-Time Audio-Video (RTAV) does not forward audio and webcam devices using USB. Instead the devices are left local to the client, and audio/images are pulled from the local devices. The audio/images are then encoded, delivered to the guest virtual machine, and decoded. A virtual webcam and a virtual microphone are installed in the guest virtual machine, which then “play” the received audio/video, and 3rd-party apps (e.g., Skype, WebEx, Google Hangout) can use these virtual devices.

Audio-out is performed from the standard View Agent audio-out functionality which provides better audio quality than using USB redirection.

Due to the fact the images and audio are being encoded, this results in much better bandwidth usage (more on this later), allowing this feature to scale across many desktops.

RTAV can support:

  • Webcams and audio-in at the same time; e.g., for VoIP video-conference-type applications
  • Audio-in only (without video); e.g., VoIP-type applications
  • Webcam on its own; e.g., for webcam-monitoring-type applications, or user photo-taking, etc.[We would love to hear about any interesting use cases you find for this functionality, as we are sure there will be many interesting things you can do with this!]

Note that RTAV only works when using the PCoIP protocol. It does not work with RDP.

How Do I Enable This Feature?

This feature currently works only on Windows clients, although other clients will add support for RTAV in due course. You will need the Horizon View Windows Client 5.4 or the new Windows Client v2.2 or later. [note, other Client OS may be supported in the future so check back for other blog updates]

In addition on your guest virtual machine, you need a Horizon View 5.2 (or later) View Agent along with the VMware Horizon View 5.2 Feature Pack 2. These can be downloaded from the Horizon View Downloads page. The optional RTAV component can be installed via the Remote Experience Agent, so make sure this is installed!

Making Your First RTAV Call

RTAV functionality is now enabled and activated by default. It is expected that it should just work!

You should not forward the audio or video devices using USB – if the devices are left local to the client, then RTAV can use them. Any devices forwarded via USB to the guest are not available for use by RTAV.

At your guest, you should see a “VMware Virtual Microphone” and a “VMware Virtual Webcam” available as options in your 3rd-party applications. Make sure these are selected for use.

Simply start a call in your 3rd-party application, and RTAV should just work.

Ending a call stops the capturing from the audio/video device.

Note that if your camera is in use (e.g., you are in a Skype call) in the client machine, then it will not be available for use in the guest and vice versa. The camera can be shared between applications in the client and guest, but not at the same time.

Which Devices Are Selected from My Client?

You may have multiple audio and video devices available on your client machine. If the video or audio does not come from your expected source device, then you may need to select a specific source device for use.

We believe that all webcams should be supported – however, we have of course not been able to test with every single webcam ever produced, so it is possible that we don’t support some. Do let us know if you find a device that does not work.

We also suspect (but have not tested) that other video source devices may work too. For example, TV tuners?! [We would love to hear about any fun use cases you identify with non-webcam devices!]

In terms of audio devices, any type of audio input device supported by Windows should work. Whether these be analog-in using the older 3.5mm jack plugs, or digital devices such as USB headsets, they should all be usable.


It is expected that you will have multiple audio input options (e.g., built-in microphone, external USB headset, possibly analog audio-in, and even microphones built into a webcam!). Usually things should just work, but you may want to configure the system to select audio from a specific audio input device.

By default, RTAV will use the “default” audio-in device as specified in Windows Recording Sound Properties.

To select a different source audio device for RTAV:

  1. End your current RTAV session if one is active (by stopping a call in the 3rd-party app).
  2. On the client machine, right-click on the speaker icon in Notification Area Icons and select “Recording Devices” (or via Control Panel –> Sound).
  3. Right-click on the device you want to use, and select “Set as Default Device”:
  4. Now start a new call in the guest, and the new audio-in device should be used. (No need for any Windows restarts!).

If you do not want to change your default client-side settings, it is also possible to configure the View Client to select a specific audio device if it is available. This is termed a “preferred” audio device. If the preferred audio device is not available, then the Windows default device would be used instead.

To configure a preferred device (remember this isn’t necessary and Windows default device selection is probably sufficient):

1. Start and stop a call in your guest 3rd-party app where your preferred device is connected to your client machine (this generates the necessary log messages).

2. On your client machine, find the log file:

Windows XP
C:\Documents and Settings\username\Local Settings\Application Data\VMware\VDM\Logs\

Windows 7 or Windows 8:

3. Open the latest debug log in a text editor (titled “debug-20XX-XX-XX-XXXXXX.txt”), and search for the following text:

[ViewMMDevRedir] AudioCaptureBase::LogDevEnum

In a log on our system here, we can see something like:

[ViewMMDevRedir] AudioCaptureBase::LogDevEnum – 3 Device(s) found

[ViewMMDevRedir] AudioCaptureBase::LogDevEnum – Index=0   Name=Headset Microphone (Plantronics C620-M)   UserId=vid_047f&pid_aa01&mi_00#7&3361ff59&0&0000   …

[ViewMMDevRedir] AudioCaptureBase::LogDevEnum – Index=1   Name=Rear Input (SoundMAX Integrated Audio)   UserId=func_01&ven_11d4&dev_194a&subsys_10280293&rev_1004#4&cebec42&0&0001 …

[ViewMMDevRedir] AudioCaptureBase::LogDevEnum – Index=2   Name=Microphone (Webcam 200)   UserId=vid_046d&pid_0802&mi_02#7&2b5ee315&0&0002   …

4. Decide which of the devices you want to make the preferred device, and copy the UserId text.As an example, let’s say you wanted to make the microphone in your webcam the default, you would copy the values “vid_046d&pid_0802&mi_02#7&2b5ee315&0&0002”

5. Start the Registry Editor (regedit.exe). Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\RTAV

6. Paste the value copied in step #4 into the REG_SZ  value srcAudioInId.

7. Save your changes and exit the registry.

8. Start a new call, and, providing the preferred device is available, then it will be used (regardless of the default device selected in Windows).


Windows does not have a concept of a default webcam. So, if you want to override the one that is selected for you by RTAV, then you need to edit the preferred video device. Again, like audio, if the device is available on your system, then it will be used, but if not, then an alternative device would be selected automatically.

If you want to set a preferred video device, then follow similar steps to the audio:

1. This time, look in the logs for device enumeration with logs looking like
[ViewMMDevRedir] VideoInputBase::LogDevEnum

2. Again, select the UserId for the device you want to use, but this time copy/paste that value into the registry in a field REG_SZ  value srcWCamId.

Configuring the Video Resolution and Frame Rate
(and Therefore Bandwidth!)

The video resolution and frame rate affect the bandwidth of the encoded video stream to the guest desktop. Precise numbers cannot be provided because the actual video image itself has a bearing on the encoded bit rate, so you will need to do some testing in your own environment.

By default, RTAV runs at 320×240 resolution @ 15 frames per second (fps).

If you want, then these can be adjusted up to a maximum value set by the administrator.

As an example of typical bandwidth consumed, we ran some tests here with a typical “office” webcam setting. As mentioned, actual values recorded on your system may vary from this a bit.

All tests were run @ 15fps.


Bandwidth (Kbps)

160 x 120


240 x 180


320 x 240


480 x 234


640 x 480


720 x 540


If you increase the frame rate, then the bandwidth will be higher than this, and reducing frame rate will lower it.

Depending on your webcam, you may not be able to encode and send higher resolutions than this at a full 15fps. If you request big resolutions (that your webcam does not support), then client-side scaling is done, and this takes time. In addition, encoding and decoding requires more CPU cycles, and hence the resultant frames per second may be lower than requested. You will see from logs at the end of a call what the resulting frame rate was, so you can run tests to adjust resolution/bandwidth to suit.

During development, we wondered about restricting the maximum frame size to a value where we could be certain that you could achieve the maximum frame rates, however we decided that some customers may have interesting use cases where they would prefer a larger image, but were okay with a much lower frame rate, and therefore we decided to leave these settings adjustable.

Setting Administrator Configuration Limits

Administrators can configure / restrict the use of RTAV via agent-side GPOs. To do this, load the RTAV GPO template vdm_agent_rtav.adm (available for download in the GPO bundle) into the group policy editor.

The GPO provides the following options:

GPO Value Default Comment
DisableRTAV 0 Disable the use of RTAV by configuring this field to 1. It is enabled by default (and set to 0).
WebcamMaxFrameRate 25 Configure a maximum frame rate available to clients. Out of the box, the absolute maximum is 25fps.
WebcamMaxResWidth Not set This is the maximum image width supported. By default, no limit is set (other than a hardcoded limit of 1920).
WebcamMaxResHeight Not set This is the maximum image height supported. By default, no limit is set (other than a hardcoded limit of 1080).

Remember that the above webcam settings are a “maximum” limit, and so the client can select any value up to the maximum. By default, the clients operate at 320×240 (width x height in pixels) at 15fps.

Setting Client-Side Resolution / Frame Rate

It is possible to configure image frame rates and resolution up to the maximum value specified by the administrator. If the value specified in the client exceeds the value set by the admin, then the value will be capped at the admin-set maximum.

To configure these values, start the Registry Editor (regedit.exe). Navigate to:

Registry Setting Default Comment
IsDisabled 0 RTAV is enabled by default. If on a per client basis you want to disable, then set this value to 1.
srcAudioInId Not set Described above – allows a preferred audio device to be selected.
srcWCamId Not set Described above – allows a preferred video device to be selected.
srcWCamFrameRate Not set, default is 15fps Enter required frame rate here. By default this is 15fps.
srcWCamFrameWidth Not set, default is 320 pixels Defaults to 320. Enter any pixel size you would like.
srcWCamFrameHeight Not set, default is 240 pixels Defaults to 240. Enter any pixel size you would like.

Note that if you request an image size that your webcam does not natively support, then client-side scaling is performed to scale to the requested size. This will potentially reduce the actual throughput of frames possible in RTAV, so it is suggested that you select a standard resolution (4:3 or 16:9 ratio) and one that your webcam supports.

Audio quality is not configurable at this time.

Using RTAV with 3rd-Party Applications

RTAV webcam support requires that the 3rd-party application supports DirectX-compatible 3rd-party applications.

Flash-based applications or websites are not currently supported.

We have been testing internally with Skype, Google Hangout, WebEx, and QQ. We are sure there are many other apps too that will work.

[We would love to hear about any other apps you use successfully, or let us know if you come across any that don’t work!]


  • When we tested RTAV at scale, we assumed that RTAV would not be a primary use case for VDI. We thought that RTAV within VDI would be for occasional use or on some (but not all) desktops concurrently. We ran tests with 10% of virtual machines on a given host running RTAV and 90% running standard VDI workloads. We did not observe any degradation in performance for either set of desktops. However, depending on your use case, 3rd-party application, and spec of virtual machines, you may need to run your own scaling tests to be confident that the solution will work in a large-scale environment for you.
  • If you physically unplug a webcam during a call and then plug it in again, video will stop (but audio should continue). Start a new call to make the webcam ready for use.


We did make a few observations when testing with Skype that are worth considering:

  • Skype seems much happier if you keep the standard 320×240 image resolution.

If you do change resolution on the client side, then ensure you completely restart Skype on the guest –- or strange images may appear!

Skype does not like some resolutions, and if you set those, then no video will be available.

  • We also observed that Skype can be quite CPU-intensive. It is recommended that you configure virtual machines with 2 x vCPU if you plan to use Skype. There are also a number of articles on the web that talk to the high CPU usage, and some make suggestions for ways to reduce the usage. Obviously a high CPU load may affect your consolidation ratio of virtual machines on a given host.


Real-Time Audio-Video brings webcam and audio-in support to your Horizon View desktop for the first time. We are very excited by this feature, and we are sure that many of you will be, too. We would love to hear feedback about it, and if you find any interesting use cases, then please do drop us a line!

Check out Part #2 of this blog talking about Linux Client support for RTAV here: http://blogs.vmware.com/euc/2013/11/vmware-horizon-view-real-time-audio-video-rtav-part-2.html

You can follow Pete @pete_brown_wimb

USB Device Redirection in VMware Horizon View 5.1 and 5.2

By Peter Brown, Senior R&D Manager, VMware, London, UK

With the EUC Solutions Management and Technical Marketing team

What Is USB Device Redirection?

We are all used to USB devices on laptop or desktop machines. If you are working in a VDI environment such as VMware Horizon View*, you may want to use your USB devices in that virtualized desktop too. USB device redirection is functionality in Horizon View that allows the USB device to be connected to the virtualized desktop as if it had been physically plugged into it.

USB Redirection Changes in VMware View 5.1

The USB device is redirected from the physical device to the virtual desktop using network redirection of the USB request block (URB). The USB device driver needs to be installed on the VDI desktop (but it does not need installing on the client machine). Recent enhancements in VMware View 5.1 have greatly improved device compatibility as well as support for USB redirection on Windows, Mac, and Linux hosts.

Continue reading