Cannot open a TFS query in Excel

After successfully upgrading from VS2008/TFS2008 to VS2010/TFS2010 in the last few months, I today realised my machine still had an outstanding issue opening TFS queries from Visual Studio in Excel . After running the query in VS and clicking Open in Microsoft Office –> Open Query in Microsoft Excel, I was the reluctant recipient of this error message and no Excel openage:

Team Foundation Error

TF80012: The document cannot be opened because there is a problem with the installation of the Microsoft Visual Studio v10.0 Team Foundation Office integration components.  Please see the Team Foundation Installation Guide for more information.

While a number of solutions were offered, what follows is the complete set of steps I followed to fix the problem in my workstation environment (Windows Server 2008 R2 x64 with Office 2010 x86 and VS2010 RTM + TFS bits):

1. I first repaired Microsoft Visual Studio 2010 Ultimate from Control Panel. This took a while and required a restart of my workstation. All of my extensions and settings were retained (I think). On its own, this didn't fix the problem but others have reported is did for them.

2. From a command prompt running as administrator (I'm in the local administrators on my machine but that's not good enough), I re-registered the TFSOfficeAdd-in.dll. I only ran the x86 command because VS2010 is a 32-bit app and I'm running the 32-bit version of Office on Windows x64; while the same assembly exists in the 64-bit Program Files directory, I'm assuming it's for the 64-bit version of Office 2010 (just guessing):

regsvr32 "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\TFSOfficeAdd-in.dll"

3. Starting Excel from that same command window to ensure Excel started as an admin, I removed the v9.0 Team Foundation Add-In since I noticed it was showing alongside the v10.0 add-in and I wasn't sure if it was wreaking havoc. At this point, the Team menu was visible in Excel when running as admin but not when running as myself. In Excel 2010, you can manage add-ins from the File –> Options menu; click the Add-Ins tab and then choose COM Add-Ins from the Manage drop down.

4. I finally opened Excel again as myself and enabled the Team Foundation Add-In (v10.0). The Team menu now appeared in Excel.

At this point I can now open a TFS query in Excel.

Note, others have suggested deleting their Windows profile solved the problem for them, at the cost of deleting all of their settings, My Documents, etc. If you go down that path, be careful!

If you found this post helpful, please support my advertisers.

Windows Server 2003 x64 on Hyper-V Driver Issues

Installing the 64-bit version of Windows Server 2003 requires service pack 2 and installation of the Hyper-V Integration Services.

Before upgrading RTM and installing the integration services, one of guys was having a bear of a time getting the network  card to appear in the guest.

If you found this post helpful, please support my advertisers.

Centralising global TFS alerts/notifications

TFS email alerts are critical to keeping your team informed about changes in the TFS projects they care about. At the very least, most users probably want to know when they've been assigned a work item.

Although Visual Studio 2010 includes the Alerts Explorer (Team –> Alerts Explorer) for signing yourself up for alerts, there's no obvious way to do the same thing for a group of users. Adding custom business logic into the mix really means you'll need to find a better alternative.

Behold! My latest Codeplex project is live, I call it TFS Global Alerts:

http://tfsalerts.codeplex.com/

When we last faced this problem with Visual Studio Team System 2008, we landed on a solution from vertigo.com--I'd link to the original blog post but it's been removed from the site. Moving forward a few years, it was recently time to upgrade our TFS 2008 install to TFS 2010 and the question naturally arose about what we do with alerts: continue using the Vertigo web service or not?

The custom logic originally added to the Vertigo solution was flailing a bit due to the kludge of time so we decided to refactor the current solution to better meet our needs and keep everything working with TFS 2010. I've uploaded a generalised version of the end result for your alerting enjoyment as an example of handling TFS events in a web service (you may want to follow the links below for alternatives based on Windows services and event listeners).

The Solution

TFS Global Alerts is, at its core, a web service containing a single public method:

[WebMethod]
public void Notify (string eventXml)

Notify() accepts a single parameter, a string containing XML detailing the change that occurred and some information about the work item itself. The Notify() method signature changed slightly from TFS 2008: it previously included a second string parameter, tfsIdentityXml. I removed this parameter to get things wired up successfully with TFS 2010.

Most elements in the eventXml look a bit like this—note the OldValue and NewValue child elements:

<Field>
<Name>State</Name>
<ReferenceName>System.State</ReferenceName>
<OldValue>Active</OldValue>
<NewValue>Resolved</NewValue>
</Field>

With the Notify() method called and most of the data you need at hand, sending an email to the relevant parties is then quite simple. TFS Global Alerts does some additional work to exclude the person who made the change from receiving a notification about that change (presumably they know what they've just done!) and avoid sending notifications about code check-ins linked to a work item.

The only real complexity in this code is retrieving an email address for each user from Active Directory. In our production environment I found TFS listed users by display name however in development, with TFS running as a service account in the dev domain, users were returned as domain\username. In production, if a user had multiple accounts (some of our admins), their name was returned as "First Last (domain\username)".

In terms of deployment, I simply deploy the web service to the web server hosting TFS itself and TFS web access.

The notification system hangs off TFS' own event subscription tool, bissubscribe.exe (you'll find it at C:\Program Files\Microsoft Team Foundation Server 2010\Tools\bissubscribe.exe). TFS raises events for all sorts of different happenings and bissubscribe.exe allows you to subscribe an email address or SOAP web service to handle those events.

Since I had some problems creating a server-level subscription, here's the command I use to create a project collection subscription (which captures all events in our case):

bissubscribe /eventType WorkItemChangedEvent /address http://localhost:8080/{vdir_path}/Alerts/WorkItemChanged.asmx /collection http://localhost:8080/tfs/{project_collection_name}

Result:

TF50001:  Created or found an existing subscription. The subscription ID is 36

Debugging

TFS 2010 only sends alerts every two minutes by default and events subscribed to via bissubscribe.exe adhere to the same policy. This can be a bit annoying when you're developing so you may want to dial down the batch wait time. I've included a Powershell script in the solution to configure this but otherwise, check out chrisid's post on the subject.

For additional help debugging bissubscribe, Grant Holliday has some useful tips.

Finally, don't forget to actually configure your TFS server to send email!

Resources

• Creating your own event handler for the TFS Event Handler Service
• TFS Event Handler (Codeplex project)
• TFS Event Handler for Team Foundation Server 2010
• Team Foundation Server Event Service

If you found this post helpful, please support my advertisers.

miisclient.exe success output

Partly for the glory but more for posterity (my own future reference!), I've screen captured what a successful SharePoint 2010 AD user profile synchronisation looks like in the FIM client:

Will this gain me entry to a special club or something? If so, thanks Spence! Now to work through all the event log errors and warnings… perhaps I ought to call it a day!

If you found this post helpful, please support my advertisers.

Hassles installing Office 2010

Had a painful time trying to get Office 2010 Professional Plus (MSDN RTM) installed in a Windows Server 2008 R2 environment. Attempting to run a customised install including Outlook, Word, Excel and PowerPoint died repeatedly after seemingly getting two thirds of the way through:

Error 1935. An error occurred during the installation of assembly component {89EDD3A9-944B-3257-8484-D6EB6A00DDF5}. HRESULT: 0x80070BC9.

The event log wasn’t any more helpful.

In the end, installing each application one-by-one—although tedious—did the trick.

TFS 2010 Install and Western Australia Timezone Error (tf255356)

The TFS 2010 install is reportedly a walk in the park by comparison with previous versions so I thought it would be fun to give it a spin as we prepare to move from TFS 2008 to the latest and greatest.

First of all, if you’re doing a test install (or any kind of install, for that matter), the TFSInstall.chm guide included in the root of the installation media has a very well-documented process for installing both SQL Server 2008 and TFS. Unlike previous guides I’ve attempted to wade through, this one is actually quite a light read and presents just the information required to get up and running.

Apart from installing Windows Server 2008 R2 with Analysis Services and Reporting Services, I also installed SQL Server 2008 and SP1 before dropping into the TFS installer; the installer will add .NET 4, the Web Server (IIS) feature, WSS 3.0 if required, and SQL Server 2008 Express if required. I reused existing service accounts on the domain for SQL Server and TFS and created a new service account for Reporting Services. Some other bits were left to run as Network Service.

When installation completes, the configuration wizard kicks off. I went with the advanced option since I didn’t want to install SharePoint. 

The entire process was a smooth experience until I ran into an old nemesis for those of us opposed to daylight saving here in Western Australia:

tf255356 Error occurred while executing servicing step Create Warehouse for component TfsWarehouse during Install: The supplied DateTime represents an invalid time.  For example, when the clock is adjusted forward, any time in the period that is skipped is invalid.

This is interesting because the push for daylight savings was defeated a while back and the latest timezone updates were reported to be installed on my new R2 machine.

Luckily Andreww posted a work around on the connect issue: change the timezone from (UTC +8:00) Perth to (UTC +8:00) Tapei (where daylight savings is also not observed and Windows recognises the fact…). Before I could continue I had to delete both the TFS_Configuration and TFS_Warehouse databases as they were created before this problem cropped up.

All good from there… configuration completed successfully. But groan nonetheless, Microsoft!

Windows Server 2008 R2 Scratch Disk

When building out a new VM I’ve occasionally created a second disk for holding non-system files and temporary data; this disk is easy to blow away every so often and saves the hassles of defragging and compressing.

I recently built a Windows Server 2008 R2 VM and created a system drive and secondary drive in Hyper-V manager before installing the OS. During the OS installation process, I created a new partition and noticed—but thought nothing of—the fact the installer didn’t nag me about creating a reserved system partition as well.

Carrying on my merry way, I eventually found the secret system reserved partition on my “scratch” disk (d:\) when I went to format what I expected was a completely unallocated disk. Bummer—I’m not clear on the ramifications of simply deleting this reserved partition but it currently means dragging around an additional 6GB of D: drive and being unable to blow away my scratch disk.

PDF iFilter not indexing content

Don’t forget: installing and configuring an iFilter to allow SharePoint to search PDF documents won’t index graphical PDF content. In other words, if search is returning PDF results based on title or other meta data but not PDF content, double-check whether that content can be highlighted and copied to notepad as text—and watch out for scanned documents!!!

SharePoint SP2 Upgrade Fails: The B2B upgrader timer job failed

Update: Be sure to checkout the comments for additional suggestions.

Upgrading to WSS SP2 from a relatively clean, MOSS 2007 SP1 + December Cumulative Updates environment went smoothly over the weekend but upgrading my day-to-day “MOSS 2007 SP1 + a selection of hot fixes” dev environment to WSS SP2 failed at step 8 of the configuration wizard with:

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown.  Additional exception information: Failed to upgrade SharePoint Products and Technologies.

Naturally, it’s not like the configuration wizard would tell me this without forcing me into the log file; no, it assumes I’m a sweet, niaive administrator with  a penchant for colourful UIs and lollypops. Even the event log simply points to the wizard log file. God forbid it present the underlying exception in the wizard UI—I’m guessing anyone dealing with SharePoint on a daily basis isn’t going to freak out when faced with a stack trace. Anyway, into the logs and search for capital ERR and there I find the source of the failure—or at least as close as I’m going to get:

The B2B upgrader timer job failed

I tried all the usual wizard tricks to no avail:

• psconfig -cmd upgrade -inplace b2b -force (failed at step 3 with the same exception but apparently the log file is more detailed)
  
• Followed up my WSS install with the MOSS install
• Browsed through KB944267
• Restarted and stopped the administration service, the timer service, IIS
  
• Cleared the file system cache as described in KB939308 

In the end I'm a complete gimp: after backing up my VM before starting this exercise, I inadvertently fired up an older copy to which I attempted my SP2 install. Moving across to my current SP1+ VM allowed me to successfully install SP2. What gives? Service packs are cumulative so I should have also been successful with my older copy, which was pre-SP1; in fact I should be able to go RTM to SP2.

Despite being a gimp, I learned a few very important lessons today:

• Always, always, always test a service pack or updates release on a non-production, non-critical environment (and backup your content database and other bits before you start in production)
• It's fun to be first but if you're risk averse, it's probably a good idea to let others go first and blog their workarounds before diving in (there's a dearth of information about the problem I encountered as it applies to SP2 and none of the SP1 suggestions from a year ago worked in my environment)
• The SharePoint Products and Technologies Configuration Wizard doesn't log much of any value

Targeting x64 Program Files Directory with VS Setup Projects

If you’ve been working in an x64 environment for a while now this will probably be old news to you; if, like us, you’re finally moving across and you’re using Visual Studio setup projects, you may need to tweak some settings to get files going where they’re supposed to go. Especially if you’re installing to the Program Files directory.

One of our solutions employs a setup project to install a bunch of static files (primarily image, JavaScript, CSS, and Flash files) to SharePoint’s 12-hive. We use a separate installer for this because it considerably simplifies the WSS solution file and reduces .wsp/.cab build time.  I’ve just got to remember to update the version number every time we send a build off to IT for deployment ;-) I’ll also mention we point a virtual directory at this location so we could install this content anywhere.

The path to the 12-hive is said to be burned into every SharePoint developer’s brain so of course you know it resides under Program Files by default. In an x86 setup project, you can either drop files into the Program Files Folder—which is hard coded to use the special ProgramFilesFolder property (a variable containing the path to your Program Files directory) or you can configure the DefaultLocation property of the Application Folder to point to any location and use the special folder variables as tokens like this:

[ProgramFilesFolder]Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\

Why not use the Program Files Folder? The install path is built up using the properties configured at the setup project level, such as Manufacturer, and don’t offer much flexibility to install to the 12-hive—even though it does sit under /Program Files.

This all works beautifully in our x86 environment but running the same installer in an x64 environment (Windows Server 2008) resulted in our sites breaking because the installed static resources couldn’t be found. The underlying reason for this was because the Application Folder was configured as described above and the ProgramFilesFolder variable was being replaced at install time by the x86 version of the Program Files path (ie. “c:\Program Files (x86)”). This can be overridden by the administrator but that’s not very friendly. Simply changing the TargetPlatform property on the setup project from x86 to x64 won’t help.

To correct this problem, the DefaultLocation property of the Application Folder was updated from ProgramFilesFolder to ProgramFiles64Folder and the TargetPlatform property of the setup project changed to x64. If you forget to do the latter you’ll receive one of the following errors at build time:

The destination path of folder 'Application Folder' is not compatible with the project's target platform 'x86'

The destination path of folder 'Program Files (64-bit) Folder' is not compatible with the project's target platform 'x86'

 

We’re not using the Program Files (x64) Folder or the Program Files Folder folders so despite what the first images shows, I actually remove them to simplify maintenance.

My own confusion stems from the fact 64-bit Windows can run both x86 and x64 applications but they install to different locations. I think of it this way:

	x86	x64
Setup Project	[ProgramFilesFolder]	[ProgramFiles64Folder]
Windows x86	Program Files	N/A
Windows x64	Program Files (x86)	Program Files

In our case, we’re actually in the middle of a transition to x64: prod is running x86 and new prod, which is under construction, is running x64. On top of that our dev VMs are still x86. A setup project can only target a single architecture (sort of) so our solution was to simply add a second setup project. The first project remains untouched and we use it regularly at the moment; the second project targets x64 and we build it only when required (it’s only configured to build in the Release configuration). A VS solution can host multiple setup projects so there’s no problem with this arrangement.

Finally, it should be noted the Platform target of the source project that feeds content files into the setup project is configured as “Any CPU”. Since we’re not installing assemblies this doesn’t seem to matter. By was of a side note, the project containing our web parts and feature receivers is also configured to target Any CPU; MOSS obviously installs the related DLLs to the local IIS bin directories (IIS 7.0) but we’ve so far had no need to specifically configure these projects to output x64 assemblies. The beauty of .NET and the CLR at work? Dunno… but if not why are the options present?

How to Install MOSS Videos

Just noticed MS has published a series of How Do I videos on TechNet relating to MOSS installation:

• How Do I: Install Configure Microsoft Office SharePoint Server? (Part 1) (15:33)
• How Do I: Install Configure Microsoft Office SharePoint Server? (Part 2) (20:55)

With more vids here.