Du är här:
IT-administratör bygger en CMDB med Discovery
Använd Discovery för att hjälpa en IT-administratör bygga en pålitlig konfigurationshanteringsdatabas (CMDB) genom att inventera konfigurationsobjekt (CI) och deras beroenden i en kontrollerad del av IT-miljön.
Överblick av användningsfall
Persona: En IT-administratör som ansvarar för konfigurationsdata, Discovery-täckning och CMDB-kvalitet
Jobb att utföra: Upptäck tillgångar, identifiera dem enhetligt, skapa eller uppdatera konfigurationsobjekt och exponera användbara relationer utan att förlita dig på manuell lagerinmatning
Startpunkt: CMDB och Servicegraf provisioneras och Tillgångsupptäckt är tillgängligt i Salesforce Go.
Resultat: Ett definierat pilotomfång producerar aktuella CI utan dubbletter, med spårbara källor och tillräckligt med relationsdata för att stödja påverkananalys.
Använd detta scenario för att välja ett inledande Discovery-omfång, validera de resulterande posterna och avgöra när data är tillförlitliga nog att expandera. Följ de länkade hjälpämnena för detaljerade procedurer för provisionering, installation, inloggningshantering och målkonfiguration.
Innan du börjar
Bekräfta att CMDB och Servicegraf har provisionerats, CMDB och Tillgångsupptäckt har aktiverats och att administratören har rätt åtkomst. Se Konfigurera Discovery med Salesforce Go för aktiveringsprocessen.
Definiera en pålitlig pilot
Börja med en lagerfråga och en avgränsad miljö. Upptäck till exempel arbetsstationer på ett kontor, servrar i ett undernät, fjärrslutpunkter i en pilotgrupp eller valda molnresurser. Ett mindre omfång gör det enklare att upptäcka fel i identifiering, täckning och relationer innan de påverkar den bredare CMDB.
| Pilotbeslut | Frågor | Bevis på beredskap |
|---|---|---|
| CI-omfång | Vilka CI-typer stöder det första operativa användningsfallet? | Obligatoriska typer och attribut finns i CI Type Manager. |
| Discovery-metod | För slutanvändare, kan Microsoft Intune eller Jamf Pro tillhandahålla lagret? För andra tillgångar, behöver du agentlösa skanningar eller slutpunktsagenter? | Den valda källan matchar hur dessa enheter redan hanteras. Intune, Jamf eller den valda skanningsmetoden är berättigad och nåbar. |
| Identitet | Vilka stabila attribut skiljer en CI från en annan? | Identifieringsregler använder värden som serienummer eller MAC-adress. |
| Ägarskap | Vem granskar nyligen upptäckta eller ändrade poster? | En namngiven dataägare kan undersöka undantag och luckor. |
| Framgångsmått | Vad bevisar att piloten är användbar? | Täckning, färskhet, dubblettfrekvens, obligatoriska attribut och fullständighet i relationen har godkännandekriterier. |
Discovery kan fylla i CMDB från källor för nätverk, slutpunkt, virtuellt, moln och hanteringssystem som stöds. För ett första inventering av slutanvändarens enhet, börja med Microsoft Intune eller Jamf Pro. Dessa integreringar hämtar hanterade Windows-, macOS- och mobilenheter från system som kunder redan använder. Använd agentlösa eller agentbaserade skanningar när målet inte är i Intune eller Jamf. Välj endast de metoder som matchar miljön och rättigheterna. Se Upptäck enheter från Microsoft Intune och Upptäck enheter från Jamf Pro. För hur Discovery och CMDB fungerar tillsammans, se Hur CMDB och Discovery fungerar tillsammans för att förbättra tillgångshantering.
Definiera identifieringsregler innan du skalar
Definiera CI-typer och de attribut som piloten behöver innan de litar på skanningsresultaten. Identifieringsregler avgör om inkommande data uppdaterar en befintlig CI eller skapar en ny. Felaktiga eller saknade identifierare kan skapa dubblettposter, uppdatera fel tillgång och försvaga relationer och rapportering.
Använd stabila identifierare som den valda källan tillhandahåller tillförlitligt. Testa representativa tillgångar som är nya, redan kända, bytt namn eller rapporterats av mer än en källa. Bekräfta att upprepade skanningar uppdaterar den avsedda CI istället för att skapa en annan post. Se Identifieringsregler i CMDB för det kanoniska matchningsbeteendet.
Identifiering är inte en allmän källpreferens eller dubblettkopplingsmotor. Om källor inte håller med, undersök källdata och modellbeslut istället för att anta att CMDB automatiskt väljer ett överlevande värde eller kopplar befintliga dubbletter.
Upptäck och validera de första tillgångarna
Välj insamlingsmetod baserat på nåbarhet. Agentlös Discovery använder ett Discovery-program på en Windows-värd, lagrade inloggningsuppgifter, mål, sonder och skanningsjobb. Agentbaserad Discovery utökar täckningen till Windows-, macOS- eller Linux-slutpunkter som inte alltid kan nås genom nätverksskanningar.
Om piloten hanterar bärbara datorer, Mac-datorer eller mobila enheter, skapa ett Intune- eller Jamf Discovery-mål istället för att börja med en nätverksskanning. Intune och Jamf körs genom Salesforce-flödet och en registrerad anslutning. Varje körning skapar eller uppdaterar CI från MDM-lagret. Gå igenom fältmappningar och identifieringsregler innan den första synkroniseringen så att enheter matchar befintliga CI istället för att skapa dubbletter.
För varje mål, håll den inledande omfattningen smal, välj lämpliga inloggningsuppgifter och sond och kör skanningen under teamets säkerhetsrutiner. Mer information om detaljerade installations- och målförfaranden finns i:
- 6528689102808206332821670507601149851513188037Agentlös upptäckt för att skanna IT-tillgångar
- Agentbaserad upptäckt för utökad enhetstäckning
- Upptäck enheter från Microsoft Intune
- Upptäck enheter från Jamf Pro
Granska skanningen som en kontrollpunkt för datakvalitet istället för att behandla slutförande som lyckat. Jämför upptäckta totaler med förväntat lager, inspektera misslyckade upptäckter och granska tillgångar under Alla, Nya och Uppdaterade. Bekräfta att obligatoriska fält är ifyllda och att upprepade skanningar uppdaterar befintliga poster. Se Övervaka och granska skanningsjobb för sektionerna kanonisk skanning och resultat.
Anslut konfigurationsobjekt till en servicevy
Lager blir operativt användbart när team kan förstå beroenden. Discovery skapar eller uppdaterar konfigurationsobjekt. Det skapar inte dessa relationer automatiskt. När skanningen eller MDM-synkroniseringen är klar, öppna Processhanteraren och kör ett Processjobb för att ansluta de upptäckta CI:erna—till exempel ett program som körs på en server eller en arbetsstation som ansluter genom en nätverksenhet. Validera relationsriktning och ta bort länkar som inte representerar den faktiska miljön. Se Processhanterare för att analysera Discovery-data och köra ett processjobb.
Använd Servicegraf för att inspektera anslutningar uppströms och nedströms, bedöma ändringar eller avbrottspåverkan och identifiera länkar som saknas. En graflayout styr vad som visas; den skapar inte relationer som inte är registrerade i CMDB. Se Visualisera konfigurationsobjektrelationer med servicegraf. Använd Servicegraf efter att Processjobb har skrivit de relationer du förväntar dig att se.
Milstolpen för användning inträffar när ett serviceteam kan använda pilotdata för att besvara en praktisk fråga, till exempel vilka system som beror på en server som påverkas. Detta kräver att Processjobb har skapat relationerna, inte bara en slutförd skanning. Ett stort CI-antal utan stabil identitet, aktuella attribut och användbara relationer är lagervolym snarare än CMDB-användning.
Övervaka datakvalitet och utöka Discovery
Registrera en baslinje efter den första framgångsrika skanningen: förväntade tillgångar, upptäckta tillgångar, nya och uppdaterade CI, fel, dubbletter, saknade obligatoriska attribut och validerade relationer. Välj skannings- eller agentintervall som matchar hur snabbt miljön ändras istället för att beskriva alla Discovery-data i realtid.
Utöka till ett annat undernät, slutpunktsgrupp, CI-typ eller källa endast efter att den aktuella piloten uppfyller sina godkännandekriterier. Fortsätt bevaka källaktivitet, första och senaste upptäcktstidsstämplar, CI-historik, skanningsresultat, täckning och färskhet. För den kanoniska Discovery-sekvensen och bearbetningsbeteendet, se Lär dig Discoverys livscykel.
