Category Archives: SharePoint 2010

InfoPath form publishing and the “SOAP message cannot be parsed” error

This error has been killing me of late. I have a SharePoint 2010 list with a form that’s customized in InfoPath. Admittedly, the list is *very* large… as in over 74000 items. I know… it should be smaller, but that’s another discussion for another time.

The form has always taken a bit of time to publish, and the time has increased as the list has grown. Recently, I made a small change to the form, and it would no longer publish. I started getting the following error – “The SOAP message cannot be parsed”:


I tried a number of methods to “fix” the problem, based on various online posts and blog entries. Most of them recommended changing IIS timeout setting, but that wasn’t solving it this time for us.

Then I found this blog entry:

It was this part that was the revelation:


I had one calculated field in the list, and ironically it was one I really wasn’t using. I deleted that field and then republished the form. Not only did it publish, but it did so in about 10 seconds (as opposed to the minutes it used to take).

I would have never thought that a calculated field would have that effect on publishing a form, but there you go.




How we fixed the “Failed to render Wiki Content column” error

This is one of those errors that doesn’t have a lot of history to pull from if you Google/Bing it to find help. I’m putting this one out here to help rectify that in some small way.

We have a site where we built a small custom list and then customized the form in InfoPath. As part of that form, we had a formatting rule that used pattern matching in order to hide a section. This was used to get a form of validation on a People Picker column.

All was going well until we embedded the form in a wiki page using an InfoPath Form web part. Then all hell broke loose. The page (AND the form) started returning this error:

Failed to render “Wiki Content” column because of an error in the “Multiple lines of text” field type control. See details in log. Exception message: Function ‘xdUtil:Match()’ has failed..

The form was easy and fast enough to rebuild when it appeared the first time. But when the form and page broke again later in the day, we knew that something had to be done. Breaking and rebuilding the form every time you want to change it really isn’t very scalable. 🙂

The xdUtil:Match portion of the error seemed to point to some type of issue with pattern matching. We wondered if perhaps the pattern matching rule we had in the form wasn’t playing well in an embedded form scenario. Once we removed that rule from the form and republished it, everything returned to normal and our problem was resolved.

While I still don’t know the details of why that broke the page and for what reason, I’m happy enough to live with “don’t do that ever again” when it comes to this situation… especially since I found a way to get the same formatting rule in place using something other than pattern matching.


The pesky “The workflow could not update the item” error

Recently, Sandra (my SharePointBuddy) and I built a peer-to-peer recognition site on SharePoint, and it’s really cool. However, we had a couple scenarios where the notification workflow would error out with the following message:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information.


If you’ve run into this issue and done any research, you know that there is no set answer for how to resolve it. Furthermore, many of the answers are “I did this and it started working again, but I don’t know why.” And of course, none of these answers addressed our problem.

After a few days of trying to figure out the “why” behind our particular variation of this, we finally stumbled across the issue.

The recipient of this particular “High Five” had a regular and a test AD account. Unlike most of the test account scenarios, his test account had his regular name with all the associated data fields filled in. When the workflow got to a point where it was trying to build a new list item, we were using the “Display Name” variation of the Recipient People Picker field for the email address. Unfortunately, the Display Name for this person’s account was not unique, so SharePoint Designer was choking on a multi-value data field that was only supposed to be a single-value occurrence.

Once we figured that out, we changed all the usages of that field to use the Login Name (which *was* unique), and then the workflow worked just fine.

I put this out here so that anyone trawling for an answer has at least one more option to choose from…

Reverting to a SharePoint 2010 default list form once it’s been customized…

20160122Image01.pngSo today’s adventure involved fixing someone’s custom list form that had “broken”. They said that it used to look one way, and then something happened and now it looks different and things at the top of the form are gone. Not a lot to go on, but that’s my job… figure things out based on people explaining issues in terms they understand.

After some thought and observation, I figured out that someone had gone into Customize Form on the list’s Ribbon Bar and saved/published a new version of the form. It’s close to the same look as the default form, but things like the Attach File icon and the buttons at the bottom of the form disappear. I also confirmed that the displayifs.aspx, newifs.aspx, and editifs.aspx versions of the forms (customized versions) were showing up as present in SharePoint Designer.

Now… how do I revert back to the default form?

It was easier than I thought… If you go into List Tools > List > Library Settings, you’ll see an option titled Form Setting under General Settings. When you open that option, select the Use The Default SharePoint Form option, and your customized forms will no longer be the default.


I tried to solve this earlier in the week for someone, and I ended up having to recreate the list from scratch and copy over the data. Obviously, this approach is MUCH easier…

How do you get a home page when you open a SharePoint wiki library?

In short, you make sure there’s a page out there named… Home.

I had a question today related to clicking on a SharePoint wiki library link. The customer wanted the library to open up to a home page, not a view of all the pages in the wiki library. Sounded easy enough, especially when she also sent me a link to a site where someone was doing just that.

Being a dev/tech person, I’m looking for settings for the library to set her Intro page to be the library home page. However, everything I tried would end up setting the Intro page to the SITE home page, not just the wiki library home page.

After considerable searching, I found a passing reference to a behavior that I didn’t know (and I admit I’m not a huge wiki fan). Apparently, if you open a SharePoint wiki library, it will attempt to open a page actually called Home. If it doesn’t find one, it opens the AllPages view of the wiki library.

I tossed a Home page out there, and voila… the library opened to that page. I then asked her to change her Intro page and rename it to Home. Worked like a dream…

Sometimes, we techies over-complicate simple things. 🙂


Getting Open In Explorer for a Picture library

Another one of those “I never noticed that before” questions today…

One of my customers wanted to get their pictures out of a Picture library, and said that they couldn’t find the Open In Explorer option in the Ribbon Bar. My first guess is that they were having a problem with the Internet Explorer SharePoint add-ons, but no… there’s basically NOTHING in the Ribbon Bar for a Picture library!

We have Sharegate, and I know I could have exported the Picture library to a file share, and it would have been fine. But still… how could I allow the customer to do that themselves?

A little digging around found an answer in the form of a nice little hack (elegant solution to a problem).

Open a Windows File Explorer window, click in the address bar at the top of the screen, and enter the SharePoint site address in the following format:

For example: \\\sites\MyTestTeamsite

That opens up the site in Windows File Explorer, and you can drill down into any library that’s out there… including Picture libraries.

I passed along the information, the customer tried it, it worked, and everyone was happy.

Changing an imported Excel number field to text in SharePoint

On a recent “Open Office Hours” call we do in our SharePoint group, we had a customer with an Excel/SharePoint issue. They had an Excel spreadsheet they needed to copy/paste into a datasheet view several times a day, and one of the fields was a “numeric text” field. In other words, the field should be treated as a text value, but it was basically a 12 character field with all numbers. The problem is that when they would import that field, it would change the value to something like 1543E+12, regardless of whether you defined the SharePoint column as text or numeric.

I’ve looked into this in the past, and all the material I found online said basically the same thing… importing a number column from Excel will always have the field being treated as numeric in the translation, even if you define the column in Excel as text. Normally I’d suggest that they pad the field with some text character to get the translation to work as text, but the group that gives them the data from Access were unwilling to make any changes. Basically, we had to do something on the SharePoint side to help them.

Fortunately, I found a workaround that took care of the condition in this particular situation. It’s not perfect for all cases, but perhaps you’ll find this useful if your situation is similar.

In the SharePoint list, define the incoming field as a number, and make sure it’s set for zero decimal places:



Next, create a calculated field in the list where the text transformation will occur:


In the calculated field, set the formula to append a non-numeric value onto the original imported field. In this example, I’m just using &”” so that it thinks there’s a text character at the end, which then makes the whole field a text value:


Here’s what the view looks like when I use the original number field (note the comma separators):


And here’s what the new calculated text version of the field looks like:


This worked great for my site. The customer tried it out, and they were ecstatic with how much time and effort it saved them.

The only two drawbacks that I can see are:

  • Leading zeroes – It would likely trim off leading zeroes during the import, so converting it to a text field would likely do so without those zeroes. In my case, that wasn’t an issue.
  • Editing – If you had a reason to edit that text-based value, you’d have to have them edit the numeric field as you can’t edit the calculated text field. That might confuse some people, but again… not an issue in either case here.

Hopefully this technique will be helpful if you find yourself in the same situation. All the Google searching I saw says there’s no way to “fix” an Excel import to treat it properly as a text value coming in. This approach at least gets you almost all of the way there, especially if you have no control over the spreadsheet data you’re receiving.

One of those “I never noticed that” on the Check Permission dialog box…

In one of my help desk calls, someone asked why a user who only had Contribute permission seemingly had a ton of other higher level permissions associated with their account. Being the cynical IT person that I am, my first thought was “OK, what did they misunderstand?” However, looking at the following, I had to agree that they had a lot more than Contribute:


In 99% of the times I’ve used Check Permissions, I don’t see “The following factors also affect this level of access for” section. What’s worse, I didn’t know right off WHY this person was getting that additional information. It certainly wasn’t as part of their SharePoint permission group settings.

It took me a bit of time to finally figure out what the difference was. This particular person was originally put in the Site Administrators area for this site, as they were one of the original business owners. Roles shifted and their permissions were altered to only have Contribute, but no one removed him from the Site Administrators group. Once I did that, all the “following factors” disappeared.


“InfoPath cannot connect to the server” – that sucks…

The other day, I was trying to customize a list form using InfoPath, and I started receiving this error:

InfoPath cannot connect to the server. The server may be offline, your computer might not be connected to the network, or InfoPath Forms Services 2010 might not be enabled on the server. To fix this problem, start by checking your network connection, and then trying again.”

Um… no, the server is up, I’m connected to the network, and InfoPath Forms Services is working just fine on every other site out there, thank you very much.

So… off to Google (or Bing) that error message, hoping for something fairly quick and simple. After a little digging, I came up with this blog post that pointed me down the right path:

To quote the meat of his post:

Since this was not an issue with other site collections we can narrow it down further that it is only with the InfoPath Site Features (IPFSSiteFeatures). This is a hidden feature in all site collections and can only be viewed through PowerShell. I found by simply disabling and re-enabling this feature fixed the problem.

Using PowerShell, you have to run the two commands:

PS C:\> Disable-SPFeature "IPFSSiteFeatures" -url "http://Server/Sites/SiteCollection"
PS C:\> Enable-SPFeature "IPFSSiteFeatures" -url "http://Server/Sites/SiteCollection"

Once I did that, everything went back to normal. I wish I knew a bit more behind the *why* of that happening, but I’m more into triage and keep moving… and this worked.

Slides from SharePoint Saturday Redmond – Leading Your SharePoint Customers To Water… *and* Teaching Them How To Drink

Here are my slides from SharePoint Saturday Portlandia on November 14th, 2015. We had a good turnout, and I made it through the session even though I was nursing a cold.

I think the most enjoyable part of this is the discussions afterwards. I love how this content sparks ideas and the “I could do that” statements.