If you’re deploying Microsoft Dynamics 365 Business Central on-premises, the decisions you make about infrastructure on day one shape everything that follows. Network topology, service account configuration, authentication, encryption, backup strategy — get these right from the start and the next five years of operations run smoothly. Get them wrong and you’ll be paying the interest on that technical debt every single quarter.

This post covers the ten infrastructure best practices Microsoft documents for Business Central v28 (2026 release wave 1), grounded in Microsoft Learn sources linked at the end. Where I add practitioner judgment on top of Microsoft’s documented guidance, I say so explicitly.

Business Central on-premises is a three-tier application. Understanding which component handles which responsibility is the foundation for every other decision in this post.

Web tier — IIS 10. Internet Information Services hosts the Business Central Web client. That’s its job on this stack. The web client is what users’ browsers talk to.

Middle tier — Business Central Server. A .NET 8.0 Windows Service that runs the AL business logic, handles session state, and — importantly — exposes the web service endpoints. SOAP runs on port 7047 and OData runs on port 7048, both served by the Business Central Server service itself, not by IIS. The client services port is 7085.

Database tier — SQL Server. Stores all business data. Requires SQL Server compatibility level 160 or 170 for v28, with full-text search enabled.

Microsoft supports three deployment topologies. Choosing between them comes down to your security, compliance, and scale requirements — not a fixed user-count formula.

One-computer topology. All three tiers on a single machine. Supported by Microsoft and the simplest option to stand up. Typical use is development and evaluation environments. Microsoft does not publish a user-count cutoff for production use of the single-box topology, so that call is yours based on your workload characteristics.

Two-computer topology. This is the co-located pattern: the web server and Business Central Server on one machine, SQL Server on a separate machine. Microsoft explicitly recommends co-locating the web server and Business Central Server “for simplicity and performance advantages.” I default to this topology for most mid-market deployments I work on — but that preference is practitioner experience, not a Microsoft-documented default.

Three-computer topology. All three tiers separated. Choose this when you need DMZ separation, compliance-mandated isolation between tiers, or regulatory requirements that force physical separation of the web tier from the business logic tier. This topology has one important operational consequence: you must explicitly configure constrained Kerberos delegation from the web server to Business Central Server so that user credentials can flow across the double hop. This is non-negotiable — without it, authentication will fail.

The v28 (2026 release wave 1) system requirements page lists the minimum specifications. Don’t build to the minimum — build to your workload — but know the floor:

• Operating system (server components): Windows Server 2022 or Windows Server 2025. Windows Server 2019 is no longer supported as of v28.
• Operating system (alternative): Windows 11 Pro, Enterprise, or Education are listed as supported operating systems for both Business Central Server and web server components. In practice, most production deployments still run on Windows Server for capacity, patching, and operational reasons — but that’s practitioner guidance, not a support-matrix limitation.
• Runtime: .NET 8.0 plus .NET Framework 4.8.
• Web server: IIS 10.
• Memory: 16 GB RAM baseline. 32–64 GB recommended for deployments with large or numerous extensions.
• Database: SQL Server with compatibility level 160 or 170.

The default service account for Business Central Server is Network Service. Don’t use it in production. Microsoft’s hardening guidance is explicit about what to do instead:

• Use a dedicated domain user account. Never an administrator — not on the domain, not on any local machine the service touches.
• Minimum SQL privileges only. During initial database setup the account needs elevated permissions. Remove the dbcreator role as soon as setup completes.
• SPN registration is required. When Business Central Server runs under a dedicated domain account, you must register Service Principal Names (SPNs) on that account for Kerberos authentication to work correctly. This is Microsoft’s documented requirement, not an optional hardening step.
• Three-computer topology adds constrained delegation. If your web server and Business Central Server are on separate machines, you must configure Kerberos constrained delegation from the web server to Business Central Server. ADO.NET connection pooling simplifies the Business Central Server-to-SQL Server leg of the stack, but it does not eliminate SPN or delegation requirements on the client-authentication path.

A locked-down service account is one of the cheapest wins in this entire post.

Business Central supports four authentication methods. Microsoft’s documented guidance is clear but it is not expressed as a formal numbered ranking.

Microsoft Entra ID (via OpenID Connect) — recommended. This is Microsoft’s explicit recommendation for new deployments. Integrates with Conditional Access for MFA, Privileged Identity Management for admin accounts, and OAuth 2.0 for service-to-service integrations.

Windows authentication — supported. Works well for domain-joined clients and fully-owned internal environments. Still a valid choice when the deployment is air-gapped or when Entra ID integration isn’t operationally feasible.

NavUserPassword — last resort. Microsoft’s guidance is to use this only when Entra ID and Windows authentication aren’t viable options.

AccessControlService — legacy. For specific hosted scenarios only. Don’t reach for this in new deployments.

For integrations: OAuth 2.0 service-to-service is the forward direction. Never hardcode tokens. Use certificate-based service principals where possible.

Web service access keys: This is where on-premises and online behave differently. For Business Central online, access keys (Basic Auth) were deprecated and removed after October 1, 2022. For on-premises deployments, Microsoft’s deprecation page says access keys “remain available for the time being.” OAuth is the direction, but existing on-premises integrations using access keys will not break overnight. Plan the migration, don’t panic about it.

Require MFA. Conditional Access policies in Entra ID are the correct mechanism. Token binding and sign-in risk policies are the next layer.

Encryption in Business Central is straightforward if you don’t cut corners.

In transit. TLS 1.2 or later is mandatory for all Business Central Server communication. Microsoft has enforced this baseline since 2019 release wave 2. Use real certificates — wildcard certificates are a shortcut that will cost you during security audits. For the Business Central Server to SQL Server channel when those components are on separate machines, IPSec is the only Microsoft-supported encryption option.

At rest. Transparent Data Encryption (TDE) protects SQL Server database files and backups. BitLocker protects the entire Windows volume. Microsoft explicitly recommends using both together as defense in depth — neither alone is enough. TDE without BitLocker leaves the OS drive exposed; BitLocker without TDE leaves backups in the clear if they’re moved off the BitLocker volume.

Key management. Store encryption keys in Azure Key Vault. Document your key rotation schedule. Know exactly who has access to the master keys.

Two performance configurations deserve attention on day one.

DataCacheSize. The Business Central Server data cache has a default size of 9, which is approximately 500 MB shared across all users on that server instance. Each increment to this setting roughly doubles the cache size. Before you raise it, check whether your workload actually benefits — caching more data only helps if the data you’re caching is being reused across operations. Measure before you tune.

Read Scale-Out. If you’re running an Always On Availability Group, Business Central Server can route read-only workloads to read replicas. Reports, API GETs, and OData read operations are the typical candidates. This keeps your transactional workload isolated on the primary and is effectively a free performance win once HA is already in place.

Sync interval. Default is 30 seconds. Leave it unless you have a specific reason to change it — tightening this won’t speed up users and will increase database load.

Microsoft is blunt in their documentation: backing up is the only way to protect your data. Start your planning from the recovery scenario, not the backup schedule.

RPO and RTO. Define these before you design the backup strategy, not after. Recovery point objective tells you how much data loss is acceptable. Recovery time objective tells you how long the business can be down. These numbers drive every other decision.

Backup strategy. Full plus differential plus transaction log backups. Keep backups on separate physical media from production storage. Rotate off-site copies to Azure Blob Storage or equivalent geo-redundant storage.

Test the restores. Schedule restore drills. An untested backup is a guess, not a recovery plan.

High availability. Always On Availability Groups for SQL Server is the standard pattern. For the Business Central Server and web tiers, Windows Server Failover Clustering or load-balanced redundancy depending on your topology.

HA is never a substitute for backups. Replication copies corruption just as faithfully as it copies good data. If your primary gets hit with ransomware, your secondary goes with it. Backups are the second line of defense, not the first.

The day-two practices that separate stable deployments from ones that drift.

• Block port 7085 from external networks. This is the Business Central Server client services port. It does not belong on the public internet. Your firewall should reject any external traffic to it.
• Set NTFS disk quotas. Client uploads can exhaust the Business Central Server drive if left unbounded. Quotas are your guardrail.
• Scheduled updates. Business Central’s release cadence is major updates in April and October, minor cumulative updates monthly. Install them in planned windows — quarterly minor, annual major is a reasonable default — not reactively after an incident.
• Proactive logging. You cannot investigate what you didn’t record. Configure telemetry to Application Insights, keep Business Central Server logs for enough time to be useful, and establish a baseline for what “normal” traffic looks like before you need to recognize abnormal traffic.
• Audit the service account regularly. Permissions drift. Quarterly review against the minimum-privilege baseline catches it before it becomes an attack surface.

If you apply one practice from each section, you have the shortlist:

1. Know which tier does what — IIS is the web client only; SOAP and OData are on Business Central Server.
2. Pick a topology that matches your security model, not a user count.
3. Build to v28’s documented system requirements, not the absolute minimum.
4. Dedicated domain service account, SPN registered, minimum SQL privileges.
5. Entra ID with MFA; OAuth 2.0 for integrations.
6. TLS 1.2+ in transit; TDE plus BitLocker at rest.
7. DataCacheSize tuned to measured workload; Read Scale-Out if you have HA.
8. Backups designed backwards from RPO and RTO; restores tested on a schedule.
9. Port 7085 blocked externally; disk quotas in place; updates on a calendar.
10. Audit what you rolled out against this list in six months and fix what drifted.

All guidance in this post traces back to the following Microsoft Learn sources. URLs point to the en-us locale; substitute your locale as needed.

Architecture and deployment

• Deployment overview
• Deploying a Business Central demonstration environment — confirms SOAP port 7047 and OData port 7048 on Business Central Server
• System requirements for Business Central on-premises

Web services

• Compare REST APIs, OData, and SOAP web services
• Publish a web service — includes SOAP deprecation notice
• SOAP web services
• Web services authentication — access key deprecation timeline (online vs on-premises)

Security and identity

• Configure web client delegation — SPN registration and three-computer delegation requirements
• User authentication with Microsoft Entra ID
• Provisioning the service account

Configuration and administration

• Configure Business Central Server
• DataCacheSize configuration

Deep-dive posts on each of the ten topics above are in progress. Subscribe for updates.