Internet Information Services, commonly known as IIS, is Microsoft’s web-server platform for hosting websites, APIs, web services, and Windows-based applications.

Installing IIS on a Windows VPS takes only a few minutes. However, a production-ready deployment also requires careful configuration of application pools, permissions, firewall rules, HTTPS, request filtering, logging, and server updates.

This guide explains how to install and configure IIS on a Windows VPS while following practical security and deployment best practices.

What You Need

Before starting, make sure you have:

A Windows VPS with administrator access
A supported Windows Server installation
Remote Desktop access
A static IP address
A domain name for a public website
Administrator PowerShell access
Your website or application files
A valid TLS certificate for production use

Developers who need a Windows server can review AvenaCloud Windows VPS hosting. Its Windows VPS page advertises administrator access, SSD storage, DDoS protection, and scalable server configurations.

Step 1: Connect to the Windows VPS

Connect to your server through Remote Desktop:

Open Remote Desktop Connection on your computer.
Enter the public IP address of the VPS.
Select Connect.
Enter your administrator credentials.
Confirm that you are connecting to the correct server.

After logging in, change any temporary password supplied by the hosting provider.

For better security, restrict Remote Desktop access to trusted IP addresses through the provider’s network firewall. Do not leave administrative services unnecessarily open to the entire internet.

Step 2: Update Windows Server

Install available Windows updates before adding IIS or deploying your application.

Open:

Settings → Windows Update → Check for updates

Install all relevant security and system updates, restart the server, and check for updates again.

Beginning with an updated operating system reduces the chance of deploying an application on top of known, already-corrected vulnerabilities.

Step 3: Decide Which IIS Components You Need

IIS has a modular architecture. This means you can install only the server features required by your application rather than enabling every available component. Microsoft’s IIS guidance notes that IIS features are optional components that can be added or removed according to the needs of the hosted sites.

For a basic static website, you normally need:

IIS Web Server
Static Content
Default Document
HTTP Errors
HTTP Logging
Request Filtering
Static Content Compression
IIS Management Console

Other applications may also require:

ASP.NET features
WebSocket Protocol
Windows Authentication
URL Rewrite
CGI
Application Initialization
Web Management Service

Best practice: Do not install every IIS role service automatically. Unused modules increase the number of components that must be updated, monitored, and secured.

Step 4: Install IIS with Server Manager

You can install IIS through the Windows graphical interface.

Open Server Manager.
Select Manage.
Select Add Roles and Features.
Choose Role-based or feature-based installation.
Select the local VPS.
Enable Web Server (IIS).
Select Add Features when prompted.
Review the available IIS role services.
Enable only the components required by your application.
Select Install.

The Server Manager workflow installs the Web Server role and lets you choose individual role services. Microsoft also supports installing roles and features through PowerShell.

Step 5: Install IIS with PowerShell

For repeatable deployments, PowerShell is usually faster and easier to document.

Open Windows PowerShell as an administrator and run:

Install-WindowsFeature Web-Server -IncludeManagementTools

The Web-Server feature installs IIS, while -IncludeManagementTools adds the management tools used to configure it. Microsoft notes that management tools are not automatically included when roles are installed through Install-WindowsFeature unless this parameter is used.

Check the installation result:

Get-WindowsFeature Web-Server

You can inspect all available IIS components with:

Get-WindowsFeature Web-*

Install additional components only when your application requires them.

For example, static-content compression can be installed with:

Install-WindowsFeature Web-Stat-Compression

Step 6: Verify the IIS Installation

Open a browser inside the VPS and visit:

http://localhost

You should see the default IIS welcome page.

You can also test IIS through PowerShell:

$response = Invoke-WebRequest -Uri "http://localhost"
$response.StatusCode

A successful response should normally return:

To test the website from another computer, enter the VPS public IP address into a browser:

http://YOUR_VPS_IP

If the local test works but the public test fails, check:

The hosting provider’s network firewall
Windows Defender Firewall
The IIS site bindings
Whether TCP port 80 is open
Whether the VPS has a public IP address

Step 7: Create a Dedicated Website Directory

Avoid placing every application directly inside the default IIS directory.

Create a separate directory for your website:

New-Item `
  -ItemType Directory `
  -Path "C:\Sites\DeveloperApp" `
  -Force

Create a basic test page:

@"
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Developer App</title>
</head>
<body>
    <h1>IIS is working</h1>
    <p>The website was deployed successfully on a Windows VPS.</p>
</body>
</html>
"@ | Set-Content "C:\Sites\DeveloperApp\index.html"

Recommended directory structure:

C:\Sites\
└── DeveloperApp\
    ├── index.html
    ├── assets\
    ├── logs\
    └── configuration\

Do not store database backups, private keys, source-control credentials, deployment secrets, or other sensitive files inside a publicly accessible website directory.

Step 8: Create a Dedicated Application Pool

An application pool separates one IIS application from another. Microsoft explains that process boundaries between application pools help prevent an application problem in one pool from directly affecting sites running in other pools.

Import the IIS PowerShell module:

Import-Module WebAdministration

Create a dedicated application pool:

New-WebAppPool -Name "DeveloperAppPool"

For a static website or an application that does not use the classic .NET Framework runtime, configure the pool with no managed runtime:

Set-ItemProperty `
  -Path "IIS:\AppPools\DeveloperAppPool" `
  -Name managedRuntimeVersion `
  -Value ""

Start the pool:

Start-WebAppPool -Name "DeveloperAppPool"

Application-pool best practices

Use a separate application pool for each unrelated production application.
Do not run an application pool as an administrator.
Do not configure all websites to use DefaultAppPool.
Set resource limits only after measuring normal application behavior.
Monitor repeated application-pool crashes or recycling.
Use a dedicated service identity only when the application genuinely requires access to external resources.

Step 9: Give IIS the Minimum Required Permissions

Grant the application pool read and execute access to the website directory:

$path = "C:\Sites\DeveloperApp"
$identity = "IIS AppPool\DeveloperAppPool"

$acl = Get-Acl $path

$rule = New-Object `
  System.Security.AccessControl.FileSystemAccessRule(
    $identity,
    "ReadAndExecute, Synchronize",
    "ContainerInherit,ObjectInherit",
    "None",
    "Allow"
  )

$acl.AddAccessRule($rule)
Set-Acl -Path $path -AclObject $acl

Only grant write permission to directories that need it, such as a dedicated upload, cache, or application-log directory.

Do not grant broad Full Control permissions to:

Everyone
Users
IIS_IUSRS
Anonymous users
The entire website directory

Following least privilege helps limit the damage that could occur if the application is compromised.

Step 10: Create the IIS Website

Create the site with PowerShell:

New-Website `
  -Name "DeveloperApp" `
  -PhysicalPath "C:\Sites\DeveloperApp" `
  -ApplicationPool "DeveloperAppPool" `
  -Port 80 `
  -HostHeader "app.example.com"

Replace app.example.com with your real domain or subdomain.

Start the site:

Start-Website -Name "DeveloperApp"

Confirm its status:

Get-Website -Name "DeveloperApp"

Test the site locally by temporarily adding a host-header entry or by configuring the domain’s DNS record.

Step 11: Configure the Domain

Create an A record through your DNS provider:

Type: A
Name: app
Value: YOUR_VPS_PUBLIC_IP
TTL: Automatic

For example:

app.example.com → 203.0.113.20

Allow time for DNS changes to propagate, and then test:

http://app.example.com

Make sure the domain in DNS exactly matches the IIS host-name binding.

IIS bindings determine the protocol, IP address, port, and host name through which a website receives requests. Separate HTTP and HTTPS bindings are required when a site supports both protocols.

Step 12: Configure the Firewall

A public web server usually needs inbound access on:

TCP port 80 for HTTP
TCP port 443 for HTTPS

Open only the ports required by the server.

Example PowerShell rules:

New-NetFirewallRule `
  -DisplayName "Allow IIS HTTP" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 80 `
  -Action Allow

New-NetFirewallRule `
  -DisplayName "Allow IIS HTTPS" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 443 `
  -Action Allow

Check whether equivalent rules already exist before creating duplicates:

Get-NetFirewallRule |
  Where-Object DisplayName -Match "HTTP|HTTPS|IIS"

Also configure the VPS provider’s external firewall or security rules. A Windows Firewall rule cannot allow traffic that is already blocked at the hosting-provider level.

Database ports, Remote Desktop, IIS management ports, and internal application ports should not normally be publicly accessible.

Step 13: Add HTTPS

A production website should use a certificate issued for its domain.

In IIS Manager:

Select the server.
Open Server Certificates.
Import or request the certificate.
Select Sites.
Select your website.
Select Bindings.
Add an https binding.
Select port 443.
Enter the website host name.
Select the correct certificate.
Enable Server Name Indication when hosting multiple HTTPS sites on one IP address.

Microsoft’s IIS guidance describes creating an HTTPS binding and associating a server-authentication certificate with the site.

After confirming HTTPS works, redirect HTTP requests to HTTPS.

Also establish a certificate-renewal process. An expired certificate can make a correctly running application appear unavailable or unsafe to users.

Step 14: Remove or Disable the Default Website

The default IIS website is useful for testing, but it should not remain publicly accessible when it is no longer needed.

Stop it with:

Stop-Website -Name "Default Web Site"

Remove it only after confirming that no application depends on it:

Remove-Website -Name "Default Web Site"

Removing unused sites reduces confusion and helps prevent content from being served through unintended bindings.

Step 15: Disable Directory Browsing

Directory browsing can expose filenames and folder structures when a default document is missing.

Disable it for the website:

Set-WebConfigurationProperty `
  -Filter "/system.webServer/directoryBrowse" `
  -Name "enabled" `
  -Value "False" `
  -PSPath "IIS:\" `
  -Location "DeveloperApp"

Microsoft’s IIS hardening guidance recommends removing unused features and disabling directory browsing as part of reducing server exposure.

Step 16: Configure Request Filtering

IIS Request Filtering can reject unwanted requests before they reach the application. It can restrict file extensions, HTTP verbs, URL sequences, hidden segments, request sizes, headers, and query strings.

Examples of possible restrictions include:

Blocking unnecessary HTTP methods
Rejecting oversized uploads
Preventing access to sensitive directory names
Blocking dangerous file extensions
Limiting URL and query-string lengths
Preventing double-encoded requests

Do not copy restrictive rules into production without testing them. An overly aggressive rule can block legitimate application traffic, APIs, file uploads, or authentication requests.

Step 17: Protect Sensitive Files

Confirm that users cannot download:

Configuration backups
Environment files
Source-code archives
Database exports
Private certificates
Deployment scripts containing credentials
Application logs containing sensitive information

Do not create backup files such as these inside the web root:

web.config.backup
database.sql
website.zip
.env
certificate.pfx
production-secrets.txt

Store private files outside the public content directory and restrict access through Windows permissions.

Step 18: Configure Logging

IIS logging is essential for troubleshooting and security investigations.

Record at least:

Request date and time
Client IP address
HTTP method
Requested URI
Response status
Substatus
Time taken
User agent
Referrer
Host name

Review logs for:

Repeated 404 responses
500 application errors
Authentication failures
Unusual URL patterns
Large request volumes
Requests for sensitive filenames
Unexpected administrative paths

By default, IIS logs are commonly stored under:

C:\inetpub\logs\LogFiles

Configure log rotation or retention so that log files do not consume all available disk space.

Step 19: Monitor the Server

Monitor both IIS and the underlying Windows VPS.

Important measurements include:

CPU usage
Available memory
Free disk space
Application-pool status
Request rate
Response time
HTTP error rates
Network traffic
Certificate expiration
Windows Event Viewer errors
Application failures
Repeated worker-process recycling

A server may appear online while the hosted application is failing. Use an external uptime check that requests a real application or health-check endpoint.

Step 20: Create a Backup and Recovery Plan

Back up:

Website files
IIS configuration
Application configuration
Databases
TLS certificates and private keys
DNS information
Deployment scripts
Required environment settings

Keep at least one backup outside the VPS.

A server snapshot can be useful, but it should not replace application-aware database backups and separately stored configuration backups.

Test the restoration process periodically. A backup should not be considered reliable until it has been restored successfully.

IIS Production Checklist

Before launching the website, verify that:

Windows Server is updated.
Only required IIS components are installed.
The application has a dedicated application pool.
The application pool does not run as an administrator.
File permissions follow least privilege.
The default website is disabled or removed.
Directory browsing is disabled.
HTTP and HTTPS bindings are correct.
A valid TLS certificate is installed.
HTTP traffic redirects to HTTPS.
Only required firewall ports are open.
Request filtering has been reviewed.
Sensitive files are outside the web root.
IIS and application logging are enabled.
Disk-space monitoring is active.
Backups are stored outside the VPS.
The application has been tested from an external network.

Common IIS Problems

The IIS welcome page appears instead of the application

Check:

The website’s host-name binding
DNS records
Whether the Default Web Site is intercepting the request
The site’s physical path
The requested domain name

HTTP 403 error

Review:

File and directory permissions
Default-document configuration
Authentication settings
Request Filtering rules
Whether directory browsing is disabled and no default file exists

HTTP 500 error

Check:

Windows Event Viewer
IIS logs
Application logs
Runtime installation
web.config
Application-pool configuration
File permissions
Database connectivity

HTTP 503 Service Unavailable

A 503 response often indicates that the application pool is stopped, unavailable, or repeatedly failing.

Check:

Get-WebAppPoolState -Name "DeveloperAppPool"

Start it if necessary:

Start-WebAppPool -Name "DeveloperAppPool"

Then inspect Event Viewer to determine why it stopped.

The site works locally but not publicly

Check:

Provider firewall rules
Windows Firewall rules
Public IP configuration
IIS bindings
DNS records
Ports 80 and 443
Whether the application is listening on the expected interface

HTTPS shows the wrong certificate

Check:

The HTTPS site binding
Host name
Selected certificate
Server Name Indication
Certificate expiration
Whether another site uses the same IP and port combination

Related Resources

Conclusion

Installing IIS on a Windows VPS is straightforward, but a secure production deployment requires more than enabling the Web Server role.

Use a dedicated application pool, install only required modules, apply least-privilege permissions, configure HTTPS, restrict firewall access, disable unused features, protect sensitive files, monitor the server, and maintain tested backups.

These practices create a cleaner, safer, and more manageable IIS environment for hosting websites, APIs, and Windows-based applications.