Check me out at:

http://www.sharepoint911.com/blogs/john

A few days ago in my post called "Creating a custom advanced search by building strings with JavaScript" I talked about how you could use the Content Editor Web Part (CEWP) to build strings that would allow you provide a user friendly way to leverage the advanced search capabilities in MOSS.

To take the concept one step further, what if you created multiple HTML fields in your CEWP and wanted to allow users to be able to type in values in each field to refine the searching experience.  For example you could have two boxes like Car and Color.  A user could type in Blue and Ford and get only the values that matched both metadata properties. All you'd need to do is figure out what your search query would need to look like.  To test you'd need to type a query in this format:

Property1:"Value1" Property2:"Value2"

This would produce a URL that looked something like this:

myResults.aspx?k=Property1%3A%22Value1%22%20poArea%3A%22Value2%22

All you'd need to do is just use some JavaScript to build a string in a similar format.  If you really wanted to get fancy, you could build some smarts into your JavaScript function to allow users to enter data into some or all of the fields and have it check if the field is blank to not use that value in the string.

 -JR

A little more than a month ago a client called and wanted to customize the MOSS search to allow users to type in a City and have the search only query values in a specific field.  It sounded easy enough, but I told the client I wanted to do some research first which led me to some blog posts like this and this.  I tried it out and it worked – well I thought it worked.  When I tested this method with a real set of data paging no longer worked.  What I mean is that if I performed a search against a scope that had 100 items, if my initial query returned 15 results.  As soon as I clicked on page 2, SharePoint basically forgot what I was searching for.  I had already told the client I had an answer for him, so I was in a little bit of a pickle.

I posted comments to the blogs and even asked a question or two in the MSDN SharePoint Forums – the answer was always “to solve the problem you’ll have to write a custom search box web part.”  This really wasn’t the answer I was looking so I decided to come up with a better way.   It wasn’t until I was in my car on a 2.5 hour drive that the answer hit me. 

A while back, Shane Young (aka The Search Pimp) had shown me a little trick on how to search on a specific metadata property.  All you have to do is  enter a query like this into your Search Box:

Title:<whatever>

That search query will then refresh the page and the URL will now show something like this:

http://webappname/searchcenter/Pages/Results.aspx?k=title%3Atest&s=All%20Sites

That URL has all the information that MOSS needs to return search results and there’s no issue with paging.  To solve my problem, all I had to do was build a string.  Those original blog posts gave me another idea – I decided to use the Content Editor Web Part (CEWP) to build a field and a button attached to a Javascript function.  The idea was that when I clicked the button it would just build my string and then redirect the page. 

If you are trying this at home here’s what you’ll need to do:

1)      Create a web part page

2)      Add the following web parts:

Content Editor Web Part

Search Statistics

Search Paging

Search Core Results

3)      Add the following code to your Content Editor Web Part:

Title:<input name=input1 />

<INPUT id="Submit1" onclick='Redirect(form.input1.value)' type="button" name="schButton" value="Search" />

<SCRIPT LANGUAGE="javascript">

function Redirect(input)

{   

//Location where you want to display the search results.  This example assumes you’d want to have a //Core Search Results webpart on the same page.  But you could redirect to any page with a Core Search //Results webpart

 var baseURL  = "mySearchResults.aspx?k=Title%3A"+input

    top.location.href = baseURL;

    return true;

}

</SCRIPT>

Using this technique opens up a ton of possibilities.  The main use I’ve seen is to allow users an easy way to search on specific information without having to show them how to use the Advanced Search.  Scopes can also be passed in as a query which you can see in the first URL I showed above.  Since doing this the first time I’ve probably had 5 requests from different clients to do some variation of this.

For my client, I customized the search results using this post from Tobias Zimmergen but the options for tweaking this idea are pretty wide open.  I’ve got some other ideas about how to further enhance this concept but I’m going to save it for another post. 

As you can see, the answer didn’t take custom coding (the JS was borrowed from one of the many examples out there) – all it took was just a little creativity with using what’s Out Of The Box.

JR

I was working with a client recently and I was giving the typical demo of MOSS functionality.  As I was showing off My Sites and the web parts available the client immediate asked about the ability to use KPIs.  The idea that a user could have their personal start page that showed personal KPIs of the projects they were working on sounded fantastic!  Right?

 Not so fast.  I agree that it is a great idea that would provide tons of value, but the truth is that the KPI web parts will not allow you to access a KPI List located in another site collection, let alone another web application (most companies put My Sites on their own web applications). 

 The rumor that this functionality will be available in future versions of the product, but until then we've got to be creative.  I'm a huge fan of the KPI and BI tools available out of the box.  Unfortunately, I don't think enough people are talking about them!  C'mon people, these are the types of things senior management loves -- and who signs checks??  Senior management! 

 For one of my clients we integrated Project Server's task lists with a MOSS Intranet -- they are both built on WSS so it wasn't too bad.  Then we used the KPI webparts to point to the task lists generated by Project Server.  Now my question is, what is everyone else doing with the KPIs and other BI tools? 

Ran across a post this morning that links to an article on CMS Wire entitled "One Collaboration Platform to Rule Them All?"
The article talks about the popularity of SharePoint and how more companies will be looking to do more with SharePoint in the future.  It is a great read and definitely worth a look -- just make sure you read all the way through to the last section entitled "Governance Becomes Key Definition for a Successful Implementation." 

 Technology is supposed to support an enterprise, not drive it. It’s an enabler. That means an organization should be carefully thinking about its business strategy and how its available resources assist that strategy. This is when IT pitches in and helps execs understand how a given technology can push the business strategy forward.
With this in mind, governance becomes the critical success factor in a SharePoint implementation plan. Whether it’s implemented at the department or enterprise level, as a collaboration or a content management platform; a governance plan must be in place to support the content stored in SharePoint.

One of the biggest points I try to drive home with the clients I work with is the value of proper planning.  This is true across many technologies, but its especially true for SharePoint implementations.  SharePoint allows companies to do many complex tasks quickly and easily -- this is a good thing!  But it can be a very bad thing if there's no master plan.  When properly implemented, SharePoint empowers users and makes everyone's life easier!
 

This morning, I logged on to check the latest blog posts on SharePointFeeds like I always do.  I decided to check out the latest post from Andrew Connell -- usually he's spitting hot fire, but this morning I was extremely disappointed.  His beloved Jacksonville Jaguars are facing off against my favorite team -- the FIVE time Super Bowl Champion Pittsburgh Steelers.  Andrew is so confident that his Jags can beat the Steelers away (twice in the same season, despite the fact the Steelers have a fantastic home field record) that he made the following comment:

I like this one so much, I'd really like to put a half-nickel if it wasn't for the wife watching me close this time of year. :)

I like your moxie, Andrew.  What do you say to a gentleman's bet?  No money -- but something to make it interesting?

Has it really been four months since I blogged about anything?  Wow.  Time sure does fly!  Its been a busy few months of SharePointing and thanks to a restful holiday I'm ready to kickoff the new year.  I'm going to start with a resolution:  Make at least one blog post per week.  So far I'm off to a great start.  Only 51 more posts. 

In all seriousness, 2008 is shaping up to be a great year.  I've got several posts I'm working on that come from my experience over the past few months.  There will be a little something for everyone from administrators to developers and even something special for you IT decision makers.  But wait, there's more!  In addition to the SharePoint content there will be a few other surprises in store.  Stay tuned.

 jr

If you're going to be in the Jacksonville area next weekend, the Jacksonville Developers User Group (JAXDUG) is hosting the Jacksonville Code Camp 2007 - a *free* full day of sessions (more than 50) from Microsoft Employees, Microsoft MVPs, National, Regional and Local speakers on a variety of topics, including:

• Visual Studio 2008
• Microsoft Silverlight
• WPF, WCF, WWF, LINQ
• SQL Server, SSIS, SSRS, SSAS
• WSS, MOSS, OBA

The SharePoint track looks especially great -- but I might be a little biased.  I'll be presenting a session highlighting the WCM features of SharePoint with demos about customizing Master Pages and the Content query Web Part.  You can't mention SharePoint in Jacksonville without talking about MVPs Andrew Connell and John Holliday who will also be there presenting.  The entire track is chock full of great presentations from great developers.

To register, go to https://www.clicktoattend.com/invitation.aspx?code=119680.

Someone once asked me how we upgrade code that has already been deployed.  It might sound like a simple question -- I thought it was.  Wrong! It was a fantastic question which surprisingly wasn't documented in many places.  It is possible to manually upgrade the files on each server -- but that can get quite tedious. In our case we had multiple web front ends so it was either manually update each file on every server (too complicated, and too many opportunities for mistakes) or use Solutions (automate the process of moving code to each of your WFEs).  The choice was a no brainer.

The answer to how you upgrade solutions lies in the following STSADM command:

stsadm -o upgradesolution -name <solution name> -filename <new solution name>....

Seems simple enough that the command upgradesolution would upgrade your solution.  There are two things to remember about this command:

1) The solution you are upgrading must have the same GUID as the original.
2) It only upgrades features and their related manifest files, as well as redeploys dlls and updates safe controls.

What it doesn't do is the most important part:

It doesn't update anything that is not referenced in a feature.xml, feature manifest, dll, or safe control.

In my case, I originally tried to include almost all functionality into my Site Definition.  It installed web parts, graphics, CSS, master pages, and templates.  The problem came when I tried to update something.  I wasn't able to update the files since everything was wrapped into the Site Definition.  Technically, ONET.XML is updated when you run upgradesolution - but it won't do any good for sites that are already deployed. 

Fixing the problem is simple -- keep only the bare minimum in your site definition and add as much functionality as possible through features.  To call a feature from the site definition you reference it by its GUID:

<SiteFeatures>
    <Feature ID="C85E5759-F323-4EFB-B548-443D2216EFB5" />
</SiteFeatures>

NOTE: When you create your feature, it is important to make it hidden if you plan to call it from your site definition.  If it is not hidden, SharePoint will throw an error saying it needs to be activated first. 

When you need to upgrade a solution you'd run the STSADM command listed above with the appropriate options.  As a best practice it is normally a good idea to activate any features in the solution using the force option:

stsadm -o activatefeature -name myFeature -force...

One final post script -- when deploying or upgrading to multiple WFEs it is important to use the -immediate option or specify a time.  Using the -local will only deploy to machine you are running the command from.  However, I ran into issues when upgrading some solutions where an error would be thrown.  Basically, the solutions would get deployed to some WFEs but not all.  Still have no idea why.  I did find a workaround that seemed to work most of the time.  I would first try to run the upgrade, it would throw the error and SharePoint would consider that the solution was no longer deployed.  Then, I'd run the same upgrade command without the -immediate tag which upgrades the solution offline.  Next I'd run the following command:

stsadm -o deploysolution -name <solution name> -local

This would deploy the solution to the server I was on without erroring.  Next I'd go into Central Admin > Operations > Solution Management and select the solution I was attempting to deploy and deploy it to the remaining WFEs. 

 Again, I'm not sure why this happened but I saw the same behavior in multiple environments.  I'd be interested to hear if anyone else has run into this.
 

My team just completed a large MOSS project and I thought now would be a great time to reflect back on the SharePoint implementation -- not to be confused with MOSS MVP John Holliday's SharePoint Reflections (of which I'm a big fan). 

The first big issue that we ran into is what I refer to as the Great MOSS Paradox.  This is the idea that Microsoft markets SharePoint 2007 to businesses as an easy to use product with a laundry list of easy to implement features.  On the surface, yes this is 100% true but it comes with a very big disclaimer.  Depending on how you use the product (Collaboration vs Publishing) different functionality is available.  The best example I can think of is blogs.  Yes, MOSS supports blogging functionality.  But if you create a new Site based on the Publishing Portal you no longer have the ability to select the blog template.  During the implementation of our project I was asked on numerous occasions "where did XYZ functionality go?"  The truth is there's a big difference between out of the box and a customized site.  For the uninitiated, it is a very tricky subject.  It is difficult for management to sell MOSS to clients and it is often difficult for the clients.  Which brings me to my next point....

Setting expectations.  We found that because of the information being communicated about MOSS that setting and managing expections was critical.  It is very easy to get wrapped up in complicated functionality that is very difficult to implement.  The learning curve with MOSS is steep and often doing the most simple tasks can take a long time.  Early on in our project we engaged MOSS MVP Andrew Connell to give us a two day primer on all things SharePoint.  One of the most valuable things we did was to design a proof of concept.  It helped us to understand all of the concepts we needed to master and along the way we learned where the biggest pain points would be.  Ultimately, we still found new pain points but it went a long way to helping us.  It helped to arm the team with the knowledge about how to estimate and gave us a punchlist of everything that needed to be completed. 

On a related note, the proof of concept also helped to reign in our expectations of what was technically feasible to be completed in the time frame we had available.  Which in turn allowed us to go back to the client and work with them to manage their expectations.  The "under promise over deliver" mantra can be a challenge -- but not impossible if you work to...

Keeping as much as you can "Out of the box."  Vincent Rothwell aka The Kid recently had a great post on this topic.  I won't rehash the post, but the main point is worth repeating: SharePoint offers a ton of functionality OOTB, but your time and effort curve increases dramatically the farther away from OOTB.  You can do a lot with a custom site definition, custom master pages, and smart use of the out of the box web parts.  Just remember that the typical development cycle for MOSS also includes Feature and Solution development so often OOTB functionality still requires some level of effort.

These three points really go hand in hand.  Gaining an understanding of the product is important so that expectations can be set properly and realistic estimates can be made.  I really enjoy working with MOSS, but it is important for everyone involved in the process to understand that although MOSS is .NET -- the development process is unique. 

In future posts on the Lessons learned from the real world I plan to discuss the technical gotchas we ran into as well as the challenge of getting more than a hundred non-technical content authors trained and entering content. 

Feel free to check out the site I've been referring to throughout my post:

Orange County Public Schools - http://www.ocps.net

Do you ever get that deja vu feeling?  I finally got around to setting this up again since the tragic outage.  I'll keep this short and sweet:

Who are you?

John Ross. 

Why should I read your blog?

My team just completed a very long and very large MOSS implementation.  We learned a lot along the way.  Worked with some of the top minds in the industry.  I plan to discuss many of the lessons learned we encountered when creating this mostly WCM implementation.  I've heard the comment "well, that's how it is supposed to work" uttered too many times.  Hopefully, I can help someone to avoid many of the issues we experienced. 

Stay tuned.  I've got more on the way.