Web Folders in Office 2000

I didn't pay much attention to the new Web folder that appeared in My Computer after I installed Microsoft Office 2000 until I needed a simple, familiar way for one of my customers to share large files with me. When I realized that you can use the drag-and-drop feature in Windows Explorer to copy and move files from your hard disk to your Web folder, I knew I'd found the perfect solution for both of us.

I've since found many other uses for Web folders. What started as a convenient way to keep the mail servers from getting clogged with enormous files has quickly grown into an important computing service for my small-business Web clients.

Many of my merchant customers need to be able to send one-of-a-kind pictures or customized documents to their customers. A fax machine is fine for some things, but it's not a replacement for a color picture, a short video clip, or a working version of a Microsoft Word document or Microsoft Excel spreadsheet. Clients can attach some of these items to an email message, but version control can become a problem (especially if more than one author has worked on the item), and some items (e.g., pictures and video clips) are simply too large. With Web folders, if merchants want more than one person to see a picture, they can drag the picture from their scanner's folder into their private Web folder and send an email message with a hyperlink to the picture. So, nontechnical merchants can selectively publish information and content in their Web domains by dragging that information from one folder to another. (Of course, they must be connected to the Internet at the time.) Web-site owners get a new level of control and capability without having to learn to edit HTML or write Web pages. They don't have to pay the Web administrator to set up special security groups, and they don't run the risk of messing up content on their production Web sites.

For larger companies that have employees in multiple locations, Web folders are shared network directories that those employees can access from anywhere in the world through the Internet. You can secure Web folders with Windows NT Challenge/Response authentication and even Secure Sockets Layer (SSL). In this article, I show you how to set up and secure Web folders on your IIS server, give examples of how my customers and I are using Web folders in our businesses, and offer some dos and don'ts for working with Web folders.

How Web Folders Work
Web folders are shared directories that you can access over the Internet. (Don't confuse Web folders with the Web Sharing option in Windows Explorer.) Web Sharing sets up a folder as a virtual directory under a Web domain. The option doesn't set up the user permissions or the Microsoft FrontPage Server Extensions that provide the actual access and file-transfer capabilities of a Web folder. A typical Web site lets users browse only; to author (i.e., read, write, delete, and change), users need some type of authoring or file-transfer software such as the FrontPage client or an FTP client. A Web folder lets users access (cut, copy, move, delete) Web folder content directly in Windows Explorer: Users don't need special software to transfer files over the Internet.

Any Web site, subweb, or virtual directory on which you've installed FrontPage 2000 Server Extensions is potentially a Web folder. FrontPage 2000 Web folders use HTTP, rather than FTP, to transfer files. The server extensions handle Web folders in the HTTP server. You don't need to set up FTP security, and no extra administration is necessary for maintaining FTP directories and security. Document transfer works safely anywhere FrontPage 2000 works—through firewalls and VPNs. Any user with the appropriate permissions in the Web folder can access the folder and its files as if they were shared folders and files on a network drive. Users don't need a client-side tool such as FrontPage to interact with a Web folder. For more information about how FrontPage Server Extensions provide a secure HTTP based-file transfer across the Internet, see "FrontPage Server Extensions Make IIS Administration Easier," January 2000.

How to Set Up Web Folders
Windows Explorer treats Web folders like network shared directories. To connect to the Web folder, users must use a mapping process in which they type or browse to the URL and then provide an acceptable ID and password (and domain name if they're using NT Challenge/Response authentication). Users can add a shortcut to a Web folder on the Internet to their local Web Folders in Windows Explorer in several ways—the Add Web Folder Wizard and the FrontPage 2000 client are the two most common methods.

Screen 1 shows the Web Folders directory and its contents. Notice the Add Web Folder Wizard at the top of the list, the explanation of Web folders in the left pane, and the Tell me more about Web folders link. These items help your users get started with Web folders. From the files in the directory, you can infer that a Web folder can be

When you click one of these Web folders, a logon screen appears (unless the folder is unsecured). If you select the Remember my password or Save this password in your password list check box, the Web folder remembers your ID and password, which makes it easy to log on (remember, however, that anyone sitting at the machine has access to the Web folder). When you've provided acceptable credentials, the Web folder opens like any other directory. If you right-click a Web folder, you can create a shortcut, rename the folder, or delete it. Note that in the Web Folders view, Delete removes only the Web folder link from the Web folder window—it doesn't remove the folder and its contents from the host. Every Web site I use FrontPage to connect to shows up in my Web Folders because the Web folder in my FrontPage client machine keeps track of those Web sites and their logons for me.

In addition, insist that customers use FrontPage to manage content. Although it's tempting to just double-click a Web folder and drag files around, several problems can arise. One problem is that the Web site won't recognize new or changed content until you run the Recalculate Hyperlinks function in FrontPage. (For more information about this function, see "Administering FrontPage 2000 Server Extensions in the MMC," April 2000.) To fix this problem, you can use the FrontPage Recalculate Hyperlinks function, either from the FrontPage client under the Tools menu or on the host under the Microsoft Management Console (MMC) IIS snap-in. Right-click the site, select Task, then select the Recalculate Web option. (This function does a lot more than its name implies.) Another problem is that a maverick author can wreck a site by changing content in the private FrontPage directories. Either way, editing a FrontPage Web without FrontPage is potentially dangerous—it's a management and version-control headache, and it definitely makes extra work.

Controlling Access to Web Folders
Because FrontPage Server Extensions power the Web folders, you can set permissions and administer folders in several ways. If you're an NT administrator, you can set up the directory permissions directly in Windows Explorer on the server, or you can use FrontPage's built-in role-based permissions to set up the access rights. (For more information, see "FrontPage Server Extensions Make IIS Administration Easier.") The difference is that setting permissions in Windows Explorer requires an NT administrator. In addition, you have to set all the rights on all the files, which can be tricky and time-consuming if, for example, you want different permissions on executable files than you want on .html files. With Windows Explorer, it's easy to set the wrong permissions on special files if you apply the read-write permissions to an entire directory. This application isn't a problem if the directory is empty, but if it's a Web site with Common Gateway Interface (CGI) scripts, you can easily break something or give the user permission to break something—for example, your scripts or applications might quit working. Using FrontPage to set up the permissions requires only a FrontPage administrator; FrontPage makes sure that you set permissions correctly on all files.

I like to set up empty FrontPage subwebs (i.e., empty directories, not Web sites) with unique permissions for my clients to use as their Web shares. That way, they can't accidentally mess up a Web site that they paid a professional to create. FrontPage makes it easy to create a subweb with unique permissions, and a FrontPage administrator can accomplish this task. All the NT administrator has to do is create IDs and possibly groups for the users who will be accessing the Web folders. When the new subweb exists, the FrontPage administrator can set up the unique permissions for it by opening it in FrontPage 2000, choosing Permissions from the Tools menu, clicking the Settings tab, selecting the Use unique permissions for this web option, then clicking Apply, as Screen 2 shows.

From the Groups or Users tab, clicking Add causes FrontPage to retrieve a list of users or groups from the Host, as Screen 3 shows. Select the users to whom you want to grant author and browse permissions, and click OK. Choose the Only registered users have browse access option from the Users window to lock the site so that only registered users have access, as Screen 4 shows. To make these permissions meaningful, you must remove the Everyone group from the Groups window. (FrontPage reminds you to remove the Everyone group if you forget to do it.)

I use this technique frequently to create private folders for my clients so that they can review and approve new work before they publish it. I have one client who negotiates contracts by using a separate locked Web folder for each negotiation. I set up the IDs for the folders in the server, and the FrontPage administrator sets up the individual negotiations folders under their root webs. The client tells me that this process has cut the time required to negotiate a contract by 30 percent and increased the number of executed contracts by 10 percent.

At Last—Real Security
Until now, the only type of security you could use on the Internet (without full SSL) was Basic authentication. However, Web folders are part of the new Office 2000 and Microsoft Internet Explorer (IE) 5.0, which let you secure your Web folders with NT Challenge/Response authentication. Screen 5 shows the MMC IIS snap-in and a newly created subweb (web folder) on a root web. When you create a new subweb on an application server in IIS, NT Challenge/Response is the default authentication. (For more information about IIS security, see Ken Spencer's Windows 2000 Magazine article "IIS 5.0's New Security Features," November 1999.)

Picking the right authentication method is trickier than it sounds. When you create a virtual root or virtual directory, the default authentication is NT Challenge/Response. If you disable Allow Anonymous Access, then only users with IE 5.0 can log on to the HTTP server with NT Challenge/Response authentication. Problems with NT Challenge/Response authentication can occur either when browsers don't support NT Challenge/Response authentication or when users don't know the correct domain name.

Browser doesn't support NT Challenge/Response. Sometimes, even in an intranet setting, someone tries to use a browser that doesn't support NT Challenge/Response to access a site. (Only IE supports NT Challenge/Response.) This problem can be very difficult for support people to debug because they might not be familiar with NT Challenge/Response authentication. In customer-support scenarios, your visible clue is that NT Challenge/Response client authentication requests the domain name along with the ID and password. So, the first question I train my support people to ask users is, "Are you using IE?" The second question is, "Do you see the Domain Name field in the logon window?" If the user doesn't see the ID, Password, and Domain Name fields, I know a browser-compatibility problem exists. If the browser doesn't support NT Challenge/Response, it won't present the additional domain field; users have no indication that anything is unusual about the logon. The browser is most likely sending the users' credentials using cleartext, so the host rejects them.

User doesn't know the domain name. A standalone NT 4.0 server has no domain name because it's not controlling a domain; consequently, the server will accept the logon with a blank domain name. Clear instructions are the key to success in this scenario. My customer-support policy is to tell Internet users to leave the domain name blank and tell intranet users to put their workgroup domain name in the field.

If you can't use NT Challenge/Response authentication, you must clear the Windows NT Challenge/Response check box and select the Basic Authentication check box on the Directory Security tab of the Web folder's Properties dialog box. (If you select both check boxes, the NT Challenge/Response logon will appear.) I don't recommend giving Anonymous users write permissions in any Web folder: That situation quickly leads to lost and corrupted files, and it's an invitation to intruders.

A Brief Scenario
Web folders are easy for your users to use, which makes your job easier. However, Web folders are new, and you need to educate your users and the support group about how to use them safely. Be sure to show the new users how to use the Add Web Folder Wizard. Here are the main points to remember about Web folders:

Don't confuse Web folders with the Web Sharing option in Windows Explorer. Web folders work just like shared directories over the Internet. The FrontPage Server Extensions power Web folders, which work through the HTTP server. A Web folder on the client is a shortcut to a virtual root, a subweb, or a virtual directory on a server.

Don't set the wrong authentication method for your users. Web folders can use NT Challenge/Response authentication, but make sure that your users understand the browser requirements. Do your homework before choosing the type of authentication you'll use on a Web folder. If you use NT Challenge/Response, remind users that they must use IE 5.0 to author in the Web folder and make sure they know the correct domain name as well as their individual IDs and passwords. Also, make sure your support people understand the different scenarios for Basic authentication and NT Challenge/Response authentication.

Don't turn a working FrontPage Web site into a Web folder. A FrontPage Web site has applications: It can have Java classes, graphical themes, data from form results, and many other types of private files that FrontPage requires to support the Web site. If you let people access a FrontPage Web site as a Web folder, anyone with author permissions on a Web folder can remove or corrupt these private files, and the Web site will stop functioning correctly. I discourage my Web authors from accessing their Web sites as Web folders and insist that they use the FrontPage client to manage their Web content.

To give you an idea how serious this situation can be, I recently received an irate email message from a client complaining that the company intranet was completely destroyed. My group had built the company's intranet, complete with several departmental sites and private folders and training for their Web masters. An examination of the Web sites showed a lot of tampering—missing FrontPage files and directories. I discovered that the people working in the office also wanted access to the Web folders. Unfortunately, these people had not attended the FrontPage and Web-authoring classes my group had provided for the company's Web content authors. The inhouse administrative resource was not familiar with Web servers or Web folders and so had shared the entire drive, changing all permissions on all files in all subdirectories and giving everyone in the company carte blanche over the entire drive. This action had exposed the carefully secured, business-critical Web folders and all the sensitive information to everyone in the company. Bottom line—don't share the drive that your Web folders are on.