Hopp til hovedinnhold

Azure - Windows Virtual Desktop

Petter Arnesen
Pc med koder

Innen Azure skjer det vanvittig mye spennende, det er det liten tvil om. Nå har de norske Azure datasentrene til Microsoft åpnet og det kommer stadig nye tjenester man kan ta i bruk. En av den mest spennende nye tjenesten, særlig for SMB bedrifter, heter Windows Virtual Desktop.

Windows Virtual Desktop kan brukes for å løse det som for mange bedrifter er siste hinder for å bli kvitt alt av egne servere, den ene gjenværende applikasjonen (eller flere for den saks skyld) som ikke lar seg erstatte av en ren skytjeneste. Enten fordi det ikke finnes en tilsvarende skytjeneste eller fordi bedriften har så mange spesialtilpasninger i applikasjonen at det ikke lar seg gjøre å bruke en tilsvarende skytjeneste.

På en annen side kan også Windows Virtual Desktop benyttes som et verktøy i et hybrid scenario, hvor du har en og samme inngangsport til applikasjoner som har tilknytninger i skyen som til applikasjoner som har tilknytninger mot on-prem systemer (lokale servere). Dette kan være med på å gjøre overgangen fra on-prem til all-cloud (alt av servere i skyen) meget smidig og tilnærmet umerkelig for brukerne.

Bakgrunn

Teknologien bak Windows Virtual Desktop er velprøvd og perfeksjonert over mange år. Teknologien het Terminal services da den ble lansert med Windows NT Server 4.0 Terminal Server Edition tilbake i 1998. Den gangen var det et helt eget operativsystem og det ga brukere muligheten til å kjøre alle sine applikasjoner inne i et eget skrivebord som ble tilgjengeliggjort fra serveren. Dette gjorde at det var serveren som sto for alt av regnekraft og det eneste klientmaskinene trengte å gjøre var å vise skjermbildet som ble sendt fra serveren. Videre gjorde dette at bedriftene kunne spare inn kostnader ved å benytte seg av såkalte tynne klienter ute hos brukerne. Tynne klienter er fortsatt mye brukt i dag og de kjennetegnes gjerne av at de har begrenset med maskinkraft, er rimelige i innkjøp og kan lett byttes ut uten at sluttbruker nødvendigvis merker noen forskjell.

Teknologien fikk seg et vesentlig løft med lanseringen av Windows Server 2008 og et nytt navn sammen med lanseringen av Windows Server 2008 R2. Fra da av har teknologien gått under navnet Remote Desktop Services.

Den største nyheten som kom med Windows Server 2008 var introduksjonen av en rekke infrastrukturroller, dette gjorde at man kunne fordele rollene over flere servere og på den måten kunne tjenesten skalere på en helt annen måte enn tidligere. De forskjellige rollene som ble introdusert er blant annet følgende:

Remote Desktop Gateway

Fungerer som inngangsporten til tjenesten. Denne rollen gav oss også muligheten til å tilby Remote Desktop Services over internett, uten å måtte bruke VPN

Remote Desktop Connection Broker

Fordeler brukerne jevnt ut over de forskjellige serverne i løsningen. Sørger også for at du som bruker blir tilkoblet samme server som du var tilkoblet sist hvis du f.eks. skulle miste nettilkoblingen et lite øyeblikk. På den måten kan man unngå tapt arbeid.

Remote Desktop Session Host

Er selve arbeidshestene i løsningen. Det er disse applikasjonene kjøres på og som står for regnekraften i løsningen.

Remote Desktop Web Access

Gir brukerne en nettside de kan logge på for å starte skrivebord eller applikasjoner.

Remote Desktop Licensing

Her legges alle lisenser for løsningen inn og denne sørger da for å tildele lisens til brukerne etter hvert som de logger på, samt at den holder oversikten over disse.

Disse rollene eksisterer fortsatt i Windows Virtual Desktop, men Microsoft besørger disse for deg, uten kostnad. Mer om det senere.

Med lanseringen av Windows Server 2008 R2 fikk man ikke bare et nytt navn på teknologien, man fikk også en utrolig nyttig ny tjeneste: RemoteApp.

RemoteApp introduserte muligheten til å sømløst publisere applikasjoner og ikke bare skrivebord. Ved å gjøre dette kan man kombinere kjøring av applikasjoner lokalt og via Remote Desktop Services, noe som gjorde at f.eks. tunge applikasjoner kunne kjøres på server og lettere applikasjoner kunne kjøres lokalt. Dette gir jo da det beste fra begge verdener, man sparer kostnader til maskinkraft ute hos brukerne, samtidig som det ikke går på bekostning av brukervennligheten.

Introduksjonen av RDmi

Spol fremover til 2016 og det ryktes i det stille at Microsoft har startet utviklingen av Remote Desktop Modern Infrastructure (RDmi), den offisielle annonseringen av RDmi fra Microsoft kom på Inspire-konferansen i 2017. RDmi skulle modernisere infrastrukturen rundt Remote Desktop Services og bedre sikkerheten betraktelig.

Sikkerheten ble bedret bl.a. ved å isolere rollene som var eksponert mot internett (f.eks. Gateway og Web Access rollen) og ved å legge til støtte for moderne autentisering.

Brukervennligheten ble økt ved at man la inn støtte for å bruke en lang rekke enheter for å koble seg til. Tidligere var man avhengig av å bruke enheter som kjørte Windows, ellers måtte man ty til tredjeparts klienter. Med RDmi kom det støtte for og klienter til blant annet Mac og Android-enheter. Det ble også mulig å koble seg til via en hvilken som helst nettleser med støtte for HTML5. Dette igjen gjorde at man nå kunne tilby Windows-baserte applikasjoner til brukere som ikke hadde kunnet kjøre dette tidligere, for eksempel brukere på Linux.

RDmi tok også steg mot å gjøre det mulig å ha en infrastruktur for Remote Desktop Services hvor man tok i bruk Azure sine PaaS- (plattform som en tjeneste) tjenester i stor grad. Flere av de tradisjonelle Remote Desktop Services rollene kunne nå kjøres som App Servicer i Azure og man kunne benytte seg av Azure SQL-databaser for miljøet i stedet for en fullverdig SQL server.

Renote1

RDmi ble lagt på is fra Microsoft sin side, men du finner veldig mange av byggeklossene igjen i dag i Windows Virtual Desktop.

Lansering av Windows Virtual Desktop

I september 2018 ble Windows Virtual Desktop annonsert av Microsoft og hovedpoenget den gangen var at dette var den første tjenesten hvor man kunne få en full Windows 10 og Office 365 ProPlus opplevelse i et flerbruker-scenario. Tidligere hadde man kun fått dette ved å ta i bruk forskjellige VDI-løsninger (Virtual Desktop Infrastructure) fra leverandører som Citrix og VMware. VDI fungerer på mange måter likt som Remote Desktop Services, men den store forskjellen er at man i VDI-løsninger har dedikerte, virtuelle maskiner til hver eneste bruker.

Siden Windows Virtual Desktop tok i bruk veldig mye av det Microsoft utviklet under navnet RDmi gikk utviklingen av tjenesten raskt, med en prøveversjon tilgjengelig i mars 2019 før den endelige versjonen ble tilgjengelig for alle (GA, Generally available) i september 2019.

Enklere infrastruktur med Plattform-som-en-tjeneste (PaaS)

Et tradisjonelt Remote Desktop Services miljø vil kreve flere servere kun for å holde infrastrukturen i løsningen i gang. I tillegg til rollene beskrevet lenger opp kreves det også en databaseserver for miljøet og domenekontroller. Selv om man konsoliderer og samler flest mulig roller på færrest mulig servere involverer et slikt miljø gjerne derfor 5 servere som et minimum. Et typisk miljø kan se omtrent slik ut:

Remote2

I eksemplet over har man da samlet Gateway og Web Access rollene på 1 server som er lagt i en ytre sone. Denne er da eksponert for internett og tilbyr brukere å for eksempel jobbe hjemmefra. Licensing rollen har blitt lagt på en eksisterende domenekontroll, man har en databaseserver for miljøet og X antall servere med Session Host rollen. Man har også lagt Web Access rollen på samme server som også har Connection Broker rollen, dette gjøres vanligvis i slike miljøer for å unngå at brukere på innsiden (kontornettet) må ta omveien ut på internett for å få tilgang til miljøet.

I Windows Virtual Desktop håndterer Microsoft mesteparten av dette for deg og leverer det som en tjeneste. Det eneste du trenger å tenke på er en domenekontroller og den tradisjonelle Session Host rollen. Domenekontrolleren kan også med fordel byttes ut med en annen tjeneste i Azure, Azure AD Domain Services. Dette gir det 80-90 prosent av funksjonaliteten du er vant med fra Active Directory lokalt, mer enn nok til et Windows Virtual Desktop miljø. I tillegg vil Azure AD Domain Services alltid synkronisere brukere fra Azure AD (brukerdatabasen til Office 365).

Dermed er det eneste igjen av tradisjonell infrastruktur du trenger å tenke på de maskinene som skal ha Session Host rollen. Dette er som nevnt selve arbeidshestene i løsningen, det er her applikasjonene kjøres. Og, det er en grunn til at jeg nå skrev maskiner og ikke servere, for med Windows Virtual Desktop kan man bruke maskiner med Windows 10 eller Windows 7 til Session Host rollen. Dette gir flere fordeler som vi skal komme tilbake til litt senere.

Tar vi høyde for ovennevnte vil en Windows Virtual Desktop infrastruktur kunne se slik ut:

Remote3

Som dere ser er infrastrukturen meget redusert i forhold til et tradisjonelt Remote Desktop Services miljø. I eksemplet over inneholder da Windows Virtual Desktop følgende av de tradisjonelle Remote Desktop Services rollene:

  • Gateway
  • Web Access
  • Licensing
  • Connection Broker

Disse trenger man ikke å forholde seg til på noen måte, de vil alltid kjøre, alltid være tilgjengelig og alltid være skalert til bruken for bedriften.

Skalering og tilgjengelighet

Som nevnt over vil infrastrukturkomponentene i Windows Virtual Desktop, de som håndteres av Microsoft, alltid være skalert til bruken av den så der trenger du ikke bekymre deg for om du har nok ressurser.

Om man også velger å gå for Azure AD Domain Services vil man heller ikke trenge å bekymre seg for skalering av denne, og da står man igjen med Session Host rollen som man må sørge for å skalere til sitt behov. Her er det i hovedsak to forskjellige måter å gjøre det på: skalere opp eller skalere ut.

Ved å skalere ut fordeler man lasten over flere maskiner, mens man ved å skalere opp øker ressursene på de maskinene man har.

Skalering ut

Windows Virtual Desktop kan konfigureres på en slik måte at brukere enten kan fordeles på så mange maskiner som mulig eller så få som mulig. Velger man å fordele brukerne på så få maskiner som mulig kan man skru av maskiner som ikke er i bruk av noen, og på den måten påløper det ingen kostnader for regnekraft (compute) for disse. Samtidig kan oppstart av flere maskiner automatiseres, slik at om antall brukere som logger på øker, kan man øke antall maskiner tilgjengelig. På den måten har man automatisk skalering ut ved behov. Går antall brukere av løsningen ned igjen kan man skru av maskiner for å redusere kostnadene, dette kalles å skalere inn igjen og kan også automatiseres.

Skalering opp

Har man et mindre miljø, med få brukere, som man ikke forventer skal vokse så kan løsningen med å skalere opp være aktuell. I et slikt miljø setter man gjerne opp et mindre antall maskiner til Session Host rollen, kanskje så lite som 1 maskin. Ved å ha færre maskiner vil man redusere kompleksiteten i løsningen, færre bevegelige deler betyr gjerne også færre ting som kan gå galt.

Ulempen med å gå for løsningen med å skalere opp og ned er at maskiner i Azure må skrus av for at man kan endre på ressursene de får tildelt. Dette innebærer da at brukere må logge ut og maskiner må skrus av for å tildele mer ressurser, eller for å redusere ressursene.

Tilgjengelighet

Siden Windows Virtual Desktop er en løsning som leveres i skyen er den tilgjengelighet overalt hvor man har tilkobling til internett. Det er her ingen behov for VPN-løsninger for å få tilgang til systemene.

Som nevnt lenger opp så introduserte RDmi muligheten for å bruke en rekke forskjellige klienter, også HTML5. Dette er også videreført, og utvidet, i Windows Virtual Desktop. Det finnes klienter til Windows, macOS, iOS, Android og Windows 10 IoT Enterprise. Støtte for Linux-baserte tynnklienter og tynnklienter fra Dell er planlagt.

Remote4

Web-utgaven gjør at så lenge man har en moderne nettleser kan man sitte på hvilken som helst enhet man vil, også Linux baserte enheter.

Har du kanskje noen i bedriften som sverger til Mac eller Linux, mens kritiske bedriftssystemer kun kan kjøres på Windows? Da er Windows Virtual Desktop en utmerket løsning. De ansatte kan bruke den type maskin og det operativsystemet de helst vil, samtidig som de får tilgang til alle bedriftens systemer.

Fleksibilitet til å skynde seg langsomt

Mange har i dag et ønske om, eller en strategi for, å bli kvitt sine on-prem systemer og heller ha alt i skyen. Her kan Windows Virtual Desktop være med å gjøre overgangen særdeles smidig for brukerne.

Ved å sette opp en forbindelse mellom Azure og on-prem miljøet kan brukerne via Windows Virtual Desktop kjøre applikasjoner i Azure som er avhengig av ditt lokale on-prem miljø. Hvis man gjør dette som et første steg så kan man deretter flytte system for system over til Azure mens brukerne fortsatt benytter seg av samme måte å få tilgang til sine applikasjoner på. Overgangen blir dermed umerkelig for brukerne og du som IT-admin kan ta den tiden som trengs for å flytte alt over i skyen.

Sikker tilgang til applikasjoner

Vi i Lillevik IT er veldig glade i betinget tilgang, dette har vi skrevet om i mer utførlig detalj blant annet her og her.

Windows Virtual Desktop benytter seg av moderne autentisering (modern authentication) og kan dermed kombineres med betinget tilgang. Dette gjør at Windows Virtual Desktop kan settes opp på en slik måte at når brukere skal logge på så må de enten sitte på en enhet som er administrert og godkjent av bedriften (f.eks. ved at antivirus er oppdatert, enheten er kryptert osv) eller så må de benytte multifaktor autentisering (MFA) ved innlogging. På den måten sikrer man seg mot at uvedkommende får tilgang til systemene hvis de skulle klare å snappe opp brukernavnet og passordet til en av dine ansatte.

Lisensiering

Som med så mange andre tjenester så krever også Windows Virtual Desktop at man har riktig lisens for å lovlig kunne bruke tjenesten. Men her er sjansen stor for at din bedrift allerede har lisensene på plass.

Lisens for bruk av Windows Virtual desktop er inkludert i Microsoft 365 Business, E3, E5, A3, A5 og F1. Har man allerede kjøpt RDS CAL lisenser for Windows Server 2012 R2 til bruk på on-prem kan også disse dekke Windows Virtual Desktop om man har en aktiv Software Assurance fordel på disse.

Om man ikke allerede har noen av disse kan Windows Virtual Desktop også lisensieres med følgende lisenser:

  • Windows 10 Enterprise E3/E5
  • Windows 10 Education A3/A5

Oppsummert så kan altså Windows Virtual Desktop lisensieres på flere forskjellige måter, kanskje har din bedrift allerede de lisensene som behøves, gjennom eksisterende Microsoft 365 abonnement.

Konklusjon

Windows Virtual Desktop gir bedrifter en særdeles smidig og kostnadseffektiv måte å tilby sine ansatte å jobbe fra akkurat den enheten de vil, samtidig som de får tilgang til de applikasjonene de har behov for.

For mange bedrifter kan Windows Virtual Desktop bety den endelige slutten på lokale servere ved at applikasjoner som er avhengig av lokale servere flyttes til Azure og tilbys til brukere gjennom Windows Virtual Desktop.

For andre bedrifter vil Windows Virtual Desktop kunne være verktøyet de trenger for å starte sin reise vekk fra lokale servere. Dette ved at brukerne kan tilbys samme grensesnitt mot sine applikasjoner uavhengig om denne applikasjonen har avhengigheter mot lokale servere eller om den kjøres helt og holdent i Azure.

Har man allerede gått over til Microsoft 365 er man også allerede lisensiert for Windows Virtual Desktop. Kostnadene for Windows Virtual Desktop begrenser seg da til forbruk i Azure og det kan man skalere opp og ned og ut og inn, slik man selv ønsker eller trenger.

Publisert:

Vi hjelper gjerne til med å finne den beste løsningen for din bedrift

Ta kontakt med oss for en uforpliktende prat!