Steg 5 av 8 · Windows

Windows-servrar

Serviceagenten är en Windows-tjänst. Den hämtar certifikat från appliancen och installerar dem på servern. Ni ansluter servern med en rad som ni kopierar från appliancen.

Innan ni börjar

Ni behöver:

En Windows-server med Windows Server 2016 eller senare.
En administratörsinloggning på servern.
Att servern når appliancen direkt över HTTPS, eller når sslbrain.com och cloud.sslbrain.com på port 443. Står servern någon annanstans än appliancen, se Servrar utanför ert nätverk.
Om App Control (WDAC), AppLocker, antivirus eller EDR begränsar program på servern, förbered godkännande av agent och skript med er säkerhetsadministratör före installation.

Anslut servern

Öppna Servrar i sslbrain och klicka på Installera serviceagent. Knappen står överst på sidan och under listan, så länge appliancen är den enda servern.
Klicka på Kopiera under Windows (rekommenderas). Det är den första raden på sidan, och den ser ut så här:
```
msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<kod> DESTINATIONS="https://<appliance>,cloud"
```
Öppna en kommandotolk eller PowerShell som administratör på servern, klistra in raden och tryck Enter.

Servern hämtar den senaste agenten från appliancen, installerar den och ansluter direkt till appliancen med koden. /qb visar installationens statusfönster, och går något fel står felet på skärmen. Efter en minut eller två står servern under Servrar.

Koden och appliancens adress står redan i raden. Öppnar ni sidan från Servrar och finns det ingen öppen installationskod, skapar appliancen själv en utan sista dag och skriver det i revisionsloggen. Samma kod fungerar på så många servrar ni vill, tills ni stänger den under Installationskoder längre ner på sidan. Där skapar ni också fler koder och ger en kod en sista dag. Stänger ni den sista öppna koden visar sidan inget kommando förrän ni klickar på Skapa en ny kod och visa kommandot.

Raden har sslbrain Cloud efter appliancen som failover så länge Tillåt agentkommunikation via Cloud är påslagen under Inställningar › Säkerhet och appliancen är ansluten till sslbrain Cloud. Annars står bara appliancens adress:

msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<kod> DESTINATIONS=https://<appliance>

Citattecknen runt listan med cloud ska vara med, så att listan når msiexec som ett värde från både kommandotolken och PowerShell. Utan cloud i listan använder agenten inte sslbrain Cloud. Ska den få Cloud senare, klicka på Aktivera Cloud igen för den här agenten på serverns sida under Servrar.

Använder appliancen sitt eget självsignerade certifikat litar Windows inte på det, och raden hämtar i stället agenten från sslbrain.com. Agenten ansluter sedan direkt till appliancen, och DESTINATIONS följer samma installationsplan som ovan:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<kod> DESTINATIONS="https://<appliance>,cloud"

Servern behöver då nå sslbrain.com på port 443. Ge appliancen ett riktigt certifikat, så hämtas agenten från appliancen själv (Gratis namn).

Anslut via sslbrain Cloud

Når servern inte appliancen direkt, öppna Servern når inte appliancen direkt på sidan och använd raden där:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<kod>

Agenten hittar appliancen genom sslbrain Cloud med koden. Cloud kan varken läsa eller ändra det som appliancen och agenten skickar till varandra (Servrar utanför ert nätverk).

Avsnittet finns bara när Tillåt agentkommunikation via Cloud är påslagen under Inställningar › Säkerhet.
Alla licenser kan ansluta via Cloud. Omfattar licensen inte Cloud-anslutning, står servern som Blockerad under Servrar och får inga uppgifter förrän den byts till direkt anslutning eller licensen uppgraderas (Servrar utanför ert nätverk).

Flera servrar på en gång

Den första raden fungerar på varje server för sig, också från ett skript eller ett verktyg för programvarudistribution. Ska servrarna inte hämta agenten själva, eller har de ingen internetåtkomst, öppna Flera servrar, GPO eller utan internet, klicka på Hämta MSI, distribuera sslbrain-agent.msi och kör raden med den lokala filen i mappen där filen ligger. Raden har samma DESTINATIONS som den första raden. Den har /qn och visar inga fönster, eftersom ett startskript eller ett distributionsverktyg kör den utan att någon ser skärmen:

msiexec /i sslbrain-agent.msi /qn INSTALLCODE=<kod> DESTINATIONS="https://<appliance>,cloud"

Med en GPO: Rulla ut serviceagenten på många Windows-servrar.

Agenten för Windows på ARM64 finns under Andra utgåvor som sslbrain.com/agent-arm64.zip.

Servern dyker upp

En server som ansluter med koden är godkänd och står under Servrar. sslbrain hittar själv tjänsterna på servern som använder certifikat och visar dem under Tjänster.

En server som ser ut som en ominstallation av en server som redan är ansluten väntar i stället under Servrar som väntar på godkännande på sidan Installera serviceagent.

Jämför Agentnyckel med nyckeln som agenten har skrivit i sin logg på servern (Loggfiler).
Klicka på Godkänn.

Kolumnen Typ under Servrar visar om servern är ansluten Lokal eller Via Cloud.

Nästa steg

Visa att domänen är er, så att sslbrain kan få certifikat för den: Visa att domänen är er.

Om det inte fungerar

Raden verkar inte göra något: i PowerShell kommer prompten tillbaka direkt medan installationen fortsätter i sitt eget fönster. Vänta några minuter och kontrollera tjänsten med Get-Service sslbrainagent. Lägg till /l*v C:\Windows\Temp\sslbrain-agent.log sist på raden för att få en logg över installationen.
Installationen stoppar med SSLBrain Agent needs its appliance eller Angiv CODE eller SERVER. Specify CODE or SERVER: raden saknar koden. Kopiera den igen från Installera serviceagent.
msiexec kan inte öppna adressen: servern når inte adressen i raden, appliancen eller sslbrain.com. Använd Hämta MSI och den lokala raden under Flera servrar, GPO eller utan internet, eller raden under Servern når inte appliancen direkt.
Servern står som Blockerad: den är ansluten via sslbrain Cloud och licensen omfattar inte det. Öppna servern och klicka på Byt till direkt (Servrar utanför ert nätverk).
Koden står som Stängd eller Utgången: öppna Installera serviceagent från Servrar. Sidan visar en öppen kod eller skapar själv en ny. Står det Ingen installationskod är öppen, klicka på Skapa en ny kod och visa kommandot.
Servern dyker inte upp: Agenten hör inte av sig.
Certifikatet installeras inte: Installationen misslyckas.

Loggfiler

Vad	Var
Agentens logg, en fil per dag	`C:\ProgramData\sslbrain\logs\agent-<datum>.log`
Uppdateringar av agenten	`C:\ProgramData\sslbrain\logs\update-msiexec-<version>-<tid>.log`

Tjänsten heter sslbrainagent, och i tjänstelistan “sslbrain agent”. Status och de senaste raderna i loggen:

Get-Service sslbrainagent
Get-Content "C:\ProgramData\sslbrain\logs\agent-$(Get-Date -Format yyyy-MM-dd).log" -Tail 50

En server som hade agenten före version 1.4.0 behåller mappen och nyckeln i registret med de versaler de fick då. Windows läser dem som samma namn.

Registret

Agentens inställningar står i HKLM\SOFTWARE\sslbrain. Värden under HKLM\SOFTWARE\Policies\sslbrain går före, så de kan sättas med en GPO. Starta om tjänsten efter en ändring med Restart-Service sslbrainagent.

Alla värden står under Inställningar i registret.

Godkänn agenten i Windows säkerhetspolicyer

App Control for Business är det nuvarande namnet på Windows Defender Application Control (WDAC). Det är samma teknik. AppLocker är en separat kontroll; antivirus och EDR kan dessutom fatta beslut om filer, skript och beteende.

Här kan er säkerhetsadministratör förbereda avgränsade regler. Ni behöver rätt att administrera relevanta policyer, den faktiskt hämtade MSI-filen och installerade filer, en referensserver med samma Windows-utgåva/build och säkerhetsinställningar samt Windows policyverktyg (ConfigCI eller AppLocker). Behåll er Windows-grundpolicy, en säkerhetskopia av policyn och en återställningsprocedur. Funktioner varierar med OS-versionen. Exemplen nedan skapar lokala XML-förslag och granskar filer; de tillämpar ingen policy. Testa förslagen genom er vanliga audit-/pilot- och tillämpningsprocess före bred utrullning. Audit ensamt bevisar inte att skript fungerar när reglerna tillämpas.

Identifiera de faktiska filerna

Den 9-10-2026 granskade vi den offentliga x64-agent.msi, version 1.4.2. MSI-tabellerna installerar C:\Program Files\sslbrain\sslbrainagent.exe som sslbrainagent, visad som “sslbrain agent”, under LocalSystem. Kontrollera PathName och StartName på er server; en äldre installation eller annan enhet kan skilja sig.

Både MSI-filen och dess extraherade EXE innehåller en Authenticode-signatur vars slutcertifikat har CN=FairSSL A/S, O=FairSSL A/S, C=DK, organisationsnummer 33075782 och utfärdare DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. Slutcertifikatets SHA-256-fingeravtryck är 8854997a1e37006307ed8f985df5142021f9edfd58422d455078dd5b7ad45dab. Det är en observerad identitet, inte en policysträng att kopiera. Linux-verktyget osslsigncode verifierade båda signaturerna, kedjorna och tidsstämplarna; Windows-status från Get-AuthenticodeSignature är inte verifierad. Verifiera era egna filer i Windows, inklusive certifikattillit och åtkomst för återkallelsekontroll. Godkänn inte en fil med saknad eller ogiltig signatur utan att undersöka den.

Spara den hämtade installeraren som sslbrain-agent.msi i aktuell mapp och granska den och den installerade EXE-filen:

$exe = 'C:\Program Files\sslbrain\sslbrainagent.exe'
Get-CimInstance Win32_Service -Filter "Name='sslbrainagent'" |
    Select-Object Name, StartName, PathName
$files = @('.\sslbrain-agent.msi', $exe)
foreach ($file in $files) {
    $s = Get-AuthenticodeSignature -LiteralPath $file
    [pscustomobject]@{
        File = $file; Status = $s.Status; Detail = $s.StatusMessage
        Subject = $s.SignerCertificate.Subject
        Issuer = $s.SignerCertificate.Issuer
        Thumbprint = $s.SignerCertificate.Thumbprint
    }
}
(Get-Item -LiteralPath $exe).VersionInfo |
    Select-Object ProductName, OriginalFilename, FileVersion
Get-FileHash -LiteralPath $exe -Algorithm SHA256

Den granskade EXE-filen har produkt sslbrain agent, OriginalFilename=SslBrainAgent.dll och filversion 1.4.2.0. Originalnamnet är ett signerat resursattribut, trots att filen på disken slutar med .exe. Hela EXE-filens SHA-256 är ccee898b41b98af4a1382426edb013f0be4bc8e084a84dfdb0d7bcb2698b131c; använd det endast för att identifiera denna granskade build. App Controls hashregler använder Authenticode/PE-image-hash, som skiljer sig från Get-FileHash; låt policyverktyget beräkna dem. Certifikatfingeravtrycket ovan är SHA-256, medan certifikatets visade Thumbprint normalt är SHA-1. Det granskade slutcertifikatets SHA-1-thumbprint är C487B12B87298E601D5CEEEB7239829AC795008A.

MSI-filen innehåller en EXE, inte separata applikations-DLL:er. Dess bundle innehåller managed assemblies, bland annat SslBrainAgent.dll och System.Management.Automation.dll, och fem native DLL:er: getfilesiginforedist.dll, microsoft.management.infrastructure.native.unmanaged.dll, PowerShell.Core.Instrumentation.dll, pwrshplugin.dll och sni.dll. De native filerna innehåller Microsoft-signaturer; deras Windows-tillitsstatus och vilka filer en viss uppgift laddar är inte verifierade. Linux-verifieringen kunde inte bygga deras utfärdarkedjor. Kontrollera faktiskt laddade/extraherade DLL:er var för sig i stället för att behandla dem som FairSSL-signerade filer. Policyer med .NET Dynamic Code Security behöver även separat validering av managed assemblies.

Syfte	Standardplats i den granskade implementationen
Hämtad uppgift och extraherade filer	`C:\ProgramData\sslbrain\work\<task-id>\package.tar` och `extracted\` under samma uppgiftsmapp
Verifierad kopia för EXE-stages och PowerShell-fallback	`.verified-<random>.ps1` eller `.exe` bredvid originalfilen i uppgiftens extraktionsmapp
Verktygssökväg definierad i kod, inte anropad i 1.4.2	`C:\ProgramData\sslbrain\tools\<tool-name>\`
Hook-sökväg definierad i kod, inte anropad i 1.4.2	`C:\ProgramData\sslbrain\hooks\`
Hämtning och tillämpning av uppdatering	`C:\ProgramData\sslbrain\update\staging\`, sedan `apply\`; kopierad updater-EXE: `apply\SslBrainAgent.exe`
Uppdaterings-MSI och återställningskopior	`update\apply\target\`, `update\apply\previous\` och `update\installed\<version>\` under datamappen
Agent- och uppdateringsloggar	`C:\ProgramData\sslbrain\logs\` (Loggfiler)

DataPath kan ändra platsen för uppgifts-/uppdateringsdata. ToolsPath konfigurerar verktygssökvägen definierad i koden; denna hämtningskod och hook-assemblern anropas inte i 1.4.2. .NET-värden för single-file-program extraherar native bibliotek under DOTNET_BUNDLE_EXTRACT_BASE_DIR om den är angiven, annars under tjänsteprocessens %TEMP%\.net. Den slutliga mappen beror på tjänstens miljö och bundle; den är inte observerad i Windows. Hitta den i ert process-/modulinventarium eller en blockeringshändelse. Sökvägarna identifierar filer att undersöka; de rekommenderar inte att tillåta eller undanta hela skrivbara mappar.

Regler i App Control och AppLocker

Granska signaturer och filmetadata ovan. Kopiera endast den verifierade referens-EXE-filen och eventuella separat verifierade beroendefiler till reference-agent i arbetsmappen. Håll andra hämtningar utanför den.
För App Control: skapa FilePublisher-förslag från dessa verkliga filer:
Terminal window
```
New-CIPolicy -ScanPath '.\reference-agent' -FilePath '.\agent-candidate.xml' `
    -Level FilePublisher -Fallback Hash -UserPEs
```
Granska XML-regelns signer, filattribut och minimiversion för varje regel. För denna EXE är standardfilattributet SslBrainAgent.dll, inte namnet på disken. Behåll både utgivare, den enskilda filens identitet och en lämplig minimiversion; det kan följa nyare signerade versioner så länge identitet och utfärdarkedja är samma. Nytt certifikat/kedja eller filidentitet kräver granskning. Granska varje Hash-fallback och förnya reglerna när binärfiler ändras. Ersätt inte saknade filmetadata med en CA-regel eller en regel för allt från FairSSL. Integrera godkända regler i er grundpolicy med ert policyverktyg; skanningen är inte en komplett utrullningspolicy. Behåll grundpolicyns skripttillämpning och granska de genererade policyalternativen; tillämpa inte skanningens XML direkt. Hantera MSI-filen separat i verktygets installerarregler utifrån den faktiskt signerade MSI-filen. Ge aldrig generell tillit till DigiCert eller någon annan CA.
För AppLocker: använd Create New Rule → Publisher → Browse i relevant EXE-, MSI- och, om aktiverad, DLL-regelsamling. Välj den verkliga referensfilen. Behåll utgivare, produkt och binärnamn och välj den testade minimiversionen och senare versioner. Granska wildcardfält från verktygen. Använd tjänstens faktiska konto för EXE-/DLL-regler och installationskontot för MSI-regler. Automatiska uppdateringar kör den kopierade uppdateraren och msiexec.exe som SYSTEM, så MSI-regler måste även omfatta S-1-5-18 när uppdateringar används. Kontrollera att den befintliga Windows-grundpolicyn tillåter nödvändiga systemfiler msiexec.exe och schtasks.exe. Kontrollera om er AppLocker-konfiguration tillämpar regler för tjänster, att Application Identity körs och vilka regelsamlingar som tillämpas. För standard-EXE-filen under LocalSystem skapar följande ett förslag och bedömer filen:
Terminal window
```
Get-AppLockerFileInformation -Path $exe |
    New-AppLockerPolicy -RuleType Publisher -User 'S-1-5-18' -Xml |
    Set-Content '.\agent-applocker-candidate.xml'
Test-AppLockerPolicy -XmlPolicy '.\agent-applocker-candidate.xml' `
    -Path $exe -User 'S-1-5-18'
```
Test-AppLockerPolicy kontrollerar filens matchning mot regler; det testar inte PowerShell-beteende, effektiv GPO-sammanslagning eller tjänstekörning. Granska den effektiva policyn och testa den faktiska tjänsten och nödvändiga uppgifter på referensservern. När den kopierade uppdateraren finns, bedöm även C:\ProgramData\sslbrain\update\apply\SslBrainAgent.exe med Test-AppLockerPolicy för S-1-5-18; en regel som endast bygger på installationssökvägen omfattar den inte. Saknar ett beroende en användbar utgivaridentitet, använd ett granskat hashförslag för den enskilda filen och uppdatera det med filen. Tillåt inte hela ProgramData, Temp, arbetsmappen eller allt via powershell.exe som godkännande av deploy-skript.

Deploy-skript kräver separat godkännande

En EXE-task-stage körs som en separat process från sin .verified-<random>.exe-kopia i uppgiftens extraktionsmapp. Den behöver en egen avgränsad publisher-/FilePublisher- eller filhashregel skapad från det faktiska verifierade programmet och dess beroenden. Tjänstens EXE-regel och sslbrains paketsignatur godkänner den inte i Windows. Använd filidentitet i stället för att tillåta den skrivbara mappen eller slumpmässiga sökvägen.

I den granskade 1.4.2-implementationen skapar det inbyggda PowerShell SDK ett runspace och anropar AddScript(scriptContent) på skripttext. Denna väg kör inte en Authenticode-godkänd .ps1-fil via dess sökväg. En FilePublisher-regel för tjänstens EXE, en paketsignatur eller en Authenticode-signatur på originalskriptet visar därför inte att detta skript i minnet får FullLanguage-godkännande under App Control.

Om den inbyggda värden saknas eller inte kan initialiseras startar fallback powershell.exe med -ExecutionPolicy Bypass och en kodad bootstrap. Den skickar indata via stdin och anropar en tillfällig verifierad skriptfil via sökväg. Bypass är ett val av execution policy för processen; det kan inte åsidosätta en execution policy från Group Policy och ger inte tillstånd i App Control eller AppLocker. Bootstrappens .NET-anrop och skripten kan möta språkbegränsningar. Fallback är inte en genväg till godkännande. Ett skript-runtime-fel, inklusive ett språkbegränsningsfel efter exekveringsstart, utlöser inte automatiskt fallback.

GPO-valet Allow only signed scripts motsvarar AllSigned för skriptfiler. Execution policy är en säkerhetshjälp, inte en säkerhetsgräns för application control: MachinePolicy/UserPolicy har företräde framför processinställningar, men AllSigned ensamt bevisar inte att AddScript-texten kontrollerades som en signerad fil. Under App Control beror PowerShells beteende på OS/API och PowerShell-version: icke godkänd kod kan begränsas eller blockeras. Det inbyggda SDK är PowerShell 7.4.7; fallback är Windows PowerShell. Kontrollera både PowerShell Core- och Windows PowerShell-GPO-inställningar: de administreras separat, med det dokumenterade valet Use Windows PowerShell Policy setting för Core. Under en effektiv GPO AllSigned kräver fallback-skriptfilen en egen giltig Authenticode-signatur och utgivartillit; en separat paketsignatur ger inte detta. Anta inte att resultat i administratörens interaktiva shell beskriver tjänstens runspace.

sslbrains separata paketsignaturer och ScriptPolicy styr paketintegritet och godkännande inom sslbrain. De är separata från Windows Authenticode och Windows-policyer. Behåll signaturkontroll av paket/hämtningar/uppdateringar: version 1.4.2 verifierar uppdateringskatalog och releasemanifest mot inbyggda produktionsankare och kontrollerar MSI mot signerade storlekar/hashvärden. Det är inte ett påstående om att uppdateraren utför Windows Authenticode-validering.

Ni kan förbereda program-/installerarregler nu. Här finns inget verifierat recept för FullLanguage-godkännande av den nuvarande deploy-vägen i minnet under en restriktiv skriptpolicy. Validera den faktiska modulens discovery, deployment och verification under er policy före användning; en tjänst som körs eller en lyckad check-in är otillräckligt. Kräver era regler att alla deployments körs som policygodkända signerade skriptfiler behöver denna väg en implementationsändring. Spara kravet och den misslyckade operationen för support; försvaga inte application control, inaktivera inte skripttillämpning och ändra inte execution policy för att få det att fungera.

Antivirus och EDR

Behåll skanning, AMSI och beteendeövervakning. Granska leverantörens faktiska larm, filhash, signatur, processträd och blockerade operation. Föredra ett avgränsat godkännande av den identifierade filen och berörd enhetsgrupp med gransknings-/utgångsdatum enligt leverantörens produktdokumentation. Bedöm igen vid uppdatering. Ett programgodkännande godkänner inte automatiskt underprocesser, skript, ändringar i certifikatlagret eller tjänsteomstart. Det finns ingen garanti för kompatibilitet med alla antivirus-/EDR-policyer.

Microsoft Defender for Endpoint stöder exempelvis filhashbaserade Allow-indikatorer och certifikatindikatorer. En certifikatindikator omfattar flera filer, så en indikator för en enskild fil är mer avgränsad när den räcker. Funktionerna kräver dokumenterad licens, rättigheter, Defender-konfiguration och enhetsavgränsning; använd leverantörsinstruktionerna nedan. Skanningsundantag i Defender Antivirus är inte samma sak som EDR-godkännande. Undanta inte hela agent-, arbets-, uppdaterings- eller .NET-extraktionsmappar och skapa inte breda processundantag. Andra leverantörer kräver en egen dokumenterad godkännandeprocedur.

Nätverksgodkännande är separat: tillåt den konfigurerade appliancens HTTPS-värd/port (normalt 443), namnuppslagning och, när Cloud används, cloud.sslbrain.com:443; installation från den offentliga hämtningen behöver sslbrain.com:443. Uppdateringar i den granskade koden hämtas från den konfigurerade appliancen över HTTPS. För en agent vars sparade destinationslista endast innehåller Cloud avvisar release 1.4.2 staging av uppdatering, eftersom denna Cloud-uppdateringskälla inte är implementerad; anta inte att Cloud-kommunikation även ger denna uppdateringsväg. Kontroll av signaturtillit/återkallelse kan behöva åtkomst till certifikatutfärdarnas tjänster enligt er nätverkspolicy. Agenten behöver ingen inkommande port. Se Så når agenten appliancen för er anslutningstyp.

Hitta en blockering och registrera vad som testats

Jämför samma tidpunkt och fil/process i agentloggen, MSI-loggen och dessa Windows-kanaler:

Event Viewer-kanal	Vad ni kontrollerar
`Microsoft-Windows-CodeIntegrity/Operational`	3076: skulle blockera i audit; 3077: blockerad vid tillämpning; koppla 3089-signaturdetaljer via ActivityID. 3099 visar en laddad policy.
`Microsoft-Windows-AppLocker/EXE and DLL`	AppLocker 8003: skulle blockera i audit; 8004: blockerad. Kontrollera fil, regel och användar-SID.
`Microsoft-Windows-AppLocker/MSI and Script`	AppLocker 8006/8007: audit/blockering. App Control 8028/8029: skriptvärdens audit-/tillämpningsbeslut; 8038: kopplade signaturdetaljer. Värden avgör begränsning eller blockering. Microsoft dokumenterar att kanalen saknas på Server Core.
`Microsoft-Windows-PowerShell/Operational` eller `PowerShellCore/Operational`	Värdfel och, när aktiverat, script-block-händelser som 4104. PowerShell Core behöver en registrerad event provider innan den kan skriva dessa händelser. Jämför med agentloggens meddelanden om inbyggd värd/fallback.
`Microsoft-Windows-Windows Defender/Operational` och EDR-konsolen	Detektion, karantän, ASR eller annan leverantörsåtgärd; följ instruktionerna för det faktiska larmet.

Get-ExecutionPolicy -List
Get-AppLockerPolicy -Effective -Xml
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-CodeIntegrity/Operational'
    Id=3076,3077,3089,3099
    StartTime=(Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message

Kör dessa läskommandon med relevanta administratörsrättigheter. En tom kanal eller saknad blockeringshändelse bevisar inte godkännande. Kontrollera effektiv policy, signaturstatus, tjänsteidentitet, beroendefil och exakt misslyckad fas. Script-block-loggar kan innehålla känsliga skript/indata; skydda diagnostikbevis med åtkomstkontroll och ta bort känsliga uppgifter före delning.

Artefaktgranskningen och källsökvägarna ovan kontrollerades den 9-10-2026 mot release 1.4.2. Windows säkerhetsbeteende dokumenteras av Microsoft; exekverings- och uppdateringsdetaljerna kommer från releasens implementation. Inget Windows-runtime-test under App Control, AppLocker, antivirus eller EDR utfördes för denna guide. Registrera OS/build, agentversion, policyer, leverantörsinställningar och resultat av installation, tjänstestart, discovery, deployment, verification och uppdatering i er pilot.