Symptoms
After performing an upgrade from SP2010 to SP2013, our SP2013 sites that are running in SP2010 compatibility mode, no longer works as expected. When refreshing the Service Objects via the "SmartObject Services Tester Tool", we get the following error...
SmartObject Server Exception: Error refreshing Service Instance 'nInstanceName]'.
Service returned : ' The SharePoint Service V2 broker only supports SharePoint Server 2010 and 2007. Verify the version of SharePoint you're connecting to, and if it's SharePoint 2013, use the SharePoint broker instead.
Server was unable to process request. ---> Requested value 'Publishing Pages' was not found. Source : SourceCode.SmartObjects.Management Inner Exception : Error refreshing Service Instance ' InstanceName]'.
Service Returned : The SharePoint Service V2 broker only supports SharePoint Server 2010 and 2007. Verify the version of SharePoint you're connecting to, and if it's SharePoint 2013, use the SharePoint broker instead. Server was unable to process request. ---> Requested value 'Publishing Pages' was not found.
Source : SourceCode.HostServerLib
Diagnoses
This is a known issue and we have a fix for this. The original fix was built on the 4.6.11 build, but we sent the ticket to LABS requesting that they retrofit the fix for us on the 4.6.7 codebase.
Resolution
After properly applying the fix to the client's production environment, the issue was resolved.
Additional Information... After initially applying the fix to the environment, we noticed that the GetList methods would all throw an http 500 error. This was because the fix was not applied properly. I have the following thoughts around why this happened.
1.) We might not have performed an IISReset after applying the fix. This was one of the steps that was in the readme, but when I tried this, the client was a little hesitant to perform an IISReset in the production environment. When applying assemblies to a SP environment, we have to do this, because the K2 Server and/or SharePoint might be holding onto the assembly. Doing an IISReset "releases" the file and the next time we call that file, we will get the new one from the GAC or the file system.
2.) The assembly might not have been GAC-ed correctly. I know that production environments are usually "clamped down" more from a security perspective. When applying assemblies to the GAC, we always recommend that you remove the assembly, make sure it is gone, add the NEW assembly, and make sure it is there. Theoretically speaking, the GACUtil /if (Install - Force) flag SHOULD overwrite the assembly in the GAC, but I have seen multiple times where this did not happen. This might explain why the fix "took" in the QA environment, but not in the Production environment.
3.) The reason why things "broke" when pointing the HOSTS file to a SP WFE without the fix, has to do with us "caching" the file in memory. This might be the reason why things still broke after pointing the HOSTS file back to a WFE with the fix. This would also explain why restarting the K2Server service "fixed" this afterwards. After we restarted the K2Server service, and performed the GetList, (Pointing to a WFE WITH the fix), it grabbed the new assembly, loaded it into memory and all was well.
