EngineeringMechanical EngineeringDeployment
The SOLIDWORKS Administrative Image
Installing seat by seat is not merely slower than imaging — it produces an estate where no two workstations are configured identically, and where that divergence stays invisible until it causes a fault nobody can reproduce. The administrative image is the highest-leverage artefact in the deployment domain.
- Group · Deployment
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 15 min
01 Why Individual Installation Fails
Installing seat by seat is not merely slower than imaging. It produces an estate where no two workstations are configured identically, and where that divergence is invisible until it causes a fault nobody can reproduce.
Each interactive installation asks a series of questions: which products to install, where files live, which library location to use, which add-ins to enable, where the licence comes from. Answered independently on twenty machines, those questions produce twenty configurations. The consequences accumulate quietly — one engineer's drawings use a different template because their template path was typed differently; another's assemblies pull hardware from a local library rather than the shared one; a third has an add-in enabled that nobody else has.
An administrative image makes those decisions once, records them, and applies them identically to every seat — on first installation, on service pack, and on annual upgrade. It is the single highest-leverage artefact in the deployment domain.
Image types, option editor capabilities and deployment mechanics change between releases. The structure described here reflects the 2026 release family; confirm specifics against the installation and administration guide for the release you are deploying.
02 What an Administrative Image Is
An administrative image is a prepared installation source held on a network share. It contains the installation files for the selected products, together with a stored configuration describing how those products should be installed. A client machine runs the installation from that share and receives both the software and the configuration without being asked anything.
Two components matter. The image folder holds the installation payload. Alongside it sits an option editor executable that reads and writes the stored configuration — global settings that apply to every installation, plus group and machine-level overrides where teams need to differ.
Image types
More than one image type is available, trading disk footprint against how much is downloaded at installation time.
| Type | Footprint | Installation behaviour | Suited to |
|---|---|---|---|
| Standard | Largest — full payload on the share | Everything served from the local network | Most environments; the default choice where storage is available |
| Remote | Reduced | Part of the payload is retrieved over the internet at install time | Sites where network bandwidth to the share is more constrained than internet access |
| Compressed | Smallest on disk | Payload expanded during installation | Constrained storage; accepts longer install time in exchange |
The storage saving from the alternative types is real but modest against the cost of a slower or less predictable installation, and a fully local payload removes an external dependency from the rollout. Choose a reduced type only where a specific constraint justifies it.
03 Creating the Image
Download the complete installation set rather than a streamed installation, so the same source serves both image creation and later upgrades.
Launch the installation manager with administrative rights and select the option to create an administrative image.
Include everything any group will need. Products can be excluded per group later, but cannot be added without rebuilding.
Create the image locally for speed and stability. Building directly onto a network share is slower and more failure-prone.
Move the finished folder to its network location and share it with read access for the accounts that will install from it.
Open the option editor, set the configuration, then install to one representative machine before releasing to the fleet.
Root path length. The image expands into a deep subfolder structure. A long root path pushes component paths past the operating system limit, producing mid-installation failures whose error messages point nowhere useful. Keep the root path well under sixty characters — a short share name and a short folder name, not a descriptive path four levels deep.
UNC, never mapped drives. A mapped drive letter does not resolve under the system account used by automated installation, and behaves inconsistently when an installer is elevated or run as a different user. Address the share as \\server\share\image everywhere, identically.
Naming for upgrade
Include the release and service pack in the folder name — for example a folder named for the release year and service pack level. This serves three purposes: it makes the current image unambiguous when several are retained, it supports the automatic client upgrade mechanism which keys on the share location, and it prevents the common error of overwriting a working image with a new release before the rollout is complete.
04 The Option Editor
Where the configuration actually lives. Everything an interactive installation would ask a user is answered here instead.
Configuration scopes
Settings worth deciding deliberately
- Library and Toolbox location. The most consequential setting in the image. Point every client at the single authoritative shared location — a UNC path or a vault folder. Leaving this at the local default is how uncontrolled per-machine libraries proliferate.
- Licence source. Standalone serial numbers or a network licence server address. Getting this wrong means every seat requires manual correction after installation.
- System options file. The exported settings file that pre-configures file locations, template assignments and drafting defaults. Covered in the deployment and settings governance page.
- Previous version handling. Whether the prior release is removed or retained. Retaining it supports a staged upgrade and a rollback position; removing it saves disk and prevents accidental use of the old version.
- Add-in selection. Enable only what a group needs. Every enabled add-in adds startup time, and in a network licensing environment some consume entitlements on activation.
The option in the editor that launches the settings administrator is unavailable unless the machine running the editor has the application installed. Administrators who prepare images from a server with no client installation find the option greyed out with no explanation. Prepare images from a workstation that has the application installed.
05 Image Lifecycle
Service packs
Service packs do not require rebuilding the image from scratch. Patch content can be applied to the existing image, and clients then update from it without retrieving the full payload again. This keeps the service pack cycle cheap enough to actually perform, which matters — a fleet on mixed service pack levels is a recurring source of inconsistency.
Annual releases
A new release requires a new image. Retain the previous one until the rollout is complete and verified, then archive or remove it. Two images live simultaneously during a transition, which is exactly why the folder naming convention matters.
| Event | Action | Retain previous? |
|---|---|---|
| Service pack | Apply patch content to the existing image; clients update from it | Not applicable — same image |
| Annual release | Build a new image in a new folder; configure and pilot before release | Until rollout complete |
| Configuration change | Edit in the option editor; no rebuild required | Not applicable |
| New add-in entitlement | Rebuild required if the product was not included at creation | Until rollout complete |
| Licence server change | Edit the server address in global settings; existing clients need separate correction | Not applicable |
The image and its stored configuration represent real accumulated decisions — library paths, settings files, group definitions. Rebuilding that configuration from memory after a server loss is tedious and error-prone. It is small, it changes rarely, and it is routinely left outside backup scope. Add it.
06 Image Preparation Checklist
- Full file set obtained. The complete installation set is held locally, not a streamed installation.
- Built locally, copied to share. Image created on local disk for stability, then moved to its network location.
- Root path short. The image root path is well under sixty characters.
- UNC addressing. The share is addressed by UNC path from every client; no mapped drive letters anywhere in the configuration.
- Folder named for release. Release year and service pack level appear in the folder name.
- All products included. Every product any group might need is in the image, even where excluded per group.
- Library path set. Shared library and Toolbox location points at the single authoritative location, not the local default.
- Licence source correct. Serial numbers or licence server address entered and verified.
- Settings file attached. An exported system options file is referenced, prepared from a machine with the application installed.
- Groups defined. Teams needing different add-ins or paths have group entries rather than post-installation correction.
- Piloted. Installed to one representative machine and verified before fleet release.
- In backup scope. The image folder and its configuration are captured by the backup regime.
07 Frequently Asked Questions
We only have six seats. Is an image worth the effort?
Yes, and the argument is not about the first installation. Six interactive installations is perhaps two hours of work. The cost appears at the first service pack, the first new starter, the first annual upgrade, and every time somebody asks why one engineer's drawings look different from another's.
An image is roughly a half-day to prepare and configure properly. It pays back within the first upgrade cycle at any team size above two or three, and it is the artefact that makes the standards and library governance work enforceable rather than aspirational.
Can we use our existing software distribution system instead?
Partly. Enterprise distribution tooling can invoke the silent installation from the image, which works well and fits existing operational processes. What it does not replace is the image itself and its stored configuration — the distribution system delivers the installation, but the image is what makes that installation configured rather than merely present.
The combination is often the best arrangement: the image holds the configuration and the payload; the distribution system handles scheduling, targeting and reporting. Note that the silent method disables the built-in automatic upgrade prompt, which is expected when an external system controls timing.
Different teams need different add-ins. Do we need multiple images?
No. One image containing every product, with groups defined in the option editor to select which products each team receives, is the intended pattern and far easier to maintain than parallel images.
The constraint is at creation time: a product not included when the image was built cannot be added to a group later without rebuilding. Include everything any group might plausibly need, even where most groups will not receive it.
How many previous images should we keep?
One. Retain the outgoing release image until the new rollout is complete and verified across every seat, then archive or remove it. That gives a rollback position during the transition without accumulating storage.
The exception is a data-managed environment where the vault client must match the server year-version. There the vault client cutover is a single coordinated event, so the previous image ceases to be a viable rollback position once the server has moved — the rollback position at that point is the server backup, not the image.
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.