
This is because the system volume is being used to run the Windows OS and cannot be taken offline unless the OS is shut down and that volume is no longer in use. If you try to run an offline scan and fix on the system volume of a running Windows OS, you will be presented with the following message: Running an Offline Scan and Fix on the System Volume of a Running VM Once the scan and repair is complete, the volume will automatically come back online and will once again be accessible. Repair-Volume –driveletter E -offlinescanandfix In order to perform an offline scan and fix, open up PowerShell and type the following commands: You would use the –scan parameter on a volume that you’d want to check for corruption when you can’t take it offline at the moment. Also, performing a scan with the –scan parameter is not needed before running an offline scan and fix.

This will also make the volume inaccessible during the scan, so this needs to be taken into account when planning an offline scan and fix. This will take the volume offline, scan for errors, and fix any errors that it finds. If there were errors found on the volume, an offline scan and fix will need to be ran in order to fix the errors. Once the scan has completed, PowerShell will report whether or not errors were found on the volume. In this example we will use the C volume to scan: In order to scan the volume for corruption without attempting to repair it, open up PowerShell on the VM you’d like to scan and type the following commands. This cmdlet is built upon the Check Disk repair feature and allows repairs to be done on volumes through PowerShell.

Windows PowerShell 4.0 introduced the Repair-Volume Cmdlet. The Check Disk repair process can now also be ran through Windows PowerShell using the Repair-Volume Cmdlet.

This process ended up taking over 6 hours to fully complete the repair resulting in unwanted downtime and lost productivity for the client.įortunately, Microsoft has made some improvements to the Check Disk utility in Windows Server 2012 reducing the downtime for offline volume repairs to seconds instead of hours. In order to repair the corrupt files, a Check Disk repair had to be run on the system volume which required the server to be offline. A read only Check Disk on the system volume reported evidence of corrupt system files. It turned out multiple remote desktop services were repeatedly crashing. Users were not receiving their redirected printers at logon. This was a VM, which was being hosted on a Server 2008 R2 Hyper-V Cluster.

Out of the blue, one of our clients called in reporting issues printing from their Windows Server 2008 terminal server. The other day I ran into one of the most common issues IT pros have to face, file corruption.
