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

www.iCiber.nl

pitfalls

Dertien valkuilen bij een SharePoint migratie en hoe deze te voorkomen

In dit artikel beschrijf ik de dertien belangrijkste valkuilen die ik tegen ben gekomen tijdens SharePoint migratieprojecten bij verschillende organisaties.

1      Gebrek aan kennis

Wat is SharePoint eigenlijk? Kennis is ‘the key’. Het maakt niet uit van welke versie naar welke versie van SharePoint wordt gemigreerd: het is van belang dat degenen die bij het migratieproject betrokken zijn een goede kennis van SharePoint hebben. Het SharePoint platform heeft veel raakvlakken met andere componenten in het ICT landschap zoals: SQL server, applicatie IIS server, DNS & Active Directory, maatwerk (.NET code), netwerk. Een goed (migratie) projectteam bestaat uit mensen die kennis hebben van alle raakvlakken. Een goed projectteam vormt dan ook de basis voor een goede SharePoint migratie.

2      Onvoldoende training voor de eindgebruikers

Training is essentieel voor een goed begrip van SharePoint functionaliteiten. Vaak denken eindgebruikers nog in folderstructuren en niet in metadata. Of eindgebruikers weten niet op een juiste manier de autorisatiestructuur in SharePoint te gebruiken. Gevoelige content kan dan met een druk op de knop beschikbaar zijn voor de hele organisatie en dat is niet wenselijk. Gebrek aan kennis staat ook een efficiënt gebruik in de weg van alle mogelijkheden die het platform biedt. Goed getrainde eindgebruikers en beheerders kunnen ook helpen om de olievlek “SharePoint” binnen een organisatie verder te verspreiden.

3      Gebrek aan communicatie over de aankomende veranderingen

Het is van belang om de organisatie op de hoogte te houden van de aankomende veranderingen: een goed communicatieplan helpt hierbij. Stem het communicatieplan af op de project planning zodat de medewerkers tijdens de uitvoering van het migratieplan geïnformeerd blijven. Communicatietips waarmee betrokkenheid van medewerkers gestimuleerd wordt:

  • Probeer tijd te krijgen bij de verschillende afdelingsoverleggen om daar het migratieprojectplan te presenteren
  • Organiseer korte sessies voor de eindgebruikers waarin de veranderingen uitgelegd worden
  • Geef demonstraties van nieuwe functionaliteiten waarmee bestaande bedrijfsprocessen vereenvoudigd worden.
4      ‘Garbage in = garbage out’

‘Garbage in = garbage out’. Zorg voor een bestaande SharePoint omgeving die zoveel mogelijk op orde is. Ga geen SharePoint omgeving migreren waarin foute data de oorzaak is van storingen. Als de content in de bestaande omgeving niet op orde is, dan zal dat ook niet het geval zijn na de migratie. Schoon data in de bestaande omgeving zoveel mogelijk op: het voorkomt ellende in de nieuwe SharePoint omgeving.

5      Onderschatting van SharePoint architectuur

SharePoint 2013 architectuur is sterk verandert ten opzichte van SharePoint 2010. Er zijn veel nieuwe features bijgekomen. Het sociale aspect van SharePoint 2013 is vernieuwd, zoals:

  • het continue crawlen van content om de search index actueel te houden;
  • request management;
  • distributed cache;
  • en nog vele andere features.

Er is in SharePoint 2013 genoeg veranderd om de gehele architectuur te herzien en niet op content databaseniveau te gaan migreren.

6      Geen “goede” inventarisatie van de bestaande omgeving

Een goede inventarisatie van de te migreren SharePoint omgeving is een must. Er zijn vele oorzaken waardoor een SharePoint migratie mislukt en een gemigreerde site niet juist functioneert. Deze oorzaken wil je van tevoren identificeren. Denk hierbij aan maatwerk, workflows, content editor webparts met script, etc. Met een eenvoudig Powershell script is het mogelijk om een goede inventarisatie te maken van de te migreren SharePoint omgeving. Met de inventarisatie bepaal je waar het zwaartepunt van de migratie komt te liggen en welke punten eerst opgelost moeten worden. Daarnaast is het ook mogelijk om gebruik te maken van de “site collection health check” tool van SharePoint 2013. Deze tool controleert een 2010 Site Collectie of deze geüpgraded kan worden. Kijk voor meer info over deze tool op: http://technet.microsoft.com/en-us/library/jj219720%28v=office.15%29

7      Niet testen

Testen, testen en nogmaals testen. Eén van de belangrijkste onderdelen van het migratietraject. Test eerst een gemigreerde site op een test- of acceptatieomgeving voordat je de site naar een productieomgeving migreert. Laat ook de site-eigenaren/eindgebruikers de gemigreerde site testen. Technisch kan een sitemigratie juist uitgevoerd zijn zonder problemen, terwijl de eindgebruiker toch fouten ontdekt. Een goede migratiestrategie houdt rekening met het testen van rechten, navigatie, huisstijl en content.

8      Alles zelf willen doen

Afhankelijk van de omvang en complexiteit van de te migreren SharePoint omgeving kan het veel voordeliger zijn om een 3th party tool aan te schaffen dan handmatig te migreren. Een 3th party tool werkt uiteindelijk kosten- en tijdsbesparend. Kijk hier voor een goed overzicht van beschikbare SharePoint migratie tools: http://SharePoint-community.net/page/sp-migration-tools

9      Te grote stappen

Werk met kleine veranderingen per keer naar de eindstreep toe. Voor veel eindgebruikers is de stap van SharePoint 2007/2010 naar SharePoint 2013 groot. Het is daarom van belang om veranderingen stap voor stap door te voeren tijdens het migratietraject. Betrek de eindgebruikers waar mogelijk bij alle stappen van het migratietraject. Ik adviseer dagelijks om  SharePoint geleidelijk in te voeren, in plaats van in één keer.

10 Geen governance doorgevoerd

Het wordt steeds belangrijker om een goed governance document te hebben voor een SharePoint omgeving. Hierin worden de regels, verantwoordelijkheden en rollen beschreven voor het gebruik van SharePoint. Op het internet zijn goede sites te vinden om SharePoint governance op te zetten. Hier vindt u de “white paper” van Microsoft voor het plannen van SharePoint governance: http://technet.microsoft.com/en-us/library/ff848257.aspx Het ontbreken van een goed governance document kan tot gevolg hebben dat:

  • informatie steeds moeilijker te vinden is;
  • conflicten ontstaan tussen IT en de business;
  • de gebruikerstevredenheid daalt;
  • er geen goed autorisatie model meer is;
  • er een slechte performance van de SharePoint omgeving optreedt.
11 Huisstijl vergeten

Dit punt wordt vaak onderschat bij een SharePoint omgeving. Het ontbreken van een bedrijfshuisstijl in een SharePoint omgeving is niet direct een punt waarop de migratie zal mislukken. Het is wel een belangrijk punt om de acceptatie bij gebruikers van de nieuwe SharePoint omgeving te bevorderen.

12  Geen rollback plan

Waarom is een goed rollback plan nodig als er een goed migratieplan ligt? De meeste migratieproblemen die ontstaan door bijvoorbeeld niet geïdentificeerd maatwerk, zijn wel weer te herstellen. Maar het herstellen van een niet juist functionerend rollback plan is niet mogelijk. Zorg daarom altijd voor goede back-ups op file- en database niveau voordat gestart wordt met de migratie. Een “in place” migratie wordt om deze reden dan ook afgeraden.

13  Doelen ontbreken

De complete SharePoint migratie is uitgevoerd en de organisatie werkt met SharePoint 2013. Maar is de migratie nu succesvol uitgevoerd? Definieer daarom vooraf een aantal meetbare doelen die met de migratie behaald moeten zijn. Bij het bepalen van meetbare doelen kunnen ook tools bijdragen die bijvoorbeeld gebruikersdata kunnen analyseren.

Conclusie

SharePoint migraties zijn een kans voor een organisatie om content op te schonen, veranderingen door te voeren en om de uiteindelijke SharePoint visie te realiseren. SharePoint migraties zijn veel meer dan een technisch project en moeten goed doordacht (en) gepland worden; anders is de kans op een succesvolle migratie nihil.

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

SharePoint_2010_shell1

Solution:

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 (http://technet.microsoft.com/en-us/library/ff607596.aspx)

SharePoint_2010_shell2

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

SQL2008_filestream1