blogs.conchango.com

This week, I've struggled a bit with my team to get MOSS installed in a simple two-server farm.  Having gone through it, I have a greater appreciation for the kinds of problems people report on the MSDN forums and elsewhere.

The final farm configuration:

• SQL/Index/Intranet WFE inside the firewall.
• WFE in the DMZ.
• Some kind of firewall between the DMZ and the internal server.

Before we started the project, we let the client know which ports needed to be open.  During the give and take, back and forth over that, we never explicitly said two important things:

1. SSL means you need a certificate.
2. The DMZ server must be part of a domain. 

Day one, we showed up to install MOSS and learned that the domain accounts for database and MOSS hadn't been created.  To move things along, we went ahead and installed everything with a local account on the intranet server. 

At this point, we discovered the confusion over the SSL certificate and, sadly, decided to have our infrastructure guy come back later that week to continue installing the DMZ server.   In the mean time, we solution architects moved ahead with the business stuff.

A weekend goes by and the client obtains the certificate.

Our infrastructure guy shows up and discovers that the DMZ server is not joined to any domain (either a perimeter domain with limited trust or the intranet domain).  We wasted nearly a 1/2 day on that.  If we hadn't let the missing SSL certificate bog us down, we would have discovered this earlier.  Oh well....

Another day passes and the various security committees, interested parties and (not so) innocent bystanders all agree that it's OK to join the DMZ server with the intranet domain (this is a POC, after all, not a production solution).

Infrastructure guy comes in to wrap things up.  This time we successfully pass through the the modern-day gauntlet affectionately known as the "SharePoint Configuration Wizard."  We have a peek in central administration and ... yee haw! ... DMZ server is listed in the farm.  We look a little closer and realize we broke open the Champaign a mite bit early.  WSS services is stuck in a "starting" status. 

Long story short, it turns out that we forgot to change the identity of the service account via central administration from the original local account to the new domain account.  We did that, re-ran the configuration wizard and voila!  We were in business.

</end>

Subscribe to my blog.

There's a common business scenario like this:

• User fills out an InfoPath form.
• Submits form.
• Long-running workflow process kicks off.
• While the workflow is running, we don't want anyone to change the content of the form.

This office.microsoft.com example describes how to create a separate "view" and mark the whole view as read-only.  This is a workable approach but has the drawback that you've effectively created two entire versions of the same form and must now keep them in sync manually.  If you add a field to the editable view, you must then add it to the non-editable view as well.  Over time, with different developers, there can be some divergence. 

This alternative might work better in some cases:

• Add a new field to the form called "IsEditable".
• Set its default value to true.
• Promote it when publishing to MOSS.
• In the workflow, set the value of IsEditble to false.
• Go back to the form.
• Add a rule that "upon open of the form", disable your save button when IsEditable is false.

The drawback to this approach is that all the fields will still be editable on the screen.  The user can get a false impression that they can actually change content.  You can mitigate that by putting in some text that the form is disabled, possibly in big red letters across the top of the page.

In one project, I created a "workflow status" view.  As the workflow progressed, it would update specific status fields that had been promoted from the form.  When the user opened the form, the "open form" rule automatically switched to that view and the user had a nice little summary status.

</end>

Subscribe to my blog.

In the last several months, a dozen or more folks from across the planet have been emailing me and asking the general question, "How do I learn SharePoint?"

I'm hardly authoritative, but I've had some success (and trying to get better all the time) so I thought I'd document my personal road map.  Others may find it valuable.

Before I do that, I just want to observe that it's obvious to me, based on these personal emails and the even greater number of MSDN / SharePoint University posts of the same nature, that there is huge developer interest in getting up to speed with WSS/MOSS.  I wonder what it's going to be like a year from now ... easier to find good SharePoint talent?  The same?  Are folks committing themselves to the platform at a rate sufficient to keep up with demand for good resources?  How could you even figure something like that out short of a WAG?

Paul's Roadmap

I was full time employed by the good folk at Conchango while I followed this road map.  This means that from a learning perspective, I was actively engaged in projects as I followed the steps I outline below. 

Some Basic Terms

For people entering this world, there are two key acronyms:

• WSS: Windows SharePoint Services
• MOSS: Microsoft Office SharePoint Server

WSS is "free" in that it's bundled with windows server 2003 (or at least can be downloaded from MS).  I put quotes around free because you need a box, a valid O/S license and probably SQL (though there's a "free" kind of SQL as well). 

MOSS is built on top of WSS and extends it.  There is no MOSS without WSS.  MOSS is not free.

Perhaps not day one, but soon after you've got some basic familiarity with the platform, it's important to learn the differences.  For example, a powerful web part, the Content Query Web Part, is a MOSS feature and not available WSS.  People often make the incorrect assumption that CQWP is available in WSS and then end up scrambling for a stop-gap measure when they realize their error.

Hit the Books

I started working with WSS/MOSS on about 01/02/2007.  I had a little prior experience with SPS 2003 but very little.  To get myself started, I purchased the two books listed here (http://paulgalvin.spaces.live.com/lists/cns!1CC1EDB3DAA9B8AA!203/).

I started with the big blue administration book.  Naturally, it covers administration.  At the same time, it provides a survey of all MOSS features (and WSS features as well).

For me, it's not so important to remember all the various details (until it's time to get certified) but it's good to know the boundaries.  (I follow this same approach in 1st person shooters I play on the xbox or PC -- I enter a room and tend to make a counter-clockwise loop until I get back where I started.  I just feel better knowing the shape of the box I'm in.)

After reading the big blue book, I would read the entire Inside WSS book.  It dives deeply into issues that developers care most about.

Create a Virtual Environment

In order to do any development or properly use the environment, you need a full blown windows server operating system with SharePoint Designer, Visual Studio 2005 (2008 works, but some useful tools have yet to be ported as of the writing of this article), InfoPath 2007 and some other stuff.  There are many good blog entries describing this process.  I'd have a look at these two:

• How to Create a MOSS 2007 VPC Image: The Whole 9 Yards - SharePoint Reporter Blog
• How to build an optimal developer VPC for SharePoint Development - Blog

In addition, Andrew Connell shared his experiences with VMWare here:

• Microsoft's virtualization products vs. VMWare's offerings

Use your favorite search engine to see what other people do.  It's a useful learning exercise in and of itself.

Spend a few minutes angrily denouncing the fact that you need a server environment on which to do development.  But ... don't bother blogging about it or posting it to MSDN forums.  It's already been done :).  Instead, embrace it and move on.  You'll be better off for it.

Get Certified

I believe that the MS SharePoint certification path, which consists four exams, is exhaustive.  I suggest that you follow their online preparation guide and do your best to understand each of the areas of the test.

I do not suggest that you take the exam just to pass it.  I do not suggest that you use one of the "brain dump" style 3rd party "tools" for passing MS tests.  If you can take the test, pass it based on a combination of your own directed study and hands-on experience, you'll be a stronger developer and job candidate for it.

There are four tests in two "tracks":

Developer:

• TS: Microsoft Windows SharePoint Services 3.0 - Application Development
• TS: Microsoft Office SharePoint Server 2007 – Application Development

Admin:

• TS: Windows SharePoint Services 3.0, Configuring
• TS: Microsoft Office SharePoint Server 2007, Configuring

I recommend that developers study for all of these exams.  You'll be strong for them, though I suppose if you skipped the admin exams, you would get by.

I found the WSS version to be considerably more challenging than the corresponding MOSS versions, much to my surprise.  I was in a class recently and several others made the same point.

While I was studying for the 70-542 exam (MOSS development) I tracked my study resources.  These may be helpful to you as well: http://paulgalvin.spaces.live.com/Blog/cns!1CC1EDB3DAA9B8AA!192.entry

Plug Yourself Into the Community

The SharePoint community is vibrant, strong and growing larger all the time.

You want to look at the following to start:

• Blogs
• Forums
• Codeplex
• Twitter

Blogs

If you don't understand RSS, stop everything and learn it.  It will take 10 minutes to learn it, maybe another 10 minutes to find a web based RSS reader (I like google's reader, www.google.com/reader).

Start by adding this blog to your RSS reader :)

Next, add www.sharepointblogs.com to your reader.  They aggregate many blogs into a single feed.

Over time, you'll find blogs that are not aggregated that way.  Just add them individually.

I subscribe to a few dozen blogs which I've accumulate over the last year.  If you want, I can export my list and email it.

Eventually, you may want to start your own blog.  I personally think that a series of blog entries describing a "newbie's" progress learning WSS/MOSS would be an interesting series. I wish I had done that myself.

Forums

I actively participate in two forum groups: MSDN and SharePoint University.

Forums are excellent places to learn.  People ask questions ranging from the very simple ("How do I create a site column") to the panicked ("My server is down!") to more hypothetical design questions.

Once you get a flavor of the environment, venture out and start replying.  Short of directly interacting with a customer, nothing is better than this for hands on experience.

Codeplex

Go to www.codeplex.com.

Check it out and search for SharePoint projects.

Subscribe to the daily summary Codeplex feed in your feed reader.

Add any new SharePoint projects to your feed reader.

Eventually, after reading the forums and facing down your own WSS/MOSS demons, consider putting together your own codeplex project.

Twitter

As I write this blog entry, a lot of SharePoint folk have started using Twitter. 

It's hard to characterize Twitter.  You'll just have to check it out yourself.

Conclusion

That wraps up my roadmap and makes me current.  I just started using Twitter two weeks ago.

WSS/MOSS is a very cool platform and the community is growing all the time.  Use community resources to improve your skills and enjoy the journey!

</end>

 Subscribe to my blog.

As many people know, the Employee Training template provided by Microsoft here has a bug that we can reproduce following these steps:

• Create a class with a max size of 10 students.
• Register --> Total available seats properly decrements by one.  Result: 9 available seats.
• Unregister: --> Bug.  Total available seats should increment by one.  It does not.  Result: 9 available seats as per SharePoint, but in fact, there are 10 available seats.

Solution: Use SharePoint Designer to correct the workflow.

First, open up the site.  The folder list for me looks like this:

If we have a look at the "Attendee registration" workflow, we see that there is a step labeled "Enforce seating policy".  It looks like this:

This step in the workflow updates the item by incrementing the "Filled Seats" metadata column on the course.  If we pull that up in more detail, we see this:

That's all the information we need to fix the unregistration workflow.

If we flip over to the unregistration workflow, there is no similar workflow step.  Add it as follows:

1: Expand "Attendee unregistration" and open up the XOML (see first screen shot if you're lost).

2: Add a new workflow variable, "New Filled Seats" of type "Number".

3: Assign a value to "New Filled Seats" as shown:

4: Decrement the Filled Seats by 1:

5: Update the related Course item:

6: Make sure all the steps are in the right sequence.  For me, it looks like this:

7: Finish the workflow to re-build it.

8: Test.

</end>

 Subscribe to my blog.

This is a continuation in my FAST coding mini-series for SharePoint folk.  The bit of code below executes a search for the term "test" in FAST via a Console application.  Obviously, it's a hop, skip and jump away to wrap this logic inside a web part or application page:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections.Specialized;
using Com.FastSearch.Esp.Search;
using Com.FastSearch.Esp.Search.Http;
using Com.FastSearch.Esp.Search.Navigation;
using Com.FastSearch.Esp.Search.Query;
using Com.FastSearch.Esp.Search.Result;
using Com.FastSearch.Esp.Search.View;
using System.Collections;

namespace Conchango
{
    class InvokeSimpleFASTQuery
    {
        static void Main(string[] args)
        {

            #region Initialize our communication with FAST
            ISearchFactory searchFactory;

            NameValueCollection nameValueCollection = new NameValueCollection();

            nameValueCollection.Add("fastsearchengine", "Com.FastSearch.Esp.Search.Http.HttpSearchFactory");
            nameValueCollection.Add("Com.FastSearch.Esp.Search.Http.QRServers", "fastdemoback:15100");
            nameValueCollection.Add("Com.FastSearch.Esp.Search.Http.RequestMethod", "GET");

            searchFactory = SearchFactory.NewInstance(nameValueCollection);

            #endregion

            #region Launch a query 
            
            string queryString = "test";

            Query query = new Query(queryString);

            query.SetParameter(BaseParameter.CLUSTERING, false);
            query.SetParameter(BaseParameter.NAVIGATION, true);
            query.SetParameter(BaseParameter.NAVIGATION_DEEPHITS, 100);

            ISearchView searchView;
            searchView = searchFactory.GetSearchView("sharepointconn");

            IQueryResult result = searchView.Search(query);

            Console.WriteLine("Total results from search: [" + result.DocCount + "].");

            int docCounter = 0;

            while (docCounter < result.DocCount)
            {

                docCounter++;

                IDocumentSummary thisDocSummary = result.GetDocument(docCounter);

                Console.WriteLine("[" + docCounter + "]: " + thisDocSummary.GetSummaryField("url").StringValue);

            } // while

            Console.ReadLine();
            #endregion

        }
    }
}

It generates the following result:

</end>

Subscribe to my blog.

I've been lucky to have an opportunity to work on a FAST <--> SharePoint integration project and thought I'd continue to share my limited experience with the community.

Microsoft is in the process of purchasing FAST.  I don't know anything about the schedule except that it should be finished in the "2nd quarter" which I assume means by 06/30/08.

My project's design, at a very high level, calls for creating a few web parts that have roughly the same look, feel and functionality as the standard MOSS search box and core results web part, but pulling from FAST.  I've made some baby steps in that direction.

FAST is a dedicated search engine.  It's not based on Microsoft technology, though it's obvious to me that some of the FAST engineers clearly understand MS tech (or they've made use of contractors). 

FAST:

FAST is a big monster server product (and I don't mean that in a bad sense; MOSS is a big monster product to me as well).  It appears to be based on Java and I noticed some apache stuff and maybe some PHP.  I wouldn't be surprised if there were other bits of tech mixed in here and there.  It definitely runs on windows server and is working fine in the virtual environment which I've been using.

It makes use of a facade web service that crawls SharePoint content for indexing in its special FAST way. 

A SharePoint end user would be pretty much at home with FAST's user interface.  It has simple/advance search, shows results, is big on relevancy (though I don't see how it handles social relevancy).  However, it does go further.  Its stemming seems better.  I really can't articulate it well but I'll just say "it's better."  You can take my word for it, or not :)  I may elaborate on this point in the future, as I learn more.

MOSS:

FAST provides a .NET-friendly DLL that provides an interface to the FAST engine.  This makes it possible for us to create web parts or application pages or whatever we want to query FAST and present the results.

There seems to be a web service interface as well.

I also have access to a FAST-provided web part that does integrate MOSS and FAST.  I don't know if this is a POC, something that was whipped up as a demo or what.  It's definitely a good learning tool, not so sure if it's production-ready.

That's it for now.  As I progress through the project, I'll post more.

</end>

Subscribe to my blog.

One of the emerging patterns I find in crafting SharePoint solutions leverages SharePoint Designer workflow and an event receiver.

Here is a business scenario to put it in context:

• I upload a document to a doc lib.
• I kick off multi-step workflow created using SharePoint Designer.
• At some point during that process, workflow assigns a task to someone (via collect data from user or assign a task).
• We want to use a KPI to track how long that task is awaiting completion.  The KPI shows green for tasks that are completed or due more than 3 days from now.  It shows yellow if the task is due tomorrow or today.  It shows red if the task is past due.
• Here's the kicker: I want the date that drives that KPI to be holiday-aware.

I can't calculate a holiday-aware due date in SharePoint Designer workflow very easily.  I would have to create a custom action or use a 3rd party tool.  However, it's easy enough to calculate such a date in an event receiver.  Merge those two together and we get a pattern like this:

• Define a hidden yes/no site column on the document library labeled "DoCalcualteDueDate".
• Initialize it to false.
• At the appropriate time in the workflow (e.g. just before the "collect data" action), assign that value to True.
• An ItemUpdate() event receiver looks to see if "DoCalculateDueDate" is true.  Since the event receiver runs on every update, "DoCalculateDueDate" is normally false.
• When workflow assigns DoCalculateDueDate to true, the event receiver calculates the holiday-aware due date.
• When the event receiver does this calculation, it sets the DoCalculateDueDate flag to false.

In the end, SPD workflow is communicated with an event receiver via the DoCalculateDueDate semaphore and we have holiday-aware due dates that are assigned at the exactly correct moment in the workflow's life.  SharePoint Designer controls when the due date is assigned but the event receiver performs the actual calculation and assignment.

</end>

Subscribe to my blog.

It's often useful to store status information in a custom list such as an approval code which should never be directly manipulated by end users.  This is a common business scenario.  I have been working on a project this year that generates various status and reminder dates via SharePoint Designer workflows that then drive KPIs and generally support time-critical business processes. 

Use a site content type / column to achieve this effect.

Create a site content type with the status column as shown:

Note the "Status (for Demo)" field at the bottom.

Next, click on the column name to access the column's properties.  Select "Hidden (Will not appear in forms)" in the Column Settings section as shown:

This removes the field from the standard edit/update forms.  However, it is still available in views, KPIs, the object model and anywhere else you want to use it, including SPD workflow. 

</end>

Subscribe to my blog.