A depot outside Emerald, a clinic in a town of 3,000, a weighbridge office at the end of a gravel road, a farm office where the nearest exchange is a tin shed. Australian businesses run thousands of sites like these, and the IT conversation about them is usually framed backwards: can this site handle the cloud? The more useful question is which connection, and which configuration patterns, let a remote site run on the same Microsoft 365 environment as head office without the link becoming a daily complaint.
Frontrow supports sites like these across regional Queensland and South Australia from offices in Mackay, Townsville, Brisbane and Adelaide, and the honest summary is that remote-site cloud IT works well now, provided three things are chosen deliberately: the link, the sync patterns, and the short list of things that genuinely still belong on site.
The connectivity options, honestly compared
Everything below depends on the link, so it is worth choosing with current information rather than the town's folklore about what is available. Coverage and products change; several options that were not worth considering five years ago are now the sensible default.
- nbn Business Fibre Zones: nbn designates zones, including many regional centres, where its business-grade Enterprise Ethernet fibre product is available through service providers, often without the fibre build cost that would otherwise apply. If a site sits in or near a designated zone, this is usually the strongest option: symmetrical speed options and business-grade service levels through the provider. Worth checking even for sites that assume they are out of reach, because zone boundaries are not intuitive.
- nbn fixed wireless: serviceable for a small site's M365 workload where the signal is good, and nbn has upgraded the fixed wireless network in recent years. Performance varies with distance from the tower and congestion, so test at the actual site rather than trusting the address checker alone.
- Starlink Business: Starlink markets a business-grade service in Australia (checked August 2026), and low-earth-orbit satellite has changed the equation for sites beyond fixed infrastructure entirely. Latency is dramatically lower than older satellite services and comfortably supports Teams calls. Plans, hardware and pricing change frequently, so verify current terms with Starlink directly rather than from any article, this one included.
- 4G/5G: perfectly workable as a primary link for a small site with good coverage, and the natural failover path for everything above. Check the actual carrier signal on site, and watch data allowances if the site will sync large files.
The pattern Frontrow recommends for any site that matters operationally: one primary link chosen from the list above, plus a failover on a physically different path, usually 4G/5G behind a router that handles the switchover automatically. The combination costs far less than the downtime it removes.
Microsoft 365 patterns that survive a flaky link
M365 was built for exactly this shape of usage; most remote-site pain comes from configuration that fights it. The native sync model keeps working files on the device and reconciles changes when the link allows, which is precisely what an intermittent connection needs. The anti-pattern is anything that makes every file operation a live round trip over the link.
- OneDrive Known Folder Move: redirect Desktop, Documents and Pictures into OneDrive by policy for every remote-site user. Staff work on local files at local speed; sync happens opportunistically in the background. A dropout costs nothing but sync delay.
- Sync, don't map: avoid mapped drives to cloud storage or file access routed through an always-on VPN. Both turn every open and save into a live network operation, which is exactly what a flaky link cannot support. Synced SharePoint libraries and OneDrive give the same files without the fragility.
- Use OneDrive sync health reporting: Microsoft provides admin-side sync health reports that show, per device, whether sync is current or wedged. For remote sites this is the difference between finding out a device has not synced for three weeks from the dashboard, or from a data-loss incident.
- Teams on a poor link: chat and recently opened content tolerate dropouts reasonably well, and calls hold up on Starlink-class latency. Anything needing live service, joining meetings and presence above all, drops with the link, so plan around scheduled syncs and asynchronous updates for the worst sites rather than promising head office a permanent video presence.
- Be deliberate about large files: a site working with drone imagery, CAD or media should sync only the libraries it needs. Selective sync and storage settings exist precisely so a 2 GB export does not queue behind the day's invoices.
Intune and patching over intermittent links
Device management is where intermittent connectivity worries people least justifiably. Microsoft Intune was designed for devices that are not always on the corporate network: devices check in when they have a connection, collect policy, and report state. A device offline for two days simply picks up where it left off. The practical work is about bandwidth scheduling, not reachability.
- Let update downloads happen on the site's quiet hours rather than competing with the working day on a constrained link.
- Use Delivery Optimization so devices on the same site LAN share downloaded update content between themselves instead of each pulling the full payload over the link.
- On metered or allowance-capped links, configure Windows and OneDrive metered-connection behaviour deliberately rather than leaving defaults to decide when a feature update downloads.
- Accept longer compliance tails: a remote fleet reaches patched state days after a metro fleet, and reporting should be read with that expectation rather than treated as failure.
Identity when the link drops
A common fear about cloud identity at remote sites: if the link dies, can anyone even sign in? For the case that matters day to day, yes. Windows devices joined to Microsoft Entra ID cache sign-in for users who have signed in before, so staff can open their laptops and work on locally synced files with the link down. What stops is anything live in the cloud, which was stopping anyway with the connection gone.
Two design notes follow from that. First, do not stand up a domain controller at a remote site purely for sign-in; cached Entra ID sign-in already covers the offline case, and a neglected server at a remote site is a liability, not a resilience feature. Second, harden the identity layer properly at the tenant, because remote-site devices live their whole lives outside any office network perimeter. Conditional Access, MFA method choices and device compliance rules do the work a site firewall never could. Frontrow's approach to that layer is covered at /insights/tenant-hardening-as-a-managed-service-australia.
When a local server still earns its place
Cloud-first does not mean cloud-only, and pretending otherwise produces bad outcomes at exactly these sites. A local server, or more often a small local appliance, still earns its place in a few specific situations, and it is worth being honest about which ones.
- Genuinely large working datasets: geospatial imagery, CAD assemblies, video. Where the daily working set is tens of gigabytes, local storage as the working tier with cloud as the system of record beats forcing everything through the link.
- Line-of-business systems that assume LAN latency: some agricultural, workshop and clinical applications simply were not written for a 600 ms bad day. Until replaced, they need local hosting.
- Plant and industrial systems: anything controlling physical equipment should not depend on an internet link to function safely, full stop.
- What no longer earns a place: the general file server, local email, and the do-everything box under the counter. Those workloads moved to M365 for good reasons, and remote sites benefit from that move more than metro ones, because there is no on-site IT to nurse a failing box.
Where local equipment remains, treat it as an edge cache, not a system of record: backed up to the cloud, monitored remotely, and replaceable without archaeology.
Monitoring sites you cannot drive to
The last piece is knowing the site is in trouble before the site rings. When the nearest technician is four hours away, monitoring is not an optional extra; it is the difference between posting a replacement router and posting a person.
- Agent-based monitoring on every device, reporting to the management platform whenever a connection exists, so device health does not depend on someone at the site noticing.
- Alerting that distinguishes the three failure modes: site power gone, site link gone, single device gone. Each has a different response, and a monitoring setup that reports all three as offline wastes every first hour.
- An out-of-band path into the router: a management channel over a separate cellular connection turns many site visits into ten-minute remote fixes.
- UPS and environment monitoring in any room with equipment: temperature in a tin shed in January is a legitimate IT metric in regional Australia.