When upgrading to Veeam Backup & Replication (VBR) v13 , many users encounter a critical installation block:
"Required port 443 for Veeam Backup & Replication is occupied by another application" In version 13, port 443 is
for the Veeam Web Service/API Gateway. This requirement is strictly enforced by the installer's compatibility check, and there is currently no supported way to change this port within Veeam or bypass the check. Identifying the Conflict
To resolve the block, you must identify which non-Veeam service is listening on port 443. Diagnostic Command netstat -anob
in an elevated Command Prompt to see which Process ID (PID) and executable are using the port. Common Culprits Hyper-V Replication
: If your VBR server also acts as a Hyper-V Replica server, it may be using 443 for replication traffic. IIS / Web Servers : Existing web hosting services or management consoles. Security Agents : Third-party monitoring or security software. How to Resolve the Block
Since Veeam's port 443 requirement is mandatory for v13, the solution involves reconfiguring the application: Reconfigure Hyper-V Replication Navigate to Hyper-V Settings Replication Configuration Change the listening port from to an alternative (e.g., 444).
Update the Replica settings for each individual VM to match this new port to avoid re-replication. Adjust Third-Party Applications
If a third-party service allows it, reconfigure it to use a different HTTPS port (e.g., 8443 or 9443). Temporary Disabling
Some admins report success by temporarily stopping the conflicting service to complete the Veeam upgrade. However, the Veeam Web Service may fail to start afterward if the original application resumes control of port 443. Dedicated Infrastructure
Veeam experts recommend moving the backup server to a dedicated, non-domain-joined environment to avoid conflicts and improve security.
Major Issues After Upgrading to Veeam V13: Port 443 Conflict
Title: The Sentinel of Port 443
Log Entry: Day 1, 08:00 GMT Administrator: Lena Koh, Senior Cloud Architect Location: Global Data Center, Floor 14
Lena Koh stared at the crimson error message on her RDP session. It was the kind of message that made her left eye twitch—a simple, declarative sentence that carried the weight of a cancelled weekend.
Error: Required port 443 (HTTPS) for Veeam Backup & Replication is occupied by another application. Please free the port and restart the Veeam Backup Service.
She had been planning this migration for six months. The old tape libraries were being retired. The new all-flash object storage array, affectionately nicknamed "The Vault," was racked and stacked. Veeam Backup & Replication v12.1 was the orchestrator, the brain that would move 4.2 petabytes of financial transaction data from the production cluster to immutable cloud storage. And its control heart—the web UI, the REST API, the service endpoint—needed port 443.
But something else had claimed the castle.
Lena opened netstat -ano | findstr :443 with the muscle memory of a concert pianist.
The output was chilling:
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4428
TCP [::]:443 [::]:0 LISTENING 4428
Process ID 4428. She pulled up Task Manager. Right-clicked the PID column. Sorted.
Process Name: AcmeCorp.Unified.Agent.Core.exe
Description: Endpoint Detection & Response (EDR) / Web Filtering Proxy
Memory Usage: 2.1 GB
Status: Running. Immovable. Blessed by the InfoSec team.
Lena groaned. AcmeCorp Unified Agent. The Swiss Army knife of cybersecurity that had been forced onto every server in the fleet three months ago. It intercepted all HTTPS traffic for deep packet inspection, certificate re-signing, and behavioral analysis. And it had planted its flag firmly on port 443.
She opened Teams. Direct message to Raj Patel, Lead InfoSec Engineer.
Lena: Raj. The AcmeCorp agent on VEEAM-SRV-02 is squatting on port 443. Veeam needs that port. Can we rebind the agent to 8443 or something?
Raj’s reply came in 14 seconds. That was never a good sign.
Raj: Negative. Corporate policy M-2024-09. All Windows servers with financial data classification must have AcmeCorp agent bound to default HTTPS port for SSL inspection. No exceptions. Change request would take 3 weeks.
Three weeks. The backup window for the monthly archive was in six days. If she missed this window, the storage array would lock for maintenance, and the auditors would flag the gap.
Lena took a breath. She had three options. And the first two were terrible.
Option 1: The Registry War
She could try to force AcmeCorp to listen on a different IP address (127.0.0.2 vs 0.0.0.0). She navigated to HKLM\SYSTEM\CurrentControlSet\Services\AcmeCorp\Parameters. There it was: ListenAddress = 0.0.0.0. She changed it to 10.24.112.45—the server’s secondary admin IP. A restart of the service later, netstat showed the agent now bound only to the secondary IP. Port 443 on the primary IP was free.
She held her breath. Started Veeam Backup Service.
Error. Same message.
She realized the truth with a sinking feeling: Veeam, by default, binds to all interfaces. It saw the AcmeCorp agent still technically occupying the port on the secondary IP. Windows Sockets don’t care about your IP segmentation logic—if any process listens on 443 on any IP, no other process can bind to 0.0.0.0. A cold war over a single integer.
She reverted the change.
Option 2: The Reverse Proxy Mirage
She considered running Veeam on port 8443 internally, then setting up an IIS ARR (Application Request Routing) reverse proxy on port 443 that forwarded traffic. Elegant in theory. In practice, Veeam’s API hard-codes redirect URLs in its authentication handshake. The moment the proxy forwarded a request, Veeam would generate a callback URL with :8443, the browser would throw a CORS error, and backup jobs would fail with cryptic "token mismatch" errors.
She had tried this once, three years ago. She still had nightmares about the log files.
Option 3: The Nuclear Option (The One She Chose)
She called a war room. Attendees: Lena (Backup & Storage), Raj (InfoSec), and Priya (Network Engineering, who owed her a favor).
Lena laid out the problem. Raj reiterated policy. Priya listened, sipping cold brew.
Then Priya spoke. "What if AcmeCorp doesn't need to inspect traffic between Veeam and its own repository?"
Raj frowned. "Explain."
Priya drew on the whiteboard. VEEAM-SRV-02 <---> THE VAULT (Storage Array). The traffic was internal. VLAN 104. No internet egress. The financial data was encrypted twice—once by Veeam, once by the array. The AcmeCorp agent was decrypting, inspecting, and re-encrypting backups of encrypted backups. It was theater. And worse, it was slow theater.
"The policy says 'all Windows servers with financial data,'" Priya said. "It doesn't say 'all interfaces on those servers.' Add a second virtual NIC. Dedicate it to VLAN 104. Tell AcmeCorp to ignore that interface. Tell Veeam to bind only to that interface for its service."
Silence.
Raj’s policy brain clicked. "A network-level segmentation exception. That… could work. The agent would still monitor the management NIC. The backup NIC is just a data plane."
Lena’s fingers flew. Two hours later:
- New vNIC:
eth2, IP172.18.0.10/24, VLAN 104. - AcmeCorp config:
ExcludedAdapters = "eth2"(A hidden setting Raj had to Google for 45 minutes). - Veeam config:
HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\ServiceBindAddress=172.18.0.10.
She restarted both services. She ran netstat -ano | findstr :443.
Two lines.
TCP 172.18.0.10:443 0.0.0.0:0 LISTENING 7892 (Veeam)
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4428 (AcmeCorp)
Peaceful coexistence. Two different universes sharing the same integer, separated only by a virtual wire.
Log Entry: Day 1, 16:32 GMT
Lena opened the Veeam Backup & Replication console. The green "Ready" status glowed on the dashboard. She created a test job: "Finance_Archive_Test." She pointed it at The Vault. She hit Start.
The progress bar ticked. 1%... 5%... 23%... 47%...
No errors. No port conflicts. Throughput: 1.2 GB/s.
She leaned back. Her phone buzzed. A calendar invite from Raj: "Meeting: Formalize NIC segregation policy – Next Tuesday."
She smiled. Tomorrow's problem. For now, port 443 was no longer a battlefield. It was just a number—two numbers, actually, living in parallel harmony, carrying the future of 4.2 petabytes to safety.
She typed a final note into the change management ticket:
Resolution: Port 443 conflict resolved via multi-homing. Veeam bound to secondary interface. AcmeCorp agent bound to primary. Backup service operational. Recommendation: Update server provisioning standards to include dedicated backup VLAN NICs.
She closed the ticket. The server hummed. And somewhere deep in the logs, a single line of Veeam success code wrote itself to history:
[Info] HTTPS listener started on 172.18.0.10:443. Ready to serve.
Dealing with Port 443 Conflicts in Veeam Backup & Replication
If you’re trying to install or start Veeam Backup & Replication and you’re hit with an error stating that Port 443 is occupied by another application, you’ve run into one of the most common configuration hurdles in the backup world.
Veeam uses Port 443 (HTTPS) for various critical tasks, including communication with the backup server, cloud gateways, and managing VMware vSphere environments. When another service grabs this port first, Veeam can’t bind to it, bringing your backup infrastructure to a halt. Here is how to identify the culprit and fix the conflict. 1. Identify Which Application is Using Port 443
Before you can fix the problem, you need to find the "squatter." Since Port 443 is the standard port for secure web traffic, the most common culprits are IIS (Internet Information Services), Apache, Skype, or VMware Workstation. The Quick Fix via Command Prompt: Open Command Prompt as an Administrator. Run the following command:netstat -ano | findstr :443
Look for the line that says LISTENING. The number at the far right is the PID (Process ID). The Visual Way (Task Manager): Open Task Manager and go to the Details tab.
Sort by the PID column and find the number you identified in the previous step. This will tell you exactly which .exe is hogging the port. 2. Common Culprits and How to Move Them
Once you’ve found the app, you have two choices: stop it or move it. A. VMware Workstation / Server VMware often uses Port 443 for its "Shared VMs" feature.
The Fix: Go to Edit > Preferences > Shared VMs. Click Change Settings, then either disable sharing or change the port to something else (like 4443). B. IIS (Internet Information Services)
If your Veeam server is also acting as a web server, IIS likely has a "Default Web Site" bound to 443.
The Fix: Open the IIS Manager, go to Bindings for your sites, and either remove the HTTPS binding or assign it to a different IP address or port. C. Windows Global HTTP Settings
Sometimes, the port is reserved by the system’s HTTP driver (http.sys).
The Fix: Use the command netsh http show servicestate to see which registered endpoints are active. 3. Can You Change the Port in Veeam?
While you can technically change the ports Veeam uses, Port 443 is a hard requirement for many of its core components (like the Veeam Backup & Replication console and the REST API).
Changing Veeam’s default ports often leads to a "domino effect" of connectivity issues across your proxies and repositories. The best practice is always to move the competing application away from Port 443, rather than moving Veeam. 4. Re-running the Veeam Setup If the conflict happened during installation: Stop the conflicting service. Click Retry in the Veeam installer.
Once Veeam is installed and its services are running, you can decide if you want to restart the other application on a different port. Summary Checklist Run netstat -ano to find the PID. Identify the app in Task Manager. Reconfigure or disable the competing service. Restart Veeam services (via services.msc).
Are you seeing this error during a fresh installation or did it suddenly appear on an existing server?
Veeam Backup & Replication (VBR) v13 is a mandatory, hardcoded requirement for the new Veeam Web Service/API Gateway
. If another application is already using this port, the VBR services will fail to bind to it, preventing the backup software from starting or functioning correctly. Veeam Community Resource Hub Why Port 443 is Required API & Web Interface
: VBR v13 introduces a REST-based web service that handles core management tasks and the modern Web UI. Identity Service
: It is used by Veeam Agents to obtain authentication tokens from the Veeam Backup Identity Service Hardcoded Configuration
: In current builds of v13 (specifically v13.0.1.180 and newer), there is no supported method to change this port within the Veeam configuration. Veeam Community Resource Hub Resolving Port Conflicts
If port 443 is occupied, you must identify and reconfigure the competing application, as Veeam's use of 443 is currently non-negotiable for v13. 1. Identify the Conflicting Application
Use the command line to find which process is holding the port: Open Command Prompt as Administrator. netstat -ano | findstr :443 (Process ID) at the end of the line.
Check Task Manager (Details tab) to see which application corresponds to that PID. 2. Common Conflicting Services Hyper-V Replication
: If the VBR server also acts as a Hyper-V Replica server, it often uses port 443. : Change the Hyper-V Replication port in Hyper-V Settings > Replication Configuration to a different port (e.g., 444). IIS (Internet Information Services)
: Web servers or management portals (like ADFS) often bind to 443. VMware Workstation : Sometimes uses 443 for shared virtual machine management. 3. Known Issues & Workarounds Temporary Bypass
: Some users have reported that stopping the conflicting service just long enough to complete the Veeam upgrade works, but VBR services will likely crash once the other app is restarted. Veeam Service Provider Console
: If you are using the Console (formerly Availability Console) rather than VBR itself, the port be changed via IIS Manager > Edit Bindings Infrastructure Segregation
: For production stability, Veeam recommends installing VBR on a dedicated server to avoid resource and port conflicts with other critical business applications. reconfiguring a known service like IIS or Hyper-V to free up port 443?
Major Issues After Upgrading to Veeam V13: Port 443 Conflict
Veeam Backup & Replication relies heavily on specific network ports to facilitate communication between its various components, including the backup server, backup proxies, repositories, and managed servers. One of the most critical ports used by Veeam is Port 443 (HTTPS), which is essential for secure communication, web services, and integration with cloud providers or VMware vSphere environments.
When you attempt to install, upgrade, or start Veeam Backup & Replication services and encounter an error stating that Port 443 is occupied by another application, it can halt your backup operations. This article provides a comprehensive guide to understanding, diagnosing, and resolving this common conflict. 🎯 Direct Answer
To resolve the "Port 443 occupied" error in Veeam Backup & Replication, you must identify the conflicting application using the netstat command or Resource Monitor, and then either stop that application, change its port configuration, or reconfigure Veeam to use an alternative port. 🔍 Understanding the Role of Port 443 in Veeam
Port 443 is the standard port for secure web traffic (HTTPS). In a Veeam environment, it is used for several critical functions:
vSphere Communication: Veeam connects to VMware vCenter Server and ESXi hosts over port 443 to manage snapshots and VM data.
Cloud Connect: Secure connections to Veeam Cloud Connect service providers.
RESTful API: Accessing the Veeam Backup & Replication RESTful API.
Enterprise Manager: Communication between the backup server and Veeam Backup Enterprise Manager.
AWS/Azure Integrations: Secure API calls to public cloud platforms.
If another software package binds to Port 443 on the Veeam server before Veeam can, the Veeam services will fail to start or operate correctly. 🛠️ Step 1: Identify the Conflicting Application
Before you can fix the issue, you need to find out which application has hijacked Port 443. Here are the two most effective methods to do this on a Windows Server. Method A: Using Command Prompt (Netstat)
The fastest way to find the PID (Process Identifier) using port 443 is through the command line. Open Command Prompt as an Administrator. Run the following command:netstat -ano | findstr :443 Look for a line showing LISTENING in the state column. Note the PID listed at the far right of that line.
To find out what that PID is, run:tasklist | findstr [PID_Number] Method B: Using Resource Monitor If you prefer a graphical interface: Press Win + R, type resmon, and hit Enter. Navigate to the Network tab. Expand the Listening Ports section. Click on the Port column to sort numerically.
Locate port 443 and look at the Image column to see the executable name. ⚠️ Common Culprits Occupying Port 443
Several applications frequently conflict with Veeam over Port 443. Common examples include:
Internet Information Services (IIS): Often installed on Windows Servers, hosting default websites on HTTPS.
VMware vCenter/Workstation: If installed on the same machine, VMware services default to port 443.
Skype / Teams: Older desktop versions famously utilized port 443 as a fallback for incoming connections.
Antivirus/Security Software: Local management consoles or update agents.
Web Server Stacks: Apache, Nginx, or XAMPP installed on the backup server. 🚀 Step 2: Resolving the Conflict
Once you have identified the application holding the port, choose one of the following remediation paths. Option 1: Stop or Uninstall the Conflicting Application
If the application occupying the port is not needed on your Veeam Backup server, the cleanest solution is to remove it.
Open services.msc and stop the offending service (e.g., World Wide Web Publishing Service for IIS).
Set the service startup type to Disabled to prevent it from grabbing the port after a reboot. Option 2: Change the Port of the Conflicting Application
If you must run both applications on the same server, change the port used by the non-Veeam application.
For IIS: Open IIS Manager, select the site, click Bindings in the right pane, edit the HTTPS binding, and change port 443 to an unused port (e.g., 8443).
For Apache: Edit the httpd.conf or ssl.conf file and change Listen 443 to another port. Option 3: Change the Port in Veeam
If you cannot change the port of the other application, you can reconfigure Veeam to use a different port for its web UI or API components during installation or via the registry/configuration files.
Note: Changing default ports in Veeam should be done with caution and documented, as you will need to specify the custom port when connecting external components or accessing web consoles. 💡 Best Practices for Veeam Port Management
To avoid running into these issues in the future, follow these industry best practices:
Dedicated Backup Server: Never install Veeam Backup & Replication on a machine running IIS, Active Directory, or vCenter. Keep the backup server dedicated.
Pre-Install Port Audits: Run netstat before installing Veeam to ensure ports 443, 6160, 9392, and 11560 are completely free.
Firewall Segmentation: Ensure internal Windows firewalls are configured to allow Veeam traffic explicitly rather than opening ports globally.
To resolve the error where port 443 is occupied, you must identify the conflicting application and either stop it or reconfigure it to use a different port. Starting with Veeam Backup & Replication (VBR) v13, port 443 is a hardcoded requirement for the REST/Web UI service, and there is no supported way to change it within Veeam itself. 1. Identify the Conflicting Application
Use the command line to find out which process is currently holding the port: Open Command Prompt as an Administrator.
Run Netstat: Type netstat -aon | findstr :443 and press Enter.
Note the PID: Look at the last column of the output for the Process ID (PID). Find the Name: Open Task Manager (Ctrl+Shift+Esc).
Go to the Details tab and sort by the PID column to find the matching application.
Common culprits include IIS, SQL Reporting Services, or Hyper-V Replication. 2. Common Fixes for Specific Services
Phase 2: Determine if Port 443 Can Be Moved
Before killing or uninstalling anything, ask: Can the other application be reconfigured to use a different port?
- IIS Default Website: Change its HTTPS binding (see detailed steps below).
- SSRS: Change the
UrlRootconfiguration from 443 to, say, 4443. - Exchange: This is harder—do not co-install Veeam on Exchange.
- WinRM: Reconfigure HTTPS listener using
winrm set winrm/config/Listener?Address=*+Transport=HTTPS @Port="5986".
Scoring rubric
- MCQs: 20% (1 point each)
- Short-answer: 20% (4 questions, 5 points each)
- Practical diagnostics: 30% (lab tasks, accuracy and commands used)
- Troubleshooting scenarios: 20% (two scenarios, 10 points each)
- Essay: 10% (clarity, coverage of prevention measures)
Why Does Veeam Need Port 443?
To understand the error, one must first appreciate that Veeam Backup & Replication is not just a file-copy tool—it is a distributed, web-centric platform. Port 443 is the default port for:
- Veeam Backup Service – Handles communication between the Veeam console and the backup server.
- Veeam REST API Service – Enables programmatic management, integration with enterprise orchestration, and modern monitoring.
- Veeam Backup Enterprise Manager – The web-based UI for centralized management (if installed on the same server).
- Veeam Cloud Connect – Allows service providers to offer backup repositories over the internet securely.
When you install Veeam Backup & Replication (version 10, 11, 12, or later), the installer attempts to bind the Veeam Backup Service to port TCP 443 on the local machine. If any other process has already claimed that port—even if it's just listening and not actively serving traffic—Veeam will refuse to start or install.
Step 3 – Check HTTP.sys kernel-mode listeners (if IIS or HTTP API)
netsh http show servicestate
Look for http.sys URL reservations on https://*:443/ or https://+:443/.
Practical diagnostic tasks (lab exercises)
Task A — Identify the process occupying port 443 (10 points)
- Use netstat -ano | findstr :443 to list listeners.
- Use Get-Process -Id or tasklist /FI "PID eq " to identify process.
- Verify with TCPView or Resource Monitor. Grading: correct commands, identification, screenshots/log excerpts.
Task B — Check HTTP.sys and SSL bindings (10 points)
- Run: netsh http show sslcert
- Run: netsh http show urlacl
- Identify any entries for 0.0.0.0:443 or specific IPs and note the owning cert thumbprint and appid. Grading: correct output interpretation, explanation of which entry blocks Veeam.
Task C — Inspect Windows Certificate Store and private key permissions (10 points)
- Open certlm.msc or use PowerShell: Get-ChildItem Cert:\LocalMachine\My | select Thumbprint, Subject
- Verify private key exists and account (Network Service or Veeam service account) has access using Get-Acl on key container or use certutil -repairstore. Grading: correct identification and commands, note missing private key or permission issues.