SharePoint Best Practice Archive Summary 2007, 2010, 2013

Posted in: Blog, SharePoint 2007, SharePoint 2010, SharePoint 2013 | Jan 17, 2013 at 5:32 PM

No comments

INTRODUCTION

In this article I would like to summarize as many SharePoint Best Practice that I’ve found throughout the Internet. Microsoft has released a dedicated page for it but it contains only links to various sites which I think is a bit rigorous to read. But anyway, if you’re interested this is the link from Microsoft: http://social.technet.microsoft.com/wiki/contents/articles/8666.sharepoint-2010-best-practices.aspx?PageIndex=2.

TOPOLOGY

The least you should have is 2-server topology being one server dedicated for SharePoint and one server dedicated for SQL. With this topology all SharePoint services (eg. Search, user profile, etc) are run off the same server and users also access the same SharePoint server.

Ideally what you want is a 3-server (or more) topology being one server dedicated to run Central Admin and all SP services (including Search), one server for web-front-end (ie. the one that users access) and one for SQL.

SharePoint Search Service is always taking a lot of resources. Therefore, for better performance it’s better to separate this out of the Central Admin server.

SERVER RESOURCES

Make sure you follow Microsoft’s recommendation for your server requirements. I’ve been in many client sites which they only have 4GB of RAM on their SharePoint server and they complain why it performs so slowly.

Prior installing SharePoint make sure you check on Microsoft website the minimum server requirements:

http://technet.microsoft.com/en-us/library/cc262485.aspx

INSTALLATION AND CONFIGURATION

– Every service (including each Service Application and its corresponding application pool) needs to be configured using different service account. Do NOT use the Farm account to run all of these services. The reason being is, if a service goes down, you can easily identify which one it is. And not just that, SharePoint will automatically assign the right permissions to each account in SQL, IIS, etc. Therefore, your environment is a lot more secure using this approach.

– Put log files on a separate drive for better performance. There are 2 log files: SharePoint error log and usage analysis.

– Turn on only the services that are required to run eg. If you don’t need Excel Services then turn it off. Each SP service consumes server resources.

– Do NOT turn on Microsoft SharePoint Foundation Sandboxed Code Service. You may not agree with me on this one but this service is taking a lot of CPU resources and causing my server running a lot slower than it’s supposed to be.

– Don’t forget to allow delegation in AD for your SP_Profile and SP_ProfilePool (ie. user account used to run the User Profile Service crawl and the application pool). Otherwise, your User Profile service will not work properly.

– Name the database using friendly name. When you try to create a site collection, SharePoint will use something like WSS_Content_[GUID] as the name. Change that to something more friendly. The only database name that I don’t mind being “unfriendly” is the Central Admin content database. The main goal is for you to be able to identify which database is for which site so it’s more maintainable.

CODING AND DEVELOPMENT

– Do NOT dispose SPContext.Current.Web and SPContext.Current.Site.Web or you will get an error.

– DO dispose SPWeb and SPSite object if you construct it explicitly (eg. SPSite site = new SPSite(url); ) or else you will get memory leak problem.

– Use SPSecurity.RunWithElevatedPrivileges if you need a piece of code to be run using System Account access. Otherwise, your code will be executed using the context of the currently-logged-in user.

– As a general development practice, always log any exception to either SharePoint log or Event Viewer or your custom logging mechanism.

– Web.config VS “web service” for storing application settings. I usually use web.config’s appsettings section to store my application settings, however this has a drawback: if you deploy your application in a multi-server topology it means that you have to ensure that these app settings are copied across to the rest of the servers in the farm. You can use WSP to add/remove web.config settings automatically but this approach needs testing. Another way of storing application settings is through a centralised “storage” such as custom lists or SQL Server.

– If you deploy a custom application that accesses custom SQL Server database, ensure that you access using Windows Authentication instead of SQL login to ensure security. Ensure that your SharePoint site application pool has the appropriate access to your custom database or else your application will not be able to access the database.

– For custom content types and columns, I normally deploy using WSP however I have also created them manually directly on the site because sometimes WSP corrupts them. Using WSP it’s all more manageable. However, the downside is, if you ever removing a field or changing field type or adding a field, it may corrupt your content type. With manual addition though, the downside is you have to take note of the content types and fields you create and replicate them in the various environments you have (eg. UAT, Prod).

– ALWAYS have at least DEV, TEST and PROD environment. Some of my clients even have STAGING where they approve content. TEST is more for developers testing code and users to test functionalities (ie. UAT).

– Retrieving items from list, ensure you’re using SPQuery instead of just iterating the .Items property for a better performance.

CAPACITY PLANNING

– Make sure that the number of items in the list and document library doesn’t exceed the maximum Microsoft suggests. Although SP 2010 and 2013 can take a lot more items does not mean that we can take it for granted. There are two approaches with creating document libraries:

A centralised document library to store ALL documents and use metadata to filter. The benefit is, it’s less overhead to maintain it. The disadvantage is, the library can grow so big. Security is also a concern since you have to define permission at an individual document level.

Separate document library on different sites. The benefit is, permission is easier to define and we can manage and maintain the size easier. The downside however is maintenance overhead. Sometimes you just can’t locate where a document sits simply because you have too many lists. You can utilise Search but still…if you have multiple documents with similar name, depending on the ranking, you may not find the document you want easily.

– Determine whether you need to create a sub-site or a brand new site collection. A brand new site collection meaning that you can assign it to a totally separate database (ie. better for performance). The downside however, you lose navigational structure. With sub-sites the OOTB SharePoint navigation automatically displays your site. A brand new site collection however will not be displayed on your root site’s drop-down menu. Therefore, you have to either build your own navigational system or add the links manually.

– Use monitoring tool to frequently monitor your portal usage especially around SQL disk space. SP is very content-database centered and when disk space is running out, SharePoint can switch your side to Read-Only mode meaning that no one can Contribute (eg. checking-in/out documents, editing pages, etc).

– For developing using SharePoint web-services, make sure that you check if your code works under proxy. See more details on this article.

SECURITY

– Always use SSL whenever possible.

– Do NOT add individual user directly to SharePoint but instead use groups (or at the very least, add an individual user to a SharePoint group). This way it is easier to manage.

– I normally add NT AUTHORITY\Authenticated Users to the Reader group. This way everyone will have read-only access to your SP site and I don’t have to worry about people calling me requesting access. And not just that, if I’m not adding this group to the SharePoint Reader group, Search functionality sometimes play up ie. not returning the correct search results. I know the downside of this approach though that everyone in AD will by default have read-only access to the portal but I can always use the Site Policy to deny a specific group or user access to SharePoint.

My argument is, denying user access is simpler and quicker than having to deal with other SP issues (such as Search) that arise simply because we are not adding that group to SP.

– If you detach a site, list or list item from the parent permission ensure that you NEVER add an individual user to it. Instead, use groups even if there is only one user in that group.

CONTENT MIGRATION

– There are various ways to migrate content such as using the OOTB Content Deployment Tool (which I hate personally – sorry Microsoft, no offence), SP Deployment Wizard from CodePlex or writing your own tool using the SPImport and SPExport class from the object model.

The benefit of OOTB Content Deployment Tool is, it’s all integrated so you will save time “re-inventing the wheel”. It can also be scheduled. The downside however, it’s just very limited in terms of options and often fails 🙁 It can’t also do partial deployment (eg. single document)

The SP Deployment Wizard is really great whereby you can migrate even down to a single document/list item. The downside however you can’t schedule it. If you want to do a migration you have to fire it up manually.

The last but not least is your custom code script using SPImport/SPExport (or Powershell). The benefit is, you can schedule them, you can do whatever you like. The downside is, it takes time to write and still needs to be tested. One thing to watch out is, if you ever schedule your code, ensure that your code can run without needing any user to be logged in to the server. There is an option in Task  Scheduler that you can set.

– Migrating content from STAGING to PRODUCTION has its own challenges. I give you an example: one of my clients has a STAGING environment where authors approve content for their website. Only the approved content need to migrated to the PRODUCTION site. The draft-s will remain draft in STAGING until submitted for approval and approved. My challenge is, how do I ensure that only the approved pages exported including their dependencies (eg. images or documents)? Plus, if I want to retain the version (ie. if it’s version 2.0 in STAGING then it has to say version 2.0 in PRODUCTION), how can I do that easily? Also, we can’t simply re-create or overwrite the page in Production because the ID to either the page or its dependencies may be different and may cause problems.

I’ve tried using one of the approaches above and none of them worked properly. The OOTB Content Deployment simply failed straight away because it can’t export down to an individual page. The Configuration Wizard is great but it can’t be scheduled. So my only option is using custom code. It will take a lot of testing to make this work.

Therefore, my last solution is to use Site Collection backup/restore. It works really-really great because I can schedule it, it will definitely retain all IDs and dependencies. The downside however, any references to any of the server services is not working properly. For example, we had some search scopes in STAGING but when we restored the site collection to PROD, the scopes were missing because they referenced STAGING’s Search Service. But other than that, for this scenario the site collection backup/restore is the most suitable method.

WORKFLOWS

– SP Designer is great for simple-medium-level-complexity workflows.

– Visual Studio workflow is great for medium-top-level complexity workflows. Plus it requires testing and the whole software-development “shebang”.

– Third party workflows such as K2 and Nintex are great to do both simple-top-level-complexity workflows except you have to pay expensive licenses. And not just that, you will need some trained resources to manage these workflows.

INFOPATH

There are two ways of developing InfoPath forms:

– Using InfoPath Form Template in Central Admin

The benefit is, you have access to ALL controls and functionalities available in InfoPath. Updating and migrating your form template from one environment to another is quiet straight forward. The downside is, you are missing connection to the individual list item. Ie. When you submit an InfoPath form, it normally submits to a document/form library. If you create custom columns in the document library and want to reference it in your form template it will be very difficult.

– Using Customize Form button in Custom Lists

Only works on Custom Lists and the benefit is, you gain direct access to the custom columns you created on that list. You can export easily by simply exporting the list template. The downside is, you have a lot less functionalities of InfoPath.

Which approach is the best? Again, it all depends on your requirements.

CONCLUSION

Surely there are other best practice items that can be added to the list. Therefore, please feel free to write a comment and I’ll include the suggestion on the post.

Cheers,

Tommy

No Comments Yet.