Home
Microsoft Teams Deployment og vedligehold
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
Set-Outlooksignatures bare nemt :-)
Det meste af de sidste 10 år har jeg professionelt arbejdet med emails og der er efterhånden 20 år siden jeg lave min første Qmail mail installation.
Et af de ekstra opgaver i den forbindelse som jeg er løbet ind i, er brugernes sigantur i Outlook, for det er ikke altid ligemeget, hvordan disse ser ud, og der kan for nogle virksomheder endvidere være Compliance krav til disse.
I sommers så jeg et linkedin opslag fra en Markus Gruber, som havde gang i et projekt der består af en powershell script som hedder Set-Outlooksignatures, det så spændene ud og jeg fik også hentet den ned, men det fejlede bigtime i mit setup, henover efteråret kom der nye features til projektet, herunder understøttelse af Exchange Online via GRAPH, hvilket betød at jeg ville give det et "ekstra skud", hvor manualen blev læst lidt grundigere først.
I første omgang virkede det faktisk ikke, jeg fik selv debuggede mig fremtil at det var nogle LDAP queries som fejlede i mit Lab setup, jeg tillod mig at skrive til Markus, som svarrede og vi begynde at debugge I powershell scriptet.
Hen over de sidste 2 uger har der været sendt logfiler og nye versioner af powershell scriptet frem og tilbage, og nu understøtter hans projekt mit lab setup i forbindelse med version 2.4.0
Hvad er så mit lab setup ?
Jo en række virtuelle server, der dækker rollerne som Onprem AD, en AAD Connect server som også har rollen som Modern Hybrid exchange samt en onprem Exchange server.
Dvs. min outlook klient forbinder direkte til exchange online og den onprem exchange server benyttes kun til "management" af remote mailboxes, hvilket er et setup, jeg finder en del mindre virksomheder som leve i.
Et par note iforbindelse med opsætning af Set-outlooksignatures imod exchange online
1) Man have graph understøttelse ellers kan den ikke sætte siganaturen i owa, man kan vælge at blot køre den i mod onprem ad og man kan få nogle fine signature i outlook, dog ikke i owa.
Markus har lavet en fin dokumentation af hvordan denne APP register i azuread skal opsættes og det er heldigvis ikke voldsomme rettigheder appen skal have, da alle er af typen Delegated, med der skal forsat gives admin Consent for et par af dem.
Authentication skal opsættes til http://localhost samt Allow Public Client flows, sættes til yes.
Er man søde ved brugerne hopper man efterfølgende over i Enterprise applications og finder appen igen for at under Permissions at giver en Grand admin consent der også, så slipper brugerne for en "browser popup", hvor de skal give adgang.
Derefter skal Application (client) ID som findes i app-registeren erstattes i "default graph config.ps1" variablen $GraphClientID
Filen findes i mappen "config"
2) lave outlook signature templates
Næste opgave er at tilrette de templates som kommer med scriptet i mappen Templates\Signatures DOCX hvilket er mega nemt, for det er word filer som fungere som templates, det er nærmest blot åben og ret, dvs. det vil alm. kontor personale kunne varetage dette efter en kort indkørring i variablerne.
Skal man virkelig lave flotte signature som står skarp på alle pladforme, vil jeg dog anbefale man i stedet ændre set-outlooksignatures til at benytte de "html" templates den også undersøtter og koder det i html, men word versionen er nok til mig for nu.
3) Test
Herefter skal scriptet blot køres i alm. bruger kontext (Set-OutlookSignatures.ps1'-graphonly $true ), og 3,2,1 der er Signatur i Outlook samt exchange online owa, det er da bare nemt :-)
Eksemple på en hurtig tilrette version, hvor langt de fleste felter kommer fra aad data
4) Deployment til brugerne
Personlig ønsker jeg ikke at auto opdater signaturen i mit miljø, for man kan kunne godt ligge den ind i en form for auto kørsel.
Jeg har i stedet pakken den ind via PSAppDeployToolkit, sådan jeg kan sende den ud på alle de lokale computer, og har i forbindelse med deployment lavet en genvej i start menuen til Set-Outlooksignatures.ps1
Powershellen i min Deployment-applications.ps1 består af 4 dele
a) Oprettelse af mappe i File strukture.
$InstallDestinationFolder = $env:programfiles + "\Set-OutlookSignatures"
if(Test-Path $InstallDestinationFolder)
{
## installtions mappe findes
Remove-Item $InstallDestinationFolder -Recurse -Force
new-Item -Path $InstallDestinationFolder -ItemType Directory -Force
}
else
{
New-Item -Path $InstallDestinationFolder -ItemType Directory
}
b) Kopiering af filer fra installations mappen og ind i file strukturen
Copy-Item -LiteralPath "$($dirfiles)" -Destination $InstallDestinationFolder -Recurse
c )Oprettelse af en genvej til startmenuen. ( eksemple på oprettelse af genvej ligger med i set-outlooksignatures zip filen, ligeledes understøttende grafik.)
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut((Join-Path -Path $([System.Environment]::GetFolderPath([System.Environment+SpecialFolder]::CommonStartMenu)) -ChildPath 'Set Outlook signatures.lnk'))
$Shortcut.WorkingDirectory = $InstallDestinationFolder
$Shortcut.TargetPath = 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe'
$Shortcut.Arguments = "-Command ""& '$($InstallDestinationFolder)\files\Set-OutlookSignatures.ps1' -graphonly $true """
$Shortcut.IconLocation = "$($InstallDestinationFolder)\files\logo\Set-OutlookSignatures Icon.ico"
$Shortcut.Description = 'Set Outlook signatures using Set-OutlookSignatures.ps1'
$Shortcut.WindowStyle = 1 # 1 = undefined, 3 = maximized, 7 = minimized
$Shortcut.Hotkey = ''
$Shortcut.Save()
d )Sync af nye templates ud på klienten, i tilfælde af at det var kommet ekstra til efterfølgende.
## sync ekstra / nye templates ned
$TemplateServer = "\\fileserver"
$TemplateShare="\Set-OutlookSignatures"
if(Test-Path "$($TemplateServer)$($TemplateShare)")
{
$tempatesFolders = Get-ChildItem "$($InstallDestinationFolder)\files\templates"
foreach($templateType in $tempatesFolders)
{
# $templateType.FullName
# "$($TemplateServer)$($TemplateShare)\$templateType"
if("$($TemplateServer)$($TemplateShare)\$templateType")
{
Copy-Item "$($TemplateServer)$($TemplateShare)\$templateType" $templateType.FullName -Recurse
}
}
}
Efter færdig deployement man man nu søge "set outlook signatures frem i start menu'en på windows og få opbygget en standard signatur udfra sine data i AD