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.
Friday, October 03, 2014
Thursday, October 02, 2014
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!
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!
Thursday, September 18, 2014
Method 'Upgrade' in type 'Microsoft.SharePoint.WorkflowServices.WorkflowServiceApplicationProxy' message
The good admin you are, you just finished deploying the Windows patches for September on your non-SP1'd SharePoint 2013 farm server...rebooted...Central Admin comes up fine...open up PowerShell and kaboom!
Method 'Upgrade' in type 'Microsoft.SharePoint.WorkflowServices.WorkflowServiceApplicationProxy' from assembly 'Microsoft.SharePoint.Wor Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' does not have an implementation.
There's an update that assumes you already have SP1 deployed - if you go back to Central Admin you'll note the UI changes for O365 & Yammer are now showing up. The fix is to deploy one more hotfix to your server - you can download it from here: http://www.microsoft.com/en-us/download/details.aspx?id=42898
No reboot required - install the update, open up that PS window & you're blissfully error free.
Happy SharePointing!
Method 'Upgrade' in type 'Microsoft.SharePoint.WorkflowServices.WorkflowServiceApplicationProxy' from assembly 'Microsoft.SharePoint.Wor Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' does not have an implementation.
There's an update that assumes you already have SP1 deployed - if you go back to Central Admin you'll note the UI changes for O365 & Yammer are now showing up. The fix is to deploy one more hotfix to your server - you can download it from here: http://www.microsoft.com/en-us/download/details.aspx?id=42898
No reboot required - install the update, open up that PS window & you're blissfully error free.
Happy SharePointing!
SharePoint 2013 Site Codes and Descriptions
Below is a list of the out of the box site codes available for SharePoint 2013. This is for the 1033 (US English) locale:
| Site Code | Description |
|---|---|
| GLOBAL#0 | Global template |
| STS#0 | Team Site |
| STS#1 | Blank Site |
| STS#2 | Document Workspace |
| MPS#0 | Basic Meeting Workspace |
| MPS#1 | Blank Meeting Workspace |
| MPS#2 | Decision Meeting Workspace |
| MPS#3 | Social Meeting Workspace |
| MPS#4 | Multipage Meeting Workspace |
| CENTRALADMIN#0 | Central Admin Site |
| WIKI#0 | Wiki Site |
| BLOG#0 | Blog |
| SGS#0 | Group Work Site |
| TENANTADMIN#0 | Tenant Admin Site |
| APP#0 | App Template |
| APPCATALOG#0 | App Catalog Site |
| ACCSRV#0 | Access Services Site |
| ACCSVC#0 | Access Services Site Internal |
| ACCSVC#1 | Access Services Site |
| BDR#0 | Document Center |
| DEV#0 | Developer Site |
| DOCMARKETPLACESITE#0 | Academic Library |
| EDISC#0 | eDiscovery Center |
| EDISC#1 | eDiscovery Case |
| OFFILE#0 | (obsolete) Records Center |
| OFFILE#1 | Records Center |
| OSRV#0 | Shared Services Administration Site |
| PPSMASite#0 | PerformancePoint |
| BICenterSite#0 | Business Intelligence Center |
| SPS#0 | SharePoint Portal Server Site |
| SPSPERS#0 | SharePoint Portal Server Personal Space |
| SPSPERS#2 | Storage And Social SharePoint Portal... |
| SPSPERS#3 | Storage Only SharePoint Portal Serve... |
| SPSPERS#4 | Social Only SharePoint Portal Server... |
| SPSPERS#5 | Empty SharePoint Portal Server Perso... |
| SPSMSITE#0 | Personalization Site |
| SPSTOC#0 | Contents area Template |
| SPSTOPIC#0 | Topic area template |
| SPSNEWS#0 | News Site |
| CMSPUBLISHING#0 | Publishing Site |
| BLANKINTERNET#0 | Publishing Site |
| BLANKINTERNET#1 | Press Releases Site |
| BLANKINTERNET#2 | Publishing Site with Workflow |
| SPSNHOME#0 | News Site |
| SPSSITES#0 | Site Directory |
| SPSCOMMU#0 | Community area template |
| SPSREPORTCENTER#0 | Report Center |
| SPSPORTAL#0 | Collaboration Portal |
| SRCHCEN#0 | Enterprise Search Center |
| PROFILES#0 | Profiles |
| BLANKINTERNETCONTAINER#0 | Publishing Portal |
| SPSMSITEHOST#0 | My Site Host |
| ENTERWIKI#0 | Enterprise Wiki |
| PROJECTSITE#0 | Project Site |
| PRODUCTCATALOG#0 | Product Catalog |
| COMMUNITY#0 | Community Site |
| COMMUNITYPORTAL#0 | Community Portal |
| SRCHCENTERLITE#0 | Basic Search Center |
| SRCHCENTERLITE#1 | Basic Search Center |
| visprus#0 | Visio Process Repository |
| ECMWebTemplate#0 | Enterprise Content Site |
Friday, September 12, 2014
Default gateway blank or 0.0.0.0
Ever had your server's default gateway stuck showing either 0.0.0.0, or blank entirely? Totally ignoring the value you're assigning? Happened to me when I was bouncing between client Hyper-V on Windows 8.1 and VirtualBox. The culprit? All of those prior network connections. Once you get rid of them, network properties works like a charm.
The catch? The devices and old connections are hidden. To show them, open up an administrator command prompt, and enter the command:
set devmgr_show_nonpresent_devices=1
then enter the command
start devmgmt.msc
to start up Device Manager (or launch it from Control Panel). Then, in the View menu, choose Show Hidden Devices, expand out your Network Adapters and be amazed:
See all of those hidden devices? The active one, Microsoft Hyper-V Network Adapter #19 is shown with the bold icon, but the others, including the Intel (R) PRO/1000 adapters are somewhat blurred - those are the ones to delete.
Do that, reboot for good measure, set that default gateway and be productive!
Update: I decided to poke around some of the other devices & there were more to remove, when making the VirtualBox to Hyper-V switch. Expand out some of the other nodes to clear out the old VirtualBox devices. Having these around wasn't causing problems, but the less clutter the better.
The catch? The devices and old connections are hidden. To show them, open up an administrator command prompt, and enter the command:
set devmgr_show_nonpresent_devices=1
then enter the command
start devmgmt.msc
to start up Device Manager (or launch it from Control Panel). Then, in the View menu, choose Show Hidden Devices, expand out your Network Adapters and be amazed:
See all of those hidden devices? The active one, Microsoft Hyper-V Network Adapter #19 is shown with the bold icon, but the others, including the Intel (R) PRO/1000 adapters are somewhat blurred - those are the ones to delete.
Do that, reboot for good measure, set that default gateway and be productive!
Update: I decided to poke around some of the other devices & there were more to remove, when making the VirtualBox to Hyper-V switch. Expand out some of the other nodes to clear out the old VirtualBox devices. Having these around wasn't causing problems, but the less clutter the better.
Also, be sure you remove either the Hyper-V Integration Services or the VirtualBox Additions from Windows Control Panel Add/Remove Programs, as appropriate. And if you're switching back to VirtualBox, odds are the Additions are out of date, so go ahead & refresh.
Tuesday, August 19, 2014
SharePoint Designer 2013 + SharePoint 2013 Workflow - where's the workflow??
Hi SharePointers,
We had an interesting one today. One of my developers was having a problem creating a new SharePoint 2013 workflow with SharePoint Designer 2013. We were able to create the workflow, but when SharePoint went to fetch the workflow actions from the server, nothing else happened - the workflow was not created. SP2010 workflows worked fine.
The solution: For some reason, a DLL was missing from the 15 hive on the server - in this path:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\WorkflowActivities
there should be a DLL:
Microsoft.SharePoint.WorkflowServices.Activities.dll
For whatever reason, that DLL was not in the folder. It was in the GAC, oddly enough. Once we copied the DLL from another server into the above folder, IISResetted, cleared the Designer cache, the workflow was able to be created.
Other things we tried that didn't help:
1) Re-registerWorkflow Manager
2) Removed Workflow Manager from the SharePoint server, then installed it on a separate smaller footprint server.
3) Re-registered Workflow Manager with non-SSL
4) Used Fiddler to see what was going on
The clue was in one message in the ULS logs - several OOTB features were missing:
Anyway, once that DLL was copied over - didn't have to GAC it or anything - all was well once again.
We had an interesting one today. One of my developers was having a problem creating a new SharePoint 2013 workflow with SharePoint Designer 2013. We were able to create the workflow, but when SharePoint went to fetch the workflow actions from the server, nothing else happened - the workflow was not created. SP2010 workflows worked fine.
The solution: For some reason, a DLL was missing from the 15 hive on the server - in this path:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\WorkflowActivities
there should be a DLL:
Microsoft.SharePoint.WorkflowServices.Activities.dll
For whatever reason, that DLL was not in the folder. It was in the GAC, oddly enough. Once we copied the DLL from another server into the above folder, IISResetted, cleared the Designer cache, the workflow was able to be created.
Other things we tried that didn't help:
1) Re-registerWorkflow Manager
2) Removed Workflow Manager from the SharePoint server, then installed it on a separate smaller footprint server.
3) Re-registered Workflow Manager with non-SSL
4) Used Fiddler to see what was going on
The clue was in one message in the ULS logs - several OOTB features were missing:
Feature definition with id 00bfea71-c796-4402-9f2f-0eb9a6e71b18 not
found. [WebPageLibrary]
Feature definition with id 065c78be-5231-477e-a972-14177cc5b3c7 not
found. [BizAppsListTemplates]
Feature definition with id 00bfea71-5932-4f9c-ad71-1557e5751100 not found.
[IssuesList]
Feature definition with id 7201d6a4-a5d3-49a1-8c19-19c4bac6e668 not
found. [MetaDataNav]
Feature definition with id 0806d127-06e6-447a-980e-2e90b03101b8 not
found. [PremiumWeb]
Feature definition with id 00bfea71-4ea5-48d4-a4ad-305cf7030140 not
found. [WorkflowHistoryList]
Anyway, once that DLL was copied over - didn't have to GAC it or anything - all was well once again.
Thursday, April 24, 2014
SharePoint 2013 and SQL Server HA options
I put together the following table to summarize the HA options available for SQL Server 2012 and SharePoint 2013. In short - use sync AlwaysOn where possible!
The difference between sync & async has to do with performance over data integrity. Sync will wait on confirmations from each end point that the transactions were successful. Async does not wait. Async will give better performance, but it's possible to have data loss.
I'm building this out in a lab environment based on VirtualBox. My attempt #1 was to get FreeNAS working with Server 2012 to set up the shared disk required by Windows Clustering. I was able to get the iSCSIInitator in Server 2012 to recognize the NAS drives, but couldn't convince Windows Clustering to use it. So next up will be to see if I can get the same working with Server 2012's iSCSI built in support.
I see this as one benefit of Hyper-V over VirtualBox - Hyper-V has a virtual fiber channel feature built in. In theory, this would let me set up a virtual SAN environment. I've been trying the same with VirtualBox (yes, I know...but I did try switching over to Hyper-V on my Windows 8 laptop, but at the time networking wasn't working. I should give it another try, I know...).
Anway, the table below is a summary of a TechNet article listing each of the SharePoint databases. I found the table format a bit easier to use.
Source: Supported HA Options for SharePoint 2013
The difference between sync & async has to do with performance over data integrity. Sync will wait on confirmations from each end point that the transactions were successful. Async does not wait. Async will give better performance, but it's possible to have data loss.
I'm building this out in a lab environment based on VirtualBox. My attempt #1 was to get FreeNAS working with Server 2012 to set up the shared disk required by Windows Clustering. I was able to get the iSCSIInitator in Server 2012 to recognize the NAS drives, but couldn't convince Windows Clustering to use it. So next up will be to see if I can get the same working with Server 2012's iSCSI built in support.
I see this as one benefit of Hyper-V over VirtualBox - Hyper-V has a virtual fiber channel feature built in. In theory, this would let me set up a virtual SAN environment. I've been trying the same with VirtualBox (yes, I know...but I did try switching over to Hyper-V on my Windows 8 laptop, but at the time networking wasn't working. I should give it another try, I know...).
Anway, the table below is a summary of a TechNet article listing each of the SharePoint databases. I found the table format a bit easier to use.
| Database | Purpose | Sync Mirroring | Sync AlwaysOn | Asyc Mirror/Log Shipping | Async AlwaysOn | |
| SharePoint_Config | Configuration database | Y | Y | N | N | |
| SharePoint_Admin_Content | CA content db | Y | Y | N | N | |
| WSS_Content | Content database | Y | Y | Y | Y | |
| AppManagement | Service database | Y | Y | Y | Y | |
| Search_Service_Application_DB | Stores Search app configuration | Y | Y | N | N | |
| Search_Service_Application_AnalyticsReportingStoreDB | Stores usage analysis data for reports | Y | Y | Y | N | |
| Search_Service_Application_CrawlStoreDB | Stores the state of the crawled content & crawl history | Y | Y | N | N | |
| Search_Service_Application_LinkStoreDB | Stores extracts of the content processing component sna click through info | Y | Y | N | N | |
| Secure_Store_Service_DB | Stores Secure Store credentials | Y | Y | Y | Y | |
| SharePoint_Logging | Stores health monitoring & usage data | Y* | Y* | Y* | N | * not recommended |
| SettingsServiceDB | Stores features and settings for hosted customers | Y | Y | Y | Y | |
| Usage Profile Service App | Stores & manages users and associated info | Y | Y | Y | Y | |
| Usage Profile Service App Sync DB | Used during a user profile sync | Y | Y | N | N | |
| Usage Profile Service Social DB | Stores social tags and notes | Y | Y | Y | Y | |
| WordAutomationServices | Stores info about pending & completed doc conversions | Y | Y | Y | Y | |
| Managed Metadata Service App | Stores managed metadata | Y | Y | Y | Y | |
| Translation Services DB | Stores info about pending & completed doc translations | Y | Y | Y | Y | |
| Business Data Connectivity Service DB | Stores external content types | Y | Y | Y | Y | |
| ProjectWebApp | Project Web App database | Y | Y | Y | Y | |
| PowerPivotServiceDB | Stores data refresh scheduled & usage data | No Guidance | No Guidance | No Guidance | No Guidance | |
| PerformancePoint Service DB | Stores temp objects & saved comments | Y | Y | Y | Y | |
| State Service db | Stores temp state info from InfoPath, Exchange, chart web part, Visio services | Y | Y | N | N |
Source: Supported HA Options for SharePoint 2013
Tuesday, February 25, 2014
SPC14
And, see you at the SharePoint Conference in Vegas! I'll be at the HP Booth Sunday night, and also speaking at the Partner Theatre Sunday night, then at the booth periodically throughout the event. If you're there stop by to say hello, or schedule a meeting with my on the MySPC site.
See you in Grand Rapids!
Accepted to speak at the DevDay conference in Grand Rapids, March 22!
http://grdevday.org/
Hope to see you there. There's a good line up of speakers and topics, I'll be attending some of the mobile development talks.
http://grdevday.org/
Hope to see you there. There's a good line up of speakers and topics, I'll be attending some of the mobile development talks.
Office Web Apps 2013 - Unhealthy
Ran into this issue on my lab servers. I installed Office Web Apps 2013, configured it, all good! But then Windows Update showed a patch from 1/2/14 for OWA, I applied that, and afterwards, Get-OfficeWebAppsMachine showed that my server was Unhealthy.
I did some Binging and found that indeed yes, there is a process to follow for patching an OWA server - first, remove the OWA server from the farm with Remove-OfficeWebAppsMachine, then apply the update, then use the New-OfficeWebAppsFarm again to rebuild the farm.
Following a comment in a host here: http://michaelvh.wordpress.com/2013/04/01/the-curious-health-problems-of-the-office-web-apps-server/
I enabled HTTP Activation for the WCF Services for the .Net Framework 4.5 on the OWA server. Since I'm running Server 2012, I needed to use the Features option on Server Configuration to get this working:
I did some Binging and found that indeed yes, there is a process to follow for patching an OWA server - first, remove the OWA server from the farm with Remove-OfficeWebAppsMachine, then apply the update, then use the New-OfficeWebAppsFarm again to rebuild the farm.
Following a comment in a host here: http://michaelvh.wordpress.com/2013/04/01/the-curious-health-problems-of-the-office-web-apps-server/
I enabled HTTP Activation for the WCF Services for the .Net Framework 4.5 on the OWA server. Since I'm running Server 2012, I needed to use the Features option on Server Configuration to get this working:
Did a reboot for good measure, now Get-OfficeWebAppsMachine shows Healthy!
Subscribe to:
Posts (Atom)