EngineeringMechanical EngineeringPlatform
SOLIDWORKS Operating Environment Configuration
Correct hardware on a badly configured operating environment performs like incorrect hardware. Most day-to-day stability is determined by policy decisions made outside engineering — antivirus scope, driver management, account rights and storage placement — which are rarely wrong in general and frequently wrong for this workload.
- Group · Platform
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 17 min
01 The Environment Around the Application
Correct hardware on a badly configured operating environment performs like incorrect hardware. Most of what determines day-to-day stability sits in policy decisions made outside engineering — antivirus scope, driver management, account rights, storage placement and update cadence.
These decisions are usually made once, for the whole estate, by people with no visibility of how CAD behaves. They are rarely wrong in general; they are wrong for this workload specifically. The administrator's task is to identify the small number of documented exceptions engineering needs, justify them, and get them recorded so they survive the next policy review.
Supported operating systems, supported office application versions and validated virtualisation platforms are revised with each release and have published end-of-support milestones. Confirm the current position for your release before planning an operating system migration or a virtualisation project.
02 Operating System & Support Lifecycle
Edition and version
The 2026 release family requires a 64-bit professional or enterprise edition of Windows 11. Consumer Home editions are not supported, and Windows 10 support ended with the 2025 SP5 release. Windows 11 additionally carries platform security prerequisites at the firmware level, which can exclude otherwise serviceable older hardware.
The consequence worth planning for is that an operating system retirement can convert a routine annual software upgrade into a hardware refresh programme. This is the single most common cause of an upgrade slipping a quarter.
Supported operating system and database versions are withdrawn on a published schedule, usually announced a release or two in advance. Maintain a short register of the retirement milestone for every platform component in service — workstation operating system, server operating system and database engine — and review it annually before upgrade planning begins. Discovering a retirement during an upgrade window is the expensive way to find out.
Associated application versions
Integration with spreadsheet and document applications underpins bills of materials, design tables and property links. Supported versions of those applications are also declared per release and retired on their own schedule. Where design tables are in use, an office application upgrade is a change that warrants testing rather than a routine desktop update.
03 Antivirus & Endpoint Protection
The highest-value configuration change available, and the one most often refused on principle rather than assessed on evidence.
Real-time scanning inspects files as they are opened and written. CAD work generates exactly the access pattern this is most expensive for: an assembly open touches hundreds or thousands of referenced files in rapid succession, and a vault check-in writes many files in sequence. Scanning each one adds latency that compounds across the operation.
What to exempt
File types
Native part, assembly and drawing extensions, plus template and library file types.
Effect: removes per-file scanning from every open and save.
Folder locations
Local vault view roots, working directories, template and library shares, and the application's temporary and backup folders.
Effect: covers intermediate files that are not caught by extension rules.
Server-side paths
Archive folders and database files on the data management servers.
Effect: prevents scanning of the vault archive, which is high-volume and already access-controlled.
Security teams reasonably resist blanket exemptions. The argument that succeeds is specific rather than general: exempt named extensions and named paths, not whole drives; note that vault archive content is written only by a controlled service account and is never user-executable; and offer a scheduled scan of the exempted paths outside working hours as compensating control. Frame it as a scoped exception with a compensating measure, and record it in the security documentation so it survives review.
04 Driver & Update Management
Graphics drivers
Certified graphics support depends on running a specific driver build, not merely a professional card. Any policy that pushes the latest available driver — Windows Update, vendor auto-update utilities, or a general endpoint management baseline — will move workstations off certification without anyone deciding to.
The correct configuration is to exclude CAD workstation graphics drivers from automatic update entirely, and to treat driver changes as deliberate, tested changes: verify the target version against the current certification listing, test on one machine against representative models, then deploy fleet-wide.
Multiple workstations developing graphical faults within the same few days, with no application change to correlate against, is almost always a driver push. Check driver versions across the affected machines before investigating anything in the application. This pattern accounts for a disproportionate share of escalated support cases.
Disk imaging
Cloning a machine image with the application already installed is not a supported activation path. Where machine imaging is part of the standard build process, either install the application after the image is applied, or use network licensing where the entitlement is not bound to the machine identity. Attempting to image a machine-activated standalone installation produces activation faults that are tedious to unpick across a fleet.
Application service packs
Service packs should be applied deliberately and uniformly, not machine by machine as users happen to be prompted. A mixed service pack state across a team is a low-grade source of inconsistency, and in a data-managed environment can produce compatibility complaints that are difficult to trace. Deploy service packs from the administrative image on a decided date.
05 Accounts, Rights & Profiles
Installation rights
The deployment method available depends on the rights model, so this must be settled before deployment is designed rather than discovered during rollout.
| Rights model | Deployment methods available | Considerations |
|---|---|---|
| Users are local administrators | All methods, including user-initiated installation from the image share | Simplest operationally; least controlled. Users can install unapproved add-ins and change system state. |
| Users are standard, IT installs | Pushed installation, or attended installation with elevated credentials | Controlled but adds a scheduling dependency on IT for every rollout and service pack. |
| Users standard, automated push | Scheduled task under the system account | The scalable option. Requires the machine account to have read access to the image share. |
Roaming profiles and folder redirection
Both are common in managed estates and both cause problems for CAD. Roaming profiles synchronise on logon and logoff; application settings and cached data inflate profile size and extend those operations substantially. Folder redirection that captures the documents folder can place working files or a local vault cache on a network share, converting local disk operations into network round trips.
Local vault views, temporary folders and working directories must resolve to local storage. If folder redirection policy captures them, performance degrades in ways that look like application faults and are difficult to attribute. Confirm the resolved physical path of these locations on a representative machine after any policy change — not the configured path, the resolved one.
06 Network & Path Conventions
Addressing shared resources
Shared resources — templates, libraries, the administrative image, a shared Toolbox — must be addressed by UNC path, identically from every client. Mapped drive letters fail in two specific and recurring ways: they do not resolve under the system account used by automated installation, and they behave inconsistently when an installer is elevated or run as another user.
The deeper problem with mapped drives is inconsistency. If one workstation maps a share as one letter and another maps it differently, file references resolve differently on each — which surfaces as missing references that appear only for certain users.
Latency and remote access
- Latency, not bandwidth, governs the experience. Assembly operations involve many small round trips; a high-bandwidth, high-latency link performs poorly regardless of throughput.
- Do not work directly against a remote share. The supported pattern for distributed teams is a local cache synchronised against a managed vault, or a replicated archive server at the remote site — not opening files across a WAN link.
- Virtual private network links are best-effort. Vendor support for specific VPN products is generally limited; performance issues over VPN are commonly referred back to the network provider.
- Licence server ports must be open. Network licensing requires specific ports inbound on the server and outbound from clients — the most frequent cause of licence availability complaints.
07 Virtualisation
Widely used and supported within defined bounds. The failure pattern is not virtualisation itself but the resource assumptions that usually accompany it.
Validated virtual environments are published per release; confirm your platform appears on the current list. Beyond that, three constraints determine whether a virtualised deployment succeeds:
Guaranteed resources
Processor and memory must be reserved, not shared on a best-effort basis. Contention with unrelated workloads is felt immediately in rebuild responsiveness.
Storage throughput
Placing a vault archive or a working volume on general-purpose shared storage alongside other workloads is the most common cause of poor check-in and check-out performance.
Graphics path
Virtualised workstations require a graphics acceleration path that presents certified capability. Software rendering is not a viable substitute for interactive modelling.
Server components are the strong case: archive and database servers virtualise well, given reserved resources and appropriate storage. Virtualised workstations are viable but demand more careful specification than physical ones, and are usually justified by access requirements — remote teams, contractor access, data residency — rather than by cost.
08 Environment Baseline Checklist
- Supported platform confirmed. Workstation and server operating systems, database engine and office application versions are all within support for the release in service.
- Retirement register maintained. End-of-support milestones recorded for every platform component and reviewed annually before upgrade planning.
- Antivirus exemptions documented. File types, client folders and server archive paths exempted, recorded in security documentation, with a compensating scheduled scan agreed.
- Driver policy in force. CAD graphics drivers excluded from automatic update; a named owner manages tested driver changes against the certification listing.
- Imaging approach settled. The application is installed after imaging, or network licensing is used.
- Rights model agreed. The installation rights position is decided and the deployment method chosen to match it.
- Local paths verified. Working directories and vault caches resolve to local storage; folder redirection does not capture them.
- UNC addressing throughout. All shared resources addressed identically by UNC path; no mapped drive letters in any configuration.
- Licence ports open. Required ports confirmed open inbound on the licence server and outbound from clients.
- Virtualisation validated. Where used, the platform is on the validated list with reserved resources and appropriate storage throughput.
09 Frequently Asked Questions
Our security policy prohibits antivirus exclusions. What now?
Blanket prohibition is rare once the request is scoped properly. What security teams generally refuse is whole-drive or whole-share exclusion. A request naming specific extensions and specific paths, with a stated rationale and a compensating scheduled scan outside working hours, is a different proposition and usually approved.
If it genuinely cannot be approved, measure the cost so the trade-off is visible: time a large assembly open and a sizeable vault check-in with scanning active and with it temporarily disabled on a test machine. Presenting the difference in minutes per operation, multiplied across the team, converts an abstract policy argument into a quantified one.
Can we keep engineering workstations on the standard desktop build?
Not without exceptions. The specific divergences a CAD workstation needs are the antivirus exemptions, exclusion of graphics drivers from automatic update, local rather than redirected working folders, and a hardware standard with its own specification and refresh cycle.
The workable arrangement is a documented engineering workstation build derived from the standard image, with those differences listed and justified. That is far easier to maintain than a wholly separate build, and far more reliable than repeatedly explaining the same exceptions to each new policy review.
How do we support engineers working from home?
Three patterns work. Network licence borrowing lets an engineer take an entitlement offline for a defined period and work locally. A virtualised workstation in the office with a remote display protocol keeps data and computation central. And where a vault is in place, a local cache synchronised over VPN can work for modest models, though large assemblies over a latent link generally will not.
What does not work is opening files directly from a network share across a remote link. The pattern of many small round trips makes this unusable at typical remote latencies regardless of available bandwidth.
Should engineers have local administrator rights?
It simplifies installation and lets engineers add add-ins and macros themselves, which is genuinely useful in a small team with high technical competence. It also removes the control that keeps a fleet consistent, and consistency is the point of everything in the deployment domain.
The scalable answer is standard user rights with automated deployment, which removes the need for elevated rights during installation entirely. Where that infrastructure does not exist, elevated rights for a small named group is a reasonable interim position — but it should be recognised as an interim position with a cost, not a permanent design.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.