Planlægning af Power BI-implementering: Overvågning på lejerniveau

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

Denne artikel om overvågning på lejerniveau er primært rettet mod:

• Power BI-administratorer: De administratorer, der er ansvarlige for at styre Power BI i organisationen. Power BI-administratorer skal muligvis samarbejde med it, sikkerhed, intern overvågning og andre relevante teams.
• Center of Excellence, IT og BI-teamet: De teams, der også er ansvarlige for at lede Power BI. De skal muligvis samarbejde med Power BI-administratorer og andre relevante teams.

Vigtigt

Vi anbefaler, at du følger Power BI-udgivelsesplanen nøje for at få mere at vide om fremtidige forbedringer af overvågnings- og overvågningsfunktionerne.

Formålet med en overvågningsløsning på lejerniveau er at registrere og analysere data for alle brugere, aktiviteter og løsninger, der er udrullet i en Power BI-lejer. Disse overvågningsdata på lejerniveau er værdifulde til mange formål, så du kan analysere indføringsindsatsen, forstå forbrugsmønstre, uddanne brugere, understøtte brugere, afhjælpe risici, forbedre overholdelse af angivne standarder, administrere licensomkostninger og overvåge ydeevnen.

Oprettelse af en end-to-end-overvågningsløsning, der er sikker og klar til produktion, er et betydeligt projekt, der tager tid. Tænk på det som at bygge business intelligence på business intelligence (BI på BI). Du kan finde oplysninger om, hvorfor overvågningsdataene er så værdifulde, under Oversigt over overvågning og overvågning.

Du kan se overvågning på rapportniveau, som er målrettet til rapportoprettere, under Overvågning på rapportniveau.

Du kan se overvågningsdataaktiver, som er målrettet til dataoprettere, under Overvågning på dataniveau.

I resten af denne artikel fokuseres der på overvågning på lejerniveau.

Tip

Det primære fokus i denne artikel er at hjælpe dig med at planlægge at oprette en komplette overvågningsløsning. Da indholdet i denne artikel er organiseret i fire faser, skal du bruge oplysninger på tværs af flere faser. Du kan f.eks. finde oplysninger i fase 1 om, hvordan du planlægger at bruge en tjenesteprincipal, og oplysninger i fase 2 om forudsætninger og konfiguration.

Derfor anbefaler vi, at du læser hele denne artikel først, så du er bekendt med, hvad der er involveret. Derefter skal du være velforberedt til at planlægge og bygge din overvågningsløsning på en iterativ måde.

Når du planlægger at oprette en overvågningsløsning på lejerniveau, skal du planlægge at bruge tid på følgende fire faser.

• Fase 1: Planlægning og beslutninger
  • Krav og prioriteter
  • Databehov
  • Type af overvågningsløsning
  • Tilladelser og ansvarsområder
  • Tekniske beslutninger
  • Beslutninger om datakilder
• Fase 2: Forudsætninger og konfiguration
  • Opret lagerkonto
  • Installér software, og konfigurer tjenester
  • Registrer et Microsoft Entra-program
  • Angiv lejerindstillinger for Fabric
• Fase 3: Løsningsudvikling og analyse
  • Udtræk og gem rådata
  • Opret de udvalgte data
  • Opret en datamodel
  • Optimer datamodellen
  • Opret analyserapporter
  • Udfør en handling baseret på dataene
• Fase 4: Vedligehold, optimer og overvåg
  • Driftsklargør og gør det bedre
  • Dokumentation og support
  • Aktivér beskeder
  • Løbende administration

Fase 1: Planlægning og beslutninger

I den første fase fokuseres der på planlægning og beslutningstagning. Der er mange krav og prioriteter at overveje, så vi anbefaler, at du bruger tilstrækkelig tid til at forstå de emner, der er introduceret i dette afsnit. Målet er at træffe gode beslutninger på forhånd, så downstreamfaserne kører problemfrit.

Krav og prioriteter

I den indledende fase er målet at identificere, hvad der er vigtigst. Fokuser på det, der betyder mest, og hvordan du vil måle indvirkningen i din organisation. Tilstræb at definere forretningsorienterede krav i stedet for teknologiorienterede krav.

Her er nogle spørgsmål, du skal besvare.

• Hvilke vigtige spørgsmål har du brug for at besvare? Der er en stor mængde overvågningsdata, du kan udforske. Den mest effektive måde at gribe revision an på er at fokusere på at besvare specifikke spørgsmål.
• Hvad er dine mål for indføring og datakultur ? Måske har du f.eks. et mål om at øge antallet af selvbetjente BI-indholdsforfattere i organisationen. I så fald skal du måle brugeraktiviteter, der er relateret til oprettelse, redigering og publicering af indhold.
• Hvilke øjeblikkelige risici er der? Du ved f.eks., at der tidligere er sket overdeling af indhold. Brugertræningen er siden blevet forbedret, og du vil nu løbende overvåge sikkerhedsindstillinger og -aktiviteter.
• Er der aktuelle KPI'er (Key Performance Indicators) eller organisationsmål? Måske har du f.eks. en organisations-KPI, der er relateret til digital transformation eller bliver en mere datadrevet organisation. Overvågningsdata på lejerniveau kan hjælpe dig med at måle, om din Power BI-implementering er justeret i forhold til disse mål.

Tip

Kontrollér overvågningskrav, og angiv prioriteter med din chefsponsor og Center of Excellence. Det er fristende at udtrække overvågningsdata og begynde at oprette rapporter baseret på en masse interessante data. Det er dog usandsynligt, at du får høj værdi af din overvågningsløsning, når den ikke er baseret på spørgsmål, du har brug for at besvare, og handlinger, du vil udføre.

Du kan finde flere idéer til, hvordan du kan bruge overvågningsdata, under Oversigt over overvågning og overvågning.

Tjekliste – Når du identificerer krav og prioriteter, omfatter vigtige beslutninger og handlinger:

• Identificer krav: Indsaml og dokumenter de vigtigste forretningskrav til overvågning af din Power BI-lejer.
• Prioriter krav: Angiv prioriteter for kravene, og klassificer dem som øjeblikkelige, kortsigtede, mellemsigtede og langsigtede (efterslæb).
• Lav en plan for de øjeblikkelige prioriteter: Placer en plan for at begynde at indsamle data, så den er tilgængelig, når du har brug for det.
• Reassess krav regelmæssigt: Opret en plan for at revurdere kravene regelmæssigt (f.eks. to gange om året). Kontrollér, om overvågnings- og overvågningsløsningen opfylder de angivne krav. Opdater handlingselementer i din plan efter behov.

Databehov

Når du har defineret kravene og prioriteterne (beskrevet tidligere), er du klar til at identificere de data, du skal bruge. I dette afsnit beskrives fire kategorier af data.

• Brugeraktivitetsdata
• Lejerlager
• Data for brugere og grupper
• Sikkerhedsdata

De fleste af de data, du skal bruge, kommer fra administrator-API'erne, som indeholder et væld af metadata om Power BI-lejeren. Du kan få flere oplysninger under Vælg en bruger-API eller administrations-API senere i denne artikel.

Brugeraktivitetsdata

Gør det til din første prioritet at hente data om brugeraktiviteter. Brugeraktiviteterne, som også kaldes hændelser eller handlinger, er nyttige til en lang række formål.

Disse data kaldes oftest aktivitetsloggen eller hændelsesloggen. Teknisk set er der flere måder at hente brugeraktivitetsdata på (aktivitetsloggen er én metode). Du kan få flere oplysninger om de involverede beslutninger og aktiviteter under Få adgang til brugeraktivitetsdata senere i denne artikel.

Her er nogle almindelige spørgsmål, som brugeraktivitetsdata kan besvare.

• Find de mest populære brugere og det mest populære indhold
  • Hvilket indhold vises oftest, og af hvilke brugere?
  • Hvad er de daglige, ugentlige og månedlige tendenser for visning af indhold?
  • Er rapportvisninger stigende eller nedad?
  • Hvor mange brugere er aktive?
• Om brugeradfærd
  • Hvilken type sikkerhed bruges oftest (apps, arbejdsområder eller deling pr. element)?
  • Bruger brugerne oftest browsere eller mobilapps?
  • Hvilke indholdsforfattere publicerer og opdaterer mest indhold?
  • Hvilket indhold publiceres eller opdateres, hvornår og af hvilke brugere?
• Identificer brugeruddannelses- og uddannelsesmuligheder
  • Hvem deler (for meget) fra deres personlige arbejdsområde?
  • Hvem eksporterer en betydelig mængde?
  • Hvem downloader regelmæssigt indhold?
  • Hvem udgiver mange nye semantiske modeller?
  • Hvem bruger abonnementer meget?
• Gør styringen og overholdelse af angivne standarder bedre
  • Hvornår ændres lejerindstillingerne, og af hvilken Power BI-administrator?
  • Hvem startede en Power BI-prøveversion?
  • Hvilket indhold tilgås af eksterne brugere, hvem, hvornår og hvordan?
  • Hvem har tilføjet eller opdateret en følsomhedsmærkat?
  • Hvilken procentdel af rapportvisninger er baseret på certificerede semantiske modeller?
  • Hvilken procentdel af semantiske modeller understøtter mere end én rapport?
  • Hvornår oprettes eller opdateres en gateway eller datakilde, og af hvilken bruger?

Du kan finde flere oplysninger om, hvordan du bruger disse data, under Forstå forbrugsmønstre.

Vigtigt

Hvis du ikke allerede udtrækker og gemmer data om brugeraktiviteter, skal du gøre det til en presserende prioritet. Sørg som minimum for at udtrække rådata og gemme dem et sikkert sted. På den måde vil dataene være tilgængelige, når du er klar til at analysere dem. Historikken er tilgængelig i 30 dage eller 90 dage, afhængigt af den kilde du bruger.

Du kan få flere oplysninger under Få adgang til brugeraktivitetsdata senere i denne artikel.

Lejerlager

Den anden prioritet er ofte at hente dataene for at oprette et lejerlager. Nogle gange kaldes det arbejdsområdeoversigt, arbejdsområdemetadata eller lejermetadata.

En lejeroversigt er et snapshot på et givet tidspunkt. Den beskriver, hvad der er publiceret i lejeren. Lejerlageret indeholder ikke de faktiske data eller de faktiske rapporter. Det er snarere metadata, der beskriver alle arbejdsområder og deres elementer (f.eks. semantiske modeller og rapporter).

Her er nogle almindelige spørgsmål, som lejerlageret kan besvare.

• Forstå, hvor meget indhold du har, og hvor
  • Hvilke arbejdsområder har mest indhold?
  • Hvilken type indhold publiceres i hvert arbejdsområde (især når du adskiller rapporteringsarbejdsområder og dataarbejdsområder)?
  • Hvilke afhængigheder findes der mellem elementer (f.eks. dataflow, der understøtter mange semantiske modeller, eller en semantisk model, der er en kilde til andre sammensatte modeller)?
  • Hvad er dataafstamningen (afhængigheder mellem Power BI-elementer, herunder eksterne datakilder)?
  • Er der tabte rapporter (som er afbrudt fra deres semantiske model)?
• Forstå forholdet mellem semantiske modeller og rapporter
  • Hvor meget genbrug af semantiske modeller sker?
  • Er der identiske eller meget lignende semantiske modeller?
  • Er der mulighed for at konsolidere semantiske modeller?
• Forstå tendenser mellem punkter i tiden
  • Stiger antallet af rapporter over tid?
  • Stiger antallet af semantiske modeller over tid?
• Find ubrugt indhold
  • Hvilke rapporter er ubrugte (eller underudnyttede)?
  • Hvilke semantiske modeller bruges ikke (eller underudnyttes)?
  • Er der mulighed for at trække indhold tilbage?

En lejeroversigt hjælper dig med at bruge aktuelle navne, når du analyserer historiske aktiviteter. Snapshottet af elementerne i din lejer indeholder navnene på alle elementer på det pågældende tidspunkt. Det er nyttigt at bruge aktuelle elementnavne til historisk rapportering. Hvis en rapport f.eks. blev omdøbt for tre måneder siden, registrerer aktivitetsloggen på det pågældende tidspunkt det gamle rapportnavn. Med en korrekt defineret datamodel kan du bruge det seneste lejerlager til at finde et element ved hjælp af dets aktuelle navn (i stedet for det tidligere navn). Du kan få flere oplysninger under Opret en datamodel senere i denne artikel.

Du kan finde flere oplysninger om, hvordan du bruger en lejeroversigt, under Forstå publiceret indhold.

Tip

Du skal ofte bruge kombiner brugeraktivitetshændelser (beskrevet i forrige afsnit) og lejeroversigten til at oprette et komplet billede. På den måde forbedrer du værdien af alle dataene.

Da en lejeroversigt er et snapshot på et givet tidspunkt, skal du beslutte, hvor ofte metadataene skal udtrækkes og gemmes. Et ugentligt snapshot er nyttigt til at foretage sammenligninger mellem de to punkter i tiden. Hvis du f.eks. vil undersøge sikkerhedsindstillingerne for et arbejdsområde, skal du bruge det forrige øjebliksbillede af lejerlageret, hændelserne i aktivitetsloggen og det aktuelle øjebliksbillede af lejerlageret.

Der er to primære måder at oprette en lejeroversigt på. Du kan få flere oplysninger om de involverede beslutninger og aktiviteter under Få adgang til lejerens lagerdata senere i denne artikel.

Data for brugere og grupper

I takt med at dine analysebehov vokser, vil du sandsynligvis finde ud af, at du gerne vil inkludere data om brugere og grupper i din komplette overvågningsløsning. Hvis du vil hente disse data, kan du bruge Microsoft Graph, som er den autoritative kilde til oplysninger om Brugere og grupper af Microsoft Entra-id'er.

Data, der hentes fra REST API'erne til Power BI, indeholder en mailadresse, der beskriver brugeren eller navnet på en sikkerhedsgruppe. Disse data er et snapshot på et givet tidspunkt.

Her er nogle almindelige spørgsmål, som Microsoft Graph kan besvare.

• Identificer brugere og grupper
  • Hvad er det fulde brugernavn (ud over mailadressen), afdelingen eller placeringen, der stammer fra deres brugerprofil?
  • Hvem er medlemmer af en sikkerhedsgruppe?
  • Hvem er ejer af en sikkerhedsgruppe (til administration af medlemmer)?
• Hent yderligere brugeroplysninger
  • Hvilke licenser – Power BI Pro eller Power BI Premium pr. bruger – tildeles til brugere?
  • Hvilke brugere logger oftest på?
  • Hvilke brugere har ikke logget på Power BI-tjeneste for nylig?

Advarsel!

Nogle ældre metoder (som er grundigt dokumenteret online) til at få adgang til bruger- og gruppedata frarådes og bør ikke bruges. Når det er muligt, skal du bruge Microsoft Graph som den autoritative kilde til brugere og grupper af data.

Du kan få flere oplysninger og anbefalinger til, hvordan du får adgang til data fra Microsoft Graph, under Få adgang til brugerdata og grupper data senere i denne artikel.

Sikkerhedsdata

Du har muligvis et krav om at udføre almindelige sikkerhedsovervågninger.

Her er nogle almindelige spørgsmål, som REST API'erne til Power BI kan besvare.

• Identificer personer og programmer
  • Hvilke rapporter har en bruger, gruppe eller tjenesteprincipal adgang til?
  • Hvilke brugere, grupper eller tjenesteprincipaler er abonnenter, der modtager rapporter med et mailabonnement?
• Forstå indholdstilladelser
  • Hvilke arbejdsområderoller tildeles til hvilke brugere og grupper?
  • Hvilke brugere og grupper tildeles til hver Power BI-appmålgruppe?
  • Hvilke tilladelser pr. element tildeles, hvilke rapporter og for hvilke brugere?
  • Hvilke tilladelser pr. element tildeles, for hvilke semantiske modeller og for hvilke brugere?
  • Hvilke semantiske modeller og datamarts har defineret sikkerhed på rækkeniveau?
  • Hvilke elementer deles med personer i hele organisationen?
  • Hvilke elementer publiceres offentligt på internettet?
• Forstå andre tilladelser
  • Hvem har tilladelse til at publicere ved hjælp af en udrulningspipeline?
  • Hvem har tilladelse til at administrere gateways og dataforbindelser?
  • Hvem har tilladelse til at administrere en Premium-kapacitet?

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

Tip

Du kan få flere overvejelser om sikkerhed i artiklerne om sikkerhedsplanlægning .

Disse almindelige spørgsmål er ikke en udtømmende liste. der er en lang række tilgængelige Power BI REST API'er. Du kan få flere oplysninger under Brug af REST API'er til Power BI.

Du kan få flere oplysninger om brug af administrator-API'er i forhold til bruger-API'er (herunder hvordan det påvirker tilladelser, der kræves for den bruger, der udtrækker dataene), under Vælg en bruger-API eller en administrations-API senere i denne artikel.

Tjekliste – Når du identificerer de data, der er nødvendige for overvågning, omfatter vigtige beslutninger og handlinger:

• Identificer specifikke databehov for brugeraktivitetsdata: Valider de krav, du har indsamlet. Identificer, hvilke overvågningsdata der er nødvendige for at opfylde hvert krav til brugeraktivitetsdata.
• Identificer specifikke databehov for lejerens lagerdata: Valider de krav, du har indsamlet. Identificer, hvilke overvågningsdata der er nødvendige for at kompilere en lejeroversigt.
• Identificer specifikke databehov for brugere og grupper af data: Valider de krav, du har indsamlet. Identificer, hvilke overvågningsdata der er nødvendige for at opfylde hvert krav for brugere og grupper af data.
• Identificer specifikke databehov for sikkerhedsdata: Valider de krav, du har indsamlet. Identificer, hvilke overvågningsdata der er nødvendige for at opfylde hvert krav til sikkerhedsdata.
• Kontrollér prioriteter: Kontrollér rækkefølgen af prioriteter, så du ved, hvad du skal udvikle først.
• Beslut, hvor ofte du vil registrere aktiviteter: Beslut, hvor ofte du vil registrere aktivitetshændelser (f.eks. én gang om dagen).
• Beslut, hvor ofte du vil hente snapshots: Beslut, hvilket interval der skal registreres snapshotdata, f.eks. en lejeroversigt eller data for brugere og grupper.

Type af overvågningsløsning

Overvågning på lejerniveau udføres enten manuelt eller med automatiserede processer.

De fleste nye overvågningsprocesser starter som en manuel proces, især under udvikling, og mens der udføres test. En manuel overvågningsproces kan udvikle sig til en automatiseret proces. Det er dog ikke alle overvågningsprocesser, der skal automatiseres fuldt ud.

Manuelle overvågningsprocesser

Manuel overvågning er afhængig af scripts og processer, der køres efter behov af en bruger (normalt en Power BI-administrator). Når det er nødvendigt, kører brugeren forespørgsler interaktivt for at hente overvågningsdata.

Manuel overvågning er bedst egnet til:

• Nye scripts, der udvikles og testes.
• Lejlighedsvise engangsrevisionsbehov.
• Sonderende revisionsbehov.
• Uvæsentlige overvågningsprocesser, der ikke kræver fuld support.

Automatiserede overvågningsprocesser

Overvågningsdata, der er nødvendige på tilbagevendende basis, skal automatiseres. Den udtrækkes og behandles efter en almindelig tidsplan, og den kaldes en automatiseret proces. Nogle gange kaldes det en automatisk proces.

Målene for en automatiseret proces er at reducere manuel indsats, reducere risikoen for fejl, øge konsistensen og fjerne afhængigheden af en individuel bruger for at køre den.

Automatiseret overvågning er bedst egnet til:

• Overvågningsprocesser, der kører i produktion.
• Automatiske processer, der kører efter en almindelig tidsplan.
• Scripts, der er fuldt testet.
• Vigtige overvågningsprocesser, der har andre rapporter (eller andre processer), der er afhængige af dem som datakilde.
• Overvågningsprocesser, der er dokumenteret og understøttet.

Procestypen – manuel eller automatiseret – kan påvirke den måde, du håndterer godkendelse på. En Power BI-administrator kan f.eks. bruge brugergodkendelse til en manuel overvågningsproces, men bruge en tjenesteprincipal til en automatiseret proces. Du kan finde flere oplysninger under Bestem godkendelsesmetoden senere i denne artikel.

Tip

Hvis der er et regelmæssigt tilbagevendende behov for at hente overvågningsdata, der i øjeblikket håndteres manuelt, kan du overveje at investere tid til at automatisere dem. Hvis en Power BI-administrator f.eks. kører et script manuelt hver dag for at hente data fra Power BI-aktivitetsloggen, er der risiko for manglende data, hvis den pågældende person er syg eller væk på ferie.

Tjekliste – Når du overvejer, hvilken type overvågningsløsning der skal udvikles, omfatter vigtige beslutninger og handlinger:

• Fastlæg det primære formål for hvert nyt overvågningskrav: Beslut, om du vil bruge en manuel eller automatiseret proces for hvert nyt krav. Overvej, om denne afgørelse er midlertidig eller permanent.
• Opret en plan for, hvordan du automatiserer: Når det er relevant for et bestemt overvågningskrav, skal du oprette en plan for, hvordan du automatiserer den, hvornår og af hvem.

Tilladelser og ansvarsområder

På dette tidspunkt skal du have en klar ide om, hvad du vil opnå, og hvilke data du skal bruge til at starte med. Nu er det et godt tidspunkt at træffe beslutninger om brugertilladelser samt roller og ansvar.

Brugertilladelser

Når du planlægger at oprette en overvågningsløsning fra ende til anden, skal du overveje brugertilladelser til andre brugere, der skal have adgang til dataene. Beslut specifikt, hvem der skal have tilladelse til at få adgang til og få vist overvågningsdata.

Her er nogle overvejelser, der skal tages hensyn til.

Direkte adgang til overvågningsdata

Du skal beslutte, hvem der kan få direkte adgang til overvågningsdataene. Der er flere måder at tænke over det på.

• Hvem skal være Power BI-administrator? En Power BI-administrator har adgang til alle lejermetadata, herunder administrator-API'er. Du kan finde flere oplysninger om, hvem der skal være Power BI-administrator, under Planlægning af sikkerhed på lejerniveau.
• Hvem kan bruge en eksisterende tjenesteprincipal? Hvis du vil bruge en tjenesteprincipal (i stedet for brugertilladelser) til at få adgang til overvågningsdata, skal der angives en hemmelighed for godkendte brugere, så de kan udføre adgangskodebaseret godkendelse. Adgang til hemmeligheder (og nøgler) bør være meget stramt kontrolleret.
• Skal adgangen kontrolleres nøje? Visse brancher med lovgivnings- og overholdelseskrav skal kontrollere adgangen mere stramt end andre brancher.
• Er der store aktivitetsdatamængder? Hvis du vil undgå at nå api-begrænsningsgrænser, skal du muligvis nøje styre, hvem der har tilladelse til at få direkte adgang til de API'er, der producerer overvågningsdata. I dette tilfælde er det nyttigt at sikre, at der ikke er dubletter eller overlappende bestræbelser.

Adgang til udtrukne rådata

Du skal beslutte, hvem der kan få vist de rå data, der udtrækkes og skrives til en lagerplacering. Adgangen til rådata er oftest begrænset til administratorer og revisorer. COE (Center of Excellence) kan også kræve adgang. Du kan finde flere oplysninger under Find ud af, hvor overvågningsdata skal gemmes senere i denne artikel.

Adgang til organiserede analysedata

Du bør beslutte, hvem der kan få vist de organiserede og transformerede data, der er klar til analyse. Disse data skal altid være tilgængelige for administratorer og revisorer. Nogle gange gøres en datamodel tilgængelig for andre brugere i organisationen, især når du opretter en semantisk Power BI-model med sikkerhed på rækkeniveau. Du kan få flere oplysninger under Planlæg oprettelse af udvalgte data senere i denne artikel.

Roller og ansvarsområder

Når du har besluttet, hvordan brugertilladelser fungerer, er du i en god position til at begynde at tænke på roller og ansvarsområder. Vi anbefaler, at du involverer de rette personer tidligt, især når flere udviklere eller teams vil være involveret i at bygge overvågningsløsningen fra ende til anden.

Beslut, hvilke brugere eller team der skal være ansvarlige for følgende aktiviteter.

Rolle	Typer af ansvarsområder	Rolle, der typisk udføres af
Kommuniker til interessenter	Kommunikationsaktiviteter og kravindsamling.	COE i partnerskab med it. Kan også omfatte udvalgte personer fra vigtige forretningsenheder.
Beslut prioriteter, og angiv retningen for krav	Beslutningstagningsaktiviteter, der er relateret til overvågningsløsningen fra ende til anden, herunder hvordan du opfylder kravene.	Det team, der styrer Power BI i organisationen, f.eks. COE. Ledelsessponsoren eller en styringskomité for datastyring kan blive involveret for at træffe vigtige beslutninger eller eskalere problemer.
Udtræk og gem rådata	Oprettelse af scripts og processer for at få adgang til og udtrække dataene. Omfatter også skrivning af rådata til lager.	Datateknikere, normalt i it og i partnerskab med COE.
Opret de udvalgte data	Datarensning, transformation og oprettelse af de udvalgte data i design af stjerneskemaer.	Datateknikere, normalt i it og i partnerskab med COE.
Opret en datamodel	Oprettelse af en analysedatamodel baseret på de udvalgte data.	Power BI-indholdsoprettere, normalt i IT eller COE.
Opret analyserapporter	Oprettelse af rapporter til analyse af de udvalgte data. Løbende ændringer af rapporter baseret på nye krav, og når nye overvågningsdata bliver tilgængelige.	Power BI-rapportoprettere, normalt i it- eller COE-filen.
Analysér dataene, og udvis resultaterne	Analysér dataene, og handle som svar på overvågningsdataene.	Det team, der styrer Power BI i organisationen, normalt COE. Kan også omfatte andre teams, afhængigt af overvågningsresultaterne og handlingen. Andre teams kan omfatte sikkerhed, overholdelse af angivne standarder, juridisk, risikostyring eller ændringsstyring.
Teste og validere	Test for at sikre, at overvågningskravene er opfyldt, og at de viste data er nøjagtige.	Power BI-indholdsoprettere i partnerskab med det team, der kontrollerer Power BI i organisationen.
Beskyt dataene	Angiv og administrer sikkerheden for hvert lagerlag, herunder rådata og de organiserede data. Administrer adgang til semantiske modeller, der oprettes til analyse af dataene.	Systemadministrator for det system, der gemmer dataene, i partnerskab med det team, der kontrollerer Power BI i organisationen.
Planlægning og automatisering	Operationaliser en løsning, og planlæg processen med det valgte værktøj.	Datateknikere, normalt i it og i partnerskab med COE.
Understøtter løsningen	Overvåg overvågningsløsningen, herunder jobkørsler, fejl og support til tekniske problemer.	Det team, der håndterer understøttelse af Power BI-systemet, som normalt er it eller COE.

Mange af ovenstående roller og ansvarsområder kan konsolideres, hvis de skal udføres af det samme team eller den samme person. Dine Power BI-administratorer kan f.eks. udføre nogle af disse roller.

Det er også muligt, at forskellige personer udfører forskellige roller, afhængigt af omstændighederne. Handlingerne vil være kontekstafhængige, afhængigt af overvågningsdataene og den foreslåede handling.

Overvej flere eksempler.

• eksempel 1: Overvågningsdataene viser, at nogle brugere ofte eksporterer data til Excel. Handling udført: COE kontakter de specifikke brugere for at forstå deres behov og lære dem bedre alternativer.
• eksempel 2: Overvågningsdataene viser, at der opstår uventet adgang til eksterne brugere. Udførte handlinger: En it-systemadministrator opdaterer de relevante indstillinger for Microsoft Entra ID for ekstern brugeradgang. Power BI-administratoren opdaterer lejerindstillingen, der er relateret til ekstern brugeradgang. COE opdaterer dokumentation og oplæring for indholdsoprettere, der administrerer sikkerhed. Du kan få flere oplysninger under Strategi for eksterne brugere.
• eksempel 3: Overvågningsdataene viser, at flere datamodeller definerer den samme måling forskelligt (tilgængelig fra api'erne til metadatascanning, hvis de er tilladt af de detaljerede lejerindstillinger for metadata). Handling udført: Datastyringsudvalget starter et projekt for at definere fælles definitioner. COE opdaterer dokumentation og oplæring for indholdsoprettere, der opretter datamodeller. COE arbejder også sammen med indholdsforfattere om at opdatere deres modeller efter behov. Du kan finde flere oplysninger om hentning af detaljerede metadata i Få adgang til lejerens lagerdata senere i denne artikel.

Bemærk

Konfigurationen af dataudtrækningsprocesser er normalt en engangsindsats med lejlighedsvise forbedringer og fejlfinding. Det er en løbende indsats at analysere og reagere på dataene, der kræver en løbende indsats på tilbagevendende basis.

Tjekliste – Når du overvejer tilladelser og ansvarsområder, omfatter vigtige beslutninger og handlinger:

• Identificer, hvilke teams der er involveret: Find ud af, hvilke teams der skal involveres i oprettelse og support af overvågningsløsningen fra ende til anden.
• Beslut brugertilladelser: Bestem, hvordan brugertilladelser skal konfigureres til at få adgang til overvågningsdata. Opret dokumentation for vigtige beslutninger til senere reference.
• Beslut roller og ansvarsområder: Sørg for, at der er klare forventninger til, hvem der gør hvad, især når der er flere teams involveret. Opret dokumentation til roller og ansvarsområder, som omfatter forventede handlinger.
• Tildel roller og ansvarsområder: Tildel bestemte roller og ansvarsområder til bestemte personer eller teams. Opdater individuelle jobbeskrivelser med HR, når det er relevant.
• Opret en uddannelsesplan: Opret en plan for oplæring af personale, når de har brug for nye færdigheder.
• Opret en plan for tværgående oplæring: Sørg for, at der findes tværgående oplæring og sikkerhedskopier for nøgleroller.

Tekniske beslutninger

Når du planlægger en overvågningsløsning på lejerniveau, skal du træffe nogle vigtige tekniske beslutninger. For at forbedre konsistensen, undgå omarbejde og forbedre sikkerheden anbefaler vi, at du træffer disse beslutninger så tidligt som muligt.

Den første planlægningsfase omfatter følgende beslutninger.

• Vælg en teknologi for at få adgang til overvågningsdata
• Bestem godkendelsesmetoden
• Vælg en bruger-API eller administrations-API
• Vælg API'er eller PowerShell-cmdlet'er
• Find ud af, hvor overvågningsdata skal gemmes
• Planlæg at oprette udvalgte data

Vælg en teknologi for at få adgang til overvågningsdata

Det første, du skal beslutte, er , hvordan du får adgang til overvågningsdataene.

Den nemmeste måde at komme i gang på er ved at bruge de færdigbyggede rapporter, der er tilgængelige i administrationsovervågningsarbejdsområdet.

Når du har brug for at få direkte adgang til dataene og oprette din egen løsning, skal du bruge en API (programgrænseflade). API'er er designet til at udveksle data via internettet. Rest-API'erne til Power BI understøtter anmodninger om data ved hjælp af HTTP-protokollen. Et hvilket som helst sprog eller værktøj kan aktivere Power BI REST API'er, når det er i stand til at sende en HTTP-anmodning og modtage et JSON-svar.

Tip

PowerShell-cmdlet'erne bruger REST API'erne til Power BI til at få adgang til overvågningsdataene. Du kan få flere oplysninger under Vælg API'er eller PowerShell-cmdlet'er senere i denne artikel.

I dette afsnit fokuseres der på dit teknologivalg. Du kan få mere at vide om kilden for at få adgang til bestemte typer overvågningsdata i Beslutninger om datakilder senere i denne artikel.

Platformindstillinger

Der er mange forskellige måder at få adgang til overvågningsdata på. Afhængigt af den teknologi, du vælger, kan du læne dig mod et foretrukket sprog. Du skal muligvis også træffe en bestemt beslutning om, hvordan du planlægger at køre dine scripts. Teknologier varierer meget i deres læringskurve og let at komme i gang.

Her er nogle teknologier, du kan bruge til at hente data ved hjælp af REST API'er til Power BI.

Teknologi	Godt valg til manuelle overvågningsprocesser	Godt valg til automatiserede overvågningsprocesser
Administrationsovervågningsarbejdsområde
Prøv det
PowerShell
Power BI Desktop
Power Automate
Foretrukken Azure-tjeneste
Foretrukket værktøj/sprog
Søgning i Microsoft Purview-overvågningslog
Defender for Cloud Apps
Microsoft Sentinel

Resten af dette afsnit indeholder en kort introduktion til hver af de muligheder, der præsenteres i tabellen.

Administrationsovervågningsarbejdsområde

Arbejdsområdet til administratorovervågning indeholder foruddefinerede rapporter og semantiske modeller i Power BI-tjeneste. Det er en praktisk måde for Fabric-administratorer at få vist de seneste overvågningsdata og hjælpe dem med at forstå brugeraktiviteter.

Prøv det i API-dokumentation

Try-it er et interaktivt værktøj, der giver dig mulighed for at opleve Power BI REST API direkte i Microsoft-dokumentationen. Det er en nem måde at udforske API'erne på, fordi det ikke kræver andre værktøjer eller nogen konfiguration på din computer.

Du kan bruge Try-it til at:

• Send manuelt en anmodning til en API for at afgøre, om den returnerer de ønskede oplysninger.
• Få mere at vide om, hvordan URL-adressen oprettes, før du skriver et script.
• Kontrollér data på en uformel måde.

Bemærk

Du skal være en licenseret og godkendt Power BI-bruger for at kunne bruge Prøv det. Den følger standardtilladelsesmodellen, hvilket betyder, at bruger-API'er er afhængige af brugertilladelser, og administrator-API'erne kræver Power BI-administratortilladelser. Du kan ikke godkende med Try-it ved hjælp af en tjenesteprincipal.

Da det er interaktivt, er Try-det bedst egnet til læring, udforskning og nye manuelle overvågningsprocesser.

PowerShell og Azure Cloud Shell

Du kan oprette og køre PowerShell-scripts på flere måder.

Her er flere almindelige indstillinger.

• Visual Studio Code: En moderne, let kildekodeeditor. Det er et frit tilgængeligt værktøj med åben kildekode, der understøttes på flere platforme, herunder Windows, macOS og Linux. Du kan bruge Visual Studio Code med mange sprog, herunder PowerShell (ved hjælp af PowerShell-udvidelsen).
• Azure Data Studio: Et værktøj til oprettelse af scripts og notesbøger. Den er bygget oven på Visual Studio Code. Azure Data Studio er tilgængelig uafhængigt af hinanden eller med SQL Server Management Studio (SSMS). Der er mange udvidelser, herunder en udvidelse til PowerShell.
• Azure Cloud Shell-: Et alternativ til at arbejde med PowerShell lokalt. Du kan få adgang til Azure Cloud Shell fra en browser.
• Azure Functions: Et alternativ til at arbejde med PowerShell lokalt. Azure Functions er en Azure-tjeneste, der giver dig mulighed for at skrive og køre kode i et serveruafhængigt miljø. PowerShell er et af flere sprog, der understøttes.

Vigtigt

Vi anbefaler, at du bruger den nyeste version af PowerShell (PowerShell Core) til alt nyt udviklingsarbejde. Du bør ophøre med at bruge Windows PowerShell (som ikke kan køre PowerShell Core) og i stedet bruge en af de moderne kodeeditorer, der understøtter PowerShell Core. Vær forsigtig, når du refererer til mange onlineeksempler, der bruger Windows PowerShell (version 5.1), da de muligvis ikke bruger de nyeste (og bedre) kodemetoder.

Du kan bruge PowerShell på flere forskellige måder. Du kan få flere oplysninger om denne tekniske beslutning under Vælg API'er eller PowerShell-cmdlet'er senere i denne artikel.

Der er mange onlineressourcer tilgængelige til brug af PowerShell, og det er ofte muligt at finde erfarne udviklere, der kan oprette og administrere PowerShell-løsninger. PowerShell er et godt valg til oprettelse af både manuelle og automatiserede overvågningsprocesser.

Power BI Desktop

Da Power BI Desktop kan oprette forbindelse til API'er, kan du blive fristet til at bruge det til at oprette din overvågningsløsning. Der er dog nogle betydelige ulemper og kompleksiteter.

• akkumuleret historik: Da Power BI-aktivitetsloggen indeholder op til 30 dages data, omfatter oprettelsen af hele overvågningsløsningen at akkumulere et sæt filer over tid, der gemmer alle historiske hændelser. Det er nemmere at akkumulere historiske filer med andre værktøjer.
• Håndtering af legitimationsoplysninger og nøgler sikkert: Mange løsninger, du finder online fra communitybloggere, er ikke sikre, fordi de har hard-code-legitimationsoplysninger og nøgler i almindelig tekst i Power Query-forespørgsler. Selvom denne fremgangsmåde er nem, anbefales det ikke, fordi alle, der henter din Power BI Desktop-fil, kan læse værdierne. Du kan ikke gemme adgangskoden (når du bruger brugergodkendelse) eller hemmeligheden (når du bruger en tjenesteprincipal) sikkert i Power BI Desktop, medmindre du:
  • Brug en brugerdefineret connector, der er udviklet med Power Query SDK. En brugerdefineret connector kan f.eks. læse fortrolige værdier fra Azure Key Vault eller en anden tjeneste, der sikkert gemmer den krypterede værdi. Der er også forskellige brugerdefinerede connectorindstillinger tilgængelige fra det globale Power BI-community.
  • Brug indstillingen ApiKeyName , som fungerer godt i Power BI Desktop. Det er dog ikke muligt at gemme nøgleværdien i Power BI-tjeneste.
• typer anmodninger: Du kan støde på nogle begrænsninger for, hvad du kan køre i Power BI Desktop. Power Query understøtter f.eks. ikke alle typer API-anmodninger. Det er f.eks. kun GET- og POST-anmodninger, der understøttes, når funktionen Web.Contents bruges. I forbindelse med overvågning sender du typisk GET-anmodninger.
• Mulighed for at opdatere: Du skal følge bestemte udviklingsmønstre i Power Query for at opdatere en semantisk model i Power BI-tjenesten. Indstillingen skal f.eks. være til stede, RelativePath når du bruger Web.Contents, så Power BI kan kontrollere placeringen af en datakilde korrekt uden at generere en fejl i Power BI-tjeneste.

I de fleste tilfælde anbefaler vi, at du kun bruger Power BI Desktop til to formål. Du skal bruge den til at:

• Byg din datamodel baseret på de eksisterende organiserede data (i stedet for at bruge dem til at udtrække overvågningsdataene).
• Opret analyserapporter baseret på din datamodel.

Power Automate

Du kan bruge Power Automate med Power BI på mange måder. I forbindelse med overvågning kan du bruge Power Automate til at sende anmodninger til REST API'erne til Power BI og derefter gemme de udtrukne data på den placering, du vælger.

Tip

Hvis du vil sende anmodninger til REST API'er til Power BI, kan du bruge en brugerdefineret connector til Power Automate til sikkert at godkende og udtrække overvågningsdataene. Du kan også bruge Azure Key Vault til at referere til en adgangskode eller hemmelighed. Begge indstillinger er bedre end at gemme adgangskoder og hemmeligheder i almindelig tekst i Power Automate-flowet.

Du kan finde andre idéer til, hvordan du bruger Power Automate, ved at søge efter Power BI i Power Automate-skabelonerne.

Foretrukken Azure-tjeneste

Der er flere Azure-tjenester, der kan sende anmodninger til REST API'erne til Power BI. Du kan bruge din foretrukne Azure-tjeneste, f.eks.:

• Azure Functions
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

I de fleste tilfælde kan du kombinere en beregningstjeneste, der håndterer logikken for dataudtrækningen, med en lagertjeneste, der gemmer rådata (og udvalgte data, når det er relevant). Overvejelser i forbindelse med at træffe beslutninger om teknisk arkitektur beskrives senere i denne artikel.

Foretrukket værktøj og/eller sprog

Du kan bruge dit foretrukne værktøj og dit foretrukne sprog til at sende anmodninger til REST API'erne til Power BI. Det er en god tilgang, når dit team har ekspertise med et bestemt værktøj eller sprog, f.eks.:

• Python
• C# på .NET framework. Du kan også bruge Power BI .NET SDK, der fungerer som ombrydning oven på REST API'erne til Power BI for at forenkle nogle processer og øge produktiviteten.
• JavaScript

Microsoft Purview-overvågningssøgning

Microsoft Purview-compliance-portal (tidligere Microsoft 365 Compliance Center) indeholder en brugergrænseflade, der giver dig mulighed for at få vist og søge i overvågningslogfilerne. De samlede overvågningslogge omfatter Power BI og alle andre tjenester, der understøtter Microsoft 365 Unified Audit Logs.

De data, der registreres i den samlede overvågningslog, er nøjagtigt de samme data, der er indeholdt i Power BI-aktivitetsloggen. Når du foretager en søgning i overvågningsloggen i Microsoft Purview-compliance-portal, føjes din anmodning til køen. Det kan tage et par minutter (eller længere, afhængigt af mængden af data), før dataene er klar.

Her er nogle almindelige måder at bruge søgeværktøjet til overvågningslog på. Du kan:

• Vælg Power BI-arbejdsbelastningen for at få vist hændelser for en række datoer.
• Søg efter en eller flere specifikke aktiviteter, f.eks.:
  • Slettede Power BI-rapport
  • Tilføjet administratoradgang til et personligt arbejdsområde i Power BI
• Få vist aktiviteter for en eller flere brugere.

For administratorer med tilstrækkelige tilladelser er søgeværktøjet til overvågningsloggen i Microsoft Purview-compliance-portal en god mulighed for manuelle overvågningsprocesser. Du kan få flere oplysninger i Microsoft Purview-compliance-portal senere i denne artikel.

Brugergrænsefladen i Defender for Cloud Apps

Defender for Cloud Apps er tilgængelig for administratorer i Microsoft Defender XDR (Microsoft 365-portal). Den indeholder en brugergrænseflade til at få vist og søge efter aktivitetslogge for forskellige cloudtjenester, herunder Power BI. Den viser de samme loghændelser, der stammer fra Microsoft Purview-compliance-portal, ud over andre hændelser, f.eks. brugerlogonaktivitet fra Microsoft Entra ID.

Overvågningsloggrænsefladen i Defender for Cloud Apps er en god mulighed for manuelle overvågningsprocesser. Du kan få flere oplysninger i Defender for Cloud Apps senere i denne artikel.

Microsoft Sentinel og KQL

Microsoft Sentinel er en Azure-tjeneste, der giver dig mulighed for at indsamle, registrere, undersøge og reagere på sikkerhedshændelser og trusler. Power BI kan konfigureres i Microsoft Sentinel som en dataconnector, så overvågningslogge streames fra Power BI til Microsoft Sentinel Azure Log Analytics (som er en komponent i Azure Monitor-tjenesten ). Du kan bruge Kusto Query Language (KQL) til at analysere de aktivitetsloghændelser, der er gemt i Azure Log Analytics.

Brug af KQL til at søge efter data i Azure Monitor er en god mulighed for at få vist en del af overvågningsloggen. Det er også en god mulighed for manuelle overvågningsprocesser. Du kan få flere oplysninger i Microsoft Sentinel senere i denne artikel.

Overvejelser i forbindelse med platformen

Her er nogle overvejelser om, hvordan du kan få adgang til overvågningsdata.

• Implementerer du en manuel eller automatiseret overvågningsproces? Visse værktøjer er stærkt i overensstemmelse med manuel behandling eller automatiseret behandling. En bruger kører f.eks. altid Try-it-funktionaliteten interaktivt, så den er kun egnet til manuelle overvågningsprocesser.
• Hvordan godkender du? Det er ikke alle indstillinger, der understøtter alle godkendelsesmuligheder. Try-it-funktionaliteten understøtter f.eks. kun brugergodkendelse.
• Hvordan gemmer du legitimationsoplysninger sikkert? Forskellige teknologier har forskellige muligheder for at gemme legitimationsoplysninger. Du kan finde flere oplysninger under Bestem godkendelsesmetoden senere i denne artikel.
• Hvilken teknologi er dit team allerede dygtig til? Hvis der er et værktøj, som dit team foretrækker og er fortroligt med at bruge, skal du starte der.
• Hvad er dit team i stand til at støtte? Hvis et andet team understøtter den udrullede løsning, skal du overveje, om det pågældende team kan understøtte den i tilstrækkelig grad. Overvej også, at dine interne teams muligvis understøtter udvikling, der udføres af konsulenter.
• Hvilket værktøj har du godkendelse til at bruge? Visse værktøjer og teknologier kan kræve godkendelse. Det kan skyldes omkostningerne. Det kan også skyldes it-sikkerhedspolitikker.
• Hvad foretrækker du at planlægge? Nogle teknologier træffer beslutningen for dig. Andre gange vil det være en anden beslutning, du skal træffe. Hvis du f.eks. vælger at skrive PowerShell-scripts, er der forskellige måder, du kan planlægge at køre dem på. Omvendt er planlægning indbygget, hvis du bruger en cloudtjeneste, f.eks. Azure Data Factory.

Vi anbefaler, at du gennemser resten af denne artikel, før du vælger en teknologi til at få adgang til overvågningsdata.

Tjekliste – Når du beslutter, hvilken teknologi der skal bruges til at få adgang til overvågningsdata, omfatter vigtige beslutninger og handlinger:

• Diskuter med it-medarbejderne: Tal med dine it-teams for at finde ud af, om der er visse værktøjer, der er godkendt eller foretrukket.
• Udforsk indstillinger med en lille blåstempling: Eksperimenter med en teknisk blåstempling. Fokuser i første omgang på læring. Fokuser derefter på din beslutning om, hvad du skal bruge fremover.

Bestem godkendelsesmetoden

Den måde, du planlægger at konfigurere godkendelse på, er en vigtig beslutning. Det er ofte et af de vanskeligste aspekter, når du kommer i gang med overvågning og overvågning. Du bør nøje overveje de tilgængelige muligheder for at træffe en informeret beslutning.

Vigtigt

Kontakt it- og sikkerhedsteamene i denne sag. Tag dig tid til at lære det grundlæggende om, hvordan sikkerhed i Microsoft Entra ID fungerer.

Ikke alle API'er på internettet kræver godkendelse. Alle REST API'er til Power BI kræver dog godkendelse. Når du får adgang til overvågningsdata på lejerniveau, administreres godkendelsesprocessen af Microsoft-identitetsplatform. Det er en udvikling af Microsoft Entra-identitetstjenesten, der er baseret på branchestandardprotokoller.

Tip

Ordlisten Microsoft-identitetsplatform er en ressource, der hjælper dig med at blive fortrolig med de grundlæggende begreber.

Før du henter overvågningsdata, skal du først godkende, hvilket kaldes logon. Begreberne godkendelse og autorisation er separate, men relaterede. En godkendelsesproces kontrollerer identiteten af , hvem der foretager anmodningen. En godkendelsesproces giver (eller nægter) adgang til et system eller en ressource ved at kontrollere , hvad brugeren eller tjenesteprincipalen har tilladelse til at gøre.

Når en bruger eller tjenesteprincipal godkendes, udstedes der et Microsoft Entra-adgangstoken til en ressourceserver, f.eks. en Power BI REST API eller en Microsoft Graph API. Et adgangstoken udløber som standard efter en time. Der kan anmodes om et opdateringstoken, hvis det er nødvendigt.

Der er to typer adgangstokens:

• Brugertokens: Udstedt på vegne af en bruger med en kendt identitet.
• tokens kun til apps: Udstedt på vegne af et Microsoft Entra-program (tjenesteprincipal).

Du kan få flere oplysninger under Objekter for program- og tjenesteprincipal i Microsoft Entra ID.

Bemærk

Et Microsoft Entra-program er en identitetskonfiguration, der gør det muligt for en automatiseret proces at integrere med Microsoft Entra ID. I denne artikel kaldes det en appregistrering. Udtrykket tjenesteprincipal bruges også ofte i denne artikel. Disse begreber beskrives mere detaljeret senere i dette afsnit.

Tip

Den nemmeste måde at godkende på er ved at bruge Connect-PowerBIServiceAccount-cmdlet'en fra Power BI Management-modulet. Du kan muligvis se andre godkendelsesrelaterede cmdlet'er i artikler og blogindlæg online. Der er f.eks. cmdlet'erne Login-PowerBI og Login-PowerBIServiceAccount , som er aliasser for Connect-PowerBIServiceAccount cmdlet'en. Der er også cmdlet'en Disconnect-PowerBIServiceAccount , som du kan bruge til eksplicit at logge af i slutningen af en proces.

I følgende tabel beskrives de to godkendelsesindstillinger.

Godkendelsestype	Beskrivelse	Beregnet til	Godt valg til manuelle overvågningsprocesser	Godt valg til automatiserede overvågningsprocesser
Brugergodkendelse	Log på som bruger ved hjælp af brugerens hovednavn (mailadresse) og en adgangskode.	Lejlighedsvis, interaktiv brug
Godkende tjenesteprincipal	Log på som en tjenesteprincipal ved hjælp af en hemmelighed (nøgle), der er tildelt en appregistrering.	Igangværende, planlagte, automatiske handlinger

Hver godkendelsesindstilling er beskrevet mere detaljeret i følgende afsnit.

Brugergodkendelse

Brugergodkendelse er nyttig i følgende situationer.

• manuelle overvågningsprocesser: Du vil køre et script ved hjælp af dine brugertilladelser. Tilladelser kan være på et af to niveauer, afhængigt af typen af API-anmodning:
  • administratortilladelser til administrator-API'er: Du skal bruge dine tilladelser som Power BI-administrator til at sende en anmodning til en api til administratorer.
  • Brugertilladelser til bruger-API'er: Du skal bruge dine Power BI-brugertilladelser til at sende en anmodning til en bruger-API-. Du kan få flere oplysninger under Vælg en bruger-API eller administrations-API.
• Interaktivt logon: Du vil logge på interaktivt, hvilket kræver, at du angiver din mailadresse og adgangskode. Du skal f.eks. logge på interaktivt for at bruge Try-it-oplevelsen , som findes i dokumentationen til Microsoft API.
• Spore, hvem der har fået adgang til lejermetadata: Når individuelle brugere og administratorer sender API-anmodninger, kan det være en god idé at overvåge, hvem disse personer er. Når du godkender med en tjenesteprincipal (beskrevet næste), er det bruger-id, der registreres af aktivitetsloggen, program-id'et. Hvis flere administratorer godkender med den samme tjenesteprincipal, kan det være svært at vide, hvilken administrator der har fået adgang til dataene.
• delt administratorkonto: Nogle it-teams bruger en delt administratorkonto. Afhængigt af hvordan den implementeres og styres, er det muligvis ikke en bedste praksis. I stedet for en delt konto bør du overveje at bruge Microsoft Entra Privileged Identity Management (PIM), som kan give en bruger lejlighedsvise og midlertidige Power BI-administratorrettigheder.
• API'er, der kun understøtter brugergodkendelse: Nogle gange skal du muligvis bruge en API, der ikke understøtter godkendelse af en tjenesteprincipal. I dokumentationen bemærker hver API, om en tjenesteprincipal kan kalde den.

Vigtigt

Når det er muligt, anbefaler vi, at du bruger godkendelse af tjenesteprincipal til automatiserede processer.

Godkende tjenesteprincipal

De fleste organisationer har én Microsoft Entra-lejer, så vilkårene for appregistrering og tjenesteprincipal bruges som regel i flæng. Når du registrerer en Microsoft Entra-app, er der to komponenter.

• appregistrering: En til appregistrering er globalt entydig. Det er den globale definition af en registreret Microsoft Entra-app, der kan bruges af flere lejere. En appregistrering kaldes også et klientprogram eller agenten. Udtrykket klientprogram indebærer typisk en brugercomputer. Det er dog ikke situationen for appregistreringer. I Azure-portal findes Microsoft Entra-programmer på siden Appregistreringer i Microsoft Entra ID.
• Tjenesteprincipal: En tjenesteprincipal er den lokale repræsentation af appregistreringen til brug i din specifikke lejer. Tjenesteprincipalen er afledt af den registrerede Microsoft Entra-app. For organisationer med flere Microsoft Entra-lejere kan der refereres til den samme appregistrering af mere end én tjenesteprincipal. I Azure-portal kan du finde tjenesteprincipaler på siden Virksomhedsprogrammer i Microsoft Entra-id.

Da tjenesteprincipalen er den lokale repræsentation, er udtrykket tjenesteprincipalgodkendelse den mest almindelige måde at referere til logon på.

Tip

Din Microsoft Entra-administrator kan fortælle dig, hvem der har tilladelse til at oprette og give samtykke til en appregistrering i din organisation.

Godkendelse af tjenesteprincipal er nyttig i følgende situationer.

• Automatiserede overvågningsprocesser: Du vil køre en automatisk proces efter en tidsplan.
• Det er ikke nødvendigt at logge på Power BI-tjenesten: Du behøver kun at oprette forbindelse til og udtrække data. En tjenesteprincipal kan ikke logge på Power BI-tjeneste.
• Delt adgang til data: Du (personligt) er ikke Power BI-administrator, men du har tilladelse til at bruge en tjenesteprincipal. Tjenesteprincipalen har tilladelse til at køre administrator-API'er for at hente data på lejerniveau (eller andre specifikke tilladelser).
• Bruges af flere administratorer: Du vil tillade, at flere administratorer eller brugere bruger den samme tjenesteprincipal.
• Tekniske blokeringer: Der er en teknisk blokering, der forhindrer brug af brugergodkendelse. Almindelige tekniske blokeringer omfatter:
  • MFA-(Multifaktorgodkendelse): Automatiserede overvågningsprocesser (der kører automatisk) kan ikke godkendes ved hjælp af en brugerkonto, når multifaktorgodkendelse er aktiveret.
  • hashsynkronisering af adgangskode: Microsoft Entra ID kræver synkronisering af adgangskodehash for at godkende en brugerkonto. Nogle gange kan it- eller et cybersikkerhedsteam deaktivere denne funktionalitet.

Formål med appregistrering og navngivningskonvention

Hver appregistrering skal have et klart navn, der beskriver dens formål og målgruppen (som kan bruge appregistreringen).

Overvej at implementere en navngivningskonvention, f.eks.: <Arbejdsbelastning> – <Formål> – <Målgruppe> – <Objekttype>

Her er delene af navngivningskonventionen.

• arbejdsbelastning: Svarer normalt til en datakilde (f.eks. Power BI-data eller Microsoft Graph-data).
• Formål: Svarer til tilladelsesniveauet (f.eks. Læs i forhold til ReadWrite). Som beskrevet nedenfor hjælper formålet dig med at følge princippet om mindst mulige rettigheder , når du opretter separate appregistreringer, der kun kan læse data.
• Målgruppe: Valgfri. Afhængigt af arbejdsbelastningen og formålet giver målgruppen dig mulighed for at bestemme de tilsigtede brugere af appregistreringen.
• Objekttype: EntraApp- er inkluderet af hensyn til klarheden.

Navngivningskonventionen kan være mere specifik, når du har flere lejere eller flere miljøer (f.eks. udvikling og produktion).

I følgende tabel vises eksempler på appregistreringer, der kan bruges til at udtrække overvågningsdata på lejerniveau:

Navn på appregistrering	Formål	Målgruppe
PowerBIData-Read-AdminAPIs-EntraApp	Udtræk metadata for hele lejeren til overvågning og administration af Power BI. Administrator-API'er er altid skrivebeskyttede og har muligvis ikke tilladelser, der er tildelt i Microsoft Entra ID (kun indstillingen for Power BI-lejer).	Power BI-administratorer og Center of Excellence
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Administrer Power BI-lejeren. Kræver læse-/skriverettigheder for at oprette eller opdatere ressourcer.	Power BI-administratorer og Center of Excellence
GraphData-Read-PowerBIAdministrators-EntraApp	Udtræk brugere og grupper af data til overvågning og administration af Power BI. Kræver læserettigheder.	Power BI-administratorer og Center of Excellence

Administration af flere appregistreringer til forskellige formål kræver en større indsats. Du kan dog drage fordel af flere fordele.

• Se, hvad appregistreringen er beregnet bruges til, og hvorfor: Når du får vist klient-id'et fra appregistreringen i dine overvågningsdata, får du en idé om, hvad det blev brugt til og hvorfor. Det er en stor fordel ved at oprette separate appregistreringer (i stedet for kun at bruge én til alle formål).
• Se, hvem appregistreringen er beregnet bruges af: Når du får vist klient-id'et fra appregistreringen i dine overvågningsdata, får du en idé om, hvem der brugte det.
• Undgå overprovisioning af tilladelser: Du kan følge princippet om færrest mulige rettigheder ved at angive separate appregistreringer til forskellige sæt personer, der har forskellige behov. Du kan undgå overprovisioning af tilladelser ved hjælp af en skrivebeskyttet appregistrering, når skrivetilladelser ikke er nødvendige. Du kan f.eks. have nogle yderst dygtige selvbetjeningsbrugere, der vil indsamle data om deres semantiske modeller. de skal have adgang til en tjenesteprincipal med læsetilladelse . der henviser til, at der kan være satellitmedlemmer af Center of Excellence, der arbejder for økonomiteamet, som programmatisk administrerer semantiske modeller; de skal have adgang til en tjenesteprincipal med skrivetilladelse .
• Vide, hvem skal være i besiddelse af hemmeligheden: Hemmeligheden for hver appregistrering bør kun deles med de personer, der har brug for det. Når hemmeligheden roteres (beskrevet senere i dette afsnit), er virkningen mindre, når du bruger separate appregistreringer til forskellige behov. Det er nyttigt, når du har brug for at rotere hemmeligheden, fordi en bruger forlader organisationen eller ændrer roller.

Tilladelser til appregistrering

Der er to primære måder, som en appregistrering kan få adgang til data og ressourcer på. Det omfatter tilladelser og samtykke.

• tilladelser kun til apps: Adgang og godkendelse håndteres af tjenesteprincipalen uden en bruger, der er logget på. Denne godkendelsesmetode er nyttig i forbindelse med automatiseringsscenarier. Når du bruger tilladelser kun til apps, er det vigtigt at forstå, at tilladelser ikke er tildelt i Microsoft Entra-id. Tilladelser tildeles i stedet på to måder:
  • Til kørsel af administrator-API'er: Visse Fabric-lejerindstillinger giver adgang til slutpunkterne for administrator-API'er (der returnerer overvågningsmetadata for hele lejeren). Du kan få flere oplysninger i Angiv lejerindstillinger for Fabric senere i denne artikel.
  • For kørsel af bruger-API'er: Power BI-arbejdsområde- og elementtilladelser gælder. Power BI-standardtilladelser styrer, hvilke data der kan returneres til en tjenesteprincipal, når der køres bruger-API'er (der returnerer overvågningsdata baseret på tilladelserne for den bruger eller tjenesteprincipal, der aktiverer API'en).
• delegerede tilladelser: Områdebaserede tilladelser bruges. Tjenesteprincipalen får adgang til data på vegne af den bruger, der i øjeblikket er logget på. Det betyder, at tjenesteprincipalen ikke kan få adgang til noget ud over, hvad den bruger, der er logget på, har adgang til. Vær opmærksom på, at dette er et andet begreb end godkendelse, der kun bruges af brugere, som beskrevet tidligere. Da der kræves et brugerdefineret program for at håndtere kombinationen af bruger- og apptilladelser korrekt, bruges delegerede tilladelser sjældent til overvågningsscenarier. Dette koncept er ofte misforstået, hvilket fører til mange appregistreringer, der er overprovisioned med tilladelser.

Vigtigt

I denne artikel fokuseres der kun på brugergodkendelse eller godkendelse kun til apps. Delegerede tilladelser (med en interaktiv bruger og tjenesteprincipalen) kan spille en vigtig rolle, når Power BI-indhold integreres programmeringsmæssigt. Vi fraråder dog på det kraftigste, at du konfigurerer delegerede tilladelser til at udtrække overvågningsdata. Hver API begrænser, hvor ofte den kan køres (med begrænsning på plads), så det er ikke praktisk at have forskellige brugere direkte adgang til de rå overvågningsdata. Vi anbefaler i stedet, at du udtrækker de rå overvågningsdata én gang (med en centraliseret proces) og derefter gør de organiserede overvågningsdata tilgængelige for godkendte brugere downstream.

Du kan få flere oplysninger under Registrer en Microsoft Entra-app senere i denne artikel.

Appregistreringshemmeligheder

En appregistrering har ofte fået tildelt en hemmelighed . Hemmeligheden bruges som en nøgle til godkendelse, og den har en udløbsdato. Derfor skal du planlægge, hvordan du jævnligt roterer nøglen, og hvordan du kommunikerer den nye nøgle til godkendte brugere.

Du skal også bekymre dig om, hvor du sikkert kan gemme hemmeligheden. En organisationsadgangskodeboks, f.eks . Azure Key Vault, er et fremragende valg.

Tip

Som en alternativ metode til at bruge en hemmelighed kan du bruge en administreret identitet. En administreret identitet fjerner behovet for at administrere legitimationsoplysninger. Hvis du vil bruge tjenester som Azure Functions eller Azure Data Factory til at udtrække dataene, er en administreret identitet en god mulighed at undersøge.

Administrer legitimationsoplysninger sikkert

Uanset om du bruger brugergodkendelse eller tjenesteprincipalgodkendelse, er en af de største udfordringer, hvordan du administrerer adgangskoder, hemmeligheder og nøgler på en sikker måde.

Advarsel

Den første regel er en, som mange mennesker overtræder: adgangskoder og nøgler bør aldrig vises i almindelig tekst i et script. Mange artikler, blogs og eksempler online gør det for nemheds skyld. Det er dog en dårlig praksis, der bør undgås. Alle, der henter scriptet (eller filen), kan potentielt få adgang til de samme data, som forfatteren har adgang til.

Her er flere sikre metoder, du kan bruge til at administrere adgangskoder, hemmeligheder og nøgler.

• Integrer med Azure Key Vault eller et andet system til organisationsadgangskodeboks, når det er muligt.
• Brug legitimationsoplysninger og sikre strenge i dine PowerShell-scripts. En legitimationsoplysninger fungerer for både brugergodkendelse og godkendelse af tjenesteprincipal. Du kan dog ikke bruge legitimationsoplysninger, når multifaktorgodkendelse er aktiveret for en brugerkonto.
• Spørg efter en adgangskode i dit PowerShell-script, eller brug interaktiv godkendelse med en browser.
• Brug modulet Secret Management til PowerShell, der udgives af Microsoft. Den kan gemme værdier ved hjælp af en lokal vault. Den kan også integreres med en ekstern Azure Key Vault, hvilket er nyttigt, når der er flere administratorer i din organisation, der arbejder med de samme scripts.
• Opret en brugerdefineret connector til Power BI Desktop, så den kan håndtere legitimationsoplysninger sikkert. Nogle brugerdefinerede connectors er tilgængelige fra communitymedlemmer (normalt på GitHub).

Tip

Vi anbefaler, at du rådfører dig med it- og sikkerhedsteams for at hjælpe med at vælge den bedste metode eller validere, at din løsning administrerer legitimationsoplysninger på en sikker måde.

Microsoft Authentication Library

Support til Azure AD Authentication Library (ADAL) sluttede i december 2022. Fremover skal du bruge Microsoft Authentication Library (MSAL). Sikkerhedsteamet i din organisation bør være bekendt med denne betydelige ændring.

Selvom det ikke er vigtigt for Power BI-fagfolk at forstå overgangen til MSAL dybt, skal du overholde følgende anbefalinger.

• Brug den nyeste version af Power BI Management-modulet, når du godkender med PowerShell-cmdlet'en Connect-PowerBIServiceAccount . Det skiftede fra ADAL til MSAL i version 1.0.946 (26. februar 2021).
• Brug Microsoft Entra V2-slutpunktet, når du godkender direkte i dit script. Microsoft Entra V2-slutpunktet bruger MSAL, mens Microsoft Entra V1-slutpunktet bruger ADAL.
• Udgå brugen af API'er og moduler, der frarådes. Du kan få flere oplysninger under Udfasede API'er og moduler senere i denne artikel.
• Hvis du finder en communityløsning online, skal du sørge for, at den bruger MSAL til godkendelse i stedet for ADAL.

Tjekliste – når du beslutter, hvordan du administrerer godkendelse, omfatter vigtige beslutninger og handlinger:

• Beslut, hvilken type godkendelse der skal bruges: Find ud af, om godkendelse af brugergodkendelse eller tjenesteprincipal er bedst egnet, afhængigt af den type overvågningsløsning, du planlægger at oprette.
• Planlæg, hvilke appregistreringer du har brug for: Overvej dine krav, arbejdsbelastninger og målgruppe (brugere af hver appregistrering). Planlæg, hvor mange appregistreringer du skal oprette for at understøtte disse behov.
• Opret en navngivningskonvention for appregistreringer: Konfigurer en navngivningskonvention, der gør det nemt at forstå det tilsigtede formål og de tilsigtede brugere af hver appregistrering.
• Planlæg, hvordan du sikkert administrerer legitimationsoplysninger: Overvej måder at administrere adgangskoder, hemmeligheder og nøgler sikkert på. Overvej, hvilken dokumentation og oplæring der kan være nødvendig.
• Bekræft brugen af MSAL-: Find ud af, om der er eksisterende manuelle eller automatiserede overvågningsløsninger, der er afhængige af ADAL. Hvis det er nødvendigt, skal du oprette en plan for at omskrive disse løsninger for at bruge det nyere MSAL-godkendelsesbibliotek.

Vælg en bruger-API eller administrations-API

Når du planlægger at hente overvågningsdata, er det vigtigt at bruge den rigtige type API.

Der er to typer API'er, der skal overvejes.

• bruger-API'er: Brug tilladelserne for den bruger, der er logget på (eller tjenesteprincipalen), til at sende anmodninger til API'en. En måde at returnere en liste over semantiske modeller i et arbejdsområde på er f.eks. med en bruger-API. Tilladelse til at læse semantiske modeller kan tildeles enten efter arbejdsområderolle eller tilladelser pr. element. Der er to måder at køre bruger-API'er på:
  • brugergodkendelse: Den bruger, der er logget på, skal have tilladelse til at få adgang til arbejdsområdet eller elementet.
  • Godkendelse af tjenesteprincipal: Tjenesteprincipalen skal have tilladelse til at få adgang til arbejdsområdet eller elementet.
• administrations-API'er: Hent metadata fra lejeren. Det kaldes nogle gange organisationsomfanget. Hvis du f.eks. vil returnere en liste over alle semantiske modeller i lejeren, skal du bruge en administrations-API. Der er to måder at køre administrator-API'er på:
  • brugergodkendelse: Den bruger, der er logget på, skal være Power BI-administrator for at kunne køre administrator-API'er.
  • Godkendelse af tjenesteprincipal: Tjenesteprincipalen skal have tilladelse til at køre administrator-API'er (uden at være afhængig af sikkerhedstilladelser som en bruger-API).

Tip

Alle administrator-API'er tilhører administratorhandlingsgruppen. Alle API'er, der har suffikset Som administrator , er en administrations-API. Alle resterende API'er er bruger-API'er.

Overvej et eksempel, hvor du skal have en liste over semantiske modeller. I følgende tabel vises seks API-indstillinger, som du kan bruge til at gøre det. Fire indstillinger er bruger-API'er, og to indstillinger er administrator-API'er. Omfanget og antallet af elementer, der returneres, er forskellige afhængigt af den API, du vælger.

API-navn	API-type	Område	Antal semantiske modeller
Hent datasæt	User	Personligt arbejdsområde	Et
Hent datasæt	User	Personligt arbejdsområde	All
Hent datasæt i gruppe	User	Ét arbejdsområde	En, forudsat at den bruger, der er logget på, har tilladelse til at læse den semantiske model
Hent datasæt i gruppe	User	Ét arbejdsområde	Alle, forudsat at den bruger, der er logget på, har tilladelse til at læse hver semantisk model
Hent datasæt i gruppe som administrator	Administrator	Ét arbejdsområde	All
Hent datasæt som administrator	Administrator	Hele lejeren	All

Bemærk

Nogle af API-navnene omfatter udtrykket Gruppe som reference til et arbejdsområde. Dette ord stammer fra den oprindelige Power BI-sikkerhedsmodel, der var afhængig af Microsoft 365-grupper. Selvom Power BI-sikkerhedsmodellen har udviklet sig markant i årenes løb, forbliver de eksisterende API-navne uændrede for at undgå at ødelægge eksisterende løsninger.

Du kan få oplysninger om lejerindstillinger i Angiv Lejerindstillinger for Fabric senere i denne artikel.

Tjekliste – Når du vælger, om du vil bruge en bruger-API eller en administrations-API, omfatter vigtige beslutninger og handlinger:

• Se datakrav: Indsaml og dokumenter de vigtigste forretningskrav til en overvågningsløsning. På baggrund af den type data, der er behov for, skal du afgøre, om et brugerområde eller et organisationsomfang er relevant.
• Test resultaterne: Eksperimenter lidt. Test nøjagtigheden af de resultater, der returneres af de forskellige API'er.
• Gennemse tilladelser: For alle eksisterende overvågningsløsninger skal du bekræfte, at tilladelserne er tildelt korrekt til Power BI-administratorer og tjenesteprincipaler. I forbindelse med nye overvågningsløsninger skal du bekræfte, hvilken godkendelsesmetode der skal bruges.

Vælg API'er eller PowerShell-cmdlet'er

En vigtig beslutning er, om du vil bruge PowerShell-cmdlet'er, når de er tilgængelige for de specifikke data, du vil hente. Denne beslutning er vigtig, hvis du har besluttet, at PowerShell er en af de teknologier, du skal bruge til at få adgang til overvågningsdata.

PowerShell er en løsning til opgaveautomatisering. Udtrykket PowerShell er et kollektivt ord, der refererer til scriptsproget, et kommandolinjebaseret shellprogram og en konfigurationsstyringsstruktur. PowerShell Core er den nyeste version af PowerShell, der kører på Windows, Linux og macOS.

En PowerShell-cmdlet er en kommando, der udfører en handling. Et PowerShell-modul er en pakke, der indeholder PowerShell-medlemmer, f.eks. cmdlet'er, providere, funktioner, arbejdsprocesser, variabler og aliasser. Du downloader og installerer moduler.

Et PowerShell-modul opretter et abstraktionslag over API'erne. Cmdlet'en Get-PowerBIActivityEvent henter (eller henter) overvågningshændelser for en Power BI-lejer. Denne PowerShell-cmdlet henter sine data fra REST API'en Hent aktivitetshændelser . Det er generelt nemmere at komme i gang ved hjælp af cmdlet'erne, fordi det forenkler adgangen til de underliggende API'er.

Kun et undersæt af API'erne er tilgængelige som PowerShell-cmdlet'er. Når du fortsætter med at udvide hele overvågningsløsningen, er det sandsynligt, at du bruger en kombination af cmdlet'er og API'er. Resten af dette afsnit hjælper dig med at beslutte, hvilken måde du vil få adgang til dataene på.

PowerShell-moduler

Microsoft har udgivet to PowerShell-moduler, der indeholder cmdlet'er, der er relateret til Power BI. De er Power BI-administrationsmodulet og datagatewaymodulet. Disse PowerShell-moduler fungerer som en API-ombrydning oven på de underliggende REST API'er til Power BI. Brug af disse PowerShell-moduler kan gøre det nemmere at skrive scripts.

Tip

Ud over de moduler, der udgives af Microsoft, er der frit tilgængelige PowerShell-moduler og -scripts, der udgives (normalt på GitHub) af Medlemmer af Power BI-community'et, partnere og Microsoft Most Valued Professionals (MVP'er).

Fra og med en communityløsning kan spille en vigtig rolle i opbygningen af din komplette overvågningsløsning. Hvis du vælger at bruge en frit tilgængelig løsning, skal du sørge for at teste den fuldt ud. Bliv fortrolig med, hvordan det fungerer, så du effektivt kan administrere din løsning over tid. It-afdelingen kan have kriterier for brug af offentligt tilgængelige communityløsninger.

Power BI Management-modul

Power BI Management-modulet er et akkumuleringsmodul, der indeholder specifikke Power BI-moduler til administration, kapaciteter, arbejdsområder og meget mere. Du kan vælge at installere akkumuleringsmodulet for at hente alle modulerne, eller du kan installere bestemte moduler. Alle Power BI-administrationsmoduler understøttes på både Windows PowerShell og PowerShell Core.

Vigtigt

Vi anbefaler, at du ophører med at bruge Windows PowerShell (som ikke kan køre PowerShell Core). Brug i stedet en af de moderne kodeeditorer, der understøtter PowerShell Core. Windows PowerShell ISE (integreret scriptmiljø) kan kun køre PowerShell version 5.1, som ikke længere opdateres. Windows PowerShell frarådes nu, så vi anbefaler, at du bruger PowerShell Core til alt nyt udviklingsarbejde.

Her er flere almindeligt anvendte cmdlet'er, som du kan bruge til at hente overvågningsdata.

Administrationsmodul	Cmdlet	Formål
Profil	Connect-PowerBIServiceAccount	Godkend en Power BI-bruger eller en tjenesteprincipal.
Administrator	Get-PowerBIActivityEvent	Få vist eller udtræk hændelser i Power BI-aktivitetsloggen for lejeren.
Arbejdsområder	Get-PowerBIWorkspace	Kompiler en liste over arbejdsområder.
Rapporter	Hent PowerBI-rapport	Kompiler en liste over rapporter for et arbejdsområde eller lejeren.
Data	Get-PowerBIDataset	Kompiler en liste over semantisk model for et arbejdsområde eller lejeren.
Profil	Invoke-PowerBIRestMethod	Send en REST API-anmodning (kommando). Denne cmdlet er en god mulighed, fordi den kan aktivere en hvilken som helst af REST API'erne til Power BI. Det er også et godt valg, når du vil bruge den enklere form for godkendelse ved hjælp af cmdlet'en Connect-PowerBIServiceAccount og være i stand til at aktivere en API, der ikke har en tilsvarende PowerShell-cmdlet. Du kan få flere oplysninger under Overvejelser i forbindelse med brug af PowerShell-cmdlet'er senere i dette afsnit.

Tip

Der er andre cmdlet'er tilgængelige til administration og publicering af indhold. I denne artikel fokuseres der dog på hentning af overvågningsdata.

Du kan downloade Power BI Management-modulet fra PowerShell-galleriet. Den nemmeste måde at installere moduler på er at bruge PowerShellHent.

Vi anbefaler, at du installerer akkumuleringsmodulet til Power BI-administration. På den måde er alle de cmdlet'er, du muligvis har brug for, tilgængelige. Du skal som minimum bruge profilmodulet (til godkendelse) og eventuelle specifikke moduler, der indeholder de cmdlet'er, du vil bruge.

Advarsel

Sørg for at holde modulerne opdateret på hver server, brugercomputer og cloudtjeneste (f.eks. Azure Automation), hvor du bruger PowerShell. Hvis modulerne ikke opdateres regelmæssigt, kan der opstå uforudsigelige fejl eller problemer. Nogle værktøjer (f.eks. Visual Studio Code) hjælper dig med at holde modulerne opdateret. Vær også opmærksom på, at PowerShellGet ikke automatisk fjerner ældre versioner af et modul, når du installerer eller opdaterer en nyere version. Det installerer nyere versioner sammen med de ældre versioner. Vi anbefaler, at du kontrollerer , om der er installerede versioner, og at du jævnligt fjerner ældre versioner.

Datagatewaymodul

Datagatewaymodulet indeholder cmdlet'er, der henter data fra en datagateway i det lokale miljø og dens datakilder. Data Gateway-modulet understøttes kun på PowerShell Core. Det understøttes ikke på Windows PowerShell.

I modsætning til Power BI-administrationsmodulet (tidligere beskrevet) indeholder datagatewaymodulet ikke nogen administrator-cmdlet'er. Mange af cmdlet'erne (og de tilsvarende gateway-API'er) kræver, at brugeren har rettigheder som gatewayadministrator.

Advarsel!

Det er ikke muligt at tildele en tjenesteprincipal som gatewayadministrator (selv når tjenesteprincipalen er medlem af en sikkerhedsgruppe). Planlæg derfor at bruge brugerlegitimationsoplysninger, når du henter oplysninger om datagateways.

Her er flere cmdlet'er fra datagatewaymodulet, som du kan bruge til at hente overvågningsdata.

Cmdlet	Formål
Connect-DataGatewayServiceAccount	Godkend en Power BI-bruger (kræver normalt, at brugeren tilhører gatewayens administratorrolle).
Get-DataGatewayCluster	Kompiler en liste over gatewayklynger.
Get-DataGatewayClusterDataSource	Kompiler en liste over datakilder til en gatewayklynge.
Get-DataGatewayInstaller	Kontrollér, hvilke brugere der har tilladelse til at installere og registrere gateways i organisationen.

Du kan downloade datagatewaymodulet fra PowerShell-galleriet.

Teknikker til brug af PowerShell

Du kan bruge PowerShell på flere forskellige måder. Den beslutning, du træffer, er en vigtig beslutning.

I følgende tabel beskrives tre forskellige teknikker til brug af PowerShell.

Teknik	Beskrivelse	Eksempel
Brug PowerShell-cmdlet'er til at forenkle godkendelse og til at kalde API'er direkte. Anbefalet fremgangsmåde	Med denne teknik er der balance mellem enkelthed og fleksibilitet. Invoke-PowerBIRestMethod-cmdlet'en er tilgængelig fra modulet Power BI-administrationsprofil. Denne cmdlet kaldes ofte for en schweizisk hærkniv , fordi du kan bruge den til at kalde en af Rest API'erne til Power BI. Fordelen ved at bruge denne teknik er, at du kan forenkle godkendelse og derefter kalde en af Power BI REST API'er. Vi anbefaler på det kraftigste, at du bruger denne teknik.	Når du har bekræftet med Connect-PowerBIServiceAccount-cmdlet'en, skal du bruge cmdlet'en Invoke-PowerBIRestMethod til at hente data fra din foretrukne API (f.eks. Hent pipelinebrugere som administrator).
Brug cmdlet'er fra PowerShell så meget som muligt, både til godkendelse og til hentning af data.	Med denne teknik bruges PowerShell i vid udstrækning. PowerShell bruges til at koordinere kørsel af scriptet, og PowerShell-moduler bruges, når det er muligt, til at få adgang til dataene. Dette skaber en større afhængighed af PowerShell fra flere aspekter.	Når du har bekræftet med Connect-PowerBIServiceAccount-cmdlet'en , skal du bruge en cmdlet (f.eks . Get-PowerBIActivityEvent) til at hente data.
Brug kun PowerShell til at koordinere kørslen af processen. PowerShell-moduler bruges så lidt som muligt.	Med denne teknik er der mindre afhængighed af PowerShell som et værktøj, da det primært bruges til at orkestrere aktivering af API-kald. Der bruges kun ét generisk PowerShell-modul til at få adgang til API'er (ingen af modulerne fra Power BI Management-modulerne bruges).	Når du har godkendt ved hjælp af Microsoft Authentication Library (MSAL), skal du kalde din foretrukne API (f.eks. Hent pipelinebrugere som administrator) ved hjælp af den generiske Invoke-RestMethod-cmdlet til at hente data.

I ovenstående tabel beskriver den første teknik en tilgang, der balancerer brugervenligheden med fleksibilitet. Denne fremgangsmåde giver den bedste balance for behovene i de fleste organisationer, og derfor anbefales det. Nogle organisationer kan have eksisterende it-politikker og personaleindstillinger, der påvirker, hvordan du beslutter dig for at bruge PowerShell.

Tip

Du kan bruge Invoke-ASCmd PowerShell-cmdlet'en til at oprette og udføre DAX-, XMLA- og TMSL-scripts . Disse use cases er dog uden for denne artikels anvendelsesområde. Du kan få flere oplysninger om forespørgsler om DMV'er (Dynamic Management Views) under Overvågning på dataniveau.

Tekniske brugere (og administratorer) kan bruge Power BI-administrationsmodulerne til at hente data eller automatisere visse aspekter af indholdsstyring.

• For administratorer: Angiv parameteren -Scope til Organization for at få adgang til objekter på tværs af hele lejeren (f.eks. for at hente en liste over alle arbejdsområder).
• For tekniske brugere: Angiv parameteren -Scope til Individual (eller udelad parameteren) for at få adgang til objekter, der tilhører brugeren (f.eks. for at hente en liste over arbejdsområder , som brugeren har tilladelse til at få adgang til).

Overvej et scenarie, hvor du skal have en liste over semantiske modeller. Hvis du vælger at arbejde direkte med API'erne, skal du angive, hvilken API der skal kaldes. Men hvis du vælger at bruge cmdlet'en Get-PowerBIDataset , kan du angive -Scope parameteren for at hente en brugerspecifik eller lejerbaseret liste over semantiske modeller. Det valg, du træffer, afhænger af din beslutning om, hvordan du bruger PowerShell (beskrevet i den forrige tabel).

I følgende tabel beskrives det, hvordan de parametre, der bruges i PowerShell-cmdlet'en, oversættes til API'ens PowerShell-kald.

Cmdlet-parametre	API, som cmdlet'en bruger	API-type	Område	Hentede elementer
-DatasetID {DatasetID} -Scope Individual	Hent datasæt	User	Personligt arbejdsområde	Én semantisk model
-Scope Individual	Hent datasæt	User	Personligt arbejdsområde	Alle semantiske modeller
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Hent datasæt i gruppe	User	Ét arbejdsområde	Én semantisk model, forudsat at den bruger, der er logget på, har tilladelse til at læse den semantiske model
-GroupID {WorkspaceID}	Hent datasæt i gruppe	User	Ét arbejdsområde	Alle semantiske modeller, forudsat at den bruger, der er logget på, har tilladelse til at få adgang til arbejdsområdet og læse den semantiske model
-GroupID {WorkspaceID} -Scope Organization	Hent datasæt i gruppe som administrator	Administrator	Ét arbejdsområde	Alle semantiske modeller
-Scope Organization	Hent datasæt som administrator	Administrator	Hele lejeren	Alle semantiske modeller

Overvejelser i forbindelse med brug af PowerShell-cmdlet'er

PowerShell-cmdlet'erne til Power BI er enklere at bruge, fordi de opsummerer nogle af kompleksiteten af REST API-kald.

Her er nogle af de måder, som cmdlet'erne forenkler adgangen til overvågningsdata på.

• Godkendelse: Den nemmeste måde at godkende i et PowerShell-script på er at bruge cmdlet'en Connect-PowerBIServiceAccount.
• Enkelthed: Det er nemmere at komme i gang, fordi teknikkerne til at hente overvågningsdata er enkle. Overvej, at når du bruger cmdlet'en Get-PowerBIActivityEvent , henter du én dags overvågningsdata. Men når du kalder REST API'en Get Activity Events direkte, henter du én times overvågningsdata. Så når du bruger REST-API'en til at hente én dags overvågningsdata, skal du bruge en løkke til at kalde API'en 24 gange for at udtrække hver time på dagen.
• Sideinddeling af store resultatsæt: Store resultatsæt hentes effektivt af sideinddeling. Sideinddeling omfatter hentning af ét afsnit af resultaterne ad gangen. Cmdlet'erne administrerer automatisk sideinddeling for dig. Men når du bruger REST API'erne direkte, skal dit script kontrollere et fortsættelsestoken for at afgøre, om der er flere resultater. Scriptet skal fortsætte med at hente dele af resultater, indtil der ikke modtages et fortsættelsestoken. Du kan se et eksempel på brug af et fortsættelsestoken under REST API for aktivitetshændelser.
• udløb af Adgangstoken: Når du godkender, returneres der et adgangstoken. Som standard udløber den efter en time. Cmdlet'erne håndterer udløb af adgangstoken for dig. På den måde behøver du ikke at skrive logik for at anmode om et opdateringstoken.
• Formatering: De data, der returneres af en cmdlet, formateres en smule pænere end de data, der returneres af REST-API'en. Outputtet er mere brugervenligt. I forbindelse med automatiserede overvågningsprocesser er det sandsynligvis ikke et problem. Men i forbindelse med manuelle overvågningsprocesser kan den pænere formatering være nyttig.

Overvejelser i forbindelse med brug af REST API'er direkte

Nogle gange er der fordele ved at kalde REST API'erne til Power BI direkte.

• Mange flere TILGÆNGELIGE API'er: Der er flere TILGÆNGELIGE REST API'er end PowerShell-cmdlet'er. Du må dog ikke overse fleksibiliteten i cmdlet'en Invoke-PowerBIRestMethod , som du kan bruge til at kalde en af REST API'erne til Power BI.
• Hyppigheden af opdateringer: Microsoft opdaterer REST API'erne oftere, end det opdaterer PowerShell-modulerne. Hvis der f.eks. føjes en ny attribut til API-svaret Get Dataset , kan det tage et stykke tid, før den bliver tilgængelig i resultaterne af Cmdlet'en Get-PowerBIDataset .
• Afhængighed af mindre sprog/værktøj: Når du bruger REST API'erne direkte (i stedet for en cmdlet), behøver du ikke at bruge PowerShell. Du kan også vælge kun at bruge PowerShell til at orkestrere kald til mange API'er i et script. Ved at fjerne (eller undgå) afhængighed af PowerShell kan du på et tidspunkt i fremtiden omskrive din logik på et andet sprog. Når it- eller udviklerteamet har stærke præferencer for værktøjer og sprog, kan mindre afhængighed være en vigtig overvejelse at tage højde for.

Uanset hvilken metode du vælger at bruge, kan REST API'erne ændres over tid. Når en teknologi udvikler sig, kan API'er (og PowerShell-moduler) frarådes og erstattes. Derfor anbefaler vi, at du målrettet opretter scripts, der er enkle at vedligeholde og robuste at ændre.

Tjekliste – Når du vælger, om du vil have adgang til REST API'erne direkte eller ved hjælp af PowerShell-cmdlet'er, omfatter vigtige beslutninger og handlinger:

• Råd dig om brugen af PowerShell: Kontakt de relevante it-team for at finde ud af, om der er eksisterende interne krav eller indstillinger for, hvordan PowerShell kan bruges.
• Beslut, hvordan du vil bruge PowerShell-: Find ud af, hvilke PowerShell-teknikker der skal bruges, og om du bevidst vil øge eller reducere din afhængighed af PowerShell. Overvej, om intern kommunikation eller uddannelse er nødvendig.
• Opgrader til PowerShell Core: Research ved hjælp af PowerShell Core. Find ud af, om administratorcomputere skal opdateres. Overvej, hvilke eksisterende scripts der skal testes. Find ud af, om administratorer eller udviklere har brug for yderligere oplæring for at opgradere deres færdigheder.
• Find ud af, hvilke PowerShell-moduler der skal bruges: Overvej, om Power BI-administrationsmodulerne og/eller datagatewaymodulet skal bruges.
• Beslut, om communityprojekter er tilladt: Find ud af, om du har tilladelse (eller endda opfordres) til at bruge PowerShell-moduler, der er tilgængelige online (i forhold til moduler, der er publiceret af Microsoft). Rådfør dig med it-tjenesten for at finde ud af, om der er kriterier for communityprojekter, der opnås online.
• Klargør, hvordan du understøtter communityprojekter: Hvis PowerShell-communityprojekter er tilladt, kan du overveje, hvem der er ansvarlig for at understøtte dem, når de bruges internt.
• Fuldføre en lille blåstempling: Eksperimentér med en teknisk BLÅS. Bekræft dine foretrukne klientværktøjer og -metode til at få adgang til data.
• Find ud af, hvordan du understøtter erfarne brugere: Overvej, hvordan du vil understøtte tekniske brugere, der selv opretter automatisering ved hjælp af bruger-API'erne.

Find ud af, hvor overvågningsdata skal gemmes

Når du planlægger at oprette en end-to-end-overvågningsløsning, skal du beslutte, hvor rådata skal gemmes (og de udvalgte data, som beskrives i næste afsnit). Dine beslutninger om datalager er relateret til dine præferencer for, hvordan du håndterer dataintegration.

Når du udtrækker rå overvågningsdata, skal du gøre det enkelt. Vi anbefaler, at du ikke vælger bestemte attributter, udfører transformationer eller anvender formatering, når du først udtrækker dataene. Udtræk i stedet alle tilgængelige attributter, og gem dataene i den oprindelige tilstand.

Her er flere grunde til, at lagring af rådata i sin oprindelige tilstand er bedste praksis.

• Alle data, der er tilgængelige i oversigten: Nye attributter og nye hændelsestyper bliver tilgængelige over tid. Lagring af alle rådata er en god måde at sikre, at du altid har adgang til de data, der var tilgængelige på det tidspunkt, hvor du udtrækkede dem. Selv når det tager dig tid – som kan være uger eller måneder – til at indse, at nye dataattributter er tilgængelige, er det muligt at analysere dem historisk, fordi du har hentet dem i rådata.
• Modstandsdygtig over for at ændre: Hvis rådataformatet ændres, påvirkes den proces, der udtrækker dataene, ikke. Da nogle overvågningsdata er tidsfølsomme, er det vigtigt at sikre, at du designer en dataudtrækningsproces, der ikke mislykkes, når der sker en ændring i kilden.
• roller og ansvarsområder: Forskellige teammedlemmer (f.eks. datateknikere eller Fabric-administratorer) kan være ansvarlige for at oprette processerne for at få adgang til, udtrække og gemme de rå overvågningsdata. Forenkling af dataudtrækningsprocessen gør det nemmere for flere teams at arbejde sammen.

Her er nogle muligheder for at gemme rådata.

• Data lake- eller objektlager: En cloudtjeneste, f.eks. OneLake-, der specialiserer sig i lagring af filer i en hvilken som helst struktur. Det er et ideelt valg til lagring af rå overvågningsdata. I en datasøarkitektur skal rådata gemmes i bronzelaget.
• Filsystem: Et filsystem (f.eks. Windows eller Linux) er et almindeligt valg til lagring af rå overvågningsdata.
• database: Det er muligt at gemme JSON-data i en relationsdatabase, f.eks. Azure SQL Database. Det er dog mindre almindeligt end at gemme dataene i en datasø eller et filsystem. Det skyldes, at det kan blive udfordrende og dyrt at forespørge og vedligeholde JSON-data, især i takt med at datamængderne vokser.

Tip

Når du bruger en datasø, et objektlager eller et filsystem, anbefaler vi, at du gemmer dataene på en måde, der er nem at organisere og sikre. Det er også vigtigt at være klar over, om dataene består af hændelser (som typisk tilføjes), eller om det er et øjebliksbillede på et tidspunkt (hvilket kræver, at du vælger en dato, der skal analyseres).

Overvej et eksempel, der involverer en rå datazone for en datasø. Zonen har et mappehierarki til lagring af aktivitetslogdata: Raw > ActivityLog > ÅÅÅÅ > MM. Mapperne partitioneres efter år og måned. En fil, der er gemt i mappen måned, har følgende format: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDD repræsenterer de faktiske data, og YYYYMMDDTTTT repræsenterer tidsstemplet for udtrækning. Ved at medtage tidsstemplet for udtrækning kan du afgøre, hvilken fil der er den nyeste (hvis du skal udtrække dataene igen). Hvis du f.eks. udtrækker data kl. 9 (UTC) den 25. april 2023 for aktivitet den 23. april 2023, vil filnavnet være PBIActivityLog-20230523-202305250900.

Vi anbefaler på det kraftigste, at du bruger en teknologi, der giver dig mulighed for at skrive rådata til uforanderligt lager. Uforanderligt lager garanterer, at når dataene er skrevet, kan de ikke overskrives eller slettes. Denne skelnen er vigtig for revisorer, og den giver dig mulighed for at stole på, at rådata er pålidelige.

Du skal også overveje, hvordan du sikkert gemmer rådata. Typisk kræver meget få brugere adgang til rådata. Adgang til rådata leveres typisk efter behov, typisk for datateknikere og systemadministratorer. Dine interne auditører skal muligvis også have adgang. De teammedlemmer, der er ansvarlige for at oprette de udvalgte data (beskrevet næste), kræver også adgang til rådata.

Her er nogle overvejelser, der kan hjælpe dig med at vælge dit rådatalager.

• Er det en manuel eller automatiseret overvågningsproces? En automatiseret overvågningsproces har typisk strengere krav til, hvordan og hvor data gemmes.
• Er emnet særligt følsomt? Afhængigt af typen af data og hvor følsom den er, kan din organisation have et krav til, hvordan og hvor de er gemt. Power BI-overvågningsdata indeholder identificerende brugeroplysninger og IP-adresser, så de skal gemmes i et sikkert område.
• Er der en foretrukken lagerteknologi? Der kan være en eksisterende lagerteknologi, der er i brug i organisationen, så det er et logisk valg.
• Får brugerne adgang til lageret direkte? Sikkerhedsmodellen er en vigtig overvejelse. Normalt får meget få brugere adgang til rådata. Adgang til de organiserede data bliver typisk gjort tilgængelige for Power BI-indholdsforfattere, der er ansvarlige for at oprette den centraliserede datamodel (den semantiske model, der fungerer som laget til rapportering).
• Har du krav til dataopbevaring? Nogle organisationer har juridiske eller lovmæssige krav til dataopbevaring for at gemme data i et bestemt dataområde.
• Hvordan organiseres dataene? Brug af medaljonsarkitekturen er en almindelig praksis, især i implementeringer af data lake og lakehouse. Målet er at gemme dine data i datalag af bronze, sølv og guld. Bronzelaget indeholder de oprindelige rådata. Sølvlaget indeholder validerede og deduplikerede data, der bruges til transformationer. Guldlaget indeholder de udvalgte, yderst raffinerede data, der er klar til analyse.

Tjekliste – Når du planlægger placeringen til lagring af rådata, omfatter vigtige beslutninger og handlinger:

• Kontakt it-: Kontakt de relevante it-team for at finde ud af, om der kører eksisterende processer for at udtrække de rå overvågningsdata. Hvis det er tilfældet, skal du finde ud af, om du kan få adgang til de eksisterende data. Hvis der kræves en ny dataudtrækningsproces, skal du afgøre, om der er præferencer eller krav til, hvor dataene skal gemmes.
• Beslut, hvor rådata skal gemmes: Find den bedste lagringsplacering og -struktur til lagring af rådata.
• Fastlæg krav til dataopbevaring: Find ud af, om der er juridiske eller lovmæssige krav til, hvor dataene kan gemmes.
• Opret en mappestruktur og navngivningskonvention: Find ud af, hvilken navngivningskonvention der skal bruges til rådatafiler, herunder mappestrukturen. Medtag disse oplysninger i din tekniske dokumentation.
• Overvej, hvordan sikkerhed for rådata fungerer: Mens du designer lagringsplaceringen for rådata, skal du overveje, hvem der skal have adgang til dataene, og hvordan adgang tildeles.

Planlæg at oprette udvalgte data

Organiserede data understøtter analyse og er designet til at være brugervenlige. Du skal træffe nogle beslutninger om, hvordan og hvor organiserede data oprettes. Den teknologi, du vælger at gemme de udvalgte data, kan være en af de teknologier, der er angivet i forrige afsnit.

Målet med udvalgte data er at transformere dataene til et mere brugervenligt format, der er optimeret til analyse og rapportering. Den udgør datakilden for en Power BI-datamodel, så det betyder, at du bruger en Power BI-datamodel til at analysere brugen af Power BI i din organisation. Grundlæggende vejledning til datamodeller gælder: Du skal anvende et stjerneskemadesign, som er optimeret til ydeevne og anvendelighed.

Du kan vælge at oprette udvalgte data på forskellige måder. Du skal beslutte, hvordan dataintegration skal udføres, og hvor langt upstream du vil anvende de transformationer, der forbereder dataene til indlæsning i et stjerneskema.

Datasø

Du kan anvende transformationer og oprette udvalgte datafiler i en datasø. Du skal bruge et guldlag til udvalgte data, så de er logisk adskilt fra de rådata, der er gemt i bronzelaget. Adskillelse af dataene i lag forenkler også angivelse af forskellige brugeradgangstilladelser.

Brug en datasø til at transformere og organisere dataene, når:

• Du forventer, at der vil være flere Power BI-datamodeller, der betjener rapportering (hvilket berettiger oprettelsen af et mellemliggende sølvlag).
• Du skal understøtte flere selvbetjente indholdsoprettere, der har brug for adgang til overvågningsdata på lejerniveau.
• Du har eksisterende værktøjer og processer, som du vil bruge til at transformere og indlæse data.
• Du vil minimere den dataforberedelse, der skal udføres (og muligvis duplikeres) i en eller flere Power BI-datamodeller.

Power BI-datamodel

Du kan muligvis fuldføre alt transformationsarbejdet i Power BI. Brug Power Query til at få adgang til og transformere dataene fra dens rå tilstand til det organiserede format.

Brug en Power BI-datamodel, når:

• Du vil forenkle arkitekturen fra ende til anden og indlæse datamodellen direkte fra rådata. Trinvis opdatering kan hjælpe med at reducere opdateringsvarigheden.
• Du foretrækker at udføre alt transformationsarbejdet, mens du indlæser datamodellen.
• Du forventer at have én central datamodel for overvågningsdataene på lejerniveau. Alle rapporter (eller andre datamodeller) kan bruge den centraliserede semantiske Power BI-model som kilde.
• Du vil kun give brugeren adgang til den centraliserede semantiske Power BI-model (og ikke til nogen af kildedataene).

Tip

Når du opretter de udvalgte data, skal du konfigurere dem på en måde, så du nemt kan køre processen igen for tidligere datointervaller. Hvis du f.eks. opdager, at der blev vist en ny attribut i overvågningsloggene for tre måneder siden, skal du kunne analysere den, siden den blev vist første gang. Muligheden for at genindlæse den organiserede datahistorik er en af flere årsager til, at det er vigtigt at gemme rådata i sin oprindelige tilstand (beskrevet tidligere i denne artikel).

Du kan få flere oplysninger om, hvilke dimensionstabeller og faktatabeller du kan inkludere i stjerneskemaet, i Opret en datamodel senere i denne artikel.

Tjekliste – Når du planlægger, hvordan du opretter udvalgte data, omfatter vigtige beslutninger og handlinger:

• Beslut, hvor transformationer skal udføres: Overvej, hvor langt opstrøms transformationsarbejdet skal udføres, og hvor det passer ind i din plan for hele arkitekturen.
• Beslut, hvilket værktøj der skal bruges til at transformere dataene til et stjerneskema: Bekræft, hvilke værktøjer og tjenester der skal bruges til at transformere rådata til udvalgte data.
• Beslut, hvor udvalgte data skal gemmes: Find det bedste valg til lagring af rådata, der er blevet transformeret til et stjerneskemaformat. Beslut, om et mellemliggende sølvlag er nyttigt i arkitekturen fra ende til anden.
• Opret en navngivningskonvention: Find ud af, hvilken navngivningskonvention der skal bruges til udvalgte datafiler og mapper (hvis relevant). Medtag oplysningerne i din tekniske dokumentation.
• Overvej, hvordan sikkerhed for udvalgte data fungerer: Overvej, hvem der skal have adgang til dataene, og hvordan sikkerheden tildeles, mens du designer placeringen af det organiserede datalager.

Beslutninger om datakilder

På dette tidspunkt skal du være klar over krav, databehov og tilladelser. Der er truffet vigtige tekniske beslutninger. Du skal nu træffe nogle beslutninger om tilgangen til, hvordan du får visse typer data.

Få adgang til brugeraktivitetsdata

Power BI-brugeraktivitetsdataene, som nogle gange kaldes aktivitetsloggen eller overvågningslogge, indeholder et væld af oplysninger, der kan hjælpe dig med at forstå, hvad der sker i din Power BI-lejer. Du kan finde flere oplysninger om, hvordan du identificerer dine databehov, under Brugeraktivitetsdata tidligere i denne artikel.

Power BI integrerer sine logge med Microsoft Purview Unified Audit Log (tidligere kendt som Microsoft 365 Unified Audit Log). Denne integration er en fordel, fordi det betyder, at hver tjeneste i Microsoft 365 ikke behøver at implementere sin egen unikke måde at logge på. Den er som standard aktiveret.

Vigtigt

Hvis du ikke allerede udtrækker brugeraktivitetsdata, skal du gøre det til en vigtig prioritet. Brugeraktivitetsdataene er tilgængelige for de seneste 30 eller 90 dage (afhængigt af kilden). Selv når du ikke er klar til at foretage dybdegående analyser, er det vigtigt at begynde at udtrække og gemme dataene så hurtigt som muligt. På den måde vil værdifuld historik være tilgængelig til analyse.

Du har flere muligheder for at hente brugeraktivitetsdata.

Teknik	Beskrivelse	Tilgængelige standarddage med historik	Godt valg til manuelle overvågningsprocesser	Godt valg til automatiserede overvågningsprocesser	Godt valg til at konfigurere beskeder	Godt valg til hurtigt at komme i gang
Manuel (brugergrænseflade)	Microsoft Purview-overholdelsesportal	90
Manuel (brugergrænseflade)	Defender for Cloud Apps	30
Programmatisk	Power BI-aktivitetslog (API eller PowerShell-cmdlet)	30
Programmatisk	Office 365 Management Activity API	7
Programmatisk	Microsoft Sentinel (Azure Monitor)	30

I resten af dette afsnit introduceres hver af de teknikker, der præsenteres i tabellen.

Microsoft Purview-overholdelsesportal

Søgeværktøjet til overvågning i Microsoft Purview-compliance-portal (tidligere kaldet Microsoft 365 Compliance Center) er et praktisk sted at få vist aktiviteter og beskeder. Dette værktøj kræver ikke, at du opretter et script for at udtrække og downloade dataene. Du kan vælge en Power BI-arbejdsbelastning for at få vist alle overvågningslogposterne i et tidsrum. Du kan også indsnævre resultaterne ved at vælge bestemte aktiviteter og brugere. En leder beder dig f.eks. om at finde ud af, hvem der har slettet et arbejdsområde tidligere på dagen, så vedkommende hurtigt kan kontakte personen for at drøfte situationen.

De seneste 90 dages historik er tilgængelige med Overvågning (Standard). Med Audit (Premium) giver langsigtet opbevaring dig mulighed for (eventuelt) at bevare overvågningslogge længere. Da langtidsopbevaring kun gælder for licenserede E5-brugere, udelukker den overvågningsposter for ikke-E5-brugere og gæstebrugere. Vi anbefaler derfor, at du kun bruger standardhistorikken på 90 dage for at sikre, at al aktivitet registreres.

Der er licenskrav for at få adgang til overvågningslogfilerne i Microsoft Purview-compliance-portal. Der kræves også administratorrettigheder til Exchange Online for at få adgang til overvågningslogfilerne.

Tip

Power BI-administratorer har som standard ikke tilladelse til at få adgang til den samlede søgning i overvågningsloggen i Microsoft Purview-compliance-portal. Da den indeholder data til mange Microsoft 365-tjenester, er det en rolle med mange rettigheder. I de fleste organisationer er disse tilladelser reserveret til et mindre antal it-administratorer. Power BI-administratorer har andre muligheder, som beskrives senere i dette afsnit.

Brugergrænsefladen i Microsoft Purview-compliance-portal er nyttig til manuelle overvågningsprocesser og lejlighedsvise undersøgelser af brugeraktiviteter.

Defender for Cloud Apps

Portalen i Defender for Cloud Apps er et praktisk sted at få vist aktiviteter og beskeder uden at skulle oprette et script for at udtrække og downloade dataene. Det giver dig også mulighed for at få vist data fra Power BI-aktivitetsloggen og brugerlogon.

Defender for Cloud Apps indeholder en brugergrænseflade til at få vist og søge efter aktivitetslogge for forskellige cloudtjenester, herunder Power BI. Den viser de samme loghændelser, der stammer fra Microsoft Purview Unified Audit Log, og den indeholder andre hændelser, f.eks. brugerlogonaktivitet fra Microsoft Entra ID.

På samme måde som Microsoft Purview-compliance-portal (beskrevet i forrige afsnit) har Defender for Cloud Apps en brugergrænseflade, der kan søges i. Filterindstillingerne er dog forskellige. Ud over 30-dages standardhistorikken kan du bruge Defender for Cloud Apps til at få vist op til seks måneders aktivitetsloghistorik (i trin på syv dage).

Der er licenskrav for at få adgang til Defender for Cloud Apps. Der kræves også separate tilladelser .

Tip

Power BI-administratorer har som standard ikke tilladelse til at få adgang til Defender for Cloud Apps. Der er en Power BI-rolle i Defender for Cloud Apps. Tilføjelse af Power BI-administratorer til denne rolle er en god måde at give dem adgang til et begrænset datasæt på.

Brugergrænsefladen i Defender for Cloud Apps er nyttig til manuelle overvågningsprocesser og engangsundersøgelser af brugeraktiviteter.

Power BI-aktivitetslog

Power BI-aktivitetsloggen stammer fra den samlede overvågningslog. Den indeholder kun brugeraktiviteter, der er relateret til Power BI-tjeneste.

Tip

For organisationer, der planlægger at udtrække brugeraktiviteter, anbefaler vi, at de starter med Power BI-aktivitetsloggen. Det er den nemmeste kilde til programmatisk adgang.

Du har to muligheder for at få adgang til Power BI-aktivitetsloggen.

• Kald REST API'en hent aktivitetshændelser ved hjælp af det valgte værktøj.
• Brug PowerShell-cmdlet'en Get-PowerBIActivityEvent . Den er tilgængelig fra administrationsmodulet i Power BI.

Du kan få oplysninger om, hvilken indstilling du skal bruge, under Vælg API'er eller PowerShell-cmdlet'er tidligere i denne artikel.

Tip

Du kan se eksempler på, hvordan du får adgang til Power BI-aktivitetsloggen med PowerShell, i Få adgang til Power BI-aktivitetsloggen.

Power BI-aktivitetslogdata er tilgængelige for alle Fabric-administratorer og Power Platform-administratorer. Du kan få adgang til dataene fra den samlede overvågningslog, der er tilgængelig for visse Exchange Online-roller. Du kan finde flere oplysninger under Spor brugeraktiviteter i Power BI.

Vi anbefaler, at du bruger Power BI-aktivitetsloggen, når du kun vil hente Power BI-overvågningslogposter.

Bemærk

I overvågningsloggens data kaldes arbejdsområder mapper. I Power BI REST API kaldes arbejdsområder for grupper.

Office 365 Management Activity API

Du kan udtrække data fra den samlede overvågningslog for andre tjenester, f.eks. SharePoint Online, Teams, Exchange Online, Dynamics 365 og Power BI. Når dit mål er at implementere en overvågnings- og overvågningsløsning for flere tjenester, anbefaler vi, at du bruger API'en til Office 365 Management Activity. Da denne API returnerer data fra mange tjenester, kaldes den Unified Auditing API (eller den samlede overvågningslog). Det er et af API'erne til Administration af Office 365.

Før du opretter en ny løsning, anbefaler vi, at du kontakter it-afdelingen for at finde ud af, om eksisterende Power BI-overvågningsposter er tilgængelige. Det er muligt, at en proces allerede udtrækker og gemmer dataene. Det er også muligt, at du får tilladelse til at få adgang til disse data i stedet for at oprette en ny løsning.

Du kan få adgang til dataene på en af to måder.

• Kald API'en til Office 365 Management Activity direkte ved hjælp af det valgte værktøj. SOM standard returnerer API'en 24 timers data. Du kan maksimalt hente syv dages historik.
• Brug PowerShell-cmdlet'en Search-UnifiedAuditLog . Det er en Exchange Online PowerShell-cmdlet. Du kan maksimalt hente 90 dages historik.

Vigtigt

Cmdlet'en Search-UnifiedAuditLog skaleres ikke godt, og det kræver, at du implementerer en løkkestrategi for at overvinde grænsen på 5.000 rækker. Af disse årsager er den velegnet til lejlighedsvise forespørgsler eller til små organisationer, der oplever lav aktivitet. Når du kun har brug for Power BI-data, anbefaler vi, at du bruger cmdlet'en Get-PowerBIActivityEvent i stedet for.

Generelt er det mere udfordrende at komme i gang med Office 365 Management Activity API end at bruge Power BI-aktivitetsloggen (beskrevet tidligere). Det skyldes, at API'en returnerer indholds-blobs, og at hver indholdsblob indeholder individuelle overvågningsposter. For store organisationer kan der være tusindvis af indholds-blobs pr. dag. Da kunder og tredjepartsprogrammer bruger denne API i høj grad, implementerer Microsoft begrænsning for at sikre, at deres brug af tjenesten ikke påvirker andre negativt (kaldet det støjende naboproblem ). Derfor kan det være en udfordring i større organisationer at hente store mængder historik. Du kan få flere oplysninger i denne artikel om fejlfinding.

Hvis du vil bruge denne API, skal du godkende med en tjenesteprincipal, der er tildelt tilladelse til at hente data fra API'en til Office 365 Management Activity.

Tip

Power BI-administratorer har som standard ikke tilladelse til at få adgang til API'en til Office 365 Management Activity. Da den indeholder data til mange Microsoft 365-tjenester, kræver adgang administrator- eller overvågningsroller med høj rettighed. I de fleste organisationer er disse roller reserveret til et lille antal it-administratorer. Power BI-aktivitetsloggen er beregnet til brug af Power BI-administratorer.

Det er et godt valg at hente overvågningsdataene programmeringsmæssigt fra API'en til Office 365 Management Activity, når it-virksomheden skal udtrække og gemme overvågningslogge fra forskellige tjenester (ud over Power BI).

Microsoft Sentinel

Microsoft Sentinel er en Azure-tjeneste, der giver dig mulighed for at indsamle, registrere, undersøge og reagere på sikkerhedshændelser og trusler. Du kan konfigurere Power BI i Microsoft Sentinel som en dataconnector. Når der er oprettet forbindelse, streames overvågningslogge (der indeholder et undersæt af data) fra Power BI til Azure Log Analytics, hvilket er en funktion i Azure Monitor.

Tip

Azure Log Analytics er baseret på den samme arkitektur, der bruges af hændelsesloggene for semantiske modeller på arbejdsområdeniveau. Du kan finde flere oplysninger om logfiler for semantiske modelhændelser under Overvågning på dataniveau.

Da det er en separat Azure-tjeneste, skal alle administratorer eller brugere, du vil køre KQL-forespørgsler (Kusto Query Language ), tildeles tilladelser i Azure Log Analytics (Azure Monitor). Når de har tilladelse, kan de forespørge om de overvågningsdata, der er gemt i tabellen PowerBIActivity . Husk dog, at du i de fleste tilfælde giver brugerne adgang til de udvalgte data i guldlaget i stedet for rådataene i bronzelaget.

Du bruger KQL til at analysere de aktivitetsloghændelser, der er gemt i Azure Log Analytics. Hvis du har SQL-erfaring, kan du finde mange ligheder med KQL.

Der er flere måder at få adgang til de hændelser, der er gemt i Azure Log Analytics. Du kan bruge:

• Det færdigbyggede skabelonprogram Log Analytics for Power BI Semantic Models .
• Power BI Desktop-connector til Azure Data Explorer (Kusto).
• Webbaseret forespørgselsoplevelse i Azure Data Explorer.
• Ethvert forespørgselsværktøj, der kan sende KQL-forespørgsler.

Advarsel

Vær opmærksom på, at kun et undersæt af power BI-aktivitetsloggens data gemmes i Azure Monitor. Når du planlægger at foretage en omfattende analyse af Power BI-forbrug og -implementering i organisationen, anbefaler vi, at du bruger andre indstillinger (beskrevet tidligere i dette afsnit) til at hente aktivitetsdata.

Den historikperiode, du kan hente, afhænger af politikken for dataopbevaring for Azure Log Analytics-arbejdsområdet. Overvej omkostninger og adgang til rådata, når du beslutter dig for, hvor mange data der skal opbevares.

Microsoft Sentinel og Azure Monitor er gode muligheder, når it-virksomheden allerede har foretaget en investering med Microsoft Sentinel, hvor detaljerede oplysninger der registreres, opfylder dine behov, og aktiviteter som trusselsregistrering er en prioritet. Da Microsoft Sentinel ikke registrerer alle Power BI-aktivitetsdata, understøtter det dog ikke udførelse af omfattende analyser af Power BI-brug og -implementering.

Overvejelser i forbindelse med brugeraktivitetsdata

Her er nogle overvejelser, der kan hjælpe dig med at vælge din kilde til brugeraktivitetsdata.

• Vil det være en manuel eller automatiseret overvågningsproces? Indstillingerne for brugergrænsefladen fungerer godt i forbindelse med manuelle overvågningsprocesser og lejlighedsvise engangsforespørgsler, især når du har brug for at undersøge en bestemt aktivitet. En automatiseret overvågningsproces, der udtrækker brugeraktivitetsdata efter en tidsplan, er også nødvendig for at understøtte historiske dataanalyser.
• Hvor ofte har du brug for brugeraktivitetsdataene? I forbindelse med automatiserede overvågningsprocesser skal du planlægge at udtrække data, der er mindst én dag før dags dato, ved hjælp af UTC (Coordinated Universal Time) i stedet for din lokale tid. Hvis din proces f.eks. kører fredag morgen (UTC-tid), skal du udtrække data fra onsdag. Der er flere grunde til, at du bør udtrække data med en dags ventetid.
  • Dine filer bliver nemmere at arbejde med, når du altid udtrækker hele 24 timer ad gangen, hvilket forhindrer delvise dagsresultater.
  • Du minimerer risikoen for manglende overvågningshændelser. Normalt ankommer overvågningshændelser inden for 30 minutter. Nogle hændelser kan nogle gange tage op til 24 timer, før de ankommer til den samlede overvågningslog.
• Har du brug for mere end Power BI-data? Overvej den mest effektive måde at få adgang til det, du har brug for.
  • Når du kun har brug for Power BI-brugeraktivitetsdata, skal du bruge Power BI-aktivitetsloggen.
  • Når du har brug for overvågningslogge fra flere tjenester, kan du bruge API'en til Office 365 Management Activity til at få adgang til den samlede overvågningslog.
• Hvem skal udvikle løsningen? Planlæg at investere noget tid i at bygge løsningen ud. Det kan tage en betydelig indsats at producere et produktionsklart script.

Tjekliste – Når du planlægger, hvordan du får adgang til brugeraktivitetsdata, omfatter vigtige beslutninger og handlinger:

• Tydeliggør omfanget af behov: Find ud af, om du kun har brug for at få adgang til Power BI-overvågningsposter eller overvågningsdata for flere tjenester.
• Kontakt it-: Find ud af, om it-virksomheden i øjeblikket udtrækker overvågningslogge, og om det er muligt at få adgang til rådata, så du ikke behøver at oprette en ny løsning.
• Beslut, om en datakilde: Find den bedste kilde, der skal bruges til at få adgang til brugeraktivitetsdata.
• Udfylde en blåstempling: Planlæg at gennemføre en lille teknisk blåstempling. Brug den til at validere dine beslutninger om, hvordan den endelige løsning oprettes.
• Spor yderligere databehov: Du kan korrelere aktivitetslogdata med andre kilder for at forbedre værdien af dataene. Hold styr på disse salgsmuligheder, efterhånden som de opstår, så de kan føjes til projektets omfang.

Få adgang til lejerens lagerdata

En lejeroversigt er en uvurderlig og nødvendig del af en moden overvågnings- og overvågningsløsning. Det hjælper dig med at forstå, hvilke arbejdsområder og hvilket indhold (semantiske modeller, rapporter og andre elementer) der findes i Power BI, og det er et fremragende supplement til brugeraktivitetsdataene (beskrevet i forrige afsnit). Du kan finde flere oplysninger om, hvordan du identificerer dine databehov, i Lejeroversigt tidligere i denne artikel.

Brugeraktiviteter (tidligere beskrevet) er overvågede hændelser. de er en post over handlinger, som en bruger udførte på en bestemt dato og et bestemt klokkeslæt. Lejerlageret er dog anderledes. Lejerlageret er et snapshot på et givet tidspunkt. Den beskriver den aktuelle tilstand for alle publicerede elementer i Power BI-tjeneste på det tidspunkt, hvor du udtrækkede den.

Bemærk

Power BI REST API-dokumentation refererer til publicerede elementer som artefakter.

Tip

Mange organisationer finder det nyttigt at udtrække lejerlageret på samme tidspunkt på dagen hver uge.

Hvis du vil analysere, hvad der sker i din Power BI-lejer, skal du både bruge brugeraktivitetsdataene og lejeroversigten. Ved at kombinere dem kan du forstå, hvor meget indhold du har, og hvor det er placeret. Det giver dig også mulighed for at finde ubrugt eller underudnyttet indhold (fordi der ikke vil være nogen hændelser for det i aktivitetsloggen). Lejeroversigten hjælper dig også med at kompilere en liste over aktuelle navne for alle elementer, hvilket er nyttigt, når elementnavne ændres.

Du kan få flere oplysninger om værdien af lejerlageret i Lejerlager tidligere i denne artikel.

Tip

Du kan bruge Hent ubrugte artefakter som administrations-API til at søge efter elementer, der ikke har nogen brugeraktivitet inden for de seneste 30 dage. Du kan dog ikke tilpasse denne tidsperiode. Du kan f.eks. have kritisk indhold, der kun bruges kvartalsvis. Ved at kombinere dit lejerlager med brugeraktivitetsdataene kan du finde ubrugte elementer på måder, som du kan tilpasse.

Du kan hente lejerlagerdata på to forskellige måder.

Teknik	Beskrivelse	Bedst egnet til	Godt valg til manuelle overvågningsprocesser	Godt valg til automatiserede overvågningsprocesser
Programmatisk	Get Groups as Admin API'en eller Get-PowerBIWorkspace PowerShell-cmdlet'en kan levere en liste over arbejdsområder for hele lejeren. Du kan også inkludere individuelle elementer (f.eks. semantiske modeller og rapporter) pr. arbejdsområde.	Mindre organisationer eller lav datamængde
Programmatisk	Et sæt asynkrone administrations-API'er, der tilsammen kaldes API'er til metadatascanning eller scanner-API'er, kan returnere en liste over arbejdsområder og individuelle elementer. Du kan også inkludere detaljerede metadata (f.eks. tabeller, kolonner og målingsudtryk).	Organisationer med høj datamængde og/eller behov for at opnå detaljerede resultater

I resten af dette afsnit introduceres hver af de teknikker, der præsenteres i tabellen.

Cmdlet til grupperings-API'er eller arbejdsområder

Hvis du vil hente en liste over arbejdsområder, kan du bruge en af flere REST API'er, f.eks. API'en Hent grupper som administrator (ved hjælp af det valgte værktøj). Resultaterne omfatter ekstra metadata, f.eks. beskrivelsen, og om arbejdsområdet er gemt i en Premium-kapacitet.

Bemærk

Api'en med navnet indeholder ordgruppen som en reference til et arbejdsområde. Dette ord stammer fra den oprindelige Power BI-sikkerhedsmodel, der var afhængig af Microsoft 365-grupper. Selvom Power BI-sikkerhedsmodellen har udviklet sig markant i årenes løb, forbliver de eksisterende API-navne uændrede for at undgå at ødelægge eksisterende løsninger.

Get Groups as Admin REST-API'en indeholder den nyttige $expand parameter. Denne parameter giver dig mulighed for eventuelt at udvide resultaterne, så de indeholder en liste over elementer, der er publiceret i arbejdsområdet (f.eks. semantiske modeller og rapporter). Du kan også overføre users datatypen til $expand parameteren for at inkludere de brugere, der er tildelt til en arbejdsområderolle.

Du kan også bruge PowerShell-cmdlet'en Get-PowerBIWorkspace . Det er fra modulet Arbejdsområder til administration af Power BI. Når du angiver -Scope parameteren organization, fungerer den som API'en Get Groups as Admin . Cmdlet'en accepterer -Include også parameteren (som svarer til parameteren i REST-API'en) for at inkludere elementer, der er $expand publiceret i arbejdsområdet (f.eks. semantiske modeller og rapporter).

Tip

Ved at angive parametre kan du bruge cmdlet'en på forskellige måder. I dette afsnit fokuseres der på hentning af en oversigt over hele lejeren. Du kan få flere oplysninger om brug af -Scope parameteren under Vælg en bruger-API eller administrations-API tidligere i denne artikel.

Hvis du vil hjælpe dig med at vælge, hvilken indstilling du vil bruge, skal du se Vælg API'er eller PowerShell-cmdlet'er tidligere i denne artikel.

Get Groups as Admin REST-API'en eller Get-PowerBIWorkspace PowerShell-cmdlet'en er bedst egnet til manuelle overvågningsprocesser og engangsundersøgelser. Store organisationer med en høj datamængde finder typisk disse muligheder udfordrende at bruge. REST API'en og cmdlet'en udtrækker altid et komplet sæt data, så de kan tage lang tid at køre. Det er derfor også sandsynligt, at større organisationer vil støde på begrænsninger for antallet af tilladte anmodninger pr. time (kendt som begrænsning, hvilket gøres for at beskytte tjenestens tilstand). Metadatascannings-API'erne (beskrevet nedenfor) giver et mere pålideligt og skalerbart alternativ.

API'er til metadatascanning

Api'erne til scanning af metadata, der ofte kaldes scanner-API'er, er et sæt API'er, der returnerer en liste over arbejdsområder og deres Power BI-elementer (semantiske modeller, rapporter og andre elementer). Konceptuelt leverer de de samme data (og meget mere) som gruppe-API'erne eller arbejdsområde-cmdlet'en, som er beskrevet i det forrige afsnit. Den metode, du bruger til at hente dataene, er dog anderledes og bedre egnet til at udtrække lejerlageret.

Bemærk

Vær opmærksom på, hvordan nogle personer bruger udtrykket scanner-API'er eller udtrykket, der scanner lejeren. De bruger ofte disse vilkår til at betyde kompilering af en lejeroversigt, hvor der skelnes mellem det og brugeraktivitetshændelserne. De refererer måske bogstaveligt talt til brugen af API'erne til scanning af metadata.

Der er to primære årsager til, at du bør overveje at bruge API'erne til scanning af Get Groups as Admin metadata i stedet for REST-API'en eller cmdlet'en Get-PowerBIWorkspace (beskrevet tidligere).

• udtræk af trinvise data: Scanner-API'erne udtrækker kun data, der er ændret, siden den sidst blev kørt. Omvendt Get Groups as Admin er REST-API'en og cmdlet'en Get-PowerBIWorkspace synkrone handlinger, der udtrækker hele datasættet, hver gang de kører.
• Mere detaljeret detaljeniveau: Scanner-API'erne kan hente detaljerede detaljer (f.eks. tabeller, kolonner og målingsudtryk), hvilket giver tilladelse fra de to lejerindstillinger til detaljerede metadata. Omvendt er det laveste detaljeniveau, der er tilgængeligt med Get Groups as Admin REST-API'en og cmdlet'en Get-PowerBIWorkspace , efter elementtype (f.eks. en liste over rapporter i et arbejdsområde).

Det kræver en større indsats at bruge scanner-API'erne, fordi du skal kalde en række API'er. De kører også som en asynkron proces. En asynkron proces kører i baggrunden, så du ikke behøver at vente på, at den afsluttes. Du skal muligvis samarbejde med it-virksomheden eller en udvikler, når det er tid til at oprette et produktionsklart script, der skal planlægges.

Her er sekvensen af trin, som din proces skal følge, når du bruger scanner-API'erne.

1. Log på: Log på Power BI-tjenesten ved hjælp af en Power BI-administratorkonto eller en tjenesteprincipal, der har tilladelse til at køre administrator-API'er. Du kan finde flere oplysninger under Bestem godkendelsesmetoden tidligere i denne artikel.
2. Hent arbejdsområde-id'erne: Send en anmodning om at hente en liste over arbejdsområde-id'er. Første gang den køres, har du ikke en ændringsdato, så den returnerer en komplet liste over arbejdsområder. Normalt overfører du den ændrede dato for kun at hente arbejdsområder, der er ændret siden det pågældende tidspunkt. Den ændrede dato skal være inden for de sidste 30 dage.
3. Starte en metadatascanning: Start et kald for at anmode om en scanning af oplysninger om arbejdsområdet ved at overføre de arbejdsområde-id'er, der blev hentet i trin 2. Bemærk, at dette er en POST-API (i stedet for en GET-API , hvilket er mere almindeligt, når du henter overvågningsdata). En POST-API er en HTTP-anmodning, der opretter eller skriver data for en angivet ressource. Denne forespørgsel angiver det detaljeniveau, der udtrækkes, f.eks. oplysninger om datakilder, semantisk modelskema, semantiske modeludtryk eller brugere. Når den er sendt, returneres et id for scanningen af API'en. Den returnerer også datoen og klokkeslættet for scanningen, som du skal registrere som snapshotdatoen.
4. Kontrollér scanningsstatussen: Brug scannings-id'et i trin 3 til at få scanningsstatus. Du skal muligvis kalde denne API mere end én gang. Når den returnerede status er Lykkedes, kan du gå videre til næste trin. Den tid, det tager at scanne, afhænger af, hvor mange data du anmoder om.
5. Hent resultaterne: Brug det scannings-id, der blev hentet i trin 3, til at hente scanningsresultatet og udtrække dataene. Du skal udføre dette trin inden for 24 timer efter fuldførelsen af trin 4. Vær opmærksom på, at tidsstemplet for øjebliksbilledet skal korreleres med trin 3 i stedet for trin 5 (når der er en betydelig forsinkelse). På den måde får du et nøjagtigt tidsstempel for øjebliksbillede. Gem resultaterne på din foretrukne placering af datalageret. Som allerede beskrevet i denne artikel anbefaler vi, at du gemmer rådata i den oprindelige tilstand.
6. Forbered den næste proces: Registrer tidsstemplet for scanningen fra trin 3, så du kan bruge den i trin 2, næste gang du kører processen. På den måde udtrækker du kun data, der er ændret siden det tidspunkt. Fremover vil alle efterfølgende dataudtrækninger være trinvise ændringer i stedet for komplette snapshots.

Tjekliste – Når du planlægger at få adgang til lejerens lagerdata, omfatter vigtige beslutninger og handlinger:

• Bekræft krav: Tydeliggør behovet for at udarbejde en lejeroversigt og analysekravene til dataene.
• Beslut, hvor ofte lejerlageret skal udtrækkes: Bekræft, hvor ofte du skal bruge en ny lejeroversigt (f.eks. hver uge).
• Beslut, hvordan lejerlageret skal udtrækkes: Bekræft, hvilken metode du vil bruge til at hente lejerens lagerdata (API, cmdlet eller api'er til scanning af metadata).
• Udfylde en blåstempling: Planlæg at gennemføre en lille teknisk blåstempling. Brug den til at validere dine beslutninger om, hvordan den endelige løsning oprettes.

Få adgang til bruger- og gruppedata

Ud over de identificerende oplysninger (f.eks. en mailadresse), der er inkluderet i brugeraktivitetsdataene, er det værdifuldt at hente yderligere oplysninger, f.eks. placering eller organisationsoplysninger. Du kan bruge Microsoft Graph til at hente data om brugere, grupper, tjenesteprincipaler og licenser. Microsoft Graph består af en række API'er og klientbiblioteker, der giver dig mulighed for at hente overvågningsdata fra en lang række tjenester.

Her er nogle oplysninger om de Microsoft Entra-objekter, du kan få adgang til.

• Bruger: En identitet, der findes i Microsoft Entra ID som en arbejds-, skole- eller Microsoft-konto. Udtrykket domænebruger bruges ofte til at beskrive organisationsbrugere, mens det formelle ord er brugerens hovednavn (UPN). Et UPN er normalt den samme værdi som brugerens mailadresse (men hvis en mailadresse ændres, ændres UPN'et ikke, fordi det er uforanderligt). Der er også et entydigt Microsoft Graph-id for hver bruger. En brugerkonto er ofte knyttet til én person. Nogle organisationer opretter brugere, der er tjenestekonti , der bruges til automatiserede aktiviteter eller til administrative opgaver.
• Tjenesteprincipal: En anden type identitet, der klargøres, når du opretter en appregistrering. En tjenesteprincipal er beregnet til automatiske aktiviteter. Du kan finde flere oplysninger under Bestem godkendelsesmetoden tidligere i denne artikel.
• Gruppe: En samling af brugere og tjenesteprincipaler. Der er flere typer grupper , som du kan bruge til at forenkle administration af tilladelser. Du kan få mere at vide under Strategi for brug af grupper.

Bemærk

Når denne artikel refererer til brugere og grupper, omfatter dette begreb også tjenesteprincipaler. Denne kortere periode bruges til korthed.

De brugere og grupper af data, du henter, er et snapshot , der beskriver den aktuelle tilstand på et givet tidspunkt.

Tip

Du kan få flere oplysninger om brugere, tjenesteprincipaler og grupper under Integration med Microsoft Entra-id.

Analytiske attributter

I forbindelse med overvågning på lejerniveau i Power BI kan du udtrække og gemme følgende attributter fra Microsoft Graph.

• Fulde navn på brugere: Mange datakilder indeholder kun mailadressen på den bruger, der udførte en aktivitet, eller som er tildelt til en rolle. Brug denne attribut, når du vil have vist det fulde navn (vist navn) i analyserapporter. Brug af det fulde navn gør rapporter mere brugervenlige.
• Andre brugeregenskaber: Andre beskrivende attributter om brugere kan være tilgængelige i Microsoft Entra ID. Nogle eksempler på indbyggede brugerprofilattributter , der har analyseværdi, omfatter stilling, afdeling, leder, område og kontorplacering.
• Medlemmer af en sikkerhedsgruppe: De fleste datakilder angiver navnet på en gruppe (f.eks. poster i Power BI-aktivitetsloggen, som en sikkerhedsgruppe blev tildelt til en arbejdsområderolle). Hentning af gruppemedlemskabet forbedrer din mulighed for fuldt ud at analysere, hvad en enkelt bruger foretager sig eller har adgang til.
• brugerlicenser: Det er nyttigt at analysere, hvilke brugerlicenser– gratis, Power BI Pro eller Power BI Premium pr. bruger – der er tildelt til brugerne. Disse data kan hjælpe dig med at identificere, hvem der ikke bruger deres licens. Det hjælper dig også med at analysere alle brugere (særskilte brugere med en licens) i forhold til aktive brugere (med seneste aktiviteter). Hvis du overvejer at tilføje eller udvide dine Power BI Premium-licenser, anbefaler vi, at du analyserer brugerlicensdataene sammen med brugeraktivitetsdata for at udføre en omkostningsanalyse.
• Medlemmer af administratorrollerne: Du kan kompilere en liste over dine Power BI-administratorer (herunder Power Platform-administratorer).

Du kan finde den autoritative reference til Power BI-licensoplysninger, som du kan finde i overvågningsdataene fra Microsoft Graph, under Produktnavne og tjenesteplan-id'er for licensering.

Tip

Hentning af medlemmer fra grupper kan være et af de mest udfordrende aspekter ved at hente overvågningsdata. Du skal foretage en transitiv søgning for at flade alle indlejrede medlemmer og indlejrede grupper ud. Du kan foretage en transitiv søgning efter gruppemedlemmer. Denne type søgning er især udfordrende, når der er tusindvis af grupper i din organisation. I dette tilfælde kan der overvejes bedre alternativer til at hente dataene. En mulighed er at udtrække alle grupper og gruppemedlemmer fra Microsoft Graph. Det er dog muligvis ikke praktisk, når kun et lille antal grupper bruges til Power BI-sikkerhed. En anden mulighed er at oprette en referenceliste over grupper, der bruges af en hvilken som helst type Power BI-sikkerhed (arbejdsområderoller, apptilladelser, deling pr. element, sikkerhed på rækkeniveau m.m.). Du kan derefter gå gennem referencelisten for at hente gruppemedlemmer fra Microsoft Graph.

Her er nogle andre attributter, du kan udtrække og gemme.

• brugertype: Brugerne er enten medlemmer eller gæster. Medlemmer er oftest interne brugere, og gæster er eksterne brugere (B2B). Lagring af brugertype er nyttig, når du har brug for at analysere eksterne brugeres aktiviteter.
• rolleændringer: Når du udfører en sikkerhedsovervågning, er det nyttigt at forstå, hvornår en bruger har ændret roller i organisationen (f.eks. når de overføres til en anden afdeling). På den måde kan du kontrollere, om deres Power BI-sikkerhedsindstillinger er blevet – eller skal – opdateres.
• deaktiverede brugere: Når en bruger forlader organisationen, deaktiverer en administrator normalt sin konto. Du kan oprette en proces for at kontrollere, om deaktiverede brugere er arbejdsområdeadministratorer eller semantiske modelejere.

Tip

Power BI-aktivitetsloggen indeholder en hændelse, der registrerer, når en bruger tilmelder sig en prøvelicens. Du kan kombinere hændelsen med brugerlicensdataene (hentet fra Microsoft Entra ID) for at oprette et komplet billede.

Hent data for brugere og grupper

Du kan hente data om brugere og grupper på forskellige måder.

Teknik	Beskrivelse	Godt valg til manuelle overvågningsprocesser	Godt valg til automatiserede overvågningsprocesser
Manuelt	Graph-tester
Programmatisk	Microsoft Graph-API'er og SDK'er
Programmatisk	Az PowerShell-modul

I resten af dette afsnit introduceres hver af de teknikker, der præsenteres i tabellen. Andre teknikker, som frarådes og ikke bør bruges til nye løsninger, beskrives i slutningen af dette afsnit.

Bemærk

Vær forsigtig, når du læser oplysninger online, da mange værktøjsnavne er ens. Nogle værktøjer i Microsofts økosystem omfatter udtrykket Graph i deres navn, f.eks. Azure Resource Graph, GraphQL og Microsoft Security Graph API. Disse værktøjer er ikke relateret til Microsoft Graph, og de er ikke omfattet af denne artikel.

Microsoft Graph Explorer

Microsoft Graph Explorer er et udviklerværktøj, der giver dig mulighed for at få mere at vide om Microsoft Graph-API'er. Det er en nem måde at komme i gang på, fordi det ikke kræver andre værktøjer eller konfiguration på din computer. Du kan logge på for at hente data fra din lejer eller hente eksempeldata fra en standardlejer.

Du kan bruge Graph Explorer til at:

• Send manuelt en anmodning til en Microsoft Graph API for at kontrollere, om den returnerer de ønskede oplysninger.
• Se, hvordan du opretter URL-adressen, overskrifter og brødtekst, før du skriver et script.
• Kontrollér data på en uformel måde.
• Find ud af, hvilke tilladelser der kræves for hver API. Du kan også give samtykke til nye tilladelser.
• Hent kodestykker, der skal bruges, når du opretter scripts.

Brug dette link til at åbne Graph Explorer.

Microsoft Graph-API'er og SDK'er

Brug Microsoft Graph-API'erne til at hente data for brugere og grupper. Du kan også bruge den til at hente data fra tjenester som f.eks. Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook og meget mere.

Microsoft Graph-SDK'erne fungerer som en API-ombrydning oven på de underliggende Microsoft Graph-API'er. Et SDK er en softwareudviklingspakke , der samler værktøjer og funktionalitet. Microsoft Graph SDK'erne viser hele sættet af Microsoft Graph-API'er.

Du kan vælge at sende anmodninger direkte til API'erne. Du kan også tilføje et lag af forenkling ved hjælp af dit foretrukne sprog og et af SDK'erne. Du kan få flere oplysninger under Vælg API'er eller PowerShell-cmdlet'er tidligere i denne artikel.

Microsoft Graph SDK'erne understøtter flere sprog, og der er også Microsoft Graph PowerShell-modulerne . Andre SDK'er er tilgængelige til Python, C#og andre sprog.

Vigtigt

Microsoft Graph PowerShell-modulet erstatter Azure AD PowerShell-moduler og MSOL-moduler (MSOnline), som begge frarådes. Du bør ikke oprette nye løsninger med udfasede moduler. Microsoft Graph PowerShell-modulet indeholder mange funktioner og fordele. Du kan få flere oplysninger under Opgrader fra Azure AD PowerShell til Microsoft Graph PowerShell.

Du kan installere Microsoft Graph PowerShell-moduler fra PowerShell-galleriet. Da Microsoft Graph arbejder med mange Microsoft 365-tjenester, er der mange PowerShell-moduler, som du installerer.

Til overvågning på lejerniveau i Power BI er her de mest almindelige PowerShell-moduler, du skal installere.

• Godkendelse (til logon)
• Brugere
• Grupper
• Programmer (og tjenesteprincipaler)
• Mappeobjekter (og licensoplysninger)

Tip

Microsoft opdaterer Microsoft Graph PowerShell-modulerne regelmæssigt. Nogle gange gøres prøveversionsmoduler tilgængelige på forhånd eller et betaslutpunkt. Det kan være en god idé at angive den version, du er interesseret i, når du installerer og opdaterer modulerne. Når du gennemser onlinedokumentationen, skal du også være opmærksom på, at det aktuelle versionsnummer automatisk føjes til slutningen af URL-adressen (så vær forsigtig, når du gemmer eller deler URL-adresser).

Az PowerShell-modul

Du kan også bruge Az PowerShell-modulet til at hente data for brugere og grupper. Der fokuseres på Azure-ressourcer.

Vigtigt

Az PowerShell-modulet erstatter AzureRM PowerShell-modulerne, som frarådes. Du bør ikke oprette nye løsninger med udfasede moduler.

Du kan bruge cmdlet'en Invoke-AzRestMethod , når der ikke er en tilsvarende cmdlet til en API. Det er en fleksibel tilgang, der giver dig mulighed for at sende en anmodning til en hvilken som helst Microsoft Graph API ved hjælp af Az PowerShell-modulet.

Fra og med Az version 7 refererer Az-cmdlet'erne nu til Microsoft Graph-API'en. Derfor fungerer Az-modulet som en API-ombrydning oven på Microsoft Graph. Az-modulerne har en delmængde af funktionalitet, der er indeholdt i Microsoft Graph API'er og PowerShell-moduler. I forbindelse med nye løsninger anbefaler vi, at du bruger Microsoft Graph PowerShell SDK.

Frarådede API'er og moduler

Du kan finde artikler og blogindlæg online, der foreslår alternative indstillinger, der ikke er præsenteret i dette afsnit. Vi anbefaler på det kraftigste, at du ikke opretter nye løsninger (og/eller overfører dine eksisterende løsninger) ved hjælp af følgende API'er eller moduler.

• AzureRM PowerShell-moduler: Frarådes og udgår. De er blevet erstattet med Az PowerShell-modulet.
• Azure AD Graph API og Azure AD PowerShell-modulet: Frarådes og udgår. Denne ændring er resultatet af migreringen fra Azure AD Graph til Microsoft Graph (bemærk, at Graph vises i begge navne, men Microsoft Graph er den fremtidige retning). Alle fremtidige PowerShell-investeringer foretages i Microsoft Graph PowerShell SDK.
• MS Online (MSOL) PowerShell-modul: Frarådes og udgår. Alle fremtidige PowerShell-investeringer foretages i Microsoft Graph PowerShell SDK.

Advarsel

Sørg for at bekræfte status for en hvilken som helst udfaset API eller det frarådede modul, du bruger i øjeblikket. Du kan få flere oplysninger om udfasning af AzureRM i denne meddelelse.

Du kan få flere oplysninger om Microsoft Entra ID og MSOL i dette meddelelsesoplæg om ophør.

Hvis du har spørgsmål eller kræver præcisering af den fremtidige retning af programmatisk dataadgang, skal du kontakte dit Microsoft-kontoteam.

Tjekliste – Når du planlægger at få adgang til data for brugere og grupper, omfatter vigtige beslutninger og handlinger:

• Bekræft krav: Tydeliggør behovet for kompilering af data, der er relateret til brugere, grupper og licenser.
• Prioriter krav: Bekræft, hvad de vigtigste prioriteter er, så du ved, hvad du skal bruge tid på først.
• Beslut, hvor ofte data skal udtrækkes: Bestem, hvor ofte du skal bruge et nyt snapshot af brugerne og gruppere data (f.eks. hver uge eller hver måned).
• Beslut, hvordan du udtrækker data med Microsoft Graph: Find ud af, hvilken metode du skal bruge til at hente dataene.
• Fuldføre en blåstempling: Planlæg at gennemføre en lille teknisk blåstempling for at udtrække brugere og grupper af data. Brug den til at validere dine beslutninger om, hvordan den endelige løsning oprettes.

Få adgang til data fra REST API'er til Power BI

Måske kan du som en lavere prioritet også hente andre data ved hjælp af REST API'erne til Power BI.

Du kan f.eks. hente data om:

• Alle apps i organisationen.
• Alle importerede semantiske modeller i organisationen.
• Alle udrulningspipelines i organisationen.
• Alle Premium-kapaciteter i organisationen.

Under en sikkerhedsovervågning kan det være en god idé at identificere:

• Elementer, der er blevet delt med hele organisationen.
• Elementer, der er tilgængelige på det offentlige internet ved hjælp af Publicer på internettet.

Du kan få flere oplysninger om de andre typer API'er under Vælg en bruger-API eller administrations-API tidligere i denne artikel.

Tjekliste – Når du planlægger at få adgang til data fra Power BI-API, omfatter vigtige beslutninger og handlinger:

• Indhent krav: Kompiler analysekrav, efterhånden som de opstår. Hold styr på dem i din efterslæb.
• Prioriter krav: Angiv prioriteter for de nye krav, der opstår.

Fase 2: Forudsætninger og konfiguration

I den anden fase af planlægningen og implementeringen af en overvågningsløsning på lejerniveau fokuseres der på forudsætninger og konfiguration, der skal udføres, før du begynder at udvikle løsninger.

Opret lagerkonto

På dette tidspunkt har du besluttet dig for en placering, hvor du vil gemme rådata , og hvordan du opretter udvalgte data. På baggrund af disse beslutninger er du nu klar til at oprette en lagerkonto. Afhængigt af organisationens processer kan det omfatte indsendelse af en anmodning til it-virksomheden.

Som beskrevet tidligere anbefaler vi, at du bruger en teknologi, der giver dig mulighed for at skrive rådata til uforanderligt lager. Når dataene er skrevet, kan de ikke ændres eller slettes. Du kan derefter have tillid til rådata, fordi du ved, at en administrator med adgang ikke kan ændre dem på nogen måde. De udvalgte data behøver dog ikke (normalt) at blive gemt i uforanderligt lager. Organiserede data kan blive ændret, eller de kan gendannes.

Tjekliste – når du opretter en lagerkonto, omfatter vigtige beslutninger og handlinger:

• Opret en lagerkonto: Opret eller send en anmodning om oprettelse af en lagerkonto. Brug uforanderlige lagerindstillinger for rådata, når det er muligt.
• Angiv tilladelser: Find ud af, hvilke tilladelser der skal angives for lagerkontoen.
• Test adgang: Lav en lille test for at sikre, at du kan læse og skrive til lagerkontoen.
• Bekræft ansvar: Sørg for, at du er klar over, hvem der løbende administrerer lagerkontoen.

Installér software, og konfigurer tjenester

På dette tidspunkt har du truffet dine beslutninger om, hvilken teknologi der skal bruges til at få adgang til overvågningsdata. På baggrund af disse beslutninger er du nu klar til at installere software og konfigurere tjenester.

Konfigurer det foretrukne udviklingsmiljø for hver administrator. Udviklingsmiljøet giver dem mulighed for at skrive og teste scripts. Visual Studio Code er et moderne værktøj til udvikling af scripts, så det er en god mulighed. Der er også mange udvidelser tilgængelige til at arbejde med Visual Studio Code.

Hvis du har truffet beslutningen (tidligere beskrevet) om at bruge PowerShell, skal du installere PowerShell Core og de nødvendige PowerShell-moduler på:

• Maskinen for hver administrator/udvikler, der skal skrive eller teste overvågningsscripts.
• Hver virtuel maskine eller server, der kører planlagte scripts.
• Hver onlinetjeneste (f.eks. Azure Functions eller Azure Automation).

Hvis du har valgt at bruge Azure-tjenester (f.eks. Azure Functions, Azure Automation, Azure Data Factory eller Azure Synapse Analytics), skal du også klargøre og konfigurere dem.

Tjekliste – når du installerer software og konfigurerer tjenester, omfatter vigtige beslutninger og handlinger:

• Konfigurer administrator-/udviklercomputere: Installer de nødvendige værktøjer, der skal bruges til udvikling, hvis det er relevant.
• Konfigurer servere: Hvis det er relevant, skal du installere de nødvendige værktøjer på de servere eller virtuelle maskiner, der findes i din arkitektur.
• Konfigurer Azure-tjenester: Klargør og konfigurer hver Azure-tjeneste, hvis det er relevant. Tildel tilladelser til hver administrator/udvikler, der skal udføre udviklingsarbejde.

Registrer et Microsoft Entra-program

På dette tidspunkt har du besluttet , hvordan du skal godkende. Vi anbefaler, at du registrerer et Microsoft Entra-program (tjenesteprincipal). Den kaldes ofte en appregistrering og skal bruges til automatiske handlinger, som du automatiserer.

Du kan finde flere oplysninger om, hvordan du opretter en appregistrering for at hente overvågningsdata på lejerniveau, under Aktivér godkendelse af tjenesteprincipal for skrivebeskyttede administrator-API'er.

Tjekliste – Når du registrerer et Microsoft Entra-program, omfatter vigtige beslutninger og handlinger:

• Kontrollér, om der findes en eksisterende appregistrering: Kontrollér med it-programmet, om der er en eksisterende appregistrering tilgængelig til kørsel af administrations-API'er. Hvis det er tilfældet, skal du afgøre, om den eksisterende skal bruges, eller om der skal oprettes en ny.
• Opret en ny appregistrering: Opret en appregistrering, når det er relevant. Overvej at bruge et appnavn, f.eks . PowerBI-AdminAPIs-EntraApp, som tydeligt beskriver formålet med appen.
• Opret en hemmelighed for appregistreringen: Når appregistreringen findes, skal du oprette en hemmelighed for den. Angiv udløbsdatoen baseret på, hvor ofte du vil rotere hemmeligheden.
• Gem sikkert værdierne: Gem hemmeligheden, app-id'et (klient-id' et) og lejer-id'et, fordi du skal bruge dem til at godkende med tjenesteprincipalen. Brug en sikker placering, f.eks. en organisationsadgangskodeboks. Hvis du har brug for at anmode om oprettelse af en appregistrering fra it-tjenesten, skal du angive, at du skal have returneret disse værdier.
• Opret en sikkerhedsgruppe: Opret (eller anmod om) en sikkerhedsgruppe, der skal bruges til Power BI. Overvej at bruge gruppenavn, f.eks . Power BI-administratortjenesteprincipaler, hvilket betyder, at gruppen bruges til at få adgang til metadata for hele lejeren.
• Tilføj tjenesteprincipalen som medlem af sikkerhedsgruppen: Brug app-id'et (klient-id) til at tilføje den nye (eller eksisterende) tjenesteprincipal som medlem af den nye sikkerhedsgruppe.
• indstillingen Opdater API-lejer for administrator i Fabric: Føj sikkerhedsgruppen til Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er lejerindstillingen.
• Spring tildeling af tilladelser over i Azure: Undlad at delegere tilladelser til appregistreringen (den får adgang til Power BI-overvågningsdata på lejerniveau ved hjælp af Power BI-Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er lejerindstillingen).
• Beslut, om appregistreringen skal have adgang til detaljerede metadata: Find ud af, om du vil udtrække detaljerede oplysninger om semantiske modeltabeller, kolonner og målingsudtryk, når du opretter dit lejerlager.
• Opdater de detaljerede lejerindstillinger for metadata i Power BI: Du kan også føje sikkerhedsgruppen til Forbedre api-svar med detaljerede metadata lejerindstilling og også Forbedre API-svar til administratorer med DAX- og miksudtryk lejerindstilling.
• Test tjenesteprincipalen: Opret et simpelt script for at logge på ved hjælp af tjenesteprincipalen, og test, at den kan hente data fra en administrations-API.
• Opret en proces til administration af appregistreringshemmeligheder: Opret dokumentation og en proces for regelmæssigt at rotere hemmeligheder. Find ud af, hvordan du på en sikker måde kommunikerer en ny hemmelighed til administratorer og udviklere, der har brug for den.

Angiv indstillinger for Fabric-lejer

Der er flere lejerindstillinger på Fabric-administrationsportalen, der er relevante for udtrækning af overvågningsdata på lejerniveau.

Administrations-API'er

Der er tre lejerindstillinger, der er relevante for kørsel af administrations-API'er.

Vigtigt

Da disse indstillinger giver adgang til metadata for hele lejeren (uden at tildele direkte Power BI-tilladelser), skal du styre dem nøje.

Lejerindstillingen Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er giver dig mulighed for at angive, hvilke tjenesteprincipaler der kan kalde administrator-API'er. Denne indstilling gør det også muligt for Microsoft Purview at scanne hele Power BI-lejeren, så det kan udfylde datakataloget.

Bemærk

Du behøver ikke eksplicit at tildele andre Power BI-administratorer til lejerindstillingen Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er , fordi de allerede har adgang til metadata for hele lejeren.

Indstillingen Forbedr api-svar til administratorer med detaljerede metadatalejer giver dig mulighed for at angive, hvilke brugere og tjenesteprincipaler der kan hente detaljerede metadata. Metadata hentes ved hjælp af API'erne til metadatascanning, og de indeholder tabeller, kolonner og meget mere. Denne indstilling gør det også muligt for Microsoft Purview at få adgang til oplysninger på skemaniveau om semantiske Power BI-modeller, så de kan gemmes i datakataloget.

Lejerindstillingen Optimer api-svar til administratorer med DAX- og miksudtryk giver dig mulighed for at angive, hvilke brugere og tjenesteprincipaler der kan hente detaljerede metadata. Metadata hentes fra API'erne til metadatascanning, og de kan omfatte forespørgsler og målingsudtryk for semantiske modeller.

Bemærk

Lejerindstillingen Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er , handler specifikt om at få adgang til administrator-API'er. Navnet svarer meget til den lejerindstilling, der er beregnet til at få adgang til bruger-API'er (beskrevet næste). Du kan få flere oplysninger om forskellen mellem administrator-API'er og bruger-API'er under Vælg en bruger-API eller administrations-API tidligere i denne artikel.

Bruger-API'er

Der er én lejerindstilling, der gælder for kaldende bruger-API'er. I denne situation kræves Power BI-tilladelser også for tjenesteprincipalen (f.eks. en rolle i arbejdsområdet).

Indstillingen Tillad, at tjenesteprincipaler bruger lejerindstillingen Power BI-API s giver dig mulighed for at angive, hvilke tjenesteprincipaler der har adgang til at køre REST API'er (undtagen administrator-API'er, som tildeles af en anden lejerindstilling, som beskrevet ovenfor).

Der er andre lejerindstillinger, der er relateret til API'er, som giver adgang til api'er til integrering, streaming-API'er, eksport-API'er og API'en til udførelse af forespørgsler . Disse API'er er dog uden for denne artikels anvendelsesområde.

Du kan få flere oplysninger om lejerindstillingerne for forbrugsdata under Overvågning på rapportniveau.

tjekliste – Når du konfigurerer indstillingerne for Fabric-lejeren, omfatter vigtige beslutninger og handlinger:

• Bekræft, at hver tjenesteprincipal er i den korrekte gruppe: Bekræft, at de tjenesteprincipaler i Power BI-administrationstjenesten gruppe indeholder de korrekte tjenesteprincipaler.
• Opdater lejerindstillingen for administrations-API'en i Power BI: Føj sikkerhedsgruppen til Tillad, at tjenesteprincipaler bruger skrivebeskyttede Power BI-administrator-API'er lejerindstilling, hvilket gør det muligt at bruge administrator-API'erne til at hente metadata for hele lejeren.
• Opdater de detaljerede lejerindstillinger for metadata i Power BI: Føj om nødvendigt sikkerhedsgruppen til Optimer administrations-API-svar med detaljerede metadata lejerindstilling og Optimer api-svar til administratorer med DAX- og miksudtryk lejerindstilling.
• Bekræft, hvilke bruger-API'er der skal tilgås: Kontrollér, om der er brug for en eller flere bruger-API'er (derudover ved hjælp af administrator-API'erne).
• Opdater lejerindstillingen for bruger-API'en i Power BI: Føj sikkerhedsgruppen til Tillad, at tjenesteprincipaler bruger Power BI-API'er lejerindstilling, som er beregnet til bruger-API'er.

Fase 3: Løsningsudvikling og analyse

Den tredje fase af planlægning og implementering af en overvågningsløsning på lejerniveau fokuserer på løsningsudvikling og analyse. På dette tidspunkt er al planlægning og beslutningstagning sket, og du har opfyldt forudsætningerne og fuldført konfigurationen. Du er nu klar til at begynde at udvikle løsninger, så du kan udføre analyser og få indsigt i dine overvågningsdata.

Udtræk og gem rådata

På dette tidspunkt skal dine krav og prioriteter være klare. De vigtigste tekniske beslutninger er truffet om , hvordan du får adgang til overvågningsdata og placeringen til lagring af overvågningsdata. Der er valgt foretrukne værktøjer, og forudsætningerne og indstillingerne er konfigureret. I de to foregående faser har du måske gennemført et eller flere små projekter (blåstempling) for at bevise muligheden. Det næste trin er at konfigurere en proces til udtrækning og lagring af rådata til overvågning.

Ligesom med data, der returneres af de fleste Microsoft API'er, formateres overvågningsdata som JSON. JSON-formaterede data beskriver sig selv, fordi det er tekst, der kan læses af mennesker, og som indeholder struktur og data.

JSON repræsenterer dataobjekter, der består af attributværdipar og matrixer. Er f.eks. et eksempel, "state": "Active" hvor tilstandsattributværdien er Aktiv. En JSON-matrix indeholder en sorteret liste over elementer adskilt af et komma, og som er omsluttet af kantede parenteser ([ ]). Det er almindeligt at finde indlejrede matrixer i JSON-resultater. Når du er blevet fortrolig med den hierarkiske struktur i et JSON-resultat, er det nemt at forstå datastrukturen, f.eks. en liste (matrix) over semantiske modeller i et arbejdsområde.

Her er nogle overvejelser, når du udtrækker og gemmer de rå data, der er hentet fra API'erne.

• Hvilken navngivningskonvention bruges? For et filbaseret system er en navngivningskonvention nødvendig for filer, mapper og datasøzoner. For en database er en navngivningskonvention nødvendig for tabeller og kolonner.
• Hvilket format bruges til at gemme rådata? Efterhånden som Power BI fortsætter med at introducere nye funktioner, vises der nye aktiviteter , der ikke findes i dag. Derfor anbefaler vi, at du udtrækker og bevarer de oprindelige JSON-resultater. Du må ikke fortolke, filtrere eller formatere dataene, mens de udtrækkes. På den måde kan du bruge de oprindelige rådata til at genoprette dine udvalgte overvågningsdata.
• Hvilken lagringsplacering bruges? En datasø eller et bloblager bruges ofte til at gemme rådata. Du kan finde flere oplysninger under Find ud af, hvor overvågningsdata skal gemmes tidligere i denne artikel.
• Hvor meget historik vil du gemme? Eksportér overvågningsdataene til en placering, hvor du kan gemme oversigten. Planlæg at akkumulere mindst to års historie. På den måde kan du analysere tendenser og ændringer ud over standardperioden på 30 dage. Du kan vælge at gemme dataene på ubestemt tid, eller du kan beslutte dig for en kortere periode, afhængigt af politikkerne for dataopbevaring for din organisation.
• Hvordan sporer du, hvornår processen sidst kørte? Konfigurer en konfigurationsfil eller det tilsvarende for at registrere tidsstemplerne, når en proces starter og slutter. Næste gang processen kører, kan den hente disse tidsstempler. Det er især vigtigt, at du gemmer tidsstempler, når du udtrækker data ved hjælp af API'erne til scanning af metadata.
• Hvordan vil du håndtere begrænsning? Nogle REST API'er til Power BI og Microsoft Graph API implementerer begrænsning. Du får vist en 429-fejl (for mange anmodninger), hvis din API-anmodning er begrænset. Begrænsning kan være et almindeligt problem for større organisationer, der har brug for at hente en stor mængde data. Hvordan du undgår mislykkede forsøg på grund af begrænsning, afhænger af den teknologi, du bruger til at få adgang til og udtrække dataene. En mulighed er at udvikle logik i dine scripts, der reagerer på en fejl på 429 "For mange anmodninger" ved at prøve igen efter en ventetid.
• Er de overvågningsdata, der er nødvendige for overholdelse af angivne standarder? Mange organisationer bruger de rå overvågningslogposter til at udføre overvågning af overholdelse eller til at besvare sikkerhedsundersøgelser. I disse tilfælde anbefaler vi på det kraftigste, at du gemmer rådata i uforanderligt lager. På den måde kan dataene ikke ændres eller slettes af en administrator eller en anden bruger, når de er skrevet.
• Hvilke lagerlag er nødvendige for at understøtte dine krav? De bedste steder at gemme rådata er en datasø (f.eks. Azure Data Lake Storage Gen2) eller objektlager (f.eks. Azure Blob Storage). Et filsystem kan også bruges, hvis cloudtjenester ikke er en mulighed.

Tjekliste – Når rådata udtrækkes og gemmes, omfatter vigtige beslutninger og handlinger:

• Bekræft krav og prioriteter: Tydeliggør kravene og prioriteterne for de data, du udtrækker først.
• Bekræft den datakilde, der skal udtrækkes: Kontrollér kilden for hver type data, du har brug for.
• Konfigurer en proces for at udtrække dataene og indlæse dem i den rå datazone: Opret den indledende proces for at udtrække og indlæse rådata i den oprindelige tilstand uden transformationer. Test, at processen fungerer efter hensigten.
• Opret en tidsplan for at køre processerne: Konfigurer en tilbagevendende tidsplan for at køre udtræknings-, indlæsnings- og transformeringsprocesserne.
• Kontrollér, at legitimationsoplysningerne administreres sikkert: Bekræft, at adgangskoder, hemmeligheder og nøgler gemmes og kommunikeres på sikre måder.
• Bekræft, at sikkerheden er konfigureret korrekt: Kontrollér, at adgangstilladelserne er konfigureret korrekt for rådata. Sørg for, at administratorer og revisorer kan få adgang til rådata.

Du kan få flere oplysninger om, hvordan en overvågnings- og overvågningsløsning vokser over tid, under Operationalize and improve senere i denne artikel.

Opret de udvalgte data

På dette tidspunkt udtrækkes og gemmes rådata. Det næste trin er at oprette et separat gulddatalag for de udvalgte data. Målet er at transformere og gemme datafilerne i et stjerneskema. Et stjerneskema består af dimensionstabeller og faktatabeller, og det er bevidst optimeret til analyse og rapportering. Filerne i det organiserede datalag bliver kilden til en Power BI-datamodel (beskrevet i næste emne).

Tip

Når du forventer, at der er mere end én datamodel, er det især nyttigt at investere i et centraliseret organiseret datalag.

Tjekliste – Når du opretter det organiserede datalag, omfatter vigtige beslutninger og handlinger:

• Bekræft krav og prioriteter: Hvis du vil bruge et mellemliggende sølvlag til de transformerede data, skal du præcisere kravene og målene for det, du skal opnå.
• Konfigurer en proces for at transformere rådata og indlæse dem i den organiserede datazone: Opret en proces til at transformere og indlæse dataene i et stjerneskema. Test, at processen fungerer efter hensigten.
• Opret en tidsplan for at køre processerne: Konfigurer en tilbagevendende tidsplan for at udfylde det organiserede datalag.
• Bekræft sikkerhed er konfigureret korrekt: Kontrollér, at adgangstilladelserne er konfigureret korrekt for de udvalgte data. Sørg for, at udviklere af datamodellen kan få adgang til de udvalgte data.

Opret en datamodel

Emnet handler om at konfigurere en analysedatamodel. En datamodel er dataressource, der kan forespørges, optimeret til analyse. Nogle gange kaldes det en semantisk model eller blot en model. I forbindelse med din overvågningsløsning vil datamodellen sandsynligvis blive implementeret som en semantisk Power BI-model.

I forbindelse med overvågning og overvågning henter en datamodel data fra det organiserede (guld) datalag. Hvis du vælger ikke at oprette et organiseret datalag, henter datamodellen dataene direkte fra rådata.

Vi anbefaler, at din Power BI-datamodel implementerer et stjerneskemadesign. Når kildedataene er det organiserede datalag, skal Stjerneskemaet for Power BI-datamodellen afspejle det organiserede stjerneskema for datalag.

Tip

Du kan få en oversigt over design af stjerneskemaer under Forstå stjerneskema og vigtigheden af Power BI.

Som med alle Power BI-projekter er oprettelse af en datamodel en iterativ proces. Du kan tilføje nye målinger efter behov. Du kan også tilføje nye tabeller og kolonner, når nye overvågningshændelser bliver tilgængelige. Med tiden kan du endda integrere nye datakilder.

Her er nogle nyttige dimensionstabeller, som du kan inkludere i datamodellen.

• Dato: Et sæt datoattributter, der muliggør analyse (udsnit og udsnit) af data efter dag, uge, måned, kvartal, år og andre relevante tidsperioder.
• Tid: Hvis du har brug for at analysere efter tidspunkt på dagen, og du har en meget stor mængde overvågningsdata, kan du overveje at gemme tidsdelen separat fra datoen. Denne fremgangsmåde kan hjælpe med at forbedre forespørgselsydeevnen.
• Brugere: Attributter, der beskriver brugere (f.eks. afdeling og geografisk område), som kan filtrere mange emner med overvågningsdata. Målet er at fjerne alle brugeroplysninger fra faktatabellerne og gemme dem i denne dimensionstabel, så de kan filtrere mange faktatabeller. Du kan også gemme tjenesteprincipaler i denne tabel.
• Aktivitetshændelser: Attributter, der grupperer og beskriver aktivitetshændelserne (handlinger). For at forbedre din rapportering kan du oprette en dataordbog, der beskriver hver aktivitetshændelse. Du kan også oprette et hierarki, der grupperer og klassificerer lignende aktivitetshændelser. Du kan f.eks. gruppere alle hændelser for oprettelse af elementer, slette hændelser osv.
• arbejdsområder: En liste over arbejdsområder i lejerens og arbejdsområdeegenskaberne, f.eks. type (personlig eller standard) og beskrivelse. Nogle organisationer registrerer flere oplysninger om arbejdsområder (muligvis ved hjælp af en SharePoint-liste). Du kan integrere disse oplysninger i denne dimensionstabel. Du skal beslutte, om denne dimensionstabel kun gemmer arbejdsområdets aktuelle tilstand, eller om den gemmer versionserede data, der afspejler betydelige ændringer i arbejdsområdet over tid. Når navnet på et arbejdsområde f.eks. ændres, viser den historiske rapportering så navnet på det aktuelle arbejdsområde eller navnet på det arbejdsområde, der var aktuelt på det pågældende tidspunkt? Du kan få flere oplysninger om versionering under Langsomt ændring af dimensioner.
• elementtyper: En liste over Power BI-elementtyper (semantiske modeller, rapporter m.m.).
• Kapaciteter: En liste over Premium-kapaciteter i lejeren.
• Gateways: En liste over datagateways i lejeren.
• Datakilder: En liste over datakilder, der bruges af en semantisk model, dataflow eller datamart.

Her er nogle nyttige faktatabeller (emner), som du kan inkludere i datamodellen.

• brugeraktiviteter: De faktadata, der stammer fra de oprindelige JSON-data. Alle attributter, der ikke har nogen analyseværdi, fjernes. Alle attributter, der hører til i dimensionstabellerne (ovenfor), fjernes også.
• lejeroversigt: Et øjebliksbillede af alle elementer, der er publiceret i lejeren. Du kan få flere oplysninger i Lejeroversigt tidligere i denne artikel.
• semantiske modeller: Omfatter brugeraktivitet, der involverer semantiske modeller (f.eks. semantiske modelændringer) eller relaterede datakilder.
• semantiske model opdateres: Gemmer dataopdateringshandlinger, herunder oplysninger om type (planlagt eller on-demand), varighed, status, og hvilken bruger der startede handlingen.
• arbejdsområderoller: Et øjebliksbillede af rolletildelinger i arbejdsområdet.
• Brugerlicenser: Et øjebliksbillede af brugerlicenser. Selvom du kan blive fristet til at gemme brugerlicensen i dimensionstabellen Brugere , understøtter denne fremgangsmåde ikke analysen af licensændringer og tendenser over tid.
• brugergruppemedlemskaber: Et øjebliksbillede af brugere (og tjenesteprincipaler), der er tildelt en sikkerhedsgruppe.
• communityaktiviteter: Indeholder fakta, der relaterer til community'et, f.eks. træningsarrangementer. Du kan f.eks. analysere Power BI-brugeraktiviteter sammenlignet med deltagelse i oplæring. Disse data kan hjælpe Center of Excellence med at identificere potentielle nye mestre.

Faktatabeller må ikke indeholde kolonner, som rapportoprettere filtrerer. Disse kolonner tilhører i stedet relaterede dimensionstabeller. Dette design er ikke kun mere effektivt for forespørgsler, men det fremmer også genbrug af dimensionstabeller med flere fakta (også kaldet detailudledning på tværs). Det sidste punkt er vigtigt at oprette en nyttig og brugervenlig datamodel, der kan udvides, når du tilføjer nye faktatabeller (emner).

Dimensionstabellen Brugere vil f.eks. være relateret til alle faktatabeller. Den skal være relateret til faktatabellen Brugeraktiviteter (der udførte aktiviteten), faktatabellen Lejerlager (der oprettede det publicerede element) og alle andre faktatabeller. Når en rapport filtrerer efter en bruger i dimensionstabellen Brugere , kan visualiseringer i den pågældende rapport vise fakta for den pågældende bruger fra en hvilken som helst relateret faktatabel.

Når du designer din model, skal du sikre, at en attribut er synlig én gang og kun én gang i modellen. Brugerens mailadresse skal f.eks. kun være synlig i dimensionstabellen Brugere . Den findes også i andre faktatabeller (som en dimensionsnøgle til understøttelse af en modelrelation). Du bør dog skjule den i hver faktatabel.

Vi anbefaler, at du opretter din datamodel adskilt fra rapporter. Afkoblingen af en semantisk model og dens rapporter resulterer i en centraliseret semantisk model, der kan betjene mange rapporter. Du kan få flere oplysninger om brug af en delt semantisk model i det administrerede selvbetjente BI-forbrugsscenarie .

Overvej at konfigurere sikkerhed på rækkeniveau, så andre brugere – ud over Center of Excellence, auditører og administratorer – kan analysere og rapportere om overvågningsdata. Du kan f.eks. bruge RLS-regler til at give indholdsoprettere og forbrugere mulighed for at rapportere om deres egne brugeraktiviteter eller udviklingsindsats.

Tjekliste – Når du opretter datamodellen, omfatter vigtige beslutninger og handlinger:

• Planlæg og opret datamodellen: Design datamodellen som et stjerneskema. Valider relationer fungerer efter hensigten. Når du udvikler modellen, opretter du iterativt målinger og tilføjer yderligere data baseret på analytiske krav. Medtag fremtidige forbedringer af en efterslæb, når det er nødvendigt.
• Konfigurer sikkerhed på rækkeniveau: Hvis du vil gøre datamodellen tilgængelig for andre generelle brugere, skal du konfigurere sikkerhed på rækkeniveau for at begrænse dataadgang. Valider, at rollerne for sikkerhed på rækkeniveau returnerer de korrekte data.

Optimer datamodellen

Hvis du vil analysere indholdsforbrug og brugeraktiviteter effektivt, anbefaler vi, at du forbedrer din datamodel. Forbedringer af datamodeller kan udføres gradvist og iterativt over tid, efterhånden som du opdager muligheder og nye krav.

Opret klassificeringer

En måde at forbedre modellen og øge værdien af dine data på er ved at føje klassificeringer til datamodellen. Sørg for, at disse klassificeringer bruges konsekvent af dine rapporter.

Du kan vælge at klassificere brugere baseret på deres forbrugsniveau eller at klassificere indhold baseret på dets forbrugsniveau.

Brugeranvendelsesklassifikation

Overvej følgende klassificeringer for brugerbrug.

• hyppige bruger: Aktivitet registreret i den sidste uge og i ni af de sidste 12 måneder.
• Aktiv bruger: Aktivitet registreret i den seneste måned.
• Lejlighedsvis bruger: Aktivitet, der er registreret inden for de seneste ni måneder, men uden aktivitet inden for den seneste måned.
• Inaktiv bruger: Der er ikke registreret nogen aktivitet inden for de seneste ni måneder.

Tip

Det er nyttigt at vide, hvem dine lejlighedsvise eller inaktive brugere er, især når de har Pro- eller Premium pr. bruger-licenser (hvilket medfører omkostninger). Det er også nyttigt at vide, hvem dine hyppige og mest aktive brugere er. Overvej at invitere dem til at deltage i kontortid eller deltage i træning. Dine mest aktive oprettere af indhold kan være kandidater til at blive medlem af dit Champions-netværk.

Klassifikation af indholdsanvendelse

Overvej følgende klassificeringer for indholdsforbrug.

• Ofte anvendte indhold: Aktivitet registreret i den sidste uge og i ni af de sidste 12 måneder.
• Aktivt brugt indhold: Aktivitet registreret i den seneste måned.
• Lejlighedsvist brugt indhold: Aktivitet, der er registreret inden for de seneste ni måneder, men uden aktivitet inden for den seneste måned.
• Ubenyttet indhold: Der er ikke registreret nogen aktivitet inden for de seneste ni måneder.

Klassificering af brugertype

Overvej følgende klassificeringer for brugertype.

• indholdsforfatter: Aktivitet, der er registreret i løbet af de seneste seks måneder, som har oprettet, publiceret eller redigeret indhold.
• Indholdsfremviser: Aktivitet, der er registreret i løbet af de seneste seks måneder, og som har set indhold, men uden nogen aktivitet til oprettelse af indhold.

Overvej recency vs. tendenser

Du skal beslutte, om brugsklassifikationerne for brugere eller indhold kun skal være baseret på, hvor nylig en aktivitet fandt sted. Det kan også være en god idé at overveje at indregne i det gennemsnitlige eller trendgivende forbrug over tid.

Overvej nogle eksempler, der viser, hvordan simpel klassificeringslogik kan forvanske virkeligheden.

• En leder fik vist én rapport i denne uge. Før denne uge havde lederen dog ikke set nogen rapporter i de sidste seks måneder. Du bør ikke anse denne leder for at være en hyppig bruger, der alene er baseret på seneste brug.
• En rapportopretter udgiver en ny rapport hver uge. Når du analyserer brugen af hyppige brugere, ser det ud til, at rapportens opretters almindelige aktivitet er positiv. Men efter yderligere undersøgelse opdager du, at denne bruger har publiceret en ny rapport (med et nyt rapportnavn), hver gang vedkommende redigerer rapporten. Det ville være nyttigt for forfatteren af rapporten at få mere oplæring.
• En leder ser en rapport sporadisk, og derfor ændres deres anvendelsesklassificering ofte. Du skal muligvis analysere visse typer brugere, f.eks. direktører, forskelligt.
• En intern revisor ser kritiske rapporter én gang om året. Den interne revisor kan se ud til at være en inaktiv bruger på grund af deres sjældne brug. Nogen kan tage skridt til at fjerne deres Pro- eller Premium pr. bruger-licens. Eller nogen tror måske, at en rapport bør udgå, da den bruges sjældent.

Tip

Du kan beregne gennemsnit og tendenser ved hjælp af DAX-time intelligence-funktionerne. Du kan få mere at vide om, hvordan du bruger disse funktioner, ved at gennemgå læringsmodulet Brug DAX-time intelligence-funktioner i Power BI Desktop-modeller .

Tjekliste – når du opretter klassificering af forbrugsdata, omfatter vigtige beslutninger og handlinger:

• Opnå enighed om klassificeringsdefinitioner: Diskuter klassificeringsdefinitioner med de relevante interessenter. Sørg for, at der er enighed, når du træffer beslutningerne.
• Opret dokumentation: Sørg for, at klassificeringsdefinitionerne er inkluderet i dokumentationen til indholdsforfattere og forbrugere.
• Opret en feedbackløkke: Sørg for, at brugerne kan stille spørgsmål eller foreslå ændringer af klassificeringsdefinitionerne.

Opret analyserapporter

På dette tidspunkt er overvågningsdataene blevet udtrukket og gemt, og du har publiceret en datamodel. Det næste trin er at oprette analyserapporter.

Fokuser på de vigtigste oplysninger, der er mest relevante for hver målgruppe. Du har muligvis flere målgrupper til dine overvågningsrapporter. Hver målgruppe vil være interesseret i forskellige oplysninger og til forskellige formål. De målgrupper, du kan betjene med dine rapporter, omfatter:

• Sponsor i ledelsen
• Center of Excellence
• Power BI-administratorer
• Arbejdsområdeadministratorer
• Administratorer af Premium-kapacitet
• Gatewayadministratorer
• Power BI-udviklere og indholdsoprettere
• Revisorer

Her er nogle af de mest almindelige analysekrav, som du måske vil starte med, når du opretter dine overvågningsrapporter.

• De mest populære indholdsvisninger: Din ledersponsor og dine ledelsesteams kan overvejende være interesseret i oversigtsoplysninger og tendenser over tid. Administratorer af arbejdsområder, udviklere og indholdsoprettere vil være mere interesseret i detaljerne.
• topbrugeraktiviteter: Dit Center for Ekspertise vil være interesseret i, hvem der bruger Power BI, hvordan og hvornår. Administratorer af Din Premium-kapacitet vil være interesseret i, hvem der bruger kapaciteten til at sikre dens tilstand og stabilitet.
• lejeroversigt: Dine Power BI-administratorer, arbejdsområdeadministratorer og auditører vil være interesseret i at forstå, hvilket indhold der findes, hvor, afstamning og de tilhørende sikkerhedsindstillinger.

Denne liste er ikke all inclusive. Det er beregnet til at give dig idéer til, hvordan du opretter analyserapporter, der er målrettet specifikke behov. Du kan få flere overvejelser under Databehov tidligere i denne artikel og Oversigt over overvågning og overvågning. Disse ressourcer indeholder mange idéer til, hvordan du kan bruge overvågningsdata, og de typer oplysninger, du kan vælge at præsentere i dine rapporter.

Tip

Selvom det er fristende at præsentere en masse data, skal du kun inkludere oplysninger, som du er parat til at reagere på. Sørg for, at hver rapportside er klar over formålet, hvilken handling der skal udføres, og af hvem.

Du kan få mere at vide om, hvordan du opretter analyserapporter, ved at gennemgå læringsforløbet Design effektive rapporter i Power BI .

Tjekliste – Når du planlægger analyserevisionsrapporter, omfatter vigtige beslutninger og handlinger:

• gennemgå krav: Prioriter oprettelse af rapporter baseret på kendte behov og specifikke spørgsmål, der skal besvares.
• Bekræft dine målgruppers: Tydeliggør, hvem der skal bruge overvågningsrapporterne, og hvad deres formål er.
• Opret og udrul rapporter: Udvikl det første sæt kernerapporter. Udvid og optimer dem gradvist over tid.
• Distribuer rapporter i en app: Overvej at oprette en app, der indeholder alle dine overvågnings- og overvågningsrapporter.
• Kontrollér, hvem der har adgang til rapporter: Kontrollér, at rapporterne (eller appen) er gjort tilgængelige for det korrekte sæt brugere.
• Opret en feedbackløkke: Sørg for, at brugerne af rapporten kan give feedback eller forslag eller rapportere problemer.

Udfør en handling baseret på dataene

Overvågningsdata er værdifulde, fordi de hjælper dig med at forstå, hvad der sker i din Power BI-lejer. Selvom det kan synes indlysende, kan du nemt overse det, du lærer af overvågningsdataene. Derfor anbefaler vi, at du tildeler en person, der er ansvarlig for at spore målbare forbedringer, i stedet for blot at gennemse overvågningsrapporter. På den måde kan du foretage gradvise, målbare fremskridt i din indførelse og dit modenhedsniveau med Power BI.

Du kan foretage mange forskellige handlinger baseret på dine mål, og hvad du lærer af overvågningsdataene. Resten af dette afsnit giver dig flere idéer.

Indholdsforbrug

Her er nogle handlinger, du kan foretage baseret på, hvordan indhold bruges.

• Indhold bruges ofte (dagligt eller ugentligt): Kontrollér, at alt kritisk indhold er certificeret. Bekræft, at ejerskabet er klart, og at løsningen understøttes tilstrækkeligt.
• Højt antal arbejdsområdevisninger: Når der forekommer et højt antal arbejdsområdevisninger, skal du undersøge, hvorfor Power BI-apps ikke er i brug.
• Indhold bruges sjældent: Kontakt målbrugerne for at finde ud af, om løsningen opfylder deres behov, eller om deres krav er blevet ændret.
• Opdateringsaktivitet forekommer oftere end visninger: Kontakt indholdsejeren for at forstå, hvorfor en semantisk model opdateres regelmæssigt uden nogen nylig brug af den semantiske model eller relaterede rapporter.

Brugeraktiviteter

Her er nogle handlinger, du kan foretage baseret på brugeraktiviteter.

• Første udgivelseshandling foretaget af en ny bruger: Identificer, hvornår en brugertype ændres fra forbruger til forfatter, som du kan identificere, når vedkommende publicerer indhold for første gang. Det er en fantastisk mulighed for at sende dem en standardmail, der indeholder vejledning og links til nyttige ressourcer.
• Engagement med de hyppigste indholdsoprettere: Inviter dine mest aktive oprettere til at deltage i dit Champions-netværk, eller deltag i dit praktiske community.
• licensstyring: Kontrollér, om inaktive oprettere stadig har brug for en Pro- eller Premium pr. bruger-licens.
• aktivering af brugerversion: En aktivering af prøvelicensen kan bede dig om at tildele brugeren en permanent licens, før prøveperioden udløber.

Muligheder for brugertræning

Her er nogle muligheder for brugertræning, som du kan identificere ud fra overvågningsdataene.

• Stort antal semantiske modeller, der udgives af den samme indholdsopretter: Lær brugerne om delte semantiske modeller, og hvorfor det er vigtigt at undgå at oprette dublerede semantiske modeller.
• Overdreven deling fra et personligt arbejdsområde: Kontakt en bruger, der deler meget fra deres personlige arbejdsområde. Lær dem om standardarbejdsområder.
• Vigtige rapportvisninger fra et personligt arbejdsområde: Kontakt en bruger, der ejer indhold, som har et stort antal rapportvisninger. Lær dem, hvordan standardarbejdsområder er bedre end personlige arbejdsområder.

Tip

Du kan også forbedre dit træningsindhold eller din dokumentation ved at gennemgå spørgsmål, der er besvaret af dit interne Power BI-community , og problemer, der er sendt til helpdesk.

Sikkerhed

Her er nogle sikkerhedssituationer, som du måske vil overvåge aktivt.

• Der er for mange brugere, der er tildelt rollen som Fabric-administrator med høj rettighed.
• Der er for mange administratorer af arbejdsområdet (når arbejdsområderollen Medlem, Bidragyder eller Fremviser er tilstrækkelig).
• Overdrevne buildtilladelser , der er tildelt semantiske modeller (når tilladelsen Læs er tilstrækkelig).
• Høj brug af tilladelser pr. element, når Power BI-apptilladelser eller rollen som arbejdsområdefremviser vil være et bedre valg for forbrugere af indhold.
• Sådan deles indhold med eksterne brugere.

Du kan få flere oplysninger i artiklerne om planlægning af sikkerhed.

Styring og risikoafhjælpning

Her er nogle situationer, du kan støde på. Overvej eksplicit at søge efter disse typer situationer i dine overvågningsrapporter, så du er klar til at handle hurtigt.

• Stort antal visninger for rapporter (og underliggende semantiske modeller), der ikke er godkendt.
• Betydelig brug af ukendte eller ikke-sanktionerede datakilder.
• Filplaceringer, der ikke er i overensstemmelse med retningslinjer for styring af, hvor kildefiler skal placeres.
• Navne på arbejdsområder stemmer ikke overens med kravene til styring.
• Følsomhedsmærkater bruges til beskyttelse af oplysninger.
• Konsistente dataopdateringsfejl.
• Betydelig og tilbagevendende brug af udskrivning.
• Uventet eller overdreven brug af abonnementer.
• Uventet brug af personlige gateways.

De specifikke handlinger, der skal udføres i hver enkelt situation, afhænger af dine politikker for styring. Du kan få mere at vide under Styring i Fabric-adoptionsoversigten.

Tjekliste – Når du planlægger potentielle handlinger baseret på overvågningsdataene, omfatter vigtige beslutninger og handlinger:

• Klargør forventningerne: Opret overvågningsrapporter med et klart sæt forventninger til, hvilke handlinger der forventes.
• Tydeliggør, hvem der skal være ansvarlig for handlinger: Sørg for, at roller og ansvarsområder tildeles.
• Opret automatisering: Automatiser kendte handlinger, der kan gentages, når det er muligt.
• Brug et sporingssystem: Brug et system til at spore en observeret situation, herunder kontaktet, næste planlagte handling, hvem der er ansvarlig, løsning og status.

Fase 4: Vedligehold, optimer og overvåg

Den fjerde fase af planlægning og implementering af en overvågningsløsning på lejerniveau fokuserer på vedligeholdelse, forbedringer og overvågning. På dette tidspunkt er din overvågningsløsning i brug i produktion. Du er nu primært optaget af at vedligeholde, forbedre og overvåge løsningen.

Driftsklargør og gør det bedre

Overvågningsprocesser anses typisk for at køre i produktion , når den indledende udvikling og test er fuldført, og du har automatiseret processen. Automatiserede overvågningsprocesser, der kører i produktionen, har større forventninger (end manuelle processer) til kvalitet, pålidelighed, stabilitet og support.

En overvågningsproces på produktionsniveau er blevet aktiveret. En driftsklar løsning indeholder ofte mange af følgende egenskaber.

• Secure: Legitimationsoplysninger gemmes og administreres sikkert. Scripts indeholder ikke adgangskoder eller nøgler i almindelig tekst.
• Planlægning: Der findes et pålideligt planlægningssystem.
• Ændringsstyring: Brug af praksisser for administration af ændringer og flere miljøer bruges til at sikre, at produktionsmiljøet beskyttes. Du kan også arbejde med udviklings- og testmiljøer eller blot et udviklingsmiljø.
• Support: Det team, der understøtter løsningen, er klart defineret. Teammedlemmer er blevet oplært, og de forstår de driftsmæssige forventninger. Sikkerhedskopimedlemmer er blevet identificeret, og krydstræning sker, når det er relevant.
• Besked: Når noget går galt, giver beskeder automatisk supportteamet besked. Besked skal helst omfatte både logge og mail (i stedet for kun mail). En log er nyttig til analyse af logførte fejl og advarsler.
• Logføring: Processer logføres, så der er en oversigt over, hvornår overvågningsdataene blev opdateret. Logførte oplysninger skal registrere starttidspunkt, sluttidspunkt og identiteten af den bruger eller app, der kørte processen.
• Fejlhåndtering: Scripts og processer håndterer og logfører fejl korrekt (f.eks. om der skal afsluttes med det samme, om du vil fortsætte eller vente, og prøv igen). Beskedmeddelelser sendes til supportteamet, når der opstår en fejl.
• kodningsstandarder: Der bruges gode kodningsteknikker, der fungerer godt. Løkker undgås f.eks. med vilje, medmindre det er nødvendigt. Der bruges ensartede kodningsstandarder, kommentarer, formatering og syntaks, så løsningen er nemmere at vedligeholde og understøtte.
• Genbrug og modularisering: For at minimere duplikering er kode- og konfigurationsværdier (f.eks. forbindelsesstrenge eller mailadresser til meddelelser) modulopbygget, så andre scripts og processer kan genbruge dem.

Tip

Du behøver ikke at gøre alt, der er angivet ovenfor på én gang. Efterhånden som du får erfaring, kan du trinvist forbedre løsningen, så den bliver komplet og robust. Vær opmærksom på, at de fleste eksempler, du finder online, er enkle, enkelt scriptstykker, der muligvis ikke er produktionskvalitet.

Tjekliste – Når du planlægger at operationalisere og forbedre en overvågningsløsning, omfatter vigtige beslutninger og handlinger:

• Vurder niveauet af eksisterende løsninger: Find ud af, om der er muligheder for at forbedre og stabilisere eksisterende overvågningsløsninger, der automatiseres.
• Fastlæg standarder på produktionsniveau: Beslut, hvilke standarder du vil have for dine automatiserede overvågningsprocesser. Faktor i forbedringer, som du realistisk kan tilføje over tid.
• Opret en plan til forbedring: Planlæg at forbedre kvaliteten og stabiliteten af produktionsrevisionsløsninger.
• Find ud af, om der er behov for et separat udviklingsmiljø: Vurder risikoniveauet og afhængigheden af produktionsdataene. Beslut, hvornår der skal oprettes separate udviklings- og produktionsmiljøer (og test)-miljøer.
• Overvej en dataopbevaringsstrategi: Find ud af, om du skal implementere en dataopbevaringsproces, der fjerner data efter en bestemt tidsperiode eller efter anmodning.

Dokumentation og support

Dokumentation og support er afgørende for enhver løsning på produktionsniveau. Det er nyttigt at oprette flere typer dokumentation, afhængigt af målgruppen og formålet.

Teknisk dokumentation

Teknisk dokumentation er målrettet det tekniske team, der har bygget løsningen, og som gradvist vil forbedre og udvide løsningen over tid. Det er også en nyttig ressource for supportteamet.

Teknisk dokumentation bør omfatte:

• En oversigt over arkitekturkomponenter og -forudsætninger.
• Hvem ejer og administrerer løsningen.
• Hvem understøtter løsningen.
• Et arkitekturdiagram.
• Designbeslutninger, herunder mål, årsager til, at der blev truffet visse tekniske valg, og begrænsninger (f.eks. omkostninger eller færdigheder).
• Sikkerhedsbeslutninger og -valg.
• Der bruges navngivningskonventioner.
• Kodning og tekniske standarder og retningslinjer.
• Krav til administration af ændringer.
• Installations-, installations- og installationsanvisninger.
• Kendte områder med teknisk gæld (områder, der kan forbedres, hvis der er mulighed for at gøre det).

Supportdokumentation

Afhængigt af hvor kritisk din overvågningsløsning er, kan du have en helpdesk eller et supportteam, hvis der opstår presserende problemer. De kan være tilgængelige hele dagen, hver dag.

Supportdokumentation kaldes også en videnbase eller en runbook. Denne dokumentation er målrettet din helpdesk eller dit supportteam, og den bør omfatte:

• Fejlfindingsvejledning til, når noget går galt. Når der f.eks. er en fejl i dataopdateringen.
• Handlinger, der løbende skal udføres. Der kan f.eks. være nogle manuelle trin, som nogen skal udføre regelmæssigt, indtil et problem er løst.

Dokumentation til opretter af indhold

Du får mere værdi ud af din overvågningsløsning ved at levere forbrugs- og implementeringsanalyser til andre teams i hele organisationen (med sikkerhed på rækkeniveau gennemtvunget, hvis det er nødvendigt).

Dokumentation til indholdsoprettere er målrettet til selvbetjente indholdsforfattere, der opretter rapporter og datamodeller, der henter de udvalgte overvågningsdata. Den indeholder oplysninger om datamodellen, herunder almindelige datadefinitioner.

Tjekliste – når du planlægger dokumentation og support til din overvågningsløsning, omfatter vigtige beslutninger og handlinger:

• Bekræft, hvem der forventes at understøtte løsningen: Find ud af, hvem der understøtter overvågningsløsninger, der betragtes som produktionsrelaterede (eller har afhængigheder af downstreamrapporter).
• Sørg for, at supportteamet er parat: Kontrollér, at supportteamet er parat til at understøtte overvågningsløsningen. Identificer, om der er nogen parathedshuller, der skal håndteres.
• Arrangerpå tværs af kurser: Udfør vidensoverførselssessioner eller tværgående træningssessioner for supportteamet.
• Klargør forventningerne til supportteamet: Sørg for, at forventningerne til svar og løsning er klart dokumenteret og kommunikeret. Beslut, om nogen skal være på opkald for hurtigt at løse problemer, der er relateret til overvågningsløsningen.
• Opret teknisk dokumentation: Opret dokumentation om de tekniske arkitektur- og designbeslutninger.
• Opret supportdokumentation: Opdater vidensbasen til helpdesk, så den indeholder oplysninger om, hvordan du understøtter løsningen.
• Opret dokumentation til oprettere af indhold: Opret dokumentation for at hjælpe oprettere af selvbetjening med at bruge datamodellen. Beskriv almindelige datadefinitioner for at forbedre ensartetheden i brugen af dem.

Aktivér beskeder

Det kan være en god idé at udløse beskeder baseret på specifikke betingelser i overvågningsdataene. Du kan f.eks. udløse en besked, når nogen sletter en gateway, eller når en Power BI-administrator ændrer en lejerindstilling.

Du kan få flere oplysninger under Overvågning på lejerniveau.

Løbende administration

Du skal udføre løbende administration af hele overvågningsløsningen. Du skal muligvis udvide eller ændre din overvågningsløsning, når:

• Organisationen registrerer nye datakrav.
• Nye overvågningshændelser vises i de rådata, du nøjagtigt har angivet fra REST API'erne til Power BI.
• Microsoft foretager ændringer af REST API'erne til Power BI.
• Medarbejderne identificerer måder at forbedre løsningen på.

Vigtigt

Afbrydelsesændringer er sjældne, men de kan forekomme. Det er vigtigt, at du har en tilgængelig person, der hurtigt kan foretage fejlfinding af problemer eller opdatere overvågningsløsningen, når det er nødvendigt.

Tjekliste – Når du planlægger løbende administration af overvågningsløsningen, omfatter vigtige beslutninger og handlinger:

• Tildel en teknisk ejer: Sørg for, at der er klart ejerskab og ansvar for hele overvågningsløsningen.
• Kontrollér, at der findes en sikkerhedskopiering: Kontrollér, at der er en teknisk ejer af sikkerhedskopiering, der kan involveres, hvis der opstår et presserende problem, som support ikke kan løse.
• Behold et sporingssystem: Sørg for, at du har en måde at registrere nye anmodninger på og på en måde, hvorpå du kan prioritere øjeblikkelige prioriteter samt prioriteter på kort, mellemlang og lang sigt (efterslæb).

Relateret indhold

I den næste artikel i denne serie kan du få mere at vide om overvågning på lejerniveau.