IT-drift

Beskriver hur en IT-avdelning installerar Privera centralt, styr programmet med grupprincip eller Intune och avinstallerar det. Installern och dess växlar gäller version 0.9.0-beta22. Styrningen av uppdateringar (avsnitt 5) och värdet UpdateMode i ADMX-mallen (avsnitt 6) gäller från 0.9.0-beta21. AppLocker-regeln som nekar äldre versioner (avsnitt 4), de signerade tilläggen i installern (avsnitt 2.1), den fullständiga signaturkontrollen av uppdateringar (avsnitt 5) och värdena RequireEventLogForExport och AllowDebugPort (avsnitt 6) gäller från 0.9.0-beta22. Det som inte är provat på en riktig dator eller i ett riktigt utrullningsverktyg står utskrivet, och är samlat i avsnitt 9.

1. Sammanfattning

2. Installation

2.1 Installationsfilen

Installern heter Privera-Setup-<version>.exe och hämtas från privera.se/download/ med en licensnyckel. Samma fil installerar per användare och per dator. Den är signerad av Itha AB. Kontrollera signaturen före utrullning:

Get-AuthenticodeSignature .\Privera-Setup-0.9.0-beta22.exe | Format-List Status, SignerCertificate

Status ska vara Valid och certifikatets subjekt CN=Itha AB, O=Itha AB, L=Södertälje, S=Stockholm, C=SE. Certifikatet kommer från Azure Trusted Signing och byts dagligen. Signaturen har en tidsstämpel och gäller även efter att certifikatet har gått ut. Installern för 0.9.0-beta22 har den binära filversionen 0.9.0.22, liksom Privera.exe (avsnitt 4.1).

Smart App Control. Installern packar upp sina tillägg (bland annat System.dll och nsis7z.dll) i %TEMP% och laddar dem där. Från 0.9.0-beta22 är tilläggen i installern och avinstalleraren signerade av Itha AB, och bygget stoppas om något av dem inte är giltigt signerat. I 0.9.0-beta21 och äldre var de osignerade. På en dator med Smart App Control påslaget stoppades då tillägget, och installern avslutades med kod 0 utan att lägga in några programfiler: ingen Privera.exe, men en genväg på skrivbordet. Det är bekräftat i Windows Sandbox 2026-10-23, som kör med Smart App Control påslaget. Där installerades 0.9.0-beta22 med de signerade tilläggen utan fel, och analys, OCR och export fungerade. Kontrollera efter en utrullning att Privera.exe finns, och inte bara att installern gav kod 0.

2.2 Per användare eller per dator

Rekommendation för en organisation: installera per dator, sätt UpdateMode till 0 och rulla ut nya versioner med samma verktyg som installationen.

Växlarna:

• /S kör installern utan fönster. Skriv stort S.
• /allusers installerar per dator och /currentuser per användare. Utan någon av dem installeras programmet per användare, utom när det redan finns en installation per dator. Då uppgraderas den.
• /D=C:\Annan mapp\Privera väljer en annan programmapp. Växeln ska stå sist och skrivas utan citattecken, även om sökvägen har mellanslag.

Det här gäller också, enligt installerns mall:

• Installern avslutar ett Privera som är igång, utan att fråga. En granskning som inte är sparad går då förlorad. Vid installation per dator gäller det alla användares Privera från samma programmapp, även på en terminalserver. Rulla ut när programmet inte används.
• En ny version installeras ovanpå den gamla: installern tar först bort den tidigare versionen och lägger sedan in den nya. Användarnas data i %APPDATA% rörs inte.
• Installern begär ingen omstart och startar inte programmet efter en tyst installation.
• Installern registrerar inte händelsekällan Privera i Windows händelselogg. Gör det i utrullningen om programmet körs under AppLocker eller WDAC, se avsnitt 2.5 och Säkerhetsloggning avsnitt 7.3.

2.3 Intune (Win32-app)

Packa installern med Microsofts verktyg Win32 Content Prep Tool:

IntuneWinAppUtil.exe -c C:\Paket\Privera -s Privera-Setup-0.9.0-beta22.exe -o C:\Paket\ut

Identifieringsregel:

Nyckelns namn är programmets fasta id och är detsamma i alla versioner. Installern skriver där också DisplayName (Privera och versionen), UninstallString och QuietUninstallString. Nyckeln och värdena är avlästa på en dator med programmet installerat per användare, där samma nyckel ligger under HKEY_CURRENT_USER. Den binära filversionen i Privera.exe är 0.9.0.22 i 0.9.0-beta22 men 0.9.0.0 i alla tidigare betaversioner, så den skiljer inte äldre versioner åt. Identifieringsregeln bygger därför på DisplayVersion.

En ny version läggs ut som en ny Win32-app som ersätter den gamla, eller genom att byta fil och identifieringsregel i den befintliga appen. Den tidigare versionen behöver inte avinstalleras först, eftersom installern uppgraderar på plats.

Per användare: installationsbeteende Användare, kommandot Privera-Setup-0.9.0-beta22.exe /S /currentuser och samma nyckel under HKEY_CURRENT_USER. Programmet hamnar då i användarens profil, med följderna i avsnitt 4.

Inte provat i Intune.

2.4 Configuration Manager

Skapa ett program med distributionstypen Skriptinstallation, samma installations- och avinstallationskommando som för Intune, identifieringsmetoden register (DisplayVersion lika med versionen, under samma nyckel) och installationsbeteendet Installera för system. Inte provat i Configuration Manager.

2.5 Exempel på installationsskript

Ett skript som installerar per dator och registrerar händelsekällan. Körs som SYSTEM, till exempel med installationskommandot powershell.exe -ExecutionPolicy Bypass -File .\installera.ps1:

$p = Start-Process -FilePath "$PSScriptRoot\Privera-Setup-0.9.0-beta22.exe" -ArgumentList '/S', '/allusers' -Wait -PassThru
if ($p.ExitCode -ne 0) { exit $p.ExitCode }
New-EventLog -LogName Application -Source Privera -ErrorAction SilentlyContinue
exit 0

Inte provat.

3. Avinstallation

Kommandona är de som installern själv skriver i QuietUninstallString. Avinstallationen avslutar Privera om det är igång.

Koppla loss licensen först, under Inställningar, Licens, så att den kan användas på en annan dator direkt. Annars får den nya datorn ta över licensen, och en övertagning går högst en gång var 30:e dag.

Kvar efter avinstallationen, för varje Windows-konto som har använt programmet:

Kvar blir också säkerhetsloggen i den katalog som policyn anger, posterna i Windows händelselogg samt exporterade filer och de exportloggar som sparats bredvid dem. Ta inte bort säkerhetsloggen om den behövs för uppföljning.

Så rensas ett konto, som den användaren:

Remove-Item "$env:APPDATA\privera-desktop", "$env:LOCALAPPDATA\privera-desktop-updater", "$env:USERPROFILE\.cache\huggingface\hub\models--KB--bert-base-swedish-cased-ner" -Recurse -Force -ErrorAction SilentlyContinue

4. AppLocker och WDAC

4.1 Signaturerna

Programfiler som Itha AB levererar utan egen signatur signeras av Itha AB med tidsstämpel. Filer som redan har en giltig signatur från sin tillverkare behåller den. I version 0.9.0-beta20 fanns 200 programfiler (.exe, .dll, .pyd, .node): 162 signerade av Itha AB, 25 av Python Software Foundation, 11 av Microsoft och 2 av Intel. Från 0.9.0-beta22 står varje programfil i SBOM:en med SHA-256 och uppgift om den bär en Authenticode-signatur, se SBOM.

AppLocker läser utgivaren som O=ITHA AB, L=SÖDERTÄLJE, S=STOCKHOLM, C=SE. En AppLocker-utgivarregel jämför utgivarens namn, inte certifikatet, och påverkas därför inte av att certifikatet byts dagligen. Så här visar AppLocker programmets exe-filer (Get-AppLockerFileInformation, avläst 2026-10-23):

Äldre versioner kan köra annan kod. Versionerna 0.9.0-beta12 till 0.9.0-beta21 är giltigt signerade av Itha AB, men i deras Privera.exe är Electrons inbyggda spärrar (fuses) inte satta. Med miljövariabeln ELECTRON_RUN_AS_NODE kör den signerade programfilen då godtycklig kod, och NODE_OPTIONS och --inspect ger andra vägar till samma sak. En tillåtande utgivarregel för Itha AB, till exempel den som stod i det här dokumentet före 0.9.0-beta22, släpper in de versionerna och därmed den vägen till egen kod. Lägg därför till den nekande regeln i avsnitt 4.2.

Spärrarna från 0.9.0-beta22. I Privera.exe är körning som Node (RunAsNode), NODE_OPTIONS och --inspect avstängda. Asar-integriteten och OnlyLoadAppFromAsar är påslagna, så programmet startar bara med det app.asar som bygget skrev, och kakor i programmets profil krypteras. Bygget stoppas om någon spärr har ett annat läge än det förväntade. Spärren som ger file: utökade rättigheter (GrantFileProtocolExtraPrivileges) står kvar på, eftersom programfönstret laddas från en fil och inte laddas alls utan den.

Felsökningsporten. Startas kundutgåvan med --remote-debugging-port, --remote-debugging-pipe, --inspect, --inspect-brk eller --inspect-port avslutas den innan något fönster öppnas. Undantaget är när policyn AllowDebugPort är 1 (avsnitt 6). Då loggas händelsen app.felsokningsport_tillaten (1006).

Kvar: installation per användare. Asar-integriteten skyddar bara app.asar. I en installation per användare, i %LOCALAPPDATA%\Programs\Privera, äger användaren programmappen och kan byta ut DLL-filer, filerna i resources\app.asar.unpacked (bland annat .node-filer) och motorn sidecar.exe. Det som stoppar det är AppLocker eller WDAC som också kontrollerar DLL-filer: en utbytt fil som är osignerad eller signerad av någon annan stoppas då. En äldre fil med en giltig signatur från samma utgivare stoppas inte av en utgivarregel. En installation per dator, i C:\Program Files\Privera, är skrivskyddad för vanliga användare.

4.2 AppLocker

AppLockers standardregler låter vanliga användare köra program bara under %WINDIR% och %PROGRAMFILES%. En installation per dator i C:\Program Files\Privera omfattas av dem. En installation per användare hamnar i %LOCALAPPDATA%\Programs\Privera och stoppas, liksom installern om användaren själv kör den. Använd installation per dator, eller lägg till reglerna nedan.

Två regler. Den första tillåter alla programfiler som Itha AB har signerat, oavsett produkt, filnamn och version. Den behövs vid installation per användare och för att motorn och OCR-motorn ska få köras: sidecar.exe och tesseract.exe saknar versionsresurs i 0.9.0-beta22, så AppLocker ser varken produktnamn eller version (O=ITHA AB, L=SÖDERTÄLJE, S=STOCKHOLM, C=SE\\,0.0.0.0), och en regel som kräver produktnamn eller lägsta version stoppar dem. Då fungerar inte Privera.

Den andra regeln nekar Itha AB:s filer med produktnamnet PRIVERA och version till och med 0.9.0.21. Den behövs eftersom 0.9.0-beta12 till 0.9.0-beta21 är giltigt signerade av Itha AB med Electrons spärrar avstängda (avsnitt 4.1), och den första regeln annars släpper in dem. I AppLocker går en nekande regel före en tillåtande. Den nekande regeln stoppar också Privera.exe i en äldre version som redan är installerad per dator under C:\Program Files, trots standardregeln där.

Den nekande regeln stoppar även installer och avinstallerare för 0.9.0-beta21 och äldre, eftersom de har samma produktnamn och versionen 0.9.0.0. En ny version tar bort den gamla med den gamla avinstalleraren. Uppgradera därför till 0.9.0-beta22, eller avinstallera äldre versioner, innan regeln slås på.

Den nekande regeln gäller bara filer med produktnamnet PRIVERA. Motorn, OCR-motorn och elevate.exe i äldre versioner har inget produktnamn eller versionsnummer som skiljer dem från 0.9.0-beta22, och släpps in av den tillåtande regeln.

Reglerna som PowerShell, med S-1-1-0 (Alla) eftersom namnet Everyone inte går att slå upp på en svensk Windows:

$tillat = [guid]::NewGuid()
$neka = [guid]::NewGuid()
@"
<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="NotConfigured">
    <FilePublisherRule Id="$tillat" Name="Privera: signerat av Itha AB" Description="Alla programfiler signerade av Itha AB." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="O=ITHA AB, L=SÖDERTÄLJE, S=STOCKHOLM, C=SE" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
    <FilePublisherRule Id="$neka" Name="Privera: nekas till och med 0.9.0-beta21" Description="Privera.exe, installer och avinstallerare med version till och med 0.9.0.21." UserOrGroupSid="S-1-1-0" Action="Deny">
      <Conditions>
        <FilePublisherCondition PublisherName="O=ITHA AB, L=SÖDERTÄLJE, S=STOCKHOLM, C=SE" ProductName="PRIVERA" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="0.9.0.21" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
</AppLockerPolicy>
"@ | Out-File -Encoding utf8 .\Privera-AppLocker.xml

# Pröva reglerna mot de installerade filerna innan de tillämpas.
$filer = (Get-ChildItem 'C:\Program Files\Privera' -Recurse -Filter *.exe).FullName
Test-AppLockerPolicy -XmlPolicy .\Privera-AppLocker.xml -Path $filer -User $env:USERNAME

# Lägg till reglerna i den lokala policyn. I en domän: importera filen i grupprincipen.
Set-AppLockerPolicy -XmlPolicy .\Privera-AppLocker.xml -Merge

Har organisationen redan en tillåtande regel för Itha AB, till exempel den som stod här före 0.9.0-beta22, räcker det att lägga till den nekande regeln.

Provat 2026-10-23 med Test-AppLockerPolicy och exakt den här policyn: Privera.exe, sidecar.exe och tesseract.exe ur ett signerat provbygge av 0.9.0-beta22, och installern för 0.9.0-beta22 och avinstalleraren i den, tillåts. Privera.exe och installern för 0.9.0-beta21, installern för 0.9.0-beta20 och avinstalleraren från en äldre version nekas av den nekande regeln, och ett program från en annan utgivare nekas eftersom ingen regel tillåter det. Inte provat: programmet under en tillämpad AppLocker-policy.

Använder organisationen AppLockers regler för DLL-filer behöver även filerna från Python Software Foundation, Microsoft och Intel tillåtas, och Itha AB:s egna DLL-filer, som har olika produktnamn och versioner och därför inte kan begränsas på version. Programmet startar Windows PowerShell för händelseloggen och för signaturkontrollen av uppdateringar. Händelseloggen påverkas av Constrained Language Mode, se Säkerhetsloggning avsnitt 7.3. Signaturkontrollen fungerar i Constrained Language Mode. Kan PowerShell inte startas alls, till exempel för att det är spärrat för användarna, installeras inga automatiska uppdateringar (avsnitt 5).

4.3 WDAC (App Control for Business)

Skapa reglerna från en dator där programmet är installerat per dator:

New-CIPolicy -FilePath .\Privera-WDAC.xml -ScanPath 'C:\Program Files\Privera' -Level Publisher -Fallback Hash -UserPEs -MultiplePolicyFormat

Mot programfilerna i 0.9.0-beta20 gav kommandot signerregler för Itha AB, Python Software Foundation, Microsoft och Intel. Regeln för Itha AB binder till Microsofts mellancertifikat Microsoft ID Verified Code Signing PCA 2021 och namnet Itha AB, inte till det dagliga certifikatet, och bör därför hålla när certifikatet byts. Den godtar varje certifikat från samma mellancertifikat med namnet Itha AB. För en snävare regel kan signeraren dessutom bindas till signeringsprofilens egen EKU, som är densamma i alla Priveras certifikat: 1.3.6.1.4.1.311.97.811471209.363444190.628451136.88475081. Microsoft beskriver det i dokumentationen för Trusted Signing (Artifact Signing).

En signerregel på nivån Publisher godtar alla versioner, också 0.9.0-beta12 till 0.9.0-beta21, där den signerade programfilen kan köra annan kod (avsnitt 4.1). Nivån FilePublisher binder regeln dessutom till filens namnuppgift och en lägsta filversion. Hur en sådan regel bör se ut för Privera, där Privera.exe saknar originalfilnamn, har vi inte provat. Inte provat under en tillämpad WDAC-policy.

5. Styrning av uppdateringar

Från version 0.9.0-beta21. Värdet UpdateMode (REG_DWORD) under HKLM\Software\Policies\Privera:

reg add HKLM\Software\Policies\Privera /v UpdateMode /t REG_DWORD /d 0 /f

• Saknas värdet gäller 2. Policyn går före allt i programmet. Det finns ingen inställning där användaren kan ändra läget.
• Ett värde som inte går att tolka, av fel typ eller ett annat tal, ger 0 och räknas i säkerhetsloggens startpost som ogiltiga_policyvarden. Går registret inte att läsa vid start (tidsgräns fem sekunder) görs ingen kontroll den starten. Ett fel öppnar alltså aldrig för automatisk installation.
• Läget står i varje startpost i säkerhetsloggen: app.start, fältet uppdateringar (automatisk, kontrollera eller av).
• Användaren ser läget under Inställningar, Om Privera. När organisationen har satt policyn står det att uppdateringarna styrs av organisationen.
• Policyn läses vid start. En ändring gäller från nästa start.
• Oberoende av policyn görs ingen kontroll utan licensnyckel och ingen i avvecklingsläget.
• Versioner före 0.9.0-beta21 bortser från värdet och uppdaterar automatiskt.

Äkthetskontrollen (från 0.9.0-beta22). Innan en hämtad uppdatering installeras kontrollerar programmet den med Windows PowerShell. Godkänt är bara att Authenticode-signaturen har status Valid, att den gäller den hämtade filen och att utgivarens namn har alla delarna CN=Itha AB, O=Itha AB, L=Södertälje, S=Stockholm, C=SE med exakt de värdena. Därefter ska filens versionsuppgift vara den version som uppdateringsmanifestet angav, så att en äldre installer med giltig signatur inte kan installeras som en nyare. En fil vars versionsuppgift saknas, inte går att läsa eller bara är nollor avvisas. Paket för webbinstallation godtas inte. PowerShell startas med full sökväg i Windows-katalogen och med en egen, minimal miljö. Allt som inte är ett uttryckligt godkännande är ett nej: uppdateringen installeras inte, och nejet loggas som uppdatering.signatur_nekad (5003). Kontrollen är provad mot den signerade installern för 0.9.0-beta21, som godkändes med rätt utgivare och fälldes med ett annat utgivarnamn, efter en ändrad byte och som osignerad.

När PowerShell är spärrat. Kan kontrollen inte köras, till exempel för att PowerShell är spärrat för användarna, installeras inga automatiska uppdateringar. Bara när PowerShell inte går att starta sparas nejet i programmets datamapp, och nästa försök görs då först efter 24 timmar, så att installern inte hämtas om vid varje start. Vid tidsgräns, fel utgivare, ogiltig signatur eller fel version nekas uppdateringen utan att något sparas, och nästa start försöker igen. Under Inställningar, Om Privera står då att uppdateringarna inte kunde verifieras på datorn, att inga uppdateringar installeras och att användaren ska kontakta IT-avdelningen. Sätt i så fall UpdateMode till 0 och rulla ut nya versioner centralt.

Före 0.9.0-beta22 jämförde utgivarkontrollen bara certifikatets namn (CN), och där PowerShell inte kunde köras hoppades signaturkontrollen över. En dator som uppdaterar från 0.9.0-beta21 till 0.9.0-beta22 prövar installern med den äldre kontrollen. Från 0.9.0-beta22 gäller den nya.

Installation per dator. Programmappen under Program Files är skrivskyddad för vanliga användare. En automatisk uppdatering startar installern, som då begär förhöjning (UAC). En användare utan administratörsrätt kan inte godkänna den, och uppdateringen blir inte av. Sätt därför UpdateMode till 0 eller 1 vid installation per dator. Det följer av installerns mall och är inte provat.

Säkerhetsuppdateringar. Rättningar ges bara i den senaste versionen, se Livscykel och support. Med läget Av eller Kontrollera och meddela ansvarar organisationen för att rulla ut dem.

6. Registerpolicyer och ADMX-mall

Programmet läser de här värdena under HKLM\Software\Policies\Privera vid start, med 64-bitarsvyn. Nyckeln är bara skrivbar för administratörer. Inga andra värden läses. Värdena läses med reg.exe. Från 0.9.0-beta22 startas det med full sökväg i Windows-katalogen, som programmet tar ur den plats som Windows laddade systembiblioteket ntdll.dll från, inte ur miljövariabeln SystemRoot, och med en egen, minimal miljö. Tidigare versioner tog katalogen ur SystemRoot. Policyn är ändå en styrning för vanlig användning, inte ett skydd mot en användare som avsiktligt vill kringgå den, se Säkerhetsloggning avsnitt 7.1.

Loggvärdena beskrivs i Säkerhetsloggning avsnitt 7.

ADMX-mallen. Privera.admx med språkfilerna sv-SE/Privera.adml och en-US/Privera.adml. Principerna hamnar under Datorkonfiguration, Administrativa mallar, Privera. Mallen beror inte på någon annan ADMX-fil.

• Grupprincip: lägg Privera.admx i PolicyDefinitions, lokalt C:\Windows\PolicyDefinitions eller i domänens centrala arkiv under SYSVOL, och språkfilerna i undermapparna sv-SE och en-US.
• Intune: Enheter, Konfiguration, Importera ADMX. Ladda upp Privera.admx med en-US\Privera.adml. Intune godtar bara en språkfil per mall och bara en-US. Skapa sedan en profil av typen Importerade administrativa mallar. En ny version av mallen godtas inte förrän profilerna och den gamla mallen är borttagna.
• Inte konfigurerad ger förvalet för alla principer. För de fem av- och på-principerna skriver Inaktiverad värdet 0. För katalogen och uppdateringarna tar Inaktiverad bort värdet, så att förvalet gäller.
• Mallen kontrolleras mot programmet i ett automatiskt test: varje värde mallen skriver läses av programmet med samma namn, typ och tal, och varje värde programmet läser finns i mallen. Den är inte provad i grupprincipredigeraren eller i Intune.

7. Nätverk

Programmet öppnar ingen inkommande port. Den utgående trafiken, till licens.privera.se och, första gången språkmodellen behövs, till Hugging Face, står i tabellen i Underlag för IT och informationssäkerhet. Med UpdateMode = 0 försvinner uppdateringskontrollen. Licenstrafiken finns kvar: aktivering, förnyelse normalt var sjunde dag och högst 14 dagar utan kontakt med licensservern.

8. VDI och terminalserver

Läget i dag, enligt programmets kod:

• Licensen binds till ett maskin-id som räknas fram ur ett slumpat installations-id i Windows-kontots profil (%APPDATA%\privera-desktop) och datornamnet. Varje Windows-konto får därför ett eget maskin-id, även på samma dator, och en licens gäller ett maskin-id åt gången.
• Terminalserver med flera sessioner: varje användare behöver en egen licens. Varje session kör en egen motor med språkmodellen. Minnesbehovet per session är inte mätt.
• Beständiga virtuella skrivbord med samma datornamn och en profil som behålls fungerar som en vanlig dator.
• Poolade skrivbord som byter datornamn eller inte behåller profilen ger ett nytt maskin-id. Licensen måste då tas över, och en övertagning går högst en gång var 30:e dag. Det fungerar inte i praktiken.
• Språkmodellen, cirka 440 MB, hämtas till varje användares profil första gången den behövs. Med profiler som inte behålls hämtas den igen.
• Licenser per organisation, per dator eller för terminalserver finns inte i dag. Kontakta [email protected].

Inget av detta är provat i en VDI- eller terminalservermiljö.

9. Det som är provat och det som inte är det

Provat i Windows Sandbox 2026-10-07 (ren Windows 11 utan Python, Node, Git eller Visual C++-runtime): tyst installation per användare (/S) av 0.9.0-beta20, uppgradering till 0.9.0-beta21 med /S ovanpå den, att licensen och licensfilen överlever uppgraderingen, att alla programfiler är giltigt signerade, att Appar och funktioner visar utgivaren Itha AB, analys med OCR och språkmodell, och UpdateMode = 1 under HKLM\Software\Policies\Privera i det installerade programmet.

Provat 2026-10-23 med Test-AppLockerPolicy mot ett signerat provbygge av 0.9.0-beta22: AppLocker-regeln i avsnitt 4.2, med resultatet som står där.

Inte provat:

• Tyst installation, uppgradering och avinstallation i Intune och Configuration Manager.
• Installation per dator på en ren dator, och automatisk uppdatering av en sådan installation.
• ADMX-mallen i grupprincipredigeraren och i Intune.
• Programmet under en tillämpad AppLocker- eller WDAC-policy.
• VDI och terminalserver.
• Värdena 0 och 2 för UpdateMode i ett installerat program (provade i automatiska tester).
• Uppdateringen på en dator där PowerShell är spärrat, i ett installerat program (provad i automatiska tester).
• RequireEventLogForExport och AllowDebugPort i ett installerat program (provade i automatiska tester).

Frågor om utrullning: [email protected].