Network, VPN & certificates

Connectivity is the layer nobody notices until the first device can't join the corporate network. This section deploys Wi-Fi, certificates, root-CA trust and VPN in dependency order, in your own Intune tenant.

Why this matters

Network access is the first thing a freshly provisioned device needs and the last thing anyone verifies before it ships. Certificate-based 802.1x — the way corporate Wi-Fi should be done — is a chain of separate Intune payloads: the root CA has to be trusted, a certificate has to be issued to the device via SCEP or PKCS, and the Wi-Fi profile has to reference that certificate. Intune will happily deploy any one of these without the others and report success. The result is a device that enrols perfectly at home or on a guest network, then can't join corporate Wi-Fi the morning it arrives.

VPN has the same shape for remote workers: if the tunnel isn't there before the user needs an internal resource, the failure surfaces as a helpdesk call from someone you can't easily remote into — because they can't connect.

What a good build does

Decolla treats this section as a dependency chain, not a menu of independent toggles. The written plan orders it: root-CA trust into the Trusted Root store first, then the certificate profile (SCEP or PKCS), then the Wi-Fi and VPN profiles that consume the issued certificate. The dependency is declared, not assumed: the SCEP/PKCS profile item explicitly depends on the Certificate Connector, NDES or Cloud PKI item in the Tenant foundation section — a certificate profile with no issuing backend behind it is undeployable, and the plan says so before anything runs, rather than letting it deploy and fail silently on every device.

For VPN, the recommended baseline is native Always-On IKEv2 — a connection profile plus routing, with no third-party client to package, patch or troubleshoot. Where you're already standardised on a vendor client or a cloud-enrolled SSE agent, the catalogue carries those as client-plus-configuration items instead; and where the native Wi-Fi payload can't express what your network needs, there's a script-armed variant. Every item appears on the itemised plan with its delivery method and reversibility class, and each can be rolled back individually — Decolla removes what Decolla deployed.

Where it bites people

Two classics.

• The orphaned SCEP profile. Intune reports the profile deployed, but no certificate ever issues because the connector or NDES backend was never stood up. Every 802.1x Wi-Fi profile that references it then fails, and nobody notices until the first laptop lands on a desk.
• The missing root CA. Certificates issue and the Wi-Fi profile applies, yet clients still refuse to connect because the RADIUS server's certificate chain isn't trusted — a failure that, from the helpdesk's side, looks exactly like a wrong password.

Both are ordering problems. That is why the plan states the chain explicitly instead of trusting deployment order to work itself out.

What's in this section (14 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.