Microsoft nye guldæg MS Teams, er på mange måde et fantasktisk produkt til at give slut brugeren en applikation til at benytte alle mulighederne i deres O365 licens, samtidig er det lidt af en "management" problem barn.
Her er lidt om de ting jeg har oplevet i forbindelse med arbejde med teams klienten de sidste par år.
Som altid er det aldrig første deployment af en applikation som giver udfordringerne, men ved teams skal man være klar på at selv om applikationen er selv opdaterende kan man komme i situationer, hvor man skal hjælpe teams på vej.
Der er i min optik 3 veje at gå.
- Brugen installer selv teams ned i sin profile på de pc'er som de benytter
- Pro
- Ingen management.
- Softeware kommer kun på enheder som skal benytte det.
- Con
- Bruger skal selv finde og installer
- Giver en åbning for brugen snydes til at teams fra ekstern side, hvor der er lagt malware med i installationen.
- Ved sikkerhed opdatering, skal man anyway ud og opdater klienten
- Bruger skal selv finde og installer
- Pro
- Admin installer Teams Wide installer pakken på enhederne
- Pro
- Central styrring
- Auto-intallation i nye bruger profiler
- Styrring af versioner
- nemmere at omgå, nogle af de udfordringer teams er indbygge i når man snakker vdi.
- Con
- der at lave 2 -4 pakker årligt for at sikre at auto-installationen virker og man ikke er kommet bagud
- Pro
- Admin laver deres egen Teams installer automatik.
- Pro
- man kan lave det man har behov for
- høj mulighed for at tilpasse den verden man ligger i
- Con
- Lidt eller ingen M$ support
- meget test arbejde
- Pro
Personlige har jeg primært arbejdet med brug af Teams wide installer pakken, men før denne fandes har jeg også levet en hjemmebrygget koncept.
lidt noter angående Teams wide installer pakken.
For en x64 maskine betyder at at der oprettes en mappe under C:\Program Files (x86)\Teams Installer, hvor i der lander en Teams.exe samt en setup.json file.
Ligeledes laves der en entry i LocalMachine RUN key : Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run
Hvergang en bruger logger ind bliver denne key kørt, dvs. har brugen ingen teams installeret, vil denne key sikre at teams installeres ind i bruger appdata local mappe.
OBS. har man kørt opdatering til windows 10 1909 eller de windows versioner deromkring via windows update, er det flere gang set at denne RUN nøgle forsvinder efter windows opdateringen, hvorved at den automatiske teams installation stopper med at virke :-(
selve "%ProgramFiles%\Teams Installer\Teams.exe --checkInstall --source=default" vil være andersledes såfremt at teams wide installaller klienten er installleret ud på maskinerne sammen med Office365 AFE, i så tilfælde vil den hedde: "%ProgramFiles%\Teams Installer\Teams.exe --checkInstall --source=PROPLUS", men det er blot alm wide installater pakke som er kørt på maskinen, og denne pakke opdaters IKKE når windows update opdatere version af Office AFE, dvs. man kan godt starte med at levere office AFE, men man slipper ikke for at senere at skulle opdatere Teams wide installer pakken ude på maskinerne, hvis de lever flere år uden reinstallation, hvilket windows 10 heldigvis er meget bedre til end, f.eks windows 7 og endnu værre windows xp.
Teams selvupdate sker når teams klienten startes, hvis teams er deployed med autostart i setup.json filen, betyder det at der kommer en entry i Current user Run key. "Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Der kalder path til update.exe i appdata local mappen hvor teams er installeret : C:\Users\lwh\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--system-initiated"
alternativ gør den startdard teams genvej næsten det samme.
Teams og VDI
Selv teams wide installer kan installeres i VDI mode, hvilke kræver nedsteående registry keys, men selve teams klienten har også nogle vdi check når det starter, dvs. at vis følgende registry keys findes på en computer også selv om teams ikke er installeret i vdi mode, vil teams starte i VDImode, hvilke ikke er ønskbar.
- HKLM\Software\Citrix\PortICA
- HKLM\Software\VMware,Inc.\VMware VDM\Agent
I vdimode er der teams features som ikke er tilrådighed, så skal man omgå dette, skal registry keys'ne væk, men der kan være senarier hvor der findes services på maskinen som skal bruge disse, f.eks hvis maskinen, benyttes i VDA sammenhæng når ingen lokale bruger er logget på, dette kan naturligvis omgået ved at keys'ne ikke er tilstede når starter teams, hvilket så kan være en udfordring...
Følgende er ikke supporteret af microsoft, citrix eller vmware, men virker i følge mine tests.
Selve teams klienten starter i brugen kontext, så ved at lave et grimt registry hack, nemlig at Deny Domain users Read adgang til registry nøglerne.
jeg har testet med Critrix, men aldrig med VMware, men som jeg har set det er det Services på maskinen, som benytter "HKLM\Software\Citrix\PortICA", og da det kun er bruger man deny'er rettigheder til denne registry key, vi disse starte og køre helt normalt.
Om teams starter i vdimode kan ses flere steder.
Hvis man finder %appdata%\microsoft\teams\logs.txt filen og søger efter vdimode: vil der være log'entires og når teams klienten er startet sådannes der forskellige nye json filer, herunder storage.json der også har en vdimode som ser udtil at være
Følgende VDImodes har jeg fundet hidtil, men jeg kende ikke helt betydning af alle udover at jeg næsten altid kun ønsker at have vdimode 0.
- VDImode: 0 = vdi mode er ikke tilstede
- VDImode: 2000 = PortICA
- VDImode: 1000 = ????
- VDImode: 1001 = ????
Det eneste sted jeg officielt har set disse vdimode beskrevet er i vmwares dokumentation: Microsoft Teams Optimization with VMware Horizon | VMware
Teams Uninstall:
%LOCALAPPDATA%\Microsoft\Teams\Update.exe –uninstall –msiUninstall –source=default
%LOCALAPPDATA%\Microsoft\Teams\Update.exe –uninstall –source=default