Microsoft 365 Apps with Shared Computer Activation

Microsoft 365 Apps on a multi-user Windows VPS or RDS Session Host requires Shared Computer Activation. SCA lets Office be installed once on the server while each Remote Desktop user activates Word, Excel, Outlook, and other apps with their own eligible Microsoft 365 account.

Use SCA when:

• multiple users connect to the same Windows Server;
• Office is installed on an RDS Session Host;
• users launch Office apps from Remote Desktop sessions;
• each user has their own Microsoft 365 identity;
• you do not want Office activation tied to the install-time admin account.

The practical setup is:

Windows VPS
  ↓
RDS Session Host
  ↓
Microsoft 365 Apps installed with Office Deployment Tool
  ↓
SharedComputerLicensing = 1
  ↓
Each user signs in with an eligible Microsoft 365 license

The important rule:

Microsoft 365 license = right to use Office apps.
RDS CAL = right to connect to the RDS Session Host.
You usually need both.

Critical support note before you deploy

Before installing Microsoft 365 Apps on Windows Server, verify Microsoft's current support matrix.

Microsoft's RDS deployment documentation currently lists Microsoft 365 Apps support on Windows Server 2022 only until October 2026 and does not list Windows Server 2025 as a supported RDS host for Microsoft 365 Apps in that article.

That means this is not a normal "newest Windows Server is always best" workload.

For Microsoft 365 Apps on RDS, the safest rule is:

Choose the Windows Server version Microsoft currently supports for Microsoft 365 Apps on RDS.
Do not assume Windows Server 2025 is supported unless Microsoft documentation confirms it.

If you are publishing this article for production buyers, verify the Microsoft support page on the same day and update this section if Microsoft changes support.

Quick verdict

What is Shared Computer Activation?

Shared Computer Activation is a Microsoft 365 Apps licensing mode for shared computers.

Without SCA, Microsoft 365 Apps activation is designed around a normal user device. That works well when one person uses Office on their own PC.

It breaks down when many users sign in to the same server.

Example:

User A signs into RDS and opens Word.
User B signs into the same RDS host and opens Word.
User C signs into the same RDS host and opens Excel.

In that situation, the Office installation is shared, but the license entitlement must be checked per user.

SCA solves this by making activation user-based:

• Office is installed once on the Windows Server.
• A user signs in to the RDS session.
• The user opens Word, Excel, Outlook, or another Office app.
• Microsoft 365 Apps contacts Microsoft licensing services.
• The user's Microsoft 365 license is checked.
• A licensing token is saved for that user.
• The same process happens separately for every user.

One user's activation does not activate Office for everyone.

Each user needs their own eligible Microsoft 365 license.

Why SCA matters on a Windows VPS

A Windows VPS used for RDP can become a shared application server.

Common use cases:

• accountants using Excel and Outlook on a shared RDS server;
• office staff using Word, Excel, and Outlook next to ERP software;
• consultants connecting to the same Windows Server desktop;
• small businesses centralizing business apps on a cloud Windows VPS;
• MSPs hosting Microsoft 365 Apps for client users in an RDS environment.

In these scenarios, installing Office normally is not enough.

You need the correct activation mode.

Otherwise you may see:

• second user cannot activate Office;
• Office asks users to sign in repeatedly;
• Office enters reduced functionality mode;
• Outlook profile problems;
• activation tied to the admin account;
• licensing errors after profile cleanup;
• users blocked even though they have a Microsoft 365 account.

SCA keeps the Office installation shared while the licensing remains per user.

Eligible Microsoft 365 plans

Not every Microsoft 365 plan supports Shared Computer Activation.

Supported plans include:

• Microsoft 365 Apps for enterprise;
• Office 365 E3 / E5;
• Microsoft 365 E3 / E5;
• Education plans that include Microsoft 365 Apps for enterprise;
• Microsoft 365 Business Premium;
• Project or Visio plans that include desktop apps, for those specific apps.

Not supported for SCA:

• Microsoft 365 Business Standard;
• Microsoft 365 Business Basic;
• Microsoft 365 Apps for business when not included through Business Premium SCA entitlement;
• Microsoft 365 Personal;
• Microsoft 365 Family;
• consumer Office licenses;
• unlicensed Microsoft accounts.

Important:

Microsoft 365 Business Premium is the only Microsoft 365 business plan in the Business tier that supports Shared Computer Activation.

Business Standard includes desktop Office apps, but it does not include the Shared Computer Activation entitlement.

That is the licensing detail that often breaks RDS Office deployments.

M365 license vs RDS CAL

Do not confuse Microsoft 365 licensing with Remote Desktop licensing.

They solve different problems.

For a real multi-user Office-on-RDS deployment, users usually need:

Eligible Microsoft 365 license
+
RDS CAL
+
Windows Server/RDS configuration
+
SCA-enabled Office install

There is no Microsoft 365 license that magically replaces the RDS CAL requirement for a Windows Server Session Host.

Plan both before production.

What you will build

This guide sets up Microsoft 365 Apps on a Windows VPS or RDS Session Host using the Office Deployment Tool.

Target architecture:

Remote users
  ↓
RDP / RDS Session Host
  ↓
Windows VPS
  ├── Microsoft 365 Apps installed once
  ├── SharedComputerLicensing = 1
  ├── Per-user Microsoft 365 activation tokens
  ├── User profiles / profile containers
  └── Internet access to Microsoft licensing services

Each user signs in with their own Microsoft 365 account.

Office activation is not tied to the server administrator account.

What you'll need

Before starting, prepare:

• a Raff Windows VPS or similar Windows Server VM;
• RDS Session Host role installed if multiple users will connect;
• eligible Microsoft 365 licenses assigned to each user;
• RDS CAL planning for users or devices;
• local Administrator access on the VPS;
• Office Deployment Tool from Microsoft;
• reliable outbound internet access from the VPS;
• a profile strategy for Outlook and Office token caching;
• 45-60 minutes for first install.

Recommended Microsoft 365 plan options:

Step 1 — Prepare the Windows VPS

Start with a clean Windows Server environment.

Before installing Microsoft 365 Apps:

1. Confirm Windows Server version support.
2. Install Windows updates.
3. Reboot the server.
4. Confirm RDS Session Host is installed if multiple users will connect.
5. Confirm users can sign in through RDP.
6. Confirm each user has an eligible Microsoft 365 license.
7. Confirm the VPS has internet access.
8. Confirm no old MSI Office installation exists.
9. Decide whether to use local profiles, User Profile Disks, FSLogix, or another profile method.

Do not install Office first and solve licensing later.

For RDS, licensing and profile planning come first.

Step 2 — Download the Office Deployment Tool

Download the Office Deployment Tool from Microsoft on the Windows VPS.

Create a folder:

New-Item -ItemType Directory -Path "C:\ODT" -Force

Run the ODT executable and extract files into:

C:\ODT

You should see:

setup.exe
configuration.xml

You can replace the sample configuration file with your own.

Step 3 — Choose the correct product ID

Use the product ID that matches your Microsoft 365 license family.

For Microsoft 365 Apps for enterprise / E3 / E5:

<Product ID="O365ProPlusRetail">

For Microsoft 365 Business Premium:

<Product ID="O365BusinessRetail">

This matters.

Business Premium supports SCA, but it includes Microsoft 365 Apps for business, not Apps for enterprise.

If you deploy the wrong product ID, activation and licensing behavior may not match the user's license.

Step 4 — Create configuration.xml

Create:

C:\ODT\configuration.xml

Option A — Microsoft 365 Apps for enterprise

Use this for Microsoft 365 Apps for enterprise, Office 365 E3/E5, or Microsoft 365 E3/E5 users.

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="OneDrive" />
      <ExcludeApp ID="Lync" />
    </Product>
  </Add>

  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="SharedComputerLicensing" Value="1" />
  <Property Name="AUTOACTIVATE" Value="0" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Updates Enabled="TRUE" Channel="MonthlyEnterprise" />
</Configuration>

Option B — Microsoft 365 Business Premium

Use this for Microsoft 365 Business Premium users.

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
    <Product ID="O365BusinessRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="OneDrive" />
      <ExcludeApp ID="Lync" />
    </Product>
  </Add>

  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="SharedComputerLicensing" Value="1" />
  <Property Name="AUTOACTIVATE" Value="0" />
  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE" />
  <Updates Enabled="TRUE" Channel="MonthlyEnterprise" />
</Configuration>

Key line:

<Property Name="SharedComputerLicensing" Value="1" />

This enables Shared Computer Activation.

Step 5 — Decide whether to exclude OneDrive

The examples above exclude OneDrive.

That is a conservative default for RDS hosts unless you have planned OneDrive sync carefully.

Reasons to exclude OneDrive on simple RDS hosts:

• sync cache can grow quickly;
• multiple user profiles can consume storage;
• support issues are common when profile strategy is weak;
• OneDrive may need additional policy planning;
• small VPS deployments usually do not need local OneDrive sync on the server.

If your users need OneDrive, do not exclude it blindly.

Plan profile storage, tenant policies, disk usage, and user training first.

Step 6 — Download Microsoft 365 Apps source files

Open PowerShell as Administrator.

Run:

cd C:\ODT
.\setup.exe /download configuration.xml

This downloads Microsoft 365 Apps installation files.

The download can take 10-30 minutes depending on connection speed.

You should see an Office folder appear under:

C:\ODT\Office

Step 7 — Install Microsoft 365 Apps with SCA enabled

Run:

cd C:\ODT
.\setup.exe /configure configuration.xml

The install runs silently if Display Level="None" is set.

Wait until setup completes.

Do not interrupt the install.

Step 8 — Verify Shared Computer Activation is enabled

After installation, check the Click-to-Run configuration.

Run PowerShell as Administrator:

$key = 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'
(Get-ItemProperty -Path $key).SharedComputerLicensing

Expected output:

1

If the value is missing or 0, SCA is not enabled.

Fix options:

1. Re-run Office setup with the correct configuration.xml.
2. Enable SCA with registry.
3. Enable SCA with Group Policy where supported.
4. Use Microsoft Support and Recovery Assistant for activation repair.

Registry method:

$key = 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name 'SharedComputerLicensing' -Value '1' -Type String

Reboot the server after changing activation mode.

Step 9 — Test with a real non-admin user

Do not test only with the Administrator account.

Use a real user account that has:

• RDP access;
• an eligible Microsoft 365 license;
• correct password/MFA path;
• normal user permissions;
• profile created on the server.

Test flow:

1. Sign out of the Administrator session.
2. RDP into the server as the test user.
3. Launch Word.
4. Sign in with the user's Microsoft 365 work account.
5. Confirm Word opens normally.
6. Go to File → Account.
7. Confirm Office shows the signed-in licensed user.
8. Sign out and repeat with a second user.

Each user should get their own activation token.

Step 10 — Understand where activation tokens are stored

With SCA, each user gets a licensing token.

By default, the token is stored in the user's profile.

Default location:

%localappdata%\Microsoft\Office\16.0\Licensing

Microsoft 365 Apps needs internet access to obtain and renew these tokens.

Tokens are valid for a limited time and renew automatically when users open Office while online.

If a user does not use the shared computer for a long period, the token can expire and Office will contact Microsoft again on next launch.

This is normal.

Step 11 — Configure token roaming only if needed

For normal persistent user profiles, the default token location is usually enough.

For non-persistent profiles, pooled desktops, or profile reset scenarios, consider token roaming.

You can configure token roaming with ODT properties:

<Property Name="SCLCacheOverride" Value="1" />
<Property Name="SCLCacheOverrideDirectory" Value="\\server\share\%username%" />

Or with registry:

$key = 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'

Set-ItemProperty -Path $key -Name 'SCLCacheOverride' -Value '1' -Type String
Set-ItemProperty -Path $key -Name 'SCLCacheOverrideDirectory' -Value '\\server\share\%username%' -Type String

Do not redirect all users to the same folder.

The token location must be unique per user and writable by that user.

For a simple single RDS host with persistent local profiles, token roaming may not be required.

Step 12 — Plan Outlook profiles carefully

Outlook is usually the hardest part of Office on RDS.

Word and Excel are simple.

Outlook creates mail profiles, cached data, signatures, add-ins, and search indexes.

Plan:

• profile storage method;
• OST cache location;
• mailbox size;
• shared mailboxes;
• add-ins;
• search performance;
• disk growth;
• profile cleanup;
• MFA and modern authentication;
• whether Cached Exchange Mode is enabled.

Common profile strategies include:

• persistent local profiles;
• User Profile Disks;
• FSLogix profile containers;
• other profile container solutions.

For small deployments, persistent local profiles may be enough.

For serious RDS deployments, use a profile container strategy so users keep Outlook state reliably across sessions.

Step 13 — Assign users to Remote Desktop access

Each Office user also needs access to the RDS host.

For a basic standalone server, add users to:

Remote Desktop Users

PowerShell example:

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\jane.doe"

If this is a domain environment, manage access with domain groups instead of adding users one by one.

Example:

RDS-Office-Users

Then add that group to Remote Desktop Users on the server.

Step 14 — Confirm each user has the right license

Before telling users to connect, check Microsoft 365 admin center.

For each user, verify:

• Microsoft 365 Apps for enterprise, E3, E5, or Business Premium is assigned;
• Office apps are enabled under the license details;
• account sign-in is allowed;
• MFA/Conditional Access does not block RDS sign-in;
• the user knows their work account password;
• Business Standard users are upgraded if SCA is required.

Do not troubleshoot Office installation if the user simply has the wrong license.

Step 15 — Verify Office activation status

From an Office app:

1. Open Word.
2. Go to File → Account.
3. Confirm the user is signed in.
4. Confirm the product is activated.

From Command Prompt, you can also inspect Office licensing scripts, but the exact path varies by Office version and architecture.

Common location:

C:\Program Files\Microsoft Office\Office16

Example:

cd "C:\Program Files\Microsoft Office\Office16"
cscript ospp.vbs /dstatus

Use this for troubleshooting, not as the only success check.

The best test is still:

User signs in → opens Word/Excel/Outlook → edits and saves a document successfully.

Common errors and fixes

Error 1 — "We can't sign you in because you don't have a license"

The user does not have an eligible Microsoft 365 license.

Check:

• license assignment in Microsoft 365 admin center;
• whether Office apps are enabled under that license;
• whether the plan supports SCA;
• whether the user signed in with the correct work account.

Business Standard is a common cause.

It includes desktop Office apps for normal device installs, but it does not support Shared Computer Activation.

Error 2 — "Microsoft 365 Apps cannot be activated because shared computer activation is not enabled"

SCA is not enabled.

Check:

$key = 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration'
(Get-ItemProperty -Path $key).SharedComputerLicensing

Expected:

1

If not, enable SCA by ODT, registry, Group Policy where supported, or Support and Recovery Assistant.

Reboot after changing activation mode.

Error 3 — Second user is blocked after the first user activates Office

This usually means Office was installed without SCA or activation happened in the wrong mode.

Fix:

1. Enable SCA.
2. Reset Office activation state.
3. Reboot.
4. Test with two separate licensed users.

Do not rely on the admin account test.

Always test multiple non-admin users.

Error 4 — Office keeps asking users to sign in

Possible causes:

• token cache is not preserved;
• user profiles are temporary;
• RDS profile cleanup deletes token folders;
• no reliable internet access;
• Conditional Access blocks sign-in;
• MFA flow cannot complete inside the RDS session;
• token roaming path is wrong;
• Office activation was previously cached incorrectly.

Check:

%localappdata%\Microsoft\Office\16.0\Licensing

If profiles are deleted at logoff, token loss is expected.

Use a persistent profile or token roaming strategy.

Error 5 — Outlook profile disappears after logout

This is a profile management problem, not only an Office activation problem.

Fix options:

• use persistent profiles;
• use User Profile Disks;
• use FSLogix profile containers;
• reduce or disable Cached Exchange Mode if storage is limited;
• check profile cleanup policies;
• verify users have write access to profile storage.

Outlook on RDS should not be deployed without profile planning.

Error 6 — Business Premium users cannot activate

Check the product ID.

For Business Premium, use:

<Product ID="O365BusinessRetail">

If you installed the enterprise product ID but users only have Business Premium, licensing may not match.

Also confirm the tenant actually assigned Business Premium to the user and that Microsoft 365 Apps is enabled in the license details.

Error 7 — Business Standard users cannot activate with SCA

This is expected.

Business Standard does not support Shared Computer Activation.

Upgrade affected users to Business Premium or an enterprise plan that supports SCA.

Error 8 — Office is in reduced functionality mode

Reduced functionality mode usually means Office is installed but not activated for that user.

Causes:

• no eligible license;
• no internet access to Microsoft licensing service;
• sign-in prompt was closed;
• token expired and cannot renew;
• SCA not enabled;
• profile/token issue.

Fix the licensing and activation path.

Do not reinstall Windows or rebuild the server before checking SCA and user license assignment.

Security and operations checklist

Before production, review:

• Windows Server support status for Microsoft 365 Apps;
• RDS Session Host installed and licensed;
• RDS CALs planned;
• Microsoft 365 licenses assigned;
• SCA enabled;
• each user signs in with their own account;
• no shared Microsoft 365 account;
• profile strategy selected;
• Outlook tested;
• OneDrive plan defined;
• Office update channel selected;
• backups enabled before production;
• users do not have local admin rights;
• RDP access is restricted where possible;
• MFA/Conditional Access tested;
• support runbook created.

Recommended update channel

For RDS hosts, use a controlled update channel.

A practical default:

Channel="MonthlyEnterprise"

Why Monthly Enterprise is a good default:

• predictable monthly update cadence;
• less change noise than Current Channel;
• still receives regular security and feature updates.

For highly conservative environments, consider Semi-Annual Enterprise Channel only if the business understands the slower feature cadence.

Avoid letting every RDS host update unpredictably.

Office updates can affect all users on that server.

How Raff fits Microsoft 365 Apps on RDS

Raff Windows VPS gives you the Windows Server foundation for running RDS-style workloads.

Raff can help with:

• Windows VPS deployment;
• RDP access;
• Windows Server version selection;
• VM sizing;
• backups and snapshots;
• private networking;
• migration planning;
• support for the Windows server layer.

Raff does not replace Microsoft 365 licensing.

You still need:

• eligible Microsoft 365 licenses;
• RDS CALs where required;
• correct Microsoft 365 tenant configuration;
• user identity and MFA planning;
• Office Deployment Tool configuration.

A practical Raff setup looks like this:

Raff Windows VPS
  ↓
RDS Session Host
  ↓
Microsoft 365 Apps with SCA
  ↓
Licensed users connect over RDP

For production teams, combine this with:

• RDP hardening;
• backup strategy;
• user profile strategy;
• restricted admin access;
• documented license assignment.

What Raff recommends

For Microsoft 365 Apps on a Windows VPS:

1. Verify Microsoft support for the Windows Server version first.
2. Use RDS Session Host for real multi-user access.
3. Assign eligible Microsoft 365 licenses to every user.
4. Do not use Business Standard for SCA.
5. Plan RDS CALs separately.
6. Install Microsoft 365 Apps with ODT, not a normal click-through installer.
7. Set SharedComputerLicensing to 1.
8. Test with two real non-admin users.
9. Plan Outlook and profile storage before production.
10. Keep Office update cadence controlled.

The key point:

A working Office install is not enough.
You need the right activation mode, user licenses, RDS licensing, and profile strategy.

Tested on

Compatible with Raff Windows VPS and RDS-style Windows Server deployments. Do not publish that claim until the environment has been tested.

What's next

• Multi-user RDP: 2 Admin Sessions vs RDS Session Host
• RDS CAL Licensing on Windows Server
• Connect to a Windows VPS via RDP
• RDP Performance Tuning for Smooth Remote Desktop
• ERP on Windows VPS: Hosting, Sizing, and Migration
• Raff Windows VPS

Sources

• Microsoft Learn — Overview of shared computer activation for Microsoft 365 Apps
• Microsoft Learn — Deploy Microsoft 365 Apps by using Remote Desktop Services
• Microsoft Learn — Configuration options for the Office Deployment Tool
• Microsoft Learn — Troubleshoot shared computer activation for Microsoft 365 Apps
• Microsoft Learn — Remote Desktop Services overview
• Date last verified: 2026-07-07