Hvordan man vælger en Windows-applikationsudgivelsessoftware

Introduktion

Windows-applikationer understøtter stadig essentielle forretningsprocesser, fra regnskab og virksomhedens ressourcestyring til sundhedspleje, fremstilling og skræddersyede forretningssystemer. Dog bliver det vanskeligt at installere og vedligeholde disse applikationer på hver endpoint, når brugerne arbejder eksternt, bruger forskellige operativsystemer eller forbinder fra ikke-administrerede enheder.

Windows applikationspubliseringssoftware tilbyder et praktisk alternativ. Applikationen kører på en centraliseret Windows-infrastruktur, mens autoriserede brugere interagerer med dens grænseflade gennem en browser, skrivebordsgenvej eller remote access-klient. Denne tilgang kan udvide adgangen til eksisterende software uden at kræve en fuldstændig web-omskrivning eller et fuldt virtuelt skrivebord for hver bruger.

Hvad er software til publicering af Windows-applikationer?

Windows applikationsudgivelsessoftware gør programmer, der er installeret på en central Windows-server eller virtuel maskine, tilgængelige for fjernbrugere. I stedet for at installere og vedligeholde applikationen og dens afhængigheder på hver enhed, administrerer administratorer dem på en eller flere centrale værter.

Platformen kontrollerer, hvilke brugere der kan starte hver applikation, hvordan de autentificerer sig, hvordan deres sessioner er sikret, og hvilke lokale ressourcer de kan bruge. Mens programmet kører på Windows-værten, viser endpointet sin grænseflade og sender tastatur-, mus- og andre tilladte input tilbage til serveren.

Microsoft Learn forklarer, at Remote Desktop Services centralt kan levere enten komplette skriveborde eller individuelle RemoteApp-programmer til autoriserede brugere.

I modsætning til downloaded software kører en offentliggjort applikation ikke fuldt ud på endpointet. Brugeren interagerer med en fjerninstans, der er hostet på den centrale Windows-infrastruktur.

Hvad betyder det at offentliggøre en Windows-applikation?

At publicere en Windows-applikation betyder at gøre den tilgængelig på afstand for udvalgte brugere uden nødvendigvis at give dem adgang til en komplet Windows-desktop.

En typisk proces inkluderer fem faser:

• Installer applikationen på en Windows-server eller virtuel maskine
• Registrer dens eksekverbare fil i publiceringsplatformen
• Tildel adgang til brugere eller grupper
• Godkend brugere gennem en portal, klient eller identitetsudbyder
• Start en fjernsession og vis applikationens grænseflade

Brugere kan kun se det regnskabsprogram, kundeplejeprogram eller proprietære værktøj, de har brug for, mens skrivebordet, serverens filsystem og urelaterede applikationer forbliver skjulte.

Hvordan fungerer offentliggørelse af Windows-applikationer?

De fleste Windows-applikationsudgivelsesmiljøer er afhængige af de samme kerne-lag, selvom terminologien og implementeringen kan variere mellem produkter.

Windows applikationsværter

Applikationen kører på en fysisk server, virtuel maskine eller cloud-hosted Windows-instans. Flere brugere kan dele en session vært gennem separate Windows-sessioner, mens platforme, der kræver stærkere isolation, kan tildele dedikerede eller poolede virtuelle maskiner.

Hver vært skal inkludere den korrekte Windows-version, applikationsfiler, rammer, databaseforbindelse, profiler, skrifttyper, drivere og andre afhængigheder. Applikationskompatibilitet afhænger derfor af den komplette værtkonfiguration snarere end applikationen alene.

Publicering og adgangskontrol

Publiceringstjenesten bestemmer, hvilke programmer brugerne kan starte, og hvordan disse programmer vises på deres enheder. Administratorer kan publicere en enkelt applikation, flere applikationer, en tilpasset launcher eller et komplet skrivebord, med forskellige versioner eller startparametre tildelt specifikke grupper, hvor det er nødvendigt.

Godkendelse bekræfter brugerens identitet, mens autorisation bestemmer, hvilke applikationer og ressourcer den bruger kan få adgang til. En passende platform bør give granulære tildelinger for individuelle brugere, grupper, roller eller lejere.

Sikker Forbindelseslag

En gateway eller webportal formidler forbindelser mellem brugerendepunkter og applikationsværter. Eksterne implementeringer bør ikke udsætte en ubeskyttet Remote Desktop Protocol-tjeneste direkte for internettet, så organisationer bør bruge HTTPS, gyldige Transport Layer Security-certifikater, multifaktorautentifikation, adgangsbegrænsninger og overvågning.

Brug af udklipsholder, udskrivning, lokal drevkortlægning og filoverførsel kan forbedre brugervenligheden, men organisationer bør kun aktivere disse funktioner, når arbejdsgangen kræver det.

Brugertilgangsmetoder

Brugere kan oprette forbindelse gennem en HTML5 portal, native desktop klient RDP-kompatibel klient, forbindelsesfil eller genvej. Browseradgang kan reducere implementeringsarbejdet, mens native klienter muligvis giver mere fuldstændig support til flere skærme, printere, smartkort og andre lokale enheder.

Windows Applikationspublisering vs. Remote Desktop

Applikationsudgivelse og fjernskrivebordsadgang er afhængige af relaterede teknologier, men de tilbyder forskellige niveauer af adgang og forskellige brugeroplevelser.

En fuld fjernskrivebord præsenterer et bredere Windows-arbejdsområde, der kan inkludere skrivebordet, Start-menuen, proceslinjen, filhåndteringsværktøjer og alle tilladte applikationer. En offentliggjort applikation eksponerer kun udvalgte programmer, ofte i individuelle vinduer, som brugerne kan åbne sammen med applikationer, der kører lokalt.

Overvejelse	Offentliggjort applikation	Fuld fjernskrivebord
Brugeroplevelse	En eller flere tildelte applikationer	Fuldstændig Windows arbejdsplads
Typisk formål	Fokuseret adgang til forretningssoftware	Generelt fjernarbejdsmiljø
Administrativt omfang	Applikationsbaseret tildeling	Desktop-niveau adgang og politik
Ressourceeksponering	Smalere	Bredere
Bedst egnet til	Entreprenører, kunder, brancheapplikationer	Medarbejdere, der har brug for flere værktøjer

Applikationspublisering er normalt at foretrække, når brugerne har brug for adgang til et defineret sæt af programmer. Et fuldt fjernskrivebord er mere passende, når de har brug for filhåndtering, flere værktøjer eller et komplet Windows-miljø, selvom nogle organisationer bruger begge modeller til forskellige brugergrupper.

Windows Applikationspublisering vs. VDI

Virtuel desktop infrastruktur (VDI) giver brugerne adgang til Windows-skriveborde, der kører i virtuelle maskiner. Afhængigt af implementeringen kan disse skriveborde være personlige, delte, vedholdende eller ikke-vedholdende.

Session-baseret applikationspublisering kan understøtte flere brugere på delt Windows-infrastruktur, ofte med højere tæthed og lavere administrationsomkostninger. VDI giver stærkere isolering på niveau med virtuelle maskiner og kan bedre understøtte arbejdsbelastninger, der har brug for dedikerede operativsystemkonfigurationer, grafiske ressourcer eller administrativ kontrol.

Overvejelse	Sessionsbaseret publicering	VDI
Leveringsenhed	Individuel applikation eller delt skrivebord	Fuldstændig virtuel maskine
Isolation	Sessionsniveau	Virtuel maskinniveau
Infrastrukturens tæthed	Normalt højere	Normalt lavere
Personalisering	Moderat	Potentielt omfattende
Typisk brug	Almindelige forretningsapplikationer	Specialiserede eller isolerede skriveborde

VDI forbliver værdifuld, når applikationer ikke kan sameksistere på en delt vært, eller når brugere har brug for dedikerede ressourcer. Dog kan det være overdrevet at levere en komplet virtuel desktop, når brugere kun har brug for en eller to Windows-applikationer.

Gør applikationspublisering en Windows-app til en webapp?

Applikationspublisering kan gøre et Windows-program tilgængeligt gennem en browser, men det konverterer ikke programmet til en native webapplikation. Den oprindelige kode fortsætter med at køre på Windows-infrastruktur, og den underliggende arkitektur bliver ikke automatisk cloud-native.

Browseradgang giver ikke applikationen responsiv webdesign, browser-native offline-funktioner, mikroservices eller applikationsprogrammeringsgrænseflader. Applikationspublisering forstås derfor bedre som modernisering af applikationslevering snarere end modernisering af selve kildekoden.

Hvad ændrer sig for brugeren?

Fra brugerens perspektiv bliver applikationen lettere at få adgang til, fordi den kan åbnes gennem en browser eller et fjernadgangsportal uden en fuld lokal installation. Brugerne undgår også at installere applikationens rammer og afhængigheder på deres egne enheder.

Grænsefladen kan vises i en browsertab eller et separat applikationsvindue, men dens reaktivitet afhænger stadig af applikationsværten, netværkskvaliteten og den fjerndisplayprotokol.

Hvad forbliver uændret?

Applikationen bevarer sin oprindelige Windows-kode, grænseflade og tekniske afhængigheder. Registreringsindstillinger, databaser, tjenester, printere og filstier skal derfor fortsætte med at fungere korrekt på Windows-værten.

Applikationsudgivelse fjerner ikke kompatibilitets- eller licenskrav. IT-teams skal stadig teste softwaren i samtidige sessioner og bekræfte, at dens tilsigtede fjern- eller hostede brug er tilladt.

Hvornår er publicering bedre end omskrivning?

Publicering kan være praktisk, når en etableret Windows-applikation forbliver pålidelig, men ville være vanskelig eller dyr at genopbygge. Organisationer kan udvide fjern- og browseradgang uden at acceptere omkostningerne og risikoen ved et øjeblikkeligt udskiftningsprojekt.

En native web-omskrivning kan være mere passende, når virksomheden har brug for responsiv design, offline brug, moderne integrationer eller cloud-native skalerbarhed. Publicering kan også give en mellem løsning, mens organisationen udvikler en langsigtet moderniseringsstrategi.

Hvornår skal du offentliggøre Windows-applikationer?

Applikationspublisering er mest effektiv, når lokal installation, softwareomskrivning eller fuld desktopvirtualisering ville skabe unødvendige omkostninger eller driftskompleksitet.

Web-aktivering af ældre Windows-applikationer

Legacy-applikationer kan være afhængige af Windows-specifikke grænseflader, ældre runtime-miljøer, registreringsindstillinger, kortlagte drev, lokale database-drivere eller specialiserede udskrivningsprocesser. Publicering holder disse applikationer på kompatibel Windows-infrastruktur, mens gøre dem tilgængelige gennem en browser eller fjernklient .

Denne tilgang kan forlænge den nyttige levetid for eksisterende software og give organisationen tid til at planlægge et kontrolleret moderniseringsprojekt. Kompatibilitetstestning er fortsat nødvendig for applikationer, der forventer en enkelt bruger, kræver forhøjede rettigheder eller er afhængige af lokalt hardware.

Centraliser forretningssoftware

IT-teams kan vedligeholde applikationer og deres afhængigheder på centrale værter i stedet for at administrere dem separat på hver arbejdsstation. De kan teste opdateringer i et kontrolleret miljø, før de gør den opdaterede applikation tilgængelig for brugerne.

Denne leveringsmodel passer ofte til virksomheders ressourcestyringssystemer, finansapplikationer, lagerstyringsværktøjer, medicinsk praksissoftware, juridiske sagsbehandlingsplatforme og tilpassede databaser.

Support af BYOD og blandede enheder

Browser-baseret publicering kan give brugere på macOS, Linux, Chromebooks, tablets eller personlige computere adgang til en Windows-applikation uden at flytte applikationen selv til disse enheder. IT-teams skal stadig definere, hvilke data brugerne har tilladelse til at kopiere, udskrive, uploade eller downloade fra ikke-administrerede enheder.

Giv kontrolleret adgang til entreprenører

Entreprenører og partnere kan have brug for adgang til én forretningsapplikation uden at kræve en virksomhedslaptop eller bred adgang til det interne netværk. At offentliggøre kun det nødvendige program kan forenkle onboarding, samtidig med at det understøtter multifaktorautentifikation, begrænsede konti og tildelinger med mindst privilegier.

Platforme som TSplus Remote Access kan kun offentliggøre de applikationer, som entreprenørerne har brug for, uden at afsløre en komplet Windows-desktop.

Lever eksisterende software som en hosted service

Uafhængige softwareleverandører (ISV'er) kan bruge applikationspublisering til at give kunderne online adgang til et eksisterende Windows-produkt. Denne tilgang kan fremskynde hostinglevering, men ISV'en forbliver ansvarlig for lejerisolering, kundens identitet, service tilgængelighed, databeskyttelse og licensering.

Hvad skal ISV'er vurdere?

En ISV-implementering skal understøtte gentagelig onboarding og administration på tværs af separate kundeorganisationer, samtidig med at hver kundes data, konfiguration og aktive sessioner beskyttes.

Lejeisolation kan være afhængig af separate databaser, brugerkonti, applikationspuljer, lagringssteder, netværk eller servere. Det passende design afhænger af applikationsarkitekturen, da publiceringssoftware ikke automatisk kan gøre en usikker enkeltlejerapplikation sikker til brug for flere lejere.

ISV'er bør også evaluere identitetsfederation, multifaktorautentifikation, kundeadministratorroller, portalbranding, automatisering og brugsrapportering. Manuel konfiguration kan være håndterbar under en pilot, men det kan blive ineffektivt, når tjenesten understøtter hundreder af brugere eller lejere.

Licensering kræver også omhyggelig gennemgang, fordi Windows, databaser, runtime-miljøer, publiceringsplatformen og ISV'ens eget produkt hver især kan pålægge betingelser for multi-brugeradgang eller hosting af tjenesteudbydere.

Fordele og begrænsninger ved publicering af Windows-applikationer

Applikationspublisering centraliserer applikationer og opdateringer, reducerer lokalt installationsarbejde og gør Windows-software tilgængelig fra et bredere udvalg af enheder. At holde applikationsbehandling og forretningsdata på administreret infrastruktur kan også reducere mængden af information, der opbevares på ikke-administrerede endpoints.

Når brugerne kun har brug for udvalgte applikationer, kan denne model give et snævrere alternativ til virtuel desktop-infrastruktur. Centralisering gør dog også applikationsværter, gateway og privilegerede konti til særligt vigtige sikkerhedsaktiver.

Applikationskompatibilitet forbliver en betydelig begrænsning. Programmer, der bruger maskinbrede indstillinger, afhænger af lokal hardware eller er afhængige af tjenester designet til en enkelt interaktiv bruger, fungerer muligvis ikke korrekt i delte sessioner, mens grafikintensive og latensfølsomme arbejdsbelastninger muligvis præsterer dårligt over fjernforbindelser.

Printning, scanning, smartkort og andre perifere enheder skal testes med de nøjagtige slutpunkter og adgangsklienter, som brugerne vil have i produktion. Serverkapacitet bør også baseres på målte CPU-, hukommelses-, lager- og samtidighedskrav snarere end generelle leverandørmaksimum.

Hvordan kan du vælge en software til publicering af Windows-applikationer?

En nyttig evaluering begynder med applikationen, brugerne og den tilsigtede driftsmodel snarere end med en sammenligning af produktfunktioner.

Bekræft applikationskompatibilitet

Dokumenter de understøttede Windows-versioner, rammer, tjenester, registreringsdatabasedependenser, databaser, filshares, printere, startparametre og licensbegrænsninger. Test den faktiske applikation i den tilsigtede multi-bruger- eller virtuel maskinemodel, herunder samtidige sessioner, brugerprofiler, opdateringer og genoprettelsesprocesser.

Sammenlign brugeradgang og oplevelse

Vurder browserunderstøttelse, native klienter, genveje, RemoteApp-lignende vinduer, flere skærme, session genforbindelse og mobiladgang. Testen bør dække vigtige arbejdsgange såsom udskrivning, filadgang, brug af udklipsholder og lokal enhedsomdirigering.

Når brugere kun har brug for simpel adgang, kan en fokuseret browsersession være lettere at sikre og supportere end en klient med omfattende lokal integration.

Undersøg identitets- og sikkerhedskontroller

Se efter bruger- og gruppeopgaver, katalogintegration, multifaktorautentifikation, kontosikkerhed, sessionstimeoutpolitikker og reviderbare begivenheder. Ekstern trafik bør bruge HTTPS og gyldige certifikater, mens CISA anbefaler at begrænse brugen af Remote Desktop Protocol og undgå eksponerede, dårligt sikrede fjernskrivebordsservices.

Sikkerhedsevalueringen bør også omfatte værtspatching, rolleadskillelse, logning, sikkerhedskopiering, overvågning og begrænsninger på brugen af udklipsholder, drevkortlægning, udskrivning og filoverførsel.

Vurdering af administration og automatisering

Test regelmæssige administrative opgaver såsom at offentliggøre en applikation, tildele den til en gruppe, tilbagekalde adgang, gennemgå aktive sessioner, opdatere branding og sikkerhedskopiere konfigurationen. Større implementeringer bør også vurdere applikationsprogrammeringsgrænseflader, kommandolinjeværktøjer, provisioning-skabeloner og overvågningsintegrationer.

Plan for skala og modstandsdygtighed

Overvej hvordan miljøet vil understøtte flere værter, belastningsbalancering, forbindelsesformidling, gateway redundans, profilopbevaring og genopretning. Mål repræsentativ CPU-, hukommelses-, lager- og netværksbrug, og oprethold derefter tilstrækkelig ekstra kapacitet til vækst, vedligeholdelsesperioder og værtsfejl.

Sammenlign implementering og samlede omkostninger

Platformen kan køre lokalt, i et privat datacenter, på offentlige cloud-virtuelle maskiner eller gennem en hostingudbyder. Udrulningsstedet bør afspejle applikationens afhængigheder, krav til datalagring, latenstid, interne færdigheder og omkostningsbegrænsninger.

Den samlede omkostning bør tage højde for platform, Windows, applikation og database licensering, samt infrastruktur, backup, overvågning, sikkerhed, implementering, administration, support og høj tilgængelighed.

Gennemgå leverandørsupport og produktmodenhed

Gennemgå understøttede Windows-versioner, udgivelseshistorik, dokumentation, sikkerhedsopdateringspraksis, supportkanaler, prøveindstillinger og migrationsressourcer. ISV'er bør også bekræfte, at leverandøren understøtter kundevendte implementeringer og tillader den tilsigtede hostingmodel.

En praktisk proof-of-concept plan

Et proof of concept bør teste den komplette brugerrejse i stedet for kun at bekræfte, at en applikation åbner.

1. Vælg en repræsentativ applikation og opret en dokumenteret testvært.
2. Publicer det til en kontrolleret pilotgruppe.
3. Konfigurer HTTPS, gyldige certifikater, multifaktorautentifikation og restriktiv adgang.
4. Test den aktuelle blanding af endpoints, browsere og native klienter.
5. Valider lancering, genforbindelse, profiler, udskrivning, filadgang og nødvendige perifere enheder.
6. Mål værtens ressourcer under realistisk samtidig aktivitet.
7. Gennemgang af logning, adgangs tilbagekaldelse, backup, opdateringer og genopretning.
8. Udvid gradvist fra tekniske testere til en begrænset produktionsgruppe.

Piloten bør udarbejde klare acceptkriterier og en tilbageføringsplan. Den bør også vise, om browseradgang er tilstrækkelig, eller om nogle brugere har brug for en native klient.

Almindelige fejl ved publicering af Windows-applikationer

At vælge en platform før testning af applikationen kan skjule kompatibilitetsproblemer, mens antagelsen om, at browseradgang giver indfødt webydelse, kan skabe urealistiske forventninger til latenstid og responsivitet.

At størrelsen af miljøet fra leverandørens maksimale grænser er lige så risikabelt, fordi serverdensiteten varierer afhængigt af applikationen og arbejdsbyrden. Organisationer skal også gennemgå hvert licenslag, før de aktiverer multi-bruger eller hostet adgang.

Springer Real Application Testing

En funktionsliste kan ikke bekræfte, om en applikation vil opføre sig korrekt i samtidige sessioner. Problemer kan kun opstå, når flere brugere får adgang til de samme filer, registreringsindstillinger, tjenester eller lokale ressourcer på samme tid.

IT-teams bør teste repræsentative arbejdsgange, brugerprofiler, opdateringer og periferiudstyr, før de vælger en platform. Beviset for konceptet bør genskabe det tilsigtede produktionsmiljø så tæt som muligt.

Undervurdering af sikkerheds- og licenskrav

At åbne Remote Desktop Protocol direkte til internettet eller aktivere hver omdirigeringsfunktion som standard kan øge risikoen. Adgang til udklipsholder, drevkortlægning, udskrivning og filoverførsel bør forblive begrænset til klart definerede forretningsbehov.

Licensering fortjener også nærmere opmærksomhed, fordi Windows, databaser, runtime-miljøer, tredjeparts komponenter og selve applikationen kan stille separate krav til multi-brugeradgang eller hostet levering.

Behandling af ekstern levering som en intern implementering

En intern implementering betjener generelt brugere fra én organisation, mens en ekstern tjeneste kan understøtte flere urelaterede kunder. Ekstern levering introducerer derfor yderligere krav til lejerisolering, privatliv, tilgængelighed, support og adgangsstyring.

Uafhængige softwareleverandører har også brug for gentagelige onboarding-, overvågnings- og genoprettelsesprocesser. En konfiguration, der fungerer for et lille internt team, kan muligvis ikke skaleres sikkert eller effektivt som en kundevendt service.

Hvordan er TSplus en praktisk løsning til publicering af Windows-applikationer?

TSplus Remote Access publicerer Windows-applikationer og -desktops fra eksisterende Windows-infrastruktur. Administratorer kan tildele applikationer til individuelle brugere eller grupper og give adgang gennem RemoteApp-lignende forbindelser, RDP-kompatible klienter eller en tilpasselig HTML5-webportal.

Denne model kan være velegnet til små og mellemstore organisationer, der har brug for centraliseret applikationslevering uden at skulle drive en mere kompleks virtuel desktop-løsning. Den kan også hjælpe ISV'er med at give remote access til etableret Windows-software, samtidig med at de bevarer kontrollen over hosting og kundeoplevelsen.

IT-teams bør stadig validere kompatibilitet, licensering, sikkerhed, brugeroplevelse, serverkapacitet, backup og gendannelse gennem et realistisk pilotprojekt, før de flytter implementeringen til produktion.

Konklusion

Windows applikationspubliseringssoftware kan udvide adgangen til forretningskritiske programmer uden at kræve lokal installation, øjeblikkelig kildekodemodernisering eller et fuldt virtuelt skrivebord for hver bruger. Dens værdi er stærkest, når applikationer er kompatible med centraliseret udførelse, og brugere har brug for fokuseret, kontrolleret adgang.

Den endelige beslutning bør baseres på praktisk testning snarere end kun funktionslister. Ved at validere kompatibilitet, sikkerhed, licensering, ydeevne, administration og modstandsdygtighed sammen kan IT-teams og ISV'er vælge en applikationsudgivelsesplatform, der forbliver håndterbar, efterhånden som brugen vokser.