System.Data.SqlClient.SqlException: CREATE DATABASE permission denied in database ‘master’.

This means that the domain account you specified to connect to the SQL Server does not have permissions to create the SharePoint config database. So go to your SQL Server and add the dbcreator role to your SharePoint Service account.

Please don’t make the SharePoint Service account elevated to domain admin level in AD or SysAdmin in SQL Server! It’s not necessary!

• Error: Startup task doesn’t exist. This is not a continuation after a restart.
• Error: This file does not exist
• Error: The tool was unable to install Hotfix for Microsoft Windows (KB976462).

I searched the Web for the errors I got and it seem that a common recommendation is to simply run prerequisiteinstaller.exe from the command-line:

• Open up a command window
• Go to your SharePoint setup location (like D:\ if running from CD drive)
• Enter “prerequisiteinstaller.exe” and then press enter
• A GUI would popup but just go ahead and proceed. It should finish installation.
• Review the log file, located in %DEFAULTUSERPROFILE%\Temp and named PrerequisiteInstaller.[datetime].log. Make sure there are no errors on the latest log file.

My MacBook Pro 13 Windows (Ultimate) Experience Index looks like the following:

Not too shabby. Lowest score is the graphics (NVidia 930M) but shouldn’t be an issue with regards to SharePoint and development work in general. See that Memory and Primary hard disk scoring 5.9? That worried me. The hard drive speed is only 5400 RPM and that could be a bottleneck for database read/writes. I went ahead and installed SharePoint 2010 on the MacBook Pro/Windows 7 anyway.

Instead of rewriting the steps needed to install SharePoint 2010 on Windows 7 for a development rig, I will point you to existing resources out there. Too many write-ups regarding this topic already. So here they are, the ones that I’ve tried and tested:

• If you are going to read anything about installing SharePoint 2010 on Windows 7, this is the resource you want – http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx
• Execute EVERY step outlined in that walkthrough. Don’t even try to shortcut or think that you can do it without reading any documentation. You may get past the installation but you will pull hair out when it’s time to configure your farm. So just do it, every step in that walkthrough! I will show some of the errors I encountered when I tried to “fast-track” the SharePoint installation.
• Here’s another good one – http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/Post.aspx?ID=112. This one talks about how to configure the scalable farm (not the Stand-Alone setup that uses SQL Express) for development purposes while using local accounts (instead of domain accounts). SharePoint 2010 needs domain accounts to configure. If you are building a “SharePoint workstation”, it’s very common to use local accounts instead of domain accounts (maybe because getting in touch with the AD admins is not easy—just create local accounts yourself). See, my MacBook Pro is not joined to a domain. I have to use non-domain accounts. I wouldn’t have been able to configure my “SharePoint farm” to use a true SQL Server 2008 if not for this walkthrough. Remember, if you do a stand-alone install, the Web apps use the SQL Express for the databases—not really  my ideal configuration!!

Here’s the first error message I encountered:

I was so excited to install SharePoint 2010 after I got my MAPS subscription that I just double-clicked the setup.exe. The above message is what I got! You have to edit the \Files\Setup\config,xml of the SharePoint 2010 install directory and add the following:

<Setting Id="AllowWindowsClientInstall" Value="True"/>

This was mentioned in Step 2: Install the Prerequisites for SharePoint 2010 of the MSDN walkthrough. Fast-forward to the end of the SharePoint 2010 installation/configuration. In Central Admin, you should see this:

Again, don’t skip any steps—follow each and every one!

In follow-up blog-posts, I’ll show the other errors I received while attempting to install/configure the SharePoint farm and how to address them.

Update 6/11/2010:  Here’s the screenshot of the Windows Task Manager of the Macbook Pro when running SharePoint 2010, SQL Server 2008, IIS Management Console, Internet Explorer, and Visual Studio 2010 (debugging/attaching to processes).

Windows 7 Task Manager in Macbook Pro

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!

I’m not sure if the crash took out IT resources (such as servers) for the IRS. I couldn’t help but think, “If the crash took out IRS servers, were they able to recover in a timely fashion”? Yeah I know it’s geeky and nerdy to be thinking about these things but I’m an IT pro—I can’t help but ponder these things!

Every IT resource—infrastructure and systems alike—should have a disaster/recovery plan. Within government agencies, they like to call this Continuity of Operations Planning or COOP. COOP is pretty comprehensive and includes not just how to recover IT but also how management succession, crisis procedures, etc. If you are part of IT and you get detailed to participate in COOP planning, most of your contributions to this COOP plan will revolve around recovering IT assets such as servers, applications, databases, and the like,

I can’t remember how many times I’ve seen network and DB administrators claim “yeah we have backups” and when disaster comes, the backups were no good and couldn’t be restored! What good is that??! What the hell is that?? See, it’s not enough that you are backing up data and applications; you must also rehearse recovery procedures using the capture back-ups so that you can confidently report to your management, “Yes, we have backups and can recover in the event of a disaster.”

In the SharePoint world, it’s not enough that you are backing up content and configuration databases—you should rehearse recovery procedures from time to time. How do you know you can recover a toasted SharePoint farm configuration if you’ve never rehearsed it and seen with your own two eyes that your backups are good? You must test your recovery procedures.

How often should you backup and test recovery procedures? Well, one can probably write a dedicated Web site just on the topic of disaster-recovery (just google it and there are tons). So, without having to discuss this too much, as a general guide I like to follow, the more critical your systems, the more backups and test-recovery procedures you should do. For less-critical apps, your frequency doesn’t have to be as extensive (the important thing is you do it). Just as an example, for critical apps—daily full back-ups with incremental back-ups during the day and test recovery procedures every 2 weeks. The “least frequent” backup schedule I’ve ever done for a “non-critical” app is bi-weekly full backups and test recoveries every 3 months.

The point is, you must backup and be ready to recover when disaster strikes. Nine years ago, the terrorists attacked WTC and the Pentagon. Last week, some lunatic had a personal grudge against the government. Who knows, maybe this week, some admin at your office spills some latte on your production server and toasts mission-critical apps. Whatever the disaster may be, be ready.

Solution Explorer in VS 2008

In order to see the manifest.xml or feature.xml file, you have to look at the “WSP View“. WSP View can be accessed by going to the menu and hitting View–>Other Windows–>WSP View. The WSP View looks like the following:

WSP View

The manifest.xml file doesn’t contain “product description” type information. The manifest.xml contains assemblies and features information. The feature.xml file, that on the other hand, start containing “description” type data. Here’s what the feature.xml contents typically look like:

<?xml version="1.0" encoding="utf-8"?>

<Feature Id="cfc5cfdd-62cf-4d98-aeba-e1b38ec6f64f"

             Title="HelloPart"

             Description="A Web part that wants to say hello to you."

             Scope="Site" Version="1.0.0.0" Hidden="FALSE"

             DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="HelloPart\HelloPart.xml" />

    <ElementFile Location="HelloPart\HelloPart.webpart" />

  </ElementManifests>

</Feature>

See that Title and Description attributes inside the Feature element? They will get displayed in the Site Features Gallery: 

WP Title and Description in the Features Gallery

What about the Web part file (in the example I’m using above, the filename is HelloPart.webpart)? What information can be customized and modified here? First, let’s take a look at the contents of the webpart file:

<?xml version="1.0" encoding="utf-8"?>

<webParts>

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">

    <metaData>

      <!--

      The following Guid is used as a reference to the web part class,

      and it will be automatically replaced with actual type name at deployment time.

      -->

      <type name="247ef4d4-489d-46d1-a628-8d8daa6267a3" />

      <importErrorMessage>Cannot import HelloPart Web Part.</importErrorMessage>

    </metaData>

    <data>

      <properties>

        <property name="Title" type="string">Gabe's Hello Web Part</property>

        <property name="Description" type="string">HelloPart is a user-friendly Web part....</property>

      </properties>

    </data>

  </webPart>

</webParts>

Inside webPart–>data–>properties section, there are property elements. The first one is the “Title” and the other is the “Description“. The values for “Title” and “Description” contained in the webpart file are what gets displayed in the Web part catalog:

WP Title and Desription in the WP Catalog

Finally, let’s take a look at the Web part XML file (in the example I used above, the filename is HelloPart.xml). The Web part XML file contains the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

    <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary" />

  </Module>

</Elements>

See how the File element doesn’t have any children? We can put a Property element as a child of the File element. This Property element will contain the “Group” the Web part appears in the catalog. By default, like the in the Web part XML file example above, the Group is not specified and therefore, the Web part gets listed under Miscellaneous Group in the Web Part catalog. If you want the Web part to appear in a group other than Miscellaneous, transform the Web part XML file from the above example to the following:

<?xml version="1.0" encoding="utf-8"?>

<Elements Id="247ef4d4-489d-46d1-a628-8d8daa6267a3" xmlns="http://schemas.microsoft.com/sharepoint/" >

  <Module Name="WebParts" List="113" Url="_catalogs/wp">

        <File Path="HelloPart.webpart" Url="HelloPart.webpart" Type="GhostableInLibrary">

              <Property Name="Group" Value="My Stuff"/>

        </File>

  </Module>

</Elements>

We added the Property element below the File element. The Name attribute of the Property element should have a value of “Group” and the Value attribute is the group name you want the Web part to appear in the catalog. In the example above, after the Web part gets deployed, the Web part appears in a category called “My Stuff“:

Web Part appearing on specified Group