Warning: Upgrading to SharePoint Designer 2010? Beware!

I just installed upgraded my Office install from Office 2007 to the 64-bit (x64)version Office 2010. I had to completely remove my Office 2007 applications including SharePoint Designer 2007, because no Office 2007 applications can coexist with any 64-bit Office 2010 application.

“That’s OK,” I thought; “who wants the old stuff when I can have the shiny new stuff?”

I fired up SharePoint Designer 2010, eager to do some edits to our SharePoint 2007. That’s when I was greeted with this lovely error:

“Microsoft SharePoint Designer cannot be used to edit web sites on servers prior to Microsoft SharePoint Server 2010.  To edit these sites, you need to use SharePoint Designer 2007.”

I can’t use SharePoint Designer 2010 with my SharePoint 2007 site nor with my customers’ SharePoint 2007 sites? Really? I hope that whoever at Microsoft made the decision that SharePoint Designer 2010 would not support SharePoint 2007 sites was able to find another job after he/she was unceremoniously fired! Could you imagine if Word 2010 could not open Word 2007 or Word 2003 files? Ridiculous.

Ok, so I can’t use SharePoint Designer 2010 to edit my SharePoint 2007 sites and I can’t install SharePoint Designer 2007 on my computer. What’s the answer? Virtualization. I’m spinning up a virtual machine that will host an instance of Office 2007, as well as a few other apps.

Read more about Office 2010.

Documentum vs SharePoint

I was looking for some info on how SharePoint stacked up against Documentum, and came upon Johnny Gee’s article titled Documentum vs SharePoint – Round 2. First I wanted to thank Johnny for a great post and Eric Crone (of ForeFront Partners LLC) for a good comment that greatly expanded the post. I learned a lot about Documentum’s eRoom. However, I saw a few things that were not quite accurate from the SharePoint perspective. This post is my response to some of the points in Johnny’s article and Eric’s comment…

 

From Johnny Gee’s article:

“Sharepoint (like eRoom) is great for collaboration.  However, once collaboration is done, the information and documents stored in Sharepoint site are siloed from the rest of the enterprise.”

My response:

SharePoint sites are not siloed from the rest of the enterprise. SharePoint has a set of rich, remotable APIs, including SOAP Web services and WebDAV, that allows the rest of the enterprise to interact with SharePoint content. Among other things, SharePoint’s records management API allows an organization to natively use an external records repository with SharePoint, if the organization does not like SharePoint records functionality (now DoD 5015.2 certified).

 

From Johnny Gee’s article:

“Since these Sharepoint sites are disconnected from the enterprise, there is no OOTB way to have users interact in enterprise business process.  This includes applying corporate retention policies on content.  Another problem with Sharepoint architecture is the reliance of storage of content in SQL Server.  This prevents the moving/archiving Sharepoint sites to 2nd tier (lower cost) storage.”

My response:

SharePoint data can indeed be spread over multiple storage tiers. A SharePoint farm can use any number of SQL Server databases managed by any number of SQL Servers. Administrators have very fine grained control over which database (and storage tier) a SharePoint site collection uses for its content store. This not only allows use of cheaper storage when appropriate, but also allows SharePoint’s storage tier to scale very nicely.

 

From Eric Crone’s comment:

“Johnny, one of the biggest issues that SharePoint has is administration. I’ve had companies come to us and tell me that they are spending 10 hours a day keeping SharePoint up and running. When you look at eRoom and have customers who have installed it a year ago and don’t have to log into the server again in that period of time, that says alot.”

My response:

SharePoint administration is on par with other enterprise-class server software. Most of my customers do maintenance every few months. As with any server software, excessive maintenance requirements is usually a sign of poor planning or improper initial install and configuration. As they say: an ounce of prevention is worth a pound of cure. This has been true of all server-class product with which I’ve dealt, not just SharePoint.

 

From Eric Crone’s comment:

“Some additional key points for eRoom is the ease of extending and building the eRooms by nontechnical business users. A manager can build her own tracking system for just about anything, such as correspondence, without IT involvement. Try doing that with SharePoint.“

My response:

SharePoint is a very good tool for organizations who want to enable their end-users to build their own tools without IT involvement. That’s why more and more organizations are purchasing SharePoint. I am continuously impressed with the types of solutions non-technical users are able to create with SharePoint.

 

From Eric Crone’s comment:

“Inboxes also don’t exist with SharePoint. But with eRoom, you can add an “inbox” to a room and then start emailing that project, program or business process as you would any member ofthe team. Then, all the related emails to the proejct are in your eRoom, within the context of what you are working on. Stored alongside files, structured and unstructured data.”

My response:

SharePoint does have inboxes. They are called “email-enabled lists” and “email-enabled document libraries”.

 

From Eric Crone’s comment:

“In SharePoint, you cannot “nest” containers. In eRoom, we can have a folder inside the room. A calendar inside the folder. An event inside the calendar. Another folder inside the event. A database inside the folder. A file attached to a database row inside the database. eRoom will truly go where you need it to go.”

My response:

You can nest containers in SharePoint. Sites can have sub sites. Folders can have sub folders. Events and documents can be promoted to workspace sites that can contain other lists, libraries, and sites. I’ve even created a free tool called List Item Workspaces which will let users easily promote any SharePoint list item to a workspace, like tasks, issues, contacts, etc.

 

From Eric Crone’s comment:

“Then, there’s the customization side of things. If you can dream it, we can do it as an extension/add-on to eRoom. The API is rich, stable and reliable. As I said, we’re at version 7.3. We’ve built add-ons for numerous purposes including a custom command that will convert the contents of a database row into a fillable PDF form template and uploaded to the attachment area of the database row. We’ve built custom single sign on. We’ve built “relational” databases within eRoom.”

My response:

Microsoft supports 3 levels of user technical capability with SharePoint:

1. Non-technical – These users can do a great deal with SharePoint’s web user interface, including creating sites, lists, libraries, and customizing pages using web parts (the .Net equivalent to portlets)
2. Semi-technical – These users can do even more with SharePoint Designer (a free tool from Microsoft). SharePoint Designer allows semi-technical users to create custom page templates, do graphical database and web service queries, and even create workflows using a wizard interface
3. Technical – These users can do just about anything they can imagine with Visual Studio and the .Net Framework. I know several organizations that have created automated Word and PDF systems similar to Eric’s description using SharePoint. I built one.

Technorati Tags: SharePoint,WSS,MOSS 2007,Documentum,SharePoint Foundation

Visual Studio 2010 Beta 2 has new SharePoint 2010 development tools

Download the Visual Studio 2010 beta and check out the SharePoint 2010 walkthroughs and how to’s here:

http://msdn.microsoft.com/en-us/vstudio/dd441784.aspx

 

Walkthroughs

• Add Feature Event Receivers
• Create a Custom Field, Content Type, List Definition, and List Instance
• Create a Site Definition Project
• Import a SharePoint Designer Reusable Workflow into Visual Studio 2010
• Import Items from an Existing SharePoint Site
• Creating a Web Part for SharePoint
• Creating a Web Part for SharePoint by Using a Designer
• Create a Custom Site Workflow Activity
• Creating a Workflow with Association and Initiation Forms
• Creating and Debugging a SharePoint Workflow Solution
• Add an Application Page to a Workflow
• Creating an Application Page
• Creating an External List in SharePoint List by Using Business Data
• Deploying a Project Task List Definition

How To…

• Add and Remove Features to a Package by Using the Package Designer
• Add or Remove SharePoint Connections
• Create a BDC Model
• Create an Event Receiver
• Customize a SharePoint Feature

 

The Catch

What’s the catch? The SharePoint development tools included in Visual Studio 2010 are exclusively for SharePoint 2010.  What can you use to accelerate your SharePoint 2007 development today? Check out WSPBuilder. WSPBuilder is an open-source tool and add-in for Visual Studio 2008 that not only automates a lot of the manual tasks of creating a SharePoint solution package (WSP file), but also comes with lots of Visual Studio templates for SharePoint artifacts, like web parts, features, content types, etc…. There’s a great WSPBuilder walkthrough by Tobias Zimmergren here.

Then. look at SharePoint Solution Installer. SharePoint Solution Installer will take any WSP package and wrap it in a very friendly wizard interface. Next, next, next, and the WSP you created using WSPBuilder is deployed to the entire SharePoint farm.

 

Technorati Tags: C#,SharePoint 2010,SharePoint,WSS,MOSS,Visual Studio,SharePoint Designer

Why SharePoint Scares Me … commentary

I recently read a post by Peter Campbell titled “Why SharePoint Scares Me”. Now being a Microsoft SharePoint MVP, you might think I’m about to go into a scathing criticism of Peter’s post. But I won’t. In fact, you may be surprised when I say that I liked his post very much.

Peter’s post was an honest and objective view on SharePoint from the perspective of someone who is neither a Microsoft zealot nor an oppositionist. Peter seems to be someone who doesn’t really care that much about the tech but is looking for something to get the job done with minimal upfront and ongoing investment. I run into similar conceptions about SharePoint very frequently. This is exactly the type of person we (the SharePoint MVPs) and Microsoft need to educate. 

To summarize Peter’s post, it conveyed concerns about SharePoint’s complexity, costs, learning curve, and operational impact. Unfortunately a lot of people share Peter’s viewpoint. I wanted to share my perspective on some of his points…

"advanced programming and integration with legacy systems can get really complicated"

This is true of all technologies, not just SharePoint. SharePoint actually has several tools that can make the job much easier. For example, many times you can implement a no-code integration with an external / legacy system using SharePoint Designer 2007 and the DataForm (aka DataView) web part. This does not require the more expensive SharePoint enterprise CAL.

"MOSS is actually two major, separately developed applications (Windows Sharepoint Services and Content Management Server) that were hastily merged into one app"

CMS was integrated, but the integration is better than one would think. It works very well for intranet and extranet scenarios. SharePoint for Internet sites can still be a challenge, but a fair amount of large Internet sites use SharePoint today. Check out this impressive list of public Internet sites using SharePoint from wssdemo.com.

"Without careful planning, Sharepoint can easily become a junkyard"

This is true of any content repository. The integrated search helps a great deal with content discovery, especially for new users, and the content expiration and records management features help to keep archives from cluttering up the works.

"Licensing for use outside of my organization is complicated and expensive"

Check with your MS sales rep. Microsoft has many programs to help smaller organizations qualify for better pricing, including BizSpark. BizSpark offers relatively new and small business free software for a period of three years! it’s a fantastic program.

The unlimited license is typically used only by public Internet sites that don’t want to or can’t track individual users. Intranets and extranets should use the per-user license. You may even get a volume discount as well. You can also start with Windows SharePoint Services (WSS) for core collaboration and document sharing, and move to MOSS later, if you need to. WSS is included with the Windows Server license.

"Compared to most Open Source portals, Sharepoint’s hardware and bandwidth requirements are significantly high"

The great thing about SharePoint is that you can start small and scale out as your needs grow. Start with a small pilot group of users. If more people want to join in (and they will once they see what SharePoint has to offer), add hardware then. You can even scale up servers without taking the farm offline.

While bandwidth can be an issue, especially for transferring large documents, this is true for any CMS.

<Shameless-plug>
Black Blade Associates (my company) has a product called SharePoint Zip. SharePoint Zip allows users to transfer files between SharePoint and their desktops as compressed Zip files. Users can transfer individual files, folders, or even a complete document library with a single click. Users can also upload multiple files as a compressed Zip file, which will be expanded into the document library. No additional client software, ActiveX, or plug-ins required.
</Shameless-plug>

"The database stores documents as database blobs, as opposed to linking to files on disk, threatening the performance of the database and putting the documents at risk of corruption."

This actually works better than storing the documents on disk. You are able to leverage database transactions, load balancing, backup, maintenance, and failover to guarantee uptime and ensure disaster recovery. SQL Server has made great gains in storing BLOBs, and SharePoint continues to benefit from those gains.

"I’m much better off with apps like Drupal, KnowledgeTree, Plone, or Salesforce, all of which do big pieces of what Sharepoint does"

I began my IT career doing enterprise application integration. I can tell you from experience that getting multiple applications to talk to one another in a way that is meaningful to your end users is always much more expensive than procuring one, integrated application. You’re generally looking at a 3X cost increase for the labor costs to do the integration. Also, don’t forget to budget extra time on top of deploying the systems to do the integration work.

"I might lose all of that out of the box integration with my MS network"

Don’t underestimate the costs of losing integration with the Office desktop applications with which your users are familiar. User productivity loss and user training costs are two very high hidden costs to deploying any CMS or collaboration system. SharePoint minimizes those costs by leveraging the expertise and familiarity users already have with the Office desktop applications.

All that said, I don’t want to give the impression that SharePoint is perfect or that Peter’s points are not valid. SharePoint is not perfect, and Peter has definitely done some due diligence before implementing a core business capability for his organization. However, when compared to the alternatives, SharePoint is a very capable and cost-effective offering, especially when you factor in comparing the hidden costs of user training, user productivity (you know, the reason you’re planning on deploying a collaboration or CMS in the first place), ease of scale-out, and general management features. Even CMSWire, a site typically critical of SharePoint, posted a lengthy reference to a Gartner report positioning SharePoint 2007 in the “magic quadrant” for enterprise CMS. Considering that SharePoint is sharing the position with products that have much higher price tags that is a high praise indeed.

By the way, if you have not already done so, you should really check out the SharePoint 2010 videos Microsoft just posted. They show many improvements to the underlying SharePoint infrastructure and development experience, and the videos address many of Peter’s concerns.

Update to SharePoint Designer 2007 Workflow on Task Lists

This is an update to my earlier post on SharePoint Designer 2007 Workflow on Task Lists

TBone has a nice article about changing the auto-assigned workflow task. The article can be found here:
http://www.sharepointblogs.com/tbone/archive/2008/01/10/ode-to-joy-changing-the-task-list-for-auto-generated-tasks-within-sharepoint-designer.aspx

Thanks TBone!

SharePoint Designer 2007 Workflow on Task Lists

Background

During the course of prototyping some task management capability for a client, I needed to create some quick and dirty workflow examples on a WSS tasks list. I did not need the workflow example to be deployable, compiled, or have any custom code, so naturally I thought of SharePoint Designer.

I created the workflow and associated it with a tasks list that we were using to manage our tasks. When I initially created the workflow, I set it to start only start when a user explicitly started it, not automatically on item additions or updates. Once I was fairly confident that the workflow was behaving properly, I wanted to go back and modify it to start automatically upon task item additions or updates. When I tried that, SharePoint Designer told me that I had errors in my workflow. It pointed to a step where I was collecting information from the user. I thought that was odd seeing how the data collecting had been working just moments before.

What made matters worse is that I had no way to get at the actual error details. When I tried to hover the cursor over the error symbol, the step drop down would obscure the error. I was stumped.

The Hunt

I decided to investigate the site in the web browser to see if I could pinpoint the problem. I remember working with the workflows that ship with MOSS, specifically, that they allowed me to select a history list and tasks list where workflow-specific data was stored. I looked through the site and found the history list but could not find the workflow tasks list.

I thought the lack of a workflow tasks list was odd. After all, how could the workflow be storing the data collection information if it did not have a workflow tasks list?

The Bug

The lack of the separate workflow tasks list proved to be the issue! It turns out that when SharePoint Designer 2007 creates a new workflow, it utilizes the first tasks list in the current site as the workflow tasks list. Now remember that I created the actual workflow to run on a tasks list. The reason I could not have the workflow auto-start was because SharePoint Designer was placing its data collection tasks into the same tasks list on which the workflow was defined. Knowing that, it was clear why the workflow could not auto-start: if the workflow auto-started it would start not only for task items that users added to the list but also for data collection tasks items that the workflow instances added to the list. That would cause workflows to cascade out of control.

The Workaround

Well, knowing the issue was great and all, but I had a customer breathing down my neck. It turned out that the workaround was easy to implement by using the behavior of the actual bug. If SharePoint Designer wanted to use the first tasks list in the site to store its workflow tasks, let it. I created a new site, and two tasks lists. I made sure to title the tasks list I wanted SharePoint Designer to use for workflow tasks to come alphabetically before the tasks list on which the workflow would actually run.

Here’s an example. Say I wanted my workflow to run on the “Tasks” tasks list. I would create another tasks list in the site called “A Workflow Tasks”. Because “A Workflow Tasks” alphabetically comes before “Tasks”, SharePoint Designer will use the “A Workflow Tasks” as the workflow tasks list for the site. Life is now good.

One Catch

I stated in the workaround that I created a new site to implement the workaround. This is because once SharePoint Designer chooses a tasks list as its workflow tasks list, it will keep that for the duration of the site’s existence. That’s why I created the new site. I suppose given enough time and desire I could have found where SharePoint Designer stores its affinity for a workflow tasks list, but at 3 AM, creating a new site seemed like the way to go.

Update

TBone has a nice article about changing the auto-assigned workflow task. The article can be found here: http://www.sharepointblogs.com/tbone/archive/2008/01/10/ode-to-joy-changing-the-task-list-for-auto-generated-tasks-within-sharepoint-designer.aspx