Wat is er nieuw in SharePoint 2016? (Deel 2/3)

In deel 2 van deze blog, ga ik verder in op een aantal nieuwe functionaliteiten binnen SharePoint 2016. Deel 1 van deze blog kunt u hier vinden.

Minimal Server role provisioning

In middelgrote tot grote SharePoint 2013 farms, worden nu vaak per server de volgende "rollen" toegewezen:

• Web Front end servers
• Applicatie servers
• Search Index en Crawl servers
• In grote farms: Distributed cache / Request management servers

Hoewel dit in de basis prima werkt, is er toch een bepaalde mate aan overhead, en code aanwezig op servers, welke niet noodzakelijk is voor de specifieke rol welke daar uitgevoerd word. Bijvoorbeeld, Wanneer een gebruiker een zoekopdracht uitvoert, moet de Search Service Application eerste alle servers in de farm nagaan, waar wel, en waar niet de service draait welke een antwoord kan geven op die zoekopdracht.

In SharePoint 2016 worden zogenaamde “Minimal Server Roles” geïntroduceerd. Bij het uitvoeren van de Configuration Wizard, om de server aan de SharePoint Farm toe te voegen, kan er een enkele rol voor die server worden bepaald. Die rol kan één van de volgende zijn:

• Web frontend
• Application Role
• Search indexing en crawling
• Distributed cache
• Specialized load

Deze Serverroles worden vervolgens door middel van health analyzer rules gecheckt, en er wordt in de Central Administration omgeving ook aangegeven, wanneer servers zogenaamd “Out of compliance” zijn. Daarbij wordt dan vervolgens ook een “Fix” mogelijkheid aangeboden. De meeste rollen spreken verder voor zich, als je kijkt hoe SharePoint 2013 farms nu al worden ingericht.

Opvallend in dit rijtje, is de "Specialized Load" rol. Deze is bedoeld voor het 3rd party services (bijvoorbeeld maatwerk, site provisioning logica, etc.). Ook kan op deze manier op een server de “klassieke” SharePoint 2010/13 manier van Services aan/uitzetten worden gehandhaaft. Servers met deze rol worden dan ook niet gecontroleerd door SharePoint door middel van de health analyzer rules.

Voordeel van deze opzet, is dat een specifieke server een kleinere overhead heeft. Servers waarvan SharePoint van te voren al “weet” dat ze bepaalde rollen niet hebben, worden dan overgeslagen.

Deze rollen kunnen overigens niet worden gecombineerd, voor zover dat nu bekend is. Verder kan bij het inrichten van de Server via Powershell gebruik worden gemaakt van de “islocalserverrole” switch, met daarna de bijbehorende rol, om geautomatiseerde installaties ook mogelijk te maken.

Patching

SharePoint 2013 kent op dit moment updates van ruim 3 Gigabyte. Het installeren van deze patches kost daarom veel tijd, met als gevolg ook lange downtime op je SharePoint omgeving. 

In SharePoint 2016 gaat Microsoft het Patch proces aanpakken. Er zal voorlopig nog steeds worden gewerkt met Servicepacks en Cumulative updates, voor zover nu bekend. Echter heeft Microsoft nu de belofte gemaakt om deze patches fors in grootte te verminderen, en daarnaast geen downtime tot gevolg. Hoe dat technisch in elkaar zal steken, is nog niet duidelijk, maar hier worden veel SharePoint ITPro’s erg blij van, waaronder ikzelf.

Ook dit is primair het gevolg van de lessen welke Microsoft heeft geleerd vanuit het moeten behalen van uptime SLA’s binnen Office 365.

User profile service Application

In SharePoint 2013, was een (aangepaste) versie van ForeFront Identity Manager (FIM) aanwezig, welke de AD Gebruikers inclusief eigenschappen, synchroniseerde naar SharePoint 2013, welke vervolgens in de vorm van User Profiles, gebruikt kunnen worden. Vervolgens kunnen deze bijvoorbeeld in een "Wie is Wie" / Smoelenboek systeem toegepast worden.

Deze mogelijkheid gaf echter, zeker in de vroege dagen van SharePoint 2010, veel technische problemen. Nog steeds bestaat een groot deel van de Support calls welke bij Microsoft binnenkomen, uit problemen omtrent deze techniek.

In SharePoint 2016 wordt die ingebouwde FIM techniek verwijderd. Er blijven vervolgens nog 2 alternatieven over:

• Een koppeling maken naar een dedicated, bestaande of nieuw in te richten, FIM Server, met een aparte licentiestructuur hiervoor.
• De "SharePoint 2007" manier, genaamd "Active Directory Import". Dit is een stabiele en snelle techniek, echter heeft deze techniek op dit moment in SharePoint 2013 de volgende nadelen:
  • Er kan alleen maar worden geïmporteerd vanuit een AD bron. (de volledige FIM kan ook vanaf andere LDAP bronnen synchroniseren, zoals Novell eDirectory, AD Import kan dit dus niet.)
  • Synchronisatie kan alleen per AD Domein worden gedaan (dus niet vanuit meerdere AD Domeinen in één AD Forest)
  • AD Gebruiker eigenschappen kunnen alleen vanuit AD, naar SharePoint worden gesynchroniseerd, dus één weg synchronisatie. Eigenschappen kunnen dus niet worden terug gesynchroniseerd richting het AD (bijvoorbeeld een profielafbeelding).

Er bestaat een grote kans dat Microsoft aan de bovenstaande nadelen nog wel wat zal gaan doen, maar dat is niet zeker. Wel is duidelijk, dat Microsoft de licensering voor de toekomstige on-premises FIM (MIM, Microsoft Identity Server) gaat aanpassen, waarbij Azure AD Premium licenties de FIM/MIM Server licentie kan vervangen.

Durable Links

Wanneer een document of pagina wordt gedeeld vanuit SharePoint 2016 naar een collega, zal er niet langer een "harde" URL worden verstuurd. In plaats daarvan, krijgt de verstuurde link een referentie ID naar het document. Het maakt dus niet uit of het document later wordt verplaatst of een andere bestandsnaam krijgt, de link zal altijd blijven werken.

In deel 3 ga ik in op andere nieuwe (technische) functionaliteiten binnen SharePoint 2016.