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
- 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.
- Outlook attachment policy. Check the user and machine security locations for values such as
Level1Add,Level1Remove,AllowAttachByRef,ShowLevel1Attach, andDontPromptLevel1Attach. - 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:
3generally means configured to load.0means 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,
scis an alias forSet-Content. Usesc.exewhen querying Windows services. - If no interactive user is logged on,
Win32_ComputerSystem.UserNameis blank. Do not reuse a stale$Sidfrom a previous host. HKCUduring a remote admin session represents the admin account, not the affected logged-on user. Resolve the affected user's SID and readHKEY_USERS\<SID>instead.- A stopped Remote Registry service may also be disabled. Do not enable it if WMI
StdRegProvcan 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.