Revit Worksharing over VPN: branch offices working without conflicts
How to set up Revit Worksharing over VPN for branch offices: where to store the central file, how to avoid conflicts, disconnects and model loss.
Why Worksharing over VPN often fails
Revit Worksharing expects fast and stable access to the central file. When branches connect to it over VPN, Revit spends more time waiting for the network than writing changes. Any latency, packet loss or short disconnects become risky: synchronizations hang, the local file may think changes were saved while the central file is unreachable.
The problem is usually not a “heavy model” but how Worksharing works. It performs many small operations: element locks, writing changes, updating worksets, and internal requests. On a LAN this is almost invisible. Over VPN each request travels a longer path and can fail because of instability.
Most often one of three things goes wrong in branches: the VPN drops or recreates the tunnel periodically; latency and jitter increase (especially at peak times); or the central file sits on a regular network share without settings Revit needs (caching, antivirus checks, backups running during active work).
Typical symptoms point to the connection rather than the model: "Synchronize with Central" sometimes takes 30 seconds and sometimes 15 minutes for similar edits; occasional messages about losing access to the central file; different users see the same operations fail at different times; conflicts increase after disconnects; "Reload Latest" hangs for no obvious reason.
The goal when using Revit Worksharing over VPN is predictability — not just "it kind of works." Syncs should take roughly the same time, conflicts should be rare and explainable, and failures should be quickly attributable to network, team rules or model structure.
How Revit Worksharing works
Worksharing has one main object: the Revit central file. It lives in a shared folder and remains the single source of truth — that’s where the team’s changes ultimately go.
Each participant works with a local copy, not the central file directly. This keeps the model responsive, and the network is only involved during synchronization.
When you press Synchronize with Central, Revit writes your changes to the central file and pulls colleagues’ changes to update your local copy. Not the whole file is transferred, but packets of changes: which elements changed, who owns what, which worksets are open. That’s why stability matters more than raw megabits.
Worksets help split the model into logical parts and control what is loaded in a session. The practical rule is simple: open only what you need for the current task and keep the rest closed.
Ownership is another key mechanism. To modify an element you must "take ownership" of it. If someone else owns it, Revit will warn you and prevent the edit until the owner synchronizes or releases the element.
Conflicts usually arise from two situations: two people edit the same area at once, or someone holds elements claimed for too long and synchronizes rarely. If you agree on rules (how often to sync, which worksets to open, what counts as someone’s area), Worksharing remains manageable even in a distributed team.
Where to start: data to collect first
Before running Revit Worksharing over VPN, spend an hour gathering initial data. It’s cheaper than spending a week resolving conflicts, sync hangs and broken worksets.
The first decision is always the same: where will the central file live and who is responsible for it. It might be a file server at headquarters, a facility in a data center, or a dedicated server at one of the locations. The important thing is clarity: who owns it, how backups are done, and how stable access is ensured for everyone.
Next, get concrete numbers: how many users will open the model concurrently and how many branches will connect during a typical working hour. This determines whether a simple setup will suffice or a separate infrastructure is needed.
Describe the VPN with measurable metrics. Ten‑second drops can be worse than just "slow": Revit may decide the connection was lost during a sync and leave some changes suspended. Ask network engineers for basic path metrics to the central file: latency (ping), packet loss and how much these metrics vary during the day.
Also document the model itself: file size, number of linked files, sync frequency, and how actively the model changes during the day. A large model with frequent syncs needs a more predictable connection than a compact project with infrequent updates.
Don’t forget security requirements. They often dictate architecture more than speed: MFA, SMB restrictions, rules for local copies, access provisioning, logging and backups.
A simple rule of thumb: if you have three offices and 12 concurrent users and the VPN drops for a minute every hour, the problem is likely the channel and reconnection policy, not Revit. In such cases agree on network targets and the central file location before choosing the working scheme.
Three working schemes for branches and how to choose
When branches connect to the central file via VPN, the deciding factors are where the model is stored and how the network reaches it. In practice there are three clear schemes.
Scheme 1: Central file on a file server, access over VPN
The easiest to start with but most demanding of channel quality. Suitable when the VPN is stable, latency is low and drops are rare. If the connection often fluctuates or drops, the risk of hangs, unpredictable syncs and central file corruption rises.
This option usually fits small teams and less heavy models, where a branch is close to the server and the team is disciplined about syncing.
Scheme 2: Remote desktop (RDS/VDI) near the server
Run Revit where the server with the model is located (in the office or data center), and branches connect to remote desktops. The network carries screen image and input, not Worksharing operations to the central file. This greatly reduces the VPN’s impact on synchronization.
The advantage is stability and predictability. The downside is higher administration overhead: virtual desktops, licensing, user profiles and performance control.
Scheme 3: Autodesk cloud collaboration as an alternative to VPN
If company policy allows cloud and subscriptions, Autodesk cloud collaboration removes some risks of the classic VPN scenario. It’s not a magic button, but for distributed teams it often simplifies things: less dependence on branch channels to the file server.
To choose a scheme without long debates, look at five things: VPN stability (drops and tunnel recreations), latency and its spikes, readiness to administer RDS/VDI and servers, security requirements (including cloud policy), and scale (model size, user count, number of offices).
Mixed schemes (some people direct over VPN, others via RDS/VDI) often cause more problems than benefits: different sync speeds, different rules and varied failure reasons. Better pick one main path and standardize its rules.
Basic central file setup
The central file should live where access is most predictable. For Worksharing over VPN this usually means a server in an office or data center with a reliable disk subsystem and backups — not a user’s workstation or a random shared folder.
Where to store and how to organize
Allocate a dedicated file share for BIM projects and create a structure that’s easy to explain to newcomers. The path to the central file should be short and stable — avoid moving or renaming it mid‑project.
Example simple structure:
- Projects\2026\Client_Project\01_Central
- Projects\2026\Client_Project\02_Links
- Projects\2026\Client_Project\03_Exports
- Projects\2026\Client_Project\99_Archive
Agree separately where links and families live. When everything is mixed in one folder, broken links and long opens appear quickly.
Unified versions and plugins
Before creating the central file, ensure the whole team uses the same Revit version (including updates) and an agreed set of plugins. Otherwise issues may surface later as synchronization errors and strange warnings.
Rules for local copies
Fix a simple rule: one central file, each user has their own local copy stored on their local disk.
Short rules to record:
- Do not rename or move the central file.
- Keep the local copy on the local disk, not on a network drive.
- Name local copies clearly (for example, Lastname_Initials + date).
- Open the central file only for administration tasks.
Schedule windows for heavy operations (mass link updates, cleanup, large imports). Doing these at random times on a weak channel will cause hangs and conflicting changes.
Team rules to avoid conflicts
Conflicts arise more from how the team divides responsibility and how often they touch shared elements than from VPN itself. Without rules, people edit the same things simultaneously, keep the model open all day and sync at random times.
Start with a simple principle: keep in your session only what you need for the task. Open necessary worksets and links, close the rest. This reduces update time and the number of locks.
Next — sync discipline. Over VPN it’s especially important to sync regularly at clear moments: before starting edits, before handing over results and before breaks. Don’t batch all syncs until the end of the day.
For transparent ownership, agree on rules: each task is tied to a model zone and a responsible person; take ownership only of elements you actually edit; release ownership after edits; assign a coordinator to change shared items (grids, levels, key views); resolve disputes immediately, not at day’s end.
Also agree on model maintenance: audits and "compaction" on a schedule (for example, weekly outside peak hours) and done by a single responsible person. Splitting the model makes sense only if teams rarely touch the same elements. If everyone constantly edits shared levels and references, order and rules help more than splitting.
Network and VPN: what matters most for Revit
For Worksharing quality matters more than raw internet speed. During synchronization Revit reads and writes small chunks, holds locks and expects quick responses. That’s why Worksharing over VPN can fail even where large files download quickly.
Critical parameters: VPN session stability, latency and packet loss. Bandwidth is helpful but secondary.
Test the network as it behaves in real work, not with a simple "download a file" test: run long packet loss tests (aim for 0% over 15–30 minutes), check ping and its jitter, and detect short drops and tunnel recreations. For synchronizations prefer wired connections; use Wi‑Fi only for viewing and minor tasks. On laptops disable network adapter sleep and system sleep during work.
Agree with IT on maintenance rules: no VPN, router or provider changes during hours when the team synchronizes in bulk.
And have a clear plan for disconnects. For example: if the connection drops during Sync, don’t press Sync again; exit carefully following agreed steps and inform the coordinator; if the drop occurred between syncs you can continue locally but don’t take new worksets; after restoration check access to the central file, then sync in small groups.
Common mistakes that cost time and risk the model
The biggest losses usually come from habits and network limits, not a “bad Revit.” A small mistake can lead to an hour of waiting, ownership conflicts or risk of central file damage.
Common issues include: manually copying the central file between offices and ending up with several "almost central" versions; opening the central file directly over an unstable channel and working that way all day; mixing Revit versions, updates and plugins; running Audit/Purge during peak hours; ignoring warnings about conflicts and trying to force Sync.
A classic scenario: an engineer in a branch opened the central file over VPN, the connection blinked for 10 seconds, Revit froze, and after restarting some elements became "owned" by that user but left in an inconsistent state. The team spends hours sorting ownership and recovery.
In short, what really reduces risk: one central file in one predictable location; unified Revit version and agreed plugins; heavy operations done in designated windows by a single responsible person; always read warnings before acting; and when the connection is unstable, avoid a setup where the central file is opened directly over VPN.
Quick checklist before rolling out to branches
Before launching Worksharing over VPN for the whole team, run a short check. It takes an hour or two but often saves days.
Confirm five things: a single source of truth is defined (where the central file and backups live and who is responsible); everyone uses the same Revit version (including patches) and agreed libraries and templates; the local model is always on the user’s local disk; the VPN is tested under real working conditions for 2–3 hours (watch for drops, latency and jitter, not just speed); and there is a short action plan for a disconnect during synchronization.
It’s useful to rehearse a mini‑scenario: two users from different branches take different worksets, make small edits and sync sequentially. Then intentionally drop the VPN for one user for 10 seconds during sync and verify that the team knows the recovery steps.
Example setup: 3 offices and one model
Headquarters in Almaty keeps the Revit central file and is responsible for its state. Two branches (for example, Astana and Shymkent) work via VPN, but the central file physically resides near the team that most often maintains it: on the HQ file server with backups and a stable LAN.
Roles are divided so no one ends up as "responsible for everything." The BIM coordinator manages the central file, Revit version updates and log checks. Another person manages templates, shared parameters and coordinate systems. A families librarian handles family requests from branches and publishes updates on a schedule so changes don’t arrive in the middle of the working day.
The working rhythm is predictable: zones and tasks are agreed in the morning, everyone works in local copies, syncs happen by agreement (usually every 60–90 minutes and always before lunch and before leaving). If an item is constantly being fought over, it is assigned to a role or put into a separate workset.
The disconnect procedure is documented: don’t press Sync repeatedly; wait for VPN restoration and then retry in the right order; if messages about the central file appear, close without writing to central and notify the BIM coordinator.
To avoid guessing, record metrics: average Synchronize with Central time by office, number of conflicts/failures and VPN drop frequency during working hours. If Sync time steadily increases, the cause is usually the network, server disks or too large change packets between syncs.
Next steps: pilot, infrastructure and support
After you define rules and network requirements, fix one working variant and don’t change the scheme every week. Small differences in settings and habits quickly turn into conflicts and wasted time.
A practical order is: document the chosen scheme on one page (central file location, how users connect, backups, recovery steps), run a pilot on a non‑critical project (3–5 users, 5–10 working days, daily problem logging and measurable criteria).
At the same time prepare infrastructure: a reliable server for central files, workstations that confidently handle the model, and backups with clear recovery (who, how long and where the last working copy is). Assign responsibilities: BIM coordinator for rules and conflicts, IT for network/VPN/rights/backups, and the project lead for discipline and priorities.
If you need an end‑to‑end solution (servers, workstations, network, support and rules), involve a system integrator. For organizations in Kazakhstan this is often done through GSE.kz: as a manufacturer and integrator they can cover hardware for BIM, infrastructure and support so the working scheme does not depend on chance failures and ad hoc settings.
FAQ
Why does Worksharing over VPN behave unstably even if the internet is fast?
Most often the issue is latency, jitter and brief disconnects, not the model size. Worksharing performs many small network operations, and over VPN each of them becomes sensitive to instability, which can make synchronizations hang or produce access errors to the central file.
Where should I start if branches complain about Synchronize with Central hanging?
Check that the VPN does not recreate the tunnel frequently and that there are no packet losses. Make sure the central file is on a reliable file server, not a user workstation. Then enforce team rules: local copies only on local disks, regular scheduled Syncs and keeping only necessary worksets open during a session.
Which network metrics matter most for Revit Worksharing?
Focus on predictability: similar Sync times for similar edits and no random multi‑minute drops. If ping and its fluctuations are noticeable or the VPN occasionally drops even for a few seconds, direct access to the central file over VPN will likely cause problems.
Can a 5–10 second VPN drop really harm the team's work?
Yes. During Sync, Revit expects quick responses and holds locks. A short disconnection can leave changes in a limbo state or trigger ownership conflicts. Agree on a procedure for such cases in advance and reduce the chance of drops at the network level.
When is the "central file on a share + VPN" scheme acceptable, and when is it not?
Direct central file access over VPN can work when the VPN is stable, latency is low, the team is small and disciplined about syncing. If metrics fluctuate during the day or drops happen repeatedly, consider RDS/VDI next to the server or another approach that avoids Revit accessing the central file over an unstable channel.
Why does a mixed scheme (some users via VPN, others via RDS/VDI) often make things worse?
Because different connection qualities produce different Sync times and update moments, the team loses a common rhythm. That leads to more conflicts, elements stuck as "owned" and difficulty diagnosing failures. It’s usually better to choose one main way of working and lock its rules in place.
How to organize storage of the central file to reduce risks?
Keep the central file in one place on a server with clear backups and avoid moving or renaming paths mid‑project. Ensure antivirus, backups and scans do not interfere during active work — such interference causes delays and access errors. The central file should not be opened by users for daily work.
Why shouldn't the local copy be stored on a network drive or in a synced folder?
Each user must have their own local copy on their local disk, not on a network drive or a synchronized folder. This reduces network dependency during work and lowers the chance of corruption with unstable connections. Recreate local copies only by the team’s rules, not ad hoc.
Which team rules most effectively reduce conflicts and "owned" elements?
Stabilize the process: sync regularly, especially before starting edits, before breaks and before delivering results. Divide model zones and assign responsibility for shared items like grids, levels and key views. Don’t keep elements checked out “just in case” and close unnecessary worksets to reduce locks.
What should a user do if the VPN drops during Synchronize with Central?
Do not press Sync again and do not try to force a hung process. Follow the internal procedure: safely close your session, check access to the central file after the connection is restored, then synchronize in small groups starting with users who have fewer changes. If there are strange ownership captures or central file errors, involve the BIM coordinator to resolve ownership.