Microsoft Cloud Show Episode 016 – Interview with Marc Anderson on Recent Changes Impacting Customers on Office 365


Microsoft Cloud Show

A few weeks back, I sat down (virtually, of course) with Andrew Connell (@AndrewConnell) and Chris Johnson (@LoungeFlyZ) to record an episode of the Microsoft Cloud Show. Andrew was in Florida, I was in Boston, and Chris was way around the world in New Zealand. Ah, the wonders of modern technology.

The only place to stay up to date on everything going on in the Microsoft cloud world including Azure and Office 365.

Whether you are new to the cloud, old hat or just starting to consider what the cloud can do for you this podshow is the place to find all the latest and greatest news and information on what’s going on in the cloud universe.  Join long time Microsoft aficionados and SharePoint experts Andrew Connell and Chris Johnson as they dissect the noise and distill it down, read between the lines and offer expert opinion on what is really going on.  Just the information … no marketing … no BS, just two dudes telling you how they see it.

I was honored to be the very first guest on the show, which already had 15 excellent episodes in the can.

In Episode 016 – Interview with Marc Anderson on Recent Changes Impacting Customers on Office 365, we talked about a number of extremely important things that have been going on with Office365 lately.

I had done a post about one issue that has caused me and users of SPServices the most consternation, Office 365 Update Changes ‘Display Name’ on Required Fields and Andrew had posted about a few others one his blog in Office 365 Needs to Treat the UX as an API if Our Customizations are to Stay Off the Server.

Last week, I released SPServices 2014.01, which addresses the title changes (adding ” Required Field” to the title attribute of some required dropdowns), but there’s a bigger set of issues at play here, as Andrew alludes to in his post.

In the podcast, we talked about the impact of these changes as well as the mindset behind them from the Microsoft side.

If you do any client side development with SharePoint – and that’s where everyone is headed – you owe it to yourself to listen to the podcast. You’ll understand more about what changes to the DOM might mean for you as a developer, or even what might happen to you as a user of customizations that rely on the DOM being stable and predictable.

One things seems certain: we’ll see more changes like the ones we discussed in the podcast and they will have an impact on everyone, not just people replying on Office365. (The same issues started to crop up for people who have applied the December 2013 Cumulative Update (CU) for SharePoint 2010 on premises.)

I want to thank Chris and Andrew for inviting me in for a chat. Assuming I didn’t annoy them too much with my scatological terminology, maybe I’ll be able to visit with them again the next time a round of changes like this pop up and cause ripples in the SharePoint time-space continuum.


Fix in the February 2012 CU for Stack Overflows with DVWPs Running Over One Second Limit Imposed by the August 2011 CU

An assassin bug
Image via Wikipedia

If you’ve been bitten by the issue I described in my post called August Cumulative Update Causing Stack Overflows with DVWPs Running Over One Second, then you’ll be happy to know that there may be a solution available to you.

An anonymous reader left a comment on the above post the today letting me know that there is a new option provided in the February CU that allows you to increase the timeout from the rather nonsensical one second introduced in the August CU to something more reasonable.

I don’t have a setup where I can test this right now, so treat it as unconfirmed information, but it looks to be from someone named Joerg Sinemus, who works at Microsoft Germany GmbH.

Check out his post with a more complete description of the fix here:

Here’s the full text of his post in case it disappears for some reason. Full credit due, of course. That’s an assassin bug photo. It seemed appropriate.

If you run into the problem described in:

2639184 SharePoint 2010: DataForm Web Part displays “Unable to display this Web Part”;EN-US;2639184

we might have another solution for you.

Our KB article 2597136 contains the following line that describes the issue but needs some more steps after you have installed the hotfix.

When you try to open a large .xsl file by using a Data Form Web Part (DFWP) on a SharePoint Foundation site, the DFWP does not display the file.

We highly recommend to use the following steps to change the behavior:
Install February 2012 cumulative update (Full Server package) for Microsoft SharePoint Foundation 2010 or SharePoint Server 2010

The code change is in the Microsoft.SharePoint.DLL with build 14.0.6117.5002 and later also on higher builds as usual.

Now you need to test which value might be a better one than One Second timeout.

On SharePoint Server log in with your Farm Account.
Start PowerShell in an elevated mode; check more information.

The following code lines will set the timeout to five seconds:

$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 5

In a discussion forum I read that two seconds are also a good value but everything depends as usual on the overall performance on the server side.

Enhanced by Zemanta

August Cumulative Update Causing Stack Overflows with DVWPs Running Over One Second

Today is one of those days where I try to figure out a bunch of odd situations in various places. The oddest was one involving a Data View Web Part (DVWP) I wrote about a year ago. It’s been running just fine ever since – until about a month or so ago. I didn’t hear about the issues until last week, and they didn’t make much sense to me.

Most of the time, the DVWP was loading just fine. Occasionally, rather than the spendiferous expected output (it really is a cool DVWP), users would see the wonderful error:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

along with a correlation ID. Of course, that error can mean just about anything, as we DVWP lovers all know. The error is sporadic and there’s nothing obvious going on. No data or code has changed, so my theory was that there must be something going on with the server at the time of the error.

In looking at the logs, we saw that a stack overflow had occurred, but there wasn’t much else to go on. So why would the same code with the same underlying data sometimes cause a stack overflow and sometimes not? I looked through the code and didn’t see anything that I’d done which was dumb.

After going back and forth on this a bit, I remembered reading that there was a change in the August CU that set a limit on the amount of time that an XSL transform was allowed to take. As I understand it, it went from 5s in the June or July CU to 1s in the August CU. This can many times not be enough time if there is a server load. Ostensibly this is to protect against denial of service (DoS) attacks. And even better, if the 1s is exceeded, a stack overflow is forced even though there is no actual error. This means that if there is a server load, the DVWPs can be forced to a stack overflow needlessly. I’m piecing all of this together based on multiple blog posts and such, of course, so I’m not certain that it’s all correct.

With Glyn Clough’s (@glynclough) help

I was able to track down KB Article 2639184 which stated the problem, and gives some possible workarounds. I don’t find the workarounds to be all that palatable, though, especially the first one:

Simplify the custom XSL that was added to the DataForm web part.

If I could simplify the XSL, then wouldn’t I have done that when I wrote it to be efficient?

I’m hoping that there will be a longer term fix for this, ideally a way to set the 1s parameter to something more reasonable. I’ve emailed the MVP mailing list to see if there’s anything positive from the Product Team and I’ll update this post if I hear anything useful.

In the meantime, I’m not sure what we’ll do other than tell our users that they need to refresh any pages that have DVWPs on them until the error disappears. I’m sure that will make me popular.
In this thread, Dan Davis shows what he found when he used Reflector to look for what was causing the issue. Scroll down for Dan Davis’ post on Monday, September 19, 2011 at 8:47 PM.

<UPDATE dateTime=”2012-03-11″>

There is reportedly a fix for this in the February 2012 CU. See Fix in the February 2012 CU for Stack Overflows with DVWPs Running Over One Second Limit Imposed by the August 2011 CU.