Hey – we’ve all made mistakes.  We all know that “oh sh**” moment right after we realize what we’ve done.  Often times this occurs right after we click a friendly “Are you sure??” dialog.  Of course I’m sure – if I wasn’t sure I wouldn’t have chosen to do it in the first place!  Stupid computer.

Anyway, I recently had a situation where someone (honestly, in this case it wasn’t me) accidentally deleted the Site Collection for the SSP admin site (/ssp/admin).  Since this was for a SharePoint farm in production I really didn’t want to have to re-create the entire SSP but I couldn’t figure out how to just re-create the site collection itself.  I figured there had to be a site template for the site but since it didn’t show up in the Create Site Collection UI I went and looked on disk.  Sure enough, a site template exists for the SSP Admin site.  It’s called OSRV.

So to create a new SSP admin site, run this command line.

stsadm.exe -o createsite -url http://<server&gt;:<ssp_port>/ssp/admin -owneremail <email address> -ownerlogin <account> -sitetemplate OSRV#0 -title "Shared Services Administration: <your ssp name>"

This might take a little while to complete, but it does eventually finish.

Next you need to edit the SSP to point to the recreated site.

stsadm.exe -o editssp -title "<your ssp name>" -sspadminsite http://<server&gt;:<ssp_port>/ssp/admin

That’s it.  You should be back up and running.

Advertisements

SharePoint? Meet Python

August 12, 2007

Ever have a need to quickly script some administrative task relating to SharePoint? Ever wish there was more you could do with STSADM? Ever wish you had an interactive console for exploring the object model and testing various methods or properties? Well Iron Python is your answer. In this short article I’ll show you how to get up and running with Iron Python and SharePoint. I’ll also show you a few scripts that will give you some insight into the potential power of this extremely useful combination. Read the rest of this entry »

Site Templates

June 20, 2007

I hate searching for this stuff every time I need it.  So here is a list of SharePoint site templates and their friendly names.

Friendly Name Template
Team Site STS#0
Blank Site STS#1
Document Workspace STS#2
Wiki Site WIKI#0
Blog BLOG#0
Basic Meeting Workspace MPS#0
Blank Meeting Workspace MPS#1
Decision Meeting Workspace MPS#2
Social Meeting Workspace MPS#3
Multipage Meeting Workspace MPS#4
Document Center BDR#0
Records Center OFFILE#1
Personalization Site SPSMSITE#0
Site Directory SPSITES#0
Report Center SPREPORTCENTER#0
Search Center with Tabs SRCHCEN#0
Search Center SRCHCENTERLITE#0
Publishing Site CMSPUBLISHING#0
Publishing Site with Workflow BLANKINTERNET#2
News Site SPSNHOME#0

I recently did some load testing for a client and needed to populate our environment with sample data to simulate real-world usage.  This was my first occasion to use the tools released on Codeplex for this – WSSDW and MOSSDW.  As I was stumbling through the semi-documentation and samples that didn’t really work I started jotting down some notes.  This is a collection of these lessons learned – hopefully they’ll help someone else avoid some of the “WTF” moments I had 🙂

Download both WSSDW AND MOSSDW.
I ran into a ton of problems when I started because I only downloaded MOSSDW.  The samples don’t work without WSSDW – WSSDWLib.dll to be exact.  So download them both and install them in the same folder. 

You need to “Unblock” the help files (chm) before you can read them.
After downloading the help files, right-click, choose properties, then click Unblock.

Don’t bother trying to delete sample content. 
The tool just doesn’t work very well.  You’ll end up with an error and a bunch of left over content.  The best thing to do is just to create your sample site hierarchy under a single “Test” web and then just delete the Test web manually (or with stsadm) each time.  Note, you may have to use the Manage Site Content and Structure UI in MOSS so that you can delete webs with subwebs.

Creating a publishing page and publishing it is a two step operation.
This just seems weird so maybe I am missing something.  But if you want to create a publishing page, add content to that page, and publish it, you need two XML node actions.  The first node creates the page and adds content.  The second node publishes it.  For example:

<TestPage Name="Page1.aspx" PageLayout="ArticleLeft.aspx" openmode="modifyexisting">
  <TestHtmlFieldValue Name="Page Content" HtmlFile="MOSS_Intro.htm" openmode="modifyexisting"/>
</TestPage>
<TestPage Name="Page1.aspx" openmode="modifyexisting" Status="Published" />

You would assume you could just add the Status=”Published” bit to the first TestPage node.  But what happens is that the status gets set before the TestHtmlFieldValue node is parsed – so this action fails because the page isn’t checked out.  *rolls eyes*

Mixing and matching MOSS tags and WSS tags has some issues.
If you’re going to mix and match MOSS and WSS tags, be sure to use WSS tags to walk your web hierarchy.  The <TestArea> MOSS tag won’t provide context to children such as <Lists>.

Agile is THE ONLY way to build SharePoint applications.  Pure and simple.  If you think otherwise, sorry.  You are wrong.

Oh… you wanted an explanation?  Okay – here you go.

I could bore you with a bunch of background on Agile and what’s good about it, what the process is, what the core concepts are, etc.  But I won’t.  If I did that we would just go back and forth forever on the benefits/shortcomings of Agile development.  Instead I’ll get right to the point.

You do not know enough about SharePoint to fully spec a solution end-to-end.

Let me repeat that.  YOU (yes you), DO NOT know enough about SharePoint.  I know you think you do.  I know you think you know how everything works, how everything fits together, but you don’t.  And you know what?  Nobody does.

There you go.  Any application you want to build that has any level of complexity just cannot be fully designed up front.  There are too many unknowns at every level in the product.  Too many assumptions need to be made about what should work.  And we all know that there are dozens of unanticipated gotchas waiting around every turn.

SharePoint 2007 is a huge product.  It has a ton of little nooks and crannys each providing great functionality, but also hiding pure WTF, “why did they do it that way”, suprises.  SharePoint is just too big and too new for anybody to know it intimately enough to fully define a solution end-to-end without actually doing some trial and error implementation.  So if you’re doing trial and error implementation anyway, why not include the client and make them short iterations?

Okay – a few more quick benefits to this approach:

  1. Don’t have to spend time documenting out of the box functionality that you don’t have control over anyway
  2. Wireframes and UI designs are less critical because you can “design” on the fly using the out of the box UI – then identify the gaps where additional design elements or controls are needed
  3. End up with less code/customization because once users see it out of the box, they quickly reach a “good enough” point.  You can focus your customizations where where adds real value.
  4. The very nature of letting the user touch and feel the solution will change their requirements.  They will realize that certain things are less important than they thought while others are more important.  This is true with any application development but the fact that you can do so much out of the box in SharePoint means you can get to this point very very quickly.

So there you go.  Good luck.  We have a tough fight ahead of us convincing people that SharePoint is different enough to warrant throwing old waterfall methodologies away and trying something new.

I’m on a mission. And that mission is to build SharePoint apps without dropping code on the server. Why would anyone want to do this? Well, in many enterprise or hosted environments you don’t have the ability to drop DLLs into a shared SharePoint environment. This has often limited the types of applications we can build to out of the box features or SharePoint designer. But with some Javascript and the WSS web services, we can build a more complex app all with AJAXy goodness.

This code sample uses the Prototype Javascript library. When you see Ajax.Request, that’s using prototype’s Ajax framework. The great thing about prototype is that everything is cross-browser compatible.

First we need some code that formats a simple SOAP envelope. SOAP is the required protocol for communicating with the SharePoint web service.


var Soap = {
  createEnvelope: function(action, ns, parameters)
  {
    var soap = '<?xml version="1.0" encoding="utf-8"?>
        <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
        <soap12:Body>';
    soap += '<' + action + ' xmlns="' + ns + '">';
    soap += Soap.__parseParameters(parameters);
    soap += '</' + action + '></soap12:Body></soap12:Envelope>';
    return soap;
  },

  __parseParameters: function(parameters)
  {
    var params = "";
    if (typeof parameters == 'object')
    {
      // check if we were provided an array or an object
      if (typeof parameters.push == 'function')
      {
        for (var i = 0, length = parameters.length; i < length; i += 2)
        {
          params += "<" + parameters[i] + ">" + parameters[i+1] +
              "</" + parameters[i] + ">";
        }
      }
      else
      {
        $H(parameters).each(
          function(pair)
          {
            params += "<" + pair.key + ">" + pair.value + "</" + pair.key + ">";
          });
      }
    }
    return params;
  }
}

Okay, so now we can make a SOAP envelope as simple as this:

var mySoap = Soap.createEnvelope(
  "MyAction",
  "http://schemas.microsoft.com/sharepoint/soap/",
  { param1: "value", param2: "value" });

Simple enough. Now let’s call a SharePoint web service. We’ll use the Lists web service and create a new list item. The UpdateListItems method allows us to pass in some XML defining the items to create. So first I’m going to build that XML.

var batch = '
  <Batch OnError="Continue">
    <Method ID="1" Cmd="New">
      <Field Name="ID">New</Field>
      <Field Name="Title">Hello World</Field>
    </Method>
  </Batch>';

Next we’ll call the web service using the Ajax.Request object:

// build parameter object
var parameters =
{
  listName: "My List",
  updates: batch       // xml created earlier
}

// create soap envelope
var soap = Soap.createEnvelope(
  "UpdateListItems",
  "http://schemas.microsoft.com/sharepoint/soap/",
  parameters);

// call web service
new Ajax.Request(
  "http://myserver/mysite/_vti_bin/lists.asmx",
  {
    method: "post",
    contentType: "application/soap+xml",
    postBody: soap,
    onSuccess: function(transoprt) { alert("Success: " + transport.responseText); },
    onFailure: function(transport) { alert("Error: " + transport.responseText); }
  });

If all goes according to plan, I should have a new list item with the title of “Hello World” in the list called “My List”.

A couple of points about the javascript above:

  1. It’s certainly not the greatest Javascript in the world. I plan to clean it up and hopefully release a Javascript library for working with all of SharePoint’s web services.
  2. The user’s browser must already be authenticated for this to work. Prototype doesn’t have a way to pass credentials to the web service so make sure you run this from a machine joined to the same domain as the sharepoint site. Ideally this is running within a sharepoint site so that should take care of the authentication problem.
  3. FireFox has an issue because it doesn’t pass domain credentials automatically. This makes debugging hard from your workstation, but if it’s running on a SharePoint site where the user has already authenticated, it works fine.
  4. I cheat in the example above and break strings onto multiple lines. That’s for the purpose of formatting only. If you copy and paste this code directly it won’t work.

You can download the code here: wsswebservice.js.

I read an interesting article today that has both re-affirmed and made me question existing notions I had about user interface design and ease of use. One of the points of the article is that user interfaces which display all avaliable choices at once are easier to use than those that hide the choices behind sub pages, sub menus, etc. The point that the article makes (actually referencing another article “The Truth About Google’s So-called ‘Simplicity’,”) is:

“Why are Yahoo! and MSN such complex-looking places? Because their systems are easier to use. Not because they are complex, but because they simplify the life of their users by letting them see their choices on the home page: news, alternative searches, other items of interest.”

My first thought when reading that was “then why is the damn SharePoint Central Admin so hard to use??”.  I don’t know about you, but every time I go in there I feel like an idiot because I have to stare at the page for 5 minutes and scan each link to remember which item will take me to the options I need.  Not only that, but I frequently have to click on an item to remember “nope – that’s not the one”.

On the other hand, I think about other interfaces like Window’s control panel.  One of the first things I do when I install Windows is revert the control panel to classic mode so that I can easily see all options available to me.

Maybe the reason why Central Admin is so hard to use is that they’ve tried to show you many options at once, but still in a grouped way.  For example, first off you have the Operations and Application Management tabs.  My first challenge when I’m looking for something is to remember what tab it’s on.  I can’t tell you how many times I’ve quickly scanned the Operations page not seeing what I need, gone to the Application Management tab only to come back to the Ops tab after reading through EVERY link on that page (and clicking on quite a few).

Then, on each page you have groupings of links: Global Configuration, Topology and Services, Security Configuration, etc.  When you’re just scanning the page you tend to see the group names before the links themselves so if you don’t remember what group something is in, you might miss it on a quick pass.

Maybe a better UI would be a simple alphabetized list of all links.  I usually know the name of the link I want, I just can’t remember what group or what tab it’s on.

Or another idea would be to group related options into “Tools” similar to the control panel in Windows.  You could have

  • Security Manager – all security settings including farm accounts, farm administrators, etc
  • Site Manager – configure web apps and site collections
  • Server Manager – services, backup and restore, farm topology, etc

Anyway, all I know is that central admin is hard to use.  But on the other hand, maybe that’s inevitable when you have a product as large and with as many options as SharePoint has.