Skip to content
Merged
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,127 @@
---
title: "ExchangePS Error: The WinRM Shell Client Cannot Process the Request"
sidebar_label: "ExchangePS Error: The WinRM Shell Client Cannot Process the Request"
description: "Resolves the 'WinRM Shell client cannot process the request' error in ExchangePS data collector jobs by updating the PackageManagement and ExchangeOnlineManagement PowerShell modules to supported versions."
keywords:
- WinRM
- ExchangePS
- PowerShell
- New-ExoPSSession
- ExchangeOnlineManagement
- PackageManagement
- Office 365
- remote session
- module update
- data collector
- Netwrix Access Analyzer
- Netwrix Enterprise Auditor
products: [enterprise_auditor, access_analyzer]
knowledge_article_id: kA0Qk0000003Fc1KAE
---

## 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,57 @@
---
title: "ExchangePS Error: Cannot Find a Variable With the Name 'EnableSearchOnlySession'"
sidebar_label: "ExchangePS Error: Cannot Find a Variable With the Name 'EnableSearchOnlySession'"
description: "Resolves the 'Cannot find a variable with the name EnableSearchOnlySession' error in ExchangePS data collector jobs by configuring an explicit connection profile with valid Exchange credentials."
keywords:
- WinRM
- ExchangePS
- EnableSearchOnlySession
- PowerShell
- Exchange
- connection profile
- EX_MBRights
- EX_SendAs
- data collector
- Netwrix Access Analyzer
- Netwrix Enterprise Auditor
- Exchange credentials
products: [enterprise_auditor, access_analyzer]
knowledge_article_id: kA0Qk00000039TNKAY
---

## 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.

---
69 changes: 69 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,69 @@
---
title: "SEEK Bulk Import Warning: DLPEX Database Does Not Exist"
sidebar_label: "SEEK Bulk Import Warning: DLPEX Database Does Not Exist"
description: "Explains why the warning 'DLPEX database does not exist' appears during SEEK Bulk Import and how to resolve it by verifying SEEK Scan completion and DLPEX database availability."
keywords:
- SEEK
- DLPEX
- bulk import
- T2 database
- data classification
- sensitive data
- SEEK Scan
- import warning
- Netwrix Access Analyzer
- Netwrix Enterprise Auditor
- scan failure
- missing database
products: [enterprise_auditor, access_analyzer]
knowledge_article_id: kA0Qk0000003BdFKAU
---

## 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.

---
57 changes: 30 additions & 27 deletions docs/kb/accessanalyzer/error-invalid-local-storage-version.md
Original file line number Diff line number Diff line change
@@ -1,54 +1,57 @@
---
description: >-
An Activity Auditing (SPAC) scan fails after upgrading Netwrix Access Analyzer
with an Invalid local SPAA storage version error; follow the steps to update
the SPAA database schema.
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: "Resolves the 'Invalid local SPAA storage version' error that occurs when running a SPAC System Scan in Netwrix Access Analyzer by updating the SPAA database schema through the appropriate System Scan and Bulk Import jobs."
keywords:
- SPAA
- SPAC
- Invalid local storage version
- SPSEEK
- SPAA_BulkImport
- System Scan
- Bulk Import
- InvalidStorageVersionException
- SharePoint
- schema update
- Netwrix Access Analyzer
- database schema
- SystemScans
- Netwrix Enterprise Auditor
- database version
- upgrade issue
- SPSEEK
products:
- access-analyzer
sidebar_label: "Error: Invalid Local Storage Version"
tags: []
title: 'Error: Invalid Local Storage Version'
- enterprise_auditor
knowledge_article_id: kA0Qk0000001RUPKA2
---

# Error: Invalid Local Storage Version
# Error: Invalid Local SPAA Storage Version When Running SPAC System Scan

## Symptom

After the recent Netwrix Access Analyzer upgrade (`11.6.0.69`), an Activity Auditing (SPAC) scan populates the following error:
When attempting to run a **SPAC System Scan** in **Netwrix Access Analyzer** (formerly Enterprise Auditor) after upgrading, the following error occurs:

```text
Stealthbits.StealthAUDIT.DataCollectors.SPAA.Storage.InvalidStorageVersionException:
Invalid local SPAA storage version. Expected %x& but found %y%.
Invalid local SPAA storage version. Expected 11603 but found 0.
```

## Cause

The SPAA database schema is outdated and requires an update.
The SPAA database schema is outdated and requires an update. This error occurs when a SPAC System Scan* is run *before* a SPAA System Scan or SPSEEK System Scan has been executed.

## Resolution

Perform the following steps to update the database schema:

1. Run either the **1-SPSEEK_SystemScans** or **2-SPAA_SystemScans** job at `level 0`. Refer to the following articles for additional information:
- https://docs.netwrix.com/docs/auditor/10_8
- https://docs.netwrix.com/docs/auditor/10_8
2. Depending on the previously selected job, run either the **4-SPSEEK_BulkImport** or **5-SPAA_BulkImport** job to update the schema.
3. Run the **3-SPAC_SystemScans** job to verify that the issue is resolved.
1. **Run a System Scan job at level 0**
- Run either the **1-SPSEEK_SystemScans** or **2-SPAA_SystemScans** job.
- Refer to the following documentation for details:
- [1-SPSEEK_SystemScans Job ⸱ Netwrix Docs 🡥](https://docs.netwrix.com/docs/accessanalyzer/12_0/solutions/sharepoint/collection/spseek_systemscans)
- [2-SPAA_SystemScans Job ⸱ Netwrix Docs 🡥](https://docs.netwrix.com/docs/accessanalyzer/12_0/solutions/sharepoint/collection/spaa_systemscans)

2. **Run a Bulk Import job to update the schema**
- Depending on the job used in step 1, run either the **4-SPSEEK_BulkImport** or **5-SPAA_BulkImport** job.

## Related Articles
3. **Verify the issue is resolved**
- Run the **3-SPAC_SystemScans** job to confirm that the error no longer appears.

- 0.Collection Job Group — 1-SPSEEK_SystemScans Job · v11.6
https://docs.netwrix.com/docs/auditor/10_8
## Related Links

- 0.Collection Job Group — 2-SPAA_SystemScans Job · v11.6
https://docs.netwrix.com/docs/auditor/10_8
- [1-SPSEEK_SystemScans Job](https://docs.netwrix.com/docs/accessanalyzer/12_0/solutions/sharepoint/collection/spseek_systemscans)
- [2-SPAA_SystemScans Job](https://docs.netwrix.com/docs/accessanalyzer/12_0/solutions/sharepoint/collection/spaa_systemscans)