The SharePoint Hillbilly

Application deployment in SharePoint is a broad topic with many options. It is extremely important to set standards in your organization for application deployment in SharePoint that are straightforward and reproducible in order to make deployment successful and repeatable. A proper deployment also lends itself to ease of maintenance of deployed applications. After giving the issue a lot of thought, research, and talking to people who know more than me, I decided to detail recommended strategies for deploying various applications into a production SharePoint environment.

So, why bother?

The objective for setting forth deployment standards in your organization is to provide guidance to developers and administrators and set expectations about SharePoint Deployment. Some Key objectives:

• · Set realistic expectations - SharePoint application deployment is never a one-step process. You can’t just copy files over and be done with it.
• · Document the process – Because multiple steps are involved in a SharePoint deployment it is important to document the deployment steps in a way that is understandable to both developers and administrators.
• · Package where possible – Part of a successful and repeatable deployment strategy is to create packages where possible that can be deployed instead of manually creating items as part of the deployment process.
• · Improve upon the process – As your organization becomes more adept at SharePoint application deployment you will be able to streamline the process allowing deployments to take place in fewer steps.

What steps might I take during a deployment?

There are multiple steps that may or may not take place when deploying an application in SharePoint. The following table details many of the various steps.

There are many options when it comes to SharePoint Application Deployment. Unfortunately, many of the options are not great and end up being “Developing in Production”.

The most common SharePoint Deployment strategies involve using SharePoint Designer and publishing SharePoint sites with SharePoint Designer. This may work fine for smaller implementations and indeed seems ideal for an initial deployment, however many problems emerge when maintenance has to be done on an application deployed using SharePoint Designer. Among these problems:

• · Any sort of republish of a site with SPD overwrites list data
• · Modifications have to either be done in production or on a copy of the site.
• · If changes are made on a copy of the site, newer data will be lost when the changes are republished.
• · SPD Workflows cannot easily be modified in Development environment and individually redeployed.
• · Using SPD to maintain pages breaks SharePoint’s “ghosting” feature.
• · Using SPD on a production server is equivalent to “developing in production” and can bring down a site if a mistake is made.

So, how should your organization handle SharePoint Application Deployments? A recent conversation with a SharePoint guru indicated that if 50% of your application deployment was made up of deployable packages then you would be ahead of 90% of the companies using SharePoint. I think 50% is an achievable goal and most organizations should endeavor to reach it.

An ideal SharePoint deployment would be 100% deployable packages and the only steps a SharePoint administrator would have to do are:

1. 1. Deploy Features
2. 2. Create Site
3. 3. Configure Security

Although ideal, this option is generally not realistic with the maturity of the SharePoint team of most organizations and in some cases is overkill (i.e. if it would take much longer to create everything as deployable packages than to just put the parts together manually). As SharePoint developers gain more experience and develop a set of internal templates they use daily, this ideal scenario becomes more plausible.

Deployment Types with Sample Deployment Scripts:

When creating deployment scripts for your SharePoint application it is important to note that not every deployment script will be the same. Steps in a deployment script can vary widely based upon a number of factors. It is not realistic to attempt to create one deployment script template that will be the basis for all deployments. Things that can affect deployment scripts:

• · Logical placement of application in production
• · Size of application
• · Customization level of application
• · Number and types of features to deploy
• · Security (AD, FBA, Anonymous, etc)

That being said, deployment scripts can be expected to fall into one of three main types. These types are described in detail below.

No Custom Development or No Template Deployments

Some sites may have no customizations, templates, or deployable packages. This means that all of the functionality for the deployed sites would need to be re-created in the production environment. Although at first glance this may seem pretty severe, it is the most common SharePoint Deployment strategy and builds upon one of the Strengths of SharePoint (rapid application development and deployment). Problems arise, however, when these applications must be modified or maintained. All changes have to be done in production or on a backup of the site which can cause data to be lost when the backup is restored into production. Again, maintenance may not be an issue for more simple sites as changes may also be kept simple. SharePoint Designer Deployments also fall into this category. Reasons for having no custom development or templates include:

• · Lack of experience of development team (don’t know how to create package “x”)
• · Time to create deployable packages is much greater than just building the site with a good deployment script
• · Site is based upon an existing template already in production (i.e. Team Site)
• · Site was designed and developed in SharePoint Designer

Below is an example Deployment Script for a site with no custom development or templates.

Mixed Deployments

A “mixed” deployment script contains non-customized items and customized deployable packages. At first glance the no custom deployment process may seem more desirable; however with this deployment script you get the advantage of maintainability around your workflows. The workflows deployed in the following script may be modified and redeployed to the site without affecting the rest of the site. This gets us closer to our goal of having all modifications occur in a development environment, tested in a QA environment, and then deployed in production. The reasons for a “mixed” deployment:

• · Lack of experience of development team (don’t know how to create package “x”)
• · Time to create deployable packages is much greater than just building the site with a good deployment script
• · Site is based upon an existing template already in production (i.e. Team Site)
• · Site was designed and developed in SharePoint Designer

The following steps are approximate steps that would need to take place to deploy the same application as the previous script using a mixed deployment scenario.

Custom Development Deployments

In an ideal world every aspect of deploying a site would be done with packages. The packages would be deployed to an appropriate location and the site created. As stated earlier, if you get 50% of your deployment to be packages you are ahead of 90% of the companies out there, so having deployments that are entirely package based may not be attainable, but should be strived for none the less.

Below is a deployment script for the same application deployed in the previous scripts but is entirely made up of packages. Steps 1,2, and 3 are the main difference between the previous script. The Site Definition will be created as a deployable package adding another level of maintainability from previous deployment script.

Caveat

One important note when creating deployable packages.  You’ll notice in that last script that the workflows were still separate packages to be deployed and not part of the same feature as the site definition.  This is important from a maintenance standpoint.  If you stick everything in one package it makes incremental updates on each web part, work flow, etc… more cumbersome.  So, don’t stick everything in one feature.  Make them dependent features instead.  You’ll thank me later.

Some important things to have in place before you begin

So, you are about to go and set up your deployment standards for your organization.  Here are a couple of things you need to have in place first:

• · A well defined taxonomy needs to be in place before rigid deployment standards are enforced
• · A back-out strategy in case an application needs to be un-deployed
• · A maintenance strategy for future modifications to application
• · Whoever is deploying the applications into production needs to be competent in SharePoint’s ins and outs and should not need handholding.

Also, some things you need to decide internally within your organization:

• · What is the threshold for creating a package versus manually creating objects in SharePoint?
• · What person / group is responsible for deploying applications?

Conclusion

These scripts are not meant to be the end of the conversation.  They can be improved upon for even more automation.  This is just to help get you started and help you understand what application deployment means in SharePoint.  Hopefully you learned something you didn’t know or maybe even had an “ah-ha!” moment.

Are you currently implementing SharePoint?  Have you implemented SharePoint and now you are pulling your hair out?  Did you hire someone to stand up your farm, now they are gone, and you have no clue what to do?  Are you generally lost and cursing SharePoint with every other breath?  Does your boss not get SharePoint?  Are you a boss and don’t get it?  Are you looking at spending thousands of dollars on training just to be able to use SharePoint?  If you are Jerry Seinfeld, is SharePoint your Newman? 

Congratulations!  You are now part of an ever growing community!  Whether you know it or not, thousands upon thousands of people are struggling with the exact same problems you are.  They are hating SharePoint and don’t know exactly where to turn.  Until you are knee deep in SharePoint and ruing the day it was created you really can’t quite comprehend what an absolute beast SharePoint is.  This thing is a monster and it will eat you alive if you are not prepared.  A good way to understand that SharePoint is a massive beast is to ask the question “What is SharePoint?”.  The correct answer is “What do you want it to be?”.  Most people don’t realize that NO ONE is an expert on every facet of SharePoint.  I don’t think it’s humanly possible.  I’ve met a few geniuses who come close, but even they have people they rely on for some aspects of SharePoint (I’ll refrain from naming names so as not to grow any egos, but you know who you are). 

Think about it, you have SharePoint Administrators who are in charge of  maintaining the farms from day to day.  SharePoint Developers who sweat blood to develop solutions to cleanly integrate into your business systems and make everything seamless.  SharePoint Architects help you structure everything and decide where it goes so that everything doesn’t implode on you in a couple of years. Branding experts know how to wrestle with themes, navigation, and style sheets to make SharePoint “not look like SharePoint”, and trainers who teach your End Users how to use SharePoint.  You’ll have SQL admins responsible for the health and back up of the SQL Servers on your farms.  You SHOULD have a SharePoint Governance Committee so people are not haphazardly creating garbage all over your farm. You may even have a SharePoint Search admin who’s sole purpose is to make sure your SharePoint Search is configured properly and performing well.  In some companies you need 2 or 3 of each of these guys!  Have you priced a talented SharePoint person lately?  They aren’t cheap.  You definitely get what you pay for.

Are you starting to get an inkling for how ginormous SharePoint is? Are you?  ARE YOU???

So, what do you do? What hope do you have?  Well, you have a couple of options!  Let’s look at those, shall we?

Training

If you are lucky enough to have spare money lying around then training is always an option.  When I started with SharePoint in November of 2007 training was really not up to par yet and we had a couple of bad experiences.  However, that has changed in the past year and there is some really great training out there.  I can personally recommend Critical Path Training (Formerly Ted Pattison Group).  These guys know their stuff, and the lab manual you get out of it is almost worth the cost of the course.  AC is one of those aforementioned geniuses.

The one issue I have with organized training is they don’t always equip you for when SharePoint doesn’t do what it’s supposed to do (which seems to be A LOT of the time).  I swear if I had a dollar for every time I saw a page that said “Unknown Error” I would be lounging on a beach somewhere.  GREAT error messages Microsoft!

Books

There are SO many SharePoint books that it’s an obvious first step to learning SharePoint.  Just look at SOME of the books I’m giving away at SharePoint Saturday Ozarks on July 18th, and these only scratch the service!

The downside with books is that you have to read and read and read.  Also, you can’t ask questions as you go.  So, if you get lost, you are lost. 

The SharePoint Community

Ahhh.. this gets me to the point of this blog.  The SharePoint Community:  if you are not involved then you are wasting valuable time and money.  There is this large group of people who know where you are, know where you are going, and know where you SHOULD go and they are more than happy to help.  I have not seen anything quite like it before.  It’s very much like a support group.  “Hello, I’m Mark, and I work with SharePoint.”  If you have a gripe, someone else has griped about it.  If you have an issue you can’t resolve and you can’t find the magic google word combination to find the answer, someone in the SharePoint community knows the answer.  You can either spend weeks and weeks on a problem or you can get involved in the SharePoint Community and find the answer in minutes. 

I personally struggled in my organization searching for answers on how to do the most basic things in SharePoint for almost an entire year.  I bought books, attended HORRIBLE training, searched online, and pretty much understood what deep depression was all about.  It was my job to implement SharePoint and I could find no clear path.  This started in November of 2007.  Then, in October of 2008 I attended the SharePoint Track at the Tulsa TechFest.  The knowledge I gained in those two days by far outweighed everything I had learned in the previous year.  The people I met are worth their weight in gold, and I finally started to understand SharePoint.  AND IT WAS ALL FREE!!!  Okay, I had to pay for my meals and hotel, but other than that it was free.  I have since built on those relationships and have an extensive SharePoint network that has led to my company hiring a very talented SharePoint Administrator (@lorigowin) and connected me with SharePoint experts all over the world.  When I have a problem and can’t find the answer, I easily reach out to this network and find answers in less than an hour.  Do you realize what that’s worth?  You absolutely cannot put a price on the friendships and connections I have made in the SharePoint Community.  Why do they do this?  Why do they help?  Well, there are several reasons.  These people are passionate about SharePoint and truly “evangelize” the product.  Also, they have been where you are and would not wish the pain they went through on their worst enemy.  The very fact such a network of tremendous individuals exists and is so helpful is a testament to how massive and daunting SharePoint is.

So, how do I get involved in the SharePoint Community?

It’s actually quite easy to get involved in the SharePoint Community and as I say over and over these guys are the most helpful people in the world.

Twitter

Start following SharePoint people on Twitter.  Look at who I’m following as a good start: @mrackley.  Watch what these guys are posting and you’ll get the latest news on SharePoint.  You’ll find out when patches and Service Packs are being released as well as any issues that arise with these patches and Service Packs before most people.  In some cases, you’ll learn things about SharePoint before Microsoft wants you to know them.  :)   Also, these guys are really helpful when you have a problem you can’t solve.  Don’t be a leech though, if you see someone struggling with a problem you had, help them out!  It will be appreciated and noticed.

Attend an Event

There are A LOT of free events out there.  Check to see if there is a SharePoint Saturday near you. These events are totally free and the knowledge you gain from attending and the worth of the contacts you meet there cannot be calculated.  Yes, these events are free.  No, it’s not a sneaky way to sell you something.  As I stated earlier I’m organizing a local SharePoint Saturday event on July 18th (SharePoint Saturday Ozarks), and I called some people I knew were just starting with SharePoint and they told me “We are not looking for training right now.”   I wanted to reach through the phone and slap the person a couple of times.  These events are a phenomenal way for you learn things you would not otherwise have the chance to learn.  It’s a chance to meet people who truly know SharePoint and will be more than happy to help you after the fact.  AND IT IS FREE!  If you are within driving distance to one of these events and you are not attending then you are making a huge mistake.  If I could slap you right now I would!  It’s asinine.  These are not Amway conventions.  People are not trying to get you to spend money.  They are sharing their knowledge in an effort to help you.  How can you turn that down?  There are many other great events other than SharePoint Saturdays as well.  Check out Microsoft Events and see if there are any events in your area.  It’s not an option.  Do it.  If you don’t, you deserve your fate.  Can I be more clear?

Create a Blog

When you start to get a little knowledge, give back.  Start a blog and share your experiences.  It earns you some street cred with the SharePoint gurus and gives you a great reference for when you run into the problem again.  You can’t be an island in SharePoint.  Give back.  Even if you think it’s something small, you might be amazed at the results.  My second blog I ever wrote was about some random thing I figured out and found a little useful.  To this date it is my most popular and commented on blog, and I just wrote it as an aside!  You never know what someone else may find invaluable! 

Adamant Conclusion

If you want to be successful in SharePoint it is really not an option.  Get involved, go to events, help where you can, and enjoy the camaraderie.  You will save time, you will save money, and you will get the most out of your SharePoint experience.  Plus, you will meet the most freaking awesome people in the world.  Including me.  :)

How’s that for a long blog title?  Well, by far my most popular blog post has been about creating a Parent / Child relationship in SharePoint Designer and one question keeps getting asked over and over again: “How do I pass multiple values to the new item screen for the Child?”  So, I thought it was about time I actually told you how.  :)  Are you ready?

As stated before, this blog is a direct continuation of a previous blog post Creating a SharePoint List Parent / Child Relationship - Out of the Box.  So, if you think you are lost, follow the steps on that blog post first, then come back.

First thing we need to do is break down what we are going to do into its parts and then tackle one at a time.  We are going to do the following:

1. 1) Make the default Web Part invisible (in case you are modifying your DispForm.aspx file).
2. 2) Drop new DataFormWebPart for parent on DispForm.aspx page
3. 3) Set up a data connection to create a parameter on the Child Web Part that has the same value as the parameter on the Parent
4. 4) Pass this parameter in the Query String to “NewForm.aspx” of the Child
5. Maybe one of you geniuses out there know how to do this in fewer steps?

Step 1: Make default Web Part Invisible on Parent DispForm.aspx

If you are doing your work in the default DispForm.aspx of the parent (Issue from previous blog) then it is necessary to make the default web part on the page invisible.  DO NOT delete the default web part.  This will break your list views and you will not be able to get them back. 

You actually should not be making the changes to the default DispForm.aspx page, you should create a new Display page and then associate this page as the Display Form for your list.  How do you do this?  Wow, you ask a lot of questions.  Okay.. Quickly:

1. 1) Create new display page:  File->New->Page->List View Pages 
2. 2) Right click on your List and select “Properties”
3. 
4. 3) Click on the “Supporting Files” tab
5. 
6. 4) Click on the “Browse” button next to the “Display item form” box and point it to your previously created form.

*one caveat* I have had very limited success re-associating forms this way.  It is SUPPOSED to work fine.  Unfortunately, just because something in SharePoint is supposed to work, doesn’t mean it will.

So, I’m going to assume that you are modifying the default DispForm.aspx and we need to make the default Web Part invisible.  We are doing this so we can add a DataFormWebPart for the Parent (Issue) on the page and set up a data connection between the child and parent. This data connection cannot be set up on the default DataFormWebPart. 

In order to make the default Web Part Invisible follow these steps:

1. 1) Search for the string “<IsVisible>true</IsVisible>” in DispForm.aspx of the Parent (Issue).
2. 2) Replace “true” with “false”
3. 3) Save the file

How painless was that?  View the page now in SharePoint, you will see that there is no data displayed for the parent item.  On to our next step.

Step 2. Drop new DataFormWebPart on page for Parent (Issue)

We now need to drop a new DataFormWebPart on the page for the Parent (Issue) Web Part.  If you are asking yourself, WHY do I keep putting “(Issue)” after the word “parent”, then you obviously didn’t read my previous post.  The parent list in the previous blog was for storing Issues.  Got it?  Can I stop saying (Issue) now?  okay.. thank you.

So, to drop the new DataFormWebPart follow these steps:

1. 1) In the DispForm page of your Parent list, place your cursor after the “<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">“ line in the aspx page (this is where we are going to put our new Web Part).
2. 2) Click on “Insert->SharePoint Controls->Custom List Form”
3. 
4. 3) Make sure you have your parent list specified, click the “Display item form” radio button, then click “OK”
5. 

You will now see the display form for your parent on the page.  You will notice that this display form differs from the default web part.  You have a lot more control from here, you can even go in and modify the look and feel of the Display Form using standard html to make it look nicer.  Have fun with that, I’m not responsible for what you break.

Step 3. Set up a data connection to create a parameters on the Child Web Part that have values from parent

Okay, so now, let’s get the data from the parent into a parameter that the child can see.

The following steps are necessary to create a parameter on the Child List for the “Status” field in the parent.

1. 1) Go to the Common View Data Tasks for the Child List on the Parent DispForm.aspx page
2. 
3. 2) Click “Web Part Connections”
4. 
5. 3) Select “Get Parameters Form”
6. 
7. 4) Make sure “Connect to a Web Part on this page” is selected and click Next
8. 5) The Target Web Part should be your Parent List, action should be “Send Row of Data To”.  click Next
9. 
10. 6) Click on “<Create a new parameter>”
11. 
12. 7) Give the Parameter a name and then click OK (I used “ParentStatus”)
13. 
14. 8) Select the field in the Parent List to associate with the Parameter name you specified
15.  
16. You can repeat steps 6 – 8 to create more parameters if you’d like.
17. 9) Click Next
18. 10) Just click Next on the next screen
19. 
20. 11) Click Finish!
21. 

*phew* If you think that too you a while to do, think who long it too ME to capture all the screens and type it in.  :)  So, still with me?  Good!  We now have parameters created in our child list that we can pass as Query String variables.  On to the next step!!!

Step 4. Pass this parameter in the Query String to “NewForm.aspx” of the Child

We now need to modify the URL used to go to the “NewForm.aspx” page of the child so that it passes the parameter as a query string variable.  Just follow these easy steps:

1. 1) Go to the link in your code.
2. If you are going off the previous blog, find this line:
3. <a href="../Time/NewForm.aspx?IssueID={$IssueID}" onclick="javascript:this.href = unescapeProperly(escape(this.href)); GoToLink(this); return false;" target="_self">Create a new Time Log Entry...</a>
4. 2) Add the parameter as a Query String variable.
5. Now add “&amp;Status={$ParentStatus}” to the previous line as follows:
6. <a href="../Time/NewForm.aspx?IssueID={$IssueID}&amp;Status={$ParentStatus}" onclick="javascript:this.href = unescapeProperly(escape(this.href)); GoToLink(this); return false;" target="_self" class="ms-alignleft">Create a new Time Log Entry...</a>
7. 3) Save your file.

That’s it!  Now when you click on the link to create a new child entry it will pass both the ID of the parent and the status of the parent.  Just be sure to add JavaScript to the NewForm.aspx of the child to set the status field in much the same was as you did to set the ID field.

So, there you have it.  Add as many query string variables as you like.  Hope this answers all the previous questions, if not.  What did I forget?  Again, thanks for reading my blog.  Hope you learned something useful.