The Hidden Cost of Outlook on Multi-User Servers
Remote Desktop Session Hosts (RDSH) — commonly known as terminal servers — allow dozens or even hundreds of users to share a single Windows Server instance simultaneously. They are a staple of enterprise environments, healthcare facilities, government agencies, and managed service providers.
When a user on an RDSH needs to open an Outlook `.msg` file, the instinctive IT response is to install Microsoft Outlook. But on a shared multi-session server, this seemingly simple decision triggers a cascade of storage, licensing, and administrative problems that can quietly cripple your infrastructure.
The Outlook Profile Problem
Unlike a single-user desktop, an RDSH must maintain a separate Outlook profile for every user who logs in. Each profile generates its own local data:
- OST files (Offline Storage Table): When Outlook connects to Microsoft 365 or Exchange Online, it creates a local cache file (`.ost`) for each user. These files routinely grow to 2–10 GB per user and can balloon to 50 GB or more for heavy mailbox users.
- AutoComplete and NK2 caches: Outlook stores per-user nickname caches, recent search history, and auto-complete data.
- Add-in data and temp files: Third-party Outlook add-ins (CRM connectors, archiving tools, signature managers) each create their own per-user data stores.
A quick example of storage impact:
| Users on RDSH | Avg OST Size | Total Storage Consumed |
|---|---|---|
| 20 | 5 GB | 100 GB |
| 50 | 5 GB | 250 GB |
| 100 | 5 GB | 500 GB |
On servers using fast but expensive NVMe or SAN-backed storage, half a terabyte of Outlook cache files is a significant — and entirely avoidable — cost.
FSLogix and Profile Bloat
Many organisations running RDSH environments use FSLogix Profile Containers (now part of Microsoft's suite) to manage user profiles. FSLogix works by mounting a per-user VHD/VHDX virtual disk that contains the user's profile data, including their Outlook OST file.
While FSLogix solves the "roaming profile" problem elegantly, it amplifies the storage issue:
- Each user's FSLogix container must be large enough to hold their Outlook cache, which means provisioning oversized VHDXs.
- These containers are stored on a central file share (often Azure Files, Azure NetApp Files, or an on-premises SMB share), where storage costs scale linearly with user count.
- Larger containers mean longer login times as the VHD is mounted, and higher IOPS demand on the storage backend.
The root cause is simple: if users only need to *view* an MSG file — not send, receive, or manage a live mailbox — then creating and maintaining a full Outlook profile is unnecessary overhead.
The OpenMSG Alternative
OpenMSG is a lightweight, standalone MSG file viewer for Windows that requires no Outlook installation, no email profile configuration, and no cloud connectivity.
Why it works perfectly on RDSH:
1. Zero Per-User Storage Overhead
OpenMSG is a single application install — under 15 MB — shared across all users on the session host. It creates no per-user cache files, no OST databases, and no profile data. Whether you have 10 users or 200 users, the storage footprint remains the same.
2. No Outlook Licensing Required
Microsoft 365 Apps for Enterprise (the version of Outlook licensed for RDSH/multi-session use) requires per-user or per-device licensing. If your users only need to *read* MSG files — not manage a mailbox — you can avoid assigning Outlook licenses entirely for those users, potentially saving thousands of dollars annually.
3. Simplified FSLogix Containers
Without Outlook generating multi-gigabyte OST files inside each FSLogix container, you can significantly reduce your VHDX size allocations. This directly translates to:
- Lower storage costs on Azure Files or your NAS.
- Faster login times as smaller containers mount more quickly.
- Reduced IOPS pressure on your storage backend during peak login storms (e.g., 9 AM Monday morning).
4. No Profile Configuration
Outlook requires each user to set up (or have auto-configured via Autodiscover) an email profile on first login. On RDSH, this means either:
- Waiting for Autodiscover/Exchange Online provisioning on every new session, or
- Pre-staging Outlook profiles via Group Policy or scripting.
OpenMSG requires zero configuration. Install it once on the server, associate it with the `.msg` file extension via Group Policy, and every user can immediately open MSG files on their next login.
5. Security and Compliance
Because OpenMSG is a read-only, offline viewer with no network connectivity for file processing, it has a minimal footprint on your server. There is no OAuth token to manage, no credential caching, and no risk of accidental mailbox synchronisation on a shared server.
Deployment Guide for IT Administrators
Rolling out OpenMSG across your RDSH farm takes minutes:
Step 1: Install on the Session Host
- Put the RDSH into Install Mode (`change user /install` from an elevated command prompt).
- Install OpenMSG from the Microsoft Store or via your MSIX deployment pipeline.
- Return to Execute Mode (`change user /execute`).
Step 2: Set the Default File Association
Use Group Policy to associate `.msg` files with OpenMSG for all users:
- Open Group Policy Management Editor.
- Navigate to User Configuration → Administrative Templates → Windows Components → File Explorer.
- Configure a default application association XML file that maps `.msg` to OpenMSG's ProgID.
Alternatively, right-click any `.msg` file on the server, choose Open with → OpenMSG, and tick Always use this app.
Step 3: Validate
Log in as a test user, double-click a sample `.msg` file, and confirm it opens instantly in OpenMSG with full HTML rendering.
When You Still Need Outlook
To be clear, OpenMSG is not a replacement for Outlook as a full email client. If your RDSH users need to:
- Send and receive email from a live mailbox,
- Manage calendars, contacts, and tasks, or
- Compose new messages,
…then Outlook (or Outlook on the Web) remains the right tool.
However, for the many users and workflows where the requirement is simply to open and read MSG files — helpdesk teams reviewing forwarded emails, legal teams processing eDiscovery archives, finance teams auditing correspondence — OpenMSG is a dramatically more efficient choice.
Conclusion
Installing Outlook on a Remote Desktop Session Host to view MSG files is like hiring a freight truck to deliver a letter. It works, but the cost in storage, licensing, login performance, and administrative complexity is vastly disproportionate to the task.
OpenMSG gives your RDSH users the ability to open any MSG file instantly, with zero per-user overhead, zero configuration, and zero licensing cost. For IT teams managing multi-session environments, it is the obvious choice.