ITMarshall Notes

Field notes / Microsoft 365

Microsoft 365 · Troubleshooting

Microsoft Outlook - Classic Outlook Blocks Attachments While New Outlook and OWA Work

ITMarshall Notes

September 11, 2026

Troubleshoot widespread attachment blocking that is isolated to Classic Outlook, and separate sender or Exchange issues from the Win32 client path.

Purpose

Use this when users can open attachments in Outlook on the web and New Outlook, but Classic Outlook reports that attachments are potentially unsafe or otherwise refuses access.

Diagnostic pattern

A client-side pattern is worth considering when several of these show up together:

  • Multiple unrelated senders and attachment types are affected.
  • The same messages work in Outlook on the web.
  • The same messages work in New Outlook.
  • Classic Outlook fails.
  • Some users are unaffected on the same or newer Office builds.

That pattern makes sender-specific MIME formatting and Exchange transport filtering less likely. It points toward the Classic Outlook Win32/MAPI stack, local configuration, or COM add-ins.

What to rule out first

  1. Office build alone. Do not assume a specific Microsoft 365 Apps build is the root cause if affected and unaffected users share the same build.
  2. Outlook attachment policy. Check the user and machine security locations for values such as Level1Add, Level1Remove, AllowAttachByRef, ShowLevel1Attach, and DontPromptLevel1Attach.
  3. Macro security level=2. This can appear on both working and affected clients. By itself it does not explain attachment blocking.

Useful registry locations:

HKCU\Software\Microsoft\Office\16.0\Outlook\Security
HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Security
HKLM\Software\Microsoft\Office\16.0\Outlook\Security
HKLM\Software\Policies\Microsoft\Office\16.0\Outlook\Security

Remote read-only collection without WinRM

If WinRM is disabled but RPC/WMI is available, use WMI/DCOM with StdRegProv. Do not enable WinRM or Remote Registry just to read these keys.

$Computer = '192.0.2.10'
$Cred = Get-Credential

$CS = Get-WmiObject -Class Win32_ComputerSystem `
    -ComputerName $Computer `
    -Credential $Cred

$User = $CS.UserName
$Sid = (
    New-Object System.Security.Principal.NTAccount($User)
).Translate(
    [System.Security.Principal.SecurityIdentifier]
).Value

$Reg = Get-WmiObject `
    -List `
    -Class StdRegProv `
    -Namespace root\default `
    -ComputerName $Computer `
    -Credential $Cred

$HKLM = [uint32]2147483650
$HKU  = [uint32]2147483651

This avoids changing service state on the endpoint.

Compare COM add-ins

Classic Outlook loads traditional COM/VSTO add-ins that New Outlook does not use in the same way. Compare working and affected hosts under:

HKCU\Software\Microsoft\Office\Outlook\Addins
HKLM\Software\Microsoft\Office\Outlook\Addins
HKLM\Software\WOW6432Node\Microsoft\Office\Outlook\Addins

Pay attention to LoadBehavior:

  • 3 generally means configured to load.
  • 0 means disabled.

Acrobat PDFMaker (PDFMOutlook.PDFMOutlook) is a common correlation on affected hosts. Treat that as a lead, not a confirmed root cause, until Safe Mode or a controlled disable/retest proves it.

Other add-ins may vary between hosts. Do not promote one to root cause unless it is actually common to the affected systems.

Highest-value validation test

Use an already-known-bad message and test it in Classic Outlook Safe Mode:

outlook.exe /safe

Then open the exact same existing message.

Interpretation:

  • Attachment works in Safe Mode. A COM add-in or Classic Outlook integration becomes the leading cause.
  • Attachment still fails in Safe Mode. Focus next on Outlook profile state, local cache/temp handling, MAPI state, or other endpoint-specific configuration.

If Safe Mode fixes the problem, disable suspected add-ins one at a time and retest the same message. Do not uninstall or weaken Outlook attachment security as the first troubleshooting step.

Outlook Secure Temp folder

Classic Outlook may use a per-user secure temp folder such as:

%LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.Outlook\<random-folder>\

If add-ins are ruled out, verify that the folder exists and that the affected user can write to it. Outlook on the web and New Outlook do not follow exactly the same classic Win32 attachment path, so this is a useful Classic-Outlook-specific branch.

Catches / gotchas

  • In PowerShell, sc is an alias for Set-Content. Use sc.exe when querying Windows services.
  • If no interactive user is logged on, Win32_ComputerSystem.UserName is blank. Do not reuse a stale $Sid from a previous host.
  • HKCU during a remote admin session represents the admin account, not the affected logged-on user. Resolve the affected user's SID and read HKEY_USERS\<SID> instead.
  • A stopped Remote Registry service may also be disabled. Do not enable it if WMI StdRegProv can already read the registry.
  • Do not treat a common add-in as causal until you have either a Safe Mode result or a controlled disable/retest.

Key lesson

If OWA and New Outlook work but Classic Outlook fails, isolate the problem to the Classic Outlook client path before changing Exchange or tenant-wide policies. Shared Office builds are weak evidence. Safe Mode is the cleanest first causal test for COM add-ins.

Related notes

If this is the kind of mess you are in, get in touch by email. Fixed-scope advisory: itmarshall.ca.