Patent Description:
Remote Desktop Services (RDS) allow a user to take control of applications running on a remote server over a network connection. With RDS, only software user interfaces are transferred from the remote server to the client terminal. All input from the client terminal is sent to the remote server, where software execution takes place.

The user's index database and configuration data are typically stored in the user's machine. When a user roams between multiple machines in a machine pool and logs into a new machine, the index database is empty for the user on the new machine. Thus, re-indexing occurs every time that a user switches to a different machine, which is an expensive task that must be performed with respect to time and computing resources. Hence, there is a need for a system and method that can allow a user to roam within multiple machines in a machine pool by without the need to re-index the user's database and configuration data. <CIT> describes that techniques are provided for preserving state-both machine state and user state-in a virtual machine (VM) in a server deployment. User state may be preserved among a plurality of VMs in a server deployment by storing data specific to the user in a virtual hard drive (VHD). When a user logs into a particular VM, the VM remaps portions of a guest OS file system that correspond to user state to the VHD and mounts the VHD. Machine state may be preserved by storing information particular to a VM apart from that VM. When a VM is to be recreated, a diff disk containing the information particular to the VM is determined based on the current VM, the information particular to the VM, and a gold image that the VM is to be created with. Then, the VM is created with the gold image and the diff disk. <NPL> describes that Windows Search maintains a single database of the files, emails, programmes and Internet history of all the users of a personal computer, providing a potentially valuable source of information for a forensic investigator, especially since some information within the database is persistent, even if the underlying data are not available to the system (e.g. removable or encrypted drives). However, when files are deleted from the system their record is also deleted from the database. Existing tools to extract information from Windows Search use a programmatic interface to the underlying database, but this approach is unable to recover deleted records that may remain in unused space within the database or in other parts of the file system. This paper explores when unavailable files are indexed, and therefore available to an investigator via the search database, and how this is modified by the indexer scope and by attributes that control the indexing of encrypted content. Obtaining data via the programmatic interface is contrasted with a record carving approach using a new database record carver (wdsCarve); the strengths and weaknesses of the two approaches are reviewed, and the paper identifies several different strategies that may be productive in recovering deleted database records.

In one general aspect, the systems and techniques disclosed herein are directed to a system including a server connected to multiple users, wherein each server hosts multiple application sessions accessible by the users. An indexer hosted on the server can be configured to analyze a file on the server to identify a user that owns the file without input from the application sessions, and to save the file to a virtual hard disk (VHD) of the identified user. The VHD can be temporarily saved on the server. A communications device can be connected to the indexer, where the communication device can send the VHD of the identified user from the server to a storage device. A processor can be on a second server, where the processor can retrieve the VHD of the identified user from the storage device, and temporarily save the VHD of the identified user on the second server.

A method, in accordance with a second aspect of this disclosure, includes analyzing via an indexer a file on a (RDS) server to identify a user that owns the file without input from application sessions running on the server. The server can be connected to multiple users and can host multiple application sessions accessible by the users. The file can be saved to a virtual hard disk (VHD) of the identified user, where the VHD can be temporarily saved on the server. An aspect of this disclosure can include sending via a communications device the VHD of the identified user from the server to a storage device. Another aspect of this disclosure can include retrieving via a processor the VHD of the identified user from the storage device and temporarily saving the VHD of the identified user on a second (RDS) server. The second server can host a session accessible by the identified user.

A computer program product for determining a group sentiment, in accord with a third aspect of this disclosure, includes a computer readable storage medium having encoded thereon instructions executable by a processor to cause the processor to analyze a file on an RDS server to identify a user that owns the file without input from desktop sessions running on the RDS server. The RDS server can be connected to multiple users and host multiple desktop sessions accessible by the users. The instructions cause the processor to save the file to a virtual hard disk (VHD) of the identified user, where the VHD is temporarily saved on the RDS server. The processor is controlled to send the VHD of the identified user from the RDS server to a storage device. The processor is controlled to retrieve the VHD of the identified user from the storage device and temporarily save the VHD of the identified user on a second RDS server. The second RDS server can host a session accessible by the identified user.

In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well known methods, procedures, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.

A system is provided that can allow a user to roam within multiple machines in a machine pool by supporting per user indexing in an RDS environment. Indexing for a user's content, such as, for example, Outlook® email, can be stored in a separate per user index (also referred to herein as an "index file"). Thus, user indexing is not stored only on the user's machine; rather, the per user indexing can roam with the user wherever the user login occurs. More specifically, the system can encapsulate the users index and configuration data into a user profile location, and dynamically load and unload the data based on a user logon or logoff event. Based on this, a query from a user session can be scoped into the per user index so that the query is fulfilled with the user data only. The RDS environment may set up user profile roaming as a virtual hard disk (VHD) mount and unmount to implement this feature.

In at least one implementation, SearchIndexer (also referred to herein as the "indexer") is an available file indexing utility for searches. The system can address performance bottlenecks in, e.g., a Windows® Virtual Desktop (WVD) environment, by providing a roamable per user index. SearchIndexer can provide this unblock adoption of a fast search scenario, such as, for example, in an Outlook® email search in a WVD environment.

During a set up phase, SearchIndexer can prepare a per user index data file under the roaming section of the user profile storage. SearchIndexer can also configure the per user index into a user hive of registry, which can also be under the roaming section of the user profile storage. Next, SearchIndexer can hook into the user log on and user log off notification, and dynamically load and unload the per user index. For indexing operations, SearchIndexer can identify an item that an application is requesting to be indexed, and identify who owns the item. SearchIndexer can also identify the file path used, and for push items such as an application programming interface (API) call, the caller's context can be retrieved. For querying operations, the client's context can be retrieved and re-directed to the per user index in order to serve the query.

Accordingly, at least one implementation provides a roamable per user index that is self-contained with data and configuration provided, which eliminates the need for re-indexing every time a user logs on to a new machine in the machine pool. This can be enabled by dynamic load and unload operations of the per user index when the user logs on and off from a WVD machine. Re-direction indexing and querying of user data can be seamlessly done in order to provide a fast search service with less cost than previous versions.

<FIG> is a diagram illustrating a system for a per user index for Windows® virtual desktop, wherein the system includes a server <NUM>, one or more servers <NUM>, and a user profile storage device <NUM>. In at least one implementation, the servers <NUM> and <NUM> are each connected to multiple client terminals (also referred to herein as "users"), where each of the servers <NUM> and <NUM> host multiple application sessions that can be accessible by the client terminals. In the example illustrated in <FIG>, server <NUM> is connected to client terminals <NUM>, <NUM>, and N; and, and server <NUM> is connected to client terminals <NUM>, <NUM>, and N2. Server <NUM> can host session <NUM> accessible by client terminal <NUM>, session <NUM> accessible by client terminal <NUM>, and session N accessible by client terminal N. In addition, server <NUM> can host session <NUM> accessible by client terminal <NUM>, session <NUM> accessible by client terminal <NUM>, and session N2 accessible by client terminal N2. Each of the sessions <NUM>, <NUM>, N, <NUM>, <NUM>, and N2 is isolated from others in their respective servers. In other implementations, the system can include up to or greater than hundreds of servers where each server hosts and is connected to hundreds of client terminals running hundreds of application sessions on each server. Although <FIG> labels items <NUM>, <NUM>, N, <NUM>, <NUM>, and N2 as "client terminals", in other implementations, <NUM>, <NUM>, N, <NUM>, <NUM>, and N are referred to as "client devices", "client machines", "remote devices", "user devices", "user machines", or "users".

In at least one implementation, the system can include a Remote Desktop Services (RDS) platform where all of the remote clients connect to a centralized set of RDS servers for their computing needs. These RDS servers can run a specialized version of Windows® or other operating system that supports a number of different configurations. User profile disks (UPDs, also referred to herein as an "index file" or a "per user index") can be stored on a network file share as virtual hard disk (VHD) files and can contain all of the information that is roamed with a user between sessions. The folder paths can be set by an information technology (IT) administrator and NTUSER. dat can be included in the UPD to enable index roaming.

The servers <NUM> and <NUM> can be remote desktop session hosts (RDSH) by hosting multiple desktop sessions that are accessible by remote users over the network. In the example illustrated in <FIG>, VHDs <NUM>, <NUM>, and N are mounted on server <NUM>; and, VHDs <NUM>, <NUM>, and N2 are mounted to server <NUM>. In one specific example, the term "mounted" includes attaching a storage peripheral to a single machine, where information is driven by the machine and not the storage peripheral. VHDs <NUM>, <NUM>, and N can be associated with sessions <NUM>, <NUM>, and N, respectively, and thus client terminals <NUM>, <NUM>, and N respectively. Similarly, VHDs <NUM>, <NUM>, and N2 can be associated with sessions <NUM>, <NUM>, and N2, respectively, and thus client terminals <NUM>, <NUM>, and N2 respectively. When the client terminals are not connected to the servers, the VHDs associated with the client terminals can be sent to a user profile storage device. For example, as illustrated in <FIG>, VHDs <NUM>, <NUM>, and <NUM> are stored on user profile storage device <NUM> because their respective client terminals are not connected to a server.

It may be assumed that all users have existing UPDs and have gone through the first log on process, but there may be a mix between users who are logging in for the first time and return users. The mount points or even mount drives may not be consistent between the servers. Server <NUM> and server <NUM> may mount at different drive letters or different paths on those drives. Since multiple users will be logged in at the same time, keeping CPU consumption to a minimal may be a concern. In at least one implementation, multiple users will have shared CPU resources, so one user consuming a lot of CPU will impact neighboring sessions.

The users may use many programs during their sessions, create content, and share content with their peers. This can include browsing the internet, syncing email, using OneNote®, saving files or searching for files (e.g., using Cortana® and/or File Explorer), and/or using Universal Windows® Platforms (UWPs) to interact with local files on their profile. While the users are performing these operations, it may be a concern to keep the experience as close to having a thick client as possible. (Thick clients are full-featured computers that are connected to a network. Unlike thin clients, which lack hard drives and other features, thick clients are functional whether they are connected to a network or not. ) Many of the users may neither notice nor care that they are running on a remote, shared machine and will simply expect their session to run smoothly.

<FIG> is a diagram illustrating a system for managing data on servers, wherein the system includes a server <NUM> connected to multiple remote users, and the server hosts multiple application sessions accessible by the users. In at least one implementation, the server <NUM> is an RDS server hosting multiple desktop sessions that are accessible by remote thin client terminals over a network. The server <NUM> can include an indexer <NUM> and a communications device <NUM>.

As used herein, the term "indexer" includes a computer hardware component (e.g., a processor) that provides fast local search of files, email, internet history, and more. The indexer <NUM> can run searchindexer. exe, searchprotocolhost. exe, and searchfilterhost. exe, available from Microsoft Corporation, Redmond, Washington, USA. As described more fully below, the indexer <NUM> can analyze a file created by one of the application sessions running on the server <NUM> and/or metadata of the file. The analysis performed by the indexer <NUM> identifies the user that created and owns the file without input from the application sessions, or before input from the application sessions is provided to the indexer <NUM>. In other words, in at least one implementation, the programs running in the application sessions do not communicate to the indexer <NUM> who created the file, who owns the file, who has access to the file, and/or where to save the file. The indexer <NUM> can analyze the file or the file metadata on its own to determine this information.

More specifically, the indexer <NUM> can include a sniffer, which is a program and/or device that monitors data traveling through the server <NUM> in order to monitor a handle number i.e., a number that the operating system assigns temporarily to a file when it is opened, of the file. The operating system uses the handle number internally when accessing the file. The indexer <NUM> monitors the handle number of the file when a process running in one of the application sessions is writing to the file in order to identify the application session writing to the file. Once the application session writing to the file is known, the application session can be mapped back to the client terminal connected to the application, and thus the user who created and owns the file. The indexer <NUM> can also analyze paths in the application sessions to identify locations where the file is written to. The indexer <NUM> can then map the identified locations back to a user in order to identify the user who created and owns the file. The indexer <NUM> can manage users logged on to the system and their profile directory paths; and, when file activity is detected, the indexer <NUM> can determine where the file belongs by looking through the profile directory path. For example, for the user 'FOO', the indexer <NUM> can determine that the profile directory path for this user is "c:\users\foo. " When a file is created having the path "c:\users\foo\documents\patent-draft. docx," the indexer <NUM> can scan through a list of profile directory paths for all of the users to identify a matching beginning port of the file path. If a match is found, the indexer <NUM> can identify that the user 'FOO' owns the profile directory.

In addition, the indexer <NUM> can analyze a list of all of the users that have access to the file (i.e., the access control list) in order to identify the user who created and owns the file. The indexer <NUM> can also analyze an attribute of the file to identify the user that created and owns the file. For example, for an encrypted file, there is a special API to meta information of the file called EncryptionOwner that allows the indexer <NUM> to determine ownership of the file.

In at least one implementation, an administrator of the system can categorize files on the server <NUM> as relevant. The indexer <NUM> can be configured to analyze only files and metadata of files that are categorized as relevant by the administrator of the system. The process of determining who the user is that created and owns a file can be expensive with respect to time and resources. The system can control which files the indexer <NUM> will consider for indexing by mapping the paths that the administrator says should be interesting (e.g., files in the "MyDocuments" folder) into the file system of the VHD to make sure that the indexer <NUM> does not search through files that do not make sense, thereby wasting CPU resources.

The indexer <NUM> can save the metadata of the file to a VHD of the identified user that is temporarily mounted to the server <NUM>. Specifically, the indexer <NUM> can save the metadata of the file to an index file of the identified user that resides on the VHD of the identified user. As described above, VHDs can contain all of the information that is roamed with a user between sessions.

The indexer <NUM> can be connected to the communications device <NUM>. As used herein, the term "communications device" includes a computer hardware component (e.g., a processor, antenna, port) that sends the VHD of the identified user from the server <NUM> to a storage device when the identified user logs out of his or her client terminal. As used herein, the term "connected" can include operationally connected, logically connected, in communication with, physically or wirelessly connected, engaged, coupled, contacts, linked, affixed, and attached.

The system can further include a second server <NUM> (e.g., an RDS server) connected to multiple users, where the second server <NUM> can host multiple application sessions accessible by the users. The system can include up to hundreds or greater of servers where each server hosts and is connected to up to hundreds or greater of client terminals running up to hundreds or greater of applications sessions on each server. In at least one implementation, the second server <NUM> is the same as the first server <NUM>.

The second server <NUM> can include a port that connects the second server <NUM> to a client terminal of the identified user, where the second server <NUM> hosts a session accessible by the identified user. The second server <NUM> can also include a processor <NUM> that retrieves the VHD of the identified user from a storage device and temporarily mounts the VHD of the identified user to the second server <NUM> when the identified user logs into his or her client terminal. Specifically, the processor <NUM> can access the index file of the identified user that resides on the VHD of the identified user. This can be performed when the identified user logs onto the server <NUM> from his or her client terminal. Thus, the system can allow users to roam within multiple machines in a machine pool by supporting per user indexing in an RDS environment.

<FIG> is a flow diagram illustrating a method for managing data on servers, where each server is connected to multiple users, and where each server hosts multiple application sessions accessible by the users. As described above, the method can be performed on an RDS platform where all of the remote users connect to a centralized set of RDS servers for their computing needs. A file on a server and/or metadata of the file on the server can be analyzed to identify a user that created and owns the file without input from application sessions running on the server (<NUM>).

More specifically, a sniffer can be utilized to monitor data traveling through the server in order to monitor a handle number assigned to the file by an operating system of the server. The handle number of the file can be monitored when an application running in one of the application sessions is writing to the file in order to identify the application session writing to the file. Once the application session writing to the file is known, the application session can be mapped back to the client terminal connected to the application, and thus the user who created and owns the file. Paths in the application sessions can also be analyzed to identify locations to which the file is written. The identified locations can then be mapped back to a user in order to identify the user who created and owns the file. In addition, attributes of the file and/or the access control list of the file can be analyzed in order to identify the user who created and owns the file. In at least one implementation, an administrator of the system categorizes files on the server as relevant; and, only files and metadata of files that are categorized as relevant by the administrator of the system as relevant are analyzed.

The metadata of the file can be saved to a VHD of the identified user temporarily mounted to the server (<NUM>). More specifically, the metadata of the file can be saved to an index file of the identified user that resides on the VHD of the identified user. In at least one implementation, analyzing and saving can be performed by an indexer. When the identified user logs out of his or her client terminal, the VHD of the identified user can be sent via a communications device from the server to a storage device (<NUM>). As described above, VHDs can contain all of the information that is roamed with a user between sessions.

When the identified user logs in to his or her client terminal, the VHD of the identified user can be retrieved from the storage device and temporarily mounted to a second server (<NUM>). The second server can now host a session that can be accessible by the identified user. The session hosted on the second server can access the index file of the identified user that resides on the VHD of the identified user. Because the user's index file is now on the second server, the need to re-index the identified user's files is eliminated.

Aspects of the present device and methods may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages.

Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention.

Referring now to <FIG>, a representative hardware environment for practicing at least one embodiment of the invention is depicted. This schematic drawing illustrates a hardware configuration of an information handling/computer system in accordance with at least one embodiment of the invention. The system comprises at least one processor or central processing unit (CPU) <NUM>. The CPUs <NUM> are interconnected with system bus <NUM> to various devices such as a random access memory (RAM) <NUM>, read-only memory (ROM) <NUM>, and an input/output (I/O) adapter <NUM>. The I/O adapter <NUM> can connect to peripheral devices, such as disk units <NUM> and tape drives <NUM>, or other program storage devices that are readable by the system. The system can read the inventive instructions on the program storage devices and follow these instructions to execute the methodology of at least one embodiment of the invention. The system further includes a user interface adapter <NUM> that connects a keyboard <NUM>, mouse <NUM>, speaker <NUM>, microphone <NUM>, and/or other user interface devices such as a touch screen device (not shown) to the bus <NUM> to gather user input. Additionally, a communication adapter <NUM> connects the bus <NUM> to a data processing network <NUM>, and a display adapter <NUM> connects the bus <NUM> to a display device <NUM> which may be embodied as an output device such as a monitor, printer, or transmitter, for example.

Claim 1:
A system comprising:
a server (<NUM>, <NUM>) accessible by multiple users (<NUM>, <NUM>, N, <NUM>, <NUM>, N2), wherein the server (<NUM>, <NUM>) is configured to host multiple application sessions (<NUM>, <NUM>, N, <NUM>, <NUM>, N2) accessible by the users (<NUM>, <NUM>, N, <NUM>, <NUM>, N2);
an indexer hosted on the server (<NUM>, <NUM>), the indexer is configured to analyze at least one of a file on the server (<NUM>, <NUM>) and metadata of the file on the server (<NUM>, <NUM>) to identify a user that created and owns the file without input from the application sessions (<NUM>, <NUM>, N, <NUM>, <NUM>, N2) and to save the metadata of the file to a virtual hard disk (VHD (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>)) (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>) of the identified user, wherein the VHD (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>) is temporarily mounted to the server (<NUM>, <NUM>);
wherein the indexer is configured to:
monitor a handle number assigned to the file by an operating system of the server (<NUM>, <NUM>) when a program running in one of the application sessions (<NUM>, <NUM>, N, <NUM>, <NUM>, N2) is writing to the file;
identify an application session writing to the file based on the monitoring of the handle number; and
identify the user by mapping the application session to the user;
a communications device connected to the indexer, the communication device being configured to send the VHD (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>) of the identified user from the server (<NUM>, <NUM>) to a storage device (<NUM>); and
a processor on a second server (<NUM>, <NUM>), the processor being configured to retrieve the VHD (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>) of the identified user from the storage device (<NUM>) and temporarily mount the VHD (<NUM>, <NUM>, N, <NUM>, <NUM>, N2, <NUM>, <NUM>, <NUM>) of the identified user to the second server (<NUM>, <NUM>).