I'm All Twitterpated

I'm late to the party, but based on the advice of many of the folks at the SharePoint Best Practices Conference I've signed up to Twitter - and boy is it fun!

It took me a while to understand it, because it's a variety of different things rolled into one. It's a micro-blogging platform, meaning it's easy to write little posts or "tweets" in 140 characters or less. It's a subscription service like an RSS feed, where you can listen to people talking about a particular topic. It's also a great way to get support - companies often search on twitter now and respond to questions and support issues.

Case in point: I'm still researching hosted Exchange email, so yesterday I started the usual Google search to find reviews etc...but then had the happy thought of asking Twitter people about it. By asking a question and putting the keyword #exchange in it, my question appeared to anyone following that keyword. Soon suggestions and advice were flowing in.

As well, companies that host Exchange starting contacting me and making suggestions. So it's a kind of active-passive channel to get quick information from people in the know.

Then there's the fun side of it - following people in all walks of life, listening to them talk about their favourite tv shows, trips, obsessions - there's a lot of weird and wonderful stuff out there. It's a real slice of life!

Right now I'm following a variety of SharePoint folks but also people interested in things like Exchange, NHibernate, and programming best practices.

I'm also following some friends and colleagues, and even the great British actor Stephen Fry, who is one of the most popular twitterers in the world with over 100,000 followers (people who subscribe to his tweets). His latest tweets describe him whale-watching, drinking Tequila, and riding a mule up a mountain for some movie he's filming (not at the same time).

To get started, all you have to do is create a profile on twitter.com. To make it easier to twitter I am using a desktop client. This helps with searching, following people, and tracking through the long lists of tweets. The one I chose is Twhirl which is an Adobe AIR application that sits in my task pane window and alerts me the moment a new tweet comes in.

A good thing to do is check out Twitter tips and tricks on the web. ReadWriteWeb has a lot of great information on twitter usage, applications, and tips - here's a link to their twitter articles. Also Joel Oleson has some SharePoint + Twitter tips on his blog.

You can follow me on twitter at @NickKellett or at www.twitter.com/NickKellett.

Using LDAP Authentication With A SharePoint Intranet Is A Very Bad Idea

A couple of years ago I wrote an article explaining step-by-step how to integrate Novell e-Directory with SharePoint. At the time it was pretty much the only available information on the web. Since then I have frequently been asked for tips on integrating LDAP with SharePoint intranets, most recently last week. So I thought I would provide some updated advice:

Run away! Run far, far away.

1. Get one of your colleagues to distract your boss.
2. Climb out of your office window.
3. Head for the nearest bus, train station, or airport.
4. Change your name.

If somehow your boss or client finds you and demands that you integrate LDAP with the SharePoint intranet, explain why it's a very bad idea.

Why is it a Very Bad Idea?

 

From a technical perspective LDAP integration is really just Forms Based Authentication (FBA) - you are passing in a username and password to SharePoint, and these happen to be authenticated via LDAP calls to an identity store somewhere.

Using LDAP, logging into your SharePoint portal will look like this:

Doing this is a big mistake!

Reason #1: Time Spent Tinkering

Now in order to do this, there are a variety of technical steps you need to take. If you run into problems anywhere along the way, you will spend your valuable time trying to figure out if the problem is in your Role and Membership provider settings, in your various web.configs, your LDAP query, or something else you have to enable in SharePoint.

This means you are spending your effort (and your client or employer's money) struggling to implement something that with Active Directory would "just work".

Some might argue that this isn't a great reason - after all plenty of time and effort goes into modifying SharePoint to accomplish other requirements. But any effort you expend making SharePoint work without AD is time you could be spending modifying SharePoint to address problems the business actually cares about. The business does not care that its credentials are currently stored in Novell eDirectory and SharePoint prefers them in AD.

Reason #2: Your SharePoint Intranet Won't Work The Way You Expect

Portal users expect seamless integration and functionality when they are using SharePoint for the intranet, because that's what all the marketing materials teach them to expect.

Building an intranet without Active Directory can lead to some surprising and annoying side effects. Out of the box web parts or controls like the Organizational Hierarchy don't work very well without Active Directory. You can make them
work with ADAM or by exploring 3rd party replacements but you'll have to test any portal functionality you think you are likely to use.

Also, the user experience with Microsoft Office integration can become a problem. Open up Word or Excel when logged in using LDAP credentials and you might see this:

It's fun explaining that to an end user!

SharePoint Designer is also tricky - it wants to automatically authenticate you using windows credentials, and throws errors when it runs into forms based authentication.

I'm not claiming that these issues are insurmountable, but collectively they introduce new bugs, development, testing, and management issues, increase cost and risk, and potentially annoy your users. Is it really worth it?

How Is that Different from Internet or Extranet Environments?

Many extranet and internet environments use Forms Based Authentication without problems. Administrators or installers have to modify SharePoint to work in these zones using Role and Membership providers...So why is it ok for those environments to use FBA but not the Intranet?

Again, it's a question of user expectations. When a user logs on to an extranet or internet site, they don't expect seamless Office integration and automatic access to file shares using their desktop credentials. When they use SharePoint intranets, they do expect these conveniences.

All the literature and sales material tells them that they should be able to interact directly with SharePoint intranets via Outlook, Word, and Excel - without annoying popup boxes and workarounds. They expect to be able to use all of the out of the box controls and web parts like the Organizational Hierarchy, and don't want to hear excuses like "that works best with Active Directory so we can't use that now".

So What Should You Do?

I recommend synchronizing your e-Directory identity information into an Active Directory domain and building SharePoint on top of that.

There are a variety of ways to do this but one way you can investigate is via Novell's IDM which can synchronize between e-Directory and Active Directory.  Your e-Directory is still the master identity store, but any e-Directory changes get automatically sync' ed to the child Active Directory. Here's a link that might help: http://www.novell.com/coolsolutions/appnote/18349.html

You can definitely make SharePoint use multiple identity providers - but the reality is your SharePoint portal becomes much more flaky and expensive to manage. These days there are many ways to populate Active Directory from some other identity store - I always recommend that since it is less effort and risk down the road, and (probably) less cost as well.

SharePoint is complicated enough without adding to the challenges.

Of course your mileage might vary. If you have attempted (or succeeded) in integrating a SharePoint intranet with LDAP what were your experiences? Besides IDM, are there other good ways to synchronize Active Directory with a master identity store?

Above the Clouds: A Berkeley View of Cloud Computing

The Electrical Engineering and Computer Sciences department at the University of California at Berkeley just put out a research paper on Cloud Computing as they see it.

The paper is an in-depth exploration of what some consider to be just another buzzword, Cloud Computing. Since nobody has agreed on what exactly it means, the implication is that it's just a marketing term.

I remember when web services started to appear, around 2000/2001 if I recall correctly. The descriptions and possibilities seemed great, but nobody really knew what to do with them or why. So there came a time when nobody talked about web services anymore and it looked like that particular bubble had burst.

In fact, behind the scenes, a host of companies and individuals were figuring web services out, building their own, and releasing them. A couple of years after the term started popping up, web services arrived for real and now we have mashups and SaaS and Software + Services and some really well-traveled XML fragments zipping around the globe.

The same thing seems to be going on with Cloud Computing. We're in the early days, and still hearing the "Moon on a stick" promises that Cloud Computing is a silver bullet for everything.

This white paper is one of the first I've seen that really quantifies the (potential) cost savings of Cloud Computing.

Some gems:

• Explanations on Cloud Computing and how it differs from previous attempts;
• Classes of Utility Computing on page 10, comparing Google AppEngine, Amazon Web Services, and Microsoft's beta Azure platform;
• Cloud Computing economic models, on page 12;
• A discussion of the Top 10 challenges- and potential solutions to them - on page 16;
• The observation that FedExing your data is a good way to cut down on your bandwidth costs and delays.

This is very impressive work. The full paper is here:

http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf

SharePoint Best Practices - Another Great Year

We enjoyed another great year of Mindsharp's SharePoint Best Practices Conference in San Diego. Thanks to Mark Elgersma, Ben Curry, and Bill English as the chief organizers, although I know there are lots of other Mindsharp folks who worked hard to pull this off.

UPDATE: Just heard back from Ben - the primary conference organizers were Bill English, Paul Stork, Paul Schaeflein, Todd Bleeker, Steve Buchannan, Pamela James, Brian Alderman, Ben Curry, and Mark Elgersma. Thanks again guys!

Given the grim economy it was noticeable how many people showed up - over 350 attendees I believe in addition to all the vendors and organizers.

I attended with echoTechnology's Director of Sales, Sean O'Reilly. He's a real hoot - a bit of a legend on the conference circuit. We arrived on the Sunday. Since Sean and I are now using demo laptops and have the exhibit booth process nailed down after numerous conferences, it only took us about 15 minutes to setup the booth before we could unwind.

That night the BPC kicked off unofficially with a Super Bowl party in Ben Curry's suite. It was great to watch the game with various attendees and exhibitors.

Joel Oleson gave a funny keynote on Monday morning, talking about the 10 steps to success.  He argued that SharePoint is plastic and so just because you can do something with it, doesn't mean you should. Some of his analogies included Robot Barbie and headless chickens. Also there was a disapproving mother ("IT") and finger-painting baby who got paint all over the wall ("the business").

One quote he mentioned from Gartner says that by 2010 less than 35% of WSS sites will put effective governance in place!

Programming Best Practices

In between exhibit hours and meetings, I was able to attend only one seminar, given by Francis Cheung of Microsoft's Patterns and Practices Group. This was a really neat explanation of best practices for programming against SharePoint.

What was interesting was Francis showed how object oriented patterns like the Repository pattern could be used to abstract out SharePoint-specific resources like list names, loggers, and so on. Francis also pointed out the need to create strongly typed business entities for SharePoint, rather than straight calls against SP objects.

This provides an additional layer of abstraction that allows mocking and unit testing. The idea is that for code testing purposes you should be able to swap in mock interfaces without relying on SharePoint being available. For instance you should be able to run unit tests against SharePoint code without the SQL database even being available.

These entities also make it easier to work with presenters/controllers without worrying about looking up Site or List GUIDs, or provide an easy way to do CRUD operations.

Microsoft currently has a patterns and practices guidance available at www.microsoft.com/spg. From the guidance doc:

This guidance discusses the following:

• Architectural decisions about patterns, feature factoring, and packaging.
• Design tradeoffs for common decisions many developers encounter, such as when to use SharePoint lists or a database to store information.
• Implementation examples that are demonstrated in the Training Management application and in the QuickStarts.
• How to design for testability, create unit tests, and run continuous integration.
• How to set up different environments including the development, build, test, staging, and production environments.
• How to manage the application life cycle through development, test, deployment, and upgrading.
• Team-based intranet application development.

This approach is actually a standard approach to custom code development but SharePoint has tended to blur the lines a little bit. What is very interesting is that more and more of the BPC seminars were about programming and unit testing. People were even talking about Test Driven Development (TDD) against SharePoint!

What this indicates is that organizations are starting to treat SharePoint seriously as a development platform. This has always held potential but required a steep learning curve. For example, at the Best Practices Conference last year there was very little on these sorts of developer-centric practices. This year it was all about programming against SharePoint in the traditional way - using unit tests, mocking, web smoke tests, and OO patterns.

There hasn't been a killer app for SharePoint yet but it's coming.

Best Practices For Centrally Governing Your Portal and Governance

On Wednesday morning I gave a presentation on helpful tips for centrally managing a portal. I showed a governance site collection I have been working on and talked about how it can be used to make it intuitive and easy to run a portal.

I'm including my powerpoint presentation here.

There are no screenshots of the governance site collection yet although I am uploading a couple as part of this post.

 

Hope this helps!