Fixing Project Portal Search

I discovered recently that searching on team project portals in SharePoint does not work out of the box.  If you try it, you'll most likely get a page with the following message:

"Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information."

If it works in your environment, fantastic!  If not, read on...

The resolution is simple really.  The basic steps can be found in the answer in the following MSDN forum thread:

http://social.msdn.microsoft.com/Forums/en-US/tfsadmin/thread/ffeaedec-7497-4c8c-8c2b-ffa185a949ee/

I verified the initial configuration in two separate test environments (TFS 2008 SP1 with WSS 3.0 SP1) and found the Windows SharePoint Services Search service disabled.  I've had reports of the same issue from environments where they upgraded from TFS 2005 with WSS 2.0.

Running through the SharePoint Products and Technologies Wizard with the default selections gets things configured so that Windows SharePoint Services Search shows up in SharePoint Central Administration | Operations | Topology and Services | Services on Server page.  From there you can start the service and configure the user accounts (I used the TFS service account making sure to include the domain).  When you go look at your content database under Applications Management | SharePoint Web Application Management | Content Databases, the dropdown next to the "Search Server" section should be enabled and contain the name of your server.  Select that and apply the changes.

Be sure to restart the Windows SharePoint Services Search service from the Services MMC snap-in after this.  I did not have to force an additional IIS reset to begin seeing search results.

Why the appropriate configuration isn't applied by the TFS install process is beyond me.  I'd be interested if someone in the know could clue me in.

jb

TF30063: You are not authorized to access...

Ever try to delete a team project and get the above message? Are you in the Team Foundation Administrators group and scratching your head? I thought TFS admins could do everything! So I finally decided to get a clear understanding of the root cause of this problem.

The resolution is simple: add your account to the site collection administrators for the SharePoint project portal (described here). You can also do this as a Farm Administrator under the Application Management section in Central Administration. Hopefully, as a TFS admin, you've been added to the Farm Administrators group in SharePoint. The nice thing about the Farm Admins group is that it supports AD groups. The site collection administrators, however, does not. From Central Administration, you can specify a primary and secondary site collection administrator. Within the settings for the project portal site, you specify additional users, but you cannot specify groups.

Why can't Farm Administrators admin site collections by default? That's just the way it is. TechNet has a great article describing how SharePoint security works. The key content is as follows:

"Members of the Farm Administrators group have no administrative access to individual sites or their content by default. However, they can take control of a specific site collection to view any content. For example, if a site collection administrator leaves the organization and a new administrator must be added, farm administrators can add themselves as site collection administrators, which action is recorded in the audit logs."

So there it is. In short, the MSDN entry on TFSDeleteProject should include a prerequisite step to make sure you have site collection administrator permissions before running the command.

jb

Tips for Setting Up TFS with SSL

I recently made it through the process of enabling SSL on a TFS instance. Every component is communicating securely now including the build agent and SharePoint Central Administration. It wasn't easy, though. The MSDN walkthrough of the process is missing some steps. If you're having trouble configuring your environment to use HTTPS, check out the following tips and lessons learned.

• If your certificates are issued used a fully-qualified domain name (FQDN), you must specify the secure URLs using the FQDNs.
  
• As you go through the process, verify the individual components of TFS are functioning correctly using HTTPS both on the several AND externally. If Reporting Services isn't working, TFS doesn't have a chance. The walkthrough gets this out of order, having you reconfigure RS after reconfiguring the team projects and TFS connections. If something went wrong, now you're pointed to an RS instance that doesn't work. Get RS configured to require SSL and test it using the Report Manager web interface. The same goes for SharePoint. Make sure you can access any existing team sites via SSL as well as create standalone sites under the TFS site collection.
  
• SharePoint will continue to redirect from secure communications to good ole vanilla HTTP unless Alternate Access Mappings have been created. These can be set up within SharePoint Central Administration. Just go to the Operations tab and click on Alternate Access Mappings under the Global Configuration section. Add internal Intranet URLs for the Default Web Site as well as the Central Administration site.

• You'll need a separate certificate for each build machine. You cannot use the same certificate used on the application tier machine. A build machine can still support multiple secure build agents with one certificate, as well.

Hopefully, these tips will help you get your TFS environment running securely. If anyone has other lessons learned from their experience with setting up TFS over HTTPS, let me know and I'll update this post.

UPDATE: The TFS global support team has posted an entry on their blog with an updated walkthrough for setting up TFS for HTTPS / SSL. It's funny knowing that my experiences at a recent client precipitated this update.

jb