Tak, je to tady, jdeme na to. Minule jsme si popsali výchozí požadavky a dnes se společně podíváme na první kroky na naší strastiplné cestě. Co jsme řešili, co jsme prožili a jak to probíhalo je obsahem dnešního článku.
SCCM/MEM
Prvním krokem na cestě k úspěchu byl upgrade samotného System Center 2012 Configuration Manager řešení na nejnovější verzi Microsoft Endpoint Configuration Manager (current branch). Nová verze nám kromě podpory nasazení nejnovějších buildů Windows 10 a Office 365 nabídla i nové technologie pro distribuci dat na samotné stanice v podobě Delivery Optimalization a Peer Cache, které jsme plánovali využít při upgradu. Příjemným benefitem pak byla možnost využití co-managementu v kooperaci s Desktop Analytics pro analýzu aplikací a jejich kompatibility s nejnovější verzí Windows 10.
Dalšími úkoly, které bylo možné v tuto chvíli vyřešit, byly rychlá a spolehlivá aktualizace stanic a nasazení bezpečnostního nástroje Microsoft Defender. Na Endpoint Manager jsme tedy nainstalovali role Software Update Point a Endpoint Protection Point, díky kterým jsme mohli začít aktualizovat stanice či sadu Office ihned po jejich instalaci a zároveň nasadit a spravovat řešení Microsoft Defender. Paráda 😊.
Koncové stanice
Po přípravě na straně Endpoint Manageru jsme se mohli vrhnout na stanice samotné, kde nás zajímaly oblasti jak HW, tak rovněž SW.
Díky analýze jsme zjistili celkem 18 modelových řad s bezmála 200 verzemi BIOSU/UEFI. Vím, zní to děsivě, ale u firem, které se v rámci svého patch management procesu omezují pouze na operační systém a několik málo aplikací, se jedná o vcelku běžný stav. Bohužel i přes enormní snahu se nám nepodařilo dostat do ruky všechny možné kombinace a zvládli jsme tak otestovat automatizovaný upgrade BIOSu/UEFI přibližně u 80 % tohoto portfolia. To není zlé 😊.
Samostatnou kapitolou v oblasti HW byl velmi žádaný upgrade TPM čipu oddělením Informační Bezpečnosti. Velmi záhy se však ukázalo, že se nebude jednat o procházku růžovým sadem, protože stanice neukládaly informace o minoritních verzích TPM firmwaru do WMI. Tento úkol nakonec pomohla vyřešit trocha skriptování v Powershellu.
Vcelku jednoduchá situace panovala v oblasti softwarového vybavení stanic. Důležité business aplikace byly řešeny povětšinou ve webovém prohlížeči a zbytek „těžkých“ aplikací jsme buď zařadili do plánovaného deploymentu stanic, či do Software Center, odkud si je uživatelé mohli nainstalovat svépomocí v momentě, kdy je potřebovali.
IEEE 802.1x
Technologie 802.1x se za poslední dekádu stala víceméně standardem v oblasti zabezpečení sítě, což je při plánovaném využití metody „wipe and load“ pro upgrade operačního systému velkým trnem v oku řadě dodavatelů, kteří tak mnohdy doporučují tuto technologii po dobu upgradu zcela vypnout. Nebudeme si nic nalhávat, je to jednoduché, ovšem nikoliv bezpečné řešení. A proto jsme se raději vydali cestou vyřešení možnosti instalace stanice při zapnutém 802.1x. Prerekvizitou se při plnění tohoto úkolu stalo použití nativního supplikantu OS Windows, několik manuálních kroků a trocha skriptování s aplikací do MEM. Nejenže nám to pomohlo v rámci jednorázové akce upgradu stanic, ale zákazník nyní může instalovat všechny nové stanice bez nutnosti zmíněnou technologii obcházet oddělenou sítí či zadáváním MAC adres počítačů do výjimek. Příjemný benefit, že? 😊
To nejhorší máme za sebou. Nebo ne?
V tuto chvíli máme připraven „balíček“ nebo chcete-li „seznam kroků“, který bez nutnosti obcházet či vypínat 802.1x dokáže:
• aktualizovat BIOS/UEFI,
• vypnout dočasně šifrování disku a promazat informace uložené v TPM,
• aktualizovat firmware TPM čipu,
• naformátovat pevný disk,
• nainstalovat OS včetně potřebných aplikací a aktualizací,
• stanici opět zašifrovat
• a v neposlední řadě aktivovat ochranu pomocí Microsoft Defender.
.jpg)
Všechno super, pohoda, jdeme na pivo… Bohužel nikoliv 😊. Vše, co jsme dosud připravili a otestovali, jsme řešili v labu či na ideálních podmínkách v podobě rychlé sítě na centrále společnosti. Nyní je nutné celé naše úsilí promítnout i do funkční podoby na vzdálených pobočkách s mizernou konektivitou. Nástroj MEM má pro tyto případy implementovaných několik zajímavých technologií.
Jako nejvhodnější pro doručení obsahu o velikosti cca 10 GB se nám osvědčilo využití Peer Cache v kombinaci s BranchCache. Jednoduše řečeno byl na každé řešené lokalitě vybrán jeden počítač, který v den vlastní migrace posloužil jako distribuční bod. Měl totiž celý obsah Task sekvence předstažen na svém pevném disku a tato distribuční stanice byla pak upgradována vždy jako poslední.
V příštím a posledním díle se zaměříme na to, proč je kvalitní komunikace v organizaci nezbytná ke zdaru celé akce. A pokud vás čeká něco podobného a zatím jen sbíráte síly, informace a odvahu, neváhejte se ozvat na konzultaci. Rádi pomůžeme!
Sdílet článek