Visio Services - The server failed to process the request

Another day, another interesting SharePoint error!  I finally got around to building out a Visio dashboard for my model office environment.  We've got a lot of servers out there and it's about time to get a handle on overall health and performance. 

The dashboard worked great until I let the team try it out - two folks reported back that the page was showing an error, "the server failed to process the request".  ULS showed a related error, at Microsoft.SharePoint.WebPartPages.Utility.SetThreadCulture - not totally obvious!

Searching out there turned up a blog post by Robert Seso of a similar problem on SharePoint 2010 - different ULS log entries, though.  I tried out the fix he suggested to solve his issue - grant a permission to the service account a used by Visio Services - not the SCOM service account or data reader account, but the service account configured for Visio Services in SP2013.  Here's the PowerShell to run:

$webapp = get-spwebapplication("http://mywebapp.myserver.com")
$webapp.GrantAccessToProcessIdentity("mydomain\sp_visiosvc")

Go back to your page, refresh, and so far so good.

http://www.robertseso.com/2012/02/troubleshooting-workflow-visualization.html

More clarification!  So far not so good.  I think the real issue here was on how I had set up the data source.  Initially, I had created a site collection, pointed the ODC file at that URL, then all was good.  I then decided to make things nicer and go with a host named site collection, which in & of itself was not the problem, the problem was, I used the original ODC file without updating it for the new HNSC.  I recreated the ODC file in the HNSC and recreated the Visio drawing to use this ODC file & it's been running fine since.

SharePoint 5586 flood fixed

Hi SharePointers,

Another SharePoint first today.  I had set up a dev server for a colleague, went back in to take a look because she said she was having performance problems.  I fixed the root certificate issue, which certainly helped, but also there were a lot of 5586 messages left.  From the ULS logs:

Unknown SQL Exception 53 occurred. Additional error information from SQL Server is included below.  A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

I checked the SQL Server aliases (this server uses a named instance, after all!), checked the registry keys used for the aliases & the SharePoint Config db, and checked the SQL Server's network configuration, but nowhere was it using Named Pipes.

Turns out: wrong alias.  I generally use SPDB as my alias name, but if I went down one more line in the ULS logs:

ConnectionString: 'Data Source=ServerName_SPDB;Initial Catalog=master;Integrated Security=True'....

So somehow, the servername value I was using was in front of the alias - sounds like a bug in my AutoSPConfig XML file!  The rest of SharePoint is working fine, so there must be a service somewhere that's using this alias.  I'll dig for that next, but workaround for now, I set up a second alias for this value & no more log flood.

Hope this helps someone!