14 days · one site or 25 endpoints
A pilot you can fail us on.
Five success criteria, written down and agreed before anyone touches a domain controller. At the end we walk them in order and mark each one pass or fail in front of you. If they fail, you walk — which is the only reason writing them down first means anything.
The five criteria
These are not aspirations. They are the specific, observable things that must be true on day fourteen.
A remote machine completes domain logon with no VPN client
A laptop at somebody’s house, on their own broadband, signs in against your domain controller. Not a cached credential — an actual authentication against the DC, before the desktop loads.
Group Policy applies to that machine
`gpresult` on the remote machine shows your policies applied, from the same GPOs head-office machines get. This is the one that usually breaks on VPN-based setups, because policy needs the DC reachable before the user signs in.
File shares resolve and open
The mapped drives your users actually use, reachable by the same UNC path they use in the office, with the same NTFS permissions deciding who gets in.
RDP works with no public port and no port forward
A technician reaches a nominated server or desktop over RDP. We then verify from outside that nothing new is listening on your public IP — the port count before and after the pilot should be identical.
MFA is enforced on the same identity
A TOTP one-time code in front of the pilot applications, against the same directory identity, so you are not running a second parallel user database to make the pilot look good.
How the fortnight runs
Scope and sign-off
Days 1–2We agree the site or endpoint list, name the specific machines and shares that will be tested, and write the five criteria down with the exact wording both sides will judge against. Nothing is installed until this is signed.
Control plane and first nodes
Days 3–5The control plane is stood up on infrastructure you nominate, and the first endpoints join the overlay outbound. No firewall inbound rules are requested. If somebody asks you to open a port, the pilot has gone wrong.
Directory reachability
Days 6–9Domain controller reachability across the fabric, then domain logon, Group Policy, and file-share testing from a genuinely remote machine — not one sitting in your office on the corporate LAN.
Identity and access
Days 10–12Single sign-on for the nominated applications, TOTP enforcement, and technician RDP paths. External port scan repeated and compared against the day-one baseline.
Result
Days 13–14We walk the five criteria in order and mark each one pass or fail in front of you. You get the evidence — screenshots, gpresult output, the before-and-after port scan — whichever way it goes.
Who brings what
You provide
- One site, or up to 25 endpoints, that you are willing to test on
- A remote machine on a genuinely external connection
- Somewhere to run the control plane — your VM, your hypervisor, your call
- An AD administrator available for roughly two hours across the fortnight
- A nominated server for the RDP test, and two or three file shares
- The names of the applications you want behind single sign-on
We provide
- The five criteria written down and agreed before we start
- Deployment and configuration of the control plane and endpoint agents
- Overlay design across your sites and subnets
- External port-scan evidence, taken before and after
- A walkthrough of each criterion with pass or fail marked in front of you
- Removal of everything we installed, if you decide not to continue
Before you commit endpoints
What happens if the pilot fails its criteria?
You walk, and you keep the evidence. That is the entire reason the criteria get written down first — it removes our ability to redefine success at the end. Exact commercial terms are confirmed in writing before the pilot starts, so nothing about the exit depends on goodwill.
Do you need inbound firewall rules?
No. Endpoints establish outbound connections only. We take an external port scan before we start and repeat it at the end specifically so you can prove the exposed surface did not grow. If any part of the design needed an inbound rule, it would not be the design we are selling.
Do we have to touch the domain controllers?
We do not modify AD schema, and we do not require a new forest, domain, or trust. The pilot makes your existing domain controllers reachable across the fabric. Your GPOs, OUs, and group structure stay exactly as they are.
What if our branch site loses internet during the pilot?
The same thing that happens today with a site-to-site VPN: remote resources become unreachable until the link returns. Where a branch has its own domain controller or an RODC, local logon continues as normal. This is a property of the branch design, not of the overlay, and it is worth discussing during the review rather than discovering mid-pilot.
Can we pilot on production endpoints?
Most customers do, because a pilot on machines nobody uses proves nothing. Pick a department that will tell you honestly when something is slow. We would rather find a problem in week one on twenty-five real endpoints than in month six on two thousand.
What does the pilot cost?
Scope, duration, and commercials are fixed in writing before day one — no open-ended engagement and no change requests mid-flight. Ask during the readiness review and you will get the number for your specific scope.
Scope a pilot
Tell us the site, roughly how many endpoints, and what your remote users cannot do today. If the readiness review has not happened yet, start there instead — it is shorter and it may save you the pilot entirely.