Abstract: An overlay optimizer can be configured to accelerate the moving of files from an overlay and to atomically move files from the overlay. To accelerate the moving of files from the overlay, the overlay optimizer can continuously monitor the consumption of the overlay. If the consumption exceeds an optimized threshold, the overlay optimizer can cause the file system cache to be invalidated to thereby release handles to any closed files that are still cached. To move files atomically from the overlay, the overlay optimizer can be configured to handle attempts to open a file by determining whether the file is in the process of being moved from the overlay. If so, the overlay optimizer can detect which stage the move process has reached and can dynamically adapt the move process to enable the attempt to open the file to be completed successfully and in a consistent manner.

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: An overlay optimizer can prevent cross-volume moves to optimize the performance of a write filter. The overlay optimizer can be configured to detect when a file move is being attempted and can modify the handling of the file move so that a cross-volume move is not performed. In the case where the file move would result in a file being moved from the volume where the overlay cache is implemented, the overlay optimizer can create a copy of the target directory tree in the overlay cache and redirect the move to the newly created directory. In the case where the file move would result in a file being moved to the volume where the overlay cache is implemented, the overlay optimizer can forgo redirection so that the file will be moved within the same volume.

Abstract: Renames can be handled in an overlay optimizer to ensure that the rename operations do not fail due to source and target volumes being different. The overlay optimizer can implement a process for linking the two IRP_MJ_CREATE operations that the operating system sends as part of a rename operation. Due to this linking, the overlay optimizer can determine when the second IRP of a rename operation is being processed and can determine the source volume for the operation. When the source volume is the volume of the overlay cache, the overlay optimizer can redirect the second IRP. This will ensure that the rename operation will complete successfully even in cases where the rename operation was initiated without specifying the MOVEFILE_COPY_ALLOWED flag.

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: 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: 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: Renames can be handled in an overlay optimizer to ensure that the rename operations do not fail due to source and target volumes being different. The overlay optimizer can implement a process for linking the two IRP_MJ_CREATE operations that the operating system sends as part of a rename operation. Due to this linking, the overlay optimizer can determine when the second IRP of a rename operation is being processed and can determine the source volume for the operation. When the source volume is the volume of the overlay cache, the overlay optimizer can redirect the second IRP. This will ensure that the rename operation will complete successfully even in cases where the rename operation was initiated without specifying the MOVEFILE_COPY_ALLOWED flag.

Abstract: An overlay optimizer can prevent cross-volume moves to optimize the performance of a write filter. The overlay optimizer can be configured to detect when a file move is being attempted and can modify the handling of the file move so that a cross-volume move is not performed. In the case where the file move would result in a file being moved from the volume where the overlay cache is implemented, the overlay optimizer can create a copy of the target directory tree in the overlay cache and redirect the move to the newly created directory. In the case where the file move would result in a file being moved to the volume where the overlay cache is implemented, the overlay optimizer can forgo redirection so that the file will be moved within the same volume.

Abstract: An overlay optimizer can be configured to accelerate the moving of files from an overlay and to atomically move files from the overlay. To accelerate the moving of files from the overlay, the overlay optimizer can continuously monitor the consumption of the overlay. If the consumption exceeds an optimized threshold, the overlay optimizer can cause the file system cache to be invalidated to thereby release handles to any closed files that are still cached. To move files atomically from the overlay, the overlay optimizer can be configured to handle attempts to open a file by determining whether the file is in the process of being moved from the overlay. If so, the overlay optimizer can detect which stage the move process has reached and can dynamically adapt the move process to enable the attempt to open the file to be completed successfully and in a consistent manner.

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: 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: Files and folders on a read-only shared layer may be protected by using a read-write layer. File system level hooks are added to capture and simulate the rename and delete operation that would otherwise corrupt or destroy files and folders on a read-only layer. Each read-write layer has an associated file system metadata cache that gives an overview of the data contained by the layer. Relevant metadata is added for the metadata entry associated with a file or folder subjected to a rename or delete operation so as to track the file system operations associated with the file or folder. One or more metadata flags may be used to assist in tracking the file system operations.

Abstract: Layer metadata within a layering system can be self-healed. When a layer is mounted, a scanning module can scan the file system structure of the layer to identify what content is stored on the layer as well as attributes of this content. Based on this scan, the scanning module can determine if the layer metadata is consistent with the actual contents of the layer and report any discrepancies to a healing module. The healing module can then repair the layer metadata so that it accurately reflects the contents of the layer.

Abstract: A directory that resides on a layered volume can be renamed. A hooking module can be employed to intercept rename requests. The hooking module can query a layering file system filter driver to determine the volume of the source and target of the rename request. If the source and target are on different volumes, thereby indicating that the source is a directory of a layered volume, the hooking module can append a signature to the target which identifies the actual volume of the source. The modified rename request can then be passed to the operating system which will perform its normal operations including verifying that the source and target are on the same volume. During this verification, the layering file system filter driver can detect the appended signature in the target and can inform the operating system that the target is on the volume identified in the signature.

Abstract: A write filter can be configured to employ a dynamically expandable overlay. The size of the overlay could initially be small and could then grow and shrink during the current session based on demand. The overlay can span both RAM and disk to thereby allow the size of the overlay to be relatively large. When sufficient RAM is available, the overlay can be allowed to grow in RAM. In contrast, if RAM is low, the overlay can grow on disk. Also, artifacts in the overlay can be moved from the RAM portion to the disk portion to reduce the amount of RAM consumed by the overlay. Because the overlay is dynamically expandable, it will typically not become full and will therefore not force a reboot.

Abstract: Applications and users can be restricted from making persistent changes to artifacts on a protected volume. In Windows-based systems that include a file-based write filter, a policy-based write filter can be positioned below the file-based write filter and can examine any write requests that target artifacts of a protected volume and are not redirected by the file-based write filter. The policy-based write filter can examine the write requests against any applicable policies to determine whether the write requests should be allowed to proceed. If the policy-based write filter determines that a write request is not allowed by policy, it can fail the write request to thereby prevent the targeted artifact from being updated in the protected volume.

Abstract: Application configurations can be merged to enhance multi-layer performance. When a layering system is employed, a layering registry filter driver can create a merged registry hive that includes the contents of each operating system registry hive as well as the contents of each registry hive of a mounted layer. The merged registry hive will therefore form a single location that the layering registry filter driver can access to complete a registry operation.

Abstract: A security solution can be implemented using a layering system. By using a layering system, any changes that are made to a computing system can be isolated within a separate write layer. Due to this isolation, the changes, which may even be malicious, can be evaluated without fear that the resources in other layers will be negatively affected. In this way, even security threats that are still unknown to antivirus solutions (so-called zero-day attacks) can be prevented from harming the system.

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.