I was trying to renew my Thawte Personal Email Certificates this week because they expire very soon. Unfortunately I was having zero luck requesting a new certificate via Thawte's certificate management website.

Whenever I reached the stage to choose a Cryptographic Service Provider, the VBScript that is supposed to fill the drop down list would fail with a generic "424 Object required" error and the process would go no further. I tried several PCs but all my machines at home and work are Vista with IE7 and Thawte's list of supported software does not list Vista or IE7.

I downloaded the Internet Explorer 6 Application Compatibility VPC image from Microsoft and was able to complete the certificate renewal then export the private key to a file and move it out of the virtual machine and install it on my workstation.

I tried IE7 on Vista 32-bit, 64-bit, non-admin, Administrator, Protected Mode On and Off, and tried adding the Thawte website to my trusted sites. None of this helped. I eventually decided to download the IE7 version of the App Compat VPC to see if Vista or IE7 is the problem.

I found that apart from a security warning, which helped me to track down the ultimate reason, the Thawte website works fine with IE7 on Windows XP. The reason is that the XEnroll.dll certificate enrolment control was replaced in Vista for a more secure CertEnroll.dll.

As usual, I'm disgusted that it has been eleven months since Vista went RTM and Thawte still haven't addressed this issue. It's even worse because the Betas and Release Candidates of Vista were around for even longer and these distributions exist so third party software and service providers can test their systems to be ready soon after launch.

I run several Vista machines each with several user accounts. Sometimes the different accounts are for different people, sometimes they are for different purposes with different permissions (ie development vs testing). Windows XP introduced a featured called "Fast User Switching" that allowed you to log into another user account without logging off the current session and Vista improves on this by allowing it in domain environments too.

But it's not enough. I want it to be faster. At the moment, in Vista, it takes far too many key presses or mouse clicks to switch to another user. This is the quickest method I've discovered so far:

Ctrl+Alt+Del, Alt+W, select account, enter password, Enter.

However, I recently discovered a much faster approach. I bought a new laptop with Vista and a built-in Vista-driver-compatible fingerprint reader. Now I've associated different fingers with different accounts and at any time I can just slide the appropriate finger over the reader and *bam*, I'm logged into another account.

Still, if anyone knows, a better keyboard shortcut would be great for the PCs without fingerprint readers.

A new HP Compaq 6710b business notebook arrived at work the other day. It was very shiny, had plenty of grunt, and was preloaded with Vista... apparently. Somehow, during the excitement, the notebook was turned on for the first time and then the lid was closed again before Windows had started. We didn't want to go through the initial setup just then, we had more important things to do.

Later, the time finally came to setup the new notebook and install and configure all the usual goodies. Unfortunately, just after the BIOS POST and before Vista started loading, we were greeted with an Vista boot loader error message: "\windows\system32\winload.exe could not be loaded because the application is missing or corrupt". All other options in Windows Boot Manager lead to the same result and no amount rebooting was going to help.

The answer to this problem, as described on the Boot Loader error screen, is to boot from the Windows installation disc. However HP like many OEMs today, do not ship any CDs with the hardware. To get the recovery disc you would normally burn them after setting up Windows for the first time (Catch-22) or order them from HP (takes about three business days).

Next idea: to be able burn the recovery discs after setting up Windows, HP must, like other brand notebooks, have the recovery images on the hard drive in a hidden partition. I downloaded the user guide from the HP website to find out how to use the recovery images on the hard drive. Option 1, run the HDD based recovery tool from the Start Menu (uh...) or Option 2, press F11 while booting to start the recovery tool without Windows. Excellent.

F11, F11, F11, F11,... doesn't work. POST screen lists others but not F11. Googling suggests that the HP boot-time recovery tool is not a BIOS feature but a boot loader on the recovery partition and the active partition is set wrong if F11 doesn't work. Ok, what is the easiest way to change the active partition on a non-booting PC?

We booted from a Windows XP install disc to use the Windows Recovery Console. XP install couldn't detect a hard drive in the notebook and refused to go any further. We created a bootable floppy with a USB floppy drive on an XP machine and copied diskpart.exe to it. Diskpart requires the full Win32 environment to work. We created a bootable Windows ME boot floppy but FDISK is unusable on drives larger than 137GB.

Lastly, we waited for the Ultimate Boot CD to download from a very slow mirror and we got Ranish Partition Manager running on the notebook. Ranish showed the notebook's hard drive correctly as a 160GB drive. It also showed that there was a single 40GB active partition formatted as NTFS and the rest of the drive was unpartitioned. Bugger.

We are now waiting for the recovery discs to arrive in the post from HP. I'm guessing that the guys at HP who setup the initial Vista image for this notebook range forgot to leave the recovery partition intact. Just goes to show though, shut down your PC properly.

If you are running Windows Vista and are bothered by "too many" UAC dialogs on a regular basis to the point that you want to turn UAC off, the problem is that you are futzing with your PC instead of doing real work.

Under just the right conditions that I have been lucky enough to meet, .NET applications deployed by ClickOnce will not start under a Terminal Services session. At the heart of the problem is this error message:

Shortcut activation from http/https or UNC sources is not allowed.

I could not find anything in Google, on the MSDN forums or in the Microsoft Support Knowledge Base. With some trial and error and a little reflection I've tracked it down to this very special combination:

• ClickOnce offline install mode is enabled
• and the application is started via the Start Menu shortcut
• and the user is logged into a Terminal Services session
• and Terminal Services is redirecting the Start Menu to a UNC.

Changing any one of these conditions is enough to avoid the problem and would probably explain why it is documented anywhere. The error message is triggered by code in the System.Deployment assembly and it it cannot be overridden by a system setting either.

Redirecting the Terminal Services Start Menu to a UNC is also a common practice when running multiple terminal servers, or a shared Start Menu for all users (as was my case).

I will be recommending users simply start the apps via the same ClickOnce deployment URL that was used for the initial install and try to disable TS folder redirection where possible.

It seems ClickOnce uses the shortcut location later in the bootstrap process and the problem exists in Orcas too so I don't think Microsoft will be fixing this one.

I've had the pleasure of chasing down some complications on a recent Small Business Server 2003 R1 deployment for a client. As is our preferred style for building new machines, we installed Windows then we ran Microsoft Update over and over, rebooting in between as necessary until every available critical and optional update had been installed.

We then proceeded to deploy our software's prerequisites to the server followed by the software itself, and lastly configure the server ready for deployment to the client's network. This last part was interesting... the SBS licensing GUI would crash when we attempted to start it. Some extensive Googling found this KB article suggesting to disable DEP for the offending program. Problem solved.

A little later the program for creating Active Directory Users was crashing exactly the same way. I couldn't find any KB articles for this program but I tried disabling DEP for the entire system and rebooted. Problem solved again. However, I wasn't happy that turning off DEP was right.

I spent an evening wandering through forums and blogs about SBS and eventually concluded that SBS SP1 was supposed to solve the problems. Of course, we had installed all the Microsoft Updates so that should already be fixed right? Sadly, no.

It turns out that because Service Pack 1 for SBS2003 apparently changes too much it doesn't get offered via Windows Update, you have to find it, download it, and install it manually. To make things worse, SP1 for SBS is supposed to be installed before SP2 for Windows Server 2003 but Microsoft Update had already installed that.

Several hours later we had uninstalled Windows Server SP2, installed the multi-file SBS SP1 update, reinstall Windows Server SP2, broken the .NET 2.0 framework, repaired that, broken SQL 2005 Reporting Services then reinstalled that, and finally reapplied SQL 2005 SP2.

Next time I think we'll have to remember to install SBS 2003 R2.

Microsoft now has a collection of Virtual PC/Virtual Server VHD images to trial a decent range of their enterprise products. They currently have Windows Vista, Visual Studio 2005 Team Suite, Windows Server 2003 R2, SQL Server 2005, Exchange 2007, and several others. These should be really useful for testing their new products without requiring a spare machine and also for testing your own software against their various platforms. Hopefully they will continue to keep their images up to date and expand on the packages available.

I recently purchased a HP dc7700 SFF PC for my home office and installed Windows Vista Business x64. I regularly use Visual Studio 2005 and SQL Server 2005 x64 on this system for bringing work home with me and for doing personal development projects. I have also been testing the Orcas Beta 1 Virtual PC image that Microsoft has made available. Based on my experiences with Windows XP 32-bit, I figured 2GB of memory would be sufficient for my new machine.

I've since discovered though that Vista x64 and SQL x64 are very memory hungry and I usually have to close several applications just to free the 1GB required by the Orcas VPC. Not being happy with the performance hit from paging, I started looking into installing more memory. Jeff Atwood had posted about the 4GB problem only a few weeks earlier and was one of the motivators for choosing a 64-bit OS and the dc7700 has the Intel Q965 Express chipset and four DDR2 slots, both of which support a maximum of 4GB. However I could not find any reliable documentation that suggested whether the BIOS in the dc7700 supported the memory remapping feature that would allow Vista x64 to utilise all the RAM.

Thankfully, I have an awesome contact in the HP reseller channel who was able get my query passed along to the right people and get confirmation on whether it would work or not. I was a little impatient and I had already ordered the new RAM before the answer came back. The new memory modules arrived today and I am pleased to say, as was promised by my HP guy, if you own a HP dc7700 like mine, you can install a full 4GB in the system and Vista x64 will happily see the whole lot. Well, it actually only reports 4031MB but I'm not going to complain about 65MB... yet.

My new home office machine has arrived and I am setting myself up for the most pain possible with my chosen configuration. Firstly I am installing Visual Studio 2005 on Vista Business Edition. Microsoft has only just released a patch for Visual Studio on Vista and it isn't perfect. Add to that running as a restricted user in Vista which introduces more problems. Finally I've chosen the 64-bit edition of Vista which complicates working with Visual Studio and software in general.

Reading the many articles and forum posts about problems with Vista and 64-bit will discourage most people from trying but so far I've found the experience to be quite pleasant. The first road-block is the need for new Vista 64-bit signed hardware drivers but Windows detected everything but the onboard sound and I was able to very easily find drivers on the HP web site for that. Two vital utilities, Daemon Tools and UltraMon, are already available with Vista x64 versions.

Vista has streamlined .zip file handling so I don't need any archiving software and the usual problems with new OS burning software are gone because Vista writes to CD and DVD out of the box. The small problem of burning disc images is solved by the free ISO Recorder, updated for Vista x64. I don't need MakeMeAdmin anymore because Vista's UAC temporary privilege elevation features have solved the problem. And, of course, Microsoft Office works beautifully.

I could rant for hours about the wonders of this new system but there were some issues. I managed to crash Visual Studio while setting the options for the first time but this is an easily avoidable documented issue (thanks Jim). I upgraded SQL Server 2005 to SP2 via Vista's built in AutoUpdate tool so I needed to run the User Provisioning Tool manually afterward to be able to connect. Also, a minor annoyance, Windows x64 has a separate Program Files folder for 32-bit and 64-bit applications and some installers were defaulting to the wrong folder.

I'm keeping a list of issues I encounter with Windows in general and developing with Visual Studio and SQL Server. I'll write about my experiences further on this blog as time passes and as I start pushing the boundaries of compatibility. At this point I have no regrets moving to Vista and 64-bit. I sure don't want to go back to either 32-bit or Windows XP and I'd recommend anyone with similar needs to my own to do the same.

At work we are currently developing a suite of applications that are expected to work on Windows XP and, I assume, eventually Windows Vista. The entire development team refreshed their workstations just after Vista went RTM and was available to MSDN subscribers. At the time Visual Studio 2005 wasn't fully supported in Vista and there were too many unknowns so an executive decision was made to stay with XP on the dev machines. I feel it was the right decision at the time.

However, there was one particular reason for staying with XP that I wasn't sure I could agree with. There was a concern that by developing under Vista we might lose touch with XP and find ourselves developing a product that has accidentally used facilities only available in Vista or that differ in Vista. The result, of course, is that we may lose compatibility with XP and discover the problem too late in development to solve it without large time, effort, or cost consequences.

I have decided to use my blog as a place of discussion for reasons why this concern is, or is not, valid. My bias is that the concern is unnecessary but I invite comments on anything I haven't considered.

Acceptance Testing

For each iteration of a product that we produce it goes to our testers to find bugs and usability issues before it can be considering for release. Our testers utilise a clean Windows XP environment inside Virtual PC to perform the suite of tests against the product. Any problems in our software that are specific to XP should be picked up here.

Visual Studio Limitations

Visual Studio 2005 was released well before Windows Vista was close to completion. As a result the IDE itself is not aware of any new features in Vista. In fact, it doesn't even fully support all the features introduced in Windows XP, one aspect that comes to mind is correct rendering of 32-bit icons. Any Vista specific features that are used will have be done so explicitly and presumably with prior consideration.

Framework 3.0

The new .NET Framework 3.0 features are included out of the box in Vista. Updates have been released for Visual Studio 2005 to provide project items and designers for the new WPF, WCF, and WWF components. However, just as we need to ensure that our XP clients need to install .NET Framework 2.0, version 3.0 is supported on XP and Server 2003, and is redistributable via the same methods as 2.0.

Features Lost

One of the primary focuses of Windows Vista has been to improve security. Many popular applications have required (or still require) an update to support Vista due to a change in the operating system's default behaviour. I believe there is a greater risk of utilising a Windows XP feature that will break under Vista because security has been tightened or the feature has been removed altogether (anyone still using WinHelp?).

Practice

With these points in mind I am in the process of building a Vista 64-bit development machine for the home office. With this configuration I intend to experience first hand what issues there are in terms of application compatibility and problems with the development process itself. Anything I find along the way that supports or disproves my beliefs above will help to decide when the development team should migrate to Vista, if at all.

If you have any experiences yourself with this situation I would appreciate your input.

Discovered recently that Windows XP has really good support for WebDAV. This command will map an unused drive letter to a folder shared via HTTP:


It's that easy. Hosting a WebDAV folder is also really easy on any machine with IIS. Just add a virtual directory, point it to your chosen local path and make sure it is browsable.

This post isn’t about .NET programming directly but it is about the tools I use when programming. I am quite fond of using batch files to execute common maintenance tasks like archiving source files or performing custom builds. However, sometimes the target folders of the actions within these batch files are located on network shares that are not mapped to a network drive. Most batch commands will happily accept UNC paths as arguments on the command line but the command prompt (cmd.exe) does not support setting the current directory to a UNC path.

I don’t like to map network drives for infrequently accesses shares and I especially don’t like mapping network drives to the hidden x$ administrative shares. A common technique is to call NET USE at the beginning of the batch to temporarily map the share until a call to NET USE /DELETE at the end of the batch cleans it up. Even better though, I found some articles on Microsoft support describing easier methods to achieve the same result.

Knowledge Base article 156276 specifies a registry key that can be changed to enable a UNC path as the current directory but this didn’t seem to work all the time for me. Article 317379 describes the more portable method of using the PUSHD and POPD directory stack commands that will automatically map an unused drive letter to the UNC path and remove it when done.

I also discovered recently that Windows XP has a built in VPN Server feature accessible from the Network Connections folder in Control Panel. Run the New Connection Wizard, select “Set up an advanced connection”, and follow the prompts. It’s scary that I am still discovering new features when I have been using Windows XP since release.

For the last few weeks I have been frustrated by Outlook 2003 on both my home and work PCs. I send and receive many files as email attachments but this has become increasingly difficult recently.

When receiving multiple attachments in a single message, I usually highlight them all, then drag them from Outlook and drop them into a folder in Explorer, but this now fails without any files appearing in the folder or any error messages popping up. However, using Outlook's Save Attachments menu item still works.

I also find it convenient to right-click a file in Explorer and select Mail Recipient from the Send To menu but when I send the message it produces an error with the text "The operation failed due to network or other communications problems". Using the Insert File menu item in Outlook works fine though.

I decided to Google the error message above but most results from the Microsoft knowledge base and various forums were related to very different problems with Outlook 2000. I tried several variations on the search keywords and eventually found some minor references on a forum to SQL Server 2005 possibly being involved.

I tried including "sql server" in my searches and I still could not find anything on Microsoft's website but I found some better results in Google Groups. Apparently, in some situations, the installation or uninstallation of SQL Server 2005 or the .NET Framework 2.0 can cause the registry entries for OLE32.DLL to become damaged.

I remembered that my problems with Outlook started at about the same time Visual Studio 2005 Professional was installed on both my home and work PCs. I decided to try to repair the registry entries for OLE32.DLL by running "regsvr32 ole32.dll" from the command line as suggested by one of the forums. I am now very pleased that Outlook is behaving as it should.

I'm not positive that Visual Studio was responsible for the OLE problem but it is quite a coincidence and maybe someone else will be able to definitively prove what caused the problem. Until then, this post should help others fix their Outlook if they experience the same symptoms and maybe Microsoft will eventually add an official article to their knowledge base.