1 2 Previous Next 10 Replies Latest reply on Jun 10, 2010 2:45 PM by SafeBoot

    ChkDsk

      Getting ready to remotely deploy my endpoint encryption using autodomain *crosses fingers*.

      Was wondering if anyone had any insight in to running ChkDsk remotely on my laptops before I deploy the client.

        • 1. Re: ChkDsk

          In great majority of cases you don't need to do that, especially if it requires substantial effort on your side.

          But practicaly, any tool that pre-reads all disk sectors and reports results prior to EEPC encryption, will improve situation. To what extent, depends on your particular environment.

          If computers are older, with important data, no recent backups, I would suggest to run chkdsk or similar tools.

          • 2. Re: ChkDsk

            I'm not sure I agree - if you chkdsk /f a machine with a bad disk, you will kill it as surely as if you try to encrypt it - so the net result is the user looses their data.

             

            it's best to just query the SMART status of the drive - that gives you a pretty good idea of the health of a drive.

             

            I'm not sure I know of any customer who did a wide-scale chkdsk/f prior to encryption. Most just take the 1 in 1000 failure and remediate afterwards. If you have a particularly old device estate though, it may be worth thinking about.

            • 3. Re: ChkDsk

              "Chkdsk /f" does not scan free space, you must use "chkdsk /r" to do that.

              I have never suggested "chkdsk /f", that would be unresponsible to run it without precautions.

              Two pass chkdsk is much better approach. First find out if file system is intact, then if no errors, proceed with full disk scan.

               

              SMART data is difficult to analyze because of many different implementations and may not be accurate, as full disk encryption is not an every day activity.

              • 4. Re: ChkDsk

                There's no value for full disk encryption in doing a file system check - EEPC doesnt pay any attention to the file system at all - it's a sector based product, so you are right, you need to do /r to be any use at all, but as I say, that will kill your drive as much as encryption will. If the internal bad block remap table fills up, your drive is as good as dead anyway.

                 

                As for SMART being difficult to analyze - I'm not sure where you get that from? All SMART implementations return the same standardized status information? You just need to get the win32_diskdrive status value as per http://msdn.microsoft.com/en-us/library/aa394132(VS.85).aspx. If you want to get the individual values, like bad block count etc, that's a little more interesting, I posted an article on the whole topic of SMART and full disk encryption a while ago (on my personal blog), but again, both the raw data, and normalized industry standard values are available so it's easy to compare different drives.

                 

                Regardless, to get the basic health status for example in VBS  (it will give you useful things such as "OK", "Error", "Degraded", "Pred Fail" etc):

                 

                On Error Resume Next

                strComputer = "."

                Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

                Set colItems = objWMIService.ExecQuery("Select * from Win32_DiskDrive",,48)

                 

                For Each objItem in colItems

                     WScript.Echo "Status: " & objItem.Status

                     WScript.Echo ""

                Next

                • 5. Re: ChkDsk

                  Since you have proposed to run chkdsk with fix errors option, I have pointed out that it is dangerous to do so.

                  There is value to run chkdsk in read-only mode, to find out if file system is not corrupted. If it is, you should not blindly run chkdsk in automatic fix or repair mode, but take some other recovery steps.

                   

                  How many disks did you see to fill sector reallocation table if some disk areas are unreadible? Statistically? I'm yet to see one, though I have seen hundreds of disks with varying numbers of bad blocks.

                   

                  As for WMI reported disk Status, I'm afraid that most disks will report OK, regardless of their true state (if they have some sectors unreadible).

                  • 6. Re: ChkDsk

                    Google did a great report on the validity of SMART - I think it was around 48% of disks fail without knowing it.

                     

                    My point is, that the only thing which really matters to FDE is unrecoverable bad blocks - file system errors don't affect it a bit, and, if you detect bad blocks with Chkdsk, your drive has ALREADY failed - for Windows to notice, the drive itself has to have already mapped more bad blocks than it can keep track of.

                     

                    So, by doing a chkdisk of the file system, you don't protect yourself, by doing a bad block scan, you'll force the drive to remap bad blocks in the same way an encrypt did, so you might as well just ask the drive "are you ok?" before you start.

                     

                    The only thing that would actually help is to not encrypt blank areas of the drive, but that opens you up to leakage and plain text attacks, a whole different discussion.

                    • 7. Re: ChkDsk

                      There is a huge difference how system is being impacted. Disk surface scan (read-only) does nothing to file system reliability, (unless theoretical sector reallocation fails the disk); while encrypting disk with substantial rea-errors leads to encryption failure. Second one affects system much more.

                      • 8. Re: ChkDsk

                        I'm not sure why you are so concerned about file system validity when talking about doing full disk encryption - the two don't really have much to do with each other. I'm also not really sure what you mean by "encryption failure" - having bad blocks does not really affect encryption at all, but, having too many bad blocks affects the users OS, and ability to save data for sure.

                         

                        Finally, I don't believe you can do a "read only" surface scan - if you touch a sector on the drive, it's internal firmware will "bad block" check it, and remap it if it fails - this is the root problem. Just reading a bunch of failed sectors on a modern drive is enough to cause it to remap them, and, once all that "invisible" remap space is used up, then Windows will start seeing bad blocks as well.

                         

                        But, to close this - if you want to do a Chkdsk prior to encrypting, it won't hurt anything. How valuable, or useful it is though is up to you to decide. In the same way every software vendor tells you to back up prior to installing anything, checking the disk is a good idea, but most people skip this.

                        • 9. Re: ChkDsk

                          I'm not sure why you are so concerned about file system validity when talking about doing full disk encryption - the two don't really have much to do with each other. I'm also not really sure what you mean by "encryption failure" - having bad blocks does not really affect encryption at all, but, having too many bad blocks affects the users OS, and ability to save data for sure.

                          I'm talking about chkdsk in general. Nothing to do with encryption yet. It is irresponsible to run "chkdsk /f" or "chkdsk /r" before you know if anything is wrong with filesystem. Therefore I have suggested to run "chkdsk" first in read-only mode to obtain that knowledge and allow user to take appropriate measures.

                           

                          If bad blocks would happen to be in free space, initial disk encryption progress might stall or fail in some other ways.

                           

                          Finally, I don't believe you can do a "read only" surface scan - if you touch a sector on the drive, it's internal firmware will "bad block" check it, and remap it if it fails - this is the root problem. Just reading a bunch of failed sectors on a modern drive is enough to cause it to remap them, and, once all that "invisible" remap space is used up, then Windows will start seeing bad blocks as well.

                           

                          I meant read-only from OS point of view. What hard drive does internally is a different story. Usually it is seen as a major slowdown (retries, remaps, whatever) and then finaly a read-failure. And that affects initial disk encryption process.

                          1 2 Previous Next