Jul09

Lessons Learned Part II -- Upgrading Code That Has Been Deployed

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.

Published: Jul-09-07 | 0 Comments | 0 Links to this post

Jul06

Lessons learned from a real world implementation - Part I

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

Published: Jul-06-07 | 0 Comments | 46 Links to this post

Jul05

Hello World v2

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.

Published: Jul-05-07 | 0 Comments | 0 Links to this post