Microsoft Bob

Just a short, simple blog for Bob to share some tips and tricks.

Be sure to check out my non-technical blog at www.geekybob.com.

Month List

IIS 6: Setting up SSL - Part 1: Making a Request

In part one of my series on setting up SSL on IIS 6, I'll describe all of the steps that are necessary to request an SSL certificate for a website. Once you have completed your certificate request, you would send that to a Certificate Authority (CA) for approval. In subsequent blog posts I'll discuss submitting a certificate to a CA - specifically Certificate Services on Windows Server 2003 - and then I'll discuss obtaining a certificate and installing it on your IIS server. But for now, let's get started with a creating certificate request. To do so, use the following steps.

  1. Bring up the properties for a website:

  2. Switch to the "Directory Security" tab and click "Server Certificate:"

  3. Click "Next" to bypass the first page:

  4. Choose to "Create a new certificate" and click "Next":

  5. Choose to "Prepare the request now, but send later" and click "Next":

  6. Enter a friendly "Name" for the request, and your desired "Bit length". Click "Next":

  7. Enter your "Organization" and "Organization unit", then click "Next":

  8. Enter the "Common name" for your site then click "Next":

    Note: This must be the actual web address that users will browse to when they hit your site.

  9. Enter your "Country", "State", and "City", then click "Next":

  10. Enter the "File name" for your request, then click Next:

  11. Review the information for your request, then click Next:

  12. Click "Finish" to exit the wizard.

FYI: If you were to open your request file in Notepad, it will look something like the following:

In the next post of my blog series, I'll show you how to use Certificate Services on Windows Server 2003 to obtain a certificate.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

Posted: Feb 14 2011, 16:12 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS | SSL
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

Life after FPSE (Part 6)

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.

Blocking FPSE-related Folders with Request Filtering

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. ;-]) Enabling access to these folders over WebDAV is necessary if you are opening your website over a WebDAV-mapped drive while you are using authoring clients that do not have native WebDAV support, such as FrontPage or Visual Studio.

Two Sites are Better Than One

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:

  • The first website (e.g. www.example.com) is used for normal HTTP web browsing
  • The second website (e.g. authoring.example.com) is used for for WebDAV authoring

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:

  • The first application pool (e.g. www.example.com) is configured to use delegated configuration
  • The second application pool (e.g. authoring.example.com) is configured to ignore delegated configuration

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.

More Information

For additional information on the concepts that were discussing in this blog, see the following topics:

  • Life after FPSE (Part 4) - This blog post discusses a couple of WebDAV-related topics, and includes my list of additional reasons why configuring two websites when you are using WebDAV can be advantageous.
  • Adding Application Pools - This topic contains the detailed information about the enableConfigurationOverride setting for an application pool.
  • Using the WebDAV Redirector - This walkthrough discusses mapping drives to WebDAV-enabled websites.

I hope this helps. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
Posted: Jan 31 2011, 12:06 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: FrontPage | IIS | WebDAV
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

IIS 6: Setting up SSL - Overview

Many years ago I wrote a series of instructions that used dozens of screenshots in order to show my coworkers how to set up and enable Secure Sockets Layer (SSL) communications in IIS 5, which I eventually turned into a blog series on one of my personal blog sites. A few years later I wrote a sequel to that series of instructions for my coworkers, and I wanted to turn that into a series of walkthroughs in the IIS.net website. Sometime ago I proposed the idea to Pete Harris, who was in charge of IIS.net at the time, but then I changed jobs and we scrapped the idea. We followed up on the idea a short time ago, but we just couldn't find a place where it made sense to host it on IIS.net, so Pete suggested that I turn it into another blog series. With that in mind, over a series of several blog entries I will show how to configure SSL on IIS 6.

Note: This first post will leverage a lot of the content from the overview that I wrote for my IIS 5 blog series, but subsequent posts will reflect the changes in IIS 6.

Much like IIS 5, setting up SSL on IIS 6 is pretty simple. SSL is a Public Key/Private Key technology, and setting up SSL is essentially obtaining a Public Key from a trusted organization. The basic process for working with SSL is reduced to the following actions:

  1. Creating a Certificate Request
  2. Obtaining a Certificate from a Certificate Authority
  3. Installing the Certificate

While not necessary, installing certificate services on your computer is helpful when troubleshooting SSL issues, and I'll discuss that later in this blog series.

Creating a Certificate Request

This is a series of steps that need to be performed on the web server, and they differ widely depending on the server and version. A web administrator is required to enter information about their organization, their locality, etc. This information will be used to validate the requester.

Obtaining a Certificate from a Certificate Authority

This is when a web administrator submits their request for a certificate to a Certificate Authority (CA), which is a trusted organization like VeriSign or Thawte. For a list of trusted organizations, see the following section in Internet Explorer.

You can choose to trust a new CA by obtaining the Root Certificate from the CA. (I'll post an Obtaining a Root Certificate blog with more information later.)

Installing the Certificate

After a request has been processed by a CA, the web administrator needs to install the certificate on the web server. Once again, this series of steps needs to be performed on the web server, and the steps differ depending on the web server and version.

For the Future...

In future blogs I'll go through the steps for creating certificate requests, obtaining certificates from a CA, and installing certificates. Following that, I'll discuss setting up a CA for testing SSL in your environment.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

Posted: Jan 31 2011, 10:13 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

IIS: Notes on Server-Side Includes (SSI) Syntax (KB 203064 Revisited)

Many years ago I wrote Microsoft KB article 203064 about using Server-Side-Include (SSI) files with IIS 4 and IIS 5, but that KB has long since vanished from Microsoft's support website because it was never updated for IIS 6 or IIS 7. I eventually turned the information from that KB article into a blog post, but that being said, I still see questions about SSI showing up in the IIS forums every once in a while. There was a great deal of useful information in that KB article about general SSI syntax and several practical examples for SSI directives, so I thought that it would make a good blog post if I updated the information from that KB for later versions of IIS.


SUMMARY

This blog post details some features that are available in the Microsoft implementation of Server-Side Include (SSI) files for Internet Information Server (IIS) and provides general syntax and examples for SSI directives.


APPLIES TO

  • Microsoft Internet Information Services 7.5
  • Microsoft Internet Information Services 7.0
  • Microsoft Internet Information Services 6.0
  • Microsoft Internet Information Services 5.0
  • Microsoft Internet Information Server 4.0

MORE INFORMATION

SSI files are most commonly used with IIS to allow content authors to include the contents of one file inside another file, allowing the easy creation of script libraries or page headers and footers to standardize the look and feel of your web content. SSI consists of very simple commands that are contained within HTML comment tokens, and are limited in functionality. Higher-level programming languages like ASP, ASP.NET, PHP, etc. make the need for SSI considerably less necessary than in previous years. In addition, programming features such as ASP.NET's Master Pages and Dynamic Web Template (DWT) files that are used by Dreamweaver, Expression Web, and FrontPage have replaced much of the need for SSI. Because of this, SSI is an outdated technology by today's standards. With that in mind, web developers are highly encouraged to migrate their SSI content to another technology, such as ASP.NET or PHP.

SSI Implementation Details

SSI files are mapped by file extension to a preprocessor or handler dynamic-link library (DLL), in the same way that file like ASP, ASP.NET, PHP, etc. are mapped to their requisite handlers. In the case of SSI, the specific handler is ssiinc.dll for IIS 4 through IIS 6 and iis_ssi.dll for IIS 7. SSI files on Windows are often named with .stm file extensions, although extensions of .shtm and .shtml are also supported.

Changes Between IIS Versions

  • SSI is not enabled by default on IIS 6. To enable SSI on IIS 6, set the status for the Server Side Includes web service extension to Allowed in the Internet Information Services (IIS) Manager.
  • SSI is not installed by default on IIS 7. To install SSI on IIS 7, see the Server Side Include <serverSideInclude> topic.
  • The cmd directive for #exec is disabled by default in IIS 5 and IIS 6. To enable the cmd directive, see Microsoft KB article 233969.
  • The cmd directive for #exec is now disabled for SSI files in IIS 7; you can only use the cgi directive.

General SSI Syntax

SSI is employed by the use of special preprocessing directives in SSI documents that are contained within HTML comment tokens; these directives are parsed by the SSI DLL and processed into HTML that is returned to a web client. All SSI directives take the following general form:

<!--#<DIRECTIVE> [<PARAMETER> = <VALUE>]-->

IIS supports a small set of SSI directives, and each directive has different parameters that configure the output for the directive. Other web servers may support a different set of SSI directives and parameters, so SSI files are not 100% compatible across different technologies.

Supported Directives

The following directives are supported in the IIS implementation of SSI:

  • #config - Configures how variables and commands are displayed.
    • The general syntax for the #config directive is as follows:
      <!-- #CONFIG <ERRMSG/TIMEFMT/SIZEFMT>="<format>" -->
    • The following is an example of a simple page that uses the #config directive:
      <html>
      <body>
      <!-- #CONFIG TIMEFMT="%m/%d/%y" -->
      <p>Today's Date = <!--#ECHO VAR = "DATE_LOCAL" --></p>
      <!-- #CONFIG TIMEFMT="%A, %B %d, %Y" -->
      <p>Today's Date = <!--#ECHO VAR = "DATE_LOCAL" --></p>
      </body>
      </html>
    • Note: See the Parameter Values for the #config Directive section later in this blog for more information about configuring dates with the #config directive.
  • #echo - Inserts the value of various Common Gateway Interface (CGI) server variables.
    • The general syntax for the #echo directive is as follows:
      <!--#ECHO VAR = "<CGI_VARIABLE_NAME>"-->
    • The following is an example of a simple page that uses the #echo directive:
      <html>
      <body>
      <p>Server Name = <!--#ECHO VAR = "SERVER_NAME"--></p>
      <p>Date = <!--#ECHO VAR = "DATE_LOCAL" --></p>
      <p>Page URL = <!--#ECHO VAR = "URL" --></p>
      </body>
      </html>
    • For a list of  supported CGI server variables, see IIS Server Variables.
  • #exec - Executes CGI or Internet Server API (ISAPI) command scripts and inserts output into an HTML document.
    • The general syntax for the #exec directive is as follows:
      <!-- #EXEC <CGI/CMD>="<command>" -->
    • The following is an example of a simple page that uses the #exec directive:
      <html>
      <body>
      <p>Root Directory of C:</p>
      <pre><!--#EXEC CGI = "/cgi-bin/HelloWorld.exe" --></pre>
      </body>
      </html>
    • Notes:
      • The CMD command for the #exec directive is disabled by default on IIS 5 and IIS 6. For more information, see the following Microsoft Knowledge Base article:

        233969 SSIEnableCmdDirective is set to FALSE by default

      • The CMD command for the #exec directive is was removed from IIS 7. For more information, see the following Microsoft Knowledge Base article:

        Server Side Include <serverSideInclude>

  • #flastmod - Retrieves the last modification time of a specified file.
    • The general syntax for the #flastmod directive is as follows:
      <!--#FLASTMOD <FILE/VIRTUAL> = "filename.ext"-->
    • The following is an example of a simple page that uses the #flastmod and #config directives:
      <html>
      <body>
      <!-- #CONFIG TIMEFMT="%m/%d/%y" -->
      <p>Modified Date = <!--#FLASTMOD FILE="filename.ext"--></p>
      <!-- #CONFIG TIMEFMT="%B %d, %Y" -->
      <p>Modified Date = <!--#FLASTMOD FILE="filename.ext"--></p>
      </body>
      </html>
  • #fsize - Retrieves the size of a specified file.
    • The general syntax for the #fsize directive is as follows:
      <!--#FSIZE <FILE/VIRTUAL> = "filename.ext"-->
    • The following is an example of a simple page that uses the #fsize and #config directives:
      <html>
      <body>
      <!-- #CONFIG SIZEFMT="BYTES" -->
      <p>File Size = <!--#FSIZE FILE="filename.ext"--> bytes</p>
      <!-- #CONFIG SIZEFMT="ABBREV" -->
      <p>File Size = <!--#FSIZE FILE="filename.ext"--> KB</p>
      </body>
      </html>
  • #include - Includes the contents of one specified file inside another.
    • The general syntax for the #include directive is as follows:
      <!--#INCLUDE <FILE/VIRTUAL> = "filename.ext"-->
    • The following is an example of a simple page that uses the #include directive:
      <html>
      <body>
      <!--#INCLUDE FILE = "header.inc"-->
      <p>Hello World!</p>
      <!--#INCLUDE VIRTUAL = "/includes/footer.inc"-->
      </body>
      </html>
    • Note: See the More Information on File and Virtual Syntax section later in this blog for more information about using file versus virtual values.

Parameter Values for the #config Directive

The #config directive supports a large array of possible parameter values, which are listed in the following table. Note: All of these values are case-sensitive.

ValueDescriptionExample
%A Full Weekday Name Tuesday
%a Short Weekday Name Tue
%B Full Month Name December
%b Short Month Name Dec
%c Full Date & Time 12/28/10 19:52:19
%d Day of Month as a Number 28
%H Hours as a Number on a 24-Hour Clock 19
%I Hours as a Number on a 12-Hour Clock 07
%j Julian Date (Offset from Start of Year) 362
%M Minutes as a Number 52
%m Month as a Number 12
%p AM or PM Indicator PM
%S Seconds as a Number 19
%U Week Number (Offset from Start of Year) 52
%W Week Number (Offset from Start of Year) 52
%w Day of the Week as a Number 2
%X Short Time 19:52:19
%x Short Date 12/28/10
%Y Four-Digit Year as a Number 2010
%y Two-Digit Year as a Number 10
%Z Time Zone Name Pacific Standard Time
%z Time Zone Name Pacific Standard Time

Note: The following Windows Script Host (WSH) code will create a sample SSI page that you can use to test the parameter values for the #config directive:

Option Explicit
Dim objFSO, objFile, intCount
Set objFSO = WScript.CreateObject("Scripting.Filesystemobject")
Set objFile = objFSO.CreateTextFile("ssitest.stm")
objFile.WriteLine("<html>")
objFile.WriteLine("<body>")
For intCount = Asc("A") To Asc("Z")
objFile.WriteLine("<!-- #CONFIG TIMEFMT=""%" & _
UCase(Chr(intCount)) & """ --><p>%" & _
UCase(Chr(intCount)) & _
" = <!--#ECHO VAR = ""DATE_LOCAL"" --></p>")
objFile.WriteLine("<!-- #CONFIG TIMEFMT=""%" & _
LCase(Chr(intCount)) & """ --><p>%" & _
LCase(Chr(intCount)) & _
" = <!--#ECHO VAR = ""DATE_LOCAL"" --></p>")
Next
objFile.WriteLine("</body>")
objFile.WriteLine("</html>")

More Information on File and Virtual Syntax

SSI directives that use file paths can reference files by using a file or virtual path.

  • The file element is used with files that are relative to the folder of the current document. The following example includes a file in the current folder:
    <!--#include file="myfile.txt"-->
  • The virtual element represents paths that are relative to the base folder of the Web server. The following example includes a file in the /scripts virtual folder:
    <!--#include virtual="/scripts/myfile.txt"-->

REFERENCES

For additional information on using SSI with IIS, click the following article numbers to view the articles in the Microsoft Knowledge Base:

  • 169996 To run an ISAPI DLL with #exec, use the CGI statement
  • 172024 INFO: Server Side Include Directives Are Not Processed by ASP
  • 195291 How to disable #exec in Server-Side Include files
  • 289496 Error Messages Appear and Access Violations Occur After You Upload SSI ASPs in IIS 5.0
  • 299982 How to create server-side include files to package ASP scripts
  • 308176 BUG: SSI #EXEC CMD Directive Does Not Work in IIS 5.1
  • 318176 SSI Output Disappears After You Apply Security Patches
  • 954754 Mappings for server-side include (SSI) directives do not work after you upgrade from IIS 6.0 to IIS 7.0

For more Microsoft Knowledge Base articles about using SSI with IIS, click here.

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

Posted: Dec 28 2010, 12:36 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS
Tags: ,
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

Disabling Local Loopback Checks on Web Servers that Run IIS

I've run into this situation more times that I can count: I set up a new web server and no matter what I do, I cannot log into websites on the server that require authentication while I am browsing to them from the console. I used to pull my hair out over this problem until I discovered the problem is in the Windows Local Security Authority (LSA) and it can be easily remedied.

  1. Open your registry editor by going to Start –> Run and enter regedit and click OK.
  2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa in the registry editor.
  3. Right-click Lsa, click on New and select DWORD value.
  4. Enter DisableLoopbackCheck and press Enter.
  5. Right-click DisableloopbackCheck and select Modify.
  6. In the Value data box, enter 1 and click OK.
  7. Reboot your server.

Several years later someone wrote the following KB article that includes this fix with a description of the problem, as well as an alternate workaround:

http://support.microsoft.com/kb/896861

HTH

Posted: Dec 16 2010, 18:09 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS | Windows
Tags: ,
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

Adding Windows Phone 7 Support to BlogEngine.NET

I love BlogEngine.NET, and I love my Windows Phone 7 mobile phone, so it goes without saying that I would want the two technologies to work together. I'm currently using BlogEngine.NET 1.6.1, but Windows Phone 7 is not supported by default. That being said, it's really easy to add support for Windows Phone 7 by modifying your BlogEngine.NET settings. To do so, open your Web.config file and locate the following section:

<appSettings>
<add key="BlogEngine.FileExtension" value=".aspx" />
<!-- You can e.g. use "~/blog/" if BlogEngine.NET is not located in the root of the application -->
<add key="BlogEngine.VirtualPath" value="~/" />
<!-- The regex used to identify mobile devices so a different theme can be shown -->
<add key="BlogEngine.MobileDevices" value="(nokia|sonyericsson|blackberry|samsung|sec\-|windows ce|motorola|mot\-|up.b|midp\-)" />
<!-- The name of the role with administrator permissions -->
<add key="BlogEngine.AdminRole" value="Administrators" />
<!--This value is to provide an alterantive location for storing data.-->
<add key="StorageLocation" value="~/App_Data/" />
<!--A comma separated list of script names to hard minify. It's case-sensitive. -->
<add key="BlogEngine.HardMinify" value="blog.js,widget.js,WebResource.axd" />
</appSettings>

The line that you need to modify is the BlogEngine.MobileDevices line, and all that you need to do is add iemobile to the list. When you finish, it should look like the following:

<add key="BlogEngine.MobileDevices"
  value="(iemobile|nokia|sonyericsson|blackberry|samsung|sec\-|windows ce|motorola|mot\-|up.b|midp\-)" />

You could also add support for Apple products by using the following syntax:

<add key="BlogEngine.MobileDevices"
  value="(iemobile|iphone|ipod|nokia|sonyericsson|blackberry|samsung|sec\-|windows ce|motorola|mot\-|up.b|midp\-)" />

That's all there is to it. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/

Posted: Dec 08 2010, 06:22 by Bob | Comments (4)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

Uh, yeah - I meant to fix that...

One of my coworkers (Mike Pope) sent me the link to a great blog post by Raymond Chen that was titled "Don't forget to replace your placeholder bitmaps with real bitmaps". Raymond's blog was a good story, but he referenced another great blog post titled "We Burned the Poop", and let's be honest - who can resist reading a blog post with a great title like that? (Note: I won't spoil the impact of that blog - you should read it first.)

But reading those two blog posts made me think back about the various code blunders that I've made over the years, which have [thankfully] never been as bad as the stories in those blog posts.

But one mistake that I made which I have never been able to live down is when I wrote the MetaEdit 2.x utility for editing the IIS metabase.

Every day I was making a huge number of changes to the MetaEdit code, and it was getting hard to keep track of everything that I needed to finish. Of course, there are several ways to track work items, and the preferred method is to keep track of everything in a bug database. But I also like to flag sections of code with comments that say things like "TODO" or "BUGBUG", that makes it easier to do a search on the code before inadvertently checking it in with something that needed to be completed.

As the deadline was rapidly approaching for me to check in the final build of MetaEdit for the Windows Server 2000 Resource Kit, I decided to add a dialog box that MetaEdit would display if you were using it with a version of IIS that was later than IIS 5.0, which we were shipping with Windows Server 2000. I wanted to make sure that MetaEdit would warn users that they might have problems using MetaEdit with a later version of IIS since I didn't know how the metabase would work in the future, or if we would deprecate the metabase like we eventually did in Windows Server 2008. I was obviously distracted for some reason and I didn't finish that section of code, but I hadn't added a comment with the text "TODO" or "BUGBUG", so I dutifully checked the code into the Resource Kit database and I didn't think anything about it.

At least I didn't think about it until we released Windows Server 2003.

If you'll recall, IIS 6.0 was shipped with Windows Server 2003, which meant that anyone who wanted to use MetaEdit in order to modify their metabase was rudely greeted with the following nonsensical and ultimately useless dialog box:

Suddenly I was receiving emails from all over the place asking me what the heck that dialog box meant. The text was supposed to have a generic warning about damaging your metabase with some sort of "use-at-your-own-risk" verbiage and a set of Yes/No buttons that would allow you to opt out of opening the application.

(Deep Sigh)

Eventually Henrik Walther wrote KB 555081 that informed users what to do, but still - I should have fixed that. Darn.

My apologies to everyone that ever saw that dialog box. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
Posted: Aug 04 2010, 09:37 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS
Tags:
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

Uh, yeah - I meant to fix that...

One of my coworkers (Mike Pope) sent me the link to a great blog post by Raymond Chen that was titled "Don't forget to replace your placeholder bitmaps with real bitmaps". Raymond's blog was a good story, but he referenced another great blog post titled "We Burned the Poop", and let's be honest - who can resist reading a blog post with a great title like that? (Note: I won't spoil the impact of that blog - you should read it first.)

But reading those two blog posts made me think back about the various code blunders that I've made over the years, which have [thankfully] never been as bad as the stories in those blog posts.

But one mistake that I made which I have never been able to live down is when I wrote the MetaEdit 2.x utility for editing the IIS metabase.

Every day I was making a huge number of changes to the MetaEdit code, and it was getting hard to keep track of everything that I needed to finish. Of course, there are several ways to track work items, and the preferred method is to keep track of everything in a bug database. But I also like to flag sections of code with comments that say things like "TODO" or "BUGBUG", that makes it easier to do a search on the code before inadvertently checking it in with something that needed to be completed.

As the deadline was rapidly approaching for me to check in the final build of MetaEdit for the Windows Server 2000 Resource Kit, I decided to add a dialog box that MetaEdit would display if you were using it with a version of IIS that was later than IIS 5.0, which we were shipping with Windows Server 2000. I wanted to make sure that MetaEdit would warn users that they might have problems using MetaEdit with a later version of IIS since I didn't know how the metabase would work in the future, or if we would deprecate the metabase like we eventually did in Windows Server 2008. I was obviously distracted for some reason and I didn't finish that section of code, but I hadn't added a comment with the text "TODO" or "BUGBUG", so I dutifully checked the code into the Resource Kit database and I didn't think anything about it.

At least I didn't think about it until we released Windows Server 2003.

If you'll recall, IIS 6.0 was shipped with Windows Server 2003, which meant that anyone who wanted to use MetaEdit in order to modify their metabase was rudely greeted with the following nonsensical and ultimately useless dialog box:

Suddenly I was receiving emails from all over the place asking me what the heck that dialog box meant. The text was supposed to have a generic warning about damaging your metabase with some sort of "use-at-your-own-risk" verbiage and a set of Yes/No buttons that would allow you to opt out of opening the application.

(Deep Sigh)

Eventually Henrik Walther wrote KB 555081 that informed users what to do, but still - I should have fixed that. Darn.

My apologies to everyone that ever saw that dialog box. ;-]

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
Posted: Aug 04 2010, 09:37 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS
Tags:
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

IIS 6.0 WebDAV and Compound Document Format Files

We recently ran into a situation where a customer thought that they were seeing file corruption when they were transferring files from a Windows 7 client to their IIS 6.0 server using WebDAV. More specifically, the file sizes were increasing for several specific file types, and for obvious reasons the checksums for these files would not match for verification. Needless to say this situation caused a great deal of alarm on the WebDAV team when we heard about it - file corruption issues are simply unacceptable.

To alleviate any fears, I should tell you right up front that no corruption was actually taking place, and the increase in file size was easily explained once we discovered what was really going on. All of that being said, I thought that a detailed explanation of the scenario would make a great blog entry in case anyone else runs into the situation.

The Customer Scenario

First of all, the customer was copying installation files using a batch file over WebDAV; more specifically the batch file was copying a collection of MSI and MST files. After the batch file copied the files to the destination server it would call the command-line comp utility to compare the files. Each MSI and MST file that was copied would increase by a small number of bytes so the comparison would fail. The customer computed checksums for the files to troubleshoot the issue and found that the checksums for the files on the source and destination did not match. Armed with this knowledge the customer contacted Microsoft for support, and eventually I got involved and I explained what the situation was.

The Architecture Explanation

Windows has a type of file format called a Compound Document, and many Windows applications make use of this file format. For example, several Microsoft Office file formats prior to Office 2007 used a compound document format to store information.

A compound document file is somewhat analogous to a file-based database, or in some situations like a mini file system that is hosted inside another file system. In the case of an MST or MSI file these are both true: MST and MSI files store information it various database-style tables with rows and columns, and they also store files for installation.

With that in mind, here's a behind-the-scenes view of WebDAV in IIS 6.0:

The WebDAV protocol extension allows you to store information in "properties", and copying files over the WebDAV redirector stores several properties about a file when it sends the file to the server. If you were to examine a protocol trace for the WebDAV traffic between a Windows 7 client and an IIS server, you will see the PUT command for the document followed by several PROPPATCH commands for the properties.

IIS needs a way to store the properties for a file in a way where they will remain associated with the file in question, so the big question is - where do you store properties?

In IIS 7 we have a simple property provider that stores the properties in a file named "properties.dav," but for IIS 5.0 and IIS 6.0 WebDAV code we chose to write the properties in the compound document file format because there are lots of APIs for doing so. Here's the way that it works in IIS 5 and IIS 6.0:

  • If the file is already in the compound document file format, IIS simply adds the WebDAV properties to the existing file. This data will not be used by the application that created the file - it will only be used by WebDAV. This is exactly what the customer was seeing - the file size was increasing because the WebDAV properties were being added to the compound document.
  • For other files, WebDAV stores a compound document in an NTFS alternate data stream that is attached to the file. You will never see this additional data from any directory listing, and the file size doesn't change because it's in an alternate data stream.

So believe it or not, no harm is done by modifying a compound document file to store the WebDAV properties. Each application that wants to pull information from a compound document file simply asks for the data that it wants, so adding additional data to a compound document file in this scenario was essentially expected behavior. I know that this may seem counter-intuitive, but it's actually by design. ;-]

The Resolution

Once I was able to explain what was actually taking place, the customer was able to verify that their MST and MSI files still worked exactly as expected. Once again, no harm was done by adding the WebDAV properties to the compound document files.

You needn't take my word for this, you can easily verify this yourself. Here's a simple test: Word 2003 documents (*.DOC not *.DOCX) are in the compound document file format. So if you were to create a Word 2003 document and then copy that document to an IIS 6.0 server over WebDAV, you'll notice that the file size increases by several bytes. That being said, if you open the document in Word, you will see no corruption - the file contains the same data that you had originally entered.

I hope this helps. ;-]

Posted: Apr 21 2010, 20:11 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS | WebDAV | IIS 6
Tags: , ,
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us

FTP 7.5 Extensibility and Visual Studio Express Editions

In earlier blog posts I have mentioned that I written the several walkthroughs to help developers get started writing providers for the FTP 7.5 service, all of which available on Microsoft's learn.iis.net Web site under the "Developing for FTP 7.5" section. In each of these walkthroughs I wrote the steps as if you were using Visual Studio 2008.

Following up on that, I received a great question yesterday from a customer, Paul Dowdle, who wondered if it was possible to write an extensibility provider for the FTP 7.5 service using one of the Visual Studio Express Editions. By way of coincidence, I used to install Visual C# Express Edition on my laptop when I was traveling around the world to speak at events like TechEd. I usually did this because the Express Edition took up less hard drive space than a full installation of Visual Studio, and I was only writing code in C# on my laptop.

To answer Paul's question, the short answer is - yes, you can use Visual Studio Express Editions to develop custom providers for the FTP 7.5 service, with perhaps a few small changes from my walkthroughs.

For example, if you look at my "How to Use Managed Code (C#) to Create a Simple FTP Authentication Provider" walkthrough, in the section that is titled "Step 1: Set up the Project Environment", there is an optional step 6 for adding a custom build event to register the DLL automatically in the Global Assembly Cache (GAC) on your development computer.

When I installed Microsoft Visual C# 2008 Express Edition on a new computer, I didn't have the "%VS90COMNTOOLS%" environment variable or the "vsvars32.bat" file, so I had to update the custom build event to the following:

net stop ftpsvc
"%ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /if "$(TargetPath)"
net start ftpsvc

Once I made that change, the rest of the walkthrough worked as written.

So, to reiterate my earlier statement - you can use Visual Studio Express Editions to develop custom providers for the FTP 7.5 service. My thanks to Paul for the great question!

Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/
Posted: Sep 17 2009, 04:19 by Bob | Comments (0)
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: IIS | FTP | Extensibility
Tags:
Social Bookmarks: E-mail | Kick it! | DZone it! | del.icio.us