Showing posts with label shared service provider. Show all posts
Showing posts with label shared service provider. Show all posts

Saturday, April 03, 2010

SharePoint 2010 Beta Migration Gotcha – SSP Errors

One of the big changes to SharePoint 2010 is the replacement of the Shared Service Provider concept with a series of application services.

Essentially instead of a central managed “pool” or bundle of application services such as Excel, User Profile, Search, and BDC, the new model allows farm administrators to turn on or off (and separately configure) an infinite variety of services that can add extra functionality to their farm.

This is a much more flexible model.

This new model does cause one problem if you are doing “in-place” migrations of existing 2007 portals to 2010 using the beta bits. For some reason, the Shared Service Provider database does get upgraded to 2010 but it causes a number of portal errors while it does so.

You’ll find these in your upgrade log file, in the 14 hive. These vary from User Profile errors to “certificate” errors. One common error looks like this:

[OWSTIMER] [UserProfileSharedResourceProvider12Sequence] [ERROR] [1/8/2010 9:23:42 AM]: Action 14.0.1.0 of Microsoft.Office.Server.Upgrade.UserProfileSharedResourceProvider12Sequence failed.

[OWSTIMER] [UserProfileSharedResourceProvider12Sequence] [ERROR] [1/8/2010 9:23:42 AM]: Inner Exception: There are no online service instances for this application.

The “fix” is to delete all Shared Service Providers from your 2007 farm BEFORE doing the in place upgrade. The sts command to do this is:

stsadm -o deletessp -title SSP -force

This isn’t a big deal - this is only a beta problem.I very much doubt this will be the case in RTM which is due next month.

Hope that helps.

Monday, October 19, 2009

Central Administration in SharePoint 2010

Here’s a quick lap around the new Central Administration console in SharePoint 2010.

New Central Administration Layout

Central Administration

The navigation structure is broken down a little more than in 2007. There is no more “Operation” and “Application Management” divide; instead the new console is divided into the following sections:

  • Application Management: Manage site collections, web applications, content databases, and the new service applications
  • System Settings: Manage servers, features, solutions, and farm-wide settings
  • Monitoring: Track, view and report the health and status of your SharePoint farms
  • Backup and Restore: Performs backup or restores
  • Security: Manage settings for users, policy, and global security
  • Upgrade and Migration: Upgrade SharePoint, add licenses, enable Enterprise Features
  • General Application Settings: Anything that doesn’t fit into one of the other sections
  • Configuration Wizards: These are nice wizards to help setup or modify the farm

This is new layout is an advantage – the “Operations” and “Application Management” tabs in 2007 always felt a bit arbitrary and it wasn’t always clear which tasks went where.

Monitoring

This is quite useful – basically you can take the heartbeat of SharePoint and its services via reports, and view problems and solutions. Here’s a screenshot of the interface:

Central Administration - Monitoring

There are only a couple of reports right now, which tell you which pages loaded the slowest, and which users are the most active. I imagine for release there will be many more.

Central Administration - Monitoring - Health Reports

The problem and solution report is very helpful in identifying which services are failing on which servers, and why. Notice in in this report there is detailed information about one of the failing services, in this case Visio, and links to remedy it.

Central Administration - Monitoring - Problem Report

Surfacing common errors in this way will go a long way to reducing the IT administrative burden of SharePoint. I hope Microsoft is active in populating this report engine (or provides a way for the community to modify it).

Usage logging settings are in here as well.

Service Applications

Central Administration - Application ManagementThese new plug-and-play replacements for the Shared Service Provider are major wins for the new SharePoint version. They allow an organization to really customize its farm based on its needs and even usage patterns. Services that needs lots of performance and support can get it, while services that are less useful can have reduced resources or even be turned off altogether. Everybody’s SharePoint 2007 farm looked alike, but going forward it is likely that no two farms will be alike.

Of course to manage this Microsoft has to surface the available services and their settings in the Central Admin. This screenshot gives an indication of just how many services can be used.Central Administration - Manage Service Applications

Export Sites and Lists

Now you can export site and list data right from SharePoint! It’s straightforward with the new Backup and Restore section, which allows full Farm Backups and Restores along with far more granular backup. The backup can include full security including site users, as well as version history information for each item in the list.

I doubt this will replace the need for 3rd party backup software but it’s another tool for IT Admins.

Here I am backing up a Calendar from a site to file.

Central Administration - Site or List Export

The new service architecture of SharePoint is one of the most exciting things about it, and obviously required a bit of a Central Administration retooling. That provided an opportunity for some other quick wins, including a much more intuitive navigation structure and some neat monitoring tasks. More evidence that SharePoint 2010 is building on, but not replacing, the core strengths of 2007.

Saturday, January 12, 2008

Anonymously Searching User Profiles in MOSS

I had a requirement the other day to enable anonymous access on an internal portal and allow users to search across the user profile database - to create what was essentially a corporate directory.

The anonymous "core requirement" was to ensure users didn't have to log in when trying to look up their colleagues (they are using the dreaded Novell e-Directory which does not play nicely with SharePoint). Anyway this time the issue wasn't importing the e-Directory accounts but rather a 401 - Unauthorized error that kept appearing when trying to view the people results.

I tried the following things:

  • I enabled Anonymous access first on the Search Centre lists and libraries and eventually on the entire site collection
  • I added IUSR as a member of Intranet Viewers and made sure that in the policy permissions for anonymous users they had a limited read policy setup
  • I tried to add IUSR_ to the SSP Settings - "Process Accounts with access to this SSP"
  • I manually turned on anonymous access to some of the individual mysite site collections that I was trying to view
  • I modified the My Site settings in the SSP to allow IUSR to be part of the default readers group and for any existing My Sites. Then I had to go to that My Sites collection and give READ permissions directly to the IUSR account
  • I created a custom permission level called "Anonymous View" in the site collection, added View Application Pages, View Items, View Pages, and Open permissions. Then I added the anonymous view permission in the "Intranet Visitors" group to ensure they could get these extra permissions.

Nothing worked. If I tried getting results back directly from the People Search page, the 401 error would instantly appear. For some reason though I could perform a user profile search if I used the regular All Items search with the People scope. However when clicking on the results the 401 error would subsequently appear.

The conclusion: anonymously accessing user profile data does not seem to be supported out of the box. I suppose some custom code might fix this but my goal was to adhere to the vanilla SharePoint as much as possible.

This issue seems to be by design - the user profile data includes colleague information, social relevance algorithms, and organizational hierarchies. None of that information would pertain to the anonymous user account. Additionally, the actual user profile data may be considered sensitive.

Has anyone else come across this limitation, and if so how did you resolve it please?

Thursday, July 26, 2007

Another day, another SharePoint learning experience for me...This time one of my SharePoint colleagues at work, Viraf, was trying to connect to an Oracle database using the BDC. I'd had some previous success using database credentials authentication to a SQL Server-backed CRM application so he and I put our heads together to get this BDC Oracle connection working.

Because we didn't have Oracle installed anywhere initially, we began by mocking up one of the client's tables in a temporary SQL Server 2005 database and using the steps in my previous post to connect to it. Since those instructions weren't using Integrated Windows Authentication and used plain old SQL command text, we figured this would be a pretty good head start. The only major change to the BDC Schema App file was the line:

<Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>

had to change to:

<Property Name="DatabaseAccessProvider" Type="System.String">Oracle</Property>

Any table names referenced in the SQL Command text in the App schema had to be prefaced with the database schema name; ex:

SELECT Field1, Field2 FROM MySchemaName.TableName

Unfortunately although all was right with the BDC schema, there was an authentication error when trying this against the client's Oracle instance. The culprit was the Single Signon database which managed the connection.

In the SQL Server test database Viraf was using, the only fields required in the Single Signon Application Schema were User Id and Password. However, Oracle requires one more field (Field 3) to complete the Connection String: "Integrated Security".

After adding this, in the “Manage Single Signon” section, we went to “Manage Account Information for enterprise application definitions” and selected the application. We needed “\Domain Users” as the group that would authenticate using SSO (in other words, every SharePoint user would use this connection). Finally, we filled out the User Id field with the Oracle username, the Password field with the account password, and the Integrated Security field with the value "no".

Although we were able to get this running internally after Viraf set up an Oracle installation to prove this would work (it did), the deployment at the client site failed with the following error in the SharePoint log files:

System.Data.OracleClient requires Oracle client software version 8.1.7 or greater.

Viraf found the following article on Roy Tore Gurskevik's blog that seems to explain it: http://dotnetjunkies.com/WebLog/rtgurskevik/archive/2005/01/19/45958.aspx . The good news is that to reach this point a connection has to be happening and SSO reports that the connection string is being retrieved. We're awaiting official confirmation but it looks like this is an environmental issue.

Saturday, June 16, 2007

If you're crawling case-sensitive URLs in your search catalog, such as an Apache-hosted intranet, you'll run into some strange errors. In your crawl log, you might see "Content for this URL is excluded by the server because a no-index attribute.". This implies that there is a no-index or no-follow metadata tag on the content, although there probably isn't. Further, the log will indicate the URLs as being all lower-case, when they aren't...

There is a Microsoft hot fix for this (SharePoint Hotfix, April 12 2007). The KB article is at http://support.microsoft.com/kb/932619. Basically you have to call up Microsoft and ask for the download, which they will send you a link for.

Once you've installed the hotfix, go to your Shared Service provider(s)'s Search Settings. Reset all the crawled content and do a full crawl on your sources. Subsequently, the SharePoint crawler will pick up and crawl the URLs appropriately.