Required Port 443 For Veeam Backup Replication Is Occupied By Another Application Link -
The blinking cursor on the dashboard monitor felt like a heartbeat, and not a calm one. It was 2:00 AM on a Sunday, the window for the off-site backup chain to close in exactly fifty-five minutes.
Elias, the senior systems engineer, gripped his coffee mug like a lifeline. The Veeam Backup & Replication console was displaying a sea of red. The job—dubbed "Critical-VMs-Offsite"—had failed. Again.
He clicked the "Details" link, his eyes scanning the error log until they locked onto the fatal sentence:
"Error: Required port 443 for Veeam Backup & Replication is occupied by another application."
Elias sighed, the sound heavy in the empty server room. Port 443. The golden gate of network traffic. The standard port for HTTPS, essential for the Veeam Backup Catalog to communicate with the repository server over WAN accelerators. Without it, the backup chain was dead in the water.
"Who stole the port?" he whispered to the hum of the cooling fans.
He opened a PowerShell terminal with administrator privileges. His fingers flew across the keyboard, invoking the network investigation.
netstat -ano | findstr :443
The screen flickered and returned a list. He ignored the established connections from the web servers; he was looking for the state LISTENING. There it was.
TCP 0.0.0.0:443:0 LISTENING 4988
Process ID 4988. The culprit.
Elias frowned. On the repository server (Repo-01), the only things running should have been the Veeam Data Mover service and basic OS functions. He ran the tasklist command to identify the owner of PID 4988.
tasklist /svc /fi "PID eq 4988"
The result made his blood run cold: vmware-hostd.exe.
"VMware?" Elias muttered, pushing back from his desk. "That doesn't make sense. This is a bare-metal repository, not an ESXi host."
He stood up and walked down the cold aisle of the data center, the blue lights of the server racks casting long shadows. He stopped in front of the rack containing Repo-01. It was a sturdy Dell PowerEdge, purchased specifically for heavy storage throughput.
He connected a crash cart—a keyboard and monitor directly into the server.
"Okay," Elias said, logging in. "What are you hiding?"
He opened the services.msc snap-in. Sure enough, the VMware Workstation Server service was running. But who installed VMware Workstation on a production backup repository?
Then, a memory flashed in his mind. Two days ago. The Junior Admin, Kevin.
"Hey Elias," Kevin had said, looking slightly nervous. "I needed to spin up a quick test lab to simulate that patch for the accounting software. I didn't want to bother the production cluster, so I just threw it on the repo server since it has all that RAM. Is that cool?"
Elias had dismissed him with a wave. "Just make sure it doesn't impact IOPS."
Elias rubbed his temples. Kevin had installed the management interface of VMware Workstation. By default, that interface grabs Port 443 to serve its web console. It was a silent conflict. Veeam had been working fine until the service restarted tonight, tried to bind to 443, and found the door already locked by VMware.
Time was ticking. 2:15 AM.
He had two choices.
- Uninstall VMware Workstation. (Too slow, required a reboot).
- Reconfigure the VMware service to use a different port.
He checked the Veeam logs again. The backup job was retrying in ten minutes. He needed a surgical fix.
He navigated to the VMware Workstation installation directory. He needed to edit the config.ini file located in the application data folder, or better yet, change the service configuration via the GUI if he could load it. He tried to open the VMware console, but it was sluggish.
"Come on," he hissed.
He decided to force the issue via the Registry Editor. It was the nuclear option, but precise.
He navigated to HKLM\SOFTWARE\WOW6432Node\VMware, Inc.\VMware Workstation.
He looked for the httpPort key. There it was, staring back at him: 443.
He changed the value to 8443. Then, he opened the Services console, located the VMware Workstation Server service, and hit Restart.
The status bar moved agonizingly slow. Starting... Starting...
Elias glanced at his watch. 2:22 AM.
Started.
Now for the moment of truth. He needed to stop the Veeam Data Mover service and restart it so it could re-bind to the now-available port.
net stop "VeeamBackupSvc"
net start "VeeamBackupSvc"
The service started cleanly. No errors. No conflicts.
He rushed back to his desk in the other room, the wheels of his chair squeaking loudly. He pulled up the Veeam console. The job was set to "Idle". He right-clicked the failed job.
"Retry".
The window popped up. Initializing... Connecting to host... Preparing metadata...
He held his breath. If the port was still blocked, it would fail instantly. Processing VM "SQL-01"...
The progress bar hit 1%. Then 2%.
Elias exhaled, a long, shaky breath. The port was free. The backup was running.
He made a mental note to have a very serious conversation with Kevin about lab hygiene on Monday morning. But for now, he watched the green progress bar crawl across the screen, the data flowing safely through the reclaimed Port 443, securing the company's future one megabyte at a time.
This error typically occurs during the installation or upgrade to Veeam Backup & Replication v13 (or newer), as port 443 is now hardcoded and required for the Veeam Web Service/API Gateway
. Because this port is fixed, the Veeam services will fail to bind and start if another application is already using it Quick Fixes for Common Conflicts
If you encounter this conflict, identify the application using port 443 and apply the relevant solution: Hyper-V Replication Conflict
: This is a common issue if the VBR server is also a Hyper-V Replica server Hyper-V Settings Replication Configuration Change the port from to something else (e.g., 444)
Update the replica settings for each VM to match this new port Windows Remote Management (WinRM)
: In some environments, WinRM or WS-Management may occupy this port Temporarily stop the Windows Remote Management
service to allow the Veeam console to load or complete its upgrade General Web Services
: Other web servers (like IIS or Apache) or third-party monitoring tools may be using port 443. Identify the process : Open a command prompt as an administrator and run netstat -anob | findstr :443
. This will tell you the PID (Process ID) of the application occupying the port Workaround
: Stop the conflicting service during the Veeam upgrade. While Veeam Support
may suggest stopping it just for the installation, the VBR console may still fail to work later if the conflict returns Important Compatibility Notes Port is Hardcoded : In version 13.0.1.180 and newer, there is no supported method to change this port for the internal Veeam Web service Database Compatibility : Ensure your SQL database is at least SQL Server 2016
or newer, as v13 requires this compatibility level to function Firewall Rules
: Veeam usually creates its own firewall rules, but you must ensure no external network firewalls are blocking 443 communication between the backup server and its components PowerShell commands to identify exactly which process is holding that port?
Major Issues After Upgrading to Veeam V13: Port 443 Conflict 11 Dec 2025 —
Here’s a properly worded version of your message:
"Port 443, required for Veeam Backup & Replication, is occupied by another application."
If you want to keep it closer to your original structure:
"Port 443, which is required for Veeam Backup & Replication, is currently occupied by another application."
Or more concisely (e.g., for an alert or log message):
"Required port 443 for Veeam Backup & Replication is in use by another application."
Let's dive deep into the issue of port 443 being occupied by another application when trying to use it for Veeam Backup replication.
Understanding the Issue
Veeam Backup & Replication uses various ports for communication between components, including the Veeam Backup Server, Proxy Servers, and Repository Servers. One of these ports is TCP 443, which is typically used for HTTPS traffic.
When you try to configure Veeam Backup replication, you may encounter an error message indicating that port 443 is already in use by another application. This can be frustrating, especially if you're not aware of what application is using the port.
Common Causes of Port 443 Occupation
Here are some common causes of port 443 being occupied:
- Other backup or replication software: Another backup or replication software might be using port 443 for its own communication. Examples include other backup solutions like Commvault, NetBackup, or Data Protection Manager.
- Web servers or IIS: If you have a web server or IIS (Internet Information Services) installed on the same machine as your Veeam Backup Server, it may be using port 443 for HTTPS traffic.
- SSL/TLS certificates or services: Services like Certificate Authority (CA) servers or SSL/TLS certificate management tools might use port 443 for certificate-related communication.
- Other applications or services: Any other application or service that uses HTTPS or SSL/TLS might be occupying port 443.
How to Identify the Occupying Application
To identify which application is using port 443, follow these steps:
On Windows:
- Open a Command Prompt as an administrator.
- Run the command:
netstat -anop | findstr 443 - This will list all processes using port 443. Look for the PID (Process ID) of the process using the port.
On Linux:
- Open a Terminal.
- Run the command:
netstat -tlnp | grep 443 - This will list all processes using port 443. Look for the PID (Process ID) of the process using the port.
Once you've identified the occupying application, you can:
- Stop the occupying application: If possible, stop the application or service using port 443.
- Change the occupying application's port: If possible, change the port used by the occupying application to a different port.
- Configure Veeam Backup to use a different port: You can configure Veeam Backup to use a different port for replication. To do this, go to Veeam Backup & Replication > Settings > Network > Ports, and change the Port value for Replication to a different port (e.g., 4433).
Additional Considerations
When changing ports, consider the following:
- Ensure that any firewalls or network access control lists (ACLs) are updated to allow traffic on the new port.
- Verify that all Veeam Backup components (e.g., Backup Server, Proxy Servers, Repository Servers) are configured to use the new port.
- If you're using a load balancer or reverse proxy, you may need to update its configuration to route traffic to the new port.
By following these steps and considerations, you should be able to resolve the issue of port 443 being occupied by another application when trying to use it for Veeam Backup replication. The blinking cursor on the dashboard monitor felt
Resolving Port 443 Conflicts in Veeam Backup & Replication Veeam Backup & Replication is the backbone of many disaster recovery strategies, but its installation or operation can come to a screeching halt when a "Port 443 occupied" error appears. Because Port 443 is the industry standard for HTTPS traffic, it is highly contested by web servers, monitoring tools, and communication platforms.
If you are seeing errors indicating that required port 443 for Veeam Backup & Replication is occupied by another application, this guide will help you identify the culprit and clear the path for your backups. Why Veeam Needs Port 443 Veeam uses Port 443 for several critical functions:
RESTful API Service: Modern Veeam components communicate via HTTPS.
Cloud Connect: Securely transmitting data to service providers.
vSphere Integration: Communicating with VMware vCenter or ESXi hosts.
Veeam Backup Enterprise Manager: Providing the web-based management interface.
When another service grabs this port first, Veeam cannot bind its services, leading to failed installations or "Service Unreachable" errors. Step 1: Identify the "Occupying" Application
Before you can fix the conflict, you need to know what is sitting on the port. Open PowerShell or Command Prompt as an Administrator.
Run the following command to find the Process ID (PID) using Port 443: powershell netstat -ano | findstr :443 Use code with caution.
Look for the line that says LISTENING. The number at the far right is the PID. To see which application owns that PID, run: powershell tasklist /fi "pid eq [YOUR_PID_HERE]" Use code with caution. Common Culprits
IIS (Internet Information Services): Often used for other web applications on the same server.
VMware Workstation/Player: The "VMware Host Agent" often claims 443.
Skype/Teams: Older versions of communication tools sometimes default to 443.
Antivirus/EDR Agents: Some security consoles use 443 for local communication. Step 2: Resolve the Conflict
You have three primary ways to fix this, depending on your environment. Option A: Disable or Move the Conflicting Service
If the application occupying the port isn't vital to that specific server, the easiest fix is to stop it.
For IIS: Change the "Default Web Site" binding from 443 to another port (like 4443) via the IIS Manager.
For VMware Workstation: Go to Edit > Preferences > Shared VMs and change the port or disable sharing. Option B: Change Veeam’s Default Port
If you are performing a fresh installation, Veeam allows you to specify the ports. If the system is already installed, changing the port is more complex and involves the registry or the Veeam Configuration backend.
Warning: Changing Veeam's default ports may require you to update firewall rules and re-authenticate connected components. Option C: Use a Dedicated Backup Server
Best practice dictates that a Veeam Backup Management Server should ideally be a dedicated role. If your server is acting as a Web Server (IIS), a Print Server, and a Backup Server, port conflicts are inevitable. Moving Veeam to its own VM or a dedicated physical box eliminates this issue entirely. Step 3: Verify the Fix
Once you have stopped the conflicting application or reassigned the port, restart the Veeam services: Open services.msc. Locate Veeam Backup Service. Right-click and select Restart.
Check the netstat -ano | findstr :443 command again to ensure the Veeam PID is now the one listening.
The "Port 443 occupied" error is a common networking hurdle, not a flaw in the Veeam software. By identifying the PID using netstat and either relocating that application or dedicating the server to Veeam, you can ensure your data protection environment remains stable and secure.
Required Port 443 for Veeam Backup Replication is Occupied by Another Application: A Comprehensive Guide
Veeam Backup & Replication is a popular data backup and disaster recovery solution used by many organizations to protect their critical data. One of the key requirements for Veeam Backup & Replication to function properly is that it needs to communicate over specific ports, with port 443 being one of them. However, what happens when the required port 443 for Veeam Backup replication is occupied by another application? In this article, we will explore the issues that arise when port 443 is occupied, and provide a step-by-step guide on how to resolve this common problem.
Understanding Port 443 and Veeam Backup & Replication
Port 443 is the default port used for HTTPS (Hypertext Transfer Protocol Secure) communication. Veeam Backup & Replication uses this port to establish a secure connection between the backup server and the vCenter server or ESXi hosts for replication and backup operations. When Veeam Backup & Replication is configured to use port 443, it attempts to establish a secure connection to the target server. However, if another application is using port 443, the Veeam Backup & Replication job will fail.
Causes of Port 443 Occupation
There are several reasons why port 443 may be occupied by another application:
- Multiple HTTPS applications: If there are multiple applications running on the same server that require HTTPS communication, they may be using port 443, causing a conflict with Veeam Backup & Replication.
- Web server configurations: A web server like IIS or Apache may be configured to use port 443 for HTTPS communication, blocking Veeam Backup & Replication from using it.
- Other backup or replication tools: Other backup or replication tools may be using port 443 for their own communication, causing a conflict with Veeam Backup & Replication.
- Incorrect Veeam Backup & Replication configuration: If Veeam Backup & Replication is not configured correctly, it may attempt to use a port that is already occupied by another application.
Symptoms of Port 443 Occupation
When port 443 is occupied by another application, Veeam Backup & Replication may exhibit the following symptoms:
- Failed backup or replication jobs: Veeam Backup & Replication jobs may fail with error messages indicating a connection issue.
- Timeout errors: Backup or replication jobs may timeout, indicating that the connection to the target server could not be established.
- SSL/TLS errors: Errors related to SSL/TLS certificates or secure connections may occur.
Resolving Port 443 Occupation
To resolve the issue of port 443 being occupied by another application, follow these steps:
Step 1: Identify the Occupying Application
- Open a command prompt or terminal on the server where Veeam Backup & Replication is installed.
- Run the command
netstat -anop | findstr 443(on Windows) orlsof -i :443(on Linux) to identify the application using port 443. - Note down the process ID (PID) and name of the occupying application.
Step 2: Change the Occupying Application's Port
- If possible, change the occupying application's port to a different one. For example, if a web server is using port 443, you can change its configuration to use a different port, such as 444.
- Restart the occupying application for the changes to take effect.
Step 3: Configure Veeam Backup & Replication to Use a Different Port
- Open the Veeam Backup & Replication console and navigate to Backup Infrastructure > vCenters.
- Select the vCenter server or ESXi host and click Properties.
- In the Properties window, navigate to the Advanced tab.
- In the Advanced tab, click Add and enter the new port number you want to use instead of 443.
- Click OK to save the changes.
Step 4: Verify Veeam Backup & Replication Connectivity
- Test the connectivity between the Veeam Backup & Replication server and the vCenter server or ESXi host using the new port.
- Verify that backup and replication jobs are successful.
Alternative Solutions
If changing the occupying application's port or configuring Veeam Backup & Replication to use a different port is not feasible, consider the following alternative solutions:
- Use a port redirector: Configure a port redirector to forward traffic from port 443 to a different port used by Veeam Backup & Replication.
- Disable the occupying application: If the occupying application is not critical, consider disabling it or stopping its service.
Conclusion
When the required port 443 for Veeam Backup replication is occupied by another application, it can cause significant disruptions to your backup and replication operations. By understanding the causes of port 443 occupation and following the steps outlined in this article, you can resolve the issue and ensure that your Veeam Backup & Replication jobs run smoothly. Additionally, consider implementing monitoring and logging to detect potential port conflicts and other issues before they impact your critical backup and replication operations.
Veeam Backup & Replication v13 is a hardcoded requirement for the Veeam Web Service/API Gateway
. If this port is occupied by another application, the Veeam services will fail to bind, and the application will not start. Veeam Community Resource Hub Common Applications Occupying Port 443 Hyper-V Replication
: If your backup server also acts as a Hyper-V replica server, it often reserves port 443. IIS (Internet Information Services)
: Other web applications or management portals may be bound to the default HTTPS port. Windows Remote Management (WinRM)
: Sometimes conflicts with Veeam's ability to load its console. How to Resolve the Conflict Since port 443 is
and cannot be changed within Veeam v13 itself, you must reconfigure the conflicting application instead. Veeam Community Resource Hub Identify the Occupying Process Open PowerShell as an Administrator. netstat -anob | findstr :443 to find the Process ID (PID) using the port. Match the PID in Task Manager to find the specific software. Reconfigure Hyper-V (If applicable) Hyper-V Settings Replication Configuration Change the specified port from to an alternative (e.g., 444).
Update individual VM replication settings to match the new port. Temporary Workaround for Upgrades
Stop the conflicting service (e.g., IIS or Hyper-V Replication) before starting the Veeam upgrade.
Once the upgrade completes, you may attempt to re-enable the third-party service on a different port. Registry Fix (Veeam Agents only) For standalone Veeam Agents
(not the main VBR server), you can sometimes force a specific port via the registry key mentioned in Veeam KB2332 For further official guidance, refer to the Veeam Help Center used ports
Major Issues After Upgrading to Veeam V13: Port 443 Conflict 11 Dec 2025 —
Step 1: Hyper-V Setting -> Replication Configuration -> Change Specify the Port from 443 to something else. Veeam B&R 13 Change Web Service Port 443 21 Nov 2025 —
The error "Required port 443 for Veeam Backup & Replication is occupied by another application" typically occurs during an upgrade to Veeam Backup & Replication (VBR) v13, as this version introduces a hardcoded requirement for port 443 for its REST API and Web UI. Review of Issue & Solutions
Industry feedback indicates this is a significant hurdle for environments where port 443 is already used by other critical services like Hyper-V Replication or third-party web applications.
Upgrade Blockage: The VBR v13 installer strictly blocks upgrades if port 443 is in use. There is currently no supported way to change this port within Veeam or bypass the check.
Common Culprit - Hyper-V: A frequent cause is the Hyper-V Replica service on the same server. An "easy fix" reported in Veeam R&D Forums involves changing the Hyper-V replication port from 443 to another value (e.g., 444) before proceeding with the Veeam upgrade.
Troubleshooting Tool: Users on Reddit recommend running netstat -anob in an elevated command prompt to identify the specific process ID (PID) currently bound to port 443.
Official Guidance: Veeam KB4557 advises that if third-party software is using the port, it is generally better to reconfigure that software rather than trying to modify Veeam's expected configuration. Summary of Resolution Steps
Identify the Conflict: Use netstat -anob to find what service is using 443.
Temporary Workaround: Stop the conflicting service long enough to complete the Veeam upgrade. Permanent Fix:
If it is Hyper-V Replication, change the port in Hyper-V Settings > Replication Configuration.
If it is a web service (like IIS or Apache), move that service's SSL binding to a different port.
Consult the Veeam Ports Guide to ensure no other required ports are blocked.
Major Issues After Upgrading to Veeam V13: Port 443 Conflict
Starting with Veeam Backup & Replication v13, port 443 is a required and hardcoded port for the Veeam Web Service/API Gateway. This change often causes conflicts if the same server is already performing other roles, such as hosting a Hyper-V Replication server or another web application. Critical Conflict: Veeam v13 and Port 443
Hardcoded Requirement: In v13.0.1.180 and newer, port 443 is mandatory for the Web Service. Currently, there is no supported method to change this port within Veeam or bypass the installer's compatibility check.
Upgrade Block: If port 443 is occupied, the Veeam installer will typically block upgrades from v12 to v13 until the conflict is resolved.
Service Failure: If the upgrade completes but another application subsequently takes port 443, the Veeam Backup & Replication (VBR) services will fail to bind and may not start. How to Identify the Occupying Application
To find out which specific application is currently using port 443 on your Windows server, use one of the following methods:
PowerShell: Run the following command as an Administrator:Get-Process -Id (Get-NetTCPConnection -LocalPort 443).OwningProcess
Command Prompt: Use the netstat command to see all active ports and the associated Process ID (PID):netstat -ano | findstr :443 Common Solutions and Workarounds
Since Veeam's use of 443 is hardcoded, you must typically reconfigure the other application to free up the port: Reconfigure Hyper-V Replication:
If your VBR server is also a Hyper-V host, change the replication port. Go to Hyper-V Settings > Replication Configuration and change the port from 443 to a different value.
Update the Replica server Port in each VM's replication settings to match the new port to avoid re-replicating data. Stop and Disable Conflicting Services:
Identify the service (e.g., IIS, Apache, or a third-party agent) and stop it during the Veeam upgrade. If that service is non-essential, consider moving it to a different server. Temporary Release for Upgrade:
Some users have successfully completed the upgrade by temporarily stopping the conflicting application to let Veeam claim the port first. However, if the other application restarts and takes the port back, Veeam services may fail. Use a Dedicated Backup Server: Uninstall VMware Workstation
Best practice is to keep the VBR server on a dedicated machine or a workgroup-joined VM to avoid port conflicts and improve security against ransomware. Veeam B&R 13 Change Web Service Port 443
Step 5 — Firewall and network checks
- Ensure Windows Firewall or network firewalls allow the chosen port (443 or alternate) for required directions and hosts.
- If using an alternate port, update firewall rules, load balancers, or DNS entries as needed.
Title
Required port 443 for Veeam Backup & Replication is occupied by another application — how to identify and resolve
Option B: Change Veeam’s Port (If Applicable)
- Veeam does NOT allow changing port 443 for the core Veeam Backup Service. It is hardcoded.
- However, Veeam Enterprise Manager can run on a different port. If EM is the conflict, reinstall EM with a custom port (e.g., 4443) and ensure the main Veeam service is using 443.