Løse eDiscovery-sperringsfeil

Denne artikkelen beskriver vanlige problemer som kan oppstå med eDiscovery-sperringer og hvordan du løser dem. Artikkelen inneholder også anbefalte fremgangsmåter for å hjelpe deg med å redusere eller unngå disse problemene.

Hvis du vil ha informasjon om eDiscovery-søkeproblemer, kan du se Løse søkefeil i eDiscovery (Standard).

Anbefalte fremgangsmåter

Hvis du vil redusere antall feil relatert til sperringer i eDiscovery, anbefaler vi følgende fremgangsmåter:

• Hvis en sperringsdistribusjon fremdeles venter, venter du med statusen On (Pending) enten eller Off (Pending), til sperringsdistribusjonen er fullført før du foretar ytterligere oppdateringer.

• Kontroller om en sperrepolicy venter før du foretar ytterligere oppdateringer av den. Kjør følgende kommandoer, eller lagre dem i et PowerShell-skript.

  $status = Get-CaseHoldPolicy -Identity <policyname> -DistributionDetail
  if($status.DistributionStatus -ne "Pending"){
      # policy no longer pending
      Set-CaseHoldPolicy -Identity <policyname> -AddExchangeLocation $user1
  }else{
      # policy still pending
      Write-Host "Hold policy still pending."
  }
  

• Slå sammen oppdateringene til en eDiscovery-sperring i én enkelt masseforespørsel i stedet for å oppdatere sperringspolicyen gjentatte ganger for hver transaksjon. Hvis du for eksempel vil legge til flere brukerpostbokser i en eksisterende sperrepolicy ved hjelp av Set-CaseHoldPolicy-cmdleten fra Security & Compliance PowerShell, kjører du kommandoen (eller legger til som en kodeblokk i et skript), slik at den bare kjører én gang for å legge til flere brukere.

  Riktig

  Set-CaseHoldPolicy -Identity "policyname" -AddExchangeLocation "User1", "User2", "User3", "User4", "User5"
  

  Feil

  $users = "User1", "User2", "User3", "User4", "User5"
  ForEach($user in $users)
  {
      Set-CaseHoldPolicy -Identity "policyname" -AddExchangeLocation $user
  }
  

  I forrige feil eksempel kjøres cmdlet fem separate ganger for å fullføre oppgaven. Hvis du vil ha mer informasjon om anbefalte fremgangsmåter for å legge til brukere i en sperrepolicy, kan du se delen Mer informasjon .

• Før du kontakter Microsoft Kundestøtte om problemer med eDiscovery-sperringen, må du kontrollere hva som forårsaker at policyen mislykkes ved å sjekke inn i DistributionResults, basert på ResultCode:

  Get-CaseHoldPolicy -Identity "policyname" -DistributionDetail | Select -ExpandProperty DistributionResults
  

  

Feil: PolicySyncTimeout

Hvis du ser denne feilen i ResultCode: PolicySyncTimeout og følgende feilmelding, kan du sjekke LastResultTime for å se om det har gått mer enn to timer siden synkroniseringen har nådd tidsavbruddet.

Det tar lengre tid enn forventet å distribuere policyen. Det kan ta ytterligere to timer å oppdatere den endelige distribusjonsstatusen, så kom tilbake om et par timer.

Løsning

Hvis du Set-CaseHoldPolicy -Identity "policyname" -RetryDistribution kjører, løses problemet.

Set-CaseHoldPolicy "policyname" -RetryDistribution

I tilfelle sperringssiden i Microsoft Purview-samsvarsportal kan du distribuere policyen på nytt ved å klikke Prøv på nytt.

Feil: PolicyNotifyError

Hvis du ser denne feilen i ResultCode: PolicyNotifyError og følgende feilmelding, avbrøt et datasenterproblem policysynkroniseringen.

Policyen kan ikke distribueres til innholdskilden på grunn av et midlertidig problem med Microsoft 365-datasenteret. Gjeldende policy brukes ikke på noe innhold i kilden, så det er ingen innvirkning fra den blokkerte distribusjonen. Prøv å distribuere policyen på nytt for å løse dette problemet.

Løsning

Hvis du Set-CaseHoldPolicy -Identity "policyname" -RetryDistribution kjører, løses problemet.

Set-CaseHoldPolicy "policyname" -RetryDistribution

I tilfelle sperringssiden i Microsoft Purview-samsvarsportal kan du distribuere policyen på nytt ved å klikke Prøv på nytt.

Feil: InternalError

Hvis du ser denne feilen i ResultCode: InternalError og følgende feilmelding, må dette problemet løses av Microsoft.

Policydistribusjon har blitt avbrutt av et uventet problem med Microsoft 365-datasenteret. Kontakt Microsoft Kundestøtte for å løse distribusjonsproblemet.

Løsning

Kontakt Microsoft Kundestøtte med følgende informasjon:

• Policynavn
• Microsoft 365-tjeneste eller -funksjon
• Resultatkode
• Resultatmelding
• Ytterligere diagnostikk

Feil: FailedToOpenContainer

Hvis du ser denne feilen i ResultCode: FailedToOpenContainer og følgende feilmelding når du setter forvaltere og datakilder på vent, bruker du løsningstrinnene til å feilsøke problemet.

Postboksen eller SharePoint-området finnes kanskje ikke. Hvis dette er feil, kan du kontakte Microsoft Kundestøtte. Ellers må du fjerne den fra denne policyen.

Løsning

• Kjør Get-Mailbox i Exchange Online PowerShell for å kontrollere om brukerpostboksen finnes i organisasjonen.

• Kjør Get-SPOSite-cmdleten i SharePoint Online PowerShell for å kontrollere om området finnes i organisasjonen.

• Kontroller om nettadressen for området er endret.

• Fjern postboksen eller området fra policyen hvis objektet ikke finnes.

Feil: SiteInReadonlyOrNotAccessible

Hvis du ser denne feilen i ResultCode: SiteInReadonlyOrNotAccessible og følgende feilmelding, er SharePoint-området i skrivebeskyttet modus.

SharePoint-området er skrivebeskyttet eller ikke tilgjengelig. Kontakt områdeadministratoren for å gjøre området skrivbart, og redistribuer deretter denne policyen på nytt.

Løsning

Lås opp området (eller be en administrator om å låse det opp) for å løse dette problemet. Hvis du vil lære mer om hvordan du endrer låsetilstanden for et område, kan du se Låse og låse opp områder.

Feil: SiteOutOfQuota

Hvis du ser denne feilen i ResultCode: SiteOutOfQuota og følgende feilmelding, har SharePoint-området nådd lagringskvoten.

SharePoint-området har ikke nok kvote. Tilordne mer kvote til områdesamlingen, og redistribuer denne policyen på nytt.

Løsning

Legg til mer lagringsplass på nettstedet (eller be en administrator om å legge til mer lagringsplass) i områdesamlingen. Hvis du vil lære mer om hvordan du administrerer lagringskvotene for et nettsted, kan du se Administrere lagringsgrenser for områdesamlinger.

Etter at mer lagringskvote er lagt til på nettstedet, må policyen distribueres på nytt.

Set-CaseHoldPolicy "policyname" -RetryDistribution

I tilfelle sperringssiden i Microsoft Purview-samsvarsportal kan du distribuere policyen på nytt ved å klikke Prøv på nytt.

Feil: RecipientTypeNotAllowed

Hvis du ser denne feilen i ResultCode: RecipientTypeNotAllowed og følgende feilmelding, tilordnes en Exchange-plassering som er en postboks til policyen.

Mottakertypen er ikke tillatt for sperringer.

Løsning

Kjør Hent mottaker i Exchange Online PowerShell for å kontrollere om adressen i endepunktet er en gyldig postboks.

Hvis cmdleten ovenfor viser at SMTP-adressen ikke er en gyldig postboks, fjerner du den fra policyen.

Set-CaseHoldPolicy "policyname" -RemoveExchangeLocation "non-mailbox user"

Mer informasjon

Veiledningen om oppdatering av sperringspolicyer for flere brukere i delen Anbefalte fremgangsmåter er et resultat av at systemet blokkerer samtidige oppdateringer til en sperrepolicy. Det betyr at når en oppdatert sperringspolicy brukes på nye innholdsplasseringer og sperringspolicyen er i ventende tilstand, kan ikke flere innholdsplasseringer legges til i sperringspolicyen. Her er noen ting du må huske på for å hjelpe deg med å løse dette problemet:

• Hver gang en sperring oppdateres, går den umiddelbart til en ventende tilstand. Statusen for ventende status betyr at sperringen brukes på innholdsplasseringer.

• Hvis du har et skript som kjører en løkke og legger til plasseringer i policyen én etter én (ligner på feil eksempel som vises i delen Anbefalte fremgangsmåter), starter den første innholdsplasseringen (for eksempel en brukerpostboks) synkroniseringsprosessen som utløser ventende tilstand. Det betyr at de andre brukerne som legges til i policyen i etterfølgende løkker, resulterer i en feil.

• Hvis organisasjonen bruker et skript som kjører en løkke for å oppdatere innholdsplasseringene for en sperrepolicy, må du oppdatere skriptet slik at det oppdaterer plasseringer i én enkelt masseoperasjon (som vist i det riktige eksemplet i delen Anbefalte fremgangsmåter).