I want to preface this post by declaring that SharePoint is not a difficult product to enhance, style or maintain. I believe this dilemma of styling versus maintaing has spawned in how the SharePoint product line has progressed over the last ten years. People are used to SharePoint being a quick and easy way to build solutions and they’ve come to expect this for every instance. This same discussion would be had if we were using Drupal, DotNet Nuke, or WordPress. Organizations not mature in their software development lifecycle (SDLC) experiences may also fall into these conversation more than those organizations with mature SDLC processes.

*   *   *   *   *   *

Administration

The first topic that upper management needs to understand is administration. Just like any system, the level of complexity requires a deeper level of support and knowledge to keep the system humming. If we’re talking about a system that services public customers or a large amount of internal customers then the expectations from the business for support will be higher. To offer a greater availability of support and knowledge you have to have a person who understands both SharePoint and the custom work that was done on the system. Also, if this is a high availability site with complex customizations or integrations then you should not rely on a vendor to support it.

Many times, companies will hire contractors on a retainer, but that doesn’t always mean that when disaster strikes that same contractor can leave what they’re doing and instantly tackle your problems. They may need to finish with the client they’re working with before they can assist. And let’s say they can’t make it for days or are on vacation. So, they pass it on to a colleague. With a highly complex site it isn’t feasible for that person to learn the system and then tackle the issue. That person may know  SharePoint, but they probably don’t know the custom solutions, timer jobs, content deployment and so on. That is why it is imperative to cross train on highly complex SharePoint sites.

Custom solutions and features can also be complex and not every SharePoint system administrator knows how to correctly handle these. A feature may have files located deep in the “x” hive and deploying a solution demands a person with a keen understanding of deploying features to the correct web application, site collection and site level. I won’t pretend that I know anything about styling or themes in SharePoint. I just received Professional SharePoint 2010 Branding and User Interface Design in the mail today to learn and understand more. What I do know from experience with highly styled and customized SharePoint 2010 sites is that the more sleek they are in terms of UI design, the more complicated they are to maintain, update, troubleshoot and deploy (more on deployment later). We now understand from 3 year of SharePoint 2007 experience and now with a 1-1/2 years under out belt with SharePoint 2010 that it is a massive system. We’re only starting to scratch the surface within of all the intricacies it possesses. It is far too much for one person to handle in a large organization, yet I see it all the time. Large deployments with one or no FTE set the organization up for failure as well as the IT group.

*   *   *   *   *   *

Enhancements

Alright, lets keep complex SharePoint sites in our forethought. When I mention complex, I mean page design beyond what SharePoint normally can accomplish with themes. I’m speaking of customizing the ribbon, the fuctionality of lists, dynamically driven content, etc. I’m talking about custom solutions deployed to a large farm that includes BCS or integrations to Data Warehouses, LOB’s such as a CRM or an ERP. www.ferrari.com, www.recovery.gov and www.chilis.com. Sites such as these have dedicated technical teams, both development and SharePro, that support these sites. When thinking about enhancements you need to take into consideration the audience of the site and the frequency in which enhancements will occur. For a public marketing site, you’re going to want it to be stylistic and carry the company brand throughout. I understand this point of view and encourage it. For 90% of all public marketing sites the frequency of features and functionality stays the same for 6 months or greater. Enhancements will come slowly and deployments less frequent. In this case, branding and custom solutions can make SharePoint sing and dance. It is still imperative to help the business understand the complexities that come with the highly styled and custom developed sites. Again, the same would be said to make Drupal or WordPress sing and dance. Development cycles are always going to increase with complexity and the time to deploy is also expanding. This either means that the site will be unavailable longer for deployment or you must invest in hardware and software to handle failover and redundancy. You can see how this is becoming more complex already. I have been involved in 20 minute deployments and I have been involved in 36 hour deployments. I prefer the 20 minute deployments. The business must be aware and understand that the investment in people and resources is greated depending on their thresholds.

But most frustration comes when the creative folks want to carry the same brand and and custom page layout from the public marketing site into the extranet, intranet/employee portal. This is where function should far outweigh form. Carrying through the company brand is essential and can be achieved on a more basic level. When you have a highly styled public site that does not necesarrily use page real estate the same way as you would if you were viewing large amounts of data (i.e. datasheet view) you have also interrupted the user experience in a negative way. When I want to see all of the columns in a list, but have two gray bars on each side of the page that together steal 150 pixels of screen real estate, then my user experience has been negatively affected. The frequency of enhancements to an internal facing site such as an employee portal will likely be more frequent so you want to bear this in mind when catering to the business needs. Custom solutions should be deployed when necessary but ease up on the custom UI.

What I am saying is that the styling and branding should not overrule the function. Solutions were meant to be built and deployed in SharePoint and with the proper planning and preparation these are painless. Keep in mind the intended usage of the site before you agree to make it sing and dance. If it’s an information working tool keep the branding and styling to a minimal. If it’s a brochureware site, make the user interface sing and dance. Branding and custom solutions both play a roll in the time to deploy enhancements and explaining this to the business is imperative. With custom work comes more quality assurance testing, more user acceptance testing and longer deployment times as well as the staff to sustain this system.

Migrations and Upgrades

In a highly complex SharePoint deployment, turn off Automatic Updates in your production environment! Some organization choose to turn it on in their QA sites or UAT sites since all solutions will be deployed through these environments first it is an easy way to find issues with custom developed solutions. As all IT Pros and developers know you’re going to have to do regression testing when these patches are released. If you’re using out of the box (OOB) SharePoint you can be less concerend about this since Microsoft does a nice QA job for you, but as soon as you introduce custom developed solutions you need to put some rigor behind upgrades and patches that vendors release. Whether it’s a update to the SAN where your SharePoint databases reside or Patch Tuesday in SharePoint deployments where there are custom solutions this is a must and it takes people. What about major releases of SharePoint? SharePoint “X” is right around the corner so take this into consideration when building those custom master pages and solutions. You want to minimize the pain in 3 years whenit’s time to upgrade. Inform upper management that the more you customize it is the more it will cost to upgrade/migrate.

So, what happens if upper management doesn’t listen and forges on? I’ll address that in Creative Balance Part III.

http://support.microsoft.com/kb/981223

There is no plug in or feature to deploy in SharePoint. This is a SQL Server Reporting Services plug-in so the footprint in minor and the results have large implications. Cost is broken up by features, the number of developers that will need to license it and the number of servers you plan installing it on. For all intensive purposes, the Standard Edition should get most organizations what they need for $3,000 and that includes maintenance.

After the reports are built, users can either access Reporting Services to run the report or you can publish them to a document library. None of the SSRS features are removed. I’ve found that most of the limitations I run into are when users want a view of the data to analyze the data, not when they want to do data entry. This tool allows you to create reports with the data your customer needs and still take advantage of the SQL Services Reporting Server features so you can even style the reports and “dress” them up.

The support is pretty good, but you’ll have to get used to French accents.

www.enesyssoftware.com.

Three months later, that customer comes back and wants to know if she could setup an approval workflow for a tasklist on her teamsite. “Sure” you say. “No problem!” And a day later your customer is being productive with that new feature.

Your customer is now creating her own lists and getting some functionality out of lists that you believed an end user would never be able to do. Now, that same customer comes to you a year later with another project. This time she wants a new site and she is going to use this site to publish content to the rest of the company. You’ve now crossed over to publishing. And because we’re going to be sharing this with 4,000 people we better dress it up. Over the years, you’ve come to fear this phrase when it’s used in conjunction with the word SharePoint. I’m a system admin you say? I don’t know anything about “dressing up.” I wear 15 year old jeans to work every day along with this flannel shirt my mother got me in 10th grade. Don’t make fun, it’s very comfortable. I’m proud I can fit into these jeans from 15 years ago. What do you do when your customer says, I want to “dress it up”?

Your first reaction is to say, “No!” because you don’t understand that side of SharePoint to give a straight answer. You haven’t even heard what the customer means when she says, “dress it up?” Maybe it’s just colors and you can achieve this in the Look and Feel section of the Site Settings. I know this happens because it’s my knee jerk reaction as well.

What happens when your marketing group wants to get involved with your intranet and customize SharePoint beyond themes? They want custom navigation and those discussion boards that SharePoint provides just are pretty. Lets dress those up too. This is where I get squeamish. Not in all cases do I get squeamish. This gut wrenching feeling comes for me when it’s sites that have fast release cycles from many user advocates. If your using SharePoint for your public marketing site, go bananas. DRESS IT UP! Customize those discussion boards and bring in that third party navigation because I know that he release cycles will be few and far between and I only have one customer tugging at my coat sleeves for enhancements.

But, with your intranet,  your servicing many customers and are receiving many requests from different business units. You also want to keep the same navigation across all the sites and the same user experience. Don’t get me wrong, I think the user experience is huge and should be consistent. But, we’re talking about making productivity tools and sharing information across business units. I doesn’t have to have custom navigation and sleek discussion boards unless…it gives you a unique competitive advantage.

So, here is the conclusion. 90% of your internal customers needs can be met with out of the box SharePoint look and feel. 80% of your customer’s needs can be met with out of the box SharePoint functionality. That is, without busting out Visual Studio. Sure, you can use SharePoint Designer and build custom workflows. That’s out of the box.

Any time you deploy features that have custom code such as navigation or altering the way SharePoint functionality works out of the box you increase deployment times, user acceptance, quality assurance. This compounds when you have 10 business units tugging at your coat sleeves for new projects and want custom solutions. Guess what, you’ve got to do regression testing so you don’t break everyone else’s customizations. The beat goes on and on from here.

My next post will assert how you get your customers to understand this in laymen’s terms.

NHA OLE at the SharePoint Users Group for Educators

http://www.andrewconnell.com/blog/archive/2010/03/27/introducing-the-sharepoint-site-collection-keep-alive-job.aspx

We have three site collections created, two of them give us an error when arriving at the default.aspx page. The third site collection is highly customized but it still works fine. The other two sites are out of the box Publishing site templates.

I can think of something that would have beneficial as part of the early adopter program and that would have been to know the other companies that were part of the program and how we can connect with them to share ideas and warn them of these types of incidents. I am trying to connect with Dan Holme to see if he’s encountered this with the Olympics site that he did in Beta 2. If anyone is aware of a reg hack or something that will fix this let me know. When I find out I will post the fix.

Believe it or not, there is not much difference in the HTML editor in SharePoint 2010 Beta 2. It seems like one of the easiest areas of improvement for Microsoft especially since you’re copying from their Office suite. Even copying from Office 2010 does not rid you of this problem. I listed my 3 major pains with the HTML editor in SharePoint 2010 Beta 2:

1. Copying text directly from Office 2007 or Office 2010 Beta 2 into the HTML editor or Content Editor Web Part produces…well, there is no one thing it may produce. I’ve seen unbolded text turn to bolded. I’ve seen white backgrounds turn to orange.
2. Changing the style of your text. The content on some pages may be longer than others. SharePoint 2010 uses the new Office Ribbon which is a really neat feature and offers many more features than the previous editor. The problem lies when your text forces you to scroll down the page further you lose sight of the Office Ribbon. Let’s say you have a line of text that you want to change the style on. You scroll down to view and highlight the text and then scroll back up to make a style change to that text. Because the Office Ribbon does the previewing of the format on the fly, just like Office 2007, it automatically moves your window down to the text you highlighted to show you the change. Before it scrolls you down to that section in the page you haven’t had a chance to click on the style you wanted to see and you end up with a style you did not want to see. This make any editing to text that is lower on the page impossible. The obvious fix is to have a floating Office Ribbon that moves down the page.
3. Table creation and editing – all text in a table is bolded by default. You have to go into the HTML and edit the formatting for the table.

What I’m saying is that the HTML editor in SharePoint 2010 Beta 2 is unpredictable at best. It’s not WordPress. If you’re thinking about giving this to a business user your kidding yourself. This particular project relies upon content from our executive staff. At no point would I ever expect them to take the time it took me to format the content in the HTML editor. Microsoft has to get this fixed before RTM.

The Release Candidate was announce last week, but I have not had time to get it installed and play with it. If RC is out then RTM cannot be far behind.

1. Go to Site Settings.
2. Click on Site Permissions under Users and Permissions.
3. Click Check Permissions
4. 
5. Enter the name or account of the person, seurity group or distribution list that you want to check
6. 
7. Click Check Now.
8. You can see where this person/distribution list/security group has permissions on your site and at what level. It will also show you what lists that entity has permissions to and what level. Another very cool feature to note is that it will check for a name within a distribution list and/or security group. For example, if you are trying to find out if Jim Smith has permissions to your site it will check for Jim Smith in any security group or distribution list that have been assigned to your site or a list within your site.
9. The other great feature as it relates to security is the ability to see what content within your site is breaking inheritance. You can do this by clicking on the Show me uniquely secured content link.
10. 
11. The screen you will be presented will show the lists and libraries on that site that are breaking inheritance. Unfortunately, it does not show you here what people or permissions are on this list. It is up to you to go to each of the libraries or lists and manage the permissions. None the less, a very helpful and needed feature.
12.