„Content Deployment“ je proces, při kterém jste schopní přesunout (a opakovaně automaticky přesouvat) data z jedné kolekce do druhé, a to dokonce i mezi webovými aplikacemi nebo farmami. Jde v podstatě jen o sadu několika po sobě jdoucích příkazů s parametry (Export-SPWeb a Import-SPWeb), které jste schopni zadat i sami prostřednictvím PowerShellu, jen tohle je trochu pohodlnější, protože můžete sledovat průběh celé akce pomocí Centrální Administrace a plánovat úlohy automaticky.

„Deployment“ umí pracovat pouze s databázemi obsahu. Přenese listy, knihovny, stránky, weby a jejich práva, metadata a poslední verze dokumentů, ale nepřenese historii verzí, soubory z koše, e-mailové notifikace (alerts), „features“ (aktivuje nainstalované pokud jsou k dispozici, ale nepřenáší je), styly, „master pages“, odemyká soubory zamčené funkcí „check-out“ a nuluje statistiky.

Na řadu věcí se opravdu hodí. Kromě toho že může přenášet data z testů do produkce nebo mezi farmami, tak data čistí – opravuje prázdné nebo z nějakého důvodu nedostupné pohledy u listů a knihoven, napravuje problémy s právy, protože během fáze importu vytváří úplně nový „User list„, uvolňuje a odemyká soubory držené systémovým účtem a přenáší soubory poškozené migrací, které do té chvíle nešly smazat ani otevřít. Bohužel, několik nových problémů tímhle procesem vzniká. Dávejte si pozor na digitálně podepsané dokumenty a funkci „property promotion“ nebo se stanete autorem všech verzí, podpisy se zneplatní a před auditem se pěkně zapotíte. Schovejte si seznam všech e-mailových notifikací uživatelů, koukněte co zůstalo v koši, připravte své uživatele na to, že přijdou o check-out příznak všech svých souborů a specielně nepřenášené historie verzí hodně bolí, protože je PowerShellový „import“ sám o sobě s tím správným parametrem umí. Ale i na to existuje skript.  

Jak to celé probíhá? Nejprve se kontroluje dostupnost a volné místo na  disku cíle, pak se porovvnávají zdrojové a cílové features (které se rovnou aktivují, pokud jsou k dispozici) a nakonec je tu samotný proces přenosu dat, který je rozdělený do několika fází. Fáze exportu ukládá zdrojová data do lokální složky na zdrojovém serveru, kde jsou postupně balena do několika .cabů (plných XML a binárních souborů). Komprimované soubory jsou posílány do lokální složky cílového serveru, kde jsou ve fázi importu rozbalené do správného cílového místa, doplněné o metadata a dorovnané o uživatelská práva a skupiny tak, jak měl nastaveno zdroj. Celý proces je zakončen čištěním zbytků lokálních složek a „timer jobů.

Fáze importu se může pohybovat někde mezi 500 MB – 20 GB / 30 min, což je zhruba 1000 – 8000 objektů / 30 minut.

Poznámka první: Celý proces trvá strašlivě dlouho. Nezáleží na počtu jader, velikosti RAM paměti, velikosti disků nebo vytíženosti sítě, tohle všechno jsme zkoušeli a nepomáhá nic. Do jisté míry zabírá trik s navýšením databázového atributu „autogrowth“ ze standartní hodnoty 1 MB na 256 MB, ale i tak se úloha zrychlí jen zhruba čtyřnásobně.

Pokud chcete s „Deploymentem“ začít pracovat, nejdříve musíte udělat několik věcí:

1. Povolte příchozí „content deployment jobs“ na cílovém serveru
   (odkaz „Configure content deployment“ v sekci CA/General Application Settings)
2. Nastavte „content deploymenent path“ na zdrojovém serveru
   (úlohy je možné nastavit oběma směry, na obou serverech najednou)
3. Nastavte nový „content deployment job“ na zdrojovém serveru
   (jedné cestě je možné přiřadit několik úloh najednou s odstupem minimálně 15 minut).
4. Založte cílovou kolekci webů
   (Pozor na šablonu – záložka „Custom“, položka „Select template later“)
   Všechny čtyři kroky výše jsou velmi dobře popsané na Becky webu.
5. Srovnejte zdrojové a cílové prostředí, minimálně „features“ a „service packs“ by měly být shodné. („Features“ přidejte, ale neaktivujte, o to se postará proces sám)
6. Ujistěte se, že máte dostatek volného místa pro data a transakční logy databází
   (Nechte si nejlépe dvojnásobek velikosti kolekce před přesunutím)
7. Připravte si skripty pro přenos všeho, co chcete mít na cílovém serveru
   (Historie verzí, souborů z koše, alertů a vůbec všeho, co „CD“ nezvládne)
   Úplný seznam „best practices“ je k dispozici zde.

Poznámka druhá: Výsledek celého procesu je oznámen mimo jiné e-mailem, který má často ve statusu slovo FAILED. Nelekněte se, stačí, aby se v logu objevil jen jeden jediný záznam s upozorněním a úloha je označena jako špatná, i když se data přesunula.

Úlohy mohou být plné nebo přírůstkové a pokud běží úplně poprvé, provedou se vždy plné, i kdyby byly označeny jen jako přírůstek.

Poznámka třetí:  Než se pustíte do ostrého přesouvání, zkuste je několikrát „nanečisto“.  Lépe se tak odhaduje skutečný čas potřebný k přesunu dat a počet věcí, které bude potřeba opravit a navíc po prvním přesunu občas sem tam něco chybí (třeba poslední verze nebo práva). Druhý pokus (přírůstek) pak všechno dorovná, i kdyby měl být spuštěný jen 15 minut po tom prvním.

A jaká je Vaše zkušenost?