1.5 Access and Communication Requirements across Your Protection Network

1.5.1 Network Requirements for the PlateSpin Server Host Web Interface

Table 1-5 describes the ports that must be open for on the PlateSpin Server host to allow access to the Web Interface.

Table 1-5 Open Port Requirements for the PlateSpin Server Host

Port (Default)

Remarks

TCP 80

For HTTP communication

TCP 443

For HTTPS communication (if SSL is enabled)

1.5.2 Network Requirements for Containers

Table 1-6 describes the software, network, and firewall requirements for the supported workload containers.

Table 1-6 Access and Communication Requirements for Containers

System

Prerequisites

Required Ports (Defaults)

All containers

Ping (ICMP echo request and response) capability.

 

All VMware containers. See Supported VM Containers.

  • VMware account with an Administrator role

  • VMware Web services API and file management API

HTTPS (TCP 443)

vCenter Server

The user with access must be assigned the appropriate roles and permissions. Refer to the pertinent release of VMware documentation for more information.

HTTPS (TCP 443)

1.5.3 Network Requirements for Workloads

Table 1-7 describes the software, network, and firewall requirements for workloads that you intend to protect by using PlateSpin Protect.

Table 1-7 Access and Communication Requirements for Workloads

Workload Type

Prerequisites

Required Ports (Defaults)

All workloads

Ping (ICMP echo request and response) support

All Windows workloads. See Supported Windows Workloads.

  • Microsoft .NET Framework 3.5 Service Pack 1

  • Microsoft .NET Framework 4.0

For discovery, source workloads must be running Microsoft .NET Framework 2 SP2 or later.

All Windows Server Cluster workloads. See Clusters in Supported Windows Workloads.

Ensure that the PlateSpin Server can resolve DNS forward lookup and reverse lookup for the IP addresses of the Windows Server Cluster and its cluster nodes. You can update the DNS server or update the local hosts file (%systemroot%\system32\drivers\etc\hosts) on the PlateSpin Server host.

 

All Windows workloads. See Supported Windows Workloads.

  • Built-in Administrator or domain administrator account credentials (membership only in the local Administrators group is insufficient).

  • The Windows Firewall configured to allow File and Printer Sharing. Use one of these options:

    • Option 1, using Windows Firewall: Use the basic Windows Firewall Control Panel item (firewall.cpl) and select File and printer Sharing in the list of exceptions.

      - OR -

    • Option 2, using Firewall with Advanced Security: Use the Windows Firewall with Advanced Security utility (wf.msc) with the following Inbound Rules enabled and set to Allow:

      • File and Printer Sharing (Echo Request - ICMPv4In)

      • File and Printer Sharing (Echo Request - ICMPv6In)

      • File and Printer Sharing (NB-Datagram-In)

      • File and Printer Sharing (NB-Name-In)

      • File and Printer Sharing (NB-Session-In)

      • File and Printer Sharing (SMB-In)

      • File and Printer Sharing (Spooler Service - RPC)

      • File and Printer Sharing (Spooler Service - RPC-EPMAP)

TCP 3725

NetBIOS (TCP 137 - 139)

SMB (TCP 139, 445 and UDP 137, 138)

RPC (TCP 135, 445)

Windows Server 2003 (including SP1 Standard, SP2 Enterprise, and R2 SP2 Enterprise).

NOTE:After enabling the required ports, run the following command at the server prompt to enable PlateSpin remote administration:

netsh firewall set service RemoteAdmin enable

For more information about netsh, see the Microsoft TechNet article, The Netsh Command Line Utility.

TCP 3725, 135, 139, 445

UDP 137, 138, 139

All Linux workloads. See Supported Linux Workloads.

Secure Shell (SSH) server

TCP 22, 3725

1.5.4 Requirements for Windows Authentication to the Microsoft SQL Server Database

PlateSpin Protect provides the ability to use Windows Authentication for access to the Microsoft SQL Server database. You must configure Active Directory settings and open up ports in the firewall to allow authentication.

To enable Windows Authentication to the SQL database:

  1. Ensure that you configure Microsoft SQL Server to allow both TCP/IP and Named Pipe connections.

  2. (Conditional) If you plan to use Windows Authentication to access the Microsoft SQL Server database, you must configure the following in Active Directory:

    • You must add the Microsoft SQL Server database server to the domain.

    • You need two domain user accounts for the PlateSpin Protect installation.

      • A Domain user with the sysadmin role set: This user with SQL Admin rights is required to create databases, tables, and other schema objects.

      • PlateSpin Service user: The service user can be a low-privileged domain user in the domain. However, the service user must be a local administrator on the PlateSpin Protect Server and should be granted that permission prior to the installation.

        If the Windows user’s password changes, you must update the password for the PlateSpin Service user and for the IIS App Pool. Consider using a Windows user whose password never expires to avoid the situation.

    NOTE:If you use Windows Authentication, you must log in as the domain user with SQL Admin rights when you upgrade or update your PlateSpin Server.

  3. Open the following ports on the firewall to support authentication to the SQL Server:

    • Ports 49152-65535/TCP: Allow traffic for RPC for LSA, SAM, Netlogon.

    • Port 1433/TCP: Allow traffic for Microsoft SQL Server.

    • Custom ports: If you configure SQL Server to use a custom TCP port, you must open that port on the firewall.

    NOTE:If you do not use dynamic ports, you must specify the dedicated port in the Database Server field.

  4. (Conditional) If you want to use dedicated ports with PlateSpin Protect, you must open the ports on the firewall:

    1. On the database server, determine which ports need to be opened:

      1. In the SQL Server Configuration Manager, select Protocols for SQLExpress > TCP/IP, then right-click and select Properties.

      2. In the dialog, select the IP Addresses tab.

      3. Under IPAll (or under the desired protocol), if TCP Port or TCP Dynamic Ports is set to any value other than 0, open the specified ports on the firewall. These are the ports you use to connect to the SQL Server.

        For example, if the TCP Dynamic Ports field is set to 60664, and the TCP Port field is set to 1555, then you must enable Port 60664 and 1555 in the firewall rules on the SQL server.

    2. Open the ports on the firewall.

    NOTE:If you have a value set for dynamic ports, you may not see your server in the list of SQL servers when you click Browse. In this case, you must specify the server manually in the Database Server input field of the PlateSpin Protect installation.

    For example, if your server name is MYSQLSERVER, the database instance name SQLEXPRESS, and the dedicated port set for the dynamic port is 60664, you type the following text, and then select the desired authentication type:

    MYSQLSERVER\SQLEXPRESS,60664

    You must open the ports on the firewall.

1.5.5 Requirements for Protection across Public and Private Networks through NAT

In some cases, a source, a target, or PlateSpin Protect itself, might be located in an internal (private) network behind a network address translator (NAT) device, unable to communicate with its counterpart during protection.

PlateSpin Protect enables you to address this issue, depending on which of the following hosts is located behind the NAT device:

  • PlateSpin Server: Using your server’s PlateSpin Configuration tool, record the additional IP addresses assigned to the PlateSpin Server host. See Requirements for the PlateSpin Server to Function through NAT.

  • Target Container: When you attempt to discover a container (such as VMware ESX), specify the public (external) IP address of that host in the discovery parameters.

  • Workload: When you attempt to add a workload, specify the public (external) IP address of that workload in the discovery parameters.

  • Failed-over VM: During failback, you can specify an alternative IP address for the failed-over workload in Failback Details (Workload to VM).

  • Failback Target: During an attempt to register a failback target, when you are prompted to provide the IP address of the PlateSpin Server, provide either the local address of the PlateSpin Server host or one of its public (external) addresses recorded in the server’s PlateSpin Configuration database. See Requirements for the PlateSpin Server to Function through NAT.

1.5.6 Requirements for the PlateSpin Server to Function through NAT

The PlateSpin Server needs additional IP addresses in order to function across environments that are enabled for Network Address Translation. See Requirements for the PlateSpin Server to Function through NAT.

1.5.7 Overriding the Default bash Shell for Executing Commands on Linux Workloads

By default, the PlateSpin Server uses the /bin/bash shell when executing commands on a Linux source workload.

If required, you can override the default shell by modifying the corresponding registry key on the PlateSpin Server. See Knowledgebase Article 7010676 Linux Default Shell Override Procedure.