Farewell to Zune? (Or not?)

I'm a little slow on this bit of news, but I just stumbled across the Goodbye from Seattle: Microsoft ending Zune device article from a month ago on GeekWire. This was really bad news for me - I own several Zune devices, so I would be extremely sad to see them go; personally I think that Zunes are great media devices that have a lot of potential. Given the existence of a large body of anti-Apple users, which has led to the creation of websites like anythingbutipod.com, there are a lot of people that don't want to settle for an iPod.

As I was lamenting the untimely demise of my favorite media player, I came across the Zune Is Not Dead article on anythingbutipod.com, which was published the day after the GeekWire article was published. The anythingbutipod.com article contained a statement from Dave McLauchlan, who is the Senior Business Development Manager for Zune, and he stated rather emphatically that the Zune is not dead.

So this leaves me a bit confused, at least for the moment; I'm not sure what to think about the future for Zune devices.

FWIW - I have two Zunes, a Zune 120 (black) and a Zune 30 (red), both of which have been great devices for me. I use my Zune 30 every day during my commute to listen to audiobooks, and I use my Zune 120 when I'm traveling in order to listen to music and watch movies.


In addition to my Zunes, my wife, my son, and my daughter all use a Zune. (I also own an HTC HD7 that is running Zune on Windows Phone 7, but that's another story.)

All that being said, the Zune never reached a critical mass, and I could easily make a wish list of features that I think would help the Zune in the long run. Here are just a couple:

  • Transferring files to and from a Zune should not require using the Zune software.
    This is an annoying limitation, and I realize that it's the same model that is used by the iPod with iTunes. But Microsoft already makes Windows Media Player, and you can use that to transfer files to/from third-party players, so I find it somewhat limiting that you have to use the Zune software.
  • The Zune should show up as a removable device in Windows Explorer like most third-party media players.
    This is somewhat related to the previous comment, but here's an example: my dad and my aunt both own media players from Creative, and it's great that their media players show up as removable devices in Windows Explorer when you plug them in. There's an old adage that says, "You can't teach an old dog new tricks," and it's great when you don't need to try. My dad is in his early 70's and my aunt is in her early 80's, so it's great that they can stick with the simple drag & drop or copy & paste functionality in Windows when they want to update the media on their players. (For that matter, I wrote a batch file that my dad uses when he adds MP3 files to his media player that automatically updates the metadata; all he has to do is run the batch file when he adds new files to his media player and everything is up-to-date. You can't do that on an iPod or a Zune.)

Anyway, that's my $.02 on the subject. I love my Zunes, and I hope that Microsoft decides to keep them around.

Credential Caching in FTP 7.0 and FTP 7.5

I've seen a few situations where people that are using the FTP 7.0 and FTP 7.5 service have noticed that it takes a while for their password changes to be reflected by the FTP service. To put this another way, here are the typical symptoms that people describe to me:

  • A user successfully logs into their FTP site using their username and password
  • The user logs out of their FTP site
  • The user changes their password
  • The user attempts to log into their FTP site using their username and their new password, but this fails
  • The user can successfully log into their FTP site using their username and their old password
  • (Note: As a corollary, restarting the FTP service fixes the symptoms)

Here's why this happens: to help improve the performance for authentication requests, the FTP service caches the credentials for successful logins. (The cache duration is set to 15 minutes by default.) This means that if you change your password, your changes may not be reflected for the cache duration.

The good news is, the FTP credential cache settings can be changed easily, and I have documented all of the settings for FTP caching in the IIS configuration reference at the following URLs:

Quoting and paraphrasing the above documentation, there are the two settings that you can configure on the <credentialsCache> element:

AttributeDescription
enabled Optional Boolean attribute.

true if credential caching is enabled; otherwise, false.

The default value is true.
flushInterval Optional uint attribute.

Specifies the cache lifetime, in seconds, for credentials that are stored in the cache.

Note: This value must be between 5 and 604,800 seconds.

The default value is 900.

What this means to you is - you can completely disable credential caching, or you can specify a different timeout. For example, on several of my development servers I often disable credential caching; this allows me to change passwords whenever I want, which is very useful when I am creating custom authentication providers. For my production servers I tend to stick with the default values, although I might change those values when I'm troubleshooting a problem.

I usually configure the settings from a command line or a batch file, although the articles that I listed earlier have steps for using the IIS Manager to change the settings for FTP credential caching. Just the same, here are some examples for setting the values by using appcmd.exe:

How to Disable FTP Credential Caching

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"False" /commit:apphost
net stop FTPSVC
net start FTPSVC

How to Specify a Custom Timeout for FTP Credential Caching

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"True" /commit:apphost
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.flushInterval:"300" /commit:apphost
net stop FTPSVC
net start FTPSVC

I hope this helps. ;-]

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

Credential Caching in FTP 7.0 and FTP 7.5

I've seen a few situations where people that are using the FTP 7.0 and FTP 7.5 service have noticed that it takes a while for their password changes to be reflected by the FTP service. To put this another way, here are the typical symptoms that people describe to me:

  • A user successfully logs into their FTP site using their username and password
  • The user logs out of their FTP site
  • The user changes their password
  • The user attempts to log into their FTP site using their username and their new password, but this fails
  • The user can successfully log into their FTP site using their username and their old password
  • (Note: As a corollary, restarting the FTP service fixes the symptoms)

Here's why this happens: to help improve the performance for authentication requests, the FTP service caches the credentials for successful logins. (The cache duration is set to 15 minutes by default.) This means that if you change your password, your changes may not be reflected for the cache duration.

The good news is, the FTP credential cache settings can be changed easily, and I have documented all of the settings for FTP caching in the IIS configuration reference at the following URLs:

Quoting and paraphrasing the above documentation, there are the two settings that you can configure on the <credentialsCache> element:

AttributeDescription
enabled Optional Boolean attribute.

true if credential caching is enabled; otherwise, false.

The default value is true.
flushInterval Optional uint attribute.

Specifies the cache lifetime, in seconds, for credentials that are stored in the cache.

Note: This value must be between 5 and 604,800 seconds.

The default value is 900.

What this means to you is - you can completely disable credential caching, or you can specify a different timeout. For example, on several of my development servers I often disable credential caching; this allows me to change passwords whenever I want, which is very useful when I am creating custom authentication providers. For my production servers I tend to stick with the default values, although I might change those values when I'm troubleshooting a problem.

I usually configure the settings from a command line or a batch file, although the articles that I listed earlier have steps for using the IIS Manager to change the settings for FTP credential caching. Just the same, here are some examples for setting the values by using appcmd.exe:

How to Disable FTP Credential Caching

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"False" /commit:apphost
net stop FTPSVC
net start FTPSVC

How to Specify a Custom Timeout for FTP Credential Caching

cd /d "%SystemRoot%\System32\Inetsrv"
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.enabled:"True" /commit:apphost
appcmd.exe set config -section:system.ftpServer/caching /credentialsCache.flushInterval:"300" /commit:apphost
net stop FTPSVC
net start FTPSVC

I hope this helps. ;-]

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

Why I Won't Buy Another HP Computer

First of all, I have to point out that I have a few friends that work for Hewlett-Packard, so I have to apologize up front for what I'm about to write in this blog. But I just had such a horrible customer support experience with HP that I won't buy from them again.

Why I Bought an HP Computer

I have nothing against HP computers; for several years I used two beefy dual-CPU HP/Compaq ProLiant servers for my web hosting machines. (I loved those computers, and I only replaced those when Windows Server 2008 was released and I thought that it was time to upgrade my servers.)

Recently I decided to replace my aging Dell desktop computer with a newer model. I'm quite partial to Dell computers, because I've always had great experiences with their computers and their company. I had a chance to buy a refurbished HP P6510F computer for a great price, so I decided to take a chance with HP since that particular computer model had a lot of great reviews.

When the computer arrived I did what I always do - I reformatted the hard drive and I installed a brand new copy of Windows from scratch. (I have to do this because all computer companies - HP, Dell, Gateway, etc. - install a bunch of useless garbage software whenever you buy one of their new computers.) The computer ran fine for several weeks, but I'm a person that likes to keep their computer up-to-date, so this past weekend I browsed to HP's website to see if there were any updates.

Upgrading the BIOS

As it turns out, there was a new version of their BIOS that was supposed to resolve issues when waking the computer from sleep mode if you have more than 4GB of memory. I only had 4GB of RAM in the computer, but I was already shopping for another 4GB, so it seemed prudent to install the BIOS update. I downloaded the update and ran their installer. After a couple of minutes a dialog box popped up saying that the update had applied successfully and I needed to reboot my computer, which I did.

That's when everything started to go wrong.

All Heck Breaks Loose

When my computer restarted it immediately hit the infamous Blue Screen of Death (BSOD); something very much like the following illustration:

A problem has been detected and Windows has been shut down to
prevent damage to your computer.

If this is the first time you've seen this Stop error screen,
restart your computer. If this screen appears again, follow
these steps:

Check for viruses on your computer. Remove any newly installed
hard drives or hard drive controllers. Check your hard drive
to make sure it is properly configured and terminated.
Run CHKDSK /F to check for hard drive corruption, and then
restart your computer.

Technical information:

*** STOP: 0x0000007B (0xFFFFF880009A9928,0xFFFFFFFFC0000034,
0x0000000000000000,0x0000000000000000)

It didn't matter how many times I tried to reboot, I still got the BSOD. I knew that BIOS updates changed some of the settings, so my natural suspicion was to assume that something in the new BIOS settings was causing the problem. I tweaked a few settings like disabling hardware virtualization and such - but there was still no joy in Mudville. After this I started to assume that perhaps the BIOS updated hadn't actually applied successfully, so I started trying to see if I could get my computer to boot from one of my several WinPE-based utility CD-ROMs and reapply the patch, but all of those also fell victim to the vicious BSOD.

I'll spare you the details of everything else that I tried - both hardware and software - but I finally gave up and decided to call HP's 24x7 technical support number.

The Technical Support Nightmare Begins

For geeks like me, having to call technical support is humiliating enough, but it's made so much worse by having to deal with front-line technical support people. Having spent 10 years in technical support myself, I have a great deal of patience with technical support engineers, but it can still be an aggravating experience. I spent the next half-hour answering mundane questions and following every instruction from HP's Tier 1 technical support script - all of which I had tried before. (At least the parts that actually applied to my situation.) I'm sure that the engineer with whom I was working meant well, but it was clear that she was floundering.

After a while she began to tell me that I didn't need the BIOS patch and that this was all my fault, to which I replied that she was correct - I didn't actually need the BIOS patch right now, but I would need it in the future, but that didn't really matter - the BIOS patch should not cause the BSOD. Besides - I always updated the BIOS in my Dell computers with no problems. (There's a good jab at HP to try yourself sometime.) Then she started to tell me that since I had a different version of Windows than HP had installed on my computer, the BIOS patch was not compatible. I asked her incredulously, "Do you mean to tell me that HP expects their customers to never install a new version of Windows?" She hesitated before replying "No," and then I reiterated my earlier assertion that no matter what, the BIOS patch should not cause the BSOD.

Then she began to tell me that I needed to purchase a system restore DVD from HP to rebuild my system. I was quick to point out that doing so would reformat my hard drive - thereby erasing all of my files - and that I was willing to bet that the problem wouldn't go away since the system restore DVD was probably not going to reset the BIOS back to an earlier version. So in my estimation I would be wasting my money and my time on a suggestion that would ultimately achieve nothing. This is where I lost her - she had no idea what I meant; so after more than an hour of basic troubleshooting with Tier 1 support and lots of time spent on hold, my patience was finally gone, and I asked to speak with someone in HP's Tier 2 support.

The Technical Support Nightmare Continues

I was transferred to a guy in Tier 2 support who discussed my predicament with me, and he seemed to have a much better handle on things. One of the first things that he did was verify that there was no reason that the BIOS update shouldn't work with my version of Windows, to which I replied that I had been trying to tell the earlier engineer the same thing. We looked at several settings, but the problem persisted, and then he suggested that I needed to purchase a system restore DVD from HP to rebuild my system. I restated my earlier claim that I would be wasting my money and my time since I was 99.9% sure that the system restore DVD would not roll back the BIOS version, so he put me on hold while he checked on that.

When he came back he informed me that the system restore DVD would not roll back the BIOS version, so I needed to return the computer to HP in order for them to reset the computer's BIOS to the original factory version. He pointed out that this would be free since the computer was under warranty, and he took my address so HP could send me a box in order to send the computer back to HP for repairs. Once all that was taken care of, we hung up.

My total time on the phone was about two hours. Ugh.

Problem Resolved

The next day I went out to lunch with my good friend, Wade Hilmo, and I related my experience to him. Once I described the symptoms he said, "I'll bet the BIOS update changed the mode for your SATA controller. Switch it from IDE to AHCI or vice-versa and the problem should go away."

Darn. I should have thought of that. ;-]

Sure enough, when I got home that night and I pulled up my BIOS settings, the SATA mode was set to RAID; I switched it to IDE and the BSOD went away. Once I knew what the problem was I found the following Microsoft Knowledge Base article that allowed me to enable AHCI:

Error message when you start a Windows 7 or Windows Vista-based computer after you change the SATA mode of the boot drive: "STOP 0x0000007B INACCESSABLE_BOOT_DEVICE"

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

My thanks to Wade for pointing that out, but Wade's follow-up comment was apropos, "I'm still a bit surprised that neither of the HP folks suggested it." So I decided that I should call HP and let them know what it took to fix the problem.

Back to Technical Support

The next day I called HP Customer Care to have them cancel my open work ticket, which was the polite thing to do since the problem was resolved. Having taken care of that, I thought that I'd give their technical support people the details of what caused the issue and how to fix it. Having worked in technical support, I always liked to know what it took to resolve an issue.

This seemed like such a good idea at the time, but it didn't turn out that way. When I called HP's Customer Care folks transferred the call to their technical support people, one of their idiots support engineers put me on hold for 20-30 minutes while he read the case notes.

Are you kidding me? It doesn't take 20-30 minutes to read the case notes, even if you're in your first year of Hooked on Phonics.

Once he took me off hold, I was pleading with him to listen to my explanation that the problem was already resolved and it was not caused by whatever stupid idea kept popping out of his wild imagination - I just wanted to share the details of how to resolve the issue if another customer calls in with the same problem, which is undoubtedly going to happen. I pointed out that I was trying to help HIM, for Pete's sake, and he just wouldn't listen. (I started hoping that HP was recording the call.)

After all that, I made it abundantly pretty clear that what he did was very unprofessional, and I asked to speak to a manager. He informed me that he'd see if a manager was available - then he put me back on hold. Fortunately I was calling from work where I have a headset for my telephone, this way I could keep working while I was on hold. (Otherwise this would have really aggravated me.)

After another 20-30 minutes I realized that this idiot engineer was not going to find a manager, he was waiting for me to hang up and go away. So I decided to put that call on hold and try to call back into technical support, but my @#$% LG-Nortel phone won't let me call a phone number if I already have that number on hold. Argh. While I was browsing HP's website to see if I could locate a different phone number for technical support I accidently hung up the original call.

Crap, crap, crap.

So I called HP again and I got another engineer - and I asked to speak to a manager right off the bat. I profusely apologized to the new engineer, and I stated emphatically that it was nothing that he did. He asked for my name and such, but I told him that I had a support ticket number and I gave him that instead. Then I started to explain what happened with the other idiot and how I resolved the issue, but this new engineer attempted to defend the earlier idiot engineer and started to change the subject. I politely cut him off and simply pointed out that the first guy took 30 minutes to read the case notes, whereas he took less than 30 seconds - even this guy had to admit that the first guy's behavior was uncalled for.

Cutting the rest of the story short, I did finally tell the new engineer what it took to fix the problem, which was simply resetting the SATA configuration back to the pre-update BIOS value. I also gave him the information about how to enable AHCI using Microsoft's KB 922976. He thanked me for the information, and after he tried unsuccessfully to upsell me on a new warranty for my computer we ended the call.

Closing Remarks

So there you have it - a thoroughly bad HP customer support experience. If either Hewlett or Packard somehow manage to read this blog, they should be ashamed on behalf of their employees. I'd give you the names of those employees, but no one that I talked to had a name that I could pronounce.

 

Of course, I never did get to speak to a manager at HP.

IIS 6: Setting up SSL - Part 3: Installing the Certificate

In part three of my series on setting up SSL on IIS 6, I'll describe the steps that are necessary to install an SSL certificate. Simply out of convenience I broke this process into two sections:


Installing Your Certificate

  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 process the request and click "Next":

  5. Click "Browse" to the locate your certificate request:

  6. Browse to the location of your certificate, highlight it, and click "Open":

  7. Verify the location of your certificate and click "Next":

  8. Choose your SSL port and click "Next":

  9. Review the information to make sure it is correct and click "Next":

  10. Click "Finish" to close the wizard:

  11. Notice that you now have all the buttons available for SSL.


Verifying Your Certificate

  1. Click the "View Certificate" button:

  2. On the "General" tab, if the certificate is good you will see a normal certificate icon. (If no, you will see a warning or error icon.)

  3. On the "Certification Path" tab you will see your certificate hierarchy:

That wraps it up for creating, submitting, obtaining, and installing a certificate. In subsequent blogs I'll post some appendices with instructions about setting up Certificate Services on Windows Server 2003.

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

IIS 6: Setting up SSL - Part 2: Submitting a Certificate Request and Obtaining a Certificate

In part two of my series on setting up SSL on IIS 6, I'll describe the steps that are necessary to obtain an SSL certificate. Typically you would submit your certificate request to any one of several Certificate Authorities (CA); and there are several that are available. Here are just a few:

The steps to obtain a certificate differ for each CA, and it would be way outside the scope of my limited blogspace to include the steps for every CA on the Internet. So for my blog series I'm going to show how to use Certificate Services on Windows Server 2003 to obtain a certificate. This part of the process is broken into three steps:


Submit the Certificate Request

  1. Browse to the "Certificate Services" website, and then click the link to "Request a Certificate":

  2. Click the link to submit an "advanced certificate request":

  3. Click the link to "Submit a certificate request by using a base-64 encoded file":

  4. Copy the text from your certificate request file and paste it into the "Base-64 Encoded Certificate Request" text box, then click "Submit":

  5. By default, Certificate Services will return a message stating that your certificate is pending. You will need to notify your Certificate Services administrator that your certificate needs to be approved.

Note: As an alternative to copying the text from your certificate request file, when you are using Certificate Services on Windows Server 2003, you can use the application to read the file for you. To do so, you would need to change the step where you copy and paste the text to the following steps:

  1. Click the link to "Browse for a file to insert":

  2. You may be prompted whether to allow an ActiveX control to run; this warning may appear because the web application uses an ActiveX control to read the certificate request file. In order to continue, you need to click "Yes":

  3. When the subform appears, click the Browse button:

  4. Locate your certificate request file, and then click "Open":

  5. Click the "Read" button to load the text from your certificate request file, this will insert it into the form:

  6. Once the text from your certificate request file has been inserted, you can submit the form as you would have done if you had copied and pasted the text manually.

Certificate Processing

At this point the Certificate Authority (CA) will consider your request. I'll post a blog later with details about processing a request using Certificate Services on Windows Server 2003.


Obtain the Certificate

When your certificate request has been processed, you need to use the following steps to save your certificate to your system before you can process it.

  1. Browse to the "Certificate Services" website, and then click the link to "View the status of a pending certificate request":

  2. Click the link for your approved request.

  3. Click the link to "Download CA certificate":

  4. When prompted, click "Save":

  5. Save the file to somewhere convenient, like your desktop:

In the next post of this blog series, I'll show you how to install your certificate on IIS 6.

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

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/

Manually Localizing FPSE 2002 for Windows Server 2008 and Windows Vista

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.

Downloading and Installing the Localized FPSE 2002 Files

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

Specifying the Language for an FPSE 2002 Website

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
See http://msdn.microsoft.com/en-us/library/0h88fahh.aspx for additional information about these languages and their related codes.

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/

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/

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/