Abstract: A secure software client is provided. A secure software client can be partitioned into a web application that functions as the user interface and a proxy that performs a number of functions to provide a desktop-like experience within the web application. The web application can be isolated within the browser and can communicate with the proxy via a secure communication channel thereby allowing the proxy to be isolated from other types of access. The proxy can generate a desktop in the form of HTML5 content that the web application can render. The proxy can customize the desktop to include representations of applications or other functionality that are available to the user. The web application can detect user interaction with the HTML5 content and relay the interaction to the proxy via the secure communication channel to allow the proxy to perform an appropriate function.

Abstract: Fault recovery of a video bitstream can be performed in a remote session. A decoder of a remote display protocol client can be configured to process a video bitstream that is transferred over a virtual channel of a remote session. As part of processing the video bitstream prior to passing it to a hardware decoder, the decoder can detect the occurrence of an error in the bitstream and then cause the remote display protocol client to employ the remote display protocol which encapsulates the virtual channel to request an I-frame from the remote display protocol service. This will force the encoder to send an I-frame even if the desktop has low entropy thereby minimizing how long a glitch may persist. Because the remote display protocol itself is employed to request the I-frame, there is no requirement to modify the video stream protocol.

Abstract: Audio and video devices can be virtualized using synchronous A/V streaming. When a video device such as a webcam is connected to a client terminal while the client terminal has established a remote session on a server, video data generated by the video device can be encoded into an encoded video stream using the H.264 or similar standard. Additionally, audio data corresponding to the video data can be embedded into the encoded video stream. The encoded video stream with the embedded audio can then be transferred to the server. The server-side components can extract the audio from the stream and perform the necessary decoding on the video and possibly on the audio data prior to providing the decoded data to drivers that function as virtualized audio and video devices on the server.

Abstract: Access to functionality of a file-based write filter can be secured. A policy-based filter can be configured to monitor and filter calls to APIs that access functionality of the file-based write filter. Based on policy, the policy-based filter can selectively block such calls to ensure that only permitted applications and/or users are allowed to access the functionality of the file-based write filter. In some cases, the policy-based filter can be configured to communicate with a server component to determine whether a particular attempt to access the functionality of the file-based write filter should be allowed.

Abstract: SCSI commands that are not supported by a client terminal can be enabled. In scenarios where the client terminal's operating system may not support the same SCSI commands as the server's operating system, a redirected mass storage device that does support the same SCSI commands as the server's operating system can still be initialized on the server as supporting these SCSI commands. Then, to allow the SCSI commands that are not supported by the client terminal's operating system to be provided to the mass storage device, a client-side proxy can employ a SCSI Pass Through Interface to send the unsupported commands rather than providing them to the client-side disk driver. The proxy may still provide supported SCSI commands to the client-side disk driver for typical handling.

Abstract: State-based I/O management is provided. A virtual bus driver of a virtual desktop infrastructure can employ containers to manage the state of an IRP that pertains to a redirected device. When an IRP that has been shared to a client terminal is cancelled, the virtual bus driver can update the state of a container associated with the IRP to prevent the IRP from being completed twice. In this way, devices for which IRPs are frequently cancelled can be redirected without concern that a cancelled IRP may result in improper system performance or a crash.

Abstract: Access to devices can be controlled dynamically. A device control driver can function as an upper filter driver so that it can intercept I/O requests that target a particular device. The device control driver can be configured to communicate with a device control server to dynamically determine whether the current user is allowed to access the particular device. The device control server can employ policy or administrator input to determine whether access should be allowed and can then notify the device control driver accordingly. When access is granted, the device control driver can pass I/O requests down the device driver stack. Otherwise, the device control driver can block the I/O requests. Also, when access is granted, the device control server can specify a permission expiration time after which the device control driver should again resume blocking I/O requests.

Abstract: Reprogramming of a redirected USB device can be restricted to prevent the redirected USB device's firmware from being modified maliciously. A virtual bus driver can be configured to monitor USB request blocks (URBs) to identify whether an URB pertains to an attempt to alter the firmware of a redirected USB device. When an URB is identified as pertaining to an attempt to alter the firmware, the virtual bus driver can block the URB unless the URB is associated with an authorized user or application. In this way, only an authorized user or application will be allowed to modify the firmware of a redirected USB device thereby ensuring that a malicious user or application cannot modify the firmware in an improper manner.

Abstract: A Windows file system can be attached to a remote non-Windows disk stack thereby allowing a mass storage device to be redirected at the disk level even though a client terminal is running a non-Windows operating system. A client-side proxy can include a disk provider that is configured to obtain disk information from a mass storage device connected to the client terminal and provide it to the server-side agent. A virtual disk enumerator on the server can employ the disk information to emulate a disk stack so that a Windows specific file system can be loaded on the server. Any Windows-specific management commands that target the mass storage device can be handled by the virtual disk enumerator using the disk information, whereas any access commands can be routed to the disk provider which can interface with a non-Windows disk stack on the client terminal for handling.

Abstract: An overlay of a file-based write filter can be freed up to thereby minimize the likelihood that the overlay will become full and force a system reboot. An overlay-managing write filter can be employed in conjunction with the file-based write filter to monitor files that are stored in the overlay and move files that are not currently being accessed. If a request is made to access a moved file, the overlay-managing write filter can modify the request so that it targets the location of the moved file rather than the location of the original file on the protected volume. In this way, the fact that modified files are being moved from the overlay but not discarded can be hidden from the file-based write filter. As a result, the effective size of the overlay will be increased while still allowing the file-based write filter to function in a normal fashion.

Abstract: Virtualized applications can be delivered using a peer-to-peer model. Each client in a virtual desktop infrastructure environment can function as both a server and a client for purposes of distributing and receiving application layers. A server component on each client can advertise any application layers that the client maintains in its local storage and can receive and service streaming requests from other clients. A client component on each client can discover each application layer that is available within its location including which client provides each application layer. The client component can therefore also be configured to request application layers from the appropriate clients. This peer-to-peer model eliminates the need to provide a dedicated server at each location. Also, because a server component on the client will only be tasked with streaming to a limited number of clients, virtually any client can function as the source of an application layer.

Abstract: Concurrent access to a user profile in a layering system is provided. When a user logs into a computing device, the server can locate a corresponding user profile to identify which layers should be provided to the user. Rather than sending these layers to the computing device for mounting, the server can mount the layers on the server. Therefore, if a user logs into multiple computing devices, the layering file system and registry filter drivers on those devices can route file system and registry requests to the server where the layers are mounted. Since the layers are mounted to a single device, concurrent access can be provided without the concern of data conflicts.

Abstract: User data can be synchronized over a virtual channel in a virtual desktop environment. A synchronization service can be included with a virtual desktop client and in the virtual desktop and can employ the virtual channel to transmit and receive new and updated user data. In this way, the user data can be synchronized without requiring any kind of file sharing between the access device and the virtual desktop and without requiring membership in any directory service. Therefore, user data can be synchronized in virtual desktop environments that employ a number of different operating systems and network security settings.

Abstract: A remote desktop can be shared with a number of clients. A proxy client can be employed to establish a remote desktop connection with a server for the purpose of accessing a remote desktop. The proxy client can receive desktop display data pertaining to the remote desktop and forward it to a remote desktop client on one or more clients to cause the remote desktop to be displayed on each of the clients. When users interact with the remote desktop displayed on the clients, the remote desktop client can send desktop input data to the proxy client. The proxy client can then forward this desktop input data to the server over the remote desktop connection. The proxy client may selectively block desktop input data received from a client that is not currently authorized to provide input to the remote desktop.

Abstract: Local network resources can be seamlessly accessed from a remote session. A remoting client that executes on a client terminal and a remoting service that executes in a remote session can each be configured to implement a virtual network pseudo device. These virtual network pseudo devices can be configured to communicate network communications via a virtual channel with the virtual channel endpoints performing any necessary network address translation. As a result, when the remote session host attempts to discover local network resources, the corresponding network communications will be routed over the virtual channel and transmitted over the client's local area network. Any resources on the client's local area network will respond accordingly with this responses being routed back over the virtual channel to the remote session host thus causing the resources to appear as if they were part of the same local area network as the remote session host.

Abstract: When it is desired to update a group of thin clients that have a common configuration, the update can be deployed to a reference device on which a replicate tool executes. The replicate tool can examine the file system and registry of the reference device and create a manifest that describes the current state. The manifest can then be published for access by an agent that executes on the thin clients in the group. When the agent receives the manifest, it can compare the received manifest to an existing manifest on the thin client that defines the thin client's current state to identify any artifacts that differ. The agent can then retrieve and install any artifacts the thin client needs to match the current state of the reference device.

Abstract: Scanners and printers can be redirected over a WAN in an efficient manner by employing a proxy device. When a client terminal has established a remote display protocol connection with a server over a WAN and attempts to redirect a printer, scanner, or other similar device over the connection, the device can instead be redirected to a proxy device that is on the same LAN as the client terminal. The proxy device can then establish a driver mapping connection with the server for the purpose of sending commands pertaining to the redirected device. In this way, the communications over the WAN will be simpler driver mapping commands rather than numerous USB-based IRPs and will therefore not suffer from the latency of the WAN.

Abstract: Authentication can be performed on thin clients using independent mobile devices. Because many users have smart phones or other similar mobile devices that include biometric scanners, such mobile devices can be leveraged to perform authentication of users as part of logging in to a thin client desktop. A mapping can be created on a central server between a user's mobile device and the user's domain identity. A mapping can also be created between the user's domain identity and the user's thin client desktop. Then, when a user desires to log in to his thin client desktop, the user can employ the appropriate biometric scanner on his mobile device to perform authentication. The central server can then rely on this authentication to identify and log the user into his thin client desktop.

Abstract: Users can be enabled to perform operations that require elevated privileges in a controlled manner. An agent can be executed on a user's computing device with admin privileges. When the user desires to perform an operation that user's privileges do not allow, the user can submit a request to an administrator. If the administrator approves the request, the agent can be notified that an operation needs to be performed. The agent can then obtain the necessary information for performing the operation and either perform the requested operation directly or perform one or more other operations to enable the user to perform the requested operation. In cases where the agent's actions grant elevated privileges to the user, the agent can be further configured to revoke the elevated privileges at a subsequent time to thereby prevent the user from retaining elevated privileges indefinitely.

Abstract: Redirection policies can be applied based on the Windows class of a USB device. When an agent on the server receives notification that a USB device has been connected to a client terminal that has a remote desktop connection with the server, the agent can employ the device descriptor contained in the notification to obtain the Windows class of the device. If the Windows class is obtained, and prior to causing the device to be enumerated on the server, the Windows class can be employed to apply one or more redirection policies. In this way, a redirected USB device can be managed at a much more granular level.