When working with the JT Engine, administrators may encounter a situation where the system fails to access files stored on mapped network drives, such as Z:\, during Planned Event imports. Although the service account running JT Engine may have full permissions to the target folder, the engine may still report that the files cannot be found. This behavior is a direct result of how Windows handles mapped drives within different execution contexts.
JT Engine operates as a Windows service, and this distinction is crucial. Mapped drives (drive letters assigned to network locations) exist only within an interactive user session. They are created when a user logs in and are stored in that user’s session-specific context. Windows services, however, run in their own isolated session that does not inherit drive mappings from any logged‑in user.
As a result, even if a mapped drive such as Z:\ is visible and accessible to a user, it does not exist from the perspective of the Windows service running the JT Engine. The service may have permission to the resource, but because the mapped drive itself is not defined within the service session, JT Engine cannot resolve the path.
Resolution: Use UNC Paths Instead of Mapped Drives
To ensure reliable access to network resources, all JT Engine file paths should be specified using UNC (Universal Naming Convention) paths instead of mapped drive letters.
A UNC path references the full network location directly, for example:
\\ServerName\SharedFolder\ImportFiles
Using UNC paths ensures that the JT Engine can consistently locate and access the required files, regardless of whether any particular user is logged in or whether mapped drives have been established. This method aligns with best practices for any application or service running under a Windows service account.
Examples
❌ X:\imports\datafile.csv
✅ \\192.168.1.10\imports\datafile.csv