Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
title: "Error: Invalid Local SPAA Storage Version. Expected 11603 but Found 0"
sidebar_label: "Error: Invalid Local SPAA Storage Version. Expected 11603 but Found 0"
description: "Resolve the 'Invalid Local SPAA Storage Version' error in Netwrix Access Analyzer by running the required SPAA or SPSEEK System Scans before executing a SPAC System Scan."
keywords: [SPAA, SPAC, SPSEEK, InvalidStorageVersionException, Netwrix, Access Analyzer, system scan, storage version, error 11603]
products: [access-analyzer, enterprise-auditor]
knowledge_article_id: ka0Qk000000GLq5IAG
---

## Related Queries

- "SPAC scan fails with storage version error."
- "Error: InvalidStorageVersionException Expected 11603."

## Symptom

When attempting to run a SPAC System Scan in Netwrix Access Analyzer (formerly Enterprise Auditor), the following error occurs:

```text
Stealthbits.StealthAUDIT.DataCollectors.SPAA.Storage.InvalidStorageVersionException: Invalid local spaa storage version. Expected 11603 but found 0.
```

## Cause

This error occurs when a SPAC System Scan is run *before* a SPAA System Scan or SPSEEK System Scan has been executed.
These scans are required to initialize and version the local SPAA storage.
If neither scan has been completed, the system reports an invalid version of `0`.

## Resolution

To resolve the issue:

1. Run a **SPAA System Scan** or a **SPSEEK System Scan**
2. After the scan completes successfully, run the **SPAC System Scan** again.

---
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
---
title: "ExchangePS Error: The WinRM Shell Client Cannot Process the Request"
sidebar_label: "ExchangePS Error: The WinRM Shell Client Cannot Process the Request"
description: "Learn how to resolve the 'WinRM Shell client cannot process the request' error in ExchangePS data collector jobs by updating the PackageManagement and ExchangeOnlineManagement PowerShell modules."
keywords: [ExchangePS, WinRM, New-ExoPSSession, PowerShell, ExchangeOnlineManagement, PackageManagement, StealthAUDIT, data collector, Office 365, remote session]
products: [enterprise-auditor, access-analyzer]
knowledge_article_id: ka0Qk000000GS0LIAW
---

## Related Queries

- "ExchangePS shell handle is not valid."
- "New-ExoPSSession fails with WinRM Shell client error."
- "ExchangeOnlineManagement 2.0.5 error with StealthAUDIT job."
- "Stealthbits Exchange data collector fails to connect."

## Symptom

Jobs that use the ExchangePS data collector fail with the following error:

```text
PowerShell error: System.Exception: New-ExoPSSession : Processing data from remote server outlook.office365.com failed with the following error message: The WinRM Shell client cannot process the request. The shell handle passed to the WSMan Shell function is not valid. The shell handle is valid only when WSManCreateShell function completes successfully.
```

## Cause

This issue occurs when one or both of the following PowerShell modules are outdated or incompatible:

- `PackageManagement` module version is earlier than `1.0.0.1`
- `ExchangeOnlineManagement` module version is `2.0.5` or earlier

These versions are known to cause instability with remote sessions using `New-ExoPSSession`.

## Resolution

### Step 1: Verify Installed Module Versions

Open a PowerShell session and run:

```powershell
Get-Module -ListAvailable PackageManagement
Get-Module -ListAvailable ExchangeOnlineManagement
```

### Step 2: Update Modules Using PowerShell (Preferred Method)

- Update `PackageManagement` module:
```powershell
Install-Module PackageManagement -Force -Scope AllUsers
```

- Update `ExchangeOnlineManagement` module:
```powershell
Install-Module ExchangeOnlineManagement -Force -Scope AllUsers
```

> **IMPORTANT:**
> Close and reopen all PowerShell sessions after updating modules.

### Step 3: Manual Update (If Unable to Install via PowerShell)

If the environment prevents direct downloads from PowerShell, update the modules manually.

#### Download the `.nupkg` Files

1. Visit the following URLs:
- [PackageManagement 1.4.8.1](https://www.powershellgallery.com/packages/PackageManagement/1.4.8.1)
- [ExchangeOnlineManagement 3.9.1-Preview1](https://www.powershellgallery.com/packages/ExchangeOnlineManagement/3.9.1-Preview1)

2. Download the `.nupkg` file for each required version.

#### Convert `.nupkg` to ZIP and Extract

1. Rename the downloaded `.nupkg` file to `.zip`
Example: `PackageManagement.1.4.8.1.zip`
2. Unblock the ZIP file using one of the following methods:
- In File Explorer, right-click **Properties** > **Unblock**.
- Or run:
```powershell
Unblock-File .\PackageManagement.1.4.8.1.zip
```
3. Extract the contents of each ZIP file.

#### Rename the Extracted Folder

- Rename `PackageManagement.1.4.8.1` to `1.4.8.1`
- Rename `ExchangeOnlineManagement.3.4.0` to `3.4.0` (or the version you downloaded)

#### Move to PowerShell Modules Directory

Place the renamed folders in the correct directories:

- For PackageManagement:
`C:\Program Files\WindowsPowerShell\Modules\PackageManagement\1.4.8.1`
- For ExchangeOnlineManagement:
`C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.4.0`

### Step 4: Confirm Module Versions

Re-run the version checks:

```powershell
Get-Module -ListAvailable PackageManagement
Get-Module -ListAvailable ExchangeOnlineManagement
```

Ensure that:

- `PackageManagement` is version **1.4.8.1** or newer
- `ExchangeOnlineManagement` is version **2.0.6** or newer

> **IMPORTANT:**
> Rerun jobs that use the ExchangePS data collector to confirm that the error message no longer appears.

---
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
title: "ExchangePS Error: Cannot Find a Variable With the Name 'EnableSearchOnlySession'"
sidebar_label: "ExchangePS Error: Cannot Find a Variable With the Name 'EnableSearchOnlySession'"
description: "Resolve the ExchangePS data collector error 'Cannot find a variable with the name EnableSearchOnlySession' by configuring the job to use an explicit connection profile with valid Exchange credentials."
keywords: [ExchangePS, EnableSearchOnlySession, PowerShell, StealthAUDIT, EX_MBRights, EX_SendAs, data collector, connection profile, Exchange, credentials]
products: [enterprise-auditor, access-analyzer]
knowledge_article_id: ka0Qk000000GCtFIAW
---

## Related Queries

- "Receiving Get-Variable 'EnableSearchOnlySession' error on EX_MBRights job."
- "EX_SendAs job failed to inherit credentials."
- "Cannot find a variable with the name 'EnableSearchOnlySession'."

## Symptom

When running Exchange jobs using the ExchangePS data collector, the following error appears:

```text
Get-Variable 'EnableSearchOnlySession' error: Cannot find a variable with the name 'EnableSearchOnlySession'.
```

## Cause

This issue occurs when the ExchangePS data collector fails to inherit the correct session credentials.
Without proper credentials, the session does not initialize the expected variables, including `EnableSearchOnlySession`.

## Resolution

To resolve the issue, configure the job to use an explicit connection profile.
This ensures the session uses the appropriate credentials, allowing the necessary variables to load correctly.

1. Right-click the affected job.
2. Select **Properties**.
3. Go to the **Connection** tab.
4. Choose the bottom radio button to specify a custom connection profile.
5. Select the connection profile that contains valid Exchange credentials.

> **NOTE:**
> Navigate to **Settings > Connection** to verify which credentials are valid for Exchange.

6. Click **OK** to save the changes.

---
57 changes: 57 additions & 0 deletions docs/kb/accessanalyzer/SEEK-warning-DLPEX-Database-Not-Exist.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
title: "SEEK Bulk Import Warning: DLPEX Database Does Not Exist"
sidebar_label: "SEEK Bulk Import Warning: DLPEX Database Does Not Exist"
description: "Learn why the SEEK Bulk Import warning 'DLPEX database does not exist' appears and how to resolve it by verifying SEEK Scan completion and DLPEX database availability."
keywords: [SEEK, DLPEX, T2 database, bulk import, SEEK Scan, data classification, import warning, Netwrix, scan failure, sensitive data]
products: [enterprise-auditor, access-analyzer]
knowledge_article_id: ka0Qk000000GKnZIAW
---

## Related Queries

- "SEEK Bulk Import error DLPEX database does not exist."
- "No sensitive data to import SEEK."
- "SEEK import warning T2 not found."
- "SEEK or SDD scan ran, but import fails."

## Symptom

When running a SEEK Bulk Import, the following warning is displayed:

```text
WARNING | DLPEX database does not exist, there is no data to import.
```

Despite the warning, the import process completes without any imported data.

## Cause

This warning indicates that the system attempted to import sensitive data (T2) from a host that does not have the required DLPEX database.
This can occur due to one of the following reasons:

- **Unscanned hosts in the import list:** One or more hosts included in the bulk import were not scanned using SEEK Scan, and therefore, no DLPEX (T2) database was created.
- **Scan failures:** The host experienced a catastrophic error during the SEEK Scan, which prevented the creation of the sensitive data (T2) database.

> **NOTE:**
> If the import runs and simply finds no new data (but the database exists), no warning is shown and the import completes successfully.
> The warning only appears if the expected DLPEX database is missing entirely.

## Resolution

To resolve this warning, follow these steps:

1. **Review the host list**
- Confirm that all hosts listed in the SEEK Bulk Import are being scanned via SEEK Scan.
- Remove any hosts from the list that are not currently scanned.

2. **Check scan results**
- Investigate SEEK Scan logs for any failed scans.
- Look for errors indicating that the DLPEX or T2 database could not be created.

3. **Rerun the scan**
- Rerun the SEEK Scan on the affected hosts to generate the T2 database.

4. **Retry the bulk import**
- Once scans have completed successfully and the DLPEX databases exist, rerun the SEEK Bulk Import.

---