I am relatively new to Microsoft OneNote (now part of all Microsoft Office 2010 suites) and totally new to Microsoft Office Web Apps. The Office Web Apps service was introduced by Microsoft a couple of weeks ago, and holds great promise for sharing information. Personally, I find the service extremely useful for jotting down notes and building simple spreadsheets when I am out of the office – it is great to have Office (albeit a scaled down version) available at my fingertips wherever I go). Documents are saved in the “cloud” on Microsoft’s SkyDrive, and are accessible from anywhere.

As things go with geeks, the simple stuff is seldom enough and you soon find yourself bumping your head against system boundaries. It seamed logical (and it proved reasonably simple too) to share a OneNote notebook and Excel spreadsheet with my significant other. I created the documents locally, shared them online, and she could access them through her Live ID. I admit that it took a little bit of head scratching to figure out how to share my online documents, but I eventually figured that out.

The opposite would not work though…

I could create a document (in this case a OneNote notebook) on SkyDrive with ease, but was unable to open it locally (i.e. using OnenNote on my main work computer). It was supposed to be as easy as clicking the Open in OneNote button. But doing that gave an error…

To open this notebook, your computer must be running a supported version of Microsoft OneNote and a browser that supports opening files directly from the Office Web Apps.

I tried using Internet Explorer (instead of my default Mozilla Firefox), but the error was the same. It took me a while (Google is my friend) to figure out that the problem was likely due to me running a 64-bit version of Microsoft Office. Some disconnect between Office Web Apps and Microsoft Office still seem to exist in the 64-bit environment. (A related issue exists in Office OneNote 2010 when using the Insert File option, e.g. dragging and dropping a PDF file into OneNote – it currently does not work with the 64-bit version.)

Microsoft will likely be addressing issues like this in due course. In the meantime, I found a work-around for the problem to be opening the online notebook in [my local] OneNote using its URL. Figuring out what the URL is, is not that difficult…

Looking at the notebook that resides on Office Web Apps (i.e. the online notebook that I want to open locally), the URL displayed in my web browser’s address bar is an ASPX (ASP.NET) page:

https://cid-XXXXXXXX.office.live.com/edit.aspx/NameOfOnlineNotebook

where XXXXXXXX is some unique session identifier.

Comparing with a notebook that I am sharing online (i.e. notebook I created locally and then shared online), I found more clues. Right-clicking the notebook and choosing Copy Link to Notebook revealed the following two URLs:

https://cid-XXXXXXXX.office.live.com/edit.aspx/NameOfSharedNotebook

as well as

https://YYYYY.docs.live.net/XXXXXXXX/NameOfSharedNotebook

where YYYYY is some subdomain for my SkyDrive instance.

Using the similarities and differences in the two URLs, I could deduct that the URL to the online notebook should be as follows:

https://YYYYY.docs.live.net/XXXXXXXX/NameOfOnlineNotebook

I could then simply use the Open command on the File menu, enter the URL for the File Name, and open the notebook

Keywords: Microsoft Office, OneNote, Office Web Apps, SkyDrive, 64-bit

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

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

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

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

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