Dela via

Felsöka loggning av programvaruinventering

Förstå SIL

Innan du börjar felsöka SIL bör du ha en god förståelse för dess komponenter och hur det fungerar. Följande videor ger en översikt över SIL och SIL Aggregator och hur du använder dem för att vidarebefordra och rapportera inventeringsdata:

  1. En introduktion till software inventory logging (SIL) (10:57)

  2. Loggning av programvaruinventering: Konfigurera SIL Aggregator (14:34)

  3. Loggning av programvaruinventering: Aktivera SIL-vidarebefordran (7:20)

Så här fungerar SIL-dataflödet

SIL-ramverket har två huvudkomponenter och två kommunikationskanaler. Dataflöde över båda kanalerna, och mellan båda komponenterna, är nödvändigt för en lyckad SIL-distribution (detta förutsätter att en virtualiserad eller molnbaserad miljö – rent fysiska miljöer behöver bara en av kommunikationskanalerna). Du måste förstå komponenterna och dataflödet i SIL för att distribuera det korrekt. När du har tittat på översiktsvideorna ovan har du sett arkitekturdiagrammet som illustrerar komponenterna och dataflödet i båda kanalerna. Orange pilar anger fjärrfrågor över WinRM, gröna streckade pilar anger HTTPS-inlägg till SIL Aggregator från SIL i varje WS-slutnod:

SIL-ramverksdiagram

Om du stöter på ett problem med SIL är det troligtvis relaterat till ett avbrott i dataflödet över kanalerna och mellan komponenterna. Följande är de vanligaste problemen som rör dataflödet, följt av felsökningsstegen i nästa avsnitt för att lösa vart och ett av de tre problemen:

  • Problem med dataflöde 1 – Inga data i rapporten när du använder cmdleten Publish-SilReport (eller vanligtvis saknar data).

  • Dataflödesproblem 2 – För många servrar under Okänd värd i rapporten.

  • Problem med dataflöde 3 – För många virtuella datorer under fysiska värdar som anges som Okänt operativsystem i rapporten och/eller ett fel som uppstår vid användning av Publish-SilData på Windows-servrar som kör SIL.

Felsöka problem med dataflöde

Innan du börjar måste du veta hur länge sedan SIL Aggregator började med cmdleten Start-SilAggregator .

Viktigt!

Det kommer inte att finnas några data i rapporten förrän SQL-datakuben bearbetas kl. 03.00 lokal systemtid. Fortsätt inte med felsökningsstegen förrän kuben har bearbetat data.

Om du felsöker data i rapporten (eller saknas i rapporten) som är nyare än den senaste gången kuben bearbetas eller innan kuben någonsin har bearbetats (för en ny installation) följer du dessa steg för att bearbeta SQL-datakuben i realtid:

  1. Logga in som administratör för SQL Server och kör SSMS i en kommandotolk.
  2. Anslut till databasmotorn.
  3. Expandera SQL Server Agent och expandera sedan Jobb.
  4. Högerklicka på SILStagingRefresh och välj sedan Starta uppgift vid steg.
  5. Klicka på Start och vänta tills förloppsindikatorn för uppdateringen har slutförts.
  6. Öppna PowerShell som administratör och kör cmdleten publish-silreport -openreport .

Om det fortfarande inte finns några data i rapporten fortsätter du med att felsöka de tre dataflödesproblemen.

Problem med dataflöde 1

Inga data i rapporten när du använder cmdleten Publish-SilReport (eller data saknas vanligtvis)

Om data saknas beror det troligen på att SQL-datakuben inte har bearbetats ännu. Om den nyligen har bearbetats och du anser att data som saknas borde ha kommit till aggregatören innan kubbearbetningen påbörjas, följer du datasökvägen i omvänd ordning. Välj en unik värd och en unik virtuell dator att felsöka. Datasökvägen omvänt är SILA-rapport<SILA-databas<SILA lokalt bibliotek<fjärrfysisk värd eller WS VM som kör SIL-agent/uppgift.

Kontrollera om data finns i databasen

Det finns två sätt att söka efter data: Powershell eller SSMS.

Viktigt!

Om kuben har bearbetats minst en gång sedan SILA infogade data i databasen bör dessa data återspeglas i rapporten. Om det inte finns några data i databasen misslyckas antingen avsökningen av de fysiska värdarna, eller så tas inget emot via HTTPS eller båda.

PowerShell

  1. Öppna PowerShell som administratör och kör cmdleten get-silvmhost och kör sedan get-silaggregator.

    Anmärkning

    Utdata från get-silaggregator efterliknar alltid fliken Windows Server-information i Excel-rapporten. Förvänta dig inte ett annat resultat.

  2. Kör get-silvmhost

    • Om det inte finns några värdar i listan lägger du till värdar med hjälp av cmdleten add-silvmhost .
    • Om värdar visas som Okända går du till Problem 2. d – Om värdar visas men det inte finns någon datetime under kolumnen Senaste avsökning går du till Problem 2 nedan.

Andra relaterade kommandon

<Get-SilAggregator -Computername fqdn för en känd server som skickar data>: Detta genererar information från databasen om en dator (VM) redan innan kuben har bearbetats. Den här cmdleten kan därför användas för att kontrollera data i databasen för en Windows Server som skickar SIL-data via HTTPS, före eller utan kubprocessen kl. 03.00 (eller om du inte har uppdaterat kuben i realtid enligt beskrivningen i början av det här avsnittet).

Get-SilAggregator -VmHostName <fqdn för en avsökt fysisk värd där det finns ett värde under kolumnen Senaste avsökning när du använder Get-SilVmHost cmdleten>: Detta genererar information från databasen om en fysisk värd även innan kuben har bearbetats.

SSMS

nSök efter data från värdar som undersöks:

  1. Öppna SSMS och anslut till databasmotorn.

  2. Expandera Databaser, expandera SoftwareInventoryLogging-databasen , expandera Tabeller, högerklicka på tabellen HostInfo och välj sedan de översta 1 000 raderna.

    Om det finns data för en eller flera värdar i tabellen har avsökningen för den/dessa värdar lyckats minst en gång.

    Sök efter data från virtuella datorer eller fristående servrar som har push-överfört data via HTTPS:

  3. Öppna SSMS och anslut till databasmotorn. A2. Expandera Databaser, expandera SoftwareInventoryLogging-databasen , expandera Tabeller, högerklicka på tabellen VMInfo och välj sedan de översta 1 000 raderna.

    Anmärkning

    Varje rad för en unik virtuell dator representerar en bearbetad bmil-fil som skickas över HTTPS och bearbetas av SIL Aggregator. Bmil-filer är proprietära filer som används av SIL, en skapas var och en av varje SIL-instans Observera att detta endast är nödvändigt när SIL och SILA används i virtuella miljöer. Annars är endast HTTPS-trafik nödvändig/förväntad).

    Alla data i databasen ska återspeglas i SIL-rapporter när kuben har bearbetats.

Problem med dataflöde 2

För många servrar under Okänd värd

Detta kommer sannolikt att inträffa i virtuella miljöer när SIL Aggregator inte lyckas avsöka fysiska värdar som är värdar för de virtuella datorerna.

  1. Öppna PowerShell som administratör och kör cmdleten get-silvmhost .

    • Om värdar visas som Okänd fungerade inte cmdleten add-silvmhost korrekt – vanligtvis på grund av felaktiga autentiseringsuppgifter som lagts till för åtkomst till dessa värdar (alltså Okänd). Men om autentiseringsuppgifterna är verifierade kan det innebära att den automatiska identifieringen av värdtyp och hypervisortyp i cmdleten add-silvmhost kunde inte identifiera plattformen. Det finns avancerade felsökningssteg för dessa situationer, men de beskrivs inte här (kontrollera EventViewer SIL Aggregator-kanaler).

    • Om värdar visas, och värdtyp och hypervisortyp visas med värden som INTE är okända, dvs. Windows och HyperV, eller Ubuntu och Xen osv., men det finns ingen datetime under senaste avsökningskolumn , så har avsökningen inte genomförts ännu.

      • Du kommer behöva vänta en timme efter att du har lagt till värden innan avsökningen kan ske (förutsatt att detta intervall är inställt på standard – vilket kan kontrolleras med cmdleten get-silaggregator).

      • Om det har gått en timme sedan värden lades till kontrollerar du att avsökningsaktiviteten körs: I Schemaläggaren väljer du Software Inventory Logging Aggregator under Microsoft>Windows och kontrollerar aktivitetens historik.

    • Om en värd visas, men det inte finns något värde för RecentPoll, HostType eller HypervisorType, kan detta till stor del ignoreras. Detta sker endast i HyperV-miljöer. Dessa data kommer faktiskt från den virtuella Windows Server-datorn och identifierar den fysiska värd som körs via HTTPS. Detta kan vara användbart för att identifiera en specifik virtuell dator som rapporterar, men kräver att databasen delas upp med cmdleten Get-SilAggregatorData .

När värdarna sonderar korrekt kan du se data för dessa fysiska värdar i SILA-databasen där det finns en datetime under nylig sondring. Avsnittet Problem 1 ovan innehåller steg för att hämta dessa data.

Problem med dataflöde 3

För många fysiska värdar med virtuella datorer listade som okänt operativsystem

  1. Välj en Windows Server-slutnod (VM) som du vet finns på en av dessa värdar och logga in som administratör.
  2. Öppna PowerShell som administratör.
  3. Kontrollera att SilLogging körs med hjälp av cmdleten Get-SilLogging .

    • När programmet körs kan du försöka skicka SIL-data manuellt med Publish-SilData.

    • Om det finns ett fel:

      • Kontrollera att targeturi har https:// i posten.
      • Se till att alla förutsättningar uppfylls
      • Se till att alla nödvändiga uppdateringar för Windows Server är installerade (se Krav för SIL). Ett snabbt sätt att kontrollera (endast på WS 2012 R2) är att söka efter dessa med hjälp av följande cmdlet: Get-SilWindowsUpdate *3060, *3000
      • Kontrollera att certifikatet som används för att autentisera med aggregatorn är installerat i rätt arkiv på den lokala servern som ska inventeras med SilLogging.
      • På SIL Aggregator kontrollerar du att certifikatets tumavtryck för certifikatet som används för att autentisera med aggregatorn läggs till i listan med hjälp av cmdleten Set-SilAggregator–AddCertificateThumbprint .
      • Om du använder företagscertifikat kontrollerar du att servern med SIL aktiverad är ansluten till domänen som certifikatet skapades för, eller på annat sätt kan verifieras med en rotutfärdare. Om ett certifikat inte är betrott på den lokala datorn som försöker vidarebefordra/skicka data till en Aggregator, misslyckas åtgärden med ett fel.

      Om alla ovanstående har kontrollerats och verifierats, men problemet kvarstår:

      • Kontrollera att certifikatet som används för att installera SIL Aggregator är felfritt och matchar namnet på själva SIL Aggregator-servern. Om företagscertifikat används för att installera SIL Aggregator kan Aggregator också behöva anslutas till domänen där certifikatet skapades (de här stegen är onödiga om andra datorer vidarebefordras till samma SIL-aggregator).

      • Slutligen kan du kontrollera följande plats för cachelagrade SIL-filer på servern som försöker vidarebefordra/pusha, \Windows\System32\Logfiles\SIL. Om SilLogging har startats och har körts i mer än en timme, eller Publish-SilData har körts nyligen, och det inte finns några filer i den här katalogen, då har loggningen till Aggregator lyckats.

Om det inte finns några fel och ingen utdata på konsolen, lyckades push/publicering av data från Windows Server-slutnod till SIL Aggregator via HTTPS. Om du vill följa sökvägen för data framåt loggar du in på SIL Aggregator som administratör och undersöker de datafiler som har anlänt. Gå till Programfiler (x86)>Microsoft SIL Aggregator> SILA-katalog. Du kan se datafiler som anländer i realtid.

Anmärkning

Mer än en datafil kan ha överförts med cmdleten Publish-SilData . SIL på slutnoden kommer att cachelagra misslyckade pushförsök för upp till 30 dagar. Vid nästa lyckade push-överföring går ALLA datafiler till Aggregator för bearbetning. På så sätt kan en nyligen konfigurerad SIL Aggregator visa data från en slutnod långt före sin egen installation.

Anmärkning

Det finns regler som SILA följer när du bearbetar datafiler i SILA-katalogen som endast är relevanta i situationer med låg trafik. Hög trafik utlöser alltid bearbetning i realtid. Standardbeteendet är att bearbetningen påbörjas antingen efter att 100 filer har kommit till katalogen eller efter 15 minuter. När du felsöker från slutpunkt till slutpunkt i en liten miljö är det ofta nödvändigt att vänta 15 minuter.

När dessa filer har bearbetats visas data i databasen.