For the umpteenth time today, my Outlook 2007 gave an error when I click on a web link:

Today’s error followed the installation of Microsoft Expression Web Studio 4. I like using Firefox as my default web browser, and it appears as if the installer messed up some setting related to the default web browser. The problem appears related to an error that I reported earlier.

As I mentioned, this is not the first time this has happened on my computer. The following fix works for me:

• Close Outlook.
• Set Internet Explorer as the default web browser. You can do this by running IE, and choosing Internet Options on the Tools menu. On the Programs tab, click Make default.
• Set Firefox as the default browser again. Do this by running Firefox, and opening the Options… on the Tools menu. On the Advanced tab, select the General sub-tab, and click Check Now [if Firefox is the default browser].

In summary: The problem appears to relate to setting a default browser other than Internet Explorer, and then installing a (Microsoft?) product that meddles with those settings. Re-setting the default browser fixes the problem for me time and again.

Keywords: Microsoft Outlook, Firefox, default browser, error, hyperlink

I administer a number of web servers, mostly CentOS and RedHat Enterprise Linux with cPanel and Web Host Manager. A while back our primary name server (a CentOS server with cPanel & WHM) gave problems when restarting the name service (Bind). The problem seemed like one of insufficient capacity. I was a bit surprised that this could be because we were serving only about 5,000 DNS zones, but nevertheless went ahead with an “upgrade”…

In my infinite wisdom, I used the /scripts/ulimitnamed script to “upgrade” the Bind name server to a version that supposedly supports a very large number of DNS zones. [ Imagine the ego trip thinking that 5,000 zones put us in the “very large” category ] The resulting Bind instance showed up in the process list as named-wrapper (used to named in originally). The new process used quite a bit more resources than the original, but because it solved the apparent capacity problem and that the box in question was primarily a name server (and some server monitoring scripts etc.), I thought the “upgrade” was a job well done.

In recent weeks I noticed a steady increase in CPU usage. This came to a boiling point when the named-wrapper process suddenly started to consume 95% plus CPU for extended periods of time. Domain lookups were slowing down, and newly added DNS zones (on other web servers in the cluster) were getting lost. At the same time (and even before when the initial problem occurred) our secondary name server was working without any problems.

Some googling (I guess I could have binged too) revealed some general unhappiness with the performance of named-wrapper. More than one users on the cPanel forum previously stated that they wanted to revert from the high-capacity version of Bind back to the “standard” version. There were some speculations how to do this, but no definitive method.

I tried to piece the puzzle together, and got lucky. Here is how I “downgraded” (quite graciously may I add) from named-wrapper to named:

1. Stopped the name service:
   service named stop
2. Replaced the named startup script (/etc/init.d/named) with the original. (I did this by copying it from the secondary name server to the primary server.)
3. Forced a reinstall of bind-libs
   yum reinstall bind-libs
4. Restarted the name service
   service named start

The above procedure solved my problem completely. CPU usage is down to almost nothing, and there are no problems starting the name service. (Why the initial apparent capacity problem occurred, I still do not know.) I hope posting it here may help someone else too.

The morals of the story:

1. Do not blindly use the utilities in the /scripts folder. Useful as many of them may be, they are generally not well documented and can be dangerous. Be sure what the use of a particular script may be before using it. (The /scripts/ulimitnamed script will reportedly be deprecated in an upcoming version of cPanel – someone else learned the same lesson it seems.)
2. Google is your friend. Search and search some more. The chances are someone else have experienced the same problem before and posted a
3. solution somewhere.

Keywords: named, named-wrapper, Bind, cPanel, cpu, ulimitnamed

Using a 64-bit version of Windows 7, I noticed that some of my programs did not display the TortoiseSVN icon overlays and lacked the SVN context menus. A bit of sleuthing revealed the (somewhat) obvious: 32-bit application require the 32-bit version of TortoiseSVN to display to integrate with TortoiseSVN.

According to the TortoiseSVN website, one can safely install both the 32-bit and 64-bit versions side-by-side. The 64-bit version will provide the necessary services to 64-bit applications (including Windows itself), and the 32-bit version will service the 32-bit application.

So, I installed the 32-bit version too. To my dismay though, the TortoiseSVN icon overlays completely disappeared. The shell integration functions (SVN Update, SVN Commit, etc.) were all there and working fine, but the icon overlays were simply missing.

Googling around confirmed that others have been experiencing problems with missing icon overlays too. There were many suggestions, generally dealing with uninstalling and rebooting, changing the status cache settings, and even deleting the icon cache itself. Nothing worked for me.

Several (too many to count) uninstall, reboot, install, and reboot sessions followed with little success. At one stage I got the icon overlays to display on the left tree panel in Windows Explorer, but on the right-side content window they remained gone. Weird.

In the end, I solved the problem uninstalling TortoiseSVN (both versions), rebooting, and then deleting all Windows Registry that made reference to “tortoise”. Reinstalling and two reboots later, all was working like a charm

I cannot remember when last I rebooting my computer this many times…

Keywords: TortoiseSVN, icon overlays, Windows 7 64-bit, shell integration

The other morning (following a massive Windows update the night before) I was greeted with an error whenever I clicked on a link in email. Outlook simply said “This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator.”

I promptly consulted my good friend Google for advice, and found a couple of relevant suggestions. The cause of the problem appeared to be related to the default browser setting in Windows (by the way, I use Firefox as my main browser) being damaged (by the Windows update?). Suggestions ranged from setting the default programs in Windows, to editing the Windows Registry. None of that worked for me though. I suspect that might have had to do with me running

Windows 7 (at the time still the Release Candidate), and the information out there relating to Windows Vista and older operating systems.

What did fix the problem was to simply run Internet Explorer and set it as the default web browser (Tools / Internet options / Programs / Make Default), and then run Firefox and set it as the default web browser (Tools / Options / Advanced / General / Check Now).

Really easy in the end!

Keywords: Outlook, Firefox, error, restrictions

In my limited dealings (to date) with WordPress, one thing quickly become abundantly clear: the formatting of posts using the built-in editor leaves a lot to be desired. The editor itself seems pretty good, but WordPress somehow messes things up. You can format your text all you want, and the next thing you see is that WordPress has removed paragraph breaks! Frustrating to say the least.

Enter Windows Live Writer…

Windows Live Writer offer a convenient way of editing your posts right from your desktop. It is not only easy to use, but it does not suffer from the mentioned annoying formatting issues.

Getting Windows Live Writer to work with WordPress is really

easy to do:

1. Log in to your WordPress admin console. Under Settings, go to Writing and enable the XML-RPC option. If you do not do this, then your WordPress installation will not accept connections from Windows Live Writer.
2. Download Windows Live Writer from the Windows Live website, install it on your computer, and add an Account for your WordPress blog on the Tools menu.

Keywords: WordPress, Windows Live Writer, XML-RPC, Settings