---
title: "What permissions are needed for service accounts scanning GUIDs?"
url: "https://dm0bkdes5q7a2ls.productfruits.help/en/article/7072217c-44f3-4fc8-8f7a-76a35774c056"
language: "en"
last_updated: "2026-05-06T03:40:02.992Z"
---

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