This one has been stuck in my drafts pile for longer than planned. It shouldn’t still be a problem because it was addressed in the December 2010 Cumulative Update. But if you do have problems opening PDFs from SharePoint 2010, the first step should be to apply Cumulative Updates. But here’s the hack that worked before the fix was issued:

Problem: Can’t open PDF files from SharePoint 2010

Reason: Looks like Microsoft got heavy with the default security settings.

Solution:

• In the DOCICON.XML file*, edit the mapping key for PDF files to include the OpenControl parameter
  e.g. <Mapping Key=”pdf” value=”pdficon.gif” OpenControl=”" />
• In Central Administration, go to Manage Web Applications. For each web application that may contain PDF files, under General Settings, change File Handling from Strict to Permissive <- by all means read the explanation about Strict vs Permissive in the dialogue first, it does have security implications.

Note this fix only applies to new libraries. See referneces for a Powershell hack to fix existing libraries.  Otherwise PDFs in existing libraries will still have the problem, whether accessed by navigating to the library or from within search results.

* If you’re wondering what the DOCICON.XML file is, you need to configure SharePoint to recognise PDF files. See related blog post: SharePoint 2010 and Adobe PDF

References:

• SharePoint 2010 won’t open PDFs – MS Technet discussion
• Powershell script to amend existing document libraries – KM Associates, Jan 2011
• December 2010 Cumulative Update details – Microsoft, Dec 2010

Microsoft have announced the upcoming planned release of SharePoint 2010′s first service pack. Due to arrive in late June 2011.

Full details in their blog. Short version here for my memory as much anything else

• Introducing the Site Recycle Bin – self-service recovery of site collections and sites!
• Shallow Copy – improved method for managing Remote BLOB Storage – can now move site collections to new content databases without moving the underlying files (used to be uploaded and then downloaded again, waste of resources). Now the references stay intact by simply updating the pointers instead.
• The return of StorMan.aspx – reporting on site quotas (top docs, library size etc.) for site owners to manage their stuff.
• Some work on browser support for IE9 (phew, should be more stable) and Google Chrome
• Plus all the usual bug fixes and will include all Cumulative Update packs through to April 2011.

Here are a few tips and tricks to use when working with user profiles in SharePoint 2010. Note: Most also apply to SharePoint 2007.

1. Displaying all profiles in the service application

When you go to edit user profiles in the User Profile service application, you will see a blank screen with a search box to find profiles. If you enter a letter, it will list all names beginning with that letter. If you simply want to list all profiles, enter the first letter or your domain.  All user profiles begin with the domain name…

2. Adding properties to user profiles

User profiles come with a whole bunch of properties to fill out. Some are automatically mapped to your domain if you are syncing profiles with Active Diretory. You can also add your own properties. They can be set to be filled in by users or be synchronised with another data source.  You can also remove the properties you don’t need.

If you want a property to be visible on the Profile page, simply check the appropriate boxes. You can choose to display it on the user profile page, display it on the Edit Details page (so that users can fill in the property themselves) and include updates to the field in newsfeeds (see item 6).

By the way, if you edit a profile from Central Admin, don’t worry about red asterisks that suggest certain properties are mandatory. They aren’t.

3. Synchronising user profiles with Active Directory

…is a lot trickier to achieve in SharePoint 2010 than it was in SharePoint 2007.  I’ve included a bunch of links that worked for me in the handbook on this site, see: Shared Services. Follow the instructions very carefully.

4. Know how search works

People search is built-in to SharePoint. When you search for information, user profiles will be included in the results. If you are specifically searching for people, the results can be less accurate. SharePoint includes phonetic search – if you don’t know how to spell a name, spell it how it sounds and the search engine should find a match. But what SharePoint does not include is partial search. A search for ‘Dan’ won’t find ‘Daniel’. And results aren’t displayed alphabetically by default – you have to change the sort order in the search results. If you want search to behave like an address book, you have to do some work. The following post provides a walkthrough: Setting up Staff Directory Search in SharePoint 2010.

5. Creating audiences

The Audience feature has been in SharePoint for a while but doesn’t always get used much. But if you are trying to create a more social intranet, audiences are a great tool. Audiences can be used to target navigation and web parts (so that items only appear for certain groups). Audiences are created using rules that match user profile content. For example, you could create a user profile property called Newsletters with a dropdown menu to pick from. You could then create an audience for each type of newsletter. When people select the newsletter in their profile, they will be added to the audience and can receive targeted content.

Final tip on audiences: don’t forget to setup a schedule to update them, preferably inline with when user profiles are synced.

6. Enable the Activity Feed Timer Job for Newsfeeds to update

New to SharePoint 2010 is the Newsfeed feature within user profiles. The newsfeed contains all updates of interest to a user – based on changes made by their colleagues or updates that match items in the ‘Interests’ section of their profile. For example, if I register an interest in XBox 360, I’ll see updates in my newsfeed regardless of who made them (i.e. they don’t need to be in my social network).

But for newsfeeds to populate, the activity timer needs to be enabled (it’s disabled by default). The default name for the Timer Job Definition is ‘User Profile Service Application – Activity Feed Job’.

7. Extend the time out on Farm Search Settings

If you have ever seen your user profiles disappear from search, it can be caused by a timeout. The issue normally occurs on an incremental crawl. Increase the timeout from 60 to 120, then perform a full crawl. After that, everything should be working.  To increase the time out, go into the Search Application service page, and click on Farm Search Administration (it’s a few links above Content Sources).

That’s all for now. If you’re interested in more details on any of these topics, leave a comment.

This post is filed in the SharePoint 2010 handbook under: Shared Services and Social Computing.

[Update] Following comments to this post, please note that this refers to using the Enterprise Wiki template when creating a site collection. The Enterprise Wiki template is the only one that will create a root site with all features available. All other templates limit the features for the site collection and the Publishing Portal template is the worst of all.  Within a site collection, you can use any site templates you want for sub-sites.

[Update 2] You must be a Site Collection Administrator to perform these steps. Being added to the Site Owners group (Full Control permission) is not enough.  The search settings are under Site Collection Administration. If you can’t see them, you’re not a Site Collection Administrator.

—- Original Post —-

In SharePoint 2007, if you created a new site collection using the ‘Collaboration Portal’ template, it would come with a number of sites, including the Search Center. In SharePoint 2010, this is no longer the case. There isn’t a Collaboration Portal template for starters, the nearest you’ll find is the Enterprise Wiki template which is my recommended starting point for Intranets, KM and Collaborative Sites. (Side note: Another example of poor usability on Microsoft’s part. The Enterprise Wiki template is available in both the Standard and Enterprise editions of SharePoint 2010. When you read about features with ‘Enterprise’ in the title, don’t assume they are limited to the Enterprise Edition, in most cases they are also available in Standard.)

In SharePoint 2010, the clue is in the search box:

When you create a new site collection, the default search settings limit search to within the current site only and uses built-in search pages. If you want to search across multiple sites (a fairly normal requirement for most internal SharePoint deployments), use search scopes and configure different types of results pages, you will be wanting a dedicated search site. Here’s what to do:

Create a Search site

1. At the root of the site collection where you want the Search site to live, click Site Actions and select ‘New Site’
2. Select the search site template you want to use
3. Enter a title and URL (Search works for me…) and create the site

There are up to three search site templates to choose from (and you should use a search template if you don’t want to create a lot of extra work for yourself setting up search query and results pages):

• Basic Search – available with all versions of SharePoint
• Enterprise Search – requires SharePoint 2010 Server: Standard or Enterprise edition (yes, another of those ‘Enterprise’ features also available in Standard)
• FAST Search – requires SharePoint 2010 Server Enterprise Edition (or FAST add-on/dedicated)

The search query box is automatically integrated every SharePoint site within the global navigation bar (as shown in the first image above). Unless you particularly want to also have the Search site listed in navigation, go into the Navigation settings and hide it.

Configure Search Settings

Once you’ve got your search site, you can now configure the search settings to use it. This step needs to be repeated for each site collection that you want to point to the Search site.

1. At the root of the site collection, go to Site Actions – Site Settings.
2. Under Site Collection Administration, click on Search Settings
3. Within Search Settings:
   • For the Site Collection Search Center, enter the URL to your search site in the format /search/Pages (replace the word ‘search’ with the site URL for your search site, if different))
   • In Site Collection Search Scopes dropdown mode, select ‘Show search scopes’
     The image below shows the settings for my demo machine:
     
     
4. Click OK and you’re done.

Once the search settings are configured, the search box will show scopes with the default set to search across all sites instead of just the current site:

Don’t forget, you’ll need to configure search settings for each site collection that you want to point to the Search site. Whilst the URL will be relative for the site collection where the search site is located, for all other site collections you will need to enter the full path (for example, on my demo the URL is http://sp2010/search/ for all other site collections)

Enter a search query in the new search box and you will be routed to the Search site to display results:

In the image above, I’ve configured the default results page in the Search site to also include federated search results. When I enter the query ‘SharePoint’ I can see documents and items on the Intranet (along with refiners on the left to filter results), people who have SharePoint in their profile and federated results YouTube.

I’ve also modified my Search site to include 2 additional tabs – Staff Directory and Internet. The Staff Directory is discussed in a follow-up post (see links at the end of this page). The Internet tab shows more federated search results from sites such as Twitter, MSDN, TechNet and Google News. I’ve even got a page for querying Facebook but haven’t managed to federate that one yet. Federated results are great for finding relevant information inside and outside your organisation using a single query.

This post is filed in the SharePoint 2010 Handbook under Install & Configuration and Enterprise Search.

Related blog posts

• Configure Adobe PDF indexing
• SharePoint 2010 vs FAST for Search
• Staff Directory Search in SharePoint 2010

In SharePoint 2010, PerformancePoint runs as a service application. Having been configuring it recently for a demo, I stumbled across a couple of steps that needed to be completed to get the demo up and running. The environment is a single server virtual machine running Windows Server 2008 R2, SQL Server 2008 R2 Enterprise, SharePoint Server 2010 Enterprise, Office 2010 (plus Visio and Project).

Configure the unattended account

PerformancePoint now delegates security to SharePoint and connections are made using an unattended account. To configure that account:

1. Go to the Secure Store Service Application (Central Admin – Manage Service Applications)
2. Click ‘Generate New Key’ in the ribbon, then click ‘Refresh Key’ in the  same ribbon
3. Go to the PerformancePoint Service Application and then click on PerformancePoint Service Application Settings
4. The Secure Store Service Application field should be populated with the name of your Secure Store Service
5. Enter the user name that is run as the unattended service account (I created a ‘ppsadmin’ account for this purpose)

All connections between Dashboard Designer and SharePoint now use the unattended account, which means you no longer have to configure manual permissions when creating dashboards and their elements.

The account will be given the appropriate SQL Server permissions. However, if you are planning to use Excel Services for data sources, don’t forget to give this account permission to access the SharePoint sites where Excel workbooks will be published to. If you try to set up a new data source and point to the SharePoint site and document library but can’t see any workbooks, chances are the unattended account doesn’t have permissions to access the document library.

Using Excel as a data source

Whilst most proper dashboards will use cubes as their data sources (accessed via SQL Server 2008 Analysis Services), you can also create dashboards based on data stored in Excel workbooks. There are two options for Excel workbooks:

• Connect to the data source using Excel Services
• Import that data from an Excel workbook

The latter approach will literally copy the data from Excel into Dashboard Designer. I had a hiccup on my demo machine because I’ve installed 32-bit Office on a 64-bit OS. Dashboard Designer requires Excel to match the OS, 64-bit OS means 64-bit Office. (One possible workaround is to dump the data into a SharePoint list, which can also be used as a data source. I prefer to use Excel Services.)

Excel Services requires an additional step compared to previous versions of SharePoint and PerformancePoint. When you publish the Excel workbook to SharePoint, you have to specifically publish the named range (item) you plan to use as a data source:

1. The spreadsheet must be saved using the new file format – .xslx
2. Name the range that contains the data to be used in your dashboard (select the cells and ‘Define Name’ in the Formulas area of the ribbon
3. Save and send to SharePoint:
   - Click Publish Options and instead of ‘Entire Workbook’ (the default) select ‘Items in the workbook’

You’ll now be able to use the workbook as an Excel Services data source in the Dashboard Designer. Without publishing the items individually, if you try to set up a new Excel Services data source, you’ll be able to point to the SharePoint site, document library and Excel workbook but won’t see any items to select.

References

• Set up and configure PerformancePoint Service – TechNet

Related blog posts

• PerformancePoint – A brief history

This is the third blog post looking at SharePoint 2010 sizing considerations. Part 1 covered hardware and software requirements, Part 2 covered databases.

SharePoint 2010 has a very flexible architecture enabling individual components to be scaled and given dedicated resources. Microsoft has published a range of technical diagrams including one covering topologies (references at the end of this post). This post is not going to reproduce that content but will try and highlight items for consideration when deciding on your topology.

Single Server Deployment

The simplest topology – install everything onto a single server. Single server installations are only suitable for three scenarios:

• Evaluation
• Testing and development
• Small office deployments

Whilst a single server installation is fine for evaluation and testing purposes, it will only be suitable for low key small production environments. It will need at least 8Gb of RAM, preferably more for performance to be acceptable. Obviously, being a single server, it has very low fault-tolerance. If the server suffers a hardware failure, no SharePoint ’til it’s fixed.

Farm Deployment

For most production environments, some level of farm will be implemented. Even small deployments will see a performance benefit from deploying at least two servers, separating the databases from the web and application servers.

The classic scenario is the three-tier architecture – web front end(s), application server(s) and database server(s). SharePoint services enable each tier to be scaled up and out to meet specific requirements:

But this is the first check-point if you are following Microsoft guidelines. The topology diagram provided by Microsoft (see references) suggests web servers should also be used for querying in small farm deployments (3 to 5 servers). A good strategy for load balancing performance but be aware that you will require additional RAM and storage on those web servers. If your web front-ends barely make the minimum hardware spec, performance may be impacted instead of improved. In that case, a better approach would be to keep the query component on the application server and control your indexing schedule to share resources – limit the amount of indexing during working hours when query performance is more important.

Two web front-ends are always better than one for load-balancing performance (and resilience) regardless of user numbers. Beyond that, Microsoft’s rule of thumb is to have one web front-end per 10,000 users. Many small farms will start with a single application server but it does risk a single point of failure impacting availability of SharePoint.

Search is without doubt the first reason for needing to add application and database servers to your farm. The indexing process is a resource hog that impacts both the application server running the service and the database holding the search databases. Querying is also resource heavy compared to standard page rendering requests. If you are planning on deploying enterprise search covering lots of content (millions of items), consider the following:

If you can have a large enough hardware specification for your web servers to take the load, do run the query component on them for load balancing. Have a dedicated application server for the indexing service and a dedicated database server for the search databases. The additional application server also adds resilience to your farm. Should the indexing server fail, it just means no fresh updates to the query servers until the indexing server is fixed. If the other application server should fail, you could temporarily stop indexing and use the indexing server to run all other services until the failed server is recovered.

As you scale up into larger search requirements, the next layer of separation is to have dedicated query servers. This introduces a fourth tier to your farm: web server – query server – application server – database server. By the time you are this big, you may also want to introduce a third database server dedicated to content databases:

In large farm deployments, you will start to scale components to multiple servers. For example you may have two or more dedicated indexing servers (the index in SharePoint 2010 can be partitioned, enabling parallel indexing of multiple sources – a huge improvement over previous versions but watch out for network bandwidth issues…) If you are developing applications on top of SharePoint, you will probably want a dedicated application server for running the sandboxed code (smaller deployments will make do with a dedicated web application on their single application server).

There are also other topologies to consider such as extranets, public-facing web sites and hosted deployments. This post was just intended to help get you started in the right direction. One final point to consider. Summary guidelines are often based on user numbers. When it comes to your production environment, don’t forget to consider the type of activities you have planned. A small number of users managing legal documents and records will use a lot more resources than occasional web surfers. Indexing needs are determined by the volume of content (type and size as well as quantity of items) to be indexed regardless of user numbers.

If you have found this post to be useful, additional links and information can be found in the SharePoint 2010 Handbook.

References:

• Microsoft topology models – Visio, PDF, XPS
• Microsoft search topologies – Visio, PDF, XPS
• Microsoft extranet topologies – Visio, PDF, XPS

Related posts:

• SharePoint sizing pt 1 – servers (hardware and software requirements)
• SharePoint sizing pt 2 – databases