Acrobat PDFMaker silently fails saving to DFS redirected/mapped folders unless Acrobat Privileged Location registry path uses the DFS namesp
Adobe PDFMaker from Microsoft Word intermittently fails when saving PDFs to DFS-backed network paths. The PDFMaker progress bar gets near completion, then closes with no error message and no PDF is created.
The source Word document opens normally, and the user has confirmed write permissions to the destination folder. The issue occurs with DFS/mapped network locations and redirected folders.
Acrobat has Protected Mode and Enhanced Security enabled. Adding the folder through the Acrobat UI under Preferences > Security (Enhanced) > Privileged Locations does not always store the path in the form that PDFMaker appears to use. In some cases, Acrobat appears to resolve the DFS namespace or redirected folder to the backend file-server path instead of retaining the user-facing DFS path.
PDFMaker only became reliable after manually correcting the Acrobat trusted-folder registry entry so that the privileged location matched the DFS namespace path exactly. Mapped drive locations you can select but the redirected desktop is not mapped so editing the registry to correct the azure files name to the dfs namespace allowed it to work and reliably create pds. Why can't we have a freeform path?
Key evidence:
The registry path involved is:
HKCU\Software\Adobe\Adobe Acrobat\DC\TrustManager\cTrustedFolders\cAlwaysTrustedForJavaScript
Example working values use the DFS namespace format:
\domain.example\dfsroot\groups\
\domain.example\dfsroot\home\username\my documents\
\domain.example\dfsroot\home\username\desktop\
Example problematic values may use the resolved backend storage target instead:
\backend-fileserver.example.com\share\home\username\desktop\
Expected behavior:
Acrobat/PDFMaker should honor the DFS namespace or mapped network path selected by the user, or it should consistently trust both the DFS namespace path and the resolved backend target.
Actual behavior:
PDFMaker silently fails near completion unless the Acrobat privileged-folder path in the registry exactly matches the DFS namespace path used by the user.
Environment details to include:
Acrobat version: 2026.001.21563
Microsoft Word version: 16.0.19929.20172
Windows version: 25H2 build 26200.8457
DFS namespace used: Yes
Redirected folders used: Yes
Backend storage type: DFS target / SMB / Azure Files / other
Endpoint security present: Yes
Impact:
Users cannot reliably create PDFs from Word directly to DFS-backed network or redirected folders using Adobe PDFMaker. The failure is silent and intermittent, making it difficult to diagnose.