SharePoint 2010 on Windows 7

It is really cool that we can install the SharePoint 2010 on Windows 7 even though the installation is not as smooth as on Windows 2008 servers but following the explanation given in the msdn article, we can get it to work.

I installed the SharePoint 2010 on Windows 7 (x64), 99% of the installation completed but it failed in executing the dbwrap.exe with the following message in the log file.

Executing command path: 'C:\Program Files\Common Files\Microsoft Shared\SERVER14\Server Setup Controller\dbwrap.exe', args: 'timeout=2950'

You can find the log file at C:\Users\[User name]\AppData\Local\Temp\SharePoint Server Setup(201008052159032560).log

To get around this, check the and see whether the SharePoint instance of the sql express is installed in your machine, most likely not, then manually, install the SharePoint instance of sql express and run the configuration wizard to complete the configuration.

This solved my problem and finally I have a stand along SharePoint 2010 in my Windows 7.

Adding a new federated location to search service applicaitons.

As we know the Shared services provider is gone in SharePoint 2010 and instead we have a nice SharePoint service application model. I do not try to explain the difference in details as I found some nice well written article readily available and hit easily by googling. The way I understand, in brief, the consumers can access the service application using the service application proxy which knows how to find out where the application is running. I think that is enough here and my focus is to tell you how to add a new federated location to a search service application.

I recently played with the search service application and I had to add a federated location to the search application automatically, we did that in SharePoint 2007 using SearchContext but it is not an option here in SharePoint 2010, SearchContext is still available but that is marked as obsolete.

So way to do is, by getting all the search service application and iterating through them and adding the new federated location if it is not already existing.

The challenge is how to get all the search service application in the farm.

First get all the services using the SPFarm.Local.Services, and iterate through all the services and find the services of type SearchQueryAndSiteSettingsService. The search applications can be found there.

//Get all the services in this farm
services = Microsoft.SharePoint.Administration.SPFarm.Local.Services;

//Iterate through all the services to find the SearchQueryAndSiteSettingsServices
foreach (SPService service in services)
{
//All Search service applicaitons are under SearchQueryAndSiteSettingsService
if (service is SearchQueryAndSiteSettingsService)
{
//Get all the search service application.
serviceApplicaiton = service.Applications;

foreach (SPServiceApplication applicaiton in serviceApplicaiton)
{

//Check whether the application is a search service application
if (applicaiton is SearchServiceApplication)
{

//This is a search service applicaiton
searchApplication = (SearchServiceApplication)applicaiton;

//Check whether the new location is already added.
if (!IsLocationExists(searchApplication.LocationConfigurations))
{
//Create a new locaiton
federatedLocation = new LocationConfiguration();

//Import the federated location
GetStream(ref filestream);

federatedLocation.Import(filestream);

searchApplication.AddNewLocationConfiguration(federatedLocation);
}
}
}
}
}

Binding asynchronous event handlers as synchronous

In SharePoint, we know, there are two types of event receivers, asynchronous and synchronous, for example, the ItemUpdating and ItemUpdated. The ItemUpdating is synchronous while the ItemUpdated is asynchronous. The obvious difference is, the synchronous event is raised before committing the changes so that we have the opportunity to cancel whatever the the operation but not in the asynchronous event as that is raised after successfully committing the changes requested.

With that simple description I will dive direct to the specifics as there are plenty of information available about event handlers in SharePoint out there. From here on, I will make a safe assumption that you know about the event handler in SharePoint and also how to write simple event handler.

With that I will explain my finding on how to bind the asynchronous event handler as synchronous as this will help us in some scenarios.

By default, using the object model, we can register the event handlers by,

parentList.EventReceivers.Add(SPEventReceiverType.ItemAdded, Constants.AssemblyName.EventManagement, className);

parentList.Update()

This will bind the event handler to the list using the default binding depending on the type of the event, for example, if it is ItemAdding, binding is synchronous and ItemAdded the binding is asynchronous.

Another way of registering an event handler to a list is by creating an empty handler and setting the values separately,

//Create the event handler
itemAddedEventReceiver = parentList.EventReceivers.Add();

//Set the values for the item added event receiver
itemAddedEventReceiver.Name = NameOfItemAdded;

//Set the binding
itemAddedEventReceiver.Synchronization = SPEventReceiverSynchronization.Synchronous;

itemAddedEventReceiver.Type = SPEventReceiverType.ItemAdded;
itemAddedEventReceiver.Assembly = Constants.AssemblyName.EventManagement;
itemAddedEventReceiver.Class = className;
itemAddedEventReceiver.Update();

parentList.Update();

Main advantage of registering event handlers in the second way, is, probably obvious by now, we can change the binding, so we can register the asynchronous event handlers such as ItemAddeded with binding set to synchronous as below.

itemAddedEventReceiver.Synchronization = SPEventReceiverSynchronization.Synchronous;

This way it is guaranteed that both ItemAdding and ItemAdded are completed synchronously. The main advantage I found here is, consider the document library and if you need to perform an automatic operation whenever a new document is added, you can do that in the ItemAdded event handler and modify the the list item and save it with the modified data within ItemAdded event handler, this works well with the multiple document updated as the multiple document update raises only ItemAdding and ItemAdded, but in the case of single document upload, as a standard feature in document library, just after the document is uploaded, SharePoint opens the list item in property edit page to enter the new property values, now since we modify the list item in ItemAdded asynchronously, the version of the list item in the property edit page is not the one we saved in ItemAdded event handler as a result when we attempt to save the new properties, we will get the unfortunate save conflicts.

So this can be avoided by registering the ItemAdded event handler to work synchronously, then the property edit page will be opened with the updated list item and not the original one.

We must use internal names.

Recently I was testing the application we designed and developed in SharePoint 2007, on SharePoint 2010, the main and least expected  problem that I discovered was the usage of display names to retrieve the values of the some fields. During the development, of course we had a common understanding to use the internal name whenever we deal with the fields as that is the unique  for the SPField but we have slipped few places and never  used the internal names, these retrieves were happened to be in the workflow module where we retrieve the field values from the workflow task list items, to edit  the respective tasks. Fortunately, the display names of some fields of the task list are changed from 2007 to 2010, I said, fortunately, because, if it is not for this, the bug will stay dormant in our production code for bit longer time.

Even this is a well know fact, I decided to share this finding with the development community to re-emphasize the usage of internal names and also to highlight the changes  in task list.

The problem I encountered is, in the task list for work flows, some of the display names are differrent in 2010. For example, we had a "Link" field in 2007 and the same field is renamed to "Related Content" in 2010, but the good thing is, the internal name remain the same  "WorkflowLink".

For the help of the beginners, this probably the way to go.

private object GetFieldValueByInternalName(string internalName)
{
              object rawValue = null;
              SPField fieldToExamine = null;

              if (null != TaskListItem)
             {
                   //Get the field by the internal name
                   fieldToExamine = TaskListItem.Fields.GetFieldByInternalName(internalName);
                 
                  if (null != fieldToExamine)
                 {
                         //Field does exist, get the value
                         rawValue = TaskListItem[fieldToExamine.Id];
                  }
             }
             return rawValue;
}

How do I know whether the list item is in a DocumentSet.

Document sets in SharePoint 2010 is a cool feature and while I was exploring the power of the document sets, I wanted to find out whether a given list item in a document library, is part of the document set or not. We might need to make this kind of decisions in event receivers.

I publish this in SharePoint forum and found a better way to do that thanks to Steve Curran, this is the link to the original thread in the forum.

http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/bfac0310-6efd-4855-a9f6-11b8ffdc35b1/#f260d5ef-4947-4148-b91a-c52e59aba047

I decided to share this information here also as I did not find any lead while googling. Hoping this will provide some kind of a lead for the others who are after similar solutions.

Start the real stuff, this interesting functionality is available in Microsoft.Office.DocumentManagement.dll, there is a separate name for document sets called
Microsoft.Office.DocumentManagement.DocumentSets. Using this you can write..

public bool IsDocumentSetItem(SPListItem itemToCheck)
{
bool documentSetItem = false;
DocumentSet documentSet = null;

if (null != itemToCheck)
{
if (null != itemToCheck.File)
{
documentSet = DocumentSet.GetDocumentSet(itemToCheck.File.ParentFolder);

if (null != documentSet)
{
documentSetItem = true;
}
}
}

return documentSetItem;
}


I wish to have this as a property of SPFolder but the DocuemntSet class is handy also.

Workflows in SharePoint 2010

I thought of sharing what I found with workflows in SharePoint 2010 today as all the others using the object model to associate the workflows to lists or list items will face the same night mare.

The main problem may be a bug in beta and hopfully MS will fix this in the final release. The problem is, we can get the workflow template collection using the workflow manager in 2007 using WorkflowManager.GetWorkflowTemplatesByCategory(). but this does not return the workflow template collection in 2010.

The work around I found is, in 2010, SPWeb.WorkflowTemplates is working and which is returning the workflow template collection for the given web. So we can use this property and get the workflow template collection for the root web of the site or any web as it does in WorkflowManager.GetWorkflowTemplatedByCategory().

I hope this will be fixed in the final release so that we can use the workflow manager to get the workflow template collection but certainly I do not see any difference in using SPWeb property also. I hope MS will have some kind of a better explaination for this behaviour.

Security model in SharePoint 2007

Background

I am currently working on SharePoint integration project and required to understand the security model used in SharePoint in order to get a better and smoother integration with the other systems, the very basic understanding I had was the security in SharePoint is based on ACLs similar to windows, I worked faire way with this assumption until I practically couldn’t achieve the expected result so I decided to get myself dirty and went through the SQL database hacking in order to make myself clear of how it all works.
For those who are wondering, what is ACL, here is a bit of a description. The ACL stands for Access control list and which is a collection of ACEs (Access control entry), the access control entry basically in the windows ACL, mainly contains who or what is allowed or denied access to the given resource and at what level.
To make the subsequent explanation of SharePoint permissions more clear, I will just provide a simple description about the related SQL schema a bit below before the more interesting stuff at the end.

Content database

There are four main tables in the content database that I found important in understanding the access control process in SharePoint. Those are UserInfo, Groups, Perms and Roles tables. Their UserInfo table keeps all the SPUsers including the AD Groups and custom groups by the custom role providers. The groups table keeps all the SPGroups. The Perms table keeps the map of the Acl against the url of the respective list, site or item and the Roles table keeps the permission levels against their respective permission mask. The permission level is explained below.
Representation of the ADAM groups and other custom groups in the UserInfo table behaves quiet different to the AD groups and the explanation of them requires a separate post and that is my next post.

Permissions in SharePoint

In SharePoint there are 33 different permissions possible even though the selection of those permissions are grouped together with the related ones and hence the more granular manual selection is not possible from the SharePoint UI but it is possible by manipulating the permission bit mask by using the SPBasePermissions enum in object model or accessing the SQL tables direct, which I will be explaining in the next section and this process is not a very clean way of doing this so my strong recommendation is not to touch the production versions unless it is badly required for debugging and fixing problems.
Permission levels in SharePoint
Permission levels in SharePoint in my simplistic understanding are a way of grouping of permissions and make the assigning process easier for the SPGroups and SPUsers. The Roles table explains above keeps the permission levels and their respective bit mask for the assign group of permissions.

Access control

This is the main part that I wanted to explain in this post to share the un-document stuff in SharePoint. If you happen to open the content database and open the Perms table you will see the Acl column with a hex byte stream as shown below.

OxF3FE000001000000000000000400000003000000FFFFFFFFFFFFFF7F22000000FFFFFFFFFFFFFF7F23000000FFFFFFFFFFFFFF7F24000000FFFFFFFFFFFFFF7F

First 16 bytes is the header and this contains 4 sets of 4 byte blocks.
F3FE0000010000000000000004000000 => F3FE0000 01000000 00000000 04000000
The 4 th byte tells the number of ACEs in this ACL, I do not have any good guesses for the other bytes but I think there may be a checksum in one of those remaining 3 sets.

03000000
FFFFFFFFFFFFFF7F

According to this ACL, there are 4 ACEs and those 4 ACEs contain 4 sets of 12 bytes. The 12 bytes are also grouped in 3 sets of 4 byte groups. For example the first ACE is shown below.
The first set of 4 bytes represents the unique ID of the corresponding entry (Raw which represents a user or a group) in UserInfo or Groups table in context database and the subsequent 2 sets of 4 bytes represent the bit mask for the SharePoint permissions. There are only 33 permissions available in MOSS 2007 and only the bits given in the SPBasePermissions enum are in use while the other are not in use at least for this version.
Note the bytes in the group of four sets bytes ate arrange in the reverse order and if you happen to look at the Roles table for the bit mask for the respective permission level, you will find it under PermMask column as a big integer.

Conclusion

The access control in SharePoint is purely based on the permissions and permission levels stored in the Roles table. As I mentioned the permission mask for a given permission level is not granular down to the each permission from the SharePoint UI, my understanding for this is to make it more convenient for the users at the user interface level and avoid mistakes but if you need to create your own custom permission level, you could do that in a dirty way by modifying the respective permission mask in SQL database or a slightly a better approach is to use SPBasePermissions enum in object model.

And finally the SharePoint ACL is working purely based on the permission masks, users and groups. The way this ACL works is different from the way Windows ACL works but for the basic concepts, it can be seen as a collection of ACEs