Not Every Website Should Be Rebuilt Just to Stay Online

Many stable websites depend on ASP, ASP.NET, .NET, or a specific Windows runtime.

These websites may contain business information, internal systems, membership services, or years of accumulated data. Rebuilding them creates cost, compatibility risk, and the possibility of losing important functionality.

NNS Windows Web Hosting provides a sustainable runtime for Windows website applications. Existing application structures can be retained and managed through a clear control panel.

One Environment for Multiple Generations of Websites

Depending on the selected product and node, NNS Windows Web Hosting can run:

• Static HTML websites
• Classic ASP applications
• ASP.NET and .NET websites
• PHP website applications
• Websites that require Windows permissions and configuration files

Users do not need to maintain separate servers for different application types. Website environments, domains, files, databases, and FTP are managed as one service.

Available versions are displayed by the selected product and node.

wwwroot Is the Real Website Entry Point

After activation, public website files belong in the wwwroot directory.

The homepage, images, stylesheets, scripts, and application files accessed through the domain must be located in this directory or one of its subdirectories.

Common entry files include:

• default.aspx
• default.asp
• index.html
• index.htm
• index.php

If the domain opens but still displays a default page, first confirm that the application was uploaded to wwwroot.

The Application Pool Is the Core of Independent Operation

Each Windows website runs inside its own application pool.

The application pool starts and hosts the website process while separating it from other hosting services on the same node. An application failure should not directly affect other websites.

After changing the runtime, updating configuration, or encountering an unresponsive application, the website application pool can be restarted without restarting the entire server.

This reduces troubleshooting from a server-wide operation to a website-level action.

web.config Controls Website Behavior

The web.config file can control:

• Default documents
• URL rewriting
• Redirects
• Custom error pages
• Access permissions
• Runtime parameters
• Static files and request processing

An application's original web.config should be preserved during upload. An incompatible configuration can cause server errors, redirect loops, or inaccessible pages.

Keep the previous configuration before making changes so the website can be restored quickly.

Windows Directory Permissions Must Be Precise

Windows websites use directory permissions to control whether an application can read, write, modify, or delete files.

Upload, cache, and data directories often require write access. Core application directories and configuration files should not receive unrestricted permissions.

Insufficient permissions can cause failed uploads, cache errors, images that cannot be saved, data files that cannot be written, and failed application updates.

Excessive permissions increase the impact of an application vulnerability.

NNS manages permissions within the website scope. Customers only need to grant write access to directories that genuinely require it.

File Locking Is Part of Windows Website Operation

A running application may hold DLLs, logs, data files, or cache files open.

When a file is in use, FTP or the browser file manager may not be able to replace, move, or delete it immediately.

For application updates:

1. Pause the website or recycle the application pool.
2. Upload and replace the application files.
3. Verify configuration and directory permissions.
4. Restore the website and test access.

This reduces incomplete updates caused by locked files.

Databases Are Created Only When Needed

A database is not forced into existence when a hosting service is activated.

Websites that require a database can create one within the product quota, create a database user, and enter the host, database name, username, and password in the application configuration.

Static websites do not consume database resources unnecessarily.

Available database types, quantities, and storage depend on the selected product and node.

Domain Bindings Work with the Website Configuration

Customers can bind primary domains, subdomains, and alias domains.

Domain bindings define which hostnames the website accepts. DNS records determine whether external requests reach the selected node. Both must be correct before the website can open through the domain.

When multiple domains are bound, application URLs, redirects, and web.config rules should also be checked to prevent users from being redirected to an old domain.

FTP and Browser File Management Serve Different Workflows

The browser file manager is suitable for checking directories, editing small files, uploading patches, and handling archives.

FTP is better for uploading a complete website, transferring large groups of files, maintaining project files, and synchronizing content from local development tools.

Both methods remain inside the directory scope of the current hosting service and do not expose another customer's website files.

Windows Web Hosting Is Not a Remote Desktop Server

NNS Windows Web Hosting is designed for website applications. It does not provide server administrator access or a remote desktop environment.

It is not intended for Windows desktop software, applications requiring administrator privileges, custom system services, long-running desktop processes, or applications requiring complete server control.

Projects with these requirements should use a dedicated server product instead of standard Windows web hosting.

A Sustainable Environment for Existing Applications

NNS Windows Web Hosting does not force customers to abandon existing applications. It gives different generations of Windows websites a clear, isolated, and manageable environment in which to continue operating.

From wwwroot, application pools, directory permissions, and web.config to domains, databases, and file management, every capability follows the real Windows website lifecycle.

When additional capabilities are needed, NNS SSL Automation, node migration, offsite recovery, and NNS AI Security Shield can be activated according to the product entitlement without rebuilding the website management environment.