A great deal has been written about the technical aspects of SharePoint. While this body of knowledge is critically important to the SharePoint ecosystem, the non-technical aspects of deploying and maintaining the platform in large organizations are somewhat underrepresented in the literature. This white paper was written to help address this gap; our goal in writing it was to provide insights, advice, best practices, and real-world experience to help organizations understand and address these non-technical issues.

We hope this paper is useful to you and your organization. We will do our best to keep the document up to date and we’d love to hear your comments and feedback. If you see any errors, feel that important topics are missing, or would just like to connect online please don’t hesitate to contact us.

Our sincere thanks to the following folks who donated their time and expertise to help improve the paper:

• Eric Halsey
• Omar Amezquita
• John Teer
• Wren Mott

As it turns out this is a known problem and there is not currently a fix for it. The work-around is to use “wildcard inclusion” on any managed paths, and in our testing it appears to work as expected. When we publish the same form to a site using the wildcard path, the secondary data connections work just fine and the form functions as designed. We have encountered some other strange issues in the explicit-inclusion sites, such as SharePoint Designer data view webparts losing their connection to linked lists, and while I’m not sure if it’s related or not we don’t see those problems when we’re not in the explicit inclusion sites.

If you’ve encountered this same issue hopefully this blog post will save you a bit of time and a call to Microsoft. I haven’t received a link to a specific knowledge base article, but if I do I’ll update the post. Here are a few links to other user postings that might help:

http://technet.microsoft.com/en-us/library/cc288905.aspx (see comment at the bottom)

http://www.eggheadcafe.com/conversation.aspx?messageid=33610469&threadid=33610468

http://social.technet.microsoft.com/Forums/en-US/sharepointinfopath/thread/851c5baf-1c81-482a-8776-f909b54da565/

1. Create a new Task list
2. Go into the List Settings and remove all of the columns other than Title, Assigned To, Created By, and Modified By
3. Save the list as a template called “Custom List with Assignment Email”

Now when we need to create a custom list that emails users when they have an item assigned to them, we simply start with the new list template and add the columns and views we need, rather than starting with the standard “Custom List” template. Simple, effective, no code, and easy for users to implement on their own.

SharePoint allows us to break out of this approach and think about organizing our content differently. By adding meta-data to our files, either through the addition of custom columns to lists or libraries, or by creating custom content types, we are able to leverage the sorting, filtering, and grouping capabilities of views. You may have noticed that it’s possible to turn off sub-folders in document libraries; I would highly recommend you do this and start creating customized views instead.

Example: let’s say your project management office wants to organize their files. In the file server world, you might find a shared folder called “PMO”. This folder would probably have sub-folders for each of the individual projects; each of these project folders might have another level of sub-folders for the phases of the project. Within each phase, you might find a folder for status reports, another for budgets, and so on. This assumes, of course, that you are lucky enough that all of the project managers follow exactly the same organizational structure. Given this approach, if you wanted to see all of the current status reports you would have to navigate through each of the projects’ folder hierarchies looking for the most recent status reports. If you wanted to see everything that had been created by a particular user, or all the files for the planning phases of each active project, you would have to collect everything by hand.

By placing your files into a document library, applying some simple meta-data, and creating custom views you can do all of those things and more. By adding a column for “project ID”, another for “phase”, another for “document category”, and another for “notes”, you can create a wide range of views that allow you to look at files for a single project, look at files across all of the projects, show only those files created in the last week that are in the final phase of a project, and so on. This gives users the ability to quickly navigate to the files they are interested in without having to memorize a folder hierarchy. It also makes it much easier for the library owner to keep things organized, as users can’t inadvertently drop files into the wrong folder.

However, if you’re not careful your document libraries can quickly become simple copies of the existing file server hierarchy already exists. By removing the option to add sub-folders and training users how to apply basic meta-data and customized views, you’ll help your organization get the most out of your new SharePoint library.

Symptoms:

• InfoPath form with ~150 data elements
• About 60 of the elements need to be attached to the SharePoint library
• We were promoting the columns to the library, and on publishing ran into failures about 90% of the time

Our best hypothesis is that the web service on the SharePoint server was timing out before the publish operation could complete. However, once we changed the way we’re publishing the problem seems to have gone away completely. The fix is to ensure all of the “linked” columns already exist in the form library, then tell InfoPath to attach to those columns, not create new ones. You can do this during the publish wizard process:

1. Click the File -> Publish… menu option
2. Select the first option “To a SharePoint server…”
3. On the next screen include the proper URL to the library
4. On the third screen select “Document Library”
5. On the fourth screen select “Update the form template in an existing library” and choose the library from the list
6. On the fifth screen you’ll have the option to add your columns. When you click the “Add” button, instead of opting to have InfoPath create the column for you (i.e. the “None: Creat the new column…” option), select the “This document library” option from the first drop-down, then select the appropriate column name from the second drop-down box

This seems to have completely corrected the “Updating content type failed” error we were having and appears to have cleared up several other issues. When our publish failed, we were losing all of the views, etc. which makes sense, as InfoPath was re-creating the columns. We were also seeing fields become un-linked in the SP Designer workflow. Presumably this will fix all of the issues and save us an incredible amount of time moving forward. Hopefully this tip helps you, and please leave comments for others if you can add any insight.