SharePoint, tak jako každý jiný produkt, dodržuje určitý systém verzování, který nám relativně jednoduše prozradí jak starý je systém, na který se právě díváme, kdy byl naposledy aktualizovaný, jaké můžeme očekávat problémy pokud dlouho aktualizovaný nebyl a jaké funkce jsou uvnitř když víme, co který update přinesl nového. Verze se nám nehodí jen pro aktualizace, pracujeme s nimi při instalaci nového serveru farmy, který musí být přesně té samé verze jako všechno ostatní uvnitř, při obnově databází ze zálohy a často podle nich určíme také příčinu vzniklé chyby, pokud je ohlášená a známá. Občas se dokonce objeví nefunkční farma, kde zjistit to správné číslo bez běžící Centrální správy nebo služeb je těžké…

To všechno nám dokážou prozradit čtyři skupiny čísel oddělené tečkou, které (bohužel) můžete najít na mnoha místech systému, ale často s různými hodnotami, což nejednoho admina lehce zmate. Ale o tom za chvilku, nejdříve si řekneme co znamenají.

První skupina označuje vydanou verzi: 12ka to byla pro MOSS 2007, 14ka pro SP 2010, 15ka pro SP 2013 a 16 to je pro SP 2016. Druhá skupina (reprezentovaná dost často jen samotnou nulou) může být povýšena jedině Service Packem. Třetí, a pro nás nejdůležitější skupina, je build – číslo které nám říká jakou poslední aktualizaci dostal náš systém a pro SP 2013 může dosahovat hodnot od 4128 (Beta) nebo 4420 (RTM verze) nebo 4569 (první, špatný SP1) až po 4815 (April 2016 CU). Poslední skupina je revize – tohle číslo označuje druh aktualizace: Service Pack, CU (1000), hotfix (5000) nebo fix doručený Microsoftem na přání platícího zákazníka (300x) pro jednu konkrétní chybu. Build a revize jsou při aktualizaci upravovány vždy, první dvě skupiny čísel se zas tak moc často nehýbou.

Kde přečteme to správné číslo buildu?

CENTRÁLNÍ SPRÁVA
První místo, které asi každého napadne je Centrální správa. Není to špatný pokus, tady opravdu v sekci „Servers in Farm“ opravdu takové číslo najdeme, nicméně bohužel nemusí být úplně přesné, protože odráží změny pouze pro komponentu nazvanou „SharePoint Foundation“. Pokud se ji změna netýká, číslo se nepovýší. Na pomyslném žebříčku přesnosti dostává tahle možnost 6/10. U centrální správy ještě chvilku zůstaneme, ještě je tu jedno místo, kde se dá tohle číslo zobrazit. Je to sekce „Upgrade & Migration“ a tady aby byl člověk detektivem. To správné číslo buildu tady najdete, jenže v záplavě mnoha dalších a to nejvyšší vyhrává. Jen proto, že ho můžete snadno přehlédnout dostává 8/10, ale způsob to není špatný, Microsoft podporou doporučovaný.

POWERSHELL
Prvním nástrojem, který asi každého správce napadne, je PowerShell, a tady je to trefa do černého. S PowerShellem dokážete všechno, i to co se přes grafické rozhraní zjistit nedá a číslo buildu je tady nejpřesnější. Potřebujeme k tomu cmdlet get-spfarm ve tvaru (get-spfarm).buildversion. Na pomyslném žebříčku přesnosti dostává tahle možnost 10/10 (pokud byl od poslední aktualizace  spuštěný psconfig, který zapsal to správné číslo buildu na všechna patřičná místa).

SOUBOROVÝ SYSTÉM
Každého správce serveru možná napadne souborový systém a verze core SharePoint souborů. I to samozřejmě jde, pokud za a) víte kam se podívat, za b) patch tyto soubory mění nebo přepisuje a nečeká na restart. Hledaný soubor se jmenuje Microsoft.SharePoint.dll a najdete ho v adresáři …\15\ISAPI. I pro tento soubor máme PowerShell: [system.diagnostics.fileversioninfo]::GetVersionInfo(„Microsoft.SharePoint.dll“). Souborový systém dostává 6/10.

REGISTRY
Druhým nástrojem, který můžeme použít a napadl by časem každého správce serveru, je editor Registrů. Je to pravda, i tam build najdeme, ale opět je tu otázka na kolik to číslo bude přesné. Aby to nebylo tak jednoduché, můžeme ho najít na třech různých místech podle použitých komponent a někdy je klíč dokonce (snad omylem) prázdný. Nejdůležitější klíč je HKLM > SOFTWARE > Microsoft > Shared Tools > Web Server Extensions > 15.0. Registry získávají na našem žebříčku 7/10.

DATABÁZE
To každého správce databázového souboru samozřejmě napadne databáze. I to jde, ale pouze pro čtení! Běda tomu kdo se pustí do dotazů, změn nebo dokonce přepisovaní. Teorie říká, že uvnitř každé databáze obsahu najdeme tabulku dbo.Versions, která schovává všechny aktualizace včetně té nejčerstvější. Tady je potřeba trošku filtrování, ale číslo se najít dá. Bohužel, ne každá databáze tuhle tabulku má a ne každý chce nebo smí pracovat s databází. Na našem žebříčku dostávají databáze 7/10.

VIRTUÁLNÍ SLOŽKY
Co možná napdne jen developery, ale je překvapivě hodně přesné a nepotřebujete k tomu vůbec nic (včetně přístupu na server nebo k databázím) jsou virtuální složky. Stačí otevřít Váš oblíbený prohlížeč a napsat cestu ke konfiguračnímu souboru verzí: /_vti_pvt/buildversion.cnf ! Rychlé, snadné, přesné, jednoduché. Tahle možnost na celé čáře vyhrává, tedy 10/10.

Jaké jsou rozdíly mezi jednotlivými aktualizacemi ?

HOTFIX / COD
… je malá věc, kterou instalujeme, jen když ji potřebujeme. Není potřeba sbírat všechny co se objeví, zvlášť pokud ani nepoužíváme komponenty, pro které byly napsané. Hotfixy jsou vydávané podle potřeby, nemají žádný pevný plán.

PUBLIC UPDATE
… byl zatím vydán pouze jeden v březnu roku 2013 a přesto je povinný a důležitý. Svoji povahou se podobal spíše bezpečnostní záplatě než balíčku a opravoval problém, který se týkal všech uživatelů systému. Jeho vydávání nepodléhá žádnému plánování.

CUMULATIVE UPDATE
… je skupina hotfixů, fixů a záplat vydaná najednou. Před červencem 2015 jedou za dva měsíce a vždy vztažená k nějaké komponentě (službě, jádru, nástroji nebo cache). Většinou řeší problémy, občas nějaké vyrobily a vzácně přinesou něco nového jako novou volbu v konfiguračním nástroji, nový cmdlet nebo něco podobně malého. CUs jste potřebovali a instalovali (skoro po jednom) až do chvíle, než je nahradily uber CU.

UBER CU
… jsou balíčky updatů vydávané teď už každý měsíc, které nepřináší pouze záplaty pro exitující problémy, ale obsahují aktualizace všeho, co se doteď vyrobilo. V praxi tedy stačí nainstalovat RTM verzi z TechNetu, povýšit ji o ten správný, první service pack a jít tabulkou updatů až k tomu nejnovějšímu Uber CU co je vydaný. Samozřejmě má to pár drobných vyjímek ale jde to. Opravdu jde.

Zpočátku byly aktualizace pro SP 2013 publikovány jen každý druhý měsíc a vycházely jako CUs. Jako balíčky, které obsahovaly vždy všechny dostupné aktualizace jedné komponenty pro kterou přinášely nějakou opravu nebo novinku. Pozor, v tom je proti dnešku velký rozdíl. Pokud se update týkal hledání, obsahoval všechny předešlé změny co se v infrastruktuře hledání až do té chvíle vydaly, ale nezahrnoval změny ostatních komponent! Dobře si prohlédněte obrázek níže a porovnejte ho s následujícím.

Od července roku 2015 však vychází něco čemu se říká „Uber“ updaty a to každý měsíc. Tyhle balíčky kromě nové změny (vždy na konci sloupce) obsahují také všechny předešlé aktualizace a nemusíme instalovat každý zvlášť. Stačí se jen podívat jakou pre-rekvizitu potřebují, většinou service pack nebo ten jediný public update, který vyšel.

Když už víme, jak starý je náš systém, jak se propracovat k nejnovějšímu buildu? Na zdánlivě jednoduchou otázku bohužel není jednoduchá odpověď, protože každý systém je jiný. Pokud je Vaše číslo buildu rovno 4569, upgrade je nutný. Pokud se pohybujete někde v roce 2015, stačí Vám najít poslední UCU (a po patřičné záloze a testování) aplikovat nejnovější balík. Pokud se pohybujete někde před červencem 2015 (kde se měnil systém vydávání balíků), potřebujete nejdřív JAN 15 CU (pak je vhodné/bezpečné se zastavit ještě někde na konci roku jako DEC 15 UCU) a pak nejnovější UCU balík z TechNetu. Prosím vyvarujte se přímé aplikaci JAN 16 CU, měl několik nepříjemných chyb a když se jim můžeme vyhnout, proč to neudělat. Na druhou stranu takový Dec 15 CU, který se mimo jiné dotýkal databází, je jednou z těch bezpečných „zastávek“ na cestě za rozdílovým upgrade po částech. Následujících pár řádek prosím berte jako příklad:

Nový/DEV systém, rychlá cesta k upgrade
= ISO + SP1 mark2 + (MS14-022) + November 17 UCU / FP1 (psconfig) + latest 17 UCU (psconfig)

Nový systém, bezpečná cesta k upgrade se zastávkami
= ISO + SP1 mark2 + Jun 15 CU (psconfig) + (MS14-022) + November 17 UCU / FP1 (psconfig) + latest 17 UCU (psconfig) + AppFabric CU 5

Systém o něco starší než červen 2015 za použití SQL 2014
= Jun 15 CU (psconfig) + Dec 15 UCU + November 17 UCU / FP1 (psconfig) + latest 17 UCU (psconfig) + AppFabric CU 5

Systém o něco starší než červen 2015
= Jun 15 CU (psconfig) + November 17 UCU / FP1 (psconfig) + latest 17 UCU (psconfig) ​+ AppFabric CU 5​

… apod. Nebojte se „přeskakovat“ UCU, pokud stáhnete novější, než si můžete dovolit, on Vás instalátor upozorní, že je potřeba se někde na cestě zastavit. Na druhou stranu není potřeba jít po jednom a instalovat každý zvlášť, důležitým milníkem je červen 2015, prosinec 2015, úplně vynechejte leden 2016 a pokračujte dubnem nebo květhem 2016. Není tajemstvím, že balíky něco nového přinesou a občas něco fungujícího poničí, nicméně tak zhruba od března 2016 se neobjevil žádný uživatelem nebo zákazníkem nahlášený bug (ťuk ťuk ťuk), což je hodně dobré znamení. Budeme doufat, že to dlouho vydží. Přiznejte se, kdo z Vás při aktualizacích myslí na AppFabric?

Čas od času se změní pohled odborníků na způsob jakým SharePoint nastavujeme, instalujeme nebo aktualizujeme. Na tom není nic špatného, postupy se prostě vylepšují a vyvíjí – jen za poslední půlrok je to způsob jak např. přejmenovat Admin databázi, jak si poradit s IIS chybou při instalaci, jak otestovat konektivitu SQL a alias při instalaci apod., které jsme roky dělali nějak a teď je všechno jinak. To samé může potkat i aktualizace, takže výše uvedený návod berte spíše jako doporučení, spíše než pravidlo prosím.

Seznam všech buildů, novinek i problémů, které mohou sebou aktualizace přinést najdete hned na několika různých místech. Nejrychlejším zdrojem informací jsou Twittery @SP2013Patches a @stefan_gossner, výbornou práci pak odvádí tým kolem projektu SharePoint updates, ale jednoduchou tabulku s linky najdete i u nás ve VIP sekci iLike stránek.

Co všechno se může během procesu aktualizace pokazit? Docela dost věcí! Předpokládejme, že se tu nemusíme zabývat věcmi jako jsou práva, volné místo na disku, integrita databází apod., ono je dost dalších věcí, na které můžete narazit. Tady je malý seznam toho nejčastějšího:

NEÚPLNÝ BALÍK
Pozor na poslední uber CUs, v drtivé většině případů chodí ve třech (jeden .exe soubor, dva .cab soubory) a potřebujete všechny tři. Na jednom místě pohromadě. Pokud se instalátoru nedaří .cab soubor rozbalit, udělejte to za něj a pak teprve spusťte přiložený ubersrv2013-kbxxxxxx-fullfile-x64-glb.exe.

BALÍK SE NECHCE NAINSTALOVAT S CHYBOU „EXPECTED VERSION IS NOT FOUND ON SYSTEM“
Pokud jste si úplně jistí, že balík který je stažený je pro vás (správná edice, správný rok, správná velikost, všechny tři soubory, správná jazyková mutace apod.), ale aktualizace se přesto odmítá spustit, můžete jí trochu pomoci parametrem při spuštění  PACKAGE.BYPASS.DETECTION.CHECK=1. Ale jen, pokud jste si opravdu jistí (např. dva servery farmy se Vám podařilo aktualizovat, ale třetí balík tvrdohlavě odmítá).

PSCONFIG ZŮSTANE ZASEKLÝ NA 10% NEBO 100%
Inicializace konfigurace chvilku trvá. Zapsat všechno do databáze chvilku trvá. Nicméně pokud jste zůstali zaseklí na 10% nebo 100% po hodně dlouhou dobu (30 – 40 min), je něco špatně. Zkontrolujte prosím následující klíč v registrech HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure, skupiny WSS_ADMIN_WPG & WSS_WPG potřebují plan práva na celou složku Secure. Násilně ukončete psconfig a spusťte ho znovu.

PRODUCT VERSION JOB
Už se Vám někdy stalo, že jste chtěli dokončit aktualizaci vašich serverů Vaší farmy a místo konfiguračního průvodce se na jednom z nich zobrazila chyba, která říkala tvrdí že se počet instalovaných balíků na serverech liší? Většinou se to stává jen u grafické verze průvodce. Nepouštějte grafickou podobu konfiguračního průvodce. A pokud už musíte, ale nepovede se Vám to, zkuste spustit ručně službu „Product Version Job“ přes Centrální Správu. Tahle úloha nemá na starosti nic jiného, než neustálé porovnávání verzí produktů mezi servery farmy a stačí ji spustit ručně. A díky tomu že to je job, zřejmě fungjí i desítky dalších návodů na internetu jak tuhle chybu opravit, které říkají, že stačí resetovat Timer… Můžeme jí úplně předejít z PowerShellu zapsáním dovětku -cmd installcheck –noinstallcheck.

MS16-004 / KB3114503
Pozor, existuje jeden nepříjemný update, který ničí pohledy všech listů a knihoven. Byl vydán v úterý 12. ledna 2016 pod číslem kb3114503. Po jeho použití vypadají všechny knihovny a listy jako prázdné, i když ve skutečnosti nejsou, poničené je pouze „default“ view. Ale komu by se chtělo opravovat je všechny? Spravit to můžeme celkem jednoduše, stačí aplikovat (minimálně) únorový CU (po testech, samozřejmě), spusit psconfig a všechno se zpraví. Více informací najdete zde.

.NET 4.6 & 4.61
Během instalace SharePointu se kontroluje správná verze .NET(u), kterou by měla být 4.5. Pokud máte v systému nainstalovaný .NET 4.6 nebo 4.61, instalace zhavaruje a to i za situace, že máte hned několik verzí .NET(u) nainstalovaných vedle sebe. Jedinou šancí je nové verze odebrat, nainstalovat SharePoint a aktualizovat .NET později znovu. Alespoň zatím. Více informací najdete zde.

A nakonec trocha toho užitečného Power Shellu. Co pro své aktualizace potřebujeme? Nejdříve asi číslo buildu, to už jsme si ukazovali na začátku pomocí příkazu:

(get-spfarm).buildversion

Aktualizaci byste měli dokončit spuštěním „Průvodce konfigurací“ z příkazové řádky ve tvaru:
PSConfig.exe -cmd upgrade -inplace b2b -wait –force

Pro některé vybrané aktualizace (jako March 2015 CU) dokonce ve tvaru:
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources

Mezi tímto prvním a posledním krokem pak může být hromada dalších věcí. Můžete pozastavit službu hledání, ale můžete ji také přeplánovat tak, aby se s časem Vašich aktualizací nepotkala… Jenže nikdo nikdy dopředu neví, jak dlouho to bude trvat. Ostatně zastavit můžete všechny služby, ale ne každý si to dovolí. Příkaz na to máme:

Stop-SPServiceInstance -Identity <ServiceGUID>

Pokud se Vám do toho nechce (z celkem pochopitelných důvodů), alespoň restartujte Timer job a nebojte se ani iisresetu. Ten sice nepatří k Power Shell příkazům, ale zadat ho do okna shellu můžete také.

Get-sptimerjob job-timer-recycle | start-sptimerjob
(ekvivalent k net stop „Windows SharePoint Services Timer„)

Pro zkušené a odvážné správce existuje script, který dokáže zkrátit dobu aktualizace z několika hodin na desítky minut právě díky tomu, že zastaví služby, odpojí uživatele od IIS a aktualizuje databíze obsahu nezávisle na všem ostatním. Najdete ho na webu: https://blogs.msdn.microsoft.com/russmax/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install.

… a jen pro pořádek na konec dodávám, že všechno se musí testovat. Vyrábějte snapshoty, kontroluje zálohy databází (protože v konečném důsledku jde vždy o data, SharePoint jako takový je nainstalovaný relativně rychle) a neinstalujete hned všechno, co se objeví. Počkejte chvilku než to otestují lidé, co mají po ruce testovací / DEV farmy s Ent. licencí a testovacími daty, protože ti mají šanci objevit maximum věcí, na které si pak Vy můžete dát pozor. No a když se něco nepodaří, obnovujte. Kdy jste naposledy zkoušeli něco jen tak cvičně obnovit, abyste měli jistotu, že to půjde až to budete opravdu potřebovat?

. . .
Článek navazuje na blog příspěvek https://blogs.technet.microsoft.com/stefan_gossner/2014/08/18/sharepoint-patching-demystified a je přepisem z přednášky o aktualizacích pro SharePoint Show 2016.
Více čtení na toto téma: https://blogs.technet.microsoft.com/stefan_gossner/2016/04/29/sharepoint-2016-zero-downtime-patching-demystified