Rimkus Replaces SolarWinds Serv-U Links With a Files.com Front Door Into SharePoint

Rimkus is a global engineering and technical consulting firm. Its experts investigate why things failed, from a building or a vehicle to a pipeline or a product, and deliver findings for corporations, insurance companies, law firms, and government agencies, including independent expert reports and testimony under cross-examination on matters ranging from small claims to multi-billion-dollar disputes. The firm operates from more than 100 offices worldwide, covering all 50 US states and 10 countries.

The work is organized as discrete client jobs, and each job gets its own SharePoint site: the system of record for everything the project produces and receives. Nearly every job also means exchanging files with outside parties. Clients, counsel, and vendors send in drawings, photos, video, audio, and inspection records, and Rimkus sends deliverables back. In a forensics practice, many of those files are evidence. How a file arrived, and who has touched it since, is not a detail. It is part of the product.

Rimkus put Files.com in front of SharePoint as the one governed path for external files, replacing SolarWinds Serv-U share links and in-person handoffs while keeping SharePoint as the system of record.

Every Client File Had to Land in the Job's SharePoint Site

External file exchange ran on two channels. Clients handed files over in meetings, and ad-hoc exchange ran through a SolarWinds Serv-U server the team maintained itself, using links that expired on a fixed timer. When a client missed the window, someone at Rimkus went back, found the files, and shared them again.

Rimkus wanted one path in their place. Every inbound file had to arrive with a record of who sent it, when it arrived, and who has opened it since, because for a firm whose product is expert findings, that record is part of the deliverable. And every file had to land in the job's SharePoint site rather than on a drive, a staging server, or a link that timed out.

Credentialed Clients, One-Off Senders, and No Second Copy

Any replacement had to match how clients actually work. A lawyer with a folder of site photos wants to hand it over in a meeting. A one-time counterparty asks where to send a video. Shutting off the old channels with nothing in their place would not have stopped the files. It would have stopped the work.

So when Rimkus moved to block USB devices under an internal security policy, the policy came with a condition: external parties needed another way in before it took effect.

That replacement had to clear four bars. Repeat clients needed credentialed access: a portal they sign into, scoped to their own job. One-off senders needed a path with no account and nothing to install. It had to carry the large drawings and media files the work runs on. And it could not create a second copy of the data: files had to land in the job's SharePoint site, the system of record, rather than on a staging server someone empties by hand.

Files.com met those requirements.

One Connection Into Tens of Thousands of SharePoint Project Sites

The architecture started from where the data already lived. Using a Files.com Remote Server Mount, Rimkus connected Files.com to its SharePoint tenant through a single system-level Entra ID connection. Every job site's address is derived from its job number, so one connection and one credential set can reach an estate of tens of thousands of active project sites, with each mounted site appearing in Files.com as an ordinary folder. A file uploaded through Files.com writes straight through to the job's SharePoint folder in real time. Nothing is duplicated, and nothing has to be moved between systems afterward.

On top of that mount sits the exchange layer. Repeat clients get Files.com credentials scoped to the folders for their own project. They sign in, see their job and nothing else, and what they submit lands in that job's SharePoint site. For a one-off sender, Rimkus issues a Files.com share link or an inbox address instead. The sender uploads from a browser, with no account, and the file arrives in the same project folder.

Rimkus's own engineers use the same front door from the field. On site, they upload photos and recordings from the Files.com mobile app directly into the job's files.

Every one of those actions (the sign-in, the upload, the download) lands in the Files.com audit log. The record Rimkus wanted behind every file is produced as a side effect of using the system.

One Governed Path Into Every Job

With Files.com in front of SharePoint, Rimkus replaced expiring links and in-person handoffs with one governed exchange path, and clients kept working the way they always had.

• Every external file now arrives through one path, whether the sender signs into a portal or opens a link.
• Every sign-in, upload, and download now leaves an audit record. For a business whose files are often evidence, that transfer history is part of the deliverable.
• Files land directly in the correct job's SharePoint folder. Nobody re-shares an expired link or maintains a staging server by hand.

The compounding result is that the pattern applies to every new job Rimkus opens. Because the mount is keyed to the site naming convention, each new project's SharePoint site can be reached through the same connection. The governed path is the default, not a per-project build.

Evidence Exchange With a Record Behind It

Today, a client with data for Rimkus signs into a portal or opens a link, and the file is in the job's SharePoint site with a record behind it before anyone at Rimkus has touched it. The consultant in a meeting points the client at the portal, and nobody spends the afternoon re-sharing links that timed out.