The forum question comes up regularly: how do I get the PDM Convert Task to save PDFs outside the vault? The answers in search results reference SOLIDWORKS PDM 2016-2019 behavior. The mechanism has not fundamentally changed, but two things shifted enough to break older walkthroughs: the Advanced Scripting variable names differ by version, and the Task Host security model tightened in PDM 2021. This post covers the working approach for both PDM Standard and Professional.
What Each License Tier Can Actually Do
This matters before touching any settings:
| Capability | PDM Standard | PDM Professional |
|---|---|---|
| Output to same folder as source | ✅ | ✅ |
| Output to a fixed subfolder within the vault | ✅ | ✅ |
| Output path with variable tokens (filename, config, variable) | ❌ | ✅ |
| Output to a path outside the vault | ❌ | ✅ via scripting |
| Two simultaneous output locations | ❌ | ✅ |
| Edit the conversion script | ❌ | ✅ Advanced Scripting Options |
PDM Standard’s Convert Task has no mechanism to write outside the vault — not through the GUI, not through scripting (no scripting access exists in Standard). If you’re on Standard, the only path is the robocopy mirror described in Method 2 below.
Method 1: Advanced Scripting (PDM Professional)
The PDM Professional Convert Task has an “Advanced Scripting Options” button in the Output File Details section. This opens a VBScript editor containing the full conversion logic. The output destination is controlled by the convFileName variable — whatever string this holds when the script calls SaveAs is where the file lands.
Finding the convFileName line
Open the task’s Advanced Scripting Options and search (Ctrl+F) for convFileName. You will find an assignment line similar to:
convFileName = "[OutputPath]"
The [OutputPath] token is a PDM task placeholder. The task engine resolves it to a full UNC path before the script runs — so by the time your VBScript sees convFileName, it holds something like \\SERVER\Vault\Engineering\Projects\ABC\Part123.pdf.
Redirecting to an external folder
Insert these lines immediately after the convFileName = "[OutputPath]" line:
' Redirect PDFs to external archive, preserving the vault folder hierarchy
Const VAULT_ROOT As String = "\\SERVER\Vault\Engineering"
Const EXT_ROOT As String = "\\FILESERVER\PDFArchive\Engineering"
convFileName = Replace(convFileName, VAULT_ROOT, EXT_ROOT)
' Ensure the target directory exists before SaveAs is called
Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")
Dim targetDir As String
targetDir = fso.GetParentFolderName(convFileName)
If Not fso.FolderExists(targetDir) Then
fso.CreateFolder targetDir
End If
Set fso = Nothing
The Replace call does a string substitution on the resolved path. The VAULT_ROOT constant must match exactly — same UNC format, same capitalization, no trailing slash — because VBScript’s Replace is case-sensitive.
When convFileName points to a path outside the vault, PDM does not check in the converted file. The PDF appears on the file system at the external path and nowhere else in the vault.
Getting both a vault copy and an external copy
The Output File Details section in the task setup has two output slot rows. Configure slot 1 with the default vault-relative path and slot 2 with a hard-coded external UNC path using PDM tokens:
\\FILESERVER\PDFArchive\[FilePath]\[FileNameNoExt].pdf
[FilePath] resolves to the file’s vault-relative folder path, [FileNameNoExt] to the filename without extension. This does not require scripting — it’s a GUI configuration in the task setup.
The security change that silently breaks this in PDM 2021+
If convFileName points to a UNC path and the conversion completes without error in the PDM task log but the PDF never appears at the external location, the cause is almost always the Task Host service account.
Prior to PDM 2021, the Task Host service commonly ran as LocalSystem or a local machine account. LocalSystem cannot authenticate to network shares. PDM 2021+ hardened the default Task Host configuration, but installations upgraded from older versions often retained the old service account. The task runs, SOLIDWORKS produces the PDF, the script calls SaveAs, and the file write to the UNC path silently fails because the service account has no access.
Fix:
- Open Services.msc on the machine running the PDM Task Host
- Find SOLIDWORKS PDM Task Host service
- Change Log On As from Local System or a local account to a domain account with write permission on the external share
- Restart the service
The PDM task execution log (default: C:\ProgramData\SOLIDWORKS PDM\Logs\) contains the actual error. Search for Access Denied, Cannot create file, or network path was not found — these appear only in the log, not in the PDM client UI.
The CreateObject(“Scripting.FileSystemObject”) block
On machines where AppLocker or Software Restriction Policies are active, CreateObject("Scripting.FileSystemObject") inside the task script may be blocked. The Set fso = CreateObject(...) call succeeds but CreateFolder silently does nothing, and the subsequent SaveAs fails with “path not found.”
Alternative that doesn’t require FSO:
' Use Shell to run mkdir — works even when FSO is restricted
Dim shell As Object
Set shell = CreateObject("WScript.Shell")
shell.Run "cmd /c mkdir """ & targetDir & """", 0, True
Set shell = Nothing
The cleaner long-term solution is to pre-create the external directory structure to mirror your vault folder hierarchy, so the target directories always exist before the task fires and the mkdir call becomes unnecessary.
Method 2: Robocopy Mirror (PDM Standard and Professional)
For PDM Standard, or when you want a simpler operational model than maintaining a task script, separate the concerns: configure the Convert Task to write PDFs to a dedicated subfolder inside the vault, and use a scheduled Robocopy job to mirror that subfolder to the external location on an interval.
Step 1: Configure a dedicated PDF subfolder in the vault
In the Convert Task output path, set:
[VaultRootFolder]\PDF_Exports\[FilePath]\[FileNameNoExt].pdf
This writes all converted PDFs into vault_root\PDF_Exports\..., mirroring the engineering folder hierarchy, which is what Robocopy needs to produce a clean mirror.
Step 2: Create a Windows Scheduled Task with Robocopy
robocopy "C:\Vault\PDF_Exports" "\\FILESERVER\SharedPDFs" ^
/E /MIR /XA:H /XF "*.swp" "*.lck" ^
/LOG:"C:\PDM\robocopy_pdf_sync.log" /NP /NDL
Flag reference:
/E— copy all subdirectories including empty ones/MIR— mirror: delete destination files that no longer exist in source/XA:H— exclude hidden files (PDM stores vault metadata as hidden files in the local cache)/XF "*.swp" "*.lck"— skip PDM lock and swap files that may be open during an active conversion/NP /NDL— suppress progress percentage and directory listing in the log
Set the Scheduled Task to run every 15-30 minutes under a domain account with read access to C:\Vault\PDF_Exports and write access to \\FILESERVER\SharedPDFs. Running it under a logged-in user account is unreliable — that user’s session won’t always be active.
If you do not want the mirror to delete external PDFs when files are removed from the vault, replace /MIR with /E. /MIR provides an exact copy; /E is append-only.
Method 3: Custom Task via IEdmTaskCallback2 (PDM Professional, Developer Path)
For routing logic that goes beyond a string replacement — conditional output paths based on workflow state, file variables, BOM data, or ERP part numbering — a custom task implementation using IEdmTaskCallback2 gives full control. The script approach above is VBScript running inside the PDM conversion framework; a custom task is a registered COM DLL that replaces that framework entirely.
C# skeleton for a minimal custom task:
using EPDM.Interop.epdm;
using System.IO;
[ComVisible(true)]
[Guid("YOUR-GUID-HERE")]
public class ExternalPdfTask : IEdmTaskCallback2
{
public void OnCmd(ref EdmCmd poCmd, ref EdmCmdData[] ppoData)
{
if (poCmd.meCmdType != EdmCmdType.EdmCmd_TaskRun) return;
var vault = (IEdmVault11)poCmd.mpoVault;
var file = vault.GetFileFromId(poCmd.mlEdmDocID);
string sourcePath = file.GetLocalPath(poCmd.mlEdmFolderID);
// Read a vault variable to determine routing
string projectNumber = file.GetVar("ProjectNumber",
poCmd.mlEdmFolderID)?.ToString() ?? "MISC";
string outputPath = Path.Combine(
@"\\FILESERVER\PDFArchive",
projectNumber,
Path.GetFileNameWithoutExtension(sourcePath) + ".pdf");
Directory.CreateDirectory(Path.GetDirectoryName(outputPath));
// Open SolidWorks and export via standard SOLIDWORKS API
// swApp.OpenDoc6 → swModel.SaveAs3 → swModel.CloseDoc
// (standard API calls, same as any SolidWorks macro)
// Optionally check the PDF into the vault under a PDF subfolder:
// vault.GetFileFromPath(outputPath, out IEdmFolder5 folder)
// .CheckIn(poCmd.mlEdmFolderID, "Auto-generated PDF", ...);
}
public void OnSetupDlg(ref EdmCmd poCmd, ref EdmCmdData[] ppoData) { }
public void OnContMenu(ref EdmCmd poCmd, ref EdmCmdData[] ppoData) { }
}
Deploy with regasm /codebase ExternalPdfTask.dll on the Task Host machine, then configure the PDM task to use the COM class ID of this assembly. The vault variable lookup (file.GetVar()) lets you route files dynamically — something the VBScript approach can only approximate with string manipulation.
The main drawback: you need to build, sign, and deploy a DLL, which is not a one-afternoon task if your team hasn’t done PDM API development before. The VBScript approach covers 80% of real use cases with a fraction of the effort.
Why Answers from 2017-2020 Stopped Working
Three specific changes:
Token name drift. In PDM 2018 and earlier, some documentation referenced the output path variable as [Target] or sConvFileName rather than convFileName. If you open your task’s Advanced Scripting Options and the convFileName = "[OutputPath]" line doesn’t appear, search for [Target] or OutputFile — the variable name changed across PDM versions.
SolidWorks instance ownership changed. PDM 2022 changed how the conversion script environment initializes the SolidWorks COM connection. Pre-2022 scripts that called CreateObject("SldWorks.Application") directly to spin up a fresh SolidWorks instance began failing because PDM now manages the SolidWorks process lifetime. The correct variable to use is swApp, which the task framework pre-initializes. Creating your own SolidWorks instance inside the script creates a second orphaned process and the conversion silently does nothing.
Task Host service account. As covered above, the LocalSystem-to-domain-account change in PDM 2021+ is the most common silent failure mode for external path output. The old answers assumed LocalSystem — which worked for local paths and failed invisibly for network paths — and never mentioned configuring the service account.
Related Reading
For the full landscape of drawing export automation — Batch Plot, Task Scheduler, and PDM task options compared side by side — the SolidWorks PDM batch plot guide is the right starting point. Convert Tasks are the correct tool when the trigger is a PDM workflow state transition; scheduled macros or standalone add-ins suit bulk exports that don’t need PDM event awareness.
Where this fits in the larger automation picture: the SolidWorks workflow automation guide maps out when each automation layer (VBA macro, Task Scheduler, PDM task, C# add-in) is the right choice. The four levels of CAD automation gives the decision framework for determining which tier your team should invest in before building infrastructure around PDM tasks.