FrontPage Versions and Timeline

November, 1995 - Vermeer FrontPage 1.0
(Version 1.0)

Mini Review: Believe it or not, FrontPage 1.0 ran on Windows 3.x and Windows NT 3.5.1. This required installing a Win32 subsystem for Windows 3.x, which was fraught with installation errors.

This version was very limited, and it didn't even support tables. The program also had a nasty little issue - if this version saw some HTML that it didn't like, it just deleted it!


June, 1996 - Microsoft FrontPage 1.1
(Version 1.1)

Mini Review: FrontPage 1.1 was Microsoft's first release for the FrontPage family of products. It thankfully supported tables, and it supported frames, even though Microsoft's version of Internet Explorer at the time did not support frames.


October, 1996 - Microsoft FrontPage 97
(Version 2)

Mini Review: FrontPage 97 dropped the need for the _vti_shm folder and started inserting FrontPage bot code into the HTML. (This was an important update.)


January, 1997 - Microsoft FrontPage 1.0 for Macintosh
(Version 2)

Mini Review: Microsoft FrontPage 1.0 for Macintosh was basically a port of FrontPage 97 for Apple computers. This didn't do all that well in the Apple market because FrontPage faced a deeply entrenched customer base of Apple users that were already using Adobe's products, and subsequently it was the only version of FrontPage that Microsoft created for the Macintosh.


September, 1997 - Microsoft FrontPage Express 2.0

Mini Review: This was a version of FrontPage that shipped with Internet Explorer 4.0; it was essentially an editor-only version of FrontPage; all of the web management features were removed. Microsoft did not make another version of FrontPage Express.


December, 1997 - Microsoft FrontPage 98
(Version 3)

Mini Review: This was the last version of FrontPage that featured a separate editor and explorer, but it was arguably a very popular version and it signaled the beginning of FrontPage's short-lived reign as one of the most-used HTML authoring tools.


March, 1999 - Microsoft FrontPage 2000
(Version 4)

Mini Review: This was the first version of FrontPage that integrated the editor and web management features, which was a huge milestone. This was also an extremely popular version, and it continued FrontPage's short-lived reign as one of the most-used HTML authoring tools.


June, 2001 - Microsoft FrontPage 2002
(Version 5 [Office 10])

Mini Review: This version marked the beginning of FrontPage's demise as one of the most-used HTML authoring tools. Tools like Dreamweaver began to seriously eat away at FrontPage's customer base as Dreamweaver and other tools became more powerful and developer-friendly, while FrontPage suffered from an identity crisis by sticking to simpler, novice-friendly authoring that alienated web developers.


October, 2003 - Microsoft Office FrontPage 2003
(Version 6 [ Office 11])

Mini Review: On a sad note, this was the last of the FrontPage family of products - Microsoft dropped FrontPage in favor of Expression Web. FrontPage 2003 is still my all-time-favorite version of FrontPage; there's a great balance of powerful functionality and ease-of-use. (Note: Several years later, Microsoft cancelled the Expression Web family, thereby ending this line of products from Microsoft.)

IIS 6: FTP User Isolation with Multiple User Accounts

In IIS 4.0 and IIS 5.0, if you created a virtual directory that had a name that was identical to a user name, when the user logged in to the FTP site they would automatically be changed to their folder. When multiple users will access the same FTP content, you could create another virtual directory that is identical to the other user name and point it to the same content.

This allowed sharing a single FTP site across several users and content sets without advertising user names or content folders. Even though a user could type "CD /" from an FTP prompt, they would not be able to see the virtual directories from other user accounts on that server because virtual directories are not listed when a user types "ls -l" or "dir" from an FTP prompt at the root. That being said, this security feature still doesn't go far enough from a security perspective.

One of the great IIS 6.0 features is User Isolation, which is discussed in the Hosting Multiple FTP Sites with FTP User Isolation (IIS 6.0) topic on MSDN. As a quick review, there are three different isolation modes that you can choose when creating an IIS 6.0 FTP site:

  • "Do Not Isolate Users"
    No user isolation; FTP works like IIS 4.0 or IIS 5.0.
    (Not covered in this post.)
  • "Isolate Users"
    Simple user isolation through folders.
    (Described below.)
  • "Isolate Users Using Active Directory"
    Requires A.D. configuration.
    (Not covered in this post.)

To configure the "Isolate Users" mode, you first need to create your FTP site and choose the "Isolate Users" option when prompted for FTP User Isolation. Once the FTP site has been created, you need to create a physical folder named "LocalUser" for local user accounts or named after your domain under your FTP server's root folder. To isolate users to a specific folder, you use these rules that I copied from the MSDN topic that I listed earlier in this post:

  • For anonymous users, the home directory is LocalUser\Public under the FTP root directory.
  • For local users, the home directory is LocalUser\UserName under the FTP root directory.
  • For users that log on with Domain\UserName, the home directory is Domain\UserName under the FTP root directory.

This is very easy to configure, and when a user logs in to your FTP server they will be restricted to their physical folder under the FTP root. Typing "CD /" from an FTP prompt will always restrict the user within their own site.

That being said, because physical directories are required for this configuration it may seem like a step backward when you consider that you used to be able to create multiple virtual directories that pointed to content in varying locations and for multiple user accounts. Not to worry, however, because Windows provides a way around this limitation using NTFS junctions.

For those of you that are not familiar with NTFS junctions, there are several topics that discuss this. (For example, see Inside Win2K NTFS, Part 1.) A junction is somewhat like a symbolic directory link in the UNIX world, where a junction looks like a folder but points to content that is physically located somewhere else. There are two tools that you can use to create junctions, LINKD from the Windows Resource Kit, and JUNCTION from Using these tools with IIS 6.0 can allow you the freedom to deploy FTP folder structures much like you did with IIS 4/5 while utilizing the user isolation features in IIS 6.

Here's an example - when configuring an IIS 6.0 FTP site, I used the following steps:

  1. I chose the "Isolate Users" option when creating my FTP site.
  2. I created the "LocalUser" physical folder under my FTP site's root folder.
  3. I created junctions under the "LocalUser" physical folder that were named after user accounts and pointed to various content folders.

When a user logs in to my FTP site using their user account, they are automatically dropped in their content folder via the junction. Since you can create multiple junctions that point to the same content folder, you can create junctions for every user account that will work with a set of content.

I hope this helps!

Note: This blog was originally posted at