Be careful when hosting your web site based on DasBlog from a Windows XP machine. While IIS 6 in Windows 2003 prevents the download of files with unknown extensions by default, the IIS 5.1 in Windows XP allows downloading such files. In the case of DasBlog all *.blogtemplate files are at risk. There are a few sites out there where these files can be downloaded. Although this probably isn’t a big security risk it might be something you want to prevent. Probably the easiest way to do that is by modifying the web.config file. You should add the following line at the end of the <httpHandlers> section:

<add verb="*" path="*.snippet" type="System.Web.HttpForbiddenHandler" />

By default the Windows XP Welcome screen shows the users created through the control panel applet. Administrator is shown only if it is the only account with administrative privileges. You can change all that by setting up the correct values in the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

To change the default behavior for a user create a DWORD value with its name identical to the account name and set its value to 1 to show it or to 0 to hide it.

I really need to write down this information here so that I won’t be googling for it every time a friend or a coworker asks me about it. The default port number 3389 for RDP (Remote Desktop and Terminal Services) can be changed through the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber

Due to tightened default security in Windows 2003 the file shares cannot be accessed without logon in a domainless environment even if both shares and folders are set up to allow access to Everyone.

A bit of googling returns many different suggestions for solving the problem, none of which really seems to work for sure. I’m just adding my two cents to this confusion, hoping that this posting will help me the next I’ll be solving the same problem.

It’s all about configuring the Security options in Local Security policy. The logical path of enabling the Network Access: Let Everyone permissions apply to anonymous users policy and disabling the Network access: Restrict anonymous access to Named Pipes and Shares policy didn’t help. On the other hand enabling the Accounts: Guest account status policy and setting the Network access: Sharing and security model for local accounts policy to Guest only - local users authenticate as Guest did the trick. Don't forget to call gpupdate after changing the policy to enforce it immediately.

I’m not asserting that this is THE solution but it worked for me. However, you should be aware of the implications of enabling the guest account before doing it to solve your immediate problem.

A few additional words on the last mentioned policy change: It proves useful when the file server and the client have the same usernames defined but the passwords don’t match because it forces the client to login as guest. By default the client tries to login to the server with wrong password which once again causes the login prompt to appear. It is useful to keep the default setting when the password is the same because the auto login allows for granularity in security settings if more than equal permissions for everyone are needed.

Never forget to disable simple file sharing (Explorer menu, Tools > Folder Options..., View tab, Use simple file sharing (Recommended)) when attempting to set permissions for certificate private key file on a machine with a fresh Windows XP install, not joined to a domain. In this case the option is enabled by default which hides the Security tab in all properties dialogs and consequently disallows any explicit setting of permissions.

It is a good practice to disable the option anyway but it is easily forgotten when setting up the machine for the first time. This reminder should prevent me from losing another half an hour wondering why I can't set the desired permissions using the WSE X.509 Certificate Tool the usual way in case I am once again given a task of preparing a demo machine for an application using certificates with service accounts.

It’s almost half a year since security update 896358 has been released which prevents viewing HTML help (CHM) files from network drives. It should be noted that the file actually can be opened only the containing HTML files don’t get displayed.

Until now it wasn’t really an issue for me as I was always opening help files from local disks. But in the last few weeks I am managing help development at work and with company policy having latest files on file server shares I keep having to copy the files to my local disk before testing and reviewing them which soon gets annoying.

To avoid the repetitive tedious task of copying files around I decided to look more closely into the issue. It turned out that you can set the maximum trusted zone in the registry to avoid the problem. Since I trust the complete local network zone at work I raised the trust level by adding the following to the registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001

Problem solved.

The problem is pretty straightforward: the web site redesign causes the structure to change, thus the old addresses become invalid. Since you don’t want the users to get the dreaded error 404: Object not found, there are a couple of options available to you (if you’re using IIS – Internet Information Services, that is).

You could just change the error page to match the style of your web site and inform the visitor about the now missing page or just make the redirection to your new starting page. This is a bit unfriendly to the visitors if you kept the old content since they have to find it themselves. It would certainly be better to redirect them directly to the new address of the old content. But still it’s not a bad idea to do this. It’s an easy way to keep the users on your website even when they encounter invalid URLs by whatever reason. Just open up the Custom Errors tab of the virtual directory or web site properties and set the desired URL for the error 404. But don’t forget that you have to enter the complete path starting from the root of the site, for example: "/mydirectory/myurl.html".

If you want to make a different redirection for each page you could just keep the old pages but instead of having any actual content they would just make a redirection to the correct new address. This solution has two problems:

• It’s difficult to maintain if you have many pages.
• You’re stuck with the client side redirection, i.e. meta refresh tag.

To make the redirection server side you could use the redirect options on the Home Directory tab of the virtual directory or web site properties. But they have some serious limitations and tend not to work as expected, even more so because the documentation doesn’t explain them very well. But there’s no reason to worry, I have a better solution for you. Setup a special 404 URL on the Custom Errors tab as already suggested. But this time use an asp or aspx page for it. The supplied query string (Request.QueryString) contains the missing URL which you can parse out and use to determine the correct new address corresponding to it. For a few pages a simple select or switch clause will do but nothing prevents you from having the mappings stored externally, in a special file or a database table for example. All that’s left is to make a Response.Redirect to the new address.

There’s one more thing to take care of. If you moved your site to a new subdirectory and chose the last suggested solution, don’t forget to setup a similar simple starting page which just redirects the visitors to the new starting page. Trying to open the site without this page will namely cause an error 403: Forbidden, because a directory listing will be attempted which you have (hopefully) prevented.

Thanks go to Peter Forret for some of the ideas I used to make this work when redesigning my page.