Skip to main content
Solved

Recommended IIS setup for a new 2026 R1 on-premise install with Production and Sandbox instances

  • Oct 29, 2026 3:59 PM UTC
  • 2 replies
  • 34 views
  • Translate All

Hi everyone,

We’re setting up a new 2026 R1 on-premise install on Windows Server 2022. It will have two instances, Production and Sandbox, and each needs its own hostname:

https://erp.company.com → Production
https://erp-sb.company.com → Sandbox

Before we build it, we’d like to follow the recommended IIS layout. These are the two options we see:

Option 1: applications under Default Web Site (the Configuration Wizard’s default)

The wizard deploys both instances as applications under Default Web Site (/Prod and /Sandbox).
Both hostnames are bound to Default Web Site, and a URL Rewrite rule redirects each root to its application.
The URLs become https://erp.company.com/Prod/....

Option 2: a dedicated IIS site per instance, at the root

We create a separate IIS site for each instance with a host-header binding, and run the instance at the site root.
The URLs are clean: https://erp.company.com/....
As far as we can tell, the wizard doesn’t create sites, so the sites would have to be set up by hand before deployment.

Questions

  1. Which layout does Acumatica recommend for production on-premise installs, and why?
  2. If we go with Option 2, what’s the supported way to deploy an instance at the root of a dedicated site? Will the Configuration Wizard recognize and upgrade those instances correctly in future versions?
  3. How are Acumatica SaaS instances (*.acumatica.com) configured? Is each one its own site at the root, or an application behind a reverse proxy or load balancer? We’d like to match that pattern if it’s practical for on-premise.
  4. With Option 1, are there any downsides to having Production and Sandbox share Default Web Site? For example, inherited site-level settings, shared IIS logs, or each hostname reaching both instances.
  5. Are there any path-related issues with Option 1 to plan for, such as REST/OData endpoints, OAuth connected applications, SSO redirect URIs or the mobile app?

Thanks in advance for any guidance or experience you can share.

Best answer by KrunalDoshi

Hi ​@yzou64,

In my opinion, I would recommend going with Option 2 for Production:

https://erp.company.com

This provides a clean URL without requiring a virtual directory, which I personally prefer for a production environment.

For Sandbox, you can retain the Default Web Site and use different virtual directories to host multiple Acumatica instances. For example:

This approach also gives you the flexibility to maintain multiple development, testing, and upgrade instances without having to create a separate IIS site for each one.

Regarding REST/OData endpoints, OAuth, SSO, and the mobile app, having Production and Sandbox under different URLs should not cause any issues by itself. Each instance has its own base URL, so the endpoints and integrations can be configured independently. Just make sure you use the correct instance URL, including the virtual directory where applicable, and configure the appropriate OAuth redirect URIs, SSO settings, and mobile app connections for each environment.

One other thing I noticed is that you haven't mentioned your database setup. My recommendation would be to host SQL Server on a separate server rather than on the same server as the Acumatica application, especially for a production environment. This can help with resource isolation and overall performance.

Since you are planning an on-premise installation, I believe this would be a practical and manageable approach.

Regarding how Acumatica manages its SaaS infrastructure (*.acumatica.com), I don't have first-hand experience with its underlying IIS configuration, so I wouldn't want to speculate. My suggestions are based on my past experience maintaining and managing on-premise Acumatica client installations.

For the required IIS Windows features and configuration, you can refer to this article:

https://www.acumatica.com/blog/setting-up-local-developer-instances-of-acumatica/

Although the article focuses on setting up developer instances, it should give you a fair idea of the IIS prerequisites and configuration.

For additional guidance on IIS performance optimization, you can also refer to Microsoft's technical documentation:

https://learn.microsoft.com/en-us/biztalk/technical-guides/optimizing-iis-performance

Hopefully, this helps!

View original

2 replies

KrunalDoshi
Pro I
Forum|alt.badge.img+9
  • Pro I
  • Answer
  • Nov 2, 2026 12:54 PM UTC

Hi ​@yzou64,

In my opinion, I would recommend going with Option 2 for Production:

https://erp.company.com

This provides a clean URL without requiring a virtual directory, which I personally prefer for a production environment.

For Sandbox, you can retain the Default Web Site and use different virtual directories to host multiple Acumatica instances. For example:

This approach also gives you the flexibility to maintain multiple development, testing, and upgrade instances without having to create a separate IIS site for each one.

Regarding REST/OData endpoints, OAuth, SSO, and the mobile app, having Production and Sandbox under different URLs should not cause any issues by itself. Each instance has its own base URL, so the endpoints and integrations can be configured independently. Just make sure you use the correct instance URL, including the virtual directory where applicable, and configure the appropriate OAuth redirect URIs, SSO settings, and mobile app connections for each environment.

One other thing I noticed is that you haven't mentioned your database setup. My recommendation would be to host SQL Server on a separate server rather than on the same server as the Acumatica application, especially for a production environment. This can help with resource isolation and overall performance.

Since you are planning an on-premise installation, I believe this would be a practical and manageable approach.

Regarding how Acumatica manages its SaaS infrastructure (*.acumatica.com), I don't have first-hand experience with its underlying IIS configuration, so I wouldn't want to speculate. My suggestions are based on my past experience maintaining and managing on-premise Acumatica client installations.

For the required IIS Windows features and configuration, you can refer to this article:

https://www.acumatica.com/blog/setting-up-local-developer-instances-of-acumatica/

Although the article focuses on setting up developer instances, it should give you a fair idea of the IIS prerequisites and configuration.

For additional guidance on IIS performance optimization, you can also refer to Microsoft's technical documentation:

https://learn.microsoft.com/en-us/biztalk/technical-guides/optimizing-iis-performance

Hopefully, this helps!

Translate

  • Author
  • Freshman I
  • Nov 2, 2026 2:20 PM UTC

Thank you, Krunai. Very thoughtful reply. I like the idea of using Default Web Site as sandbox instances

Translate