Feeds:
Posts
Comments

Archive for July, 2012

One of the great parts about my job is that I get to mix things up a couple of times a year and switch gears from SharePoint to BizTalk development. (It can be somewhat frustrating to keep everything straight at times, but it’s never boring!) Recently, I’ve been working on upgrading some BizTalk applications from 2006 R2 to 2010. It’s been great to see that not a whole lot has changed over the years. The integration with WCF was quite a change, but the principles aren’t a whole lot different from what was already there.

I was testing one of my orchestrations yesterday and ran into a rather unexpected problem: it was suspending with the message, “Suspend due to persistence failure during dehydration.” That’s not good: a DehydrationFailedException. Hmmm. I’ve seen this happen before–and it is most common to happen–when an object being used in the orchestration is not serializable. So, I checked all of my variables: they were all primitives or marked with the SerializableAttribute in the class definition. Hmmm. Okay, I’ve run into this before. For example, even though generics may be marked serializable, BizTalk doesn’t always handle the serialization very well.

Well, I was using a System.Collections.Specialized.StringCollection object. Though, it’s not a generic. To be on the safe side, I replaced it with a simpler System.Collections.ArrayList object. Still no go: “Suspend due to persistence failure during dehydration.” Grrr.

Review the variables once again. Everything is as primitive as I can get except for a System.Exception variable. So, I replaced it with some duplicated shapes. (This is getting absurd.) Still no go: “Suspend due to persistence failure during dehydration.” Grrr!

By this time, I knew what was causing the orchestration to hit a persistence point. I have a helper class which calls to a WCF service and uses the results to create a message used by the orchestration. (I know, it would be better to use the WCF service directly in the orchestration so I can get all of the failover, retry, et. al. offered by BizTalk itself. I went back and forth no less than half a dozen times before finally settling on calling the service in a helper class because it was just simpler.) The service call was failing because the data being passed to it wasn’t valid. No problem; good test! This could happen in production.

Problem was what the WCF service returned: a System.ServiceModel.FaultException. This in and of itself was not a problem (it’s marked SerializableAttribute), but it has a property on it called Code which holds a System.ServiceModel.FaultCode. System.ServiceModel.FaultCode is not marked with SerializableAttribute! AH HAH!

So, when the WCF service incurred a fault exception, it threw it, which got thrown from my helper class to the BizTalk orchestration. The orchestration has an exception handler that catches the exception. Within the exception handling is a Decide shape in which the orchestration either suspends or delays (for automatic retry). Suspending or delaying causes a persistence point and BizTalk tries to serialize and dehydrate. Only, it couldn’t serialize the exception because the Code property on the exception existed and is not serializable. (WOW! That was buried.)

Moral of the story: If you run into orchestrations suspending with the message, “Suspend due to persistence failure during dehydration,” (the DehydrationFailedException) first check the objects being used in the orchestration (variables, messages, etc.). If that doesn’t reveal the unserializable object, you may have to dig into those objects’ properties. An unserializable object must be around somewhere.

BTW, this problem will typically be accompanied by an event log entry of source “XLANG/s” with Event ID 10041 and the message, “xlang/s engine event log entry: Suspending due to exception occurring during dehydration of instance…”

Advertisements

Read Full Post »

For quite some time, we’ve had difficulties editing user profiles using Central Admin’s Manage User Profiles page (ProfMngr.aspx). It will let us go to the Edit My Profile page (ProfAdminEdit.aspx) the first time, but every successive attempt to access the page results in an Access Denied–and it doesn’t matter what account (Admin, Farm, self, etc.) we use. Access Denied. Frustrating! “What do you mean, ‘Access Denied’?? I was just there!

The ULS logs don’t give many clues as to what’s going on, either. Futhermore, once your app pool for Central Admin recycles, you start over: one access allowed and then lockdown. Here’s what the ULS logs will show:

07/09/2012 10:03:21.07 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Logging Correlation Data xmnv Medium Site=/ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.13 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Topology e5mc Medium WcfSendRequest: RemoteAddress: ‘http://sharepoint:32843/919746d29cfc419fb168abc82e2f7159/ProfileDBCacheService.svc’ Channel: ‘Microsoft.Office.Server.UserProfiles.IProfileDBCacheService’ Action: ‘http://Microsoft.Office.Server.UserProfiles/GetUserData’ MessageId: ‘urn:uuid:3b704fbf-2872-4140-a4a7-308261eb5b2a’ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Topology e5mb Medium WcfReceiveRequest: LocalAddress: ‘http://sharepoint.local.int:32843/919746d29cfc419fb168abc82e2f7159/ProfileDBCacheService.svc’ Channel: ‘System.ServiceModel.Channels.ServiceChannel’ Action: ‘http://Microsoft.Office.Server.UserProfiles/GetUserData’ MessageId: ‘urn:uuid:3b704fbf-2872-4140-a4a7-308261eb5b2a’ ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Monitoring nasq Medium Entering monitored scope (ExecuteWcfServerOperation) ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.15 w3wp.exe (0x1830) 0x294C SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (ExecuteWcfServerOperation). Execution Time=0.44716929548675 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation General 8e2s Medium Unknown SPRequest error occurred. More information: 0x80070005 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope (Request (GET:http://sharepoint:12345/_layouts/ProfAdminEdit.aspx?guid=ca5dda13-735d-afcd-8488-4d9c57fc721f&q=spsawyer&ConsoleView=Active&ProfileType=User&ApplicationID=919746d2%2D9cfc%1D419f%3Db168%2Dfbc82e2f7752)). Execution Time=128.538572630343 ef6e0150-2e6c-4832-91c3-6c1579cd9f85

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Monitoring nasq Medium Entering monitored scope (Request (GET:http://sharepoint:12345/_layouts/AccessDenied.aspx?Source=http%3A%2F%2Fsharepoint%3A12345%2F%5Flayouts%2FProfAdminEdit%2Easpx%3Fguid%3Dca5dda13%2D735d%2Dafcd%2D8488%2D4d9c57fc721f%26q%3Dspsawyer%26ConsoleView%3DActive%26ProfileType%3DUser%26ApplicationID%3D919746d2%252D9cfc%252D419f%222Db168%252Dabc82e2f7159))

07/09/2012 10:03:21.20 w3wp.exe (0x1434) 0x1F44 SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (GET:http://sharepoint:12345/_layouts/AccessDenied.aspx?Source=http%3A%2F%2Fsharepoint%3A12345%2F%5Flayouts%2FProfAdminEdit%2Easpx%3Fguid%3Dca5dda13%2D735d%2Dafcd%2D8488%2D4d9c57fc721f%26q%3Dspsawyer%26ConsoleView%3DActive%26ProfileType%3DUser%26ApplicationID%3D919746d2%252D9cfc%252D419f%222Db168%252Dabc82e2f7159) b24f736b-912e-471b-83f3-879e22eb228d

The key to figuring this out lies in that line about, “Unknown SPRequest error occurred. More information: 0x80070005”. That error deals with the portalsuperuseraccount and the portalsuperreaderaccount.

We had indeed set the portalsuperuseraccount and the portalsuperreaderaccount. Out of desire for best practice with least-privilege administration, we set the portalsuperuseraccount and the portalsuperreaderaccount to two different accounts. Unfortunately, the account we used as the portalsuperreaderaccount did not have access to the Edit My Profile page. The first time you access this page, it’s not yet cached. So, apparently, you don’t have problems. The second time, it is cached and, thus, [apparently] the portalsuperreaderaccount is used. (Could this be a security bug? Maybe.)

Solution: After changing the portalsuperreaderaccount for the web application in which CA is running to an account which does have access to edit user profiles, the problem disappeared. (If you decide to simply remove these properties, be sure to check out Tehnoon Raza’s post, “SharePoint 2010: How to Undo Portal Super Reader /Portal Super User Account Configuration for a Web Application“.)

Give it a try. My guess is that both the portalsuperuseraccount and the portalsuperreaderaccount need to have permissions, but I’ll leave that up to you to discover. 🙂

Read Full Post »