Rob’s Tech Fun and Games

Well, I’ve reached 100 tweets, from various different devices, and thought I’d jot down my thoughts on the best tools on the various platforms.

First up – the iPhone!  I love the iPhone, and will shortly be upgrading to version 3.0!  Its my favorite platform for twittering generally, as I always have it with me.  I’ve tried a range of tools, but my favorite is Twitterrific, ever since their last version upgrade.  It does absolutely everything I need or want it to do, and is free, if you’re willing to put up with an occasional advert.  I also use Twitterfall, which is a pretty cheap application, and is by far the best tool for monitoring trending topics in the twitterverse.

Next – the BlackBerry.  My BlackBerry is provided by work, and until I got my iPhone was by far the best mobile device I’d come across – its still the best for corporate use and sending emails.  Here, I’ve recently been introduced to the delights of UberTwitter, which is excellent – the location plotting tools are brilliant if a little intrusive if you don’t notice them for the first few tweets!

Of course, posting tweets from the desktop is always useful!  The main Twitter site is always really useful.   The best tool for posting and monitoring tweets used to be Tweetree but I’ve found it a little unreliable of late.  Twitterfall is great on the desktop too, for monitoring trending topics.  Finally, for cordinating a group on Twitter, I’ve found Twibes to be simply great and very easy to use.

Are there other great tools on these platforms?  Absolutely!  These are just the ones that I, as a relative newbie to twitter, have found really accesible and highly useful!  I’d love to hear about others if people want to comment.

OK, before I get started here, let me clarify.  I’m predominantly a SharePoint administrator, not a developer, so these reviews are based around their use for installation and administration, as opposed to their use for a web developer!  If I think something would be useful for different roles, I’ll try and point it out, but do bear the viewpoint in mind as you read further.

With the disclaimer out of the way, lets get started with O’Reilly’s “Essential SharePoint 2007″ (You can find this at Amazon.co.uk and Amazon.com).  I’ve got mixed feelings about this book.  I used it a lot when getting started with SharePoint, and its a great reference when I go back to do something that I’m not doing frequently.  However, it lacks depth, and seems a bit unfocussed, covering areas that developers, administrators and users all need to know.  Almost the entire team I work with, both developers and admins, have a copy of the book and use it on occasion, but its not a great place to start, and not the best place to go for a detailed technical reference either.  I’d say its absolutely ideal for someone tackling SharePoint in a smaller company, where you need to have an understanding across the board, rather than specialising in a particular area.  In a larger company, its a great book if you occasionally work with SharePoint and want a solid technical reminder.

Surprisingly, one of the most useful books for me for SharePoint was  “Microsoft SharePoint 2007 for Dummies” (You can find this at Amazon.co.uk and Amazon.com).  This may be because I’m a dummy, or just my method of approaching a new technology.  I read through a simple introduction to the technology, to get a rough idea of how it works, what the components are, how they fit together, and what the terminology is.  Because I start with a simple, clear and concise book , I can pick up that information really quickly, then I can use that information to bootstrap myself up to the complex technical specifics, and actually get the most of the in depth technical references.  The “Microsoft SharePoint 2007 for Dummies” is perfect for this, providing a really solid introduction to the concepts and terminology.  I think it’d also be useful for a developer trying to understand how SharePoint fits together and is likely to be used, and very useful for a technical manager who just needs broad brushstrokes while his team does the detail work.

I wasn’t keen on the “Microsoft Office SharePoint Server 2007 Administrator’s Companion” (You can find this at Amazon.co.uk and Amazon.com).    Others may feel differently about it – many of the technical people I work with love the style in these Microsoft Press books.  I find that its too focussed on how to achieve specific goals by clicking specific buttons, rather than focussing on the particularly settings you need, and why they are needed.  Its more a philosophical difference than anything – I’m not just focussed on results, I need to know why I’m doing something.  I’ve found a solid understanding of a technology leads to much better results … and a much better ability to troubleshoot issues … than simply knowing what you need to click to achieve a particular goal.  Unfortunately, that’s the path Microsoft in general have taken with their books and courses, and increasingly seems to be the approach taken by the technical people I meet.  If thats what you want, this book is perfect.  I didn’t get on with it.  If you check the Amazon reviews, however, you’ll find most people love it.

“SharePoint 2007 The Definitive Guide” (You can find this at Amazon.co.uk and Amazon.com) was pretty good as a guide.  Some aspects are very good – its coverage of SharePoint installations and upgrades from 2003 is excellent, for example.  Its coverage of network topologies and security is also excellent.  Where this falls down, and where the Internet shines, is the fact that I’ve found you need to know how a range of technologies work together to cover many of the odder demands of a SharePoint installation.  If you publish a SharePoint site, you’ll probably want to use ISA Server 2006 to secure it, not just rely on SharePoint.  Using a SQL server on a different domain via SQL authentication isn’t uncommon for DMZ deployments.  This book is great for vanilla SharePoint installs, and is definitive for basic admin tasks, such as deploying and configuring basic sites, roles and permissions.  You’ll need to look elsewhere for any installs beyond the vanilla.  I rarely go back to this book, but I’d thoroughly recommend reading through it at least once, and using it as a reference if you’re actively looking after SharePoint sites, as opposed to looking after the architecture.  If you need to get to grips at level of the stsadm command line, you won’t find it here.

As a follow up query to the previous notes on working with the PeoplePicker and ADAM, I’ve been asked about the behaviour of the PeoplePicker – specifically, that it appears to only return external users if their username is specifically searched for, not if part of their name is entered.  Is there a way to get exactly the same results for users from AD and ADAM?  Unfortunately, there are pretty severe limits to this, and unfortunately, I don’t believe you can actually get the same results, though I’d love to be proven wrong.

By default, when dealing with custom authentication sources, including ADAM, the PeoplePicker only returns exact matches.  If I search for the username, it will find it.  If its a user already on the site collection, it can use the local user details.  However, to find non exact matches in a custom repository, you need to edit the WebConfig file, by adding the following section:

<PeoplePickerWildcards>
  <clear />
  <add key=”ADAMMembership” value=”*” />
</PeoplePickerWildcards>

Unfortunately, this solution isn’t perfect.  It effectively adds the wildcard symbol * to every search in the people picker.  Lets illustrate this step by step, using a Pat Smith as an example name.

If I search for “Pat”, before updating the web.config file, they’ll only appear with the full name in the results if they’ve already been added to the site somewhere, or if they’re actually in the Active Directory repository.

If I search for “Pat” after updating the web.config file, all the Pats from the ADAM repository and from AD will appear.   Problem solved?  No.

If I search for Smith, as a surname, I’ll get all the Smiths from AD, but not from ADAM.   Thats because the search going to ADAM is actually like “Smith*”.  It’ll find everything starting with Smith, not all names containing Smith, and I haven’t come across any variations that will actually resolve this search issue.  However, you’ll probably find that this is a significant step forward in any event.

As always with SharePoint, make sure you edit all of the relevant web.config files.  You may find SharePoint is happier if you run

iisreset -noforce

after making the change, although in theory you shouldn’t need to - as a rule of thumb, major changes to web applications within SharePoint can have odd consequences otherwise.

In a stroke of rare genius, applying SharePoint SP2 to SharePoint 2007 has a strange effect – it resets the license type to become a 180 day trial version!

Its not a major issue – reapplying your license key in the “Convert License Type” section in Central Administration will reset it, and you won’t have lost any data in the meantime, but its something you need to be aware of…. otherwise you might hit more than a few issues in about 6 months!

One of the comments on my PeoplePicker post asked some questions about the way PeoplePicker works with ECTS – the External Collaboration Toolkit for SharePoint.  To be honest, I haven’t worked with the ECTS myself, but I understand the theory.

The ECTS uses Microsoft’s ADAM – Active Directory Application Mode – to act a a user repository, which gives you a SharePoint structure that should resemble the following:

External Collaboration Toolkit for SharePoint Architecture

Getting the PeoplePicker to work correctly with this is difficult, but not impossible.  The question asked was what could cause the PeoplePicker to fail to return AD users when logged in as an external user?   Of course, as is often the case with comments on blogs, there really isn’t anywhere near enough information about the setup to answer accurately.

My first guess would be that the PeoplePicker has actually been deliberately configured that way.  It is a potentially huge security risk to allow external users to see all the usernames of your company, which is why many people using ADAM authentication run the following command:

stsadm -o setproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv yes

This command deliberately stops PeoplePicker returning internal AD users when logged in via forms based authentication outside of windows, including using ADAM.  You can tell if this is turned on by running:

stsadm -o getproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode

If this is the problem, you can turn the security feature off by running:

stsadm -o setproperty -url https://<url> -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv no

And your PeoplePicker should leap back into life for all users.

However, there are still some quirks with using the PeoplePicker with ADAM, even if AD users are allowed to respond.  Take a look at Matt Morse’s excellent blog on how the PeoplePicker returns different results from ADAM than you might expect if you are used to working with normal windows authentication.

EDIT:-

As always, after applying stsadm commands to your SharePoint installation, don’t forget to either reset IIS or the relevant application pool.

After installing SharePoint, and importing all the User Profiles, you’ll find if you are using the People Picker, you’ll only see users from the trusted domain that have successfully logged on the SharePoint 2007 server, rather than all of them.  This is rather bizarre, as you’ve imported all the profiles, and can see them!

You actually need to configure the PeoplePicker to do a lookup to the Domain Controllers, as its here the People looks, NOT the SharePoint user profile store.  It seems unusual, but true!  It’s quite a complex task.

Before you do anything else, work out a list of all of the domains the PeoplePicker needs to look at, INCLUDING the domain SharePoint is installed on.  If SharePoint is on Domain1 and you want to see all the Domain1 users and all the users from the trusted domain Domain2, you’re going to need to list them both, something most of the guides online don’t make clear.  You’ll also need the fully qualified domain names – doing use the older NetBIOS name.  If your domain is exampledomain.local, don’t just use “exampledomain” – we’ll need the full thing.

Next, make sure you have a valid Active Directory user account on each of the domains you want to look at.  You don’t need to worry about the domain the SharePoint server is on – the accounts SharePoint should be running under will already have access.

Now, we first need to set up an encryption key, so SharePoint can securely store the usernames and passwords for the other domains.  Use the following command on every server in the farm – if you don’t, the other SharePoint servers won’t be able to decrypt the stored user names and passwords:

stsadm –o setapppassword –password MyPassword

Replace MyPassword with your chosen encryption key, of course! 

Next, we need to tell each Web Front End server, which domains to use.  I always list the current domain SharePoint is a member of first, for ease of reference.  Normally, I’d expect at least two entries – the current domain and the trusted domain (or domains) – if there isn’t a trusted domain, why are you doing this???.  We’ll need to separate the entries in the domain list with semi-colons.

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain1.com;domain:domain2.com,domain2\user,password –url https://sharepoint.domain1.com

Here, the url should be replaced by that of your web application – don’t forget to use https if you’ve set the application up to use SSL.  Domain names should obviously be replaced with your own, and you should use the usernames and passwords from each domain that you either created or ensured were available earlier.  A more realistic looking example might be:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:technet.microsoft.com;domain:kb.microsoft.com,kb\AD_Lookup,LookUp2009 –url https://sharepoint.technet.microsoft.com

Please note this is an entirely hypothetical example, so don’t think of trying the links or usernames! 

Fianlly, though this generally isn’t mentioned in most of the other guides, you need to reset IIS before SharePoint will pick up the changes.  As always, I prefer the noforce option, just in case.

issreset -noforce

You should now see all of the available people from the domains you’ve selected in the people picker!

ISA Server 2006 is a strange, temperamental beast, and often needs to be cajoled into fairly standard functionality.  In order to deploy security so that users can authenticate from both the DMZ Active Directory, and the internal network (with a one way trust between the two) you need to deploy LDAP authentication.  In order to act as a secure front end and logging point, forms based authentication is recommended, particularly if branded authentication pages are important for you.  If you want to use it as a front end to extranet systems, a custom login page is pretty much a necessity, and if you need external users to change their passwords (rather than using code within your extranet or OWA), you’ll need to configure LDAP over SSL (LDAPS).

Before you begin, you’ll need to configure a domain user for ISA server to use to bind to the LDAP server, with rights to make changes if you need password change functionality.

You’ll need to ensure that your active directory domain can support LDAPS.  In order to do this, you need to intall certificate services, and ensure that the domain controllers and your ISA server all have server certificates installed, with the certificates matching their fully qualified domain names correctly. 

You can find a pretty complete guide here:

http://technet.microsoft.com/en-gb/library/bb794854.aspx

I struggled with a few points – its not clear that for password changes to work, for example, you need to use a user account with the right to make AD changes when defining the LDAP server set, and you don’t in order to simply log users onto the domain.  You apparently do in order to change passwords.

You can’t use windows authentication for any domains other than the one that the server is in, even if one way trusts are correctly configured – you really need to use LDAP server sets.  Thats not a problem if all of your internal users will access your secure extranet from the internal domain – you could bypass your ISA server and go straight to the web server.  However, people will want to give demonstrations, and work on the extranets from outside the office – its up to your policy to determine if this will affect the configuration.  Existing SSL VPN solutions might be a better option for your own employees.

Publishing SharePoint via ISA Server is fairly straightforward, even if you use SSL to the reverse proxy, and connect on port 80 to the SharePoint server in order to move the encryption load from your SharePoint box.

However, for some reason, this appears to break Telerik’s RadEditor.  In order to use RadEditor, you need to be able to connect directly to the server in the same format of the initial request, which means in the case of a secured SharePoint site, SSL.   Simply change the bridging rule to redirect requests to the SSL port, and disable redirection to the HTTP port.  This will place more load on your SharePoint servers – every request is encrypted via SSL between the SharePoint server and the proxy – weigh this load up against the editing benefits of RadEditor.

One of the common problems I’ve seen with Microsoft SharePoint is the loss of search functionality, and I’ve found a lot of different theories and possible solutions.  I’ve tried to combine the various ideas into a step by step troubleshooting strategy.  Pleae note that this only applies if you’ve had a working earch service in the past – if not, you need to enable the search service before you do anything else!

Symptoms

Individual sites and site collections respond to any search query with no results.

The event log on the SharePoint Server shows Event  ID 2436 – The start address <site url> cannot be crawled.

The crawl log within SharePoint says that the site cannot be crawled and has been deleted from the gatherer.

Possible Resolutions

First, disable loopback checking on IIS, if you haven’t already.  This is one of the most common causes of the problem, and if it isn’t done, means that you WILL experience the problem sooner or later anyway.  To disable loopback checking, you need to make a registry change and restart your server, so schedule it for a quiet time.

Follow these steps:

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value.
4. Type DisableLoopbackCheck, and then press ENTER.
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor, and then restart your computer.

Second, check the permissions on the search service.  It sounds silly, but it is easy to sometimes use an account that doesn’t have access rights to actually crawl the sites!  Don’t get too involved with this, however – if it looks right, it probably is.  Its easy to waste days checking odd possibilities of access rights, but if this is the cause, its normally pretty obvious!

Third, ensure that there is a site at the top level of the web application.  This sounds ludicrous, but I’ve seen systems spring into life after a blank site is deployed at the root of the website.  Its easy to check, and easy to fix.  Many people won’t have seen this, as it’s pretty common practise to deploy self service site creation in the root url.  I’ve particularly seen this on systems after an SP2 MOSS and WSS install.  If a 404 error is received on the root url, all the other sites won’t be crawled.

The SharePoint usage reports, once enabled, look extremely pretty, but are generally pretty meaningless unless you are dealing with absolutely huge numbers of hits, where averages and graphical representations are the only effective way of dealing with information.  However, there are two report pages that are extremely useful, particularly for slightly smaller sites, that can’t be reached through the GUI interface in MOSS 2007.   They are actually from the basic WSS system, and MOSS inexplicably misses out any direct reference though the administration pages.

The second of these, usage details, is brilliant for tracking usage of a site, showing which users have accessed the site on which days over the last month.  Its invaluable as a quick security check to make sure no unexpected users are accessing the site!  The permissions system in SharePoint is pretty robust, especially if you’ve stuck to SharePoint and AD groups to assign rights, but its always possible for oddities to happen.