EngineeringMechanical EngineeringDeployment
SOLIDWORKS Deployment Methods & System Options Governance
A prepared image is a plan; deployment is the execution. The method available is constrained by a decision usually made elsewhere — whether engineers hold local administrator rights — and the settings file carries the second half of configuration control: how the application behaves, and which of that a user may change.
- Group · Deployment
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 18 min
01 From Image to Installed Fleet
A prepared image is a plan. Deployment is the execution, and the method chosen is constrained by a decision usually made elsewhere: whether engineers hold local administrator rights.
Three delivery methods exist, distinguished by who initiates the installation and under which account it runs. They are not interchangeable — one supports automatic upgrade prompting and another does not, one requires no user rights at all, and each fits a different operating model. Choosing before the rights model is settled leads to rework.
Deployment also carries the second half of configuration control. The image determines which products install and where files live; the settings file determines how the application behaves once running — file locations, template assignments, drafting defaults, and which of those a user may subsequently change.
Deployment mechanics and the settings administration tool have evolved across releases and continue to. The structure described reflects the 2026 release family; confirm specific steps against the installation and administration guide for the release being deployed.
02 Delivery Methods Compared
| Method | Initiated by | Runs as | User rights | Automatic upgrade | Best fit |
|---|---|---|---|---|---|
| Guided | The user, from the image share | The logged-on user | Local administrator | Supported | Small teams; environments where users control their own upgrade timing |
| Silent | A script or distribution system | The invoking context | Local administrator | Disabled | Estates with existing software distribution tooling controlling timing |
| Automated push | The administrator, from the option editor | The machine's system account | None required | Administrator-controlled | Managed fleets where users are standard accounts |
The automatic upgrade mechanism
The guided method supports a useful behaviour: when the image share is updated to a newer release or service pack, clients installed from that share detect the change and prompt the user to upgrade. This keeps a fleet current without administrator intervention per machine.
The mechanism keys on the share location, which is why the image folder naming convention matters. It is also why the silent method disables it — a script-invoked installation records no relationship to a monitored share. Where an external distribution system controls timing, that is the intended behaviour rather than a limitation.
The pushed method executes through the operating system's task scheduler on each target machine, running under the local system account. That account is presented on the network as the machine's own identity, so the machine account — not the user account — must have read access to the image share. This is the single most common reason a pushed deployment fails with a permissions error that appears nonsensical, because the administrator's own access to the share is irrelevant to it.
03 Rollout Sequencing
A deployment that reaches every seat simultaneously has no recovery position. Sequencing is what converts a risky event into a controlled one.
- Stage 1Validate add-ins and automationTest third-party add-ins, internal macros and any integrations against the target release on a non-production machine. This is the most common cause of a rollout being halted mid-way.
- Stage 2Deploy to the administratorInstall to your own machine first. Anything the configuration gets wrong is discovered by the person able to fix it, before anyone else is affected.
- Stage 3Pilot groupThree to five engineers covering the range of work — assembly design, drawing production, simulation if applicable. Run for at least a working week against real deliverables, not test files.
- Stage 4Correct and re-verifyFix whatever the pilot surfaced in the image configuration rather than on the pilot machines, so the correction propagates to everyone.
- Stage 5Staged fleet releaseRelease by team rather than all at once, leaving a gap between groups. Where the vault client must match a server version, this staging applies to the CAD application only.
- Stage 6Verify and closeConfirm version and configuration consistency across the fleet, then retire the previous image once every seat is verified.
Templates resolve from the shared location; library components insert from the shared library and not a local copy; drawing views and bills of materials generate correctly against real assemblies; add-ins load; macros run; printing and export to the formats you actually issue behave as expected; and where a vault is in use, check-in and check-out complete normally. A pilot that only confirms the software launches has verified nothing that matters.
04 System Options Governance
The settings administration tool exports a settings file that the image applies to every client. Its distinguishing feature is that applying a value and preventing its change are separate decisions.
Apply and lock as independent controls
Each option carries two controls. The first determines whether the exported value is applied at installation. The second determines whether the user may subsequently change it. This produces four possible treatments, and choosing correctly between them is what separates governance from control for its own sake.
| Applied | Locked | Effect | Use for |
|---|---|---|---|
| Yes | Yes | Value set and cannot be changed | File locations, template assignments, library paths — anything where divergence breaks standards |
| Yes | No | Sensible default set; user may adjust | Display quality, view manipulation, performance settings with a good starting value |
| No | Yes | Whatever value exists is frozen | Rarely useful; produces inconsistent frozen values across machines |
| No | No | Untouched | Genuinely personal preferences the organisation has no interest in |
A defensible locking policy
Lock — divergence has a cost
- File locations: templates, sheet formats, design library, materials, and the shared hardware library.
- Default template assignments for parts, assemblies and drawings.
- Drafting standard and units defaults.
- Backup and auto-recover paths, so recovery files land somewhere known.
- Any setting with a known-bad value that produces support calls.
Apply but leave open — preference is legitimate
- Display quality, shaded and edge display defaults.
- Spin, zoom and view manipulation behaviour.
- Colour schemes and interface layout.
- Mouse gesture and shortcut configuration.
- Performance settings that vary appropriately with workstation capability.
Locking settings without explanation reliably generates resentment and, in an estate where anyone holds elevated rights, attempts to circumvent it. A short published list — each locked setting, its value, and one line on why — changes the conversation entirely. An administrator who can justify every lock meets very little resistance; one who cannot should reconsider whether the lock is doing useful work.
The settings administrator is launched from within the option editor, and that option is unavailable unless the machine running the editor has the application installed. Prepare images and settings files from a workstation with a working installation, not from a server.
05 Post-Deployment Verification
A deployment is not complete when installation succeeds. It is complete when the configuration is confirmed present.
- Version and service pack. Confirm every seat reports the intended release and service pack level. A mixed estate is the failure this whole domain exists to prevent.
- File locations. Check the resolved paths for templates, library and materials on a sample of machines. Configured path and resolved path can differ where folder redirection policy intervenes.
- Library source. Insert a hardware component and confirm it comes from the shared location rather than a local copy. This is the check most often skipped and most consequential when it fails.
- Add-in state. Confirm each group has the add-ins intended, and no others. Unintended add-ins consume startup time and, under network licensing, may consume entitlements.
- Licence source. Verify seats are drawing from the intended source, and that network seats are not falling back to a standalone activation.
- Locked settings. Confirm the locked options are actually locked on a sample machine — a settings file that failed to apply produces an installation that looks correct and is not.
Capture the confirmed configuration — release, service pack, file locations, add-ins per group — in the standards register at the close of each rollout. It becomes the reference point for the next upgrade and the first thing to compare against when a machine starts behaving differently from its peers.
06 Common Deployment Failures
| Symptom | Likely cause | Correction |
|---|---|---|
| Pushed install fails with a permissions error | Machine account lacks read access to the image share | Grant the machine account, not the user account, read access |
| Installation fails part-way with an unhelpful error | Image root path too long for the expanded structure | Rebuild the image under a shorter root path |
| Install works interactively, fails when automated | Mapped drive letter that does not resolve under the system account | Address the share by UNC path everywhere |
| Clients never prompt for upgrade | Silent method used, which disables the mechanism | Expected behaviour; control timing through the distribution system instead |
| Settings file option greyed out | No local installation on the machine running the option editor | Prepare the image from a workstation with the application installed |
| Templates resolve to a local path after deployment | Folder redirection policy intercepting the configured location | Check the resolved path, not the configured one; exclude from redirection |
| One team missing an add-in | Product not included when the image was created | Rebuild the image with all products included; select per group |
07 Deployment Checklist
- Method matched to rights model. Delivery method chosen against the agreed local administrator position, not the other way round.
- Machine account access granted. Where pushing, target machine accounts have read access to the image share.
- Add-ins and macros validated. Third-party add-ins and internal automation tested against the target release before any user is deployed to.
- Administrator first. Deployed to your own machine before the pilot group.
- Pilot run against real work. Three to five engineers, a working week, real deliverables — not test files.
- Corrections made in the image. Pilot findings fixed in the image configuration so they propagate, not patched on individual machines.
- Staged release. Fleet released by team with gaps between groups, not simultaneously.
- Settings file applied and confirmed. Locked options verified as actually locked on a sample machine.
- Library source verified. A component inserted on a sample machine comes from the shared location.
- Locking policy published. The list of locked settings and their justification is available to the team.
- Verified state recorded. Confirmed configuration captured in the standards register at close of rollout.
08 Frequently Asked Questions
Our engineers object to locked settings. How much should we lock?
Lock what has an organisational consequence when it diverges, and nothing else. File locations, template assignments and library paths qualify — divergence there produces inconsistent drawings and unreliable bills of materials. Colour schemes and mouse behaviour do not.
The complaint is usually not about locking as such but about locking without explanation. Publishing the list with a one-line justification per item resolves most of it. If you find yourself unable to write that justification for an item, that is a reasonable signal to unlock it.
Can we deploy over the top of the previous version, or must we uninstall first?
Both are supported and the choice is set in the image. Removing the previous version saves disk and prevents engineers inadvertently continuing to work in the old release — which matters because file format progression is one-way and a file saved in the newer version cannot be reopened in the older one.
Retaining it gives a per-machine fallback during a staged rollout. The usual pattern is to retain during the transition and remove once the rollout is verified complete. Where a vault client must match a server version, retention offers less than it appears, since the old client cannot connect once the server has moved.
How long should a pilot run?
At least one full working week, and it should span the range of work the team actually does. A pilot that only covers assembly modelling will not surface a drawing template fault or a bill of materials problem, and those are exactly the issues that are expensive to discover after a fleet release.
Where the release includes changes to drawing or annotation behaviour, extend it until the pilot group has issued real drawings through your normal approval route. The test is whether documentation leaving the business is correct, not whether the software runs.
What if a deployment goes wrong mid-rollout?
This is what staging is for. Halt further releases, and address the affected group. Where the previous version was retained, affected machines have a local fallback; where it was removed, reinstall from the retained previous image.
The important discipline is to diagnose and correct in the image configuration before resuming, rather than patching affected machines individually. Individual fixes leave the underlying fault in place for every seat still to come, and reintroduce exactly the divergence the image exists to prevent.
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.