Thursday, July 28, 2011

Upgrading SharePoint from Standard CAL to Enterprise CAL

In Central Admin, first check your existing Farm license by clicking on ‘Convert Farm License Type’ under Upgrade and Migration.
It will display the Current License Type. It also has a text box for ‘Enter Product Key’. The textbox is always disabled on all the servers I have come across. It’s not what matters.
To upgrade from Standard to Enterprise CAL, go to Central Admin, click on ‘Upgrade on Migration’ in Left Navigation,  and then click ‘Enable Enterprise Features’. Enter the product key for Enterprise CAL, and then click OK.
You might see following errors:
·         “An error occurred while enabling Enterprise features. Refer to the event logs…”
·         “You do not have the appropriate permissions to use the SharePoint Products and Technologies Configuration Wizard.”
·         “The Execute method of job definition Microsoft.SharePoint.Portal.Administration.SkuUpgradeJob threw an exception”
It does not matter what account you have used to log in to Central Admin or remote into the machine. SharePoint uses Timer jobs to provision and enable the additional Enterprise features. You need to check the account under which your SharePoint Timer Job is running.
In my case, it was the SharePoint Farm account, but that did not seem to work.  I configured the Timer Job to run under the local machine admin account, and tried again. It worked like a charm. I have now reset the timer job to run under its original account. This was on a Single Server environment.  I haven’t tried on a multiple server farm, but I might add the Timer Job account to local Admin group on each machine in farm and then convert from Standard to Enterprise.
p.s.: In muli-server farm, do I need to make the account admin on each machine???

Wednesday, July 27, 2011

Workflow Errors on MOSS 2007

We have a MOSS 2007 Developer box. Actually it’s a training box and we give it to anyone wanting to learn and do some hands on for SharePoint 2007. With so many people using it and experimenting, shit happens and SharePoint on the machine is often broken. It’s not a Virtual Environment, and I cannot easily revert back to base configuration L
But I try to take it positively and tell myself “Fixing it is a good learning exercise” J
The Workflows on the machine were broken, and we were getting some errors in SPD. Below is a description of the errors and the resolution to fix it.
Error 1: On creating a new workflow using SharePoint Designer, it gave a popup message:
The list of workflow actions on the server references an assembly that does not exist. Some actions will not be available. The assembly strong name is ....
Obviously, the assembly did not exist in GAC. But I did not have the public key token to recreate it.
Check the following folder for custom .actions files:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\Workflow

By default, there should be only two files in the folder:
In my Training box, there were many additional .actions files like MySubStringActivity.actions.
I deleted all the custom files in the folder (after backup) and tried to create a new workflow again.
I still got the error. After some additional digging and semi-frustration, I did an IISReset. The error went away after the IISReset. SharePoint seems to cache them. Key is to do an IISReset after updating or deleting .actions file.
Error 2: After adding some valid steps in my workflow and clicking Finish, it gave the message:
“Errors were found when compiling the workflow. The workflow files were saved but cannot be run.”
I checked event logs, SharePoint logs, but nothing useful was being logged.
I opened my web.config, and Under <System.Workflow.ComponentModel.WorkflowCompiler>, <authorizedTypes> , noticed the following entry:
<authorizedType Assembly="Nintex.Workflow, Version=, Culture=neutral, PublicKeyToken=913f6bae0ca5ae12" Namespace="Nintex.Workflow.*" TypeName="*" Authorized="True" />
We are not using Nintex in any of our current projects, but it’s a Training machine and someone must have tried it out. I am not saying Nintex breaks its. Its one of our developers, but we dont keep track of who does what on a Training box. I removed the authorizedType  Nintex.Workflow line, saved the web.config  and tried again.
I can now successfully create the workflows using SharePoint Designer. My Training box for MOSS 2007 is working again…for now.