Windows Server 8 béta - Távoli elérés és munka

2011 szeptemberében a Microsoft kiadta a következő hálózati operációs rendszerének, jelenlegi kódnevén Windows Server 8-nak a nagyon korai, ún. "Developer Preview" (DP) változatát. A fanatikusok (jómagam is) ezt már ütögették rendesen, de ez még tényleg egy elég korai változat volt, egy halom dolog nem, vagy nem helyesen működött. Aztán jó ideig látszólag semmi nem történt, míg végül 2012 februárjának utolsó napján letölthetővé vált a következő mérföldkő a "Beta".

A két dátum közötti időszakban a Microsoft legújabb kori elvei értelmében nem igazán voltunk elkényeztetve információval vagy köztes verziókkal, most viszont a telepítő image-ek mellett több száz oldalnyi deployment guide, step-by-step doksi, és egyéb adalék áll rendelkezésre. Ebben a sorozatban megpróbálom követhető terjedelemben összefoglalni a legfontosabb újdonságokat, mind a DP óta, mind úgy általában a Windows Server 2008 R2-höz képest.

Távoli elérés és munkavégzés

A Windows szerverek világában ez az egyik olyan nagy terület, amelynek alkotóelemei az elmúlt 4-5 évben „gigamega” fejlődésen mentek keresztül – nyilván nem véletlenül, hanem inkább az igények apropóján. A Windows Server 2008-cal kezdődött a folyamat, amikor is a klasszikus, tizenvalahány éves Terminal Services (akkor még ez volt a neve) szerepkör olyan plusz megoldásokkal bővült, mint például a RemoteApp, a WebAccess, vagy éppen a Gateway. De a távoli elérésben is kaptunk újdonságot, például az SSTP-t, azaz egy új SSL VPN típust, és persze szintén kibővült és új nevet is kapott (Network Policy and Access Server) a korábbi Windows Serverekből jól ismert RRAS, IAS, stb. elemeket tartalmazó, beolvasztó szerver szerepkör is. Ebből a felsorolásból egyébként az is látszik rögvest, hogy ez igazából két terület (elérés, munkavégzés), és az is hogy elsősorban a felhasználók elérésére és munkavégzésre koncentrálunk és nem a felügyeletre.

De ez még csak a 2008 év termése volt, az igazán „durva” dolgok ezután, azaz az R2-vel érkeztek. A távoli elérésben az IKEv2 (VPN Reconnect), és főleg a DirectAccess, azaz a belső hálózat IPv6-on és IPSec-en alapuló, folyamatos elérése, amelyet sokszor hasonlítunk a VPN-hez, de úgy, hogy azt is elmondjuk, hogy jóval több és más is, mint a klasszikus távoli elérési forma. A terminálszerver rajongók vére is felpezsdült az R2 beta időszakban, mivel sok-sok apró korrekció mellett az eddig egydimenziós Session Broker helyett kaptunk egy univerzális Connection Brokert, valamint a Hyper-V virtualizációval együttműködő „Virtualization Hosts” képességet. Ezzel megnyílt a lehetőség a VDI (Virtual Desktop Infrastructure) kiépítésére, és a felhasználók az RD Web Accessen, azaz az RD portálon keresztül, a böngészőből kaphattak saját, személyes használatú vagy „12 egy tucat” típusú (pooled) virtuális gépeket. Ja és persze nem elírás az RD* rövidítés használata, a Terminal Services-ből Remote Destop Services lett, mert az átnevező kommandó él és virul.

A session virtualizáció (RDS)

Büszke vagyok magamra, mert 295 szóban összefoglaltam majdnem 5 igen sűrű évet és 2 teljes operációs rendszert, de lépjünk tovább, nézzük mi látszik megvalósulni jelenleg, azaz a Windows Server 8 Beta kapcsán ezen a tényleg dinamikusan bővülő területen. Először is tovább osztódunk, első körben tekintsük át az RDS, azaz a munkamenet virtualizáció újdonságait.

^{Nagy változás nincs, de az ördög a részletekben rejtőzik majd – mint mindig}

A komponensekben listájában nem látni változást, ellenben egy RDS/VDI rendszer feltelepítésében felépítésében igen, méghozzá többet is. Például rögvest választhatunk a Server Managerben egy olyan szkenáriót, amelyben az RDS (vagy a VDI-jal bővített RDS) szerepkörök egy menetben felkerülnek a rendszerünkre (Remote Desktop Services scenario-based installation).

^{Ez a kép  már ismerős lehet az előző cikkből}

Ha ezt választjuk, akkor újabb elágazás jön, azaz egyrészt mondhatjuk azt, hogy van egy rakat készenlétben álló szerverünk, hogy egy igazán profi vállalati RDS infrastruktúrát rakjunk össze, de egy helyről, azaz erről a gépről. Vagy kicsiben akarunk játszani, és mondjuk összesen 1 db (!) gépünk van minderre.

^{Itt még bármi lehet, kicsi vagy nagy rendszer egyaránt}

Ha kitaláltuk, hogy mit szeretnénk (én elsőre az egyszerűbb Quick Start-tal kezdem), akkor el kell döntenünk, hogy VDI-jal spékelt rendszert építünk, vagy csak egy „szimpla” RDS-t.

^{Újabb döntési lehetőség, a cikk első felében maradok az RDS-nél}

Ezután már csak az kérdés, hogy melyik szerveren dolgozunk (mert ugye tudjuk az előző cikkből, hogy bármelyikről bármelyikre tudunk telepíteni), aztán közli a telepítő, hogy a Connection Broker, a Session Host és a Web Access telepítésre kerül, és lesz restart is.

^{Csík csík hátán, készül az RDS központ}

Ha netalántán a 2. képnél a Standard opciót választjuk, akkor a szerepkörökhöz kellemes kis varázsló is párosul, azaz a már elérhető, működő kiszolgálókat szépen hozzárendelhetjük a különböző RDS szerepkörökhöz. Ez persze egyúttal azt is jelenti, hogy egy helyről fogjuk tudni felügyelni is az összes RDS gépünket.

^{Ha a Standard típust választjuk, akkor elkezdhetjük kiválogatni a szervereket az RD szerepkörökhöz}

Ami még a telepítési/felügyeleti résznél komoly változás, az az hogy nincs elengedve a kezünk, további kellemes és egyértelmű varázslók segítik a végső konfiguráció kialakítását, vagy megváltoztatását (pl. további Session Host szerverek hozzáadása is innen történhet).

^{Innen mindent látunk és elérhetünk, valószínű ezt hívják „unified experience”-nek}

^{A telepítési folyamat befejezése indulhat az előző kép Deployment Overview / Tasks pontjából. Itt konfiguráljuk a megmaradt RD szerepköröket, plusz pl. a tanúsítványokat}

Ha még egyszer visszanézünk az „Overview” képre, akkor egy teljesen ismeretlen elemet is láthatunk a baloldali keretben, ez lenne a „Collections”, amelyben egy „QuickSessionCollection” pont már létezik is, ami gyakorlatilag egy, a telepítő által létrehozott csoport, amelyben nálam akkor még csak egyetlen RDSH szerver volt. De egyszerűen gyárthatunk tetszés szerinti „Session collectiont” (hogy értsük: ez lenne nagyjából a korábbi rendszerekben megszokott farm). Egy ilyen kollekcióban aztán az  adott RDSH gépek összes, központilag piszkálható beállítása található (jogosultságok, kliensbeállítások, load balancing, RemoteApp publikálás, aktuális kapcsolatok, stb.).

De miért csinálnánk egynél több kollekciót? Például mert különböző biztonsági szabályokkal működő farmokat tervezünk, vagy el akarjuk választani a klasszikus RDP-vel elérhető RDS szervereket azoktól, amelyeken csak a RemoteApp programokat érhetik el a felhasználók. Bármelyik esetről van szó, 100000 beállításban tehetünk különbséget a két környezet között – és továbbra is egyetlen gépről!

^{A Netlogon RDS kollekcióban két RDSH gép van, és pont most konfigurálom a terheléselosztást}

Még egy dolog, amihez már nem társul látványos képi elem, de azért igen fontos, főképp a nagyobb rendszerekben. A Windows Server 2008 R2-ben megismerhettük a „FairShare” technikát, amellyel felválthattuk a „testvéries” erőforráskiosztást a user munkamenetek között, de csak a CPU szintjén. A FairShare lényege röviden, hogy aki több erőforrást követelt, az sem kapott egy időszeleten belül többet, mint a másik, hanem várt a sorára. Egy Windows Server 2003-nál bizony megkapta az adott session a teljes igényét, akár a többi session hátrányára is, ezért emlegetem a testvéries szót, szemben a FairShare-rel megvalósított igazságossal (2 fiatalabb testvérem van, tudom, miről beszélek). Mostantól viszont  a WS8-ban mindezt kiterjeszthetjük a lemezekre (I/O műveletek), és a hálózati erőforrásokra is (sávszélesség), ami egy igen pozitív előrelépés.

A VDI

Ha az RDS-nél megértettük a Standard/Quick forgatókönyvek lényegét, akkor azt rögtön implementálhatjuk a VDI-nál is, ráadásul az első két lépés ugyanaz lesz. De aki ismeri az R2-es VDI-t, az rögtön kiszúrja majd ebben a mondatban a csapdát, azaz hogy a VDI-nál úgyis minimum két fizikai szerver kell, egy RDS és egy RDVH, tehát mi ebben az egyszerű? Hát az, hogy nem kell két szerver, immár egyetlen gépen is összehozhatjuk a Connection Broker + Web Access + Virtualization Hosts rész-szerepköröket.  A varázsló mindent felrak ezekhez, igazából  egyetlen paramétert kell megadnunk, egy darab sablont, ami a VDI-t alkotó kliens virtuális gépek sysprepelt változata lesz (ez egy .vhd gyakorlatilag).

<sup>Egy sysprepelt image-re szükségünk lesz, és bár sehol nem derült ki előzetesen, de a .vhdx a tapasztalataim szerint nem megfelelő


3 csík versenyez a kedvünkért</sup>

És a legszebb az egészben hogy ezek után máris működik a VDI környezet, azaz az RD WebAccessen keresztül be is léphetünk egy virtuális gépbe, mivel minden mást megcsinált a varázsló! Nyilván célszerű lesz még jó pár beállítást megtenni illetve testre is szabni, de aki rakott már össze VDI-t R2-vel, az tudja, hogy rengeteg piszmognivaló volt az első indításig, például a kliensekkel, a Connection Brokerrel és magával a Hyper-V-vel is. Ez itt nincs, működik egyből.

^{Ez bizony egy W8 CP virtuális gép a böngészőből, de esküszöm, hogy hozzá nem nyúltam a Hyper-V-hez kézzel}

A gyári alapértelmezés az megint csak egy kollekció, ami itt a „QuickVMCollection” névre hallgat, és amelyben finomhangolhatunk is, de akár egy újat is létrehozhatunk. Ez egyébként egy 13 lépéses varázsló, amiből szintén látszik, hogy számos új lehetőséget is elnyertünk a WS8-cal.

^{Most éppen egy új kollekcióban a személyes virtuális gépeket konfigurálom}

De egy VDI kollekcióban is kreálhatunk RemoteApp-okat, a virtuális gépekből származtatva az alkalmazásokat (lásd RemoteApp for Hyper-V!), vagy készíthetünk egy „User logoff policy”-t, ami a kötelező rekreáció miatt lehet fontos. De virtuális desktop-oknak és a sablonoknak is van jó pár konfigurálható opciója, illetve a desktopok számának bővítése is kellemesen egyszerű feladat (és soha nem a Hyper-V-ben kell szöszmötölnünk).

<sup>2 már van, kérek még hármat


Mintha a keltetőben lennénk, úgy élednek fel a virtuális gépek a Hyper-V alatt, és még a Rollback pillanatfelvétel gyártása is teljesen automatikus</sup>

Ha már VDI, akkor foglalkozzunk kicsit a felhasználókkal is. A RemoteFx-en, az USB-eszközök kiemelt támogatásán (RDS és VDI egyaránt) és az SSO fejlesztéseken kívül, nagy segítség lesz egy további újdonság, az ún. „User profile disks”, ami a felhasználók környezeti beállításainak tárolásában segít (a user profil részeiről van szó), amelyeket központilag egy hálózati megosztásra irányítva és pl. méretkorláttal ellátva állíthatunk be a VDI felhasználóknak, no és persze ez a beállítás is kollekcióként lehet más és más.

Távoli elérés

Ennyi lenyűgöző újdonság után szerintem még mindig tudok újat mondani, de ehhez térjünk rá a VPN és a DirectAccess képességekre! Igazából a VPN résznél annyira nem is tobzódunk az újdonságokban, némi S2S változás, a PowerShell-kompatibilitás és maximum a kezelőfelület változása az, ami feltűnik, ugyanis a megszűnt DA MMC helyett az új ún. Remote Management konzolban a DA mellett a VPN/Dial-up kapcsolatainkat is kezelhetjük (mivel az RRAS és a DA integrálódott), de nagyjából más változást nem látok WS8 VPN-ügyben, kérem kapcsolja ki.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Ellenben a DirectAccess-fétisünket halmozottan kiélvezhetjük a WS8-ban. Finoman szólva is átalakult ez a sokak számára kissé (nagyon) bonyolult és sok kötöttséggel rendelkező, sok szakembert elriasztó komponens. Pont ezért nézzük meg, hogy mennyiben egyszerűsödött a helyzet elsőként a felügyelettel és az ellenőrzéssel  kapcsolatban:

• Az új konzolon rengeteg plusz infót  láthatunk és jóval logikusabb elrendezésben, mint korábban.  A Dashboard-on belül a szerverek valamint a kliensek állapota, meg az aktivitásuk is remekül követhető
• Az „Operations status” alatt a DA-t alkotó összetevők „egészségi” állapota látszik
• A Dashboard-ról jelentéseket is tudunk egyszerűen generálni
• Az „Accounting” pontban döntjük el, hogy hová naplózzunk, egy helyi Windows Internal Database-be, vagy egy távoli RADIUS szerverbe. Ez a naplózás tárolja a távoli user adatokat, a statisztikákat, a szerver használatot és a konfig változásokat is.

^{Ez lenne az új Dashboard}

Még két dolog ami ide tartozik, egyrészt a DCA-t cserélő NCA (Network Connectivity Assistant) alapból be van építve a Windows 8-as kliensekbe és szerveren is integrálódik a DA konfigba, másrészt máris van DCA 2.0 Beta a Windows 7-es kliensek számára (ami pl. támogatja az OTP-t is, azaz a One Time Password hitelesítési típust). Másrészt a járvány ide is betört, azaz teljes körű PowerShell-támogatás van. Ami azért nagyszerű, mert a korábbi nehézkesen és időnként csak hosszú parancsokkal operáló netsh helyett (azért szeretjük ám!) rengeteg parancs és szkript használható többek között pl. a hibakereséshez.

De haladjunk tovább és nézzük meg, hogyan dőlt le jó pár korábban a WS08R2 DA esetén fennálló kőkemény implementációs tabu. Ezek döntögetése azért igazán kellemes, mert így egyszerűbb lesz a bevezetés, ami főképp a KKV környezetben lesz hasznos, ugyanis:

• A telepítő varázsló akár összesen 2 lépésből is állhat (nem viccelek), a többi teendő automatikusan megtörténik.
• Lehet tűzfal mögött a DA szerver, tehát átmegy a NAT-on is, tehát nem kell a 2 db publikus IPv4-es cím (de lehet benne 2 NIC is, lásd következő kép)
• Lehet egyetlen hálózati interfésszel is DA szervert építeni
• Nem kötelező a PKI infrastruktúra kiépítése, egy self-signed tanúsítvánnyal is kiválóan működik (ha W7-es DA kliensünk is lesz, akkor azért kell egy root CA)
• A csak IPv4-gyel működő belső szerverek elérése is megoldott, tehát nem szükséges a belső hálózatban valamilyen konverziós megoldás.
• Eleddig két IPSec csatornával működött a DA, röviden és sarkítva egy kellett a gépnek, egy pedig a felhasználónak, de innentől egyetlen tunnellel is képes működni
• Telepítési mód: immár van lehetőségünk arra, hogy válasszunk, a kliensek távoli elérést és távoli felügyeletet kapjanak, vagy csak távoli felügyeletet.

^{A 3 variáció több mint 1}

Huhh, ez nem kevés, de ha ez nem elég, akkor pár újdonságot felsorolnék még, önkényesen válogatva és ömlesztve:

• NAP támogatás (eddig csak a Forefront UAG-gal működött)
• TPM-alapú virtuális smartcard támogatás
• One-time password (OTP) hitelesítés (eddig csak a Forefront UAG-gal működött)
• Egyszerű migráció a Forefront UAG DA-ról
• NLB támogatás (eddig csak a Forefront UAG-gal volt elérhető)
• IP-HTTPS proxy mögött: eddig ha kötelező volt a proxy hitelesítés egy idegen hálózatban, akkor a böngészővel ugyan kimentünk a netre ha volt usernév+jelszó, de a DA klienssel IP-HTTPS-sel nem
• IP-HTTPS NULL encryption: mint tudjuk, az IP-HTTPS mindig is izmosabb teljesítményt követelt a dupla titkosítás miatt, ezért is számított kevésbé favoritnak a trancíziós megoldásoknál. A WS8-ban éppen ezért az IP-HTTPS a felesleges redundáns SSL titkosítás megszűnt
• Multisite: földrajzi, vagy failover okokból kialakíthatunk egy ún. multisite konfigurációt is, amikor a kliensek több ponton (több DA szerveren) keresztül is be tudnak lépni.

^{Ne feledjük, a W7-es DA klienseket külön engedélyezni kell}

Bár sok helyen rövidítettem és egyszerűsítettem, és sok mindent ki is hagytam, de azt gondolom ezután röpke leírás után joggal kapkodhatjuk a fejünket a Windows Server „8” újdonságai miatt. És még nincs vége, legközelebb a Hyper-V jön, ami szintén odacsap rendesen.

Gál Tamás
informatikai vezető, vezető oktató, IQSOFT-John Bryce Oktatóközpont