Just a short, simple blog for Bob to share his thoughts.
30 November 2014 • by Bob • FTP, SSL
For the next installments in my series about FTP clients, I will be taking a look at two FTP redirectors at the same time. In this specific blog post, I will focus on WebDrive (from South River Technologies), whereas my next post will look at NetDrive (from Bdrive Inc.).
At the time of this blog's writing, WebDrive is a for-retail FTP client and redirector which is available from the following URL:
For this blog post I will be using WebDrive version 12.10.4082.
Before I continue, I would like to begin with some background information: because of my ongoing blog series about FTP clients, one question that I have often been asked is, "Which FTP client do you use?" Usually I have to answer, "That depends." I know that my answer sounds non-committal, but to be honest - I have yet to find an FTP client that does everything that I want, although a few FTP clients have had enough features for me to use them quite often. And with that in mind, I need to point out that I purchased my first license for WebDrive over 12 years ago, and over the years I have periodically renewed my license for later versions. So to partially answer my earlier question - WebDrive is one of the FTP clients that I have used a lot.
That being said, WebDrive is different from many of the other FTP clients that I have reviewed because it is an Internet protocol redirector, meaning that it allows you to map drive letters to a variety of Internet-based repositories. (I'll discuss those various protocols and repositories shortly.)
When you install and open WebDrive, you are presented with a fairly empty user interface:
If you click the App Settings icon, you will be presented with a dialog box that offers dozens of customizable options:
When you click the New icon, you will be presented with a Site Wizard which lists the supported Internet protocols and repositories which you can use for mapping drives:
As you can see from the illustration above, WebDrive's list of support technologies is quite extensive: WebDAV, Secure WebDAV, FTP, Secure FTP, Google Drive, Amazon S3, SFTP, Dropbox, and FrontPage Server Extensions.
When you choose to create an FTP connection, WebDrive launches its Site Wizard, and the initial dialog box is pretty self-explanatory:
However, when you click the Advanced Settings button, you are presented once again with dozens of customizable settings for this specific connection:
As you continue to add sites with WebDrive, their connection types and current statuses are displayed in the user interface:
However, when you view your drives in Windows Explorer, even though network drives which are mapped through WebDrive are displayed with a different icon, you cannot tell the protocol type for mapped drives; this is one of the few times where NetDrive supported a feature that I really missed in WebDrive. (See my next blog entry for more information.)
WebDrive 12 supports command-line scripting, so if you find the features of the built-in Windows FTP client are somewhat limited, you can investigate scripting WebDrive:
WebDrive Command Line Parameters
I would love to take an in-depth look at all of the supported protocols in this review, but this series is about FTP clients, so I'll move on to the FTP-specific features that I normally review.
WebDrive 12 has built-in support for FTP over SSL (FTPS), and it supports both Explicit and Implicit FTPS. To specify which type of encryption to use for FTPS, you need to choose the appropriate option from the Security Type drop-down menu in the FTP Settings for a site:
True FTP hosts are not supported natively by WebDrive 12, and there are no settings that I could find which would allow me to customize the login environment in order to work around this situation.
WebDrive 12's login settings allow you to specify the virtual host name as part of the user credentials by using syntax like "ftp.example.com|username" or "ftp.example.com\username", so you can use virtual FTP hosts with WebDrive 12.
This concludes my quick look at a few of the FTP features that are available with WebDrive 12, and here are the scorecard results:
Client Name | Directory Browsing | Explicit FTPS | Implicit FTPS | Virtual Hosts | True HOSTs | Site Manager | Extensibility |
---|---|---|---|---|---|---|---|
WebDrive 12.10.4082 | N/A | Y | Y | Y | N1 | Y | N/A |
Notes:
|
That wraps things up for today's review of WebDrive 12. Your key take-aways should be: WebDrive is a powerful redirector with support for a wide variety of protocols. What's more, the WebDrive application and each individual connection contain dozens of options which allow you to customize the environment in hundreds of ways. As is the case with many of my reviews, I have barely presented a fraction of the capabilities that are available in WebDrive 12; you might want to try it out and experiment with all of its possibilities.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
29 April 2014 • by Bob • Random Thoughts
It seems that I have always had a difficult time explaining to people what I do at Microsoft. It's not that I'm unsure about what I do - the details of my job have always been crystal-clear to me and I love what I am doing. It's just that I can't find a way to explain things in a way that doesn't result in blank stares from anyone who isn't a geek. (This problem isn't limited to me, though; my non-technical wife simply responds "I have no idea what he does" when someone asks her what I do for a living.)
Here's a perfect example: when I was a Program Manager on the Internet Information Services (IIS) team, people would often ask me what I did for Microsoft, and I would reply with something like, "I help design and implement the web publishing protocols for Microsoft's web server."
Other Person: [Blank Stare]
I would attempt to remedy the situation by adding, "You know, I design Microsoft's implementation of Internet technologies like the File Transfer Protocol, WebDAV, and the FrontPage Server Extensions."
Other Person: [Blank Stare]
In a sometimes-futile effort to salvage the conversation from complete disaster, I would interject, "You like to use the Internet, right? Well, your computer is on one side of the Internet, and my team helps build the other side of the Internet. That's kind of what I do."
That comment would usually be met with a slight spark of recognition, which was sometimes followed by a half-muttered, "That's nice."
At one time or other during my tenure as a Program Manager on the IIS team I was responsible for a smattering of disparate technologies; things like FTP, WebDAV, FPSE, FastCGI, PHP, URL Rewrite, IIS Express, Log Parser, etc. Most of those technologies garnered little to no interest for the average person, and many of my coworkers found them pretty boring as well. Just the same, I personally found every one of those technologies completely fascinating. (Why else would I spend eight years trying to get just one new command added to FTP?)
A couple of years ago I left the IIS program management team and I joined the writing team which is responsible for documenting Microsoft's ASP.NET framework; and if you have to ask what that means, then you are probably not interested in the answer.
Still, people would ask me what I do for Microsoft, and I would try to explain my job with statements like, "I document the Application Programming Interfaces (or APIs) for Microsoft's ASP.NET."
Other Person: [Blank Stare]
I would try to nudge the conversation along by saying things like, "I help people write web code."
Other Person: [Blank Stare]
Skipping ahead in the conversation, I would usually make a last-ditch attempt by stating, "Let's say you wanted to create a website; if so, you might read something that I wrote in order to help you get started."
Sometimes this remark would illicit a hint of acknowledgment, but usually I just got another blank stare.
This leads me to a few days ago. My wife and I were at dinner, and a waiter asked me what I did for a living. In the back of my mind I started to say something like, "Well, these days I'm documenting a set of APIs that Java programmers will use with Microsoft Azure technologies [blah blah blah]..."
But what actually came out of my mouth was, "I could explain it to you, but I'm pretty sure you wouldn't want me to. Trust me."
I like that answer. I think I'll stick with it in the future. :-)
02 February 2011 • by Bob • FrontPage
The FrontPage Server Extensions from Ready-to-Run Software, Inc. (RTR), are available and supported only in the English language. But that being said, the localized language files for FPSE 2002 are available for download from Microsoft, and if you're willing to do a little work, you can configure the FPSE 2002 administration pages for your website to be displayed in sixteen different languages. (The specific list of languages is provided later in this blog.)
Please note that this information is being presented "as-is" and is not officially supported by Microsoft or RTR.
Download the self-extracting MSGS.EXE page that contains the FPSE 2002 language files from the following URL:
Extract the FPSE 2002 files by double-clicking the MSGS.EXE file and specifying an output folder.
By default, the installation package will install all of the localized files to the FPSE 2002 parent folder that is located at:
%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50
If you run the installation package on your server and accept the default path, then all of the languages will be available on your server.
However, if you only want to have one or more specific languages available, you would need to specify an alternate output folder for the extraction process. Under the output folder that you specified, you will see three folders: admisapi, bin, and isapi. Each of these folders will contain several subfolders, each of which contains the files for each of the localized languages. Each language that you want to have available on your server will need to be copied to their corresponding folders under the FPSE 2002 parent folder at:
%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50
You may copy all of the localized files to your FPSE directories, or you can select a single language by locating just the appropriate localized subfolders. For example, if you extracted the FPSE 2002 files to your C:\Temp folder and you wanted just the German language files, you would need to select the following folders:
C:\Temp\admisapi\1031
C:\Temp\bin\1031
C:\Temp\isapi\_vti_adm\help\1031
And you would copy those folders to the following paths:
%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50\admisapi\1031
%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50\bin\1031
%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50\isapi\_vti_adm\help\1031
Open the service.cnf file for one of your websites in Windows Notepad; this file will be kept in the _vti_pvt folder for a website. For example, for the Default Web Site this file would be at:
C:\Inetpub\wwwroot\_vti_vt\service.cnf
Choose the language abbreviation for your desired language from the list below. For example, if you were using German your abbreviation would be "de-de."
Language Description | LCID | Abbreviation |
Arabic - Saudi Arabia | 1025 | ar-sa |
Chinese - Taiwan | 1028 | zh-tw |
German - Germany | 1031 | de-de |
English - United States | 1033 | en-us |
French - France | 1036 | fr-fr |
Hebrew | 1037 | he |
Italian - Italy | 1040 | it-it |
Japanese | 1041 | ja |
Korean | 1042 | ko |
Dutch - Netherlands | 1043 | nl-nl |
Portuguese - Brazil | 1046 | pt-br |
Swedish - Sweden | 1053 | sv-se |
Thai | 1054 | th |
Chinese - China | 2052 | zh-cn |
Chinese - Hong Kong SAR | 3076 | zh-hk |
Spanish – Spain (Modern) | 3082 | es-es |
In the service.cnf file, locate the vti_defaultlanguage
entry and change the value to the abbreviation for your desired language. If this value does not exist, you will need to add it. For example, if you were using the German language the syntax would be:
vti_defaultlanguage:SR|de-de
When you open the FPSE 2002 administration pages for your website, you should now see it in your localized language. (Note: You may need to refresh your browser's cache to see it correctly.)
That's all that there is to it. Once again, please note that the version of the FPSE 2002 from RTR is only supported in English; so if you are having any issues, you will need to change the value of the vti_defaultlanguage
entry back to "en-us
" before you contact RTR for support.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
31 January 2011 • by Bob • FrontPage, IIS, WebDAV
In this latest installment on my series about configuring your server for hosting without the FrontPage Server Extensions (FPSE), I'd like to discuss a couple of WebDAV best practices that I like to use.
In my How to Migrate FPSE Sites to WebDAV walkthough, I discuss the following FPSE-related folders:
Folder | Notes |
_fpclass | Should contain publicly-available FrontPage code - but should be secured. |
_private | The FrontPage Server Extensions often keep sensitive data files in this folder, so it should be secured to prevent browsing. |
_vti_bin | This is the virtual directory for the FrontPage Server Extensions executables. This path is configured to allow executables to function, and since we are migrating sites to WebDAV it should be secured to prevent browsing. |
_vti_cnf | The FrontPage Server Extensions keep sensitive metadata files in this folder, so it should be deleted or secured to prevent browsing. |
_vti_log | The FrontPage Server Extensions keep author logs in this folder, so it should be deleted or secured to prevent browsing. |
_vti_pvt | This folder holds several files that contain various metadata for your website, and should be secured. |
_vti_txt | This folder contains the text indices and catalogs for the older FrontPage WAIS search. Since later versions of FrontPage only used Index Server, it is safe to delete this folder, but at the very least it should be secured to prevent browsing. |
fpdb | FrontPage keeps databases in this folder, so it should be secured to prevent browsing. |
One of the actions that I usually take on my servers is to lock down all of these folders for my entire server using Request Filtering. To do so, open a command prompt and enter the following commands:
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_cnf']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_fpclass']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_private']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_log']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_pvt']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_txt']" /commit:apphost
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='fpdb']" /commit:apphost
Note: You should only enter the following commands if you are sure that you will not be using FPSE anywhere on your server!
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.webServer/security/requestFiltering /+"hiddenSegments.[segment='_vti_bin']" /commit:apphost
These settings will prevent any of the FPSE-related paths from being viewed over HTTP from a web browser; web clients will receive an HTTP Error 404.8 - Not Found message when they attempt to access those paths. But that being said - when you enable WebDAV for a website by using the Internet Information Services (IIS) Manager, it will configure the Request Filtering settings that enable WebDAV clients to access those paths through WebDAV requests, even though access from a web browser is still blocked. (All of this is made possible through the built-in integration between WebDAV and Request Filtering.
In part 4 of this blog series I discussed why I like to set up two websites when using WebDAV; as a quick review, here is the general idea for that environment:
There is a list of several reasons in that blog post why using two sites that point to the same content can be beneficial, and I won't bother quoting that list in this blog post - you can view that information by looking at that post.
But that being said, one of the items that I mentioned in that list was using separate application pools for each website. For example:
This configuration helps alleviate problems from uploading invalid Web.config files that might otherwise prevent HTTP access to your website. By way of explanation, the WebDAV module attempts to validate Web.config files when they are uploaded over WebDAV - this is done to try and prevent crashing your HTTP functionality for a website and being unable to fix it. Here's what I mean by that: IIS 7 allows configuration settings to be delegated to Web.config files, but if there is a mistake in a Web.config file, IIS 7 will return an HTTP Error 500.19 - Internal Server Error message for all HTTP requests. Since WebDAV is HTTP-based, that means that you won't be able to fix the problem over WebDAV. (If the WebDAV module didn't perform any validation, that means that your website would become unusable and unrepairable if you had uploaded the bad Web.config file over WebDAV.) To help alleviate this, the WebDAV module performs a simple validation check to prevent uploading invalid Web.config files. But if you save an invalid Web.config file through some other means, like the local file system or over FTP, then you will have no way to repair the situation through WebDAV.
This leads us back to the idea that you can implement when you are using two websites - you can configure the application pool for the WebDAV-enabled website to ignore delegated configuration settings; so it doesn't matter if you have an invalid Web.config file - you will always be able to fix the problem over WebDAV. To configure an application pool to ignore delegated configuration settings, open a command prompt and enter the following commands:
cd %WinDir%\System32\inetsrv
appcmd.exe set config -section:system.applicationHost/applicationPools /[name='authoring.example.com'].enableConfigurationOverride:"False" /commit:apphost
Note: you need to update the highlighted section of that example with the name of your website, such as "Default Web Site," etc.
When you have two websites configured in this example and you have an invalid Web.config file that is causing the HTTP 500 error for the www.example.com website, you can still connect to authoring.example.com via WebDAV and fix the problem.
For additional information on the concepts that were discussing in this blog, see the following topics:
I hope this helps.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
28 April 2010 • by Bob • FrontPage
I've had a few questions about getting the FrontPage 2002 Server Extensions (FPSE2002) AllowUNC feature to work with Windows Server 2008, so I thought that I would put together a blog from some of the information that I had been giving out whenever someone was having problems.
As a little bit of background information, Windows 2003 Server shipped with a later version of FPSE2002 than had previously been released, and that version of FPSE2002 was used as the code base for the version of FPSE2002 that was later shipped for Windows Server 2008. One the great features of this release was the ability to host your content on a remote server using a UNC share, which is something that web administrators had been requesting for years. Microsoft wrote a full whitepaper that details all of the possible configurations and steps to configure FPSE2002 with this feature at the following URL:
That being said, that whitepaper is quite large, and not all of it is necessary if you simply want to host FPSE2002-based content on a UNC path. With that in mind, I have come up with an abbreviated set of steps that uses the whitepaper as a base for enabling this feature. To be more specific, I was able to implement this feature by using only the following sections of that whitepaper:
The body of this blog post is an excerpt from the whitepaper, and contains only the steps that I used to get my test scenario up and running. For my test, I set up a domain controller, a file server, and a web server; all running Windows Server 2008 or Windows Server 2003. I include notes when necessary to highlight issues that I ran into.
Additional Notes:
You must configure a shared folder on the file server and grant the Web server access to the contents of that folder. Note that you must set the permissions for the folder itself, not a parent folder. It is recommended that you also implement IP Security on the file server, so that only the Web server, the domain controller, and other administrator computers can access the file server over TCP/IP. For more information about configuring IP Security, see Setting Up IPsec Domain and Server Isolation in a Test Lab.
Giving Everyone full control to your server share is necessary so that all users of your Web site can view the Web site information and run the ASP pages required to use FrontPage 2002 Server Extensions. However, you do not want to allow other computers or other servers access to the file share and those ASP pages. It is recommended that you implement Internet Protocol (IP) Security to help prevent users and computers from circumventing the FrontPage 2002 Server Extensions and Internet Information Services security for the file share and ASP pages.
Note - The separate user management feature for FrontPage 2002 Server Extensions also helps secure the process for accessing ASP pages through the file system. It is recommended that you implement this feature if you are connecting Web sites to UNC shares. For more information about managing users separately, see Authenticating Users Separately For Each Virtual Server.
You use Internet Information Services (IIS) to create your new virtual server. You must also decide how to configure the security settings for your virtual server.
Note - If you chose to allow anonymous access for the virtual server, you must specify the domain account to use for anonymous users. When you use a local folder, you can use the default anonymous user (usually IUSR or IUSR_Machinename). To connect to a shared resource on a domain, however, you must specify an account with rights to the domain. Be sure to use an account with limited rights to the computers and resources in your domain. Do not unintentionally give anonymous users the ability to administer your server or print to your network printers.
Note from me:
As stated by me earlier, this entire article does not appear to work unless you specify a domain-level IUSR account in IIS, even if you are going to not allow anonymous access. In my testing, it seems to fail when anonymous is disabled and the anonymous user had been local, whereas it succeeded when the anonymous user is a domain-account with rights to the share, even though anonymous is disabled for the site.
After you have created the virtual server, you must configure the security settings. When a Web site user requests a file that actually resides on a network share, there are two methods that FrontPage Server Extensions can use to provide the required authentication information:
Warning - Basic authentication forwards the requestor's username and password over the network. This means that usernames and passwords can be captured using a network packet analyzer. Only use basic authentication if you are sure that potential hackers don't have access to your network cabling or wireless media.
Note from me:
As stated by me earlier, I only tested with Basic Authentication; I did not try Kerberos. Since we are making a single hop to another server, I would expect simple NTLM to fail. See KB 315673 for a description of single versus double hop setups when working with IIS configurations. But that being said, Windows Authentication in an Internet environment is impractical, so in most scenarios this point is moot.
After you create the virtual server, and before you can extend it with FrontPage 2002 Server Extensions, you must set the following registry entries to enable your Web server to work with a shared UNC folder:
Both subkeys are under the following path in the registry depending on your version of Windows:
If these subkeys do not exist yet, you can add them as new string values, and then set them to 1.
After the virtual server has been created and configured, you are ready to extend it with FrontPage 2002 Server Extensions. You must extend the virtual server before you can publish Web site content to it.
After you extend the site, it is recommended that you run server health to make sure the permissions are set correctly and do not allow unauthorized access. To run server health, use the following command-line operations:
cd /d "%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\50\bin"
owsadm.exe -o check -p 80 -w /
As I mentioned in the beginning of this post, there are a lot of steps to get this working, but it's possible to do so.
I hope this helps. ;-]
23 April 2008 • by Bob • FrontPage, IIS, WebDAV
Following up on my last blog post, today's blog post will discuss some of the highlights and pitfalls that I have seen while transitioning from using the FrontPage Server Extensions to publish web sites to WebDAV. It should be noted, of course, that FTP still works everywhere - e.g. Expression Web, FrontPage, Visual Studio, etc. As the Program Manager for both WebDAV and FTP in IIS I can honestly say that I love both technologies, but I'm understandably biased. <grin> That said, I'm quite partial to publishing over HTTP whenever possible, and Windows makes it easy to do because Windows ships with a built-in WebDAV redirector that enables you to map a drive to a web site that is using WebDAV.
To set the mood for today's blog, let's have a little fun at FPSE's expense...
To start things off, I wrote a detailed walkthrough with instructions regarding how to migrate a site that is using FPSE to WebDAV that is located at the following URL:
Migrating FPSE Sites to WebDAV
http://go.microsoft.com/fwlink/?LinkId=108347
I wrote that walkthrough from the point-of-view that you might want to preserve the FPSE-related metadata in order to open your web site using a tool like Visual Studio or FrontPage. Neither of these tools have native WebDAV support, so you have to map a drive to a WebDAV-enabled web site in order to use those tools, and the instructions in that walkthrough will lead you through the steps to make the FrontPage-related metadata available to those applications over WebDAV.
The part of that walkthrough that makes backwards compatibility work is where I discuss adding settings for the IIS 7 Request Filtering feature so that FPSE-related metadata files are blocked from normal HTTP requests, but still available to WebDAV. (These metadata settings are all kept in the folders with names like _vti_cnf, _vti_pvt, etc.)
It should be noted, however, that if you are not interested in backwards compatibility, the steps are much simpler. In Step 1 of the walkthrough, you would choose "Full Uninstall" as the removal option, and all of your _vti_nnn folders will be deleted. If you've already removed FPSE from a web site and you chose the "Uninstall" option, you can remove the _vti_nnn folders from your site by saving the following batch file as "_vti_rmv.cmd" in the root folder of you web site and then running it:
dir /ad /b /s _vti_???>_vti_rmv.txt for /f "delims=;" %%i in (_vti_rmv.txt) do rd /q /s "%%i" del _vti_rmv.txt
It's worth noting, of course, that this batch file can be pretty disastrous if run in the wrong web site, as FPSE will no longer be able to access any of the metadata that defined your web site. Any content stored in folders like _private, fpdb, _overlay, etc., will all be preserved.
Windows Vista and Windows Server 2008 both ship a first-class director, making it easy to use WebDAV sites across the Internet as though they were local shares. Using the WebDAV director is as intuitive as mapping a drive to any UNC share, you just specify the drive letter and the destination URL:
If you prefer, you can also use the command-line to map a drive to a WebDAV site:
net use * http://www.example.com/ Enter the user name for 'www.example.com': msbob Enter the password for www.example.com: ****** Drive Z: is now connected to http://www.example.com/. The command completed successfully.
Rather than repeat myself any more than necessary, I wrote the following walkthrough for anyone that plans on using the WebDAV redirector:
Using the WebDAV Redirector
http://go.microsoft.com/fwlink/?LinkId=112138
That walkthrough discusses how to install the redirector if necessary, how to map drives to WebDAV sites, and how to troubleshoot any problems that you might see.
One of my favorite publishing features in Expression Web is that it has native WebDAV support built-in, so it doesn't have a dependency on the WebDAV redirector in order to work with a WebDAV-enabled web site. If you're currently using Expression Web to open a web site using FPSE, the change to WebDAV should be fairly seamless. If you're currently using FrontPage, the Expression Web team has put together a whitepaper that describes the differences between FrontPage and Expression Web, which is available from the following link:
That being said, when opening a WebDAV web site in Expression Web, you simply enter the HTTP URL the same way that you would if you were opening a site using FPSE:
When you first open a web site using WebDAV, Expression Web will prompt you whether to edit the web site live, or edit locally and publish your changes later:
Once your live web site is opened, the WebDAV editing experience is what you would have expected from using FPSE:
So in closing, I've presented a few things to consider when working with WebDAV instead of FPSE. Using the WebDAV redirector makes working with WebDAV sites as easy as working with network shares, and using Expression Web is by far the easiest way to edit WebDAV sites.
17 April 2008 • by Bob • FrontPage, IIS
Today's blog post will be the first in a series of blog posts that I intend to write about my experiences with putting together a Windows Server 2008 machine without using the FrontPage Server Extensions (FPSE) for any web publishing. The main goal of this series is to describe some of the highlights and pitfalls that I have run into while transitioning away from FPSE.
Over the years I've seen the users of FPSE broken down into two groups: those that love FPSE and those that hate FPSE. So before anyone thinks that I fall into the category of people that hate FPSE, in this first part of the series I will explain a brief bit of my history with FPSE.
In late 1995, Microsoft bought a little-known Massachusetts-based company named Vermeer Technologies, Inc., which really only had one product: FrontPage 1.0. (Incidentally, that's where all of those _vti_nnn folders that FPSE uses come from: the "vti" stands for Vermeer Technologies, Inc.)
FrontPage was quickly transitioned into the Microsoft array of Office products, and Microsoft realized that they needed someone to support it. With that in mind, four of my coworkers and I started a FrontPage support team in Microsoft's Product Support Services (PSS) organization. The following photo shows what the five of us looked like "way back when..."
Back then we supported both the FrontPage client and FPSE. Two coworkers specialized on what was then a small array of Windows-based servers (WebSite, Netscape, etc.), while another coworker and I specialized on the wider array of Unix-based servers, (NCSA, CERN, Netscape, Apache, etc.) At first FPSE was 100% CGI-based, but Microsoft soon released Internet Information Services (IIS) 1.0 for Windows NT Server 3.51 and we provided an ISAPI version of FPSE when FrontPage 1.1 was released in early 1996. In either case, FPSE was often somewhat difficult to configure, so a couple of my coworkers and I used to spend our free time searching the Internet looking for servers that were using FPSE incorrectly, then we would call them and offer to help fix their web sites for free. (Support was different back then, wasn't it? )
Industry acceptance for FrontPage and FPSE grew rapidly through the releases of FrontPage 97 and FrontPage 98. During that same time period Microsoft released IIS 2.0 through IIS 4.0 for Windows NT Server 4.0, where I switched from supporting the FrontPage client and refocused my career to work exclusively with FPSE and IIS. Over a short period of time a couple of coworkers and I became the escalation point for all the really difficult FPSE cases - so chances are good that if you were using FPSE back then and you had a problem then one us us probably helped you fix it. Sometime around this period Microsoft decided to scrap internal development for the Unix version of FPSE, so Microsoft contracted Ready-to-Run Software, Inc., to port FPSE to Unix.
The next couple of years saw the releases of FrontPage 2000, FrontPage 2002, and FrontPage 2003, where FrontPage did its best to move away from a simple web authoring tool into more of a feature-rich developer tool. During that same time period Microsoft released IIS 5.0 for Windows Server 2000 and IIS 6.0 for Windows Server 2003. Through all of these releases I slowly transitioned from an escalation team member to writing content, where I wrote or edited hundreds of Knowledge Base articles about FPSE and IIS for Microsoft's support web site. I also worked extensively with several members of the IIS product team in order to get some much-needed changes into FTP and WebDAV.
What was interesting about the release of FrontPage 2003 is that Microsoft did not release a version of FPSE to coincide with that release. This decision was based on the fact that the product team that was responsible for FPSE was also responsible for SharePoint, and they decided to drop FPSE as a separate product in favor of SharePoint. What this meant to FPSE end users was - FPSE was being slowly phased out in favor of SharePoint, or in favor of competing publishing technologies like WebDAV or FTP.
After the release of IIS 6.0 I accepted a position as an SDK writer on the IIS User Education team, and a short time later I found out that the Product Unit Manager for IIS, Bill Staples, was looking for someone to take over web publishing in IIS 7.0 on Windows Server 2008. Bill and I had already had several discussions on the subject so I volunteered for the position, and for the last few years my life has been happily consumed with shipping FPSE, FTP, and WebDAV for Windows Server 2008.
During this same time period, however, Microsoft ended the line of FrontPage products; the team responsible for the FrontPage client splintered into the groups that now make the SharePoint Designer and Expression Web products, and the FPSE product team was now focusing exclusively on SharePoint. This situation meant that no one that worked on FPSE in the past was available to work on a new version for Windows Vista or Windows Server 2008, which left FPSE users in a predicament if they wanted to upgrade their operating systems. With this in mind, the IIS product team decided to contract Ready-to-Run Software, Inc. again in order to port the Windows version of FPSE to Windows Vista and Windows Server 2008. Even then, though, FPSE's days are numbered.
So, the short end to this long story is that I've been around the FrontPage Server Extensions in one way or another ever since the very beginning, and I've seen the good, the bad, and the ugly.
In my next post, I'll discuss using WebDAV instead of FPSE.
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
14 December 2007 • by Bob • FrontPage, IIS, IIS News Item
Earlier today Microsoft and Ready-to-Run Software released to web the Release Candidate 1 (RC1) version of the FrontPage 2002 Server Extensions for IIS 7.0 on Windows Server 2008 and Windows Vista. This build now includes a combined installation package for 32-bit and 64-bit versions of Windows.
Listed below is the link for the download page for the combined 32-bit/64-bit installation package:
FPSE 2002 RC1 for IIS 7 is supported on all of the the following operating systems:
Once again, additional documentation about installing and using this version of FPSE 2002 can be found at the following URL:
Installing the FrontPage 2002 Server Extensions:
http://go.microsoft.com/fwlink/?LinkId=88546
While this release is a beta version and not technically supported, feedback about this release and requests for information can be sent to fpbeta@rtr.com or posted to the following web forum:
IIS7 - Publishing:
http://forums.iis.net/1045.aspx
Thanks!
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
02 October 2007 • by Bob • FrontPage, IIS, IIS News Item
Earlier today Microsoft and Ready to Run Software released to web the Release Candidate 0 (RC0) version of the FrontPage 2002 Server Extensions for IIS 7.0 on Windows Server 2008 and Windows Vista. This build now includes support for 64-bit Windows, and addresses several issues that we've seen since the FPSE release that shipped last April.
Listed below are the links for the download pages for each of the individual installation packages:
FPSE 2002 RC0 for IIS 7 is supported on all of the the following operating systems:
Additional documentation about installing and using this version of FPSE 2002 can be found at the following URL:
Installing the FrontPage 2002 Server Extensions:
http://go.microsoft.com/fwlink/?LinkId=88546
Quoting and updating some of my notes from the last release:
It should be noted that this version of FPSE 2002 is a beta release and is therefore unsupported. Also, this version of FPSE 2002 introduces no new functionality; it is essentially the same version of FPSE 2002 that was created for Windows Server 2003 that has been updated to work on Windows Server 2008 (code name "Longhorn") and Windows Vista. That being said, this version of FPSE 2002 will enable web hosters and developers to author their web content on servers or workstations that are running IIS 7.0 on Windows Server 2008 and Windows Vista.
While this release is a beta version and not technically supported, feedback about this release and requests for information can be sent to fpbeta@rtr.com or posted to the following web forum:
IIS7 - Publishing:
http://forums.iis.net/1045.aspx
Thanks!
28 April 2007 • by Bob • FrontPage, IIS
Following up on my FrontPage Server Extensions on Vista and Longhorn blog post from last February, I'm happy to announce that Microsoft and Ready to Run Software have released the first beta version of the Microsoft FrontPage 2002 Server Extensions (FPSE 2002) for Windows Server Code Name "Longhorn" and Windows Vista.
The beta version of FPSE 2002 can be downloaded from the following URL:
Additional documentation about installing and using this version of FPSE 2002 can be found at the following URL:
It should be noted that this version of FPSE 2002 is a beta release and is therefore unsupported. Also, this version of FPSE 2002 introduces no new functionality; it is essentially the same version of FPSE 2002 that was created for Windows Server 2003 that has been updated to work on Windows Server Code Name "Longhorn" and Windows Vista. That being said, this version of FPSE 2002 will enable web hosters and developers to author their web content on servers or workstations that are running IIS 7.0 on Windows Server Code Name "Longhorn" and Windows Vista.
Feedback about this release can be sent to fpbeta@rtr.com.