Fakulta elektrotechniky a komunikačních technologií VUT v Brně

Program MSDN Academic Alliance
Nástrahy aneb na co si dát pozor

Smyslem tohoto dokumentu je upozornit na některé z problémů, na něž lze při používání MSDN AA narazit a které mohou při jejich neznalosti způsobit zbytečné komplikace. Zkušenosti se 4letým provozem MSDN AA na FEKT ukazují, že mnohé z těchto problémů ani nemusí být předem zřejmé a o to větší pak může být jejich záludnost.

Obsah

[ rozbalit vše | sbalit vše ]  

Zálohování vydaných produktových klíčů a staženého software (více)(méně)

Ukazuje se, že mluvit o zálohování nejenže není zbytečné, ale je to naopak naprosto nezbytné. Uživatele proto důrazně upozorňujeme na vlastní zodpovědnost za zálohování vydaných produktových klíčů i staženého software!

Někteří již důsledky zanedbání této zodpovědnosti pocítili. V lepším případě jen tak, že např. museli požádat správce MSDN AA o dohledání svých produktových klíčů nebo o povolení dalšího stažení software. Tito uživatelé měli štěstí, protože jejich problém šel v daném případě relativně snadno vyřešit a řešení tak znamenalo (jen) určitou časovou ztrátu.

Řešení ale nemusí být vždy tak snadné, případně vůbec nemusí být k dispozici. To se ukázalo např. při přechodu na novou verzi eLMS, při kterém provozovatel data ze starého systému do nového nepřeváděl a veškeré informace ze starého systému (včetně produktových klíčů vydaných jednotlivým uživatelům) tak pro nás byly zcela nenávratně ztraceny.

Zanedbání zálohování vydaných produktových klíčů i staženého software se může nevyplatit v různých situacích a také z několika důvodů. O některých z nich mnozí možná ani nevěděli (a často vědět nejspíš ani nemohli), a to bylo také jedním z důvodů pro vznik tohoto textu. Několik kritických situací bude zmíněno také v následujících bodech, ale hlavní ponaučení by mělo být jasné již po přečtení tohoto bodu.

Na zodpovědnost za zálohování byli uživatelé na tomto místě upozorněni ještě před otevřením nového eLMS, ve kterém začínáme víceméně "od nuly". Tedy za stavu, kdy ještě ani nemohla existovat jakákoli možnost tuto zodpovědnosti v novém systému porušit. Je proto na uživatelích, aby využili tohoto nového začátku a začali se chovat zodpovědně. Žádosti uživatelů vzniklé pro zanedbání zálohování mohou být vyřizovány jen omezeně, případně pouze ve velmi závažných případech.

Omezený počet pokusů pro stažení software (více)(méně)

Jedna z neviditelných nástrah (alespoň zpočátku, než na ni narazíte) je omezení počtu stažení jednotlivých produktů. Tato "vlastnost" je bohužel obsažena i v novém systému. Mnozí o ní již ví, mnozí ale ne. A protože ani v novém systému na ni není nijak výrazně (nebo dokonce vůbec) upozorněno, nezbývá, nežli takto učinit zde.

Pro stažení každého produktu je v eLMS k dispozici pouze omezený počet pokusů, po jejichž vyčerpání Vám již systém další stažení neumožní. Při vyčerpání pokusů proto budete nuceni žádat správce MSDN AA o povolení dalšího stažení produktu.

Podle nápovědy v eLMS jsou výchozím stavu u každého produktu k dispozici jen 2 pokusy, tedy stejně jako u většiny produktů i ve starém eLMS. Správce MSDN AA nemá možnost toto nastavení nijak měnit. Výjimkou byly jen produkty, které nebyly balíčkovány provozovatelem eLMS a proto měly komplexnější konfiguraci, která umožňovala správci nastavit i tuto hodnotu. To byla ale záležitost starého eLMS, která již v novém systému není aktuální.

Je proto lépe počítat s tím, že výchozí pokusy spolehlivě pokryjí jen jediné (první) stažení. Případné další pokusy jsou určeny jen jako záložní, např. pro případ chybného stažení při prvním pokusu (takto hovoří přímo nápověda v eLMS). S dalšími pokusy proto určitě nelze počítat pro pozdější opakované stažení produktu a zanedbávat díky tomu zálohování staženého software.

Návrhy na doplnění upozornění o omezení počtu stažení přímo do eLMS jsme provozovateli systému podali již před několika lety, patrně naprosto bez výsledku. Obdobně dopadly i snahy o odstranění či jakékoliv zmírnění omezení počtu stažení, které mimochodem považujeme za zbytečné a nesmyslné. V době používání předchozího systému jsme navíc pro stahování používali server na FIT VUT, takže většinu související zátěže by nesl jen tento server. Bohužel i tyto návrhy byly zamítnuty s odůvodněním, že jde o politiku Microsoftu. A ani přednesení návrhu českému zástupci Microsoftu na úrodnou půdu nepadlo.

Jediné změny tak doznal snad jen formulář pro podávání žádostí o povolení dalšího stažení. I ten měl své chyby, které byly u provozovatele rovněž reklamovány společně s konkrétními návrhy na zlepšení. Možná i proto v novém systému tento formulář už neexistuje. V zásadě to ale nevadí, protože žádnou zásadní výhodu nepřinášel. Smysl by měl, kdyby vyplněním vznikl přímo v eLMS požadavek, který by pak správce už jen nechal provést (nebo jej případně zamítl). Jeho skutečnou funkcí ale nebylo nic víc, než vygenerování e-mailu, který musel správce ručně(!) zpracovat. A ani uživatelům při podávání žádosti zjevně příliš nepomáhal, o čemž svědčí mnohé chybné až nesmyslné (někdy dokonce i ledabyle vyplněné) žádosti, které byly jeho prostřednictvím podány.

Možnost stažení poškozeného a/nebo nekompletního software (více)(méně)

Zkušenosti se starým eLMS ukázaly, že downloader, pomocí kterého se ve starém systému stahoval software, neměl příliš dobře řešenu kontrolu chyb při stahování a integrity staženého obsahu (občas byl důvod pochybovat, že v něm nějaké kontroly vůbec byly implementovány). V novém eLMS má sice downloader nový vzhled, ale je možné, že to je jediná změna a právě popsaný problém je tak aktuální i nadále.

Testy downloaderu v minulosti ukázaly, že v některých případech může dojít ke stažení poškozeného nebo neúplného obsahu. Výsledkem pak může být obraz instalačního média nebo jiný obsah ve zcela nepoužitelné podobě. Výskyt tohoto problému navíc může proběhnout bez jakékoliv indikace (tj. žádné chybové zprávy apod.).

Zmíněné problémy se při testech zcela systematicky vyskytovaly při poškozeném (většinou ale jen neúplném) SDC balíčku na serveru. Nelze je však vyloučit ani v případech, kdy při stahování dojde jen k nahodilému problému (např. přerušení spojení). Downloader při testech žádný problém nenahlásil (a možná ani nezjistil) a stahování proběhlo na první pohled bez problémů. Výsledný ISO obraz po extrakci však v pořádku nebyl.

Problémy se mohou projevit až při pokusech o přečtení obsahu souborového systému obsaženého v ISO obrazu (tj. až po jeho vypálení na médium nebo až po připojení pomocí nástroje pro emulaci optické mechaniky). Při detailnějším pozorování bylo zjištěno, že velikost staženého SDC balíčku byla podezřele menší než velikost z něj extrahovaného ISO obrazu. Protože ale není důvod předpokládat velký kompresní poměr, velikosti SDC balíčku by měla být podobná velikosti ISO obrazu. Velikost staženého obsahu však uživatel asi běžně záměrně nesleduje a navíc případné problémy spolehlivěji odhalí přímější testy popsané dále.

Minimální doporučitelnou kontrolou je (po dokončení stahování a následné extrakci obsahu staženého SDC balíčku) alespoň porovnat velikost výsledného ISO souboru s velikostí obsahu v něm obsaženého souborového systému (tj. se součtem velikostí všech v něm obsažených souborů). Je-li ISO obraz výrazně menší, není téměř určitě v pořádku (4 GiB dat se do 500 MiB velkého ISO obrazu prostě jen tak nevejdou). Pro tuto kontrolu bude nutné extrahovaný ISO obraz vypálit na médium nebo připojit pomocí nástroje pro emulaci optické mechaniky.

Lze však doporučit provést i test čitelnosti obsahu celého ISO obrazu či média. Tento test sice chvíli potrvá a bude asi vyžadovat i nemalý dočasný diskový prostor, zato ale poskytne poměrně spolehlivou kontrolu staženého obsahu. Test lze provést např. přečtením všech souborů (třeba jejich zkopírováním na pevný disk).

Při problémech se stahováním sice žadatelé o povolení dalšího stažení téměř jistě odmítnuti nebudou, nicméně i tak lze provedení kontroly staženého obsahu (např. způsobem navrženým výše) jen doporučit. Vyhnete se tak pozdějším překvapením či dokonce situaci, že stažení dotyčného software již nebude možné.

Doplňující informace pro technicky zvídavé

Downloader dokáže po spuštění pokračovat v případném nedokončeném stahování od místa, kde naposledy skončil. Při opětovném spuštění je jen třeba zadat stejnou cílovou cestu jako při předchozím spuštění, aby mohl najít doposud stažený obsah.

Nedokončené pokusy se také nezapočítávají pro účely zmíněného omezení počtu pokusů pro stažení software. Ke snížení počtu zbývajících pokusů by proto mělo dojít pouze po úspěšném dokončení stahování. Při testech se ale ukázalo, že za dokončená musela být považována i neúplná či jinak nekorektní stažení, asi díky tomu, že downloader problém nejspíš ani nedetekoval.

Používání software po ukončení studia/zaměstnání na FEKT (více)(méně)

Jak jistě víte, licenční podmínky MSDN AA umožňují pokračovat v používání získaného software z MSDN AA i po ukončení studia či zaměstnání na FEKT (nadále se při tomto používání ovšem musíte řídit podmínkami a omezeními, která z licenčních podmínek vyplývají). Po ukončení vztahu k FEKT už ale licence nedovoluje získávat další software a proto Vám po odchodu z FEKT již nemůže být umožněn přístup do eLMS.

To ovšem znamená, že po ukončení studia či zaměstnání na FEKT již nebudete mít ani přístup k informacím, které jsou zde uloženy a tedy si nebudete ani moci stáhnout software ani zjistit produktové klíče, které jste během studia či zaměstnání legálně získali! Nemáte-li zároveň vlastní zálohy, po odchodu z FEKT kvůli tomu můžete mít problémy s pokračováním v používání legálně nabytého software!

Správce MSDN AA k těmto informacím může mít přístup i nadále. Důrazně však nedoporučujeme na toto spoléhat, protože dodatečné zpřístupnění těchto informací bývalým studentům či zaměstnancům může být administrativně dost složité. V případě nemožnosti ověření žadatele by byla nutná osobní přítomnost a prokázání totožnosti. Navíc v novém systému již nemá správce k vydaným produktovým klíčům tak pohodlný přístup jako ve starém systému, kde bylo možné zobrazit si naráz všechny klíče vydané jednomu uživateli. Vytvoření seznamu všech produktových klíčů tak může být zbytečně pracné.

Kromě toho podle vyjádření provozovatele eLMS takovéto dodatečné zpřístupnění produktových klíčů má údajně porušovat podmínky MSDN AA. Dosavadní praxe, kdy skončivším studentům byly jim vydané produktové klíče na žádost dodatečně zpřístupněny, proto možná skončila zcela definitivně.

Další stažení a další produktový klíč jsou 2 naprosto rozdílné věci (více)(méně)

Možná je to jen dojem, možná ale skutečně není jasný rozdíl mezi mezi těmito dvěma pojmy uvedenými v nadpisu. Pro jistotu bude rozdíl mezi těmito pojmy dále vysvětlen včetně příslušných souvislostí.

Při používání eLMS a software z MSDN AA se lze setkat se dvěma základními omezujícími prostředky. Prvním je již zmíněné omezení počtu pokusů pro stažení software. Tím druhým jsou produktové klíče resp. vydané licence, ke kterým produktové klíče přísluší. Princip omezení počtu pokusů pro stažení software je asi zřejmý z názvu, blíže je však popsán také ve výše odkazovaném bodě. U produktových klíčů je omezení dáno standardním nárokem na 1 licenci produktu u každého uživatele, přičemž účinnost tohoto omezení v praxi může být vynucována povinnou aktivací u některých produktů.

Jak by nyní mělo z předchozího popisu být zřejmé, jedná se o dvě různá omezení s rozdílnou funkcí. Pojmy zmíněné v nadpisu této části jsou pak prostředky, které správci MSDN AA umožňují tato jednotlivá omezení obejít či zmírnit. Každý z nich se vztahuje k jednomu z popsaných omezení a z toho také vyplývá jejich rozdílné využití. Pro podávání správných a účelných žádostí je třeba tento rozdíl rozlišovat.

Povolením dalšího stažení tedy nedojde k vydání další licence ani produktového klíče! Tímto povolením může správce MSDN AA umožnit pouze další stažení produktu, u kterého uživatel vyčerpal pokusy pro jeho stažení.

Analogicky, vydáním další licence resp. produktového klíče nedojde nutně k umožnění dalšího stažení produktu, u kterého má uživatel pokusy pro stažení již vyčerpány. Alespoň teoreticky; prakticky bude známo, až se vyjasní postup vydávání dalších licencí v novém systému. Zatím je proto třeba předpokládat, že v tomto případě dojde pouze k vydání další licence (pro další instalaci lze opakovaně použít již staženou kopii daného software).

Možná, že jedním ze zdrojů zmatení býval nevhodný název tlačítka sloužícího pro vyvolání formuláře pro podání žádosti o povolení dalšího stažení ve starém eLMS. Toto tlačítko zde bývalo označeno poměrně zavádějícím popiskem Request Re-Install, což mohlo vést ke zbytečnému podávání žádostí o další stažení v těch případech, kdy by bylo na místě spíše vydání další licence pro instalaci na dalším počítači nebo kdy bylo třeba řešit problém s (re)aktivací po přeinstalaci. Popisek tohoto tlačítka byl ale na základě naší reklamace již před více jak rokem změněn na snad méně matoucí znění Request Additional Downloads.

Vydání dalšího produktového klíče pro reaktivaci nepřipadá v úvahu (více)(méně)

Vydání dalšího produktového klíče pro reaktivaci software nepřipadá v úvahu z velmi prostého důvodu – pro tento případ je to zcela nepřiměřené řešení. Pokud bychom tento postup převedli do situace uživatele s běžnou placenou maloobchodní licencí, rovnal by se tento postup zakoupení nové(!) licence, a asi jen málokdo by byl ochoten platit za něco opakovaně.

Případné problémy při reaktivaci produktu je proto třeba řešit způsobem obvyklým pro takový případ. To znamená obrátit se na podporu výrobce daného software, neboť se jedná o problém s konkrétním produktem. Protože nejde o záležitost týkající se specificky MSDN AA, správce MSDN AA nemůže v této věci nijak pomoci. Dle dostupných informací příslušný postup obnáší zavolání na aktivační linku Microsoftu, kde stačí požádat o povolení reaktivace.

Informace v tomto bodě se nevztahují na problémy již při prvotní aktivaci. Občas už se stalo, že vydaný produktový klíč nebyl použitelný a bylo nutné vydat klíč nový. Protože jde o zcela odlišný problém, žádosti o vydání náhradního produktového klíče v tomto případě budou akceptovány.