Monthly Archives: March 2009

Fun SharePoint SSO Fact of the Day

1 Reply

I’ve been working with SharePoint SSO and learning as I go.  One way in which this works is that you tell SharePoint about external applications.  Users log into that application via some SharePoint function (e.g. iView web part).  The first time the user performs this action, it prompts them for the correct user id and password to use for that system.  It’s setting up a mapping between your SharePoint credentials and your credentials for that backend system.  Thereafter, the user won’t have to enter their ID when they hit up that system.

That part worked well for me.  However, it begs the question, “how does the user change that user id or password?”  The user might have made a mistake, or maybe you’re doing some testing in a dev environment and need to quickly switch between accounts.

I don’t know the answer to that, but I do know that you can go into Central Administration and manage the user’s credentials:

Central Administration –> Operations –> Manage Single Sign-On –> Manage Account Information for an Enterprise Application Definition

From there, you can specify the external application (e.g. SAP) and the account you want to delete.  You can also change the mapping.

If you know how to allow end users to directly change their credentials, kindly post a comment 🙂

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Technorati Tags: , ,

Adventures With iView Web Parts

Leave a reply

I needed to do some minimal proving today that iView web parts can work in my client’s environment.  I’ve never worked with this slice of SharePoint before.

Microsoft has created a very high quality white paper on this subject.

The first obstacle I had to overcome was – where is the iView web part?  For some reason, my first thought was that I’d have to download it from a site somewhere, perhaps SAP’s site.  I had 1/2 convinced myself that iView web parts might even cost extra.  Of course, they are included with MOSS (I think Enterprise; that’s what I’m using here in any event).  I’ve seen the standard “add a web part” dialog box hundreds or more times and always glossed over it.  No more!

The next obstacle is that I can’t read instructions. 

I was using the web part and kept getting this annoying message:

No SAP servers are configured for this site.  Contact your administrator to configure trusted SAP servers.

The white paper clearly says to edit a configuration file located at file “<Drive Letter:>\Program Files\Microsoft Office Servers\12.0\Config\TrustedSAPHosts.config”.  The first dozen times I looked at that, all I saw was “Program Files\…\Config” and I went straight away to the 12 hive.  Once I finally slowed down to read it, I realized my mistake and it was easy to fix. 

I continued on my merry way with SSO configuration.  It’s not all at clear to me if that worked, but that’s another story for another day.

Bottom line:

1. iView web parts are included out of the box with SharePoint (probably Enterprise).

2. The magic configuration file, “TrustedSAPHosts.config”, does not live in the 12 hive.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

 

MOSS User Profile as the Authority for User Language Preference

4 Replies

On my current project, some of the users will travel around the world and when they arrive at different destinations, use whatever machine is handy at the time.   Those guest machines will be running Windows and installed and configured for the local locale.  (I’ve just realized that the guest machines may not have the right language packs… probably won’t, in fact… I’m parking that one for now).

SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS.  In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it. 

We’re going to investigate two approaches:

  1. HTTP Handler: A custom HTTP handler installed on IIS will look up the user’s MOSS profile, figure out the preferred language and then switch the HTTP header around as needed before passing control to MOSS.
  2. global.asax: Modify global.asax to do the same thing.  We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic. 

The other complicating factor is that we need to support 60k users, about 1,000 of which may be simultaneously accessing MOSS at peak load.

The HTTP handler seems pretty drastic, but possibly the best place to put the code since it’s at the IIS level and all-knowing.  It’s a good single point of work.

We’re leaning toward a global.asax type approach, mainly because we believe we’ll have more options for caching data at that point.

I’ll be blogging more on this subject as I learn more.

If you have know anything about this, please post a comment 🙂

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin

Capturing “mailto:” Metrics

5 Replies

I’m on a project where we need to collect metrics around a function named "Share a Story."  The idea is very simple — if you’re looking at an interesting article on the intranet and want to share it with someone, click a link labeled "Share this story" email it to your buddy.

We played around with a custom form for this purpose, but in the end, common sense won the day and we just use the familiar <a href=mailto:…> technique.  (<a href mailto:…> is a surprisingly robust little bit of HTML; as a bonus, that link brings me back to my old UNIX man pages days; those were the days!).

This technique provides a great interface for end users since they get to use their familiar MS Outlook client (or whatever email client they have installed).

It makes things harder on us poor developer types since they client *also* wants to run a report in the future that shows how often users share stories and even which stories are shared most often.

We whiteboarded a few potential solutions.  My favorite is to carbon copy (CC) a SharePoint list.  That way, the end user still gets the outlook client while we get to capture the event because we’ll get a copy of the email ourselves.  There are some obvious drawbacks.  The main problem is that the user could simply blank out or otherwise mangle the CC address.  And, we need to manage that event library of emails.  We have a scheduled job on the white board responsible for that cleanup.

If you have some clever approach to solving this problem, please do tell.

</end>

Subscribe to my blog.

Follow me on Twitter at http://www.twitter.com/pagalvin