Helbred din SCOM 2016 vedligeholdelsesfejl

I den komplekse verden af IT-infrastruktur fungerer System Center Operations Manager (SCOM) som et centralnervesystem, der overvåger helbredstilstanden for dine servere og applikationer. Men ligesom ethvert avanceret biologisk system, kan selv SCOM vise tegn på sygdom. Et almindeligt symptom, der har plaget mange administratorer efter opdatering til SCOM 2016 UR1, er en frustrerende fejl, når de forsøger at bruge den nye funktion til planlagt vedligeholdelse. Denne fejl er ikke blot en mindre irritation; den forhindrer en vital funktion, der er designet til at gøre systemadministration mere smidig. I denne artikel vil vi agere som læger for dit system. Vi vil diagnosticere den specifikke fejl, forklare den underliggende årsag og give dig en præcis og effektiv behandlingsplan for at kurere dit SCOM-system og genoprette dets fulde funktionalitet.

Symptomerne: Sådan genkender du sygdommen

Når et system er sygt, viser det symptomer. I tilfældet med SCOM 2016 UR1 er symptomerne meget specifikke og opstår, så snart du navigerer til 'Maintenance Schedules' i Operations Console. Det første tegn er en fejlmeddelelse, der tydeligt indikerer, at noget er galt med tilladelserne:

Dato: 22-10-2016 15:03:32
Applikation: Operations Manager
Applikationsversion: 7.2.11719.0
Alvorlighed: Fejl
Meddelelse:
EXECUTE-tilladelsen blev nægtet for objektet 'sp_help_jobactivity', databasen 'msdb', skemaet 'dbo'.
Datatilgangstjenestekontoen har muligvis ikke de nødvendige tilladelser.

Denne meddelelse er systemets råb om hjælp. Den fortæller os præcist, hvor smerten er lokaliseret: en manglende tilladelse i 'msdb'-databasen, som er SQL Serverens database til håndtering af automatiserede opgaver, kendt som SQL Agent Jobs. Hvis du ignorerer dette første symptom og forsøger at oprette en ny vedligeholdelsesplan, eskalerer tilstanden, og du præsenteres for en endnu mere kryptisk og alvorlig fejlmeddelelse, der indikerer en total afbrydelse af kommunikationen mellem klienten og serveren (Microsoft.EnterpriseManagement.Common.ServerDisconnectedException). Dette svarer til et kommunikationssvigt i kroppens nervesystem – signalerne når simpelthen ikke frem.

Diagnosen: Hvorfor opstår problemet?

En korrekt diagnose er afgørende for en effektiv behandling. Årsagen til denne specifikke SCOM-sygdom ligger i en utilstrækkelig konfiguration af tilladelser for SCOM's Data Access Service (DAS) konto. Tænk på DAS-kontoen som en specialiseret sygeplejerske, der har brug for adgang til forskellige dele af hospitalet (din SQL-server) for at udføre sine opgaver. Da SCOM 2016 UR1's nye vedligeholdelsesfunktion er tæt integreret med SQL Server Agent til at planlægge og udføre opgaver, skal DAS-kontoen have udvidede rettigheder til at interagere med SQL Agent. Specifikt skal den kunne læse og administrere jobaktivitet i 'msdb'-databasen.

Når du installerer eller opgraderer SCOM, tildeles denne specifikke adgang ikke automatisk. Systemet er derfor i en tilstand, hvor det forsøger at udføre en handling, det ikke har fået lov til. Fejlmeddelelsen om 'EXECUTE permission was denied' er SQL-serverens måde at sige 'Adgang nægtet' på. Uden de korrekte 'adgangskort' kan DAS-kontoen ikke udføre de nødvendige procedurer for at oprette og administrere vedligeholdelsesplaner, hvilket resulterer i de fejl, du oplever.

Behandlingen: En trin-for-trin guide til helbredelse

Nu hvor vi har stillet diagnosen, er det tid til at administrere medicinen. Behandlingen er en kirurgisk præcis justering af tilladelser i SQL Management Studio. Følg disse trin nøje for at kurere dit system. Det er en engangsbehandling, der permanent vil løse problemet.

1. Åbn operationsstuen: Start SQL Server Management Studio (SSMS) og opret forbindelse til den SQL-serverinstans, der hoster din SCOM-database.
2. Find patientjournalen: I Object Explorer skal du navigere ned gennem træstrukturen. Udvid mappen 'Security' og derefter mappen 'Logins'.
3. Identificer den rigtige konto: Gennemse listen over logins for at finde den konto, du bruger til SCOM Data Access Service (ofte kaldet SDK/DAS-kontoen).
4. Forbered indgrebet: Højreklik på DAS-kontoen og vælg 'Properties' fra menuen. Dette åbner et nyt vindue med kontoens egenskaber.
5. Vælg det korrekte operationsområde: I vinduet 'Login Properties' skal du vælge siden 'User Mapping' i venstre panel. Dette viser en liste over alle databaser på serveren.
6. Tildel adgang til MSDB: Find 'msdb'-databasen på listen i den øverste rude, og sæt et flueben i boksen ud for den. Dette 'mapper' brugeren til databasen.
7. Administrer den nødvendige medicin: Når 'msdb' er valgt, vil den nederste rude ('Database role membership for: msdb') blive aktiv. Her skal du tildele de specifikke roller, som DAS-kontoen har brug for. Sæt flueben ved følgende tre roller:
   • SQLAgentOperatorRole
   • SQLAgentReaderRole
   • SQLAgentUserRole
8. Afslut proceduren: Klik på 'OK' for at gemme ændringerne. Tilladelserne anvendes øjeblikkeligt.

Efter at have fulgt denne procedure, kan du vende tilbage til SCOM Operations Console. Luk og genåbn den for en sikkerheds skyld. Når du nu navigerer til 'Maintenance Schedules', vil fejlen være forsvundet, og du vil kunne oprette og administrere dine vedligeholdelsesplaner som forventet. Dit system er nu helbredt.

Forståelse af 'medicinen': Hvad gør disse SQL-roller?

For at give en dybere forståelse for behandlingen, er det værd at vide, hvad de tre tildelte roller rent faktisk gør. Hver rolle giver et specifikt sæt af tilladelser, der tilsammen giver den nødvendige funktionalitet.

• SQLAgentUserRole: Dette er den mest basale rolle. Den giver kontoen tilladelse til kun at se de SQL Agent-jobs, som den selv ejer. Det er et fundamentalt adgangsniveau.
• SQLAgentReaderRole: Denne rolle udvider adgangen betydeligt. Den giver læseadgang til alle SQL Agent-jobs og deres egenskaber, selv dem, der ejes af andre brugere. Dette er afgørende for, at SCOM kan få et overblik over planlagte opgaver.
• SQLAgentOperatorRole: Dette er den mest kraftfulde af de tre roller. Ud over alt, hvad de to andre roller giver, tillader denne rolle også kontoen at se jobhistorik og at aktivere eller deaktivere jobs. Evnen til at aktivere og deaktivere jobs er kernen i, hvordan SCOM's vedligeholdelsesplaner fungerer, da SCOM opretter et SQL Agent-job for hver tidsplan.

Ved at tildele disse tre roller sikrer du, at SCOM's DAS-konto har præcis de rettigheder, den behøver for at administrere hele livscyklussen for vedligeholdelsesjobs uden at give unødvendigt brede administrative rettigheder på SQL-serveren.

Sammenligningstabel: Systemets helbred før og efter behandling

For at visualisere effekten af vores behandling, er her en simpel sammenligning af systemets tilstand.

Ofte Stillede Spørgsmål (FAQ)

Gælder denne løsning for andre versioner af SCOM?

Denne specifikke fejl og løsning er primært dokumenteret for SCOM 2016 med Update Rollup 1 (UR1). Dog kan lignende tilladelsesbaserede problemer opstå i andre SCOM-versioner, der interagerer med SQL. Princippet om at sikre, at servicekonti har de korrekte database-tilladelser, er universelt gældende.

Er det sikkert at tildele disse roller til min DAS-konto?

Ja, det er helt sikkert. Disse roller er designet af Microsoft til netop dette formål. De giver granulær kontrol over SQL Agent-funktionalitet og er begrænset til MSDB-databasen. Du tildeler ikke fulde systemadministratorrettigheder, men kun de specifikke tilladelser, der er nødvendige for, at funktionen virker korrekt.

Hvad gør jeg, hvis jeg ikke kan finde min DAS-konto i SQL Logins?

Hvis kontoen ikke vises, kan det skyldes, at den er en del af en Windows-gruppe, der har fået adgang. I så fald skal du give tilladelserne til den pågældende Windows-gruppe. For at verificere, hvilken konto der bruges, kan du åbne 'Services' på din SCOM Management Server og finde tjenesten 'System Center Data Access Service'. Den konto, der er angivet under 'Log On As', er den, du skal konfigurere i SQL.

Jeg har fulgt guiden, men fejlen vedvarer. Hvad nu?

Dobbelttjek først, at du har anvendt tilladelserne på den korrekte SQL-server og til den korrekte konto. Genstart SCOM Data Access Service og SCOM Console for at sikre, at ændringerne er trådt i kraft. Hvis problemet fortsætter, kan der være andre underliggende konfigurationsproblemer, og det kan være nødvendigt at undersøge SCOM's event logs for yderligere diagnostiske spor.