Since I’ve been working in the area of Workflow Manager (WFM) as it relates to SharePoint and since WFM is ‘tied at the hip’, so to speak, to Service Bus one of my co-workers forwarded me some interesting information regarding Service Bus that I thought was worth letting you know about if if you didn’t already…
<wow, that was a long and I’m sure grammatically incorrect sentence>
Basically, my peer, Joe Rodgers, is a powershell nut and uses it for everything. He was writing some scripts for one of his customers and noticed that when he changes the password for his Service Bus RunAs account, that the credentials for the Service Bus VSS service also change to match that RunAs account. Initially when you configure SB along with WFM for SharePoint, the Service Bus VSS service is configured to use LocalSystem.
Before the change:
The script used:
After the change:
Notice that the script doesn’t mention the account name, but what happens is in the code for setting the password of the SB RunAs account it also takes those credentials and sets them on the Service Bus VSS service.
I don’t expect this to affect many of us, but it’s possible that this will affect you if you are using some product that hooks into the VSS writers.
While working on a migration for a customer we were combing through the results of Test-SPContentDatabase in preparation for the migration efforts of taking their SharePoint 2010 content into a new SharePoint 2013 environment. We were systematically reviewing and repairing all the common errors that we found, like MissingFeatures, MissingSetupFiles, and MissingWebParts. It was the last of these that gave us a bit of a problem. After using the common scripts for removing these missing web parts, which normally show up as an error, these missing web parts were remaining quite stubborn.
Category : MissingWebPart
Error : True
UpgradeBlocking : False
Message : WebPart class [8dd36a66-e8d0-c735-2173-b3cf93383598] (class [
m assembly [2010_VisualWebPartProject, Version=18.104.22.168, Cultu
re=neutral, PublicKeyToken=7552893a02bae51b]) is referenced [
2] times in the database [WSS_Content], but is not installed
on the current farm. Please install any feature/solution whic
h contains this web part.
Remedy : One or more web parts are referenced in the database [WSS_Con
tent], but are not installed on the current farm. Please inst
all any feature or solution which contains these web parts.
The end result is complicated by a couple of factors:
- The version of SP2010 that I was working with was 14.0.4762.1000… yes, the RTM build
- The web parts that were being stubborn were sourced from Sandbox Solutions.
The combination of the above two items actually cause Test-SPContentDatabase to result in false negatives regarding these web parts…even after you remove the sandbox solution. Yes, folks you heard that correctly.. if you have the RTM build of SP2010 and remove your sandbox solutions that contain web parts, then Test-SPContentDatabase will still show false negatives for these web parts.
I did not test every build to find out exactly where it changed, but at some point before the release of service pack 1, Test-SPContentDatabase was altered to ignore sandbox solutions. So you no longer get an error on these web parts. There may or may not be another problem in that after removing the solution from the solution gallery and the web parts from the web part gallery that the reference still exists in the AllWebParts table, but I can neither confirm nor deny such theory at this time..
My final thoughts on this?
If you are upgrading SP2010 RTM –> 2013, then you can ignore missing web part warnings/errors from Test-SPContentDatabase as long as you confirm they are referring to sandbox solutions.