Peter Bromberg's UnBlog

"Politicians and diapers should be changed frequently, and for the same reason." — Eça de Queirós (Portuguese writer) For a couple of months now I’ve tried to install Server 2008 R2 (which only comes in the 64-bit flavor) and Sharepoint2010 on a virtual machine so that I could conveniently study SharePoint without all the extra resources hogging my regular development box. The first thing you learn is that Windows 7 Virtual PC will not handle a 64-bit guest operating system, not even if It’s the x64 version installed on an x64 box. Drats, Microsoft! Then you learn that VMware is somewhat bloated in that it  installs a lot of extra driver-type baggage, so I gave up on that.  And, I still had issues installing Server 2008 R2 on that. Plus it’s not free, although I do know that they do have a “free” Player version, to their credit. And then you learn that “supposedly” you can trick Windows 7 x64 into accepting an installation of SharePoint 2010 – but the fixes a...

Quis custodiet ipsos custodes Who shall keep watch over the guardians? Some may  think I write about this subject ( example ) too often, but frankly, I don't think I write about it often enough: Your server (or workstation) machine is important. Having it not boot up properly or operate normally  can often mean serious loss of income. That's real hard-earned dollars that you CANNOT GET BACK.  So why is it that so many Admins don't have a reliable backup and recovery strategy? Maybe we just think "it can't happen to me". Or maybe we're just plain stubborn and dumb! The single most important ingredient of a recovery strategy is the ability to restore a known good Registry.  Registry corruption often occurs when the machine is shutting down as OS changes are being written to the Registry. It can also occur if there is a network (TCP)  glitch or a power glitch. The bottom line is this: NOBODY IS IMMUNE TO REGISTRY CORRUPTION!  NOBODY! R...

The best minds are not in government. If any were, business would hire them away. - Ronald Reagan I was working with a partner on testing his MSI Installer for various operating systems, and on Windows Server 2008 x64 it was continuing to come up with this error: Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.SqlServer.ConnectionInfo) I checked the signature of the local assembly in the installation folder against the one in the GAC, and they were identical. So, go figure, right? It turns out that the solution is very simple: Unless you've installed the 64-bit verion of SQL Server 2005, you need to install the 64-bit version of SMO. It's not there by default. If it is not installed ,you can download the 64 bit version from http://download.microsoft.com/download/4/4/D/44DBDE61-B385-4FC2-A67D-48053B8F9F...