The “Soft” part of SharePoint - Part 3, Solution intake process

Where developer should have a standard SharePoint Development process, which describes the development best practices in your environment, should every SharePoint administrator have a solution intake process.

Poorly implemented custom solutions can introduce security or performance risks, increase the cost of support, complicate deployment, and reduce productivity. Over the past years I have seen that developers do not always know how to develop good solutions for SharePoint. Even though SharePoint is build on .NET, developing for SharePoint is a totally different discipline than developing for .NET. More than often I have seen developers delivering code that was either seriously affecting the environment, not using the SharePoint deployment framework or very poorly documented.

In order to guarantee quality, it is very important to create a solution intake process. The process verifies if certain best practices have been followed and the solution is safe to deploy the environment:

• Create a code acceptance checklist for the developer to fill out.
• This checklist forces developer to sign off their solutions against a list of Best Practices.
• Check the code using SPDisposeCheck.
• This tool checks the custom code for memory leaks and proper use of disposable objects.
• Check deployment documentation.
• Check if the deployment documentation is correct and contains the required information.
• Check solution package
• Check if the solution package is created properly, using the Solution Deployment framework technologies.

If you want to have a good example of a solution intake process, Microsoft has released some documents for their SharePoint Online cloud service. Their intake process is really strict and requires the developer to design, document and test the solution before handing it over to Microsoft. They have published their process in the following documents:

• SharePoint Online Dedicated Custom Solution Policies and Process (October 2010)
• SharePoint Online Dedicated Custom Solution Developers Guide (October 2010)

More information:
Check list example: http://technet.microsoft.com/en-us/library/cc707802.aspx
SPDisposeCheck: http://code.msdn.microsoft.com/SPDisposeCheck
Using Disposable Object: http://msdn2.microsoft.com/en-us/library/aa973248.aspx

[SP2010] Issue migrate Classic to Claims authentication

[SITUATION]
Currently I am working at a customer where we have to migrate SharePoint 2007 data to a new SharePoint 2010 environment. Security ACLs on the SharePoint 2007 data are registered in the old SharePoint 2007 way (called Classic in SharePoint 2010). In order to use claims these ACLs need to be converted into Claims ACLs.

[ISSUE]
On the TechNet site I discovered this article. Unfortunately when performing these steps (running a PowerShell script), it did not work. As with many issues, SharePoint doesn't give any clue what might be wrong :-(

[SOLUTION]
After some troubleshooting I remembered an issue I had back in MOSS2007. There I tried to perform an activity on a site collection, which did not work. It turned out that I did not have permissions on the site collection. To solve that, I granted myself "Full Control" permissions via the "Policy for Web Applications" page, after which the activity worked fine.

To test this theory, I tried the following steps:

1. Create a new web application
2. Create a new site collection
3. Add some data and set unique permissions
4. Grant my admin account Full Control permissions for the web application
5. Run the PowerShell script to migrate the web application to Claims

and see here, the script now runs just fine and migrates all Classic ACLs to Claims ACLs!!

[NOTE]
Microsoft has confirmed that there are some issues with the Classic to Claims migration. According to them, Service Pack 1 will include a tool which should be able to successfully migrate Classic to Claims. So either test your migration thoroughly or wait for SP1 (expected end Q2/beginning Q3)!!