When software attacks!

Thoughts and musings on anything that comes to mind

Searching SharePoint through an IE8 Activity

IE8 Activities look cool. They're almost like favlets from where I stand, but they offer a very simple way for users to access online services and pass simple parameters.

I decided I wanted to play, and we use SharePoint heavily here at Black Marble. The obvious thing to do was to create an activity which would allow the user to search for the selected text using SharePoint search.

Activities are defined through XML. Essentially, you give it a name, an icon and define the actions that can be performed. There are execute and preview actions, but the small preview window doesn't really lend itself to SharePoint search (I tried!).

Here is the xml for our sharepoint search activity. Note that I've replaced our hostnames. I called this file SharePointSearch.xml

   1: <?xml version="1.0" encoding="UTF-8"?>
   2:   <openServiceDescription xmlns="http://www.microsoft.com/schemas/openservicedescription/1.0">
   3:   <homepageUrl>https://portal.blackmarble.co.uk</homepageUrl>
   4:   <display>
   5:     <name>Find in Black Marble Portal</name>
   6:  <icon>https://portal.blackmarble.co.uk/_layouts/images/favicon.ico</icon>   
   7:   </display>
   8:   <activity category="find">
   9:   <activityAction context="selection">
  10:       <execute action="https://portal.blackmarble.co.uk/search/Pages/results.aspx">
  11:         <parameter name="k" value="{selection}" type="text" />
  12:       </execute>
  13:     </activityAction>
  14:   </activity>
  15: </openServiceDescription>

So what does that lot do? Well most of it seems pretty self explanatory. The key to the activitiy is in the section which defines the custom action. That has a url which IE8 will call and a list of parameters into which information is passed. A simple search in SharePoint uses the 'k' parameter to pass in the search term, so I have set that here.

So now we have our file, how do we get it into the browser. Well, I copied the xml file into the LAYOUTS folder in the SharePoint installation folder on the hard disk of the server, which is reference via _layouts in a url. I then added a Content Editor web part onto one of my pages and pasted the code to add the action into the source view:

   1: <p>Search Portal easily from IE8 with our custom activity.</p><button onclick="BLOCKED SCRIPTwindow.external.addService('/_layouts/SharePointSearch.xml')">Add Portal Search Activity</button>

This simply shows a short paragraph and a button. When the user clicks the button, IE8 asks whether it should install the activity and hey presto, a new menu item appears under 'More Activities' on the context menu. When I highlight text in my browser I can now quickly search our SharePoint for any relevant content.

Web development helpers: Redux

After posting yesterday about useful tools for development I stumbled across another little gem of a utility. IE7Pro is much more of a usability-enhancing tool but it has a wonderfully handy tool nestling within - Save Current Tab As Image. If you need to do grabs of pages for documentation or presentations and the page is more than a single screen in length this will transform your life - no more cropping and stitching!

IE7Pro also has a raft of features such as adblocking and mouse gestures, which I will admit to switching off immediately. However, it's inline search (not quite Find As You Type, but pretty close) is jolly useful.

Get IE7Pro

Web development little helpers

As web development gets more and more complex having the right tools to help you figure out what's going on is essential. I thought I'd do a quick post on the ones I find most useful. In no particular order, then, here they are.

  1. Virtual PC
    This one is a godsend, because as we all know, running multiple versions of Internet Explorer is hard. VPC, now available as a free download from Microsoft, allows me to run the numerous variants of IE our clients require me to test against.
    If you just want IE6, Microsoft have a handy downloadable pre-built VPC:
    Download Virtual PC
    Download the Internet Explorer Compatibility VPC Image
  2. Firebug for Firefox
    Now imitated for other browsers, Firebug is fantastic. A clear and straightforward way to identify the bugs in your pages or styles, it allows you to easily identify which stylesheet rules are being applied and in what order, and to hack 'em on the fly as you test your fixes. Add to that the ability to mangle the page and debug javascript and we have a winner.
    Download Firebug
    Firebug running in Firefox
  3. Chris Pederick's Developer Toolbar for Firefox
    Even though Firebug is great, I still use Chris Pederick's trusty developer toolbar for enabling and disabling styles, accessing the W3C validator and other stuff. Couldn't live without it, in fact.
    Get Developer Toolbar
  4. Nikhil Kothari's Web Development Helper for IE
    Broadly offering the same level of information as Firebug, but without the ability to hack on the fly, this is a handy way of seeing what IE is doing with your page under the hood.
    Get Web Development Helper
    Webhelper in IE
    The Webhelper DOM Inspector
  5. Inspector for Safari (for Windows)
    I have a trusty Mac Mini that I use for checking Safari as well, but the advent of Safari for Windows has made my life easier, I must admit. How excited was I, then, to find that you get Inspector working with the Windows version. Again, loads of info about the page, although hacking on the fly. Instructions courtesty of David Barkol's blog. A note - as I write this the latest nightly crashes horribly - I am using the nightly from the 21st June and it works well. At some point I will try later builds but right now a stable platform that I can enable easily and consistently is more important.
    Enable Web Inspector for Safari on Windows
    Inspector in Safari for Windows
    The Inspector Information Window

I'd love to hear from anybody who uses other cool tools that I may not have come across. I'm particularly interested in these kind of things for Opera.

SharePoint problems with access rights

I spent a while knocking my head against a problem with a SharePoint server farm that's worth posting about. It's also worth a big hats-off to our Technical Support Coordinator at Microsoft Partner Support who dredged up the article that finally pointed us in the right direction.

The problem

I'll post later about our approach to SharePoint installations, but I'll summarise thus: We create multiple user accounts to the SharePoint services - a db access account, an installation account etc etc. In this instance we were building a three server setup - db server, web server, index server. The accounts were created first, logged in as a domain admin. I also installed SharePoint as the domain admin, but didn't run the config wizard.

I then logged in as our installation user, which has local admin rights to the two servers and dbcreator and securityadmin roles in the SQL server. I ran the config wizard on the web server and created the farm, specifying the db access account for (shock!) db access! The web server got to host the central admin site, which was tested and worked.

Before doing anything else I ran the config wizard on the second server and connected to the farm. At this point I had three servers listed in the Central Admin site, and it was time to configure services.

At this point we hit the snag - when I tried to configure the Office Server Search Service to run on the second server I got a SharePoint page telling me access was denied ('The request failed with HTTP status 401: Unathorised'. There was a similar error in the event log with an event ID of 1314, and we also found an event log error with ID 5000.

I bashed my head against this for a while, checking user rights, group memberships and stuff. I checked the DCOM IIS WAMREG activation rights for the users that the app pools were running as and just in case did an aspnet_regiis -ga <username> for those accounts to ensure that all the .Net registrations and rights were correct. No success.

I removed SharePoint and reinstalled the farm with the roles reversed. The fault moved to the other server. I confirmed that I could configure the service on the same server as the central admin site but never on the other server. I looked at the system registry, compared service configurations with a working system and tried manually hacking the config to no effect.

In the end I uninstalled everything, installed the farm clean and unconfigured and called in air support.

The fix

I can't praise our support guy at Microsoft enough. He's incredible - I emailed him and got a phone call within five minutes! We ran through the problem and he consulted his support resources. What he came back with took a few goes to make stick, but it worked, and in fixing SharePoint pointed to the root of the problem.

The solution is to edit the web.config for the Office Server Web Services site. On our system that file is in C:\Program Files\Microsoft Office Servers\12.0\WebServices\Root. The original file looks like this:

<?xml version="1.0" encoding="utf-8"?>
        <sectionGroup name="microsoft.office.server" type="Microsoft.Office.Server.Administration.OfficeServerConfigurationSectionGroup, Microsoft.Office.Server, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" > 
            <section name="sharedServices" type="Microsoft.Office.Server.Administration.SharedServiceConfigurationSection, Microsoft.Office.Server, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> 
            <allow roles=".\WSS_ADMIN_WPG" /> 
            <deny users="*" /> 
                <clear /> 
                <add name="AnyHttpSoap" /> 
                <add name="Documentation" /> 

The solution is to edit the <authorization> section, adding entries to grant access to the user accounts for installation and db access:

            <allow roles=".\WSS_ADMIN_WPG" /> 
            <allow users="ondemand\MOSSdba" /> 
            <allow users="ondemand\MOSSsetup" /> 
            <deny users="*" /> 

However, the gotcha is that SharePoint puts the settings back - don't do an IISreset; don't recycle the app pool. Simply edit the file then go the page to configure the search service and it works. Once you've done that the service will start.

I then found that I couldn't get back into the page because the web.config got reset (grr), but that's not important right now.

The cause

The key in all this is that the two users I added explicit rights for were members of the WSS_ADMIN_WPG group specified inthe original file. This pointed at an issue with the domain - the server was failing to get a list of members for that group.

The servers themselves were built and managed by our customer's hosting provider, so I passed the fault to them. They checked the systems and found a domain fault affecting synchronisation. Result!

X2100 IPMI Redux - success!

In hindsight I should have thought of it, but even if I had, others got there first.

You may remember my problems with IPMI on our X2100 servers from an earlier posting. Today I had cause to revisit the matter, as we're having terrible issues with the Nvidia RAID on one of our servers.

The lack of a Windows version of IPMItool is still a pain, but I am leagues closer to a usable solution now, thanks to Cygwin. The solution, it turns out, whilst somewhat laborious, is fairly straightforward. Simply build IPMItool under cygwin. Result!

Instruction are available on the 'net and the IPMItool man page is on Sourceforge.

I can now query the SMDC board on my X2100s from Windows.

SharePoint 2007 on x64 - don't try to run 32-bit web apps!

We're slowly migrating services onto our new servers here at Black Marble. This morning we had one of those moments where significant amounts of wall kicking and teeth gnashing ensue.

Basically, we forgot that if you enable 32-bit .net support on IIS 6 it disables 64-bit support - you can't run 32 bit and 64 bit apps concurrently.

We spent a long time the other week getting our release version of SharePoint 2007 installed on one of our shiny Sun X2100 x64 servers. We expect the site to be quite large, so it made sense to run the x64 version of SharePoint.

Unfortunately, when 32-bit .Net apps were enabled by mistake, SharePpint and the other 64-bit web apps all stopped. Removing .Net 1.1 and running the aspnet_iisreg -i command from the x64 .Net 2 framework folder got us back up and running, but SharePoint refused to allow anyone to login.

Fortunately the Central Admin site was still working, so I had a rummage. It looked like SharePoint was no longer talking to our AD, so I went to the Application Management site, and went to the Authentication Providers option in the Application Security section.

In here you can edit the settings for each Web Application. I went through each of ours, and clicked on the 'Default' zone which is listed in the Web Application page.

I didn't need to change anything - simply hit the save button and SharePoint seemed to rewrite it's settings. Once this was done, our SharePoint started talking to people again.

Now, I don't expect you to hit the same crazy situation as we did, but it's nice to know that you can coax SharePoint back into life without restoring stuff from backup.