SharePoint : Error - Custom Field Type has not been installed properly

Some days ago, while I was deploying a release package to the UAT server, I had to face a strange issue. There was a release step in the release note to execute a PowerShell script after installing the solution, in order to update some of the metadata fields in a Document Library. 

There is a field within the document library columns which has been created using a custom field type, which is deployed through a farm solution. The given farm solution had web application scoped resources therefore it was deployed only to the Web Front End server and not globally deployed. 

Now the issue was, when executing the PowerShell script to update some metadata in the document library items, the values already existent in the above custom field had got emptied although this field was not touched through the script. 

After digging into the problem, I found that the root cause for this problem was because I was executed the script within the Application server. The farm solution had only installed the definition of the custom field type to the WFE server. This can happen to the feature definitions as well. Therefore, when retrieving the list item object through PowerShell code, the value of the custom field was not included. That's because the field type cannot be retrieved when trying to access it from the APPs server. As the list item object does not include this custom field property, it had emptied while updating list item back. 

Finally, I changed the server and ran the script in the WFE server and everything worked properly. 

Therefore, as a best practice and also as recommended, we have to keep in mind to execute these kind of PowerShell scripts inside the WFE server when the multi server architecture is used.

  

Folders in SharePoint - is it a bad idea?

Following are some compelling reasons on why folders in SharePoint should be avoided. The list is geared more towards end-users and folder proponents and could be used as a business case on why document library should be setup using meta-data. So here it goes:

1. USABILITY

Nested folder structure is only known to the person who created it. Also, too many sub-folders tend to “hide” things.

2. URL LENGTH LIMITATION

SharePoint adds all folder and sub-folder names to URL. Overall URL length is limited to around 260 characters. You are out of luck if you create too many sub-folders.

3. FILE URL

Moving file from one folder to another means change of file URL.

4. SECURITY

Maintaining Security by folders in SharePoint is an administrative nightmare. 

5. USER EXPERIENCE

User Experience (navigation, finding the documents) just stinks with folders

6. FILE DUPLICATION

With folders you can deposit multiple copies of same file into different locations – not a good thing when you try to organize documents and data in the first place!

7. ONE LONELY VIEW

There is another reason NOT to user folders. With folders, you get one view: the folder view. Using metadata, you can create unlimited number of views by whatever properties you have setup (i.e. organize documents by date, by customer, by project, etc.) So the document browsing experience is much better-off.

8. CAN’T SORT & FILTER

Since your files are buried in the folders, you can’t really benefit from sorting and filtering capabilities of document library headers (unless of course you are just sorting and filtering in the particular folder).

9. CHANGE IS HARD

It’s hard to change folder structure, while changing metadata is easy.

10. LOST DOCUMENTS

You can “lose” documents when placed in the wrong folder. Additionally, Also, too many sub-folders tend to hide things, making it impossible or too time-consuming for users to find a particular document.

11. NAVIGATION

When you are in a particular sub-folder, there is no way to tell in which folder you are at any given time, and no easy way to navigate to the parent folder (there is no breadcrumb on folder navigation menu available)

12. COST

If you are essentially recreating nested folders you had on file share, by using SharePoint, you have got yourself one expensive file share.

SharePoint: Error : Workflow definition Id is undefined (returns 0)

Sometime back we developed a SharePoint 2013 Visual Studio Workflow to one of our clients. The workflow association to a document library was also implemented in the code inside a feature activation. Recently, I was deploying this solution to a new site collection in my development environment and I got an exception while activating the workflow association feature. 

The issue was because the workflow definition id returns 0 when retrieving the workflow definitions deployed to the site.

WorkflowServicesManager workflowServicesManager = new WorkflowServicesManager(currentWeb);

WorkflowDeploymentService workflowDeploymentService =                            workflowServicesManager.GetWorkflowDeploymentService();

 WorkflowDefinitionCollection workflowDefinitions = workflowDeploymentService.EnumerateDefinitions(true);

foreach (WorkflowDefinition workflowDefinition in workflowDefinitions)

            {

                if (workflowDefinition.DisplayName.Equals("Document Workflow"))

                {                    

                    WorkflowSubscription workflowSubscription = new WorkflowSubscription();

                    workflowSubscription.DefinitionId = workflowDefinition.Id;

                    workflowSubscription.Enabled = true;

                    workflowSubscription.EventSourceId = documentLibraryList.ID;

                    workflowSubscription.Name = workflowDefinition.DisplayName;

                    workflowSubscription.EventTypes = eventTypes;

                    workflowSubscription.SetProperty(

                        OnlineSubmissionWorkflowAssociationFeatureEventReceiver.TaskListId,

                        documentWorkflowTaskList.ID.ToString());

                    workflowSubscription.SetProperty(

                        OnlineSubmissionWorkflowAssociationFeatureEventReceiver.HistoryListId,

                        workflowHistoryList.ID.ToString());

                    workflowSubscription.SetProperty(

                        OnlineSubmissionWorkflowAssociationFeatureEventReceiver.FormData,

                        string.Empty);

WorkflowSubscriptionService workflowSubscriptionService = workflowServicesManager.GetWorkflowSubscriptionService();

  if (workflowSubscriptionService.EnumerateSubscriptionsByList(documentLibraryList.ID).Count == 0)

   {

        workflowSubscriptionService.PublishSubscriptionForList(workflowSubscription, documentLibraryList.ID);

     }

  }

}

As the workflow definition Id is not defined, the workflow subscription Id is also becomes undefined. Therefore, the exception was thrown when trying to publish the subscription without a definition id, to the list.

Following are the steps followed to resolve this issue.

• Activate the Workflow Task Content Type site feature if not already activated.
• Activate the “Workflow service store” hidden feature. 

            In the SharePoint 2013 Management shell, run  the command, 

          Enable-SPFeature -Identity "workflowservicestore" -url "<sub site url>"

• Make sure the Service Bus Gateway, Service Bus Message Broker and also Workflow Manager Backend services are up and running in the WFE server. Also, all these services should be logged on using the same service account.  Restart the services. 
• Go to IIS Manager and check whether the Workflow Management Pool is running under Application Pools using the same service account. Restart the application pool.

Now the issue should be gone away.