I'm running a C# application that needs to encrypt/decrypt files (using NTFS's EFS encryption) on behalf of a specific user account--a user account other than the one under which the application is running.  I didn't want to go through the hassle of firing up a new process (using CreateProcessAsUser) because I'd have to worry about IPC and it'd be less performant.  The question I had was:  is it possible to encrypt/decrypt files as a user other than the one under which the process is running within that process?  I couldn't find any resource on the web that stated an answer definitively, so I wrote some code to try it.  The answer is:  yes.

Here are the steps (it involves a mix of Interop and managed methods):

1. Get a handle to the desired user (the one whose encryption key you want to use) by calling LogonUser.  (You'll need the user's password.)
2. Load the user's profile (aka registry hive) by calling LoadUserProfile.
3. Construct a WindowsIdentity object using the handle provided by the call in step 1.
4. Invoke WindowsIdentity.Impersonate().
5. Perform any file I/O -- it'll be in the context of that user.  The user's encryption key will be used with any File.Encrypt() / FileInfo.Encrypt() invocation.
6. Unload the profile by calling UnloadUserProfile.
7. Close the user handle by calling CloseHandle.

You can do steps 1-4 in the constructor of an IDisposable object and do steps 5-7 in the Dispose() method to ensure proper resource cleanup. 

I installed Windows Desktop Search--with some reluctance--after Outlook 2007 kept prodding me to do so.  Traditionally I've used Google Desktop Search without issue, but I didn't have either installed on this particular machine and decided to give Microsoft's search a try.

One big surprise:  it completely replaces Windows' built-in Find Files & Folders feature that's integrated with Windows Explorer.  I like that Microsoft has provided a rich client UI (as opposed to Google's web-based one), however actually replacing an OS feature is a little hard to justify, especially when it removes some functionality.  In this case, my ability to find files and folders by name is now limited.  If I search for "notepad.exe," for example, I get a "Nothing found in All Locations" message.  Hmmm... Not cool.  (Actually, it looks like if I "click here to use Search Companion" I get the old functionality.  Not really intuitive!  Why didn't Microsoft just add another button to the Explorer toolbar for "Desktop Search" and keep the existing "Search" button working the way it was, or at least provide both search options in the shell namespace tree?)

At any rate, dropping to the command line provides a decent enough workaround, and is probably faster than the Windows UI anyway:

dir /s notepad.exe

Windows Server 2003 provides support for volume mirroring.  To get this set up correctly, you need at least two physical disks.

• The first disk (I'll call it "disk0") must be a dynamic disk.
• The second disk (I'll call it "disk1") must be a dynamic disk.
• Disk1 must have unallocated space at least the size of the volume you intend to mirror.

Seems simple enough.  However, when I opened the Disk Management MMC snapin, clicked "Add Mirror" on disk0, and chose disk1 as the target, I got this error message:

Cannot mirror to a disk with a different partition style.

Both disks were marked as "dynamic," so I wasn't sure what Windows was complaining about.  But when I right clicked on disk1, I was able to convert the disk from dynamic to MBR.  After making this choice, it worked.  Moral:  there's more to the label "dynamic" than meets the eye.