Tips: How do I handle permission issues with Folder GUID scanning?

Handling permission issues when scanning specific Outlook folders via GUIDs requires a two-pronged approach: verifying the Identity (who is scanning) and the Access Level (what they can see).

When you use "Search Selected Outlook Folders," the Spirion agent must have explicit permission to "traverse" the mailbox structure to reach those specific IDs.

1. Identify the "Scanning Context"

First, determine which account is actually performing the scan, as this dictates how permissions must be set:

Logged-in User: If the scan runs while a user is logged in, it uses that user's own Outlook permissions.
Service Account: If you are scanning remotely or via a background service, you are likely using a Service Account. This account needs "Full Access" or "Application Impersonation" rights in Exchange to "act as" the user and see their folders.

2. Common Permission Fixes

If the agent logs show MAPI_E_NO_ACCESS or Access Denied for a specific GUID, follow these steps:

A. Check "Folder Visible" Permissions

In Outlook/Exchange, a user might have "Read" access to a sub-folder, but if they don't have "Folder Visible" permission on the parent folders (like the "Top of Information Store"), the Spirion agent may fail to reach the target GUID.

The Fix: Ensure the scanning account has at least "Folder Visible" rights from the root of the mailbox down to the target folder.

B. Verify "Set Outlook Bitness"

This is a common "hidden" permission issue. If Spirion is set to the wrong bitness (e.g., 32-bit Spirion trying to use 64-bit Outlook MAPI), the operating system will block the connection, which often looks like a permission error.

The Fix: Match the "Set Outlook Bitness" setting in the wizard to the version of Outlook installed on the endpoint.

C. Address "Public Folder" Restrictions

If the GUIDs you are targeting belong to Exchange Public Folders, they are governed by a different set of permissions than standard mailboxes.

The Fix: Ensure the option "Exclude Exchange Public Folders" is set to No in the wizard, and verify the scanning account has "Owner" or "Publishing Editor" rights to those specific Public Folders.

3. Troubleshooting Steps

If you are still seeing errors after checking the above:

Test with MFCMAPI: Run the MFCMAPI tool on the endpoint using the same credentials as the Spirion agent. If MFCMAPI cannot open the folder using that GUID, Spirion won't be able to either. This confirms the issue is with Exchange/Outlook permissions, not Spirion settings.
Check "Cached Mode" vs "Online": Sometimes permissions sync differently in Cached Mode. Try toggling "Search only Cached Exchange Stores" to No to force the agent to check permissions directly against the Exchange server.
Review the Ingress/Console Logs: If you are using a Service Account, check the Exchange Audit logs. They will tell you if the "Impersonation" call was rejected by the server.

Best Practice: The "Service Account" Rule

If you are scanning mailboxes across the entire enterprise, the most stable way to handle permissions is to use an Exchange Service Account with the ApplicationImpersonation role.
This bypasses individual folder-level permission headaches and allows the Spirion agent to resolve any GUID in any mailbox it is assigned to scan.

Summary

Permission issues are usually caused by a lack of "Folder Visible" rights on parent folders or a Bitness mismatch. Use MFCMAPI to verify that the scanning account can actually "see" the GUID before troubleshooting the Spirion configuration.