A large part of working in IT
involves figuring out how to prevent bad things from happening — or if they do
occur, how to ensure they don’t happen again. While some might term this “closing
the barn door after the horse has escaped,” I prefer to think of it as “building
the habit of closing the barn door so he won’t get out again.”  Of course, that’s often when you find out the
barn door might not look too pretty when you’re trying to keep it shut.

This was recently exemplified by
an episode I experienced at a client site that involved a critical folder accidentally
deleted from a Windows 2008 file server. It was a fairly typical scenario where
the folder had somehow gotten lost through user mishap one afternoon. No
problem. Just restore last night’s backup, right? Well, no dice to that idea
since the files had all been created that day, after the previous backup finished.

But the game wasn’t quite over, because
the client uses the Volume Shadow Copy Service on the server and it
was set to take a snapshot of the data volume (H: drive) twice per day – at 10
am and 2 pm. We looked at the 2 pm snapshot using the Previous Versions
function in Windows (whereby you right-click a network folder, choose
Properties, click the Previous Versions tab, browse to the data you want, then
copy it to the live location).  We managed
to obtain three files from it, but the remaining dozen or so were still gone
because they had been created after 2.

Figuring it couldn’t hurt to
gamble with free utilities, we tried the undelete programs Recuva and FreeUndelete but did not find any files to recover. I have only had middling
at best luck with these types of programs, but they can still be worth a shot —
though for some reason they always seem capable of recovering unimportant files
rather than important ones.

Cutting losses and preparing for
next time

That brought us to the end of
the road. The user had to re-create the missing files, which wasn’t the end of
the world, but we figured rather than taking volume snapshots of the server H:
drive twice per day, perhaps a better idea would be to do so hourly during
business operations.

Configuring the Volume Shadow Copy
Service snapshot schedule is easy. You just log onto the Windows server,
right-click the volume in question, choose Properties, and then choose the
Shadow Copies”tab. However, when we did this we got the error shown in
Figure A.

Figure A



Uh, what?

This error seemed to indicate a
problem with the Volume Shadow Copy Service. The service seemed to be running
okay, and as previously stated we were able to access the data it protected,
but some vague errors appeared in the Application Logs:

“Volume Shadow Copy Service error: Error calling a
routine on a Shadow Copy Provider {b5946137-7b9f-4925-af80-51abd60b20d5}.
Routine details Cannot ask provider {b5946137-7b9f-4925-af80-51abd60b20d5} if
volume is supported. [0x8000ffff] [hr = 0x8000ffff].”

Research indicated that
the issue was caused by TrueCrypt running on the server. TrueCrypt is an open source encryption solution that allows you to
encrypt entire disks, partitions, or special volumes (called containers) to
securely store data. I use it for my personal documents and it provides great
peace of mind.

In my client’s case, they have an encrypted TrueCrypt 7.1a volume on this server mounted as its own drive (I:), which has
folders that are shared and secured via the normal Windows server methods. This
volume exists to safeguard extra-sensitive confidential data. When the server
boots up and is logged in, a command runs automatically, which mounts the TrueCrypt
volume after prompting for the password:

files\truecrypt\truecrypt” /q /m /l i h:\Security.TC

This performs the following

c:\program files\truecrypt\truecrypt calls the TrueCrypt executable

/q tells the TrueCrypt
program to prompt for the volume password

/m tells the TrueCrypt
program to mount a volume

/l i tells the TrueCrypt
program to mount the encrypted volume as the I: drive

h:\Security.TC is
the actual TrueCrypt encrypted container object

We decided to try dismounting
the TrueCrypt volume to see if that Volume Shadow Copy Service error went away
(Figure B).

Figure B



This was as simple as launching
TrueCrypt then selecting the I: drive and clicking Dismount. Once this was done, the Shadow
Copies tab appeared as normal (Figure C).

Figure C



We were then able to set hourly
shadow copies of the H: drive, as shown. What would happen when we remounted
the TrueCrypt volume, though?

As it turned out, the same error
showed on the Shadow Copies tab, but it did not interfere with the actual Shadow
Copy operation — nor were backups affected. As you can see in Figure D, the
hourly snapshots were being faithfully generated (and we made sure to test

Figure D



It seems this is a known issue,
which TrueCrypt has acknowledged. There are lots of references to the issue on
the TrueCrypt forums,
and it’s clear this situation has existed for some time. The site states that:

“The Windows Volume Shadow
Copy Service is currently supported only for partitions within the key scope of
active system encryption (e.g., a system partition encrypted by TrueCrypt, or a
non-system partition located on a system drive encrypted by TrueCrypt, mounted
when the encrypted operating system is running). Note: For other types of
volumes, the Volume Shadow Copy Service is not supported because the documentation
for the necessary API is not available.”

It should be pointed out that
this essentially says that we’re using TrueCrypt in a non-supported fashion,
but that’s an acceptable scenario since it’s performing per our needs and has
been for some time.

I got curious to see if I could
circumvent the error via other methods. I didn’t want to make any changes to
the system drive, but I did want to see whether encrypting an entire test
volume with TrueCrypt (as opposed to the container method I described) might
change the situation. Unfortunately, it did not. I also tried this on another
server, making sure to keep the encrypted file container on a separate volume
from the one for which I was trying to configure shadow copies, but the same
error resulted.

Learning to live with things

In the end, some barn doors may
get slammed shut and still look crooked, but at least they’re shut. It’s not a
big deal for us to have to dismount the TrueCrypt volume to make changes to the
Shadow Copy options on this server. In fact, we probably won’t have to make any
changes again anyway. So long as the Volume Shadow Copy Service is working as
expected, we’re satisfied with the results.

However, it’s interesting to see
how these kinds of problems might arise and how to handle them. If I were
younger and more impetuous I probably would have slogged on, stubbornly
searching for some kind of solution — perhaps backing up, reformatting, and
then restoring the volume, for instance. Nowadays, though, the fear of losing
valuable business hours to a cosmetic issue (as opposed to something that is
actually broken) outweighs the lure of finding a solution that may not exist,
like a treacherous will o’ the wisp. You have to pick and choose your battles
in the IT realm and decide where your priorities lie, just as you do everywhere

Share your feedback

Have you run into conflicts like
the one described here? Share your experiences (and workarounds) with fellow
TechRepublic members.