Mark Carroll's Blog

Ugh, what a crappy bug. I have a fully licensed RTM version of MOSS 2007 running on my Virtual Server. I have been playing about with changing Master Pages quite successfully. Actually I think that is a great feature and I am longing to show it off to a client. However, when I went to the Page Settings page and tried to change the Page Layout from one to another I got this error:

After a bit of Googling, I discovered that this is a case of bad error message. To cut a long story short it comes down to a DCOM permissions bug. To fix it I had to add my MOSS app's IIS Application Pool domain account to the local BUILTIN\Administrators user group and then it all worked just fine.

So much for least privilege, although I guess I can change it back afterwards! :s

I had a weird problem a while back where the history bar for IE7 on my Windows Vista Ultimate box was not showing anything at all - not even the dates. This was not like I had cleared the history, rather it was more like it was not loading it in the first place. As you can see below, not that the menu did not even have the sort options in it:

Since a large part of the functionality both Windows Explorer and Internet Explorer comes from shell extensions that are loaded through COM classes, I took a look at the folder where the history should be stored. In my case this was at:

C:\Users\<username>\AppData\Local\Microsoft\Windows\History

Now the way Explorer (and IE7) determine which shell extensions to load is by looking in a hidden file called "desktop.ini". You may need to turn on hidden system file to be able to see it if it is not there. To do that:

1. Click the round blue Start thing in the left corner
2. Click on Computer
3. Click on the Organize button on the toolbar and chose Folder and Search Options
4. Click the View tab
5. Click Show hidden files and folders
6. If you want to see system files as well (which we do here) unclick "Hide protected operating system files (Recommended)"
7. Click OK

Now open the desktop.ini file in Notepad (usually double-clicking it will invoke Notepad) and ensure that it contains the following:

[.ShellClassInfo]
ConfirmFileOp=0
DefaultToFS=0
CLSID={FF393560-C2A7-11CF-BFF4-444553540000}
UICLSID={7BD29E00-76C1-11CF-9DD0-00A0C9034933}

If not, paste it in and save it. Now log off and on again and open IE7.

Hopefully your history is now back - it worked for me anyway. :)

Mark 

 Just found this great tip from Steven Tapping on how to suppress this annoying message that Vista Remote Desktop app always pops up:

Remote Desktop cannot verify the identity of the computer you want to connect to.

Here is the link: http://blogs.vertigo.com/personal/steventap/Blog/Lists/Posts/Post.aspx?ID=3

I just tried downloading and installing the Orcas Beta 1 Virtual PC version. It unpacks two VHDs and a couple of VMC files. While there are instructions for how to load these in Virtual PC, they do not work for Virtual Server. It seems there is some trickery involved in getting this to work on Virtual Server 2005 that I might have spent hours looking for had it not been for a very useful post by Jason Nadrowski. In his post Setting up Visual Studio Code Name "Orcas" Beta 1 Team Suite (Virtual PC version) the pertinent part that I needed was this:

What isn't described in the instructions but perhaps should is how to link this base VHD to OrcasBeta1VSTS.vhd in Virtual Server. From the Virtual Server Left Nav, go to Virtual Disks group and then select Inspect. Select the Orcas VHD in the drop down and then click the Inspect button. This page allows you to modify the parent virtual hard disk(s) and therefore specify any path for the Base01.vhd.

Thanks Jason. Very helpful. What a wonderfully obscure setting to have to find.

One interesting thing that I noticed was that the path to the base VHD was called "TimeBombedBase". Hmm... :)

I hit a weird bug today when trying to install Longhorn Server Beta 3 on a new box I just built for that purpose. I put in a Highpoint RocketRaid 2310 RAID controller set up with three 500GB SATA drives in RAID5 on an Intel D945GTP motherboard. 

I booted up the PC into the Longhorn DVD and started the installation process. As expected once I got to the drive selection screen nothing showed up. I inserted my USB Flash drive with the Highpoint RAID controller driver on it and chose Load Driver.  Then from there I navigated to the flash drive and to the drivers I copied to it. After choosing the right driver for my setup, the Longhorn setup now found my RAID drive.  However, when I clicked on Next, instead of moving to the next screen, I was greeted with a wonderful error:

Windows is unable to find a system volume that meets its criteria for installation

Nice!  Well to cut a long story short, after a bunch of fiddling around it turns out that in order to get past this to install Longhorn Server you have to go back into your BIOS, change the hard drive to be the first drive and first device in the boot order (so move it before the DVD drive and/or any LAN cards) and try running setup again. 

On the second time around, do exactly the same as the first time, insert the flash drive, load the driver and then select the newly discovered RAID drive.  This time around hitting Next will take you to the next installation screen and you should be good to go.  Weird, huh?

After this week's security updates installed themselves and kindly rebooted our server (yes we normally turn these off but this one got through), we discovered that our internal Microsoft Office SharePoint Server 2007 was no longer working.

After narrowing the problem down to Security Update for Microsoft .NET Framework 2.0 (KB928365), we determined that somewhere along the line SharePoint was not loading properly. IIS was happily serving up basic HTML pages, but when we tried to hit even the Sharepoint Central Administration page, all we got was a 404 error. The Event Log normally has some sign that something is wrong, it may not give you the detail but at least it mentions something. However, in this case there was nothing at all other than Search Crawler failures.

Just as we were starting to think we were going to have to go down the usual, install/re-install, fiddle with some settings then install again route, on a whim I decided to check the Web Service Extension settings in IIS Manager. As it happens I was rewarded with a surprisingly simple fix. It turns out that something in the 7/10/2007 security update patch process managed to disable ASP.NET v2.0.50727 – exactly the thing that MOSS needs to work. So, just the click of one button set everything right as we were back up and running again.

I love security. :-S

For anyone else that has hit this problem just go to IIS Manager:

Click on "ASP.NET v2.0.50727" in the right-hand pane, and click the Allow button. All you should see is the status changing as below.

That's it. Now go hit that Sharepoint URL again and you should be rewarded with success.

If that worked for you then I'm glad I could help. If not, I'm sorry but that's the wonderful world of security updates for you...

Recently I spent way more time that I should have diagnosing my main machine that became unbootable right after uninstalling Acronis Migrate Easy 7.0. I had bought a new hard drive and decided to try using the tool to do a clone of my old drive onto the new one. It appeared to do a fantastic job and initially I was very happy with the result. That is, until I uninstalled the Acronis software and did a reboot…

My machine became unbootable. Every time I booted the machine it got itself in a reboot loop, never getting past the first part of the loading screen. Of course I tried the obvious – hit F8, pulled up the boot menu and selected Safe Mode boot. This helped in as far as I could see each driver it was loading, but as soon as it got to crcdisk.sys it blue-screened on me and that was it.

At this point I was pretty mad but not panicking too much as I knew that the Vista DVD came with a new tool called the Windows Recovery Environment (WinRE). It is designed to automatically detect and repair a bunch of the most common boot problems without any user interaction. I have used it before on a hard drive that became unbootable and it worked wonderfully. Not this time however.

After running the tool and waiting for quite a while for it to do full disk test it failed to fix the problem. So I ran up the command prompt off the WinRE menu and did some digging of my own. The boot settings seemed to be fine – if you want to verify, use bcdedit to check and fix the new Vista boot configurations.

To cut a long story a little shorter, I finally came around to checking the file system filter drivers to see if anything was getting in the way of the file system loading up. As it turned out, this was the culprit. There was an upper filter driver that was still trying to load up that had not been properly cleaned up by the Acronis Uninstall. There was still an entry that was trying to load the driver file snapman.sys but the file was not there anymore. On boot, Windows reads the filter driver entries in the registry and looks for the corresponding driver file, if it is not there, Windows will not be able to load.

Now that we know where to look, the fix is easy:

1. Insert your Windows Vista DVD and boot up to the DVD boot menu.
2. Press OK to get past the language settings.
3. Choose Repair Computer.
4. Choose cancel if asked to run System Restore
5. At the menu, choose Command Prompt. This will put you on a command line in the WinRE.
6. Enter "regedit" without the quotes.
7. Highlight HKEY_LOCAL_MACHINE (HKLM) in the left pane.
8. Go to the File menu and choose Load Hive.
9. In the source box, navigate to the drive where Vista is installed (C: in my case). Drill down to C:\Windows\System32\Config. Choose the "System" file (with no extension). Hit OK.
10. In the next window name the hive "Broken System" without the quotes.
11. Hit the plus next to HKLM. You will see a key named " Broken System".
12. Drill down to HKLM\Broken System\ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}.
13. Look in the right pane for an Upper Filters line. If you see "snapman" without the quotes, you need to delete it. 
      
14. Only delete snapman by using the Modify on the Edit menu entry. Make sure you do not delete any other Upper Filters in the list.
    
15. You should also check HKLM\Remote System\ControlSet001\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F} for Upper Filter entries. If you see "snapman" remove it from there as well.
16. Now unload the Remote System hive. Highlight it in the left pane. Go to the File menu and choose Unload Hive. This will save the changes in the Vista registry.
17. Exit the command prompt and hit Restart
18. Keep your fingers crossed…

In my case this solved my problem and I was finally able to boot Vista without having to resort to a rebuild. Your mileage may vary… good luck!!!

After doing some Google searching, it seems it is not obvious to a lot of people how to remove the HDD password on a Toshiba laptop, specifically in my case the Toshiba M400 Tablet PC. The only option in the BIOS setup screen appears to be to reset the password with no apparent way to remove it. As it turns out the solution is incredibly simple:

1. Open the BIOS setup menu
2. Go down to the HDD password
3. Type your current HDD password and press Enter
4. Now press Enter twice at the requests for the new password and confirm new password
5. Press END and Y

That's it. Password cleared.

I spent a large part of my day today building a Windows Server 2003 virtual machine with Visual Studio 2005 set up so that I could do some MOSS 2007 development on the road. During the set up process I went through my usual steps of installing Visual Studio 2005 followed by installing the monolithic Visual Studio 2005 Service Pack 1. However this time around things did not go as expected.

Every time I ran the SP1 install it came up with the following error:

Now since the dialog box did not contain a hyperlink, I did the usual moan and groan and tried again, ignoring the link in the text. Seems this was a stupid thing to do as, for once, the error message was actually almost useful. Clicking on the link takes you to http://support.microsoft.com/kb/925336 which tells you that all you need to do is install this hot-fix KB925336 for Windows Server 2003 and all will be well.

Sure enough, installing that did indeed fix the problem. Next time I will try the link first on the off-change it sends me somewhere helpful…

I have been using the build in Validator controls that come with ASP.NET and have found them very useful. I especially like the regular expression validator as it works as a great backup when there is nothing else available. However the need came up for me to validate a couple of date text fields that I was using with the new AJAX Toolkit Calendar Control. The control is awesome for providing a quick and simple drop-down date picker with almost no extra coding. However it does not validate that the date in the text box is a valid date format. As it turns out, there is a really easy way to do this with the CompareValidator control. Here is how I did this…

1. Before adding the date picker control, you must ensure the AJAX Toolkit is registered. Add this line at the top of the page right after the @Page directive:

        <%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit"
                     TagPrefix="ajaxToolkit" %>

2. If you have not already done so anywhere else (such as your master page), you also need to add a ScriptManager to the page.

        <asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>

3. In the ASPX page add the following controls to give you a date picker with a drop-down graphic that displays the calendar control when clicked:

        <asp:Label ID="lblDate" runat="server" Text="Date: "></asp:Label>
        <asp:TextBox ID="txtDate" runat="server" Width="140px"></asp:TextBox>
        <asp:Image ID="imgCalendar" runat="server" ImageUrl="~/Images/Calendar.png" />
        <ajaxToolkit:CalendarExtender ID="CalendarExtender1" runat="server"
               TargetControlID="txtDate" Format="MM/dd/yyyy"
               PopupButtonID="imgCalendar" />

4. Now to ensure that the date entered in the text box is a valid parse-able date, simply add this one extra control to the page:

        <asp:CompareValidator ID="CompareValidator1" runat="server"
               ControlToValidate="txtDate" ErrorMessage="* Enter a valid date"
               Operator="DataTypeCheck" Type="Date" ValidationGroup="grpDate" />

Make sure you set the Operator attribute to DataTypeCheck and the Type to Date and when you click on whatever button you have on your page that triggers a postback, the validator will try to parse the date into a DateTime and display the message if that fails. Of course, you also need to ensure that your button (or whatever) has CausesValidation set to true (the default) or the Validator will not trigger.

That's it! You now have a very cool drop-down date picker with validation and all with no coding involved.