Category Archives: Blog

iCiber – delivers expert support for SharePoint, IT Operational improvements, Transition & Transformation Programs, Troubleshooting & Performance challenges

Founded in 2016, iCiber delivers expert support for SharePoint, IT Operational improvements, Transition & Transformation Programs, Troubleshooting & Performance challenges. Focus of iCiber is on the Microsoft platforms (e.g. SharePoint, Exchange, Office365, Azure, SQL). Our colleagues from iCiber are Microsoft MVP (Most Valuable Professional) or similar levels. iCiber has significant expertise in delivering operational services from offshore centers.

Areas of expertise: Migration of Service Desk Services, Local Support Services, Cross Functional Services (processes & procedures), Mail Services, File Services, Live Collaboration Services (Skype for business), Computer Device Services (Windows 7/Windows 10), Print & Scan Services, SharePoint Services, Stepping Stone Services and Server Management Services, Performance and Operational improvements large SharePoint environment (>50.000 users), Performance and Operational improvements large Exchange environment (>90.000 mailboxes), SQL, VMware


Thirteen pitfalls of SharePoint migration and how to avoid them

In this article, I describe the thirteen most prominent pitfalls that I have encountered in the SharePoint migration projects of various organisations.

1. Lack of knowledge

What is SharePoint exactly? Knowledge is the key. It does not matter from which to which version of SharePoint one migrates: it is important that those who are involved in the migration project possess adequate knowledge about SharePoint. The SharePoint platform is linked to many other components of the IT landscape, including: SQL servers, IIS application servers, DNS & Active Directory, custom .NET code and networks. A good (migration) project team consists of people who are knowledgeable about all these other components. Hence, a strong project team is the foundation of a successful SharePoint migration.

2. Insufficient end user training

Training is essential for a good understanding of SharePoint’s features. End users often think in terms of folder structures instead of metadata, or do not know how to properly use SharePoint’s authorisation structure. This means a single click can make sensitive content available to the entire organisation, which is not desirable. Lack of knowledge also prevents one from efficiently making use of all the possibilities offered by the platform. Well-trained end users and managers can also help the ‘SharePoint oil spill’ to spread within the organisation.

3. Lack of communication about the upcoming changes

It is important to keep the organisation updated about the upcoming changes: a solid communication plan will help. Adjust the communication plan to the project’s planning so employees will stay informed during the execution of the migration plan. Here are some communication tips to stimulate employee involvement:

  • Try to get some time in the various department meetings to present the migration plan there.
  • Organise short sessions for the end users in which the changes are explained.
  • Give demos of new features which will simplify existing corporate processes.

4. ‘Garbage in = garbage out’

‘Garbage in = garbage out’. Make sure the existing SharePoint environment is as proper as possible. Do not migrate a SharePoint environment where erroneous data is the cause of malfunctions. If the existing environment’s content is not proper, then it will not be proper after the migration. Clean up the existing data as much as possible: you will prevent mishaps in the new SharePoint environment.

5. Underestimating SharePoint architecture

SharePoint 2013’s architecture has changed much compared to that of SharePoint 2010. Many new features have been added. The social aspect of SharePoint 2013 has been updated, and now has:

  • continuous content crawl to keep the search index up to date;
  • request management;
  • distributed cache;
  • and many other features.

So much has changed in SharePoint 2013 that you will need to revisit the entire architecture and cannot migrate on the content database level.

6. No “good” assessment of the existing environment

A good assessment of the SharePoint environment that is to be migrated is vital. There are many factors which can cause a SharePoint migration to fail and a migrated website to function incorrectly. You will want to identify these causes beforehand. Think of custom code, work flows, content editor web parts with scripts, etc. Using a simple Powershell script, it is possible to make a good assessment of the SharePoint environment that is to be migrated. Using the assessment, you can determine the main focus of the migration and which matters need to be resolved first. It is also possible to use the ‘site collection health check’ tool in SharePoint 2013. This tool checks a 2010 site collection to see if it is eligible for upgrading. For more information about this tool, go to:

7. Not testing

Test, test, and test again. It is one of the most important parts of the migration project. First test a migrated website in a testing or acceptance environment before migrating it to a production environment. Have the website owners/end users test the migrated website as well. An end user can detect errors even if a migration has been executed in a technically proper way. A good migration strategy takes into account the testing of rights, navigation, style and content.

8. Wanting to do everything yourself

Depending on the size and complexity of the SharePoint environment that is up for migration, it can be much cheaper to purchase a 3rd party tool instead of migrating manually. Ultimately, a 3rd party tool will save on costs and time. For a nice overview of available migration tools for SharePoint, go here:

9. The steps are too big

Work towards the finish line in incremental changes. For many end users, the gap between SharePoint 2007/2010 and SharePoint 2013 is wide. It is therefore important to execute changes one by one during the migration project. If at all possible, involve end users in every step of the way. My advice is to introduce SharePoint gradually instead of in one go.

10. No governance has been implementend

It is becoming increasingly important to have a proper governance document for a SharePoint environment. This document describes the rules, responsibilities and roles related to using SharePoint. The internet offers websites that will help you set up SharePoint governance. Here you will find Microsoft’s ‘white paper’ for the planning of SharePoint governance::
The lack of a proper governance document can cause:

  • information to be increasingly harder to find;
  • conflicts to erupt between IT and the business;
  • user satisfaction to drop;
  • the lack of a good authorisation model;
  • bad performance of the SharePoint environment.

11. Style has been forgotten

This matter is often underestimated when it comes to a SharePoint environment. The lack of a native style in a SharePoint environment will not directly cause the migration to fail. However, it plays an important role in improving users’ acceptance of the new SharePoint environment.

12. No plan for rollbacks

Why is a strong rollback plan necessary if there is a strong migration plan? Most migration problems that are caused by, for instance, unidentified custom work can be resolved. But recovering a non-functioning rollback plan is not possible. Therefore, you should always ensure there are good backups on the file and database levels before the migration commences. For this reason, an ‘in place’ migration is not recommended.

13. Lack of goals

The entire SharePoint migration has been carried out and the organisation now uses SharePoint 2013. But has the migration been successful? You should define a number of assessable goals beforehand that ought to have been accomplished after the migration has been completed. There are certain tools, for example those that can analyse user data, which can aid in the formulation of assessable goals.


SharePoint migrations offer an organisation an opportunity to clean up content, implement changes and realise the ultimate SharePoint vision. SharePoint migrations are much more than just a technical project, and should be well thought-out and planned; otherwise, there is no chance of a successful migration.

PowerShell error: The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

When you run SharePoint management powershell on your SharePoint 2010 server you get the following error:

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered



Make sure the logged in user has the correct rights to the SharePoint_Configuration database

  • SharePoint_Shell_Acces or:
  • DB_reader or DB_writer

Use the following Powershell cmdlet to give this user the correct databases permissions, since Direct database changes are not supported by Microsoft: Add-SPShellAdmin (


sql maintenance plan

SQL Maintenance Plan SharePoint 2010 databases

To maintain good overall databases performance of the SharePoint 2010 databases I use the following SQL maintenance plan. This plan consist of two main parts: – The configuration of each separate databases and database properties settings – The automated maintenance plan, to perform database maintenance task once a week.

Please note: For most of the SQL tweaks to perform on a LIVE SQL database you will need the Enterprise edition of SQL 2008 R2. Otherwise you need to put the databases offline before executing the maintenance plan as described in the article.

Databases Types SharePoint 2010 has three types of databases: – System/Configuration databases (do not include these databases in the maintenance plan) – Service Application databases – Content Databases

Powershell created databases I always create SharePoint databases with a powershell script and not with the default auto-provisioned functionality. The advantages of this approach are: – guaranteed control over database names (no GUIDs in the database names) – guaranteed control over database sizing – procedural separation of control over application and data environments

Data Integrity To prevent database corruption we need to protect the SharePoint databases. There are two kinds of database corruption: – Physical corruption, might occur when the disk that holds a log file or data file has been altered. This type of physical corruption tends to affect sectors on a disk due to problems in the I/O subsystem, such as the physical network hardware and disk drives themselves. – Logical corruption is caused by data being altered in some unanticipated way that severs a data relationship. This type of corruption usually is caused by an application error or human error that causes data problems but doesn’t affect the physical structure of the database.

To prevent and detect any kind of databases corruption issue I use the SQL function DBCC_CHECKDB in the maintenance plan. The only downside is that if any error occurs from this check the only solution will be to restore the database from a backup.

Managing Database files The recommendation for the SharePoint SQL environment is to place log files and data files on different disks and to ensure that no other application uses those disks. This setup minimizes overall write access to the disks, and lessens the opportunities for file fragmentation.

Measuring and Reducing database index Fragmentation Index fragmentation can result in performance degradation and inefficient space utilization, and indexes may become quickly fragmented on even moderately used databases. In SharePoint 2010 a table that often becomes fragmented is AllDocs, which contains document libraries, their associated documents and lists and list items, and their respective metadata.

SQL Server Fill Factor The fill factor of each SharePoint databases needs to be set to default. Default the way the database fill factor defines how much free space is required on a database page during an index rebuild before moving to a new database page. Otherwise the database takes more database space because the database pages are larger. Instead we sill set the default fill factor for the whole SQL server, a server-wide setting of 80% is optimal to support growth and minimize fragmentation.

Shrinking Databases SQL Server 2008R2 has the ability to shrink data files, which recovers disk space by removing unused data. The best way is not to set the shrinking of the databases in SharePoint to automatically shrink the data files. Also not to configure a maintenance plan that does it automatically on a SharePoint database. The reason is that the database auto-shrink ignores the fill factor setting and causes all the indexes to become fragmented. Then, when you run a rebuild indexes command, the database grows back to its original size. 

Instead of auto-shrinking databases on SQL, it’s safer to partition content databases or to remove data from existing databases on SharePoint 2010 level.

Recommended Database Maintenance plan for SharePoint 2010 All tasks to prevent the issues that can occur are being automated within a SQL 2008 R2 maintenance plan. Normally I will schedule this maintenance plan for once a week but in some environments (where there are a lot of changes in the SharePoint environment) you can choose to execute the maintenance plan more often.

1. The maintenance plan contains the following steps:

  • Remove excessive transaction log file fragmentation by ensuring the appropriate recovery model and backup schedule.
  • Turn off any scheduled shrink operations to reduce the risk of unnecessary index fragmentation.
  • Put a regular process in place to detect and remove index fragmentation.
  • A process to run DBCC CHECKDB.
  • A maintenance plan should include either index reorganization or index rebuilding (never use both).
  • Update Statistics

2. The configuration of each database:

  • Turn on AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS, and have a regular process in place to update statistics.
  • Turn on instant file initialization such that database auto-growth is an instantaneous operation rather than a slow operation that requires zero-filling new space.
  • Place Database and log files on different SAN disks.
  • Set auto-growth correctly by using a predetermined set file size rather than a percentage. Follow this up by periodically examining database sizes and determining whether manual database growth is necessary to ensure optimum Performance.
  • Turn on page checksums.

Enable FILESTREAM on SQL Server 2008R2

FILESTREAM is a  feature of SQL 2008 that supports BLOB file storage on NTFS file shares.  This feature is also supported by SharePoint 2010, but first you’ll need to enable the feature in SQL 2008R2 server, default the  FILESTREAM feature is disabled during the SQL 2008 installation.

To enable FILESTREAM feature on SQL Server 2008:

  1. Open SQL Server Configuration Manager (Start > Programs > Microsoft SQL Server 2008 > Configuration Tools > SQL Server Configuration Manager)
  2. Navigate to the SQL Server Services node and select the SQL Server instance you want to modify SQL Server (MSSQLSERVER)
  3. Click the FILESTREAM tab and select the checkboxes to enable FILESTREAM and enter a share name for the files, as shown