Leitfaden zur Indexer-Problembehandlung bei Azure AI Search

Artikel
12/10/2024

Gelegentlich gibt es mit Indexern Probleme, die keine Fehler verursachen oder die bei anderen Azure-Diensten auftreten, z. B. während der Authentifizierung oder beim Herstellen einer Verbindung. Dieser Artikel konzentriert sich auf die Behandlung von Indexerproblemen, wenn keine Meldungen zur Unterstützung vorhanden sind. Er bietet auch die Problembehandlung für Fehler, die aus Nicht-Suchressourcen stammen, die während der Indizierung verwendet werden.

Hinweis

Wenn Sie einen Fehler im Zuammenhang mit Azure KI-Suche untersuchen müssen, nutzen Sie stattdessen Beheben von häufigen Fehler und Warnungen bei Suchindexern in Azure Cognitive Search.

Problembehandlung bei Verbindungen mit eingeschränkten Ressourcen

Bei Datenquellen unter Azure-Netzwerksicherheit ist die Art und Weise eingeschränkt, wie Indexer die Verbindung herstellen. Derzeit können Indexer mit einer freigegebenen privaten Verbindung über einen privaten Endpunkt auf eingeschränkte Datenquellen hinter einer IP-Firewall oder in einem virtuellen Netzwerk zugreifen.

Firewallregeln

Azure Storage, Azure Cosmos DB und Azure SQL bieten eine konfigurierbare Firewall. Sie erhalten keine spezifische Fehlermeldung, wenn die Firewall die Anforderung blockiert. Normalerweise sind Firewall-Fehler allgemeiner Natur. Häufige Fehler sind z. B. folgende:

The remote server returned an error: (403) Forbidden
This request is not authorized to perform this operation
Credentials provided in the connection string are invalid or have expired

Es gibt zwei Möglichkeiten, Indexern in einem solchen Fall Zugriff auf diese Ressourcen zu ermöglichen:

Konfigurieren Sie eine eingehende Regel für die IP-Adresse des Suchdiensts und den IP-Adressbereich des Diensttags AzureCognitiveSearch. Details zum Konfigurieren der Einschränkungen des IP-Adressbereichs für die einzelnen Datenquellentypen finden Sie unter den folgenden Links:
Deaktivieren Sie als letzte Möglichkeit oder als temporäre Maßnahme die Firewall, indem Sie den Zugriff für Alle Netzwerke zulassen.

Einschränkung: Einschränkungen des IP-Adressbereichs funktionieren nur, wenn Sich Ihr Suchdienst und Ihr Speicherkonto in verschiedenen Regionen befinden.

Zusätzlich zum Datenabruf senden Indexer auch ausgehende Anforderungen über Skillsets und benutzerdefinierte Fähigkeiten. Beachten Sie bei benutzerdefinierten Fähigkeiten, die auf einer Azure-Funktion basieren, dass Azure-Funktionen auch IP-Adresseinschränkungen unterliegen. Die Liste der IP-Adressen, die für die Ausführung von benutzerdefinierten Fähigkeiten zulässig sind, umfasst die IP-Adresse des Suchdiensts und den IP-Adressbereich des AzureCognitiveSearch-Diensttags.

NSG-Regel (Netzwerksicherheitsgruppe)

Wenn ein Indexer auf Daten in einer SQL-verwalteten Instanz zugreift oder wenn eine Azure-VM als Webdienst-URI für eine benutzerdefinierte Fähigkeit verwendet wird, bestimmt die Netzwerksicherheitsgruppe, ob Anforderungen zulässig sind.

Konfigurieren Sie für externe Ressourcen, die sich in einem virtuellen Netzwerk befinden, eingehende NSG-Regeln für das AzureCognitiveSearch-Diensttag.

Weitere Informationen zum Herstellen einer Verbindung mit einem virtuellen Computer finden Sie unter Konfigurieren einer Verbindung eines Indexers der kognitiven Azure-Suche mit SQL Server auf einer Azure-VM.

Netzwerkfehler

Normalerweise sind Netzwerkfehler allgemeiner Natur. Häufige Fehler sind z. B. folgende:

A network-related or instance-specific error occurred while establishing a connection to the server
The server was not found or was not accessible
Verify that the instance name is correct and that the source is configured to allow remote connections

Wenn Sie eine dieser Fehler erhalten:

Stellen Sie sicher, dass Ihre Quelle zugänglich ist, indem Sie versuchen, sich direkt mit ihr zu verbinden und nicht über den Suchdienst
Überprüfen Sie Ihre Ressource im Azure-Portal auf aktuelle Fehler oder Ausfälle
Suchen Sie nach Netzwerkausfällen im Azure-Status
Stellen Sie sicher, dass Sie einen öffentlichen DNS für die Namensauflösung verwenden und nicht einen Azure Private DNS

Azure SQL-Datenbank – serverlos: Indizierung (Fehlercode 40613)

Wenn sich Ihre SQL-Datenbank auf einer serverlosen Computeebene befindet, müssen Sie sicherstellen, dass die Datenbank ausgeführt wird (und nicht angehalten wurde), wenn der Indexer eine Verbindung mit ihr herstellt.

Wenn die Datenbank angehalten wurde, sollte sie bei der ersten Anmeldung Ihres Suchdiensts automatisch fortgesetzt werden. Darüber hinaus wird jedoch ein Fehler mit dem Fehlercode 40613 und dem Hinweis zurückgegeben, dass die Datenbank nicht verfügbar sei. Wenn die Datenbank ausgeführt wird, wiederholen Sie den Anmeldeversuch, um eine Verbindung herzustellen.

Microsoft Entra-Richtlinien für bedingten Zugriff

Sie einen SharePoint-Online-Indexer erstellen, gibt es einen Schritt, bei dem Sie sich nach dem Angeben eines Gerätecodes bei Ihrer Microsoft Entra-App anmelden müssen. Möglicherweise erhalten Sie die Meldung "Your sign-in was successful but your admin requires the device requesting access to be managed". In diesem Fall wird der Indexer wahrscheinlich durch eine Richtlinie für bedingten Zugriff daran gehindert, auf die SharePoint-Dokumentbibliothek zuzugreifen.

So aktualisieren Sie die Richtlinie und erlauben den Indexerzugriff auf die Dokumentbibliothek:

Öffnen Sie das Azure-Portal, und suchen Sie nach „Bedingter Microsoft Entra-Zugriff“.
Wählen Sie im Menü links Richtlinien aus. Wenn Sie keinen Zugriff zur Anzeige dieser Seite haben, bitten Sie entweder einen Benutzer mit entsprechendem Zugriff, die Seite zu öffnen, oder fordern Sie Zugriff auf die Seite an.
Ermitteln Sie, welche Richtlinie den Zugriff des SharePoint Online-Indexers auf die Dokumentbibliothek blockiert. Die Richtlinie, die den Indexer möglicherweise blockiert, enthält das Benutzerkonto, das Sie während des Schritts zur Indexererstellung im Abschnitt Benutzer und Gruppe für die Authentifizierung verwendet haben. Die Richtlinie umfasst darüber hinaus möglicherweise Bedingungen, für die Folgendes gilt:
- Einschränkung von Windows-Plattformen
- Einschränkung von Mobile Apps und Desktopclients
- Gerätestatus auf Ja festgelegt
Nachdem Sie bestätigt haben, welche Richtlinie den Indexer blockiert, erstellen Sie eine Ausnahme für den Indexer. Rufen Sie zunächst die IP-Adresse des Suchdiensts ab.

Rufen Sie als erstes den vollqualifizierten Domänennamen (FQDN) Ihres Suchdiensts ab. Der FQDN sieht wie <your-search-service-name>.search.windows.net aus. Sie können im Azure-Portal nach dem FQDN suchen.

Nachdem Sie nun den FQDN haben, rufen Sie die IP-Adresse des Suchdienstes ab, indem Sie einen nslookup (oder ping) des FQDN durchführen. Im folgenden Beispiel fügen Sie einer eingehenden Regel in der Azure Storage-Firewall „150.0.0.1“ hinzu. Es kann bis zu 15 Minuten nach dem Aktualisieren der Firewalleinstellungen dauern, bis der Suchdienstindexer auf das Azure Storage-Konto zugreifen kann.
```
nslookup contoso.search.windows.net
Server:  server.example.org
Address:  10.50.10.50

Non-authoritative answer:
Name:    <name>
Address:  150.0.0.1
Aliases:  contoso.search.windows.net
```
Rufen Sie die IP-Adressbereiche für die Indexerausführungsumgebung für Ihre Region ab.

Zusätzliche IP-Adressen werden für Anforderungen verwendet, die aus der mehrinstanzenfähigen Ausführungsumgebung des Indexers stammen. Sie können diesen IP-Adressbereich über das Dienst-Tag abrufen.

Die IP-Adressbereiche für das Diensttag AzureCognitiveSearch können entweder über die Ermittlungs-API oder die herunterladbare JSON-Datei abgerufen werden.

Für diese Übung sollte unter der Annahme, dass der Suchdienst der öffentliche Azure-Clouddienst ist, die öffentliche Azure-JSON-Datei heruntergeladen werden.

Aus der JSON-Datei sind unter der Annahme, dass sich der Suchdienst in „USA, Westen-Mitte“ befindet, die IP-Adressen für die Ausführungsumgebung des Indexers für mehrere Mandanten nachfolgend aufgeführt.
```
    {
      "name": "AzureCognitiveSearch.WestCentralUS",
      "id": "AzureCognitiveSearch.WestCentralUS",
      "properties": {
        "changeNumber": 1,
        "region": "westcentralus",
        "platform": "Azure",
        "systemService": "AzureCognitiveSearch",
        "addressPrefixes": [
          "52.150.139.0/26",
          "52.253.133.74/32"
        ]
      }
    }
```
Wählen Sie im Azure-Portal zurück auf der Seite „Bedingter Zugriff“ im Menü links die Option Benannte Standorte und anschließend + IP-Adressbereiche (Standort) aus. Geben Sie dem neuen benannten Standort einen Namen, und fügen Sie die IP-Adressbereiche für Ihre Suchdienst- und Indexerausführungsumgebungen hinzu, die Sie in den letzten beiden Schritten erfasst haben. 1
- Für die IP-Adresse Ihres Suchdiensts müssen Sie möglicherweise am Ende der IP-Adresse „/32“ hinzufügen, da nur gültige IP-Adressbereiche akzeptiert werden.
- Denken Sie daran, dass Sie für die Indexerausführungsumgebung nur die IP-Adressbereiche der Region hinzufügen müssen, in der sich Ihr Suchdienst befindet.
Schließen Sie den neuen benannten Speicherort aus der Richtlinie aus:
1. Wählen Sie im Menü links Richtlinien aus.
2. Wählen Sie die Richtlinie aus, die den Indexer blockiert.
3. Klicken Sie auf Bedingungen.
4. Wählen Sie Standorte aus.
5. Klicken Sie auf Ausschließen, und fügen Sie dann den neuen benannten Speicherort hinzu.
6. Speichern Sie die Änderungen.
Warten Sie einige Minuten, bis die Richtlinie aktualisiert wurde, und erzwingen Sie die neuen Richtlinienregeln.
Versuchen Sie erneut, den Indexer zu erstellen:
1. Senden Sie eine Aktualisierungsanforderung für das Datenquellenobjekt, das Sie erstellt haben.
2. Senden Sie die Anforderung zum Erstellen des Indexers erneut. Verwenden Sie den neuen Code für die Anmeldung, und senden Sie eine weitere Anforderung zur Indexererstellung.

Indizieren nicht unterstützter Dokumenttypen

Wenn Sie Inhalte aus Azure Blob Storage indizieren und der Container Blobs eines nicht unterstützten Inhaltstyps enthält, überspringt der Indexer dieses Dokument. In anderen Fällen können Probleme mit einzelnen Dokumenten auftreten.

In diesem Fall können Sie Konfigurationsoptionen festlegen, damit die Indexerverarbeitung bei Problemen mit einzelnen Dokumenten fortgesetzt werden kann.

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "failOnUnsupportedContentType" : false, "failOnUnprocessableDocument" : false } }
}

Fehlende Dokumente

Indexer extrahieren Dokumente oder Zeilen aus einer externen Datenquelle und erstellen Suchdokumente, die dann vom Suchdienst indiziert werden. Gelegentlich wird ein Dokument, das in der Datenquelle vorhanden ist, nicht in einem Suchindex angezeigt. Dieses unerwartete Ergebnis kann aus folgenden Gründen auftreten:

Das Dokument wurde nach der Ausführung des Indexers aktualisiert. Wenn Sie für Ihren Indexer einen Zeitplan festgelegt haben, wird er das Dokument schließlich erneut ausführen und abrufen.
Für den Indexer wurde vor der Erfassung des Dokuments ein Timeout ausgelöst. Es gibt Grenzwerte für die maximale Bearbeitungszeit, nach deren Ablauf keine Dokumente mehr bearbeitet werden können. Sie können den Indexerstatus im Azure-Portal oder durch Aufrufen von Get Indexer Status (REST API) überprüfen.
Feldzuordnungen oder KI-Anreicherung haben das Dokument verändert, und seine Formulierung im Suchindex ist anders, als Sie es erwarten.
Änderungsnachverfolgungs-Werte sind fehlerhaft oder Voraussetzungen fehlen. Wenn der hohe Grenzwert ein Datum ist, das auf einen späteren Zeitpunkt festgelegt ist, werden alle Dokumente mit einem früheren Datum vom Indexer übersprungen. Sie können den Zustand der Änderungsnachverfolgung des Indexers mithilfe der Felder „initialTrackingState“ und „finalTrackingState“ im Indexerstatus bestimmen. Indexer für Azure SQL und MySQL müssen über einen Index für die Hochwassermarken-Spalte in der Quelltabelle verfügen. Andernfalls kann bei Abfragen des Indexers ein Timeout auftreten.

Tipp

Wenn Dokumente fehlen, überprüfen Sie die von Ihnen verwendete Abfrage, um sicherzustellen, dass sie die betreffenden Dokumente nicht ausschließt. Verwenden Sie für die Abfrage nach einem bestimmten Dokument die Lookup Document-REST-API.

Fehlender Inhalt aus Blob Storage

Der Blobindexer findet und extrahiert Text aus Blobs in einem Container. Beim Extrahieren von Text können u.a. diese Probleme auftreten:

Das Dokument enthält nur gescannte Bilder. PDF-Blobs mit Nichttextinhalten wie gescannten Bildern (JPGs) erzeugen keine Ergebnisse in einer Standard-Blobindizierungspipeline. Wenn Sie Bildinhalte mit Textelementen haben, können Sie mithilfe der optischen Zeichenerkennung (OCR) oder Bildanalyse Text suchen und extrahieren.
Der Blobindexer ist so konfiguriert, dass er nur Metadaten indiziert. Zum Extrahieren von Inhalten muss der Blobindexer so konfiguriert sein, dass er sowohl Inhalte als auch Metadaten extrahiert:

PUT https://[service name].search.windows.net/indexers/[indexer name]?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]

{
  ... other parts of indexer definition
  "parameters" : { "configuration" : { "dataToExtract" : "contentAndMetadata" } }
}

Fehlender Inhalt von Azure Cosmos DB

Azure AI Search ist implizit von der Azure Cosmos DB-Indizierung abhängig. Wenn Sie die automatische Indizierung in Azure Cosmos DB deaktivieren, gibt Azure AI Search zwar einen erfolgreichen Status zurück, indiziert aber keine Containerinhalte. Anweisungen zum Überprüfen der Einstellungen und zum Aktivieren der Indizierung finden Sie unter Verwalten der Indizierung in Azure Cosmos DB.

Abweichung der Dokumentanzahl zwischen der Datenquelle und dem Index

Ein Indexer kann eine andere Dokumentanzahl als von der Datenquelle, dem Index selbst oder der Anzahl in Ihrem Code angezeigen. Hier sind einige mögliche Gründe, warum dieses Verhalten auftreten kann:

Der Index kann die tatsächliche Dokumentanzahl verzögert anzeigen, insbesondere im Azure-Portal.
Eine Dokumentrichtlinie im Indexer wurde gelöscht. Die gelöschten Dokumente werden vom Indexer gezählt, wenn die Dokumente indiziert werden, bevor sie gelöscht werden.
Wenn die ID-Spalte in der Datenquelle nicht eindeutig ist. Dies gilt für Datenquellen mit Spaltenkonzept wie Azure Cosmos DB.
Wenn die Datenquellendefinition eine andere Abfrage aufweist als die, die Sie verwenden, um die Anzahl der Datensätze zu schätzen. In Ihrer Datenbank können Sie beispielsweise die Datensätze abfragen, während Sie in der Datenquellen-Definitionsabfrage nur eine Teilmenge von Datensätzen auswählen, die indiziert werden sollen.
Die Anzahl wird in verschiedenen Intervallen für jede Komponente der Pipeline überprüft: Datenquelle, Indexer und Index.
Die Datenquelle verfügt über eine Datei, die vielen Dokumenten zugeordnet ist. Diese Bedingung kann auftreten, wenn BLOBs indiziert werden und wenn „parsingMode“ auf jsonArray und jsonLines festgelegt ist.

Mehrfach verarbeitete Dokumente

Indexer nutzen eine konservative Pufferstrategie, um sicherzustellen, dass jedes neue und geänderte Dokument in der Datenquelle während der Indizierung aufgenommen wird. In bestimmten Situationen können sich diese Puffer überlappen, wodurch ein Indexer ein Dokument doppelt oder mehrfach indiziert, was dazu führt, dass die Anzahl der verarbeiteten Dokumente größer als die tatsächliche Anzahl von Dokumenten in der Datenquelle ist. Dieses Verhalten wirkt sich nicht auf die im Index gespeicherten Daten aus, es werden z. B. keine Dokumente dupliziert, sondern hat lediglich zur Folge, dass es länger dauern kann, bis die letztliche Konsistenz erreicht ist. Diese Bedingung tritt besonders häufig auf, wenn eines der folgenden Kriterien zutrifft:

Bedarfsbasierte Indexeranforderungen werden in schneller Folge ausgegeben.
Die Topologie der Datenquelle umfasst mehrere Replikate und Partitionen (ein solches Beispiel wird hier erläutert).
Die Datenquelle ist eine Azure SQL-Datenbank-Instanz, die als „Obergrenze“ ausgewählte Spalte hat den Typ datetime2.

Indexer sollen nicht mehrmals in schneller Folge aufgerufen werden. Wenn Sie schnell Updates benötigen, besteht der unterstützte Ansatz im Pushen von Updates an den Index, während gleichzeitig die Datenquelle aktualisiert wird. Für die bedarfsbasierte Verarbeitung wird empfohlen, dass Sie Ihre Anforderungen in Intervallen von fünf Minuten oder mehr senden und den Indexer nach einem Zeitplan ausführen.

Beispiel für die doppelte Verarbeitung Dokumente mit einem Puffer von 30 Sekunden

Bedingungen, unter denen ein Dokument zweimal verarbeitet wird, werden im Folgenden in einer Zeitachse mit den einzelnen Aktionen und Gegenaktionen beschrieben. Die folgende Zeitachse veranschaulicht das Problem:

Zeitachse (hh:mm:ss)	Event	Obere Indexergrenze	Kommentar
00:01:00	`doc1` wird in eine Datenquelle geschrieben, mit letztlicher Konsistenz.	`null`	Dokumentzeitstempel ist 00:01:00.
00:01:05	`doc2` wird in eine Datenquelle geschrieben, mit letztlicher Konsistenz.	`null`	Dokumentzeitstempel ist 00:01:05.
00:01:10	Indexer wird gestartet.	`null`
00:01:11	Indexer fragt alle Änderungen vor 00:01:10 ab; dem vom Indexer abgefragten Replikat ist nur `doc2` bekannt; nur `doc2` wird abgerufen.	`null`	Indexer fordert alle Änderungen vor dem Startzeitstempel an, empfängt aber tatsächlich eine Teilmenge. Für dieses Verhalten ist der zurückliegende Pufferzeitraum erforderlich.
00:01:12	Indexer verarbeitet `doc2` zum ersten Mal.	`null`
00:01:13	Indexer wird beendet.	00:01:10	Die obere Grenze wird auf den Startzeitstempel der aktuellen Indexerausführung aktualisiert.
00:01:20	Indexer wird gestartet.	00:01:10
00:01:21	Indexer fragt alle Änderungen zwischen 00:00:40 und 00:01:20 ab; dem vom Indexer abgefragten Replikat ist `doc1` und `doc2` bekannt; `doc1` und `doc2` werden abgerufen.	00:01:10	Indexer fordert alle Änderungen zwischen der aktuellen oberen Grenze minus dem 30-Sekunden-Puffer und dem Startzeitstempel der aktuellen Indexerausführung an.
00:01:22	Indexer verarbeitet `doc1` zum ersten Mal.	00:01:10
00:01:23	Indexer verarbeitet `doc2` zum zweiten Mal.	00:01:10
00:01:24	Indexer wird beendet.	00:01:20	Die obere Grenze wird auf den Startzeitstempel der aktuellen Indexerausführung aktualisiert.
00:01:32	Indexer wird gestartet.	00:01:20
00:01:33	Indexer fragt alle Änderungen zwischen 00:00:50 und 00:01:32 ab; `doc1` und `doc2` werden abgerufen.	00:01:20	Indexer fordert alle Änderungen zwischen der aktuellen oberen Grenze minus dem 30-Sekunden-Puffer und dem Startzeitstempel der aktuellen Indexerausführung an.
00:01:34	Indexer verarbeitet `doc1` zum zweiten Mal.	00:01:20
00:01:35	Indexer verarbeitet `doc2` zum dritten Mal.	00:01:20
00:01:36	Indexer wird beendet.	00:01:32	Die obere Grenze wird auf den Startzeitstempel der aktuellen Indexerausführung aktualisiert.
00:01:40	Indexer wird gestartet.	00:01:32
00:01:41	Indexer fragt alle Änderungen zwischen 00:01:02 und 00:01:40 ab; `doc2` wird abgerufen.	00:01:32	Indexer fordert alle Änderungen zwischen der aktuellen oberen Grenze minus dem 30-Sekunden-Puffer und dem Startzeitstempel der aktuellen Indexerausführung an.
00:01:42	Indexer verarbeitet `doc2` zum vierten Mal.	00:01:32
00:01:43	Indexer wird beendet.	00:01:40	Beachten Sie, dass diese Indexerausführung mehr als 30 Sekunden nach dem letzten Schreibzugriff auf die Datenquelle gestartet und auch `doc2` verarbeitet wurde. Dies ist das erwartete Verhalten, denn wenn alle Indexerausführungen vor 00:01:35 entfernt werden, wird dies zur ersten und einzigen Ausführung zur Verarbeitung von `doc1` und `doc2`.

In der Praxis tritt dieses Szenario nur auf, wenn bedarfsbasierte Indexer für bestimmte Datenquellen innerhalb weniger Minuten manuell aufgerufen werden. Dies kann zu abweichenden Zahlen führen (z. B. dass der Indexer gemäß den Indexerausführungsstatistiken insgesamt 345 Dokumente verarbeitet hat, in der Datenquelle und im Index aber nur 340 Dokumente enthalten sind) oder eine potenziell erhöhte Abrechnung verursachen, wenn Sie die gleichen Skills für dasselbe Dokument mehrmals ausführen. Empfehlung: Die Ausführung eines Indexers unter Verwendung eines Zeitplans ist die bevorzugte Vorgehensweise.

Parallele Indizierung

Wenn mehrere Indexer gleichzeitig ausgeführt werden, ist es normal, dass einige von ihnen sich in eine Warteschlange einreihen und auf verfügbare Ressourcen warten, um mit der Ausführung zu beginnen. Die Anzahl der Indexer, die gleichzeitig ausgeführt werden können, hängt von mehreren Faktoren ab. Wenn die Indexer nicht mit Skillsets verknüpft sind, hängt die Kapazität zur parallelen Ausführung von der Anzahl der Replikate und Partitionen ab, die im KI-Suchdienst eingerichtet wurden.

Wenn ein Indexer dagegen einem Skillset zugeordnet ist, wird er innerhalb der internen Cluster der KI-Suche ausgeführt. Die Fähigkeit, in diesem Fall gleichzeitig zu laufen, hängt von der Komplexität des Skillsets und davon, ob andere Skillsets gleichzeitig ausgeführt werden, ab. Integrierte Indexer sind so konzipiert, dass Daten zuverlässig aus der Quelle extrahiert werden, sodass keine Daten fehlen, wenn sie in einem Zeitplan ausgeführt werden. Es ist jedoch zu erwarten, dass die Indizierungsprozesse der Parallelisierung und Skalierung einige Zeit in Anspruch nehmen werden.

Indizieren von Dokumenten mit Vertraulichkeitsbezeichnungen

Wenn Sie Vertraulichkeitsbezeichnungen für Dokumente festgelegt haben, können Sie sie möglicherweise nicht indizieren. Wenn Sie Fehler erhalten, entfernen Sie die Bezeichnungen vor der Indizierung.

Freigeben über