What permissions are needed for service accounts scanning GUIDs?

For a service account to successfully scan specific Outlook folders using GUIDs, it requires a specific set of permissions within the Exchange/Office 365 environment.

Because GUID scanning is a "targeted" operation, the service account must be able to bypass standard user-level restrictions to "see" and "open" those specific IDs.

The required permissions differ slightly between Exchange Online (Office 365) and On-Premise Exchange.

1. Exchange Online (Office 365)

The most robust and recommended method for a service account is Application Impersonation.

Role Required: ApplicationImpersonation
What it does: This allows the service account to "impersonate" the user. When the Spirion agent provides a Folder GUID, the service account acts as the mailbox owner to access it.
Why it's needed for GUIDs: Without impersonation, the service account would need to be manually added to every single folder's Access Control List (ACL), which is not scalable.
How to assign:

New-ManagementRoleAssignment -Name "SpirionServiceAccount" -Role "ApplicationImpersonation" -User "spirion_svc@yourcompany.com"

2. On-Premise Exchange

For local Exchange servers, you typically use Full Access permissions, but you must be careful about how it is applied.

Permission Required: FullAccess
Scope: This must be granted at the Mailbox Database level or the individual Mailbox level.
The "Folder Visible" Requirement: Even with Full Access, if you are targeting a deep sub-folder via GUID, the service account must have the "Folder Visible" right on the "Top of Information Store" (the root of the mailbox). Without this, the MAPI subsystem may return a MAPI_E_NOT_FOUND error when the Agent tries to resolve the GUID.

3. Local System / Endpoint Permissions

Beyond the Exchange server, the service account needs specific rights on the Windows Endpoint where the Spirion agent is running:

Log on as a Service: The account must have this local security policy right to run the IdentityFinder.exe or IdentityFinderCMD.exe process.
Profile Access: If you are scanning in Cached Mode, the service account must have NTFS "Read" permissions to the folder where the user's .ost or .pst files are stored (usually C:\Users\[User]\AppData\Local\Microsoft\Outlook).
MAPI Initialization: The service account must be able to initialize a MAPI session. This usually requires the service account to have its own (often empty) Outlook profile on the machine, or for the Spirion agent to be configured to use a "Profile-less" connection.

4. Summary of Permission Levels

Permission Type	Recommended For	Why?
Application Impersonation	Office 365 / Modern Exchange	Best for security; allows the agent to see exactly what the user sees.
Full Access	On-Premise Exchange	Simplest to configure for local servers; ensures no GUID is "hidden."
Folder Visible (Root)	Targeted Sub-folders	Essential for the agent to "traverse" the mailbox to find the specific GUID.
Local Admin (Endpoint)	All Environments	Often required for the agent to interact with the Outlook MAPI subsystem and local data files.

Troubleshooting Tip

If your service account has "Full Access" but the GUID scan is still failing with MAPI_E_NO_ACCESS, check if there is a Deny permission set anywhere in the folder hierarchy. In Exchange, a "Deny" always overrides an "Allow," and some organizations explicitly "Deny" access to certain folders (like "Legal" or "Executive") even for administrators.

Summary

For the best results with GUID scanning, use a service account with the ApplicationImpersonation role (for O365) or Full Access (for On-Premise).

Ensure the account also has Local Admin rights on the endpoint to handle the MAPI connection.