SteveOH

Background Information (MS Knowledge Base Article 223316) : The Microsoft Windows operating systems (2000/2003 and XP) include the ability to encrypt data directly on volumes that use the NTFS file system so that no other user can access your data. You can encrypt your files and folders if you set an attribute in the object’s Properties dialog box .

 

**Warning** The use of Encrypting File System (EFS) will prevent a person who does not have administrative rights from gaining access to your data. Theft of encrypted files is still possible but the files/folders will be formatted in such a way that they can’t be viewed by any casual user. These files CAN be deleted and erased from your system so backups are necessary. If you don’t back up the certificate keys to the EFS then the data will be useless to you if you ever have to recover your system from scratch.

How to enable Encrypting File System file sharing

In Microsoft Windows XP, EFS supports file sharing of encrypted files among multiple users. With this support, you can give individual users permission to access an encrypted file. The ability to add additional users is restricted to individual files. Support for multiple users on folders is not provided in either Microsoft Windows 2000 or Windows XP. Also, support for the use of groups on encrypted files is not provided by EFS.

After a file has been encrypted, file sharing is enabled through a new button in the user interface. A file must be encrypted first and then saved before additional users can be added. Users can be added either from the local computer or from the Active Directory service if the user has a valid certificate for EFS. The ability to add additional users is restricted to individual files. Support for multiple users on EFS encrypted folders is not provided. Also, only individual users can be added to files. Support for the use of groups on encrypted files is not provided by EFS.

 

How to encrypt and decrypt using the Encrypting File System

The following steps encrypt and decrypt a file or folder using the Encrypting File System.

Note These guidelines apply to Windows 2000 and Windows XP.

Encrypting a folder

Although you can encrypt files individually, we strongly recommend that you designate a specific folder for storing encrypted data.

Encrypt a folder and its contents

Although you can encrypt files individually, generally it is a good idea to designate a specific folder where you will store your encrypted files, and to encrypt that folder. If you do this, all files that are created in or moved to this folder will automatically obtain the encrypted attribute.

To encrypt a folder and its current contents, follow these steps:

•  Right-click the folder that you want to encrypt, and then click Properties .

•  In the Properties dialog box, click Advanced .

•  The Advanced Attributes dialog box displays attribute options for compression and encryption. This dialog box also includes archive and indexing attributes.

Note Although the NTFS file system supports both compression and encryption, it does not support both at the same time. This means that you can only select one or the other. A file or folder cannot be both encrypted and compressed at the same time.

To encrypt the folder, click to select the Encrypt contents to secure data check box, and then click OK .

•  Click OK to close the Advanced Attributes dialog box.

•  If the folder you chose to encrypt in steps 1 to 3 already contains files, a Confirm Attribute Changes dialog box will appear.

You can choose to encrypt only the folder so that all files subsequently moved to the folder or created in this folder will be encrypted. If you want to also encrypt all the contents of this folder, click Apply changes to this folder, subfolders, and files , and then click OK .

Decrypting a folder

To decrypt a folder, use basically the same process but in reverse order:

•  Right-click the folder that you want to decrypt, and then click Properties .

•  Click Advanced .

•  Click to clear the Encrypt contents to secure data check box to decrypt the data.

•  Click OK to close the Advanced Attributes dialog box.

•  Click OK to close the Properties dialog box.

•  If the folder has files in it, the Confirm Attribute Changes dialog box appears. You can choose to decrypt only the folder. However, this will not decrypt any files currently contained in the folder.

If you want to decrypt all the contents of this folder, click Apply changes to this folder, subfolders, and files , and then click OK .

Additional information

How files are encrypted

Files are encrypted through the use of algorithms that essentially rearrange, scramble, and encode the data. A key pair is randomly generated when you encrypt your first file. This key pair is made up of a private and a public key. The key pair is used to encode and decode the encrypted files.

If the key pair is lost or damaged and you have not designated a recovery agent, and then there is no way to recover the data.

Why you must back up your certificates

Because there is no way to recover data that has been encrypted with a corrupted or missing certificate, it is critical that you back up the certificates and store them in a secure location. You can also specify a recovery agent. This agent can restore the data. The recovery agent’s certificate serves a different purpose than the user’s certificate.

How to back up your certificate

To back up your certificates, follow these steps:

•  Start Microsoft Internet Explorer.

•  On the Tools menu, click Internet Options .

•  On the Content tab, in the Certificates section, click Certificates .

•  Click the Personal tab.

Note There may be several certificates present, depending on whether you have installed certificates for other purpose.

•  Select one certificate at a time until the Certificate Intended Purposes field shows Encrypting File System . This is the certificate that was generated when you encrypted your first folder.

•  Click Export to start the Certificate Export Wizard , and then click Next .

•  Click Yes, export the private key to export the private key, and then click Next .

•  Click Enable Strong protection , and then click Next .

•  Type your password. (You must have a password to protect the private key.)

•  Specify the path where you want to save the key. You can save the key to a floppy disk, another location on the hard disk, or a CD. If the hard disk fails or is reformatted, the key and the backup will be lost. (If you back up the key to a floppy disk or CD, you must store that disk or CD in a secure location.)

•  Specify the destination, and then click Next .

 

For additional information about the Encrypting File System (EFS), visit the following Microsoft Web sites:

Encrypting File System in Windows 2000
http://www.microsoft.com/windows2000/techinfo/howitworks/security/encrypt.asp

Encrypting File System in Windows XP and Microsoft Windows Server 2003
http://www.microsoft.com/WINDOWSXP/pro/techinfo/administration/recovery/default.asp

If you regularly work with files stored in shared folders on a Windows XP network, chances are that you’ve used Windows’ Map Network Drive command to map a drive letter to that folder. Wouldn’t it be nice if you could map a drive letter to a nested folder on your hard disk? Then, you could access nested subfolders just as easily as you can access shared folders on the network.

Fortunately, you can do just that. Unbeknownst to most Windows users, there’s an old DOS command called Subst that’s designed to associate a drive letter with any local folder—and it’s still a viable tool in Windows XP. Here’s how to use the Subst command:

1. Open a Command Prompt window.
2. Type the following command and press [Enter]:

subst x: C:\{pathname}\foldername}

In the command, x: is any available drive letter and {pathname}\foldername} is the complete path to your selected folder. For example:

Subst K: C:\Downloads\Windows\Drivers

Now, instead of typing the full path, you can reach the Drivers folder by accessing drive K: in Windows Explorer.

Should I stay or should I go … with Visual Studio 2005 or 2008 is the question in this particular case. One of my customers is still on Visual Studio 2003 and they are wondering whether to upgrade to VS 2005 or to VS 2008.

Are there reasons for moving to VS 2005 instead of 2008 even though 2008 is so close to release? Minimizing risk is probably the major driver for deciding on VS 2005. After all, it’s been out in the market for almost two years and it’s stable and mature. There’s also the common wisdom that you shouldn’t deploy a Microsoft product that doesn’t have at least one service pack. Mind you that SP1 for Visual Studio didn’t come out until 12 months after the release of the product. Microsoft is no longer in the mode where the Service Pack has to hit 6 months after release because there were quality issues that needed to be fixed.

When it comes to determining to move to the newer Visual Studio 2008 and the .NET Framework 3.5 there are more points to consider:

1) Stability and maturity of the underlying framework and consequently the applications you’re building on top of the framework.

2) Stability and maturity of new features added with VS 2008

3) Product Support differences.

4) Productivity benefits of VS 2008 compared to VS 2005.

Let’s dive a little deeper and examine each of these points:

1) Enhancements to the .NET Framework are built around the stable core of Version 2.0 that ship with Visual Studio 2005, when additions like generics and partial classes required modifying the CLR.

Version 3.0 added to the core set of .NET 2.0, but does not change the core CLR. New functionality is packed in new assemblies, e.g. System.ServiceModel. There were some minor changes to some of the library assemblies, e.g. System.Runtime.Serialization to accommodate new WCF functionality, but by all and large 3.0 is built around the solid core of the CLR and the BCL of 2.0.

Version 3.5 follows the same approach. The 2.0 CLR/BCL core remains largely untouched. New features are either implemented at the compiler level or in the System. Core assembly. Scott Hanselman (who’s finally joined Microsoft) confirmed this claim by doing some deeper research recently. He compared the core libraries that shipped with VS 2005 and the Beta 2 release of .NET 3.5 and found that the percentage of churn was in the single digits.

Since the .NET Runtime and the core libraries are pretty much the same between VS 2005 and VS 2008, there’s no increased risk for applications that leverage core .NET functionality only.

2) Now that we realized that .NET is very stable at its core, let’s look at the additional functionality that’s new with .NET 3.5. There are quite a number of new features (WCF, WPF, Visual Studio, Linq, too many others), but this particular customer is very interested in the new AJAX features. Again, the core framework code at the ASP.NET Ajax framework level has been in the public as a CTP since 2006 and has been RTM since early 2007. The Visual Studio 2008 release is adding more server side control features (for example control extenders), but the core has been publicly available as a preview release for more than 18 months. Another customer I work with is running one of the world’s largest eCommerce sites on top of AJAX some of these CTP bits without impact to their business.

Visual Studio 2008 adds design time tools and more server controls for richer UIs and better communication between the client-side code and the server. Those features are very helpful and the runtime features have been available in CTPs for a while.
Finally, one more risk mitigation factor to consider is recent announcement that source code (with comments) and debugging symbols are going to be available with Visual Studio 2008 and .NET Framework 3.5. If you’re running into issues, you have the unprecedented ability to trouble shoot and diagnose problems.

With all that, my take would be (if I was an architect that didn’t work for Microsoft) that risk from new framework libraries around ASP.NET AJAX is manageable. In other areas, you get all the fixes for .NET 3.0 SP1, which means there’s actually a benefit of fewer pieces to install. The remaining risk is the new code in System.Core and in some other places. Still, I’d feel good about moving to 2008.

3) Now, you may argue that the tools are still new, and there’s some truth in that. Even though the quality of Visual Studio has been pretty good, much better than in the 90s when I first looked at Microsoft tools, but new code is always new risk. One could argue that VS 2005 + VS 2005 SP1 + .NET 3.0 + .NET 3.0 SP1 + ASP.NET AJAX RTM + AJAX Control Toolkit + ASP.NET AJAX Futures CTP gives me the same capabilities as VS 2008 with more stable, proven code. But consider this: The AJAX Control Toolkit is released under a community license, which means there’s not official product support through the Premier Support channels. The ASP.NET AJAX Futures CTP delivers some of the cool improvements over RTM, but the CTP is an unsupported product. The new controls that ship with VS 2008 are fully supported.

You’re actually increasing risk a little bit by staying with Visual Studio 2005 because of a few unsupported bits and you’re greatly increasing complexity of your install process. With VS 2008 you get the stable service pack code for Visual Studio and .NET 2.0 and 3.0 and you get all that in a single install and you get all that in a single install which reduces complexity and consequently risk and cost of deployment. I give that one to Visual Studio 2008.

4) Yes, there is new code in Visual Studio 2008 and there better be . VS 2005 has been lacking the tool support to take full advantage of the .NET 3.0 platform. VS 2005 shipped with .NET 2.0, remember? The .NET 3.0 release was only a framework release. The tool support for WPF, WCF and ASP.NET AJAX is finally shipping with VS 2008.

The improved Javascript IntelliSense support alone is a great enhancement for somebody like me that delegates mundane tasks like remembering method overloads and signatures to IntelliSense. AJAX was painful because IntelliSense in the code editor was rather limited.

Then there’s the client-side JavaScript debugging Scott Guthrie was talking about. You now can set breakpoints from the start, debug and inspect javascript variables with property grids, visualizers and an immediate window just like you can in with managed code on the server.

Then there are other very helpful new features, like the ability call WCF JSON services, the Web Designer with rich CSS Support or the built-in support to make the back button AJAX aware with the history control and, of course , Linq. There are many other exciting new features, too many others to list here, but the bottom line is, there are numerous reasons why VS 2008 is the better choice for developing AJAX enabled sites.

Finally, you could argue that VS 2008 actually gives you the best of both worlds because VS 2008 lets you target different versions of the .NET Runtime. If you’re feeling very strongly about shipping applications on the 2.0 bits or the 3.0 bits, you can still take advantage of the new productivity enhancements in the IDE but build against the framework version of your choice.That’s a great combination or productivity and stable code to optimize for low risk.

Published Monday, October 08, 2007 9:01 AM by ChristophDotNet