EDiscovery-bewaringsfouten oplossen

In dit artikel worden veelvoorkomende problemen besproken die kunnen optreden met eDiscovery-bewaringen en hoe u deze kunt oplossen. Het artikel bevat ook aanbevolen procedures om deze problemen te verhelpen of te voorkomen.

Zie Zoekfouten in eDiscovery (Standard) oplossen voor problemen met zoeken in eDiscovery.

Aanbevolen procedures

Om het aantal fouten met betrekking tot eDiscovery-bewaringen te verminderen, raden we de volgende procedures aan:

• Als een bewaringsdistributie nog in behandeling is, met de status On (Pending) of Off (Pending), wacht totdat de bewaringsdistributie is voltooid voordat u verdere updates aanbrengt.

• Controleer of een bewaringsbeleid in behandeling is voordat u er verdere updates in aanbrengt. Voer de volgende opdrachten uit of sla deze op in een PowerShell-script.

  $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."
  }
  

• Voeg uw updates samen in een eDiscovery-bewaring in één bulkaanvraag in plaats van het bewaringsbeleid herhaaldelijk bij te werken voor elke transactie. Als u bijvoorbeeld meerdere gebruikerspostvakken wilt toevoegen aan een bestaand bewaringsbeleid met behulp van de cmdlet Set-CaseHoldPolicy van Security & Compliance PowerShell, voert u de opdracht uit (of voegt u toe als een codeblok aan een script), zodat deze slechts één keer wordt uitgevoerd om meerdere gebruikers toe te voegen.

  Juist

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

  Onjuist

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

  In het vorige onjuiste voorbeeld wordt de cmdlet vijf keer afzonderlijk uitgevoerd om de taak te voltooien. Zie de sectie Meer informatie voor meer informatie over de aanbevolen procedures voor het toevoegen van gebruikers aan een bewaarbeleid.

• Voordat u contact opneemt met Microsoft Ondersteuning over problemen met eDiscovery-bewaring, controleert u waarom het beleid mislukt door in te checken bij DistributionResults, op basis van de ResultCode:

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

  

Fout: PolicySyncTimeout

Als u deze fout ziet in de ResultCode: PolicySyncTimeout en het volgende foutbericht, controleert u lastResultTime om te zien of het langer dan twee uur geleden is dat de synchronisatie de time-out heeft bereikt.

Het implementeren van het beleid duurt langer dan verwacht. Het kan nog twee uur duren voordat de uiteindelijke implementatiestatus is bijgewerkt, dus kom over een paar uur terug.

Oplossing

Als u de Set-CaseHoldPolicy -Identity "policyname" -RetryDistribution uitvoert, wordt het probleem opgelost.

Set-CaseHoldPolicy "policyname" -RetryDistribution

Ook op de pagina case-bewaring in de Microsoft Purview-nalevingsportal kunt u het beleid opnieuw implementeren door op Opnieuw proberen te klikken.

Fout: PolicyNotifyError

Als u deze fout ziet in de ResultCode: PolicyNotifyError en het volgende foutbericht, heeft een datacenterprobleem de beleidssynchronisatie onderbroken.

Beleid kan niet worden geïmplementeerd in de inhoudsbron vanwege een tijdelijk probleem met het Microsoft 365-datacenter. Het huidige beleid wordt niet toegepast op inhoud in de bron, dus er is geen invloed op de geblokkeerde implementatie. U kunt dit probleem oplossen door het beleid opnieuw te implementeren.

Oplossing

Als u de Set-CaseHoldPolicy -Identity "policyname" -RetryDistribution uitvoert, wordt het probleem opgelost.

Set-CaseHoldPolicy "policyname" -RetryDistribution

Ook op de pagina case-bewaring in de Microsoft Purview-nalevingsportal kunt u het beleid opnieuw implementeren door op Opnieuw proberen te klikken.

Fout: InternalError

Als u deze fout ziet in de ResultCode: InternalError en het volgende foutbericht, moet dit probleem worden opgelost door Microsoft.

De beleidsimplementatie is onderbroken door een onverwacht probleem met het Microsoft 365-datacenter. Neem contact op met Microsoft-ondersteuning om het implementatieprobleem op te lossen.

Oplossing

Neem contact op met Microsoft Ondersteuning met de volgende informatie:

• Beleidsnaam
• Microsoft 365-service of -functie
• Resultaatcode
• Resultaatbericht
• Aanvullende diagnostische gegevens

Fout: FailedToOpenContainer

Als u deze fout ziet in ResultCode: FailedToOpenContainer en het volgende foutbericht bij het in bewaring plaatsen van beheerders en gegevensbronnen, gebruikt u de oplossingsstappen om het probleem op te lossen.

Het postvak of de SharePoint-site bestaat mogelijk niet. Als dit onjuist is, neemt u contact op met Microsoft-ondersteuning. Verwijder dit anders uit dit beleid.

Oplossing

• Voer get-mailbox uit in Exchange Online PowerShell om te controleren of het gebruikerspostvak in uw organisatie bestaat.

• Voer de cmdlet Get-SPOSite uit in SharePoint Online PowerShell om te controleren of de site in uw organisatie bestaat.

• Controleer of de site-URL is gewijzigd.

• Verwijder het postvak of de site uit het beleid als het object niet bestaat.

Fout: SiteInReadonlyOrNotAccessible

Als u deze fout ziet in de ResultCode: SiteInReadonlyOrNotAccessible en het volgende foutbericht, is de SharePoint-site in de modus Alleen-lezen.

De SharePoint-site is alleen-lezen of niet toegankelijk. Neem contact op met de sitebeheerder om de site beschrijfbaar te maken en implementeer vervolgens dit beleid opnieuw.

Oplossing

Ontgrendel de site (of vraag een beheerder om deze te ontgrendelen) om dit probleem op te lossen. Zie Sites vergrendelen en ontgrendelen voor meer informatie over het wijzigen van de vergrendelingsstatus voor een site.

Fout: SiteOutOfQuota

Als u deze fout ziet in de ResultCode: SiteOutOfQuota en het volgende foutbericht, heeft de SharePoint-site het opslagquotum bereikt.

De SharePoint-site heeft onvoldoende quotum. Wijs meer quotum toe aan de siteverzameling en implementeer dit beleid opnieuw.

Oplossing

Voeg meer opslagruimte toe aan de site (of vraag een beheerder om meer opslagruimte toe te voegen) aan de siteverzameling. Zie Opslaglimieten voor siteverzamelingen beheren voor meer informatie over het beheren van de opslagquota voor een site.

Nadat er meer opslagquota zijn toegevoegd aan de site, moet het beleid opnieuw worden geïmplementeerd.

Set-CaseHoldPolicy "policyname" -RetryDistribution

Ook op de pagina case-bewaring in de Microsoft Purview-nalevingsportal kunt u het beleid opnieuw implementeren door op Opnieuw proberen te klikken.

Fout: RecipientTypeNotAllowed

Als u deze fout ziet in de ResultCode: RecipientTypeNotAllowed en het volgende foutbericht, wordt een Exchange-locatie die een postvak is toegewezen aan het beleid.

Het type ontvanger is niet toegestaan voor bewaring.

Oplossing

Voer de get-recipient uit in Exchange Online PowerShell om te controleren of het adres in het eindpunt een geldig postvak is.

Als de bovenstaande cmdlet aangeeft dat het SMTP-adres geen geldig postvak is, verwijdert u het uit het beleid.

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

Meer informatie

De richtlijnen voor het bijwerken van bewaarbeleid voor meerdere gebruikers in de sectie Aanbevolen procedures zijn het gevolg van het feit dat het systeem gelijktijdige updates naar een bewaringsbeleid blokkeert. Dit betekent dat wanneer een bijgewerkt bewaringsbeleid wordt toegepast op nieuwe inhoudslocaties en het bewaarbeleid de status In behandeling heeft, er geen extra inhoudslocaties kunnen worden toegevoegd aan het bewaringsbeleid. Hier volgen enkele dingen om rekening mee te houden om dit probleem te verhelpen:

• Telkens wanneer een bewaring wordt bijgewerkt, krijgt deze onmiddellijk de status In behandeling. De status In behandeling betekent dat de bewaring wordt toegepast op inhoudslocaties.

• Als u een script hebt waarmee een lus wordt uitgevoerd en locaties één voor één aan beleid worden toegevoegd (vergelijkbaar met het onjuiste voorbeeld in de sectie Aanbevolen procedures), wordt met de eerste inhoudslocatie (bijvoorbeeld een gebruikerspostvak) het synchronisatieproces gestart dat de status in behandeling activeert. Dit betekent dat de andere gebruikers die in volgende lussen aan het beleid worden toegevoegd, resulteren in een fout.

• Als uw organisatie een script gebruikt waarmee een lus wordt uitgevoerd om de inhoudslocaties voor een bewaarbeleid bij te werken, moet u het script bijwerken zodat locaties in één bulkbewerking worden bijgewerkt (zoals wordt weergegeven in het juiste voorbeeld in de sectie Aanbevolen procedures).