diff --git a/docs/kb/accessanalyzer/Error-invalid-local-SPAA-storage-version.md b/docs/kb/accessanalyzer/Error-invalid-local-SPAA-storage-version.md new file mode 100644 index 0000000000..59ff8a9d68 --- /dev/null +++ b/docs/kb/accessanalyzer/Error-invalid-local-SPAA-storage-version.md @@ -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. + +--- diff --git a/docs/kb/accessanalyzer/ExchangePS-Error-WinRM-Shell-Client-Cannot-Process-Request.md b/docs/kb/accessanalyzer/ExchangePS-Error-WinRM-Shell-Client-Cannot-Process-Request.md new file mode 100644 index 0000000000..e84246257b --- /dev/null +++ b/docs/kb/accessanalyzer/ExchangePS-Error-WinRM-Shell-Client-Cannot-Process-Request.md @@ -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. + +--- diff --git a/docs/kb/accessanalyzer/ExchangePS-error-cannot-find-variable-with-name-enablesearchonlysession.md b/docs/kb/accessanalyzer/ExchangePS-error-cannot-find-variable-with-name-enablesearchonlysession.md new file mode 100644 index 0000000000..9cc9e3dd40 --- /dev/null +++ b/docs/kb/accessanalyzer/ExchangePS-error-cannot-find-variable-with-name-enablesearchonlysession.md @@ -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. + +--- diff --git a/docs/kb/accessanalyzer/SEEK-warning-DLPEX-Database-Not-Exist.md b/docs/kb/accessanalyzer/SEEK-warning-DLPEX-Database-Not-Exist.md new file mode 100644 index 0000000000..a18fb91622 --- /dev/null +++ b/docs/kb/accessanalyzer/SEEK-warning-DLPEX-Database-Not-Exist.md @@ -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. + +---