Moving to Plesk Automation 11.5

Moving to Plesk Automation 11.5 Last updated: 2 June 2015

Contents About This Document 4 Introduction 5 Preparing for the Move 7 1. Install the PA Moving Tool... 8 2. Install Mail Sync Software (Windows Servers)... 9 3. Configuring Firewalls... 10 4. Prepare Source Servers... 12 5. Prepare Service Nodes... 13 Register Service Nodes in PA... 15 Check Disk Space on Service Nodes... 15 Install MySQL on IIS Web Server Nodes (Windows Servers)... 16 Install Server Side Includes (Windows Servers)... 17 6. (Optional) Create Reverse DNS Zones... 17 7. (Optional) Prepare for Assimilating SmarterMail Servers... 17 8. (Optional) Prepare for Assimilating Database Servers... 19 Transfer Scenario for Plesk 8.6 and Later 21 Multiple Webspaces in a Single Subscription... 23 1. Configure the Tool... 24 2. Import Resellers to PA... 28 3. Import Plans to PA... 28 4. Generate a Transfer List... 30 5. Associate Subscriptions with Plans... 33 6. Check for Possible Conflicts... 34 7. Install MySQL on Target IIS Nodes... 35 8. Run Transfer... 36 9. Redirect DNS to the New Servers... 36 10. Verify the Transferred Data... 36 11. Finalize the Synchronization of Content... 37 Transfer Scenario for Expand 2.3.3 38 1. Import Resellers to PA... 40 2. Import Plans to PA... 40 3. Configure the Tool... 41 4. Generate a Transfer List... 45 5. Associate Subscriptions with Plans... 47 6. Check for Possible Conflicts... 48 7. Run Transfer... 49 Transfer Scenario for H-Sphere 3.5 and Later 51 Prerequisites... 55 1. Prepare Source Servers... 55

About This Document 3 2. Configure the Tool... 57 3. Generate a Transfer List... 59 4. Import Resellers to PA... 61 5. Associate Subscriptions from H-Sphere with Plans in PA... 62 6. Perform the Migration... 63 7. Set Up DNS Forwarding... 63 8. Verify the Transferred Data... 64 Transfer Scenario for PBAS 65 1. Import Plans to PA... 68 2. Connect PA to PBAS... 68 3. Generate the Transfer Data and Configuration Files... 70 4. Configure the Tool... 72 5. Check for Possible Conflicts... 73 6. Install MySQL on IIS Web Server Nodes (Windows Servers)... 74 7. Run Transfer... 75 8. Finalize Transfer... 75 Transfer Scenario for Helm 3 77 1. Prepare Source Servers... 81 2. Configure the Tool... 82 3. Import Resellers to PA... 84 4. Import Plans to PA... 85 5. Generate a Transfer List... 85 6. Associate Subscriptions from Helm with Plans in PA... 87 7. Check for Possible Conflicts... 88 8. Run Transfer... 89 9. Redirect DNS to the New Servers... 90 10. Verify the Transferred Data... 90 11. Finalize the Synchronization of Content... 91 Transfer Scenario for Helm 4.2.2 92 1. Prepare Source Servers... 95 2. Configure the Tool... 96 3. Import Resellers to PA... 98 4. Import Plans to PA... 99 5. Generate a Transfer List... 100 6. Associate Subscriptions from Helm with Plans in PA... 102 7. Check for Possible Conflicts... 103 8. Run Transfer... 104 9. Redirect DNS to the New Servers... 105 10. Verify the Transferred Data... 105 11. Finalize the Synchronization of Content... 106 Troubleshooting 107 Known Issues and Limitations... 107

C H A P T E R 1 About This Document This document describes how to move from a number of independent servers controlled by some hosting panels to a multi-server environment controlled by Plesk Automation (hereafter referred to as PA). The document is intended for administrators who are considering moving their hosting servers under the PA control and are willing to gain all benefits of centralized server management.

C H A P T E R 2 Introduction Currently, a large number of hosting providers use control panels like Plesk as a means to manage web hosting on a single server. Typically, such servers are administered separately, so server maintenance costs grow with each new added server. To reduce the costs and simplify server maintenance, we offer the providers to transition their existing infrastructure to a multi-server environment managed from a single web interface called Plesk Automation (PA). PA is a web hosting control panel where one central server (management node) controls an arbitrary number of other servers with various roles - web, mail, DNS, and so on. In terms of PA, these controlled servers are called service nodes. When a customer subscribes to a web hosting plan, PA allocates all the necessary resources on service nodes and links these resources to the customer s account. For example, when a customer subscribes to a shared web hosting plan, PA creates a webspace for the customer on one of the available web server nodes. If the subscription also includes mail services, PA creates mailboxes for the customer on one of the mail server nodes. Note: This document assumes you already have a working PA installation. For information about how to install PA, refer to the Plesk Automation: Deployment Guide. Moving to PA Moving to PA involves transferring of hosting data from existing servers to PA service nodes. All business objects (service plans, customer and reseller accounts, and other) are transferred from the servers to the PA management node. All subscriptions, websites and mailboxes are relocated to registered PA service nodes. When migrating from Plesk or Expand, you also have the option to keep existing SmarterMail mail servers and assimilate them in a PA installation. Supported Source Platforms The following source platforms are supported: Plesk 8.6 and later Plesk Expand 2.3.3 Parallels H-Sphere 3.5 and later Parallels Business Automation Standard 4.3.1-12 and later Parallels Helm 3. Parallels Helm 4.2.2

6 Introduction Prerequisites Before starting a transfer, you should perform a number of common preparation steps (on page 7). Once the steps are completed, you can proceed to transferring data. The transfer scenarios vary depending on the source platform.

C H A P T E R 3 Preparing for the Move You should perform the following preparation steps before performing the move: 1. Install the moving tool (on page 8). To perform your move to PA, you should use a command-line tool called ppatransfer, which is available from the Parallels website. 2. Install mail sync software (Windows servers) (on page 8). This step is required only if you perform the move from Windows-based Panel servers. Without this software, the tool will be unable to transfer mail from such servers. 3. Open ports in firewalls (on page 10). To ensure that the data transfer is possible, configure the firewalls on the source and destination servers to allow connections on the necessary ports. On Windowsbased source servers, also make sure that the administrative shares (admin$, c$, d$) exist. 4. Prepare the source servers (on page 12). Carry out several checks and install the rsync software on Windows-based nodes. 5. Prepare the destination service nodes (on page 13). Add the required number of servers to PA and install additional software. Once the preparation is finished, you can start the data transfer. In this chapter: 1. Install the PA Moving Tool... 8 2. Install Mail Sync Software (Windows Servers)... 8 3. Configuring Firewalls... 10 4. Prepare Source Servers... 12 5. Prepare Service Nodes... 13 6. (Optional) Create Reverse DNS Zones... 17 7. (Optional) Prepare for Assimilating SmarterMail Servers... 17 8. (Optional) Prepare for Assimilating Database Servers... 19

8 Preparing for the Move 1. Install the PA Moving Tool We strongly recommend that you install the tool on the management node. However, if needed, you can run the tool on any server in your network that meets the following requirements: CentOS 5.x/6.x or Red Hat Enterprise Linux 5.x/6.x is installed on the server. The server is able to connect to your hosting servers and the PA management node. To install the tool on a server: 1. Log in to your server as root. 2. Download the installation script: wget http://autoinstall.plesk.com/panel-migrator/installer.sh 3. Make installer.sh executable: chmod +x installer.sh 4. Install the tool by running the script:./installer.sh After you complete this step, the tool will be ready for operation. The tool is automatically updated every time you run it. Tuning the Migration Performance By default, PA restarts Apache service on PA Apache service nodes after every change that requires a restart. There are several such changes during the transfer of a single subscription. If the PA Apache service node carries many sites, each restart of the Apache service may take up to a minute. For example, if you transfer 10 subscriptions to a single PA Apache service node, Apache restart takes 30 seconds, and this happens 3 times during the transfer of each subscription. In this case, migration takes additional 15 minutes just to restart the Apache service. To reduce the migration time, you can do the following: set PA s apache-restart-interval setting to a high value before transfer, run the transfer, restore the original Apache restart interval, and then restart Apache on all Apache service nodes. If you want the migration tool to do this automatically, specify a value for the apacherestart-interval setting in the migration tool s configuration file. You can learn more about configuration in the corresponding sections titled Configure the Tool.

Preparing for the Move 9 2. Install Mail Sync Software (Windows Servers) Important: This step is required if the source mail server on your Plesk for Windows supports IMAP. By default, the support for IMAP is turned on in all versions of Plesk for Windows starting with Plesk 9. If you use an earlier Plesk version or if you intentionally turned off the support for IMAP, skip this step. The PA moving tool transfers mail services from Windows servers using a third-party utility called imapsync. Therefore, before transferring data from Windows servers, you should install imapsync on the same server where you installed the PA moving tool. If you are planning to assimilate a single SmarterMail server, then you do not need to install imapsync. To install imapsync on CentOS 5, use the PA moving tool: ppa-transfer install-imapsync To install imapsync on RHEL 5, follow the instructions below: 1. Install EPEL repository by running the following command: On 32-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/5/i386/epel-release- 5-4.noarch.rpm On 64-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/5/x86_64/epelrelease-5-4.noarch.rpm 2. Install imapsync from the EPEL repository: yum install imapsync To install imapsync on CentOS 6 or RHEL 6, follow the instructions below: 1. Install EPEL repository by running the following command: On 32-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/6/i386/epel-release- 6-8.noarch.rpm On 64-bit OSes: rpm -ihv http://dl.fedoraproject.org/pub/epel/6/x86_64/epelrelease-6-8.noarch.rpm 2. For RHEL 6, install the perl-file-copy-recursive package from the CentOS 6 repository: # rpm -ihv http://mirror.centos.org/centos/6/os/i386/packages/perl-file-copy- Recursive-0.38-4.el6.noarch.rpm 3. Install imapsync from the EPEL repository: yum install imapsync

10 Preparing for the Move 3. Configuring Firewalls If a source or destination server is behind a firewall, you need to properly configure the firewall to allow the migration data exchange. The following ports must be opened on the source servers. Source platform Linux-based servers running Plesk Windows-based servers running Plesk Windows-based servers operating as Plesk Expand centralized mail servers Services and ports SSH connections TCP port 22 Plesk API TCP port 8443 Files and Printers sharing TCP ports: 135, 139, 445 UDP ports: 137, 138 Microsoft SQL server rsync TCP ports: 1433 (if using the default instance) UDP ports: 1434 TCP ports: all, or manually selected (if using a named instance) TCP ports: 873 Plesk API TCP ports: 8443 POP3 and IMAP TCP ports: 110, 143 Files and Printers sharing TCP ports: 135, 139, 445 UDP ports: 137, 138 Plesk API TCP ports: 8443 POP3 and IMAP TCP ports: 110, 143

Preparing for the Move 11 Windows-based servers operating as Plesk Expand centralized database servers Microsoft SQL Server MySQL TCP ports: 1433 (if using the default instance) UDP ports: 1434 TCP ports: all, or manually selected (if using a named instance) TCP ports: 3306

12 Preparing for the Move 4. Prepare Source Servers The preparation of source servers for transfer consists of two main steps: checking that the source servers meet the transfer requirements and installing the rsync software (only for Windows servers). Preliminary Checking Before you start the transfer, perform the following checks on your source servers: 1. Make sure that your source servers are capable of working as slave DNS servers. To check this, you can: 1. Create a sample domain on your source server. 2. Select the source server s DNS server as the slave DNS server for the domain s zone. 3. Ensure that changes in the zone are successfully propagated from the master DNS server to your slave DNS server. 2. Make sure your source servers meet the following disk space requirements: At least 1 GB of free disk space. Additional free disk space for storing dumps of user databases. A dump may be several times larger in size than the original database. Installing the rsync Software (Windows Servers) To transfer data from Windows-based servers, you need to install the rsync software on them. When migrating from Expand, Helm 3, and Plesk for Windows, rsync is configured automatically. To install and configure the rsync software on the source servers: 1. Download the installation file cwrsyncserver_4.0.5_installer.zip from http://autoinstall.plesk.com/panel-migrator/cwrsyncserver_4.0.5_installer.zip. 2. Unpack the file and install rsync following the installation instructions. Important: You must specify a user account with administrator s privileges during installation. 3. Update the rsync configuration file rsyncd.conf with the strings given below. The file is located in the rsync installation directory (C:\Program Files\ICW by default) uid = 0 gid = 0 hosts allow = <target_node1_ip_address>, <target_node2_ip_address>,... log file = rsyncd.log [vhosts] path = /cygdrive/c/inetpub/vhosts

read only = true transfer logging = yes Preparing for the Move 13 where <target_node1_ip_address>, <target_node2_ip_address>,... are the IP addresses of the Windows-based service nodes. Important: If virtual hosts in your Plesk installation are not located in the default directory, change the value of the path variable: 1. Obtain the right path from the Windows registry: HKLM\SOFTWARE\PLESK\PSA Config\Config\HTTPD_VHOSTS_D for 32-bit systems or HKLM\SOFTWARE\Wow6432Node\PLESK\PSA Config\Config\HTTPD_VHOSTS_D for 64-bit systems. 2. Update the value of the path variable with the path from the registry. Note that you should convert the path to the Cygwin format. For example, if your virtual hosts are located at D:\home\plesk_vhosts, the resulting path is /cygdrive/d/home/plesk_vhosts 4. Create the C:\migrator directory and update the rsync configuration file rsyncd.conf with the strings given below. [migrator] path = /cygdrive/c/migrator read only = true transfer logging = yes 5. Configure your firewall to allow inbound connections from target Windows nodes to the port 873. 6. Start the rsync service on behalf of the Windows administrator: net start RsyncServer After installing and configuring rsync, go to the service settings (Services > Log On tab), and make sure that administrator s username and password are specified, or Local system account is selected. Restart the service after changing the user. 5. Prepare Service Nodes Before starting the transfer, you should prepare your PA service nodes for this. These service nodes must be a complete replacement for your source hosting servers: They must provide all the services provided by the source servers. Example 1 For example, you want to migrate from two Plesk servers: one for Windows and one for Linux. To correctly prepare for the transfer, you should: 1. Prepare two clean servers: one with installed Linux and one with installed Windows operating system. 2. Register both servers in PA: Windows server as the node with the IIS web server / MS SQL Server 2008 database server role.

14 Preparing for the Move Linux server as the node with the Apache web server / Postfix mail server / MySQL database server role. 3. Install MySQL on the Windows service node. 4. Install SSI on the Windows service node. 5. Prepare two clean Linux servers (for the DNS service). 6. Register these servers as nodes with the DNS server role. Example 2 For example, you want to migrate from two Plesk for Windows servers. The migration should be performed on two separate Windows service nodes. To correctly prepare for the transfer, you should: 1. Prepare two clean Windows servers (replacement for your existing servers) and one clean Linux server (for the mail service). 2. Register Windows servers in PA as nodes with the IIS web server / MS SQL Server 2008 database server role. 3. Register Linux server as the node with the Postfix mail server role. 4. Install MySQL on the Windows service nodes. 5. Install SSI on the Windows service nodes. 6. Prepare two clean Linux servers (for the DNS service). 7. Register these servers as nodes with the DNS server role. Example 3 For example, you want to migrate from Expand that controls two Plesk servers: one for Windows and one for Linux. To correctly prepare for the transfer, you should: 1. Prepare two clean servers: one with installed Linux and one with installed Windows operating systems. 2. Register both servers in PA: Windows server as the node with the IIS web server / MS SQL Server 2008 database server role. Linux server as the node with the Apache web server / Postfix mail server / MySQL database server role. 3. Install MySQL on the Windows service node. 4. Install SSI on the Windows service node. 5. Prepare two clean Linux servers (for the DNS service). 6. Register these servers as nodes with the DNS server role.

Preparing for the Move 15 Example 4 For example, you want to migrate from Expand that controls two Plesk for Windows servers without the mail service. The migration must be performed on two separate Windows service nodes. To correctly prepare for the transfer, you should: 1. Prepare two clean Windows servers (replacement for your existing servers) and one clean Linux server (for the mail service). 2. Register Windows servers in PA as nodes with the IIS web server / MS SQL Server 2008 database server role. 3. Register Linux server as the node with the Postfix mail server role. 4. Install MySQL on the Windows service nodes. 5. Install SSI on the Windows service nodes. 6. Prepare two clean Linux servers (for the DNS service). 7. Register these servers as nodes with the DNS server role. Next in this section: Register Service Nodes in PA... 15 Check Disk Space on Service Nodes... 15 Install MySQL on IIS Web Server Nodes (Windows Servers)... 16 Install Server Side Includes (Windows Servers)... 17 Register Service Nodes in PA The transfer scenario assumes that you already have a working PA environment with service nodes that can be used as a replacement for your existing servers. Therefore, before performing the data transfer, you should register these service nodes. For instructions on how to register service nodes in PA, refer to the Plesk Automation: Deployment Guide, section Adding Service Nodes. Check Disk Space on Service Nodes Make sure your PA target service nodes have the same (or more) amount of disk space as source servers do.

16 Preparing for the Move Install MySQL on IIS Web Server Nodes (Windows Servers) While Plesk for Windows provides support for MySQL databases, IIS-based web server nodes in PA do not do that. This means that before transferring customer databases from Windows-based Plesk servers, you should first add support for MySQL to the target node. To add support for MySQL on the target IIS web server node: 1. Obtain the MySQL 5.1 distribution package and install it following the installation instructions. 2. Add the MySQL installation directory to the PATH environment variable. 3. Restart the PEM service by running the following commands on behalf of the Windows administrator: net stop pem net start pem

Preparing for the Move 17 Install Server Side Includes (Windows Servers) By default, support for Server Side Includes (SSI) is not enabled on Windows servers. Therefore, if SSI was enabled on your source servers, you must turn on support for SSI on the PA Windows service nodes as well. To turn on support for SSI on a Windows service node: 1. Connect to the node over RDP. 2. Log in to the node as Administrator. 3. Add the SSI role to the server in Server Manager > Roles > Web Server (IIS) > Add Role Services > Server Side Includes. 6. (Optional) Create Reverse DNS Zones A reverse DNS lookup process (when a client looks up a computer name based on its address) is essential to a large number of Internet services. The processing of reverse requests is based on reverse DNS zones that store the information about IP addresses and corresponding domain names. This information is represented by PTR records contained within a corresponding reverse DNS zone. By default, the reverse DNS lookups are disabled in PA. To enable them, you must create one or more reverse DNS zones according to your network configuration. You can do this in Administration Panel > Services > DNS Zones > DNS tab > Reverse DNS Zones. Note that you do not need to create PTR records. PA will automatically create them for all hosted domains, once you have created a suitable reverse DNS zone. 7. (Optional) Prepare for Assimilating SmarterMail Servers The information provided in this article is applicable only to those who migrate from Plesk 9.5 or later, or Expand 2.3, and who use Windows-based SmarterMail servers. Starting from PA 11.5, you have the option to keep existing SmarterMail mail servers in production and connect them to your PA installation. In this case, mailboxes will remain on the SmarterMail servers and PA will control the servers just like any other service nodes. The existing SmarterMail servers can be used for serving new domains and domains transferred from Plesk or Plesk Expand. Compared to the usual data transfer process, this assimilation offers the following advantages: There is no need to buy new hardware for a new SmarterMail server. There is no need to buy an additional SmarterMail license for a new SmarterMail server.

18 Preparing for the Move Zero downtime for the mail services. No additional mail synchronization is required after moving. However, when migrating SmarterMail in transfer mode, the downtime can also be significantly reduced by setting low TTL values in DNS zones before migration. When using external DNS servers (not controlled by the source panel), you do not have to change mail DNS records. There are also several disadvantages in the assimilation: You should be very careful when using the source panel after domains are moved to PA: Any changes to the mail settings of domains in the source panel might disrupt the operation of mail services. Assimilation cannot be reverted. Once a domain is in PA, you cannot transfer it back to the old panel. For this reason, SmarterMail assimilation must not be used when performing test migrations. In general, we recommend performing a transfer instead of assimilation, if you can obtain new hardware and a SmarterMail license. Supported Software Versions Prerequisites SmarterMail 8-11. Versions earlier than 8 are not supported. Plesk 9.5, 10.4, 11.0, 11.5. Parallels Expand 2.3.2 with centralized mail based on Plesk 9.5, 10.4, 11.0, 11.5. 1. Connect the existing SmarterMail server to PA as a regular service node. Refer to Deployment Guide to learn how to do it: http://download1.parallels.com/ppa/11.5/docs/en- US/online/ppa_deployment_guide/71931.htm. 2. Configure a service template for SmarterMail migration. You need to configure a service template that includes the Mail Service resource that is provisioned to a SmarterMail node. When creating service template with the Add Shared Hosting Template wizard, set Mail Hosting to SmarterMail-based. Refer to Operations Guide to learn how to create a new service template: http://download1.parallels.com/ppa/11.5/docs/en- US/online/ppa_operations_guide/70934.htm. 3. Check whether SmarterMail and the newly created service template are properly configured: a Based on the service template, create in PA a test subscription with a webspace and mail resource. b Make sure that there are no failed tasks related to the subscription in PA s task manager (in Operations > Tasks). c Log in to the hosting panel (Operations > Subscriptions > subscription name > Managed By > Login as Customer), and try creating a mailbox (Mail tab > Create Email Address). d Log in to the SmarterMail web interface using the SmarterMail administrator s credentials and make sure that the mailbox was created in SmarterMail.

Preparing for the Move 19 e (Optional) Make sure that this mailbox can receive new messages and that you can send new messages from that email address. Running the Transfer Run the data transfer as described in the following chapters. During the transfer, you will not need to use any special settings or additional configuration steps to ensure that the mailboxes will not be transferred. 8. (Optional) Prepare for Assimilating Database Servers You have the option to keep existing database servers in production and connect them to your PA installation. In this case, databases and database users will remain on the existing database servers and PA will control the servers like any other external database servers. The existing database servers can be used for serving new domains and domains transferred from other hosting platforms. Compared to the usual data transfer process, this assimilation offers the following advantages: There is no need to buy new hardware. There is no need to reconfigure existing customers applications that use databases. In case of Microsoft SQL Server (or other commercial solutions) there is no need to buy additional licenses. There are also several disadvantages in the assimilation: You should be very careful when using the source panel after domains are moved to PA: for example, when you remove a domain from the source panel, databases will be removed too. Two instances of the same web application (on the source and on the target server) use the same databases, which may lead to conflicts. You should consider that and be careful when testing migrated web applications. In general, we recommend performing a transfer instead of assimilation, if you can obtain new hardware, licenses, and reconfigure web applications after migration. Prerequisites 1. Connect existing database servers to PA as external database servers. To do this, use the Add Database Server wizard in Administration Panel > Infrastructure > Database Servers. Important: To be able to register Microsoft SQL Server-based database servers, you should have at least one IIS web server node registered in PA.

20 Preparing for the Move When specifying database server administrator s credentials, do not use root as the username. 2. Create resource types for these servers. To do this, go to Products > Resources > Add New Resource Type > Database Service, type a name, for example assimilated MySQL server, select a database server type, and specify the IP address and port of the external database server. 3. Configure service templates that use these resources. Refer to Operations Guide to learn how to create a new service template: http://download1.parallels.com/ppa/11.5/docs/en- US/online/ppa_operations_guide/70934.htm. You can specify the resources when creating a service template with the wizard, or you can manually add the resources to any service template. 4. Check whether the service templates and external database servers are properly configured: a Based on a service template, create in PA a test subscription with a webspace and a database. b Make sure that there are no failed tasks related to the subscription in PA s task manager (in Operations > Tasks). c Log in to the hosting panel (Operations > Subscriptions > subscription name > Managed By > Login as Customer), and try creating a database and a database user. d (Optional) Make sure that you can log in to the external database server with new database user s credentials, and that the database is present on the server. Running the Transfer Run the data transfer as described in the following chapters. During the transfer, you will not need to use any special settings or additional configuration steps to ensure that the databases will not be transferred.

C H A P T E R 4 Transfer Scenario for Plesk 8.6 and Later The transfer of hosting data requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Thus, all business objects such as plans, customer and reseller accounts are transferred to the PA management node. Subscriptions from your existing servers are transferred to certain service nodes. Performing the Data Transfer The process of transferring hosting data consists of the following steps: 1. Configure the ppa-transfer tool. The tool is configured with the help of a configuration file. It defines various communication parameters such as server IP addresses, the administrator s credentials, and so on. 2. Import resellers to PA (on page 28). The ppa-transfer tool does not fully automate the transfer of resellers to PA: It automatically transfers reseller accounts while you need to manually configure these accounts and reseller plans before transferring resellers customers and domains. 3. Import plans (templates) to PA (on page 28). Service plans are not automatically registered in PA during transfer. Therefore, you should either create your plans in PA manually or use the ppa-transfer tool for this purpose. 4. Create a transfer list (on page 30). A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers. 5. Associate subscriptions and plans (on page 33). Associate subscriptions with certain imported plans. 6. Check for possible conflicts and limitations (on page 34). Before moving to PA, we strongly recommend that you perform a preliminary check for possible transfer conflicts. For example, two different service plans on different Panels may have the same name. Based on the check results, the tool generates a report with all found conflicts. 7. Install MySQL on target Windows-based IIS service nodes. 8. Run the transfer process (on page 36). Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes. 9. Redirect DNS to the new servers (on page 36). After DNS services are relocated to PA, you need to update all your NS records on the registrar s DNS servers with the IP address of your PA DNS server.

22 Transfer Scenario for Plesk 8.6 and Later 10. Verify that the data were transferred correctly (on page 36). The operability of web, mail, DNS, and FTP services for each transferred domain is checked. 11. Finalize the synchronization of content (on page 37). Ensure that any changes to the content made by your customers during the transfer process are transferred as well. 12. (Optional) Create reverse DNS zones (on page 17). As PA does not automatically create reverse DNS zones for used IP network addresses, this should be done manually. In this chapter: Multiple Webspaces in a Single Subscription... 23 1. Configure the Tool... 24 2. Import Resellers to PA... 28 3. Import Plans to PA... 28 4. Generate a Transfer List... 30 5. Associate Subscriptions with Plans... 33 6. Check for Possible Conflicts... 34 7. Install MySQL on Target IIS Nodes... 35 8. Run Transfer... 36 9. Redirect DNS to the New Servers... 36 10. Verify the Transferred Data... 36 11. Finalize the Synchronization of Content... 37

Transfer Scenario for Plesk 8.6 and Later 23 Multiple Webspaces in a Single Subscription In PA, several sites can be hosted either in one subscription, or in individual subscriptions. By default, when transferring sites from Plesk 8 or 9, every domain of a user is transferred to a separate subscription. This results in domain owners having multiple subscriptions to manage, which is not very convenient. To avoid this inconvenience, the migration tool provides the option to transfer all domains of a user into multiple webspaces under one subscription. To use this option, you need to do the following: 1. Before starting a transfer, create in PA a service template that will provide enough web hosting and mail hosting resources. In service template properties (in Products > Service Templates > template name > Resources tab), set the following types of resources to unlimited or equal to the number of migrated sites: Apache Webspace, IIS Webspace, Postfix Mail, SmarterMail, and Subscription. 2. In the tool configuration, set the migration mode, as shown in the section 1. Configure the Tool (on page 24), Example 4.

24 Transfer Scenario for Plesk 8.6 and Later 1. Configure the Tool Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains the config.ini.plesks.template file which you can use as a basis for creating your own config.ini. To configure the tool: 1. Create the config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.plesks.template config.ini 2. Edit the config.ini file to configure the tool. The description of file sections is provided below. The Structure of the Configuration File The config.ini file consists of several sections of two types: Predefined. These sections contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. Custom. These sections contain information about your existing servers. You can use arbitrary names for such sections. For example, [plesk1], [plesk2], and so on. Also, each section has a number of settings of two types: Mandatory. You must define these settings. Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file inside that setting s description. That description also has a commented line with the setting and its default value: if you want to change the value, uncomment that line and change the value in it. The meaning of each setting is described in the configuration template file. Examples of the Configuration File Let us take a look at the examples of the config.ini file. In all these examples, PA is deployed with webmail on a separate service node with IP address 192.168.0.21.

Transfer Scenario for Plesk 8.6 and Later 25 Example 1. In this example, we are going to transfer data from three Panel servers (two on Linux and one on Windows). [GLOBAL] source-type: plesk source-plesks: plesk1, plesk2, plesk3 [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk2] ip: 192.168.0.101 os: unix panel-username: admin panel-password: setup2 ssh-username: root ssh-auth-type: password ssh-password: 234wer [plesk3] ip: 192.168.0.102 os: windows panel-username: admin panel-password: setup3e windows-username: Administrator windows-password: 345ertYU Example 2 In this example, we are going to transfer data from Panel server on Linux, and for security reasons, we do not want to reveal privileged user s password in the config.ini file. Instead of using the password, we will set up the key-based authentication. [GLOBAL] source-type: plesk source-plesks: plesk1

26 Transfer Scenario for Plesk 8.6 and Later [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: key ssh-key: /root/.ssh/id_rsa Example 3 In this example, we are going to transfer data from Panel server on Linux, which uses an external PostgreSQL server to host user databases. That PostgreSQL server is registered in Panel using its IP v4 address (192.168.0.200). [GLOBAL] source-type: plesk source-plesks: plesk1 external-postgresql-servers: pg1 [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe [pg1] host: 192.168.1.200 ip: 192.168.1.200 ssh-username: root ssh-auth-type: password ssh-password: 123qwe

Transfer Scenario for Plesk 8.6 and Later 27 Example 4 In this example, we are going to transfer domains from a Plesk 8 server on Linux to PPA subscriptions with multiple webspaces. [GLOBAL] source-type: plesk source-plesks: plesk1 transfer-domains-to-subscription: same [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 192.168.0.100 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe Example 5 In this example, we are going to transfer domains from a Plesk 11 server on Windows to PA, and assimilate an existing SmarterMail server. [GLOBAL] source-type: plesk source-plesks: plesk1 [ppa] ip: 192.168.0.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 10.52.53.54 os: windows panel-username: admin panel-password: setup4e windows-username: Administrator windows-password: 128erfJR copy-mail-content: none

28 Transfer Scenario for Plesk 8.6 and Later 2. Import Resellers to PA The ppa-transfer tool has the following limitation: It allows you to transfer reseller accounts to PA but it does not automatically transfer reseller plans. Therefore, to seamlessly import existing reseller accounts from your servers, you should first manually create reseller plans in PA that correspond to the ones on your servers, and subscribe the resellers to these plans after the transfer. See the detailed instructions below. To import resellers to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Generate a transfer list file called migration-list, by issuing the following command: # ppa-transfer generate-migration-list config.ini 3. Edit the transfer list file migration-list (located in your session directory) to exclude reseller accounts that you do not want to transfer to PA. To exclude a certain account from transfer, comment out or delete the corresponding line from the list. The lines look like Reseller: <reseller s username>. 4. Perform the transfer of reseller accounts to the PA management node by running the command: # ppa-transfer import-resellers config.ini All resellers that exist in your hosting solution will be transferred to PA. 5. Subscribe the transferred resellers to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates. 6. Configure hosting service templates on behalf of the reseller. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 3. Import Plans to PA The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually. To import plans to PA: 1. Create service plans (templates) in PA that correspond to hosting plans on your Panel servers. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

Transfer Scenario for Plesk 8.6 and Later 29 2. Configure subscription provisioning by assigning proper provisioning attributes to the templates. The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers.

30 Transfer Scenario for Plesk 8.6 and Later 4. Generate a Transfer List A transfer list defines the list of objects (plans, reseller accounts, user accounts, and subscriptions) that should be transferred from source Panels to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the generation, it contains all objects that are present on source servers (see the example below). To generate the transfer list, if you have not done this in step 2, run the following command: # ppa-transfer generate-migration-list config.ini After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps. Transfer List Structure After generation, the list contains all subscriptions that exist on source Panels. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related. The list comprises a number of sections - one section per each reseller. The sections are marked with a line Reseller: Reseller s name. Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol. Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers subscriptions. Customer account names are marked with a line Customer: customer s name. By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list. Each subscription must be assigned to a customer. By default, administrator s subscriptions are assigned to a special customer called ppa-admin. Reseller s subscriptions are assigned to a special customer called ppa- <reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts. You can reassign all subscriptions (including the administrator s and resellers subscriptions) to any customers using the transfer list.

Transfer Scenario for Plesk 8.6 and Later 31 Note: You can assign subscriptions to nonexistent customers. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them. Note that your hosting plans are not grouped under a certain section: They go at the beginning of the file before the reseller sections. Depending on the source panel type, the initial content of the file may differ: If a source panel is Panel 10.x and later, the tool automatically determines association between plans and subscriptions. Thus, each plan section contains the list of associated subscriptions. The only exceptions are custom subscriptions - subscriptions that are not associated with a certain plan. Custom subscriptions are placed outside of plan sections. Typically, all you need is to move custom subscriptions to a certain plan section. If a source panel is Panel 9.x or earlier, the file will contain an unsorted list of all subscriptions and service plans (templates). You should associate subscriptions with the plans by moving them to corresponding plan sections. An Example of the List # The list of subscriptions # These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer. Customer: ppa-admin admins-subscription1.tld Customer: bobs customer1-subscription1.tld customer1-subscription2.tld # Administrator s service plans and subscriptions Plan: Gold hosting Customer: ppa-admin admins-subscription2.tld Customer: jacks customer2-subscription1.tld customer2-subscription2.tld Plan: Bronze hosting Plan: Silver hosting # Resellers Reseller: johns_123 # The subscriptions that are not assigned to a certain service plan. They must be moved to a section of a certain service plan of this reseller. Customer: ppa-johns_123 notassigned1.tld # Reseller s service plans Plan: Unlimited Customer: ppa-johns_123 # The subscriptions of this reseller reseller-subscription1.tld reseller-subscription2.tld # The customers of this reseller subscribed to this plan Customer: johndoe # The subscriptions of this customer reseller1-customer1-subscription1.tld

32 Transfer Scenario for Plesk 8.6 and Later Reseller: toms # Reseller s service plans Plan: Reseller Plan 2 # The customers of this reseller subscribed to this plan Customer: katie_23 # The subscriptions of this customer reseller2-customer1-subscription1.tld

Transfer Scenario for Plesk 8.6 and Later 33 5. Associate Subscriptions with Plans In this step you should associate subscriptions that exist on your servers with certain service plans you have imported to PA in the previous step. This is done by adjusting the transfer list file. As all subscriptions in PA should be associated with certain plans (templates), this step is obligatory for all hosting platforms: Panel 9.x and earlier do not support association between plans (templates) and subscription. Therefore, you should associate them before performing the data transfer. In Panel 10.x and later all subscriptions are associated with certain plans (these associations are automatically reflected in the file). The only exceptions are custom subscriptions - subscriptions that are not the instances of certain service plans. As PA does not support custom subscriptions, you need to associate them with certain plans using the transfer list. To associate subscriptions with certain service plans, edit the transfer file. The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions. Note that the tool will not start the transfer until there are subscriptions which are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding lines or delete them. Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the transfer. For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan move the corresponding line under the plan section. Before # Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting After Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob customer1-subscription1.tld Plan: Silver hosting

34 Transfer Scenario for Plesk 8.6 and Later 6. Check for Possible Conflicts Before performing a transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppa-transfer tool and includes a number of checks concerning various aspects of hosting panels functionality. Below we describe the most important checks that may require your attention: Check for customer / reseller accounts with the same e-mails and contact names. There are three account parameters that the tools use to identify an account: username, e-mail, and contact name. Let us look closer at the system behavior when these parameters match for different accounts: Usernames, e-mails, and contact names are the same. The system considers such accounts to represent the same person or company: Only one of them will be transferred to PA. The priority is given to the account from the panel that is listed first in the sources string of config.ini. Accounts from other panels are ignored: Their subscriptions are also registered in PA, but these subscriptions become associated with the customer / reseller account which had the priority during the transfer. If you want each of such accounts to be transferred to PA, specify another e-mail and username for conflicting accounts. Usernames and contact names are the same, e-mails are different. The move to PA will be impossible until you specify another username for conflicting accounts. Usernames and e-mails are the same, contact names are different. The move to PA will be impossible until you specify the same contact names (if these are the same persons) for conflicting accounts. E-mails are the same, usernames and contact names are different. The move to PA will be impossible until you specify other e-mails for conflicting accounts. To perform the preliminary check: $ ppa-transfer check config.ini Based on the check results, the tool generates a report. The report contains messages of two types: WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when a certain issue blocks the transfer. You must resolve all issues marked as ERROR before performing the transfer.

Transfer Scenario for Plesk 8.6 and Later 35 7. Install MySQL on Target IIS Nodes While Plesk for Windows provides support for MySQL databases, IIS-based web server nodes in PA do not do that. This means that before transferring customer databases from Windows-based Plesk servers, you should first add support for MySQL to the target node. To add support for MySQL on the target IIS web server node: 1. Obtain the MySQL 5.1 distribution package and install it following the installation instructions. 2. Add the MySQL installation directory to the PATH environment variable. 3. Restart the PEM service by running the following commands on behalf of the Windows administrator: net stop pem net start pem

36 Transfer Scenario for Plesk 8.6 and Later 8. Run Transfer Once all preparation steps are done, you can run the transfer process. To run the transfer: 1. Issue the following command: ppa-transfer transfer-accounts config.ini The tool performs the transfer of your hosting data to certain service nodes. 2. Test the transferred domains: ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that. 3. If any issues were found by the tool, resolve them and re-run the command in step 2 to verify they are resolved. The tool does not require you to resolve all of these issues. You can resolve only the important ones. Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example: ppa-transfer test-all config.ini--skip-dns-forwarding-test--migration-list-file migrationsession/successful-subscriptions.1385955582.55 9. Redirect DNS to the New Servers As the DNS service is relocated to the PA DNS server, you should update all your NS records on the registrar s DNS server with the IP addresses of your PA DNS servers. Also, make sure that DNS propagation has ended. This means that you should wait for the period of time which is equal to the sum of TTL and SOA refresh interval. 10. Verify the Transferred Data To check the operability of web, mail, DNS, and FTP services for each transferred domain, issue the following command: ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command checks the following:

Transfer Scenario for Plesk 8.6 and Later 37 Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check. 11. Finalize the Synchronization of Content To complete the synchronization of content between the source and the destination servers, do the following: 1. Copy the content that could be added by your customers during the transfer process from your source servers. To copy mail content: ppa-transfer copy-mail-content config.ini To copy website content: ppa-transfer copy-content config.ini To copy databases: ppa-transfer copy-db-content config.ini In this step, the tool will update the content of the transferred subscriptions with any changes that were made during the transfer. Note that the tool makes a full copy of databases (as opposed to mail and web content where only new content is copied) which may require significant time. 2. Check that the transfer completed successfully. a Issue the command ppa-transfer test-all config.ini. b Send a few email messages from some external address to a transferred mailbox, and check that these messages were received successfully. 3. Remove the rsync software from the source Windows servers.

C H A P T E R 5 Transfer Scenario for Expand 2.3.3 Transferring of hosting data from Plesk Expand 2.3.3 (hereafter referred to as Expand) requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Thus, all business objects such as plans, customer and reseller accounts are transferred to the PA management node. Subscriptions from your existing servers are transferred to certain service nodes. Expand, as a multi-server solution, provides the support for two specific server types: central mail servers and central DNS servers. The services from these servers are transferred in the following way: Central mail servers. Mailboxes and their content are relocated from such servers to a mail server node registered in PA. Central DNS servers. DNS services are relocated to DNS servers registered in PA: They store all DNS zones from the Expand s central DNS server. After the transfer, Expand s DNS server starts to forward all requests to a PA s master DNS server. This allows keeping all existing NS records on a registrar s DNS server as is. Performing the Data Transfer The process of transferring hosting data consists of the following steps: 1. Import resellers to PA (on page 40). Reseller accounts are not automatically transferred to PA: you should do this manually. 2. Import plans (templates) to PA (on page 40). Service plans are not automatically registered in PA during transfer: you should do this manually. 3. Configure the ppa-transfer tool (on page 41). The tool is configured with the help of a configuration file. This defines various communication parameters such as server IP addresses, the administrator s credentials, and so on. 4. Create a transfer list (on page 45). A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers. 5. Associate subscriptions and plans (on page 47). Associate subscriptions with certain imported plans.

Transfer Scenario for Expand 2.3.3 39 6. Check for possible conflicts and limitations (on page 48). Before moving to PA, we recommend that you perform a preliminary check for possible transfer conflicts. For example, two different service plans on different Panels may have the same name. Based on the check results, the tool generates a report with all found conflicts. 7. Run the transfer process (on page 49). Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes. In this chapter: 1. Import Resellers to PA... 40 2. Import Plans to PA... 40 3. Configure the Tool... 41 4. Generate a Transfer List... 45 5. Associate Subscriptions with Plans... 47 6. Check for Possible Conflicts... 48 7. Run Transfer... 49

40 Transfer Scenario for Expand 2.3.3 1. Import Resellers to PA The ppa-transfer tool does not automatically transfer reseller accounts to PA. You should do this manually. To import resellers to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Create all reseller accounts you want to transfer as described in the Plesk Automation: Operations Guide, section Creating Reseller Accounts. 3. Subscribe the resellers you created in step 2 to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates. 4. Configure hosting service templates on behalf of the reseller. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 2. Import Plans to PA The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually. Note that this refers to all types of service plans: hosting plans, reseller plans, and hosting plans of your resellers. To import hosting plans to PA: 1. Create service plans (templates) in PA that correspond to hosting plans in Expand. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 2. Configure subscription provisioning by assigning proper provisioning attributes to the templates. The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers. To import reseller plans to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans in Expand. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Subscribe resellers transferred in step 3. Import Resellers to PA (on page 40) to the newly created reseller templates. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates.

Transfer Scenario for Expand 2.3.3 41 To import hosting plans of a certain reseller to PA: 1. Create service plans (templates) in PA that correspond to the hosting plans of this reseller in Expand. To do this, use the Add New Service Template button in Operations > Resellers > select a reseller > Subscriptions tab > Service templates. 2. Configure subscription provisioning by assigning proper provisioning attributes to the templates. The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers. 3. Configure the Tool Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains the config.ini.expand.template file that you can use as a basis for creating your own config.ini. Important: We strongly recommend that you create a separate directory for each transfer operation and perform the transfer being in this directory. To configure the tool: 1. Create the config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.expand.template config.ini 2. Edit the config.ini file to configure the tool. The description of file sections is provided below. The Structure of the Configuration File The config.ini file consists of several sections of two types: Predefined. These sections contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. The [expand] section contains the information about your Expand server. Custom. These sections contain information about your existing servers. You can use arbitrary names for such sections. For example, [plesk1], [plesk2], and so on. Also, each section has a number of settings of two types: Mandatory. You must define these settings.

42 Transfer Scenario for Expand 2.3.3 Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file inside that setting s description. That description also has a commented line with the setting and its default value: if you want to change the value, uncomment that line and change the value in it. The meaning of each setting is described in the configuration template file. An Example of the Configuration File Let us take a look at the example of the config.ini file. Example 1 In this example, we are going to transfer data from Expand with the following servers connected: two Panel servers (one on Linux and one on Windows), one centralized mail server, and one centralized DNS server. The PA installation in this example is deployed with webmail on a separate service node with IP address 192.168.1.21. [GLOBAL] source-type: expand source-plesks: plesk1, plesk2 centralized-mail-servers: cm1 centralized-dns-servers: cd1 [ppa] ip: 192.168.1.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.1.21 [expand] ip: 192.168.0.1 panel-username: root panel-password: 123qwe ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk1] ip: 192.168.0.2 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk2] ip: 192.168.0.3 os: windows panel-username: admin panel-password: setup2

Transfer Scenario for Expand 2.3.3 43 windows-username: Administrator windows-password: 234werTY [cm1] ip: 192.168.0.4 os: unix panel-username: admin panel-password: setup3 ssh-username: root ssh-auth-type: password ssh-password: 345ert [cd1] ip: 192.168.0.5 ssh-username: root ssh-auth-type: password ssh-password: 456rty Example 2 In this example, we are going to transfer data from an Expand installation that has one Linux-based web hosting server, and one centralized Windows-based mail server running SmarterMail. The mail server will be assimilated. [GLOBAL] source-type: expand source-plesks: plesk1 centralized-mail-servers: cm1 [ppa] ip: 192.168.1.1 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.1.21 [expand] ip: 192.168.0.1 panel-username: root panel-password: 123qwe ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk1] ip: 192.168.0.2 os: unix panel-username: admin panel-password: setup1 ssh-username: root ssh-auth-type: password ssh-password: 123qwe [cm1] ip: 10.52.53.54 os: windows

44 Transfer Scenario for Expand 2.3.3 panel-username: admin panel-password: setup windows-username: Administrator windows-password: setup copy-mail-content: none

Transfer Scenario for Expand 2.3.3 45 4. Generate a Transfer List A transfer list defines the list of objects (plans, reseller accounts, user accounts, and subscriptions) that should be transferred from source Panels to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the generation, it contains all objects that are present on source servers (see the example below). To generate the transfer list, run the following command: # ppa-transfer generate-migration-list config.ini After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps. Transfer List Structure After generation, the list contains all subscriptions that exist on source Panels. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related. The list comprises a number of sections - one section per each Expand reseller. The sections are marked with a line Reseller: Reseller s name. Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol. Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers subscriptions. Customer account names are marked with a line Customer: customer s name. By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list. Each subscription must be assigned to a customer. By default, administrator s subscriptions are assigned to a special customer called ppa-admin. Reseller s subscriptions are assigned to a special customer called ppa- <reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts. You can reassign all subscriptions (including the administrator s and resellers subscriptions) to any customers using the transfer list. Note: You can assign subscriptions to nonexistent customers. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them.

46 Transfer Scenario for Expand 2.3.3 Note that your hosting plans are not grouped under a certain section: They go at the beginning of the file before the reseller sections. The tool automatically determines association between plans and subscriptions. Thus, each plan section contains the list of associated subscriptions. The only exceptions are custom subscriptions - subscriptions that are not associated with a certain plan. Custom subscriptions are placed outside of plan sections. Typically, all you need is to move custom subscriptions to a certain plan section. An Example of the List # The list of subscriptions # These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer. Customer: ppa-admin admins-subscription1.tld Customer: bobs customer1-subscription1.tld customer1-subscription2.tld Customer: johns_123 # Expand Plesk resellers are converted into PA customers. notassigned1.tld # Administrator s service plans and subscriptions Plan: Gold hosting Customer: ppa-admin admins-subscription2.tld Customer: jacks customer2-subscription1.tld customer2-subscription2.tld Customer: johns_123 # Expand Plesk resellers are converted into PA customers. reseller-subscription1.tld reseller-subscription2.tld Customer: johndoe # The subscriptions of this customer reseller1-customer1-subscription1.tld Plan: Bronze hosting Plan: Silver hosting # Expand Resellers Reseller: exp_ress1 Plan: PA plan for exp_ress1 customers Customer: jake site1.tld site2.tld Customer: robert # Expand Plesk resellers are converted into PA customers. site3.tld site4.tld

Transfer Scenario for Expand 2.3.3 47 5. Associate Subscriptions with Plans In this step you should associate subscriptions that exist on your servers with certain service plans you have imported to PA in one of the previous steps. This is done by adjusting the transfer list file. By default, the file already contains such associations for all subscriptions. As PA does not support custom subscriptions, you need to associate them with certain plans using the transfer list. Note: The list contains plans and subscriptions only from the Expand server. Plans from Panel servers connected to Expand are ignored. To associate subscriptions with certain service plans, edit the transfer file. The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions. Note that the tool will not start the transfer until there are subscriptions that are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding subscription lines or delete them. Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the transfer. For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan, move the corresponding line under the plan section. Before # Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting After Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob customer1-subscription1.tld Plan: Silver hosting

48 Transfer Scenario for Expand 2.3.3 6. Check for Possible Conflicts Before performing the transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppa-transfer tool and includes a number of checks concerning various aspects of hosting panels functionality. Below we describe the most important checks that may require your attention: Check for customer / reseller accounts with the same e-mails and contact names. There are three account parameters that the tool uses to identify an account: username, e-mail, and contact name. Let us look closer at the system behavior when these parameters match for different accounts: Usernames, e-mails, and contact names are the same. The system considers such accounts to represent the same person or company: Only one of them will be transferred to PA. The priority is given to the account from the panel that is listed first in the sources string of config.ini. Accounts from other panels are ignored: Their subscriptions are also registered in PA, but these subscriptions become associated with the customer / reseller account which had the priority during the transfer. If you want each of such accounts to be transferred to PA, specify other e-mail and username for conflicting accounts. Usernames and contact names are the same, e-mails are different. The move to PA will be impossible until you specify another username for conflicting accounts. Usernames and e-mails are the same, contact names are different. The move to PA will be impossible until you specify the same contact names (if these are the same persons) for conflicting accounts. E-mails are the same, usernames and contact names are different. The move to PA will be impossible until you specify other e-mails for conflicting accounts. To perform the preliminary check: $ ppa-transfer check config.ini Based on the check results, the tool generates a report. The report contains messages of two types: WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when a certain issue blocks the transfer. You must resolve all issues marked as ERROR before performing the transfer.

Transfer Scenario for Expand 2.3.3 49 7. Run Transfer Once all preparation steps are done, you can run the transfer process. To complete the transfer: 1. Lower records TTL and refresh interval on the central DNS servers. This will let you minimize the time of new DNS records propagation. You can do this by running the command: ppa-transfer set-low-dns-timings config.ini This command sets TTL and refresh time using the value of the zones-ttl parameter from the config.ini file. We recommend that you use the default value (120 seconds). 2. Run the transfer: ppa-transfer transfer-accounts config.ini The tool performs the transfer of your hosting data to certain service nodes. If you did not set the resource limits in the service templates that you use for transfer to Unlimited, then the migration tool may exhaust certain resources of a PA subscription while creating webspaces that do not need these resources. This can result in failure to create the webspaces for which the resources are required. To avoid this, use the option--allocate-only-required-resources. For example: ppa-transfer transfer-accounts config.ini--allocate-onlyrequired-resources Test the transferred domain by issuing the command ppa-transfer test-all config.ini-- skip-dns-forwarding-test. The test-all command checks the following: Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. 1. If any issues were found by the tool, resolve them and re-run the command in the previous step to verify they are resolved.

50 Transfer Scenario for Expand 2.3.3 The tool does not require you to resolve all of these issues. You can resolve only the important ones. Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example: ppa-transfer test-all config.ini--skip-dns-forwarding-test-- migration-list-file migration-session/successfulsubscriptions.1385955582.55 2. Prohibit your hosting customers from accessing their subscriptions both on the source servers and target service nodes. You can do this in any way you find convenient. For example, temporarily change customers passwords or prohibit connections to the 8443 port on the server. 3. Ensure that the period of time which is equal to the sum of old values of TTL and SOA refresh interval has passed since you ran the tool. This guarantees that all mail clients receive a new TTL value before you switch DNS forwarding on. 4. Turn on DNS forwarding: ppa-transfer set-dns-forwarding config.ini Note: If you perform the transfer from Expand with the central DNS server, you should set up DNS forwarding on this server instead of removing it from your infrastructure. In this case, the central DNS server continues to work - it does not store any DNS records (this is done by PA) but only forwards all requests to a PA s master DNS server. This allows keeping all existing NS records on a registrar s DNS server as is. 5. Ensure that the period of time which is equal to the sum of new values of TTL and SOA refresh interval (that you set up on the step 1) has passed after you switched forwarding. This guarantees that all clients have received the new address of your mail server. 6. Copy the content that could be added by your customers during the transfer process from your source servers. To copy mail content: ppa-transfer copy-mail-content config.ini To copy website content: ppa-transfer copy-content config.ini To copy databases: ppa-transfer copy-db-content config.ini In this step, the tool will update the content of the transferred subscriptions with the changes that were made between the steps 1 and 3. Note: The tool makes a full copy of databases (as opposed to mail and web content where only new content is copied) which may require significant time. 7. On target service nodes, allow your hosting customers to access their subscriptions. 8. Check that the transfer completed successfully by issuing the following command: ppa-transfer test-all config.ini

C H A P T E R 6 Transfer Scenario for H-Sphere 3.5 and Later In the current release, PA migration tools allow for migration of H-Sphere for Linux and Windows hosting subscriptions to the PA environment. This includes migration of the websites running under Apache and IIS web servers, mail accounts from H-Sphere qmail to PA postfix, MySQL and Microsoft SQL Server databases. To start the migration, you need a running PA environment with all required service nodes attached. The service templates (hosting plans) should be pre-configured in PA. You will be mapping your old H-Sphere subscriptions to the PA plans. Note: To learn more about configuring the PA environment before migration, see the section Prerequisites (on page 55). During migration, all account information is imported to the PA management node. After that, the migration tool creates a subscription in PA and the hosting content is copied into this subscription. If you are using reseller accounts, you should import the reseller s data first, and then configure service templates for these resellers. After that you will be mapping the subscriptions belonging to the resellers in H-Sphere to the service templates for these resellers in PA. Note that DNS records are not migrated from H-Sphere. Instead, PA creates new zone definitions based on its own DNS zone template. You can pre-configure the DNS template from PA administration panel. Mapping of Business Objects In H-Sphere Admin User Account Reseller The first domain of an account Other domains of an account Subdomain Third-level domain Parked domain In PA Provider Customer Subscription Reseller The main domain of a subscription Add-on domains Subdomain Add-on domain Add-on domain

52 Transfer Scenario for H-Sphere 3.5 and Later Stopgap domain Add-on domain Known Limitations for Transfers from H-Sphere Migration of the following hosting features and settings on Linux-based servers is not supported: ModLogAn Referrer Log Agent Log Redirects Ruby on Rails Web Access Control PHP file extensions Migration of the following hosting features and settings on Windows-based servers is not supported: FrontPage Redirects Additional server aliases Any settings of Microsoft Exchange Web access control based on domain names is not transferred, as it s not supported in PA. IP-address-based web access control settings are transferred. SSI #exec directive support ODBC DSNs PA does not support ASP.NET 1.1. Sites using ASP.NET 1.1 will have to work with ASP.NET 2.0 after transfer. Please consider this when checking the transferred sites. Migration of the following mail features is not supported: mail SMS comments from mailboxes mailing lists gray lists mail domain keys mail accounts on subdomains After migration, database users will have the database administrator privileges. The privileges of database users that were granted before migration are not restored. The migration tool does not support csh on FreeBSD.

Transfer Scenario for H-Sphere 3.5 and Later 53 Known Problems After transfer of virtual directories located in user s home directory (above the site s directory), the virtual directory is not accessible over the the Web, resulting in the error 403 Forbidden. To resolve it, PA administrators should grant the corresponding IIS anonymous web user (IUSR_<webspace s system user name>) all permissions (except Full Control) on the transferred directory and files/directories under it. There is no such problem with virtual directories placed under site s directory. After transfer of error pages placed above the site s directory, IIS will respond with its default error messages instead of these error pages. To resolve this, PA administrators should grant the corresponding IIS anonymous web user (IUSR_<webspace s system user name>) the Read permission on the transferred error pages files. There is no such problem with error documents placed under site s directory. If a customer wants to change the path to error page file in PA Hosting Panel, Hosting Panel will reject the entered path, unless customer places the error page file under <webspace>/error_docs directory and enters its relative path starting after error_docs/. IIS dedicated application pools are not transferred. PA allows using different PHP and ASP.NET versions in different virtual directories of a webspace as long as this webspace is not using a dedicated application pool. So it s up to the customer to choose: either to use a dedicated application pool, or to have the ability to set different PHP and ASP.NET versions in different sites and different virtual directories of the same webspace. Applications that need to create files in the directories of add-on domains or subdomains (such as WordPress), will not operate properly after transfer because they do not have the write permission. To resolve this, after completing the transfer, go to the Customer Panel > Websites tab, click the Hosting Settings link next to the addon domain or subdomain, switch on the Additional write/modify permissions, and click OK. An IIS site transferred from H-Sphere may not work, issuing 500 Internal Server Error, if that site is using parent paths in its ASP pages. For example, a page of such a site refers to another page as: <% Response.Write Server.MapPath(../example.asp ) %> PA offers IIS hosting on Windows 2008 and 2012. IIS on both these versions does not allow using parent paths by default. When a site is using parent paths, IIS does not let it work. Possible solutions: After migration of a specific site: enable the use of parent paths for the specific site that is using them, in that site s ASP settings in IIS Manager. Before migration of any sites: enable the use of parent paths for all future sites on an IIS service node, in global or default settings of its IIS service.

54 Transfer Scenario for H-Sphere 3.5 and Later Before or after migration of specific sites: notify the site owners that the parent paths policy has been changed, and they must modify their sites so as to avoid the use of parent paths; otherwise, their sites will not work. MnoGoSearch and PHPBB are migrated but are not manageable through PA. Performing a Migration The process of transferring hosting data is performed by the ppa-transfer tool and consists of a number of steps: 1. Prepare source servers. 2. Configure the ppa-transfer tool. The tool is configured with the help of a configuration file. This defines various communication parameters such as server IP addresses, the administrator s credentials, and so on. 3. Create a transfer list. A transfer list is a file that specifies what objects (reseller accounts and subscriptions) should be transferred to PA from the source H-Sphere server. 4. Import resellers to PA. The ppa-transfer tool does not fully automate the transfer of resellers to PA: It automatically transfers reseller accounts while you need to manually configure these accounts and reseller plans before transferring resellers customers and domains. 5. Associate subscriptions from H-Sphere and plans in PA. 6. Run the migration process. Once all preparation steps are completed, you can run a migration. In this step, the tool creates new subscriptions in PA according to the chosen service templates and imports the subscription content from H-Sphere: websites, databases, and mailboxes. 7. Set up DNS forwarding to ensure that the migrated domains are resolved in the DNS. 8. Verify the transferred data. The operability of web, mail, DNS, and FTP services for each transferred domain is checked. In this chapter: Prerequisites...55 1. Prepare Source Servers...55 2. Configure the Tool...57 3. Generate a Transfer List...59 4. Import Resellers to PA...61 5. Associate Subscriptions from H-Sphere with Plans in PA...62 6. Perform the Migration...63 7. Set Up DNS Forwarding...63 8. Verify the Transferred Data...63

Transfer Scenario for H-Sphere 3.5 and Later 55 Prerequisites Before migrating, configure the PA environment: 1. Attach all required service nodes as described at http://download1.parallels.com/ppa/docs/en- US/online/ppa_deployment_guide/70075.htm. 2. Install license keys as described at http://download1.parallels.com/ppa/docs/en- US/online/ppa_deployment_guide/71386.htm. 3. Create service plans (referred to as shared hosting templates) in PA that correspond to hosting plans on your H-Sphere server. This is described at http://download1.parallels.com/ppa/docs/en- US/online/ppa_operations_guide/70934.htm. 4. Assign provisioning attributes to the plans. The provisioning attribute is a tag that links a plan and nodes on which the services included in the plan can be set up. Learn more about attributes at http://download1.parallels.com/ppa/docs/en- US/online/ppa_operations_guide/70804.htm. 1. Prepare Source Servers Prepare the H-Sphere Control Panel Server PostgreSQL in H-Sphere is usually configured to accept only local connections. Thus, you need to do the following: 1. Reconfigure PostgreSQL to listen on any interface. Comment out the virtual_host setting in /var/lib/pgsql/data/postgresql.conf. 2. Change the PostgreSQL authentication settings to accept connections from the migration tool. Add a new line to /var/lib/pgsql/data/pg_hba.conf: host all all MIGRATION_TOOL_SERVER_IP 255.255.255.255 password where MIGRATION_TOOL_SERVER_IP is the IP address of the server on which the migration tool is installed. 3. Restart PostgreSQL: /etc/init.d/postgresql restart 4. Restart H-Sphere control panel: /etc/init.d/httpdcp restart

56 Transfer Scenario for H-Sphere 3.5 and Later Prepare the H-Sphere Windows Servers For each Windows-based server that you want to transfer, do the following: 1. Switch off H-Sphere s rsync service. To do this: a Edit the file C:\Program Files\HSphere\Config\hsphere.config and comment out all sections describing rsync. After commenting, these sections should look like: <!-- <section name= rsync type= Psoft.HSphere.Services.RSync.RSyncServiceInitializer location= Services.RSync, Version=3.5.9.4658, Culture=neutral, PublicKeyToken=null /> --> and <!-- <rsync> <service name= rsyncservice type= Psoft.HSphere.Services.RSync.RSyncService package= HsRSync location= Services.RSync, Version=3.5.9.4658, Culture=neutral, PublicKeyToken=null > <prop name= security value= stdsecurity description= Security object name /> <prop name= log value= rsynclog description= Logger object name /> <prop name= sessionmanager value= dimesessionmanager description= Session manager object name /> <prop name= quotaservice value= quotamanagerservice description= QuotaService object name /> </service> <logger name= rsynclog type= Psoft.HSphere.Logging.Logger package= HsRSync location= Psoft.HSphere, Version=3.5.282.4658, Culture=neutral, PublicKeyToken=null > <prop name= rotateperiod value= 168 description= Rotate period in hours /> <prop name= location value= C:\Program Files\HSphere\log\services\rsync\rsync.log description= Log file location /> <prop name= backupsnum value= 3 description= Backup files number /> <prop name= rotatetype value= 0 description= Type of rotation /> <prop name= rotatesize value= 1000000 description= Maximum size of logfile in bytes /> </logger> </rsync> --> b After saving your changes in this file, restart H-Sphere s agent. You can do it by running these two commands in Windows command line: net stop hsphere net start hsphere c By using the Windows Task Manager, end the process called rsync.exe.

2. Install the RsyncServer service. a Transfer Scenario for H-Sphere 3.5 and Later 57 Download the installer archive from http://autoinstall.plesk.com/panelmigrator/cwrsyncserver_4.0.5_installer.zip, unpack it, and install the RsyncServer service following the installer s instructions. b Update the Rsync Server configuration file rsyncd.conf with the strings given below. The file is located in the Rsync Server installation directory (C:\Program Files\ICW by default) uid = 0 gid = 0 hosts allow = <target_node1_ip_address>, <target_node2_ip_address>,... log file = rsyncd.log [vhosts] path = <cygwin path to hshome> read only = true transfer logging = yes c where <target_node1_ip_address>, <target_node2_ip_address>,... are the IP addresses of the Windows-based service nodes. <cygwin path to hshome> is the cygwin-style path to the directory containing IIS users home directories. The default path to this directory is C:\hshome, and the corresponding cygwin-style path is /cygwin/c/hshome Change the system settings and run the installed RsyncServer service: 1. Click Start > Administrative Tools > Services. 2. In the Properties of the RsyncServer service: 3. On the Log On tab, select Local System account for the Log on as setting. 4. On the General tab, change the Startup type to automatic, and start the service. 2. Configure the Tool Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains a template file called config.ini.hsphere.template that you can use as a basis for creating your own config.ini. To configure the tool: 1. Create the config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.hsphere.template config.ini 2. Edit the config.ini file to configure the tool. The description of file sections is provided below.

58 Transfer Scenario for H-Sphere 3.5 and Later The Structure of the Configuration File The config.ini file consists of several sections, which contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. The configuration file should also contain the [hsphere] section with the information about your H-Sphere server. Also, each section has a number of settings of two types: Mandatory. You must define these settings. Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file inside that setting s description. That description also has a commented line with the setting and its default value: if you want to change the value, uncomment that line and change the value in it. The meaning of each setting is described in the configuration template file. An Example of the Configuration File Let us take a look at the example of the config.ini file. In this example, we are going to transfer data from a single H-Sphere server. The PA installation in this example has webmail on a separate service node with IP address 192.168.0.1. [GLOBAL] source-type: hsphere [ppa] ip: 192.168.0.20 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [hsphere] ip: 192.168.0.200 ssh-username: root ssh-auth-type: password ssh-password: 123qwe db-port: 5432 db-name: hsphere db-user: wwwuser db-password: 1q2w3e

Transfer Scenario for H-Sphere 3.5 and Later 59 3. Generate a Transfer List A transfer list defines the list of objects (accounts and subscriptions) that should be migrated from the source H-Sphere server to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the generation, it contains all objects that are present on the source H-Sphere server. See the example below. To generate the transfer list, run the following command: # ppa-transfer generate-migration-list config.ini After you run the command, the tool will create a migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps. If the creation of the transfer list is interrupted because of errors, and an error report is shown, resolve the issues as described in the section 6. Perform the Migration (on page 63). Transfer List Structure After generation, the list contains all subscriptions that exist on source servers. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related. The list comprises a number of sections - one section per each reseller. The sections are marked with a line Reseller: Reseller s name. Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol. Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers subscriptions. Customer account names are marked with a line Customer: customer s name. By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list. Each subscription must be assigned to a customer. By default, administrator s subscriptions are assigned to a special customer called ppa-admin. Reseller s subscriptions are assigned to a special customer called ppa- <reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts. You can reassign all subscriptions (including the administrator s and resellers subscriptions) to any customers using the transfer list.

60 Transfer Scenario for H-Sphere 3.5 and Later Note: You can assign subscriptions to non-existent customers. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them. An Example of the List # The list of subscriptions # These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer. Customer: ppa-admin admins-subscription1.tld Customer: bobs customer1-subscription1.tld customer1-subscription2.tld # Administrator s service plans and subscriptions Plan: Gold hosting Customer: ppa-admin admins-subscription2.tld Customer: jacks customer2-subscription1.tld customer2-subscription2.tld Plan: Bronze hosting Plan: Silver hosting # Resellers Reseller: johns_123 # The subscriptions that are not assigned to a certain service plan. They must be moved to a section of a certain service plan of this reseller. Customer: ppa-johns_123 notassigned1.tld # Reseller s service plans Plan: Unlimited Customer: ppa-johns_123 # The subscriptions of this reseller reseller-subscription1.tld reseller-subscription2.tld # The customers of this reseller subscribed to this plan Customer: johndoe # The subscriptions of this customer reseller1-customer1-subscription1.tld Reseller: toms # Reseller s service plans Plan: Reseller Plan 2 # The customers of this reseller subscribed to this plan Customer: katie_23 # The subscriptions of this customer reseller2-customer1-subscription1.tld

Transfer Scenario for H-Sphere 3.5 and Later 61 4. Import Resellers to PA The ppa-transfer tool has the following limitation: It allows you to transfer reseller accounts to PA but it does not automatically transfer reseller plans. Therefore, to seamlessly import existing reseller accounts from your servers, you should first manually create reseller plans in PA that correspond to the ones on your servers, and subscribe the resellers to these plans after the transfer. See the detailed instructions below. To import resellers to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Edit the transfer list file migration-list (located in your session directory) to exclude reseller accounts that you do not want to transfer to PA. To exclude a certain account from transfer, comment out or delete the corresponding line from the list. The lines look like Reseller: <reseller s username>. 3. Perform the transfer of reseller accounts to the PA management node by running the command: # ppa-transfer import-resellers config.ini All resellers that exist in your hosting solution will be transferred to PA. 4. Subscribe the transferred resellers to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates. 5. Configure hosting service templates on behalf of the reseller. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

62 Transfer Scenario for H-Sphere 3.5 and Later 5. Associate Subscriptions from H-Sphere with Plans in PA In this step you should associate the subscriptions that are present on your H-Sphere server with the service plans you have created in PA in the previous step. This is done by adjusting the transfer list file. To associate subscriptions with service plans, edit the transfer file. The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions. Note that the tool will not start the transfer until there are subscriptions that are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding lines or delete them. Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the migration. For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan, move the corresponding line under the plan section. Before # Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting After Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob customer1-subscription1.tld Plan: Silver hosting

Transfer Scenario for H-Sphere 3.5 and Later 63 6. Perform the Migration Once all preparation steps are done, run the migration process by issuing the following command: ppa-transfer transfer-accounts config.ini.hsphere--migrationlist-file migration-list During the migration or transfer, all data from H-Sphere are saved to a backup. If there are settings or data that cannot be migrated because of database inconsistency, network connection problems, or other issues, the migration tool interrupts the migration process and shows a report with recommendations on how to resolve such issues. After seeing this report, you need to resolve the detected issues and restart the migration. If all issues are properly resolved, the migration will not be interrupted. If not all of the detected issues were resolved, but you still want to migrate the remainder of data, run the migration tool with the option--ignore-fetch-source-errors: ppa-transfer transfer-accounts config.ini.hsphere--migrationlist-file migration-list--ignore-fetch-source-errors In this case, only the subscriptions and accounts that do not have any issues will be migrated. When the migration is finished, a message similar to the following will be shown in the console: Report tree was saved in migrationsession/resellers_report_tree.<date and time> file. You can learn about the results of the migration process by viewing the contents of this file. Important: After migration is completed, modify the migrated sites so that they start using their databases hosted by PA. This will help you (1) ensure that the sites on the source server are not affected while the migrated sites are being tested on the destination server, and (2) ensure that the migrated sites remain operable after the source server is decommissioned. 7. Set Up DNS Forwarding To ensure that the migrated domains are resolved, issue the following command: ppa-transfer set-dns-forwarding config.ini--migration-list migration-list

64 Transfer Scenario for H-Sphere 3.5 and Later 8. Verify the Transferred Data To check the operability of web, mail, DNS, and FTP services for each transferred domain, issue the following command: ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command checks the following: Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check.

C H A P T E R 7 Transfer Scenario for PBAS Parallels Business Automation Standard is a billing solution that enables providers to sell hosting services from an arbitrary number of Panel servers. Transferring data from PBAS to PA implies that all subscriptions that exist on these servers are moved to PA service nodes. Other business objects such as plans, customer and reseller accounts are transferred to the PA management node and become synced with the corresponding PBAS objects. PBAS continues working as is with only difference that now it communicates (creates accounts, subscriptions, and so on) with the PA management node instead of a number of separate Panel servers (see the diagram for convenience).

66 Transfer Scenario for PBAS Resellers after the Transfer Unlike PA, resellers in PBAS are not subscribed to reseller plans (PBAS does not have such a plan type). Resellers are divided into two groups: those who have their dedicated Panel server and those who serve customers on shared servers. The main difference between the categories is in the payment model. While resellers with dedicated servers pay periodically for leasing their server, the second category of resellers pays for each subscription purchased by their customers. To keep the payment model intact, resellers of these two categories should be transferred in different ways. The recommended transfer scenario implies that you subscribe resellers with dedicated servers to separate PA reseller templates which guarantee the amount of resources equivalent to the ones provided by their former dedicated server. All the resellers using shared servers are subscribed to some common reseller template. In further sections, instructions for transferring these reseller categories will be given separately and designated by names Resellers on Dedicated Servers and Resellers on Shared Servers correspondingly. Important Notes The transfer is possible only from servers with Plesk 8 and later connected to PBAS. You can transfer only the subscriptions to the service plans of the Plesk Domain and Plesk Client types. After the transfer, DNS zones of the transferred domains located on the PBAS DNS server will be rewritten with the ones from PA. Therefore, all changes made to DNS records in PBAS will be lost after the transfer. Performing the Data Transfer The process of transferring hosting data from PBAS consists of the following steps: 1. Import plans (templates) to PA (on page 68). Service plans are not automatically registered in PA during transfer. Therefore, you should create your plans in PA manually. 2. Connect PA to PBAS (on page 68). In this step, you should register the PA management node in PBAS and create PBAS service plans connected with the PA templates (created in step 1). 3. Create the transfer data and configuration files (on page 70). After this step, you will get two files: The transfer data file (contains data about subscriptions that should be transferred to PA nodes) and the tool configuration file (defines server communication parameters). 4. Configure the ppa-transfer tool (on page 72). The tool is configured with the help of the configuration file created in step 4. This file defines various communication parameters such as like server IP addresses, the administrator s credentials, and so on.

Transfer Scenario for PBAS 67 5. Check for possible conflicts and limitations (on page 73). Before moving to PA, we recommend that you perform a preliminary check for possible transfer conflicts. For example, two different subscriptions on different Panels may have system users with the same name. Based on the check results, the tool generates a report with all found conflicts. 6. Install MySQL on IIS Web Server Nodes (Windows Servers) (on page 74). Panel for Windows provides support for MySQL databases while IIS-based web server nodes in PA do not. This means that to transfer customer databases, you should first add support for MySQL to a target IIS node. 7. Run the transfer process (on page 75). Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your Panel servers to PA nodes. 8. Finalize the transfer (on page 75). In this step, the system creates new PBAS subscriptions associated with the ones transferred to PA nodes. In addition, DNS zones in PBAS are updated with new servers IP addresses. In this chapter: 1. Import Plans to PA... 68 2. Connect PA to PBAS... 68 3. Generate the Transfer Data and Configuration Files... 70 4. Configure the Tool... 72 5. Check for Possible Conflicts... 73 6. Install MySQL on IIS Web Server Nodes (Windows Servers)... 74 7. Run Transfer... 75 8. Finalize Transfer... 75

68 Transfer Scenario for PBAS 1. Import Plans to PA As the ppa-assimilate tool does not perform the transfer of service plans to PA, you should create the corresponding service templates manually. In addition, if you served resellers through PBAS and want to transfer them to PA, you should also create one reseller template which will be used by all resellers. To import plans to PA from PBAS: 1. Log in to PA. 2. Create service templates in PA that correspond to hosting plans in PBAS (including the ones owned by resellers). For detailed instructions on how to do this, refer to the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 3. Assign provisioning attributes to the plans. The provisioning attribute is a tag that links a plan and nodes on which the services included in the plan can be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Setting Up Your Business Offer. Each Panel subscription includes support for a number of services, such as web hosting, mail services, and database services. The subscriptions from your hosting solution will be relocated to PA service nodes using the standard provisioning workflow: PA will match the attribute of a service with attributes of service nodes. If PA does not find a match, a subscription will not be relocated. You can assign attributes in the Administration Panel > Products > Service Templates > select a template > Resources > select a resource > Provisioning Attributes. 4. For resellers on shared servers, create a reseller template in PA which will be used by all of the transferred resellers. For detailed instructions on how to do this, refer to the Plesk Automation: Operations Guide, section Creating Reseller Templates. Note: You can create a template with only one resource type - Client accounts. 5. For resellers on dedicated servers, create reseller templates in PA which will include all resources for hosting subscriptions, plus the Client account resource. Set the limit on all included resources (except Disk space) to Unlimited. As for Disk space, you can set it to unlimited or to an actual amount that your new dedicated server provides. For detailed instructions on how to do this, refer to the Plesk Automation: Operations Guide, section Creating Reseller Templates. 2. Connect PA to PBAS To be able to sell PA services through PBAS, you should connect the PA management node to your PBAS instance and create service plans linked to the PA templates. These service plans will represent corresponding PA templates in PBAS. Thus, when a customer subscribes to a plan in PBAS, PA will create a subscription to the template linked with this plan.

Transfer Scenario for PBAS 69 To connect PA to PBAS: 1. Log in to PA as the administrator. 2. Set the following system settings in System > Settings > System Properties: Ability to add domains from customer CP - Enabled. Domain registrar status default value - Ready. Allow using of several dots in domain name - Enabled. Allow to move domains between subscriptions - Disabled. Customers management from POA UI - Disabled. IDN Domains Support - Enabled. Ability to remove domains from customer CP - Disabled. 3. Allow access to PA Public API from the PBAS server by adding the server s IP address to System > Settings > Public API > Allowed Networks. 4. Log in to PBAS as the administrator. 5. Register the PA management node by running Service Director > Parallels Automation Manager > Nodes > New Node. When setting the Reseller Service Template parameter, specify the reseller template you created in step 3 of 1. Import Plans to PA (on page 68). This reseller template will be used for all resellers on shared servers. 6. Wait until the list of service templates from PA is propagated to PBAS. You can check the list at Service Director > Parallels Automation Manager > Service Templates. 7. For each PA service template (excluding the ones owned by resellers on dedicated servers), create the corresponding service plan in Billing Director > Product Manager > Hosting Plans > New Hosting Plan. You will be prompted to provide a number of plan options: In Select a Plan Type step, set POA as the plan type. When specifying PA nodes, choose your PA management node. In Service Templates step, specify the PA service template that corresponds to the created plan. 8. For each reseller on shared servers: 1. Log in to PBAS on behalf of a certain reseller using Account Director > Reseller Manager > Resellers > select the reseller > Login to RCC. 2. Create plans by copying those hosting plans (created in step 4) that correspond to the former reseller s plans. You can do this in Billing Director > Product Manager > Hosting Plans > New Hosting Plan > Create a copy of the Provider s existing hosting plan. 9. For each reseller on dedicated servers: 1. Subscribe each reseller to the corresponding reseller plan created in step 4 of 1. Import Plans to PA (on page 68). Important: This operation can be done by the reseller representative only. They should subscribe to the plan through the PBAS online store. 2. Log in to PBAS on behalf of a certain reseller using Account Director > Reseller Manager > Resellers > select the reseller > Login to RCC.

70 Transfer Scenario for PBAS 3. For each PA service template that corresponds to former reseller s plan, create a service plan in Billing Director > Product Manager > Hosting Plans > New Hosting Plan. You will be prompted to provide a number of plan options: In Select a Plan Type step, set POA as the plan type. When specifying PA nodes, choose your PA management node. In Service Templates step, specify the PA service template that corresponds to the created plan. 10. Log in to PA as the administrator. 11. For the DNS resource type in Products > Resources > DNS > Activation Parameters tab > Edit, set the First nameserver parameter to the PBAS server. This means that all DNS zones will be managed by the PBAS DNS server (by default they are managed by the PA DNS server). Note: By default, the DNS resource type is included in all shared hosting templates. If you use another resource type for DNS services, perform the step for this type. 3. Generate the Transfer Data and Configuration Files In this step, you create two files needed to complete the transfer to PPA: A transfer data file. This is an XML file that defines the list of transferred subscriptions and specifies new plans (created on the previous step 3. Connect PA to PBAS (on page 68)) for them. A transfer configuration file. This file contains various communication parameters such as IP addresses of all involved servers, administrator credentials, and so on. Both files are created with the help of the plesk_to_ppa_migrate.pl tool which is a part of the PBAS distribution. To generate the transfer data and configuration files: 1. Log in to your PBAS server over SSH as root. 2. Generate a transfer list file: plesk_to_ppa_migrate.pl -prepare-migration The tool will generate the migration_list.txt file. 3. Configure the transfer process by editing the migration_list.txt file. This file is used to map the plans (created in the previous step 3. Connect PA to PBAS (on page 68)) and the former PBAS plans used for subscriptions you want to transfer. It also allows you to set the exact list of subscriptions to transfer. The example of the file with comments is given below: # Plan mapping. The plans are grouped by owners - the provider and resellers.

Transfer Scenario for PBAS 71 # In this section, define the mapping between former plans used for transferred subscriptions and new plans (connected to PA) with which the subscriptions should be associated after the transfer. Each line in this section should contain the former plan s Series Key and new plan s ID separated by the -> symbol. # Note that for the former plans, the tool automatically takes plans with the latest ID based on their Series Key. # Provider 7 (Plesk Domain)-> 16 12 (Plesk Client 11)-> 20 14 (Plesk Client 9)-> 20 16 (Plesk Domain 9)-> 20 # reseller John Doe 37 (Plesk Domain 3 res)-> 21 38 (Plesk Domain 2 res)-> 22 # The list of subscriptions to transfer. If you don t want to transfer a certain subscription either remove it from this list or comment it out with #. # Provider 2; customer-domain-plesk.tst # pbas customer 3; customer-domain2-plesk.tst # pbas customer # reseller John Doe 6; example1.tst 9; example2.tst 4. Generate the transfer data and configuration files: plesk_to_ppa_migrate.pl -start-migration -migrationfile=migration_list.txt After completing this step, the plesk_to_ppa_migrate.pl tool will generate two files: migration_data.xml - the transfer data file. config.ini - the configuration file. Note: After this step, the tool will also transfer customer and reseller accounts (owners of the transferred subscriptions) from PBAS to PA.

72 Transfer Scenario for PBAS 4. Configure the Tool Since the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which was created in the previous step 5. Generate the Transfer Data and Configuration Files (on page 70). To configure the tool: 1. Copy the config.ini and migration_data.xml files you created in the previous step from the PBAS server to the server where the ppa-transfer tool is located. 2. Edit the config.ini file to configure the tool. The description of file sections is provided below. The Structure of the Configuration File The config.ini file consists of several sections of two types: Predefined. These sections contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. Custom. These sections contain information about your existing servers connected to PBAS. You can use arbitrary names for such sections. For example, [plesk1], [plesk2], and so on. Note: The major part of the parameters in the file is already set. Typically, all you have to do is specify authentication settings such as passwords and authentication type. For the meaning of these parameters, their possible values, and for information about other supported parameters, see the configuration template file /etc/ppamigrator/config.ini.pbas.template. An Example of the Configuration File Let us take a look at the example of the config.ini file. In this example, we are going to transfer data from two Panel servers. The PA installation in this example has webmail on a separate service node with IP address 192.168.0.21. [GLOBAL] source-type: pbas pbas-data-file: migration_data.xml source-plesks: plesk1, plesk2 [ppa] ip: 10.52.71.64 panel-username: admin panel-password: setup ssh-username: root

Transfer Scenario for PBAS 73 ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [plesk1] ip: 10.50.51.194 os: unix panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe [plesk2] ip: 192.168.0.102 os: windows panel-username: admin panel-password: setup1q windows-username: Administrator windows-password: 123qweQWE 5. Check for Possible Conflicts Before performing a transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppa-transfer tool and includes a number of checks concerning various aspects of hosting panels functionality, such as usernames of accounts staff members, DNS hosting type, and other. To perform the preliminary check: $ ppa-transfer check config.ini Based on the check results, the tool generates a report. The report contains messages of two types: WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when a certain issue blocks the transfer. You must resolve all issues marked as ERROR before performing the transfer.

74 Transfer Scenario for PBAS 6. Install MySQL on IIS Web Server Nodes (Windows Servers) While Plesk for Windows provides support for MySQL databases, IIS-based web server nodes in PA do not do that. This means that before transferring customer databases from Windows-based Plesk servers, you should first add support for MySQL to the target node. To add support for MySQL on the target IIS web server node: 1. Obtain the MySQL 5.1 distribution package and install it following the installation instructions. 2. Add the MySQL installation directory to the PATH environment variable. 3. Restart the PEM service by running the following commands on behalf of the Windows administrator: net stop pem net start pem

Transfer Scenario for PBAS 75 7. Run Transfer Once all preparation steps are completed, you can run the transfer process: 1. Run the transfer: ppa-transfer transfer-accounts config.ini The tool performs the transfer of your hosting data to certain service nodes. 2. Test the transferred domains: ppa-transfer test-all config.ini--skip-dns-forwarding-test 3. If any issues were found by the tool, resolve them and re-run the command in the previous step to verify they are resolved. The tool does not require you to resolve all of these issues. You can resolve only the important ones. Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example: ppa-transfer test-all config.ini--skip-dns-forwarding-test-- migration-list-file migration-session/successfulsubscriptions.1385955582.55 Note: In this step, DNS zone files on the PBAS DNS server are not yet updated with new IP addresses of Panel servers. 8. Finalize Transfer Once the data transfer is completed, you should finalize the transfer process. During finalization, the plesk_to_ppa_migrate.pl tool will perform the following operations: New PBAS subscriptions will be created and associated with the ones transferred to PA nodes. Formerly used PBAS subscriptions will be put on hold. DNS zone files on the PBAS DNS server will be updated with the IP addresses of PA service nodes. To finalize the transfer: 1. Log in to the PBAS server over SSH as root. 2. Run finalization with the following command: plesk_to_ppa_migrate.pl -finalize-migration -data-file migration_data.xml 3. Ensure that DNS propagation has ended. This means that you should wait for the period of time which is equal to the sum of TTL and SOA refresh interval.

76 Transfer Scenario for PBAS 4. Verify that the data were transferred successfully by issuing the following command: ppa-transfer test-all config.ini 5. Copy the content that could be added by your customers during the transfer process from your source servers. To do this, log in to the server with the ppa-transfer tool as root and run the following commands: To copy mail content: ppa-transfer copy-mail-content config.ini To copy website content: ppa-transfer copy-content config.ini To copy databases: ppa-transfer copy-db-content config.ini 6. Check that the transfer completed successfully by issuing the command ppa-transfer test-all config.ini--skip-dns-forwarding-test. The test-all command checks the following: Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. 7. Remove the rsync software from Windows service nodes.

C H A P T E R 8 Transfer Scenario for Helm 3 The transfer of hosting data requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Mapping of Business Objects In Helm Admin Reseller Package Domain User Hosting plan In PA Provider Reseller Subscription Domain Customer Service plan

78 Transfer Scenario for Helm 3 Migration of the following hosting features and settings is supported: Resellers Reseller account details Extra features DNS settings Users User account details Domains Website content Forwarding domains and domains without hosting Mail POP3 accounts Mail content Forwarders Catch-all Multi-recipient addresses FTP accounts Databases Users Content MIME types ODBC DSNs DNS records Subdomains Domain aliases Web settings Virtual directories Web scheduler tasks Known Limitations for Transfers from Helm Migration of the following items is not supported: Secure folders ColdFusion FrontPage Statistics

Domain registrars Transfer Scenario for Helm 3 79 Custom error pages The following items are not migrated for forwarding domains: Scripting settings (ASP.NET, PHP, and so on) Website settings (app pool isolation, and so on) Secure folders Virtual directories Subdomains MIME types Limitations: FTP accounts and databases from all package domains are migrated to subscriptions. PHP 4 and PHP 5 limits are merged. ASP.NET 1 and ASP.NET 2 limits are merged. Some Helm limits are turned to permissions. PA does not support MS Access databases, therefore such databases will not appear in the databases list after migration. However, database files (*.mdb) will be migrated as part of private site content. You can use them directly from your applications or create ODBC DSNs for them. If you already have ODBC DSN records for the databases in Helm, they will be migrated to PA. Virtual directories of the URL redirect type are not migrated. All domains in a Plesk subscription share one IP address. Known issues: PA does not support URLs in scheduled tasks. Virtual directories of the URL redirect type are not migrated. Performing the Data Transfer The process of transferring hosting data consists of the following steps: 1. Prepare source servers for migration. 2. Configure the ppa-transfer tool. The tool is configured with the help of a configuration file. It defines various communication parameters such as server IP addresses, the administrator s credentials, and so on. 3. Import resellers to PA. The ppa-transfer tool does not fully automate the transfer of resellers to PA: It automatically transfers reseller accounts, however, you need to manually configure these accounts and reseller plans before transferring resellers customers and domains. 4. Import plans (templates) to PA. Service plans are not automatically registered in PA during transfer. Therefore, you should either create your plans in PA manually or use the ppa-transfer tool for this purpose. 5. Create a transfer list.

80 Transfer Scenario for Helm 3 A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers. 6. Associate subscriptions and plans. Associate subscriptions with certain imported plans. 7. Check for possible conflicts and limitations. Before moving to PA, we strongly recommend that you perform a preliminary check for possible transfer conflicts. Based on the check results, the tool generates a report with all detected conflicts. 8. Run the transfer process. Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes. 9. Redirect DNS to the new servers. After DNS services are relocated to PA, you need to update all your NS records on the registrar s DNS servers with the IP address of your PA DNS server. 10. Verify that the data were transferred correctly. The operability of Web, mail, DNS, and FTP services for each transferred domain is checked. 11. Finalize the synchronization of content. Ensure that any changes to the content made by your customers during the transfer process are transferred as well. In this chapter: 1. Prepare Source Servers... 81 2. Configure the Tool... 82 3. Import Resellers to PA... 84 4. Import Plans to PA... 85 5. Generate a Transfer List... 85 6. Associate Subscriptions from Helm with Plans in PA... 87 7. Check for Possible Conflicts... 88 8. Run Transfer... 89 9. Redirect DNS to the New Servers... 90 10. Verify the Transferred Data... 90 11. Finalize the Synchronization of Content... 91

Transfer Scenario for Helm 3 81 1. Prepare Source Servers The Helm Control Panel Server s database is usually configured to accept only local connections. You need to switch on remote connections on the instance of SQL Server 2005/2008 and switch on the SQL Server Browser service. To do this, use the SQL Server 2005/2008 Surface Area Configuration tool. The Surface Area Configuration tool is installed during the installation of SQL Server 2005/2008. To switch on remote connections for the Helm database: 1. Go to Start > Programs > Microsoft SQL Server 2005/2008 > Configuration Tools > SQL Server Surface Area Configuration. 2. Click Surface Area Configuration for Services and Connections. 3. Expand Database Engine, click Remote Connections, click Local and remote connections, click the appropriate protocol that should be enabled for your environment, and then click Apply. 4. Click OK when you receive the following message: Changes to Connection Settings will not take effect until you restart the Database Engine service. 5. In Surface Area Configuration for Services and Connections, expand Database Engine, click Service, click Stop, wait until the MSSQLSERVER service stops, and then click Start to restart the MSSQLSERVER service.

82 Transfer Scenario for Helm 3 2. Configure the Tool As the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains a template file called config.ini.helm3.template that you can use as a basis for creating your own config.ini. To configure the tool: 1. Create a config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.helm3.template config.ini 2. Edit the config.ini file to configure the tool. The description of file sections is provided below. The Structure of the Configuration File The config.ini file consists of several sections, which contain information about your target management node and various aspects of data transfer. The names of the sections [GLOBAL], [ppa], and [helm3] are predefined by the tool and you should not change them. Each section has a number of settings of two types: Mandatory. You must define these settings. Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file, in the setting s description. That description also has a commented line with the setting and its default value: if you want to change a value, uncomment that line and change the value in it. The meaning of each setting is described in the configuration template file. An Example of the Configuration File Let us take a look at the example of the config.ini file. In this example, we are going to transfer data from a single Helm server. The PA installation in this example has webmail on a separate service node with IP address 192.168.0.1. [GLOBAL] source-type: helm3 source-helms: helm3, helm3-remote-server [ppa] ip: 192.168.0.20 panel-username: admin panel-password: setup ssh-username: root ssh-auth-type: password

Transfer Scenario for Helm 3 83 ssh-password: password webmail-ip: 192.168.0.21 [helm3] ip: 192.168.0.200 windows-username: Administrator windows-password: password copy-mail-content: messages db-user: sa db-password: password [helm3-remote-server] ip: 192.168.0.201 windows-username: Administrator windows-password: password

84 Transfer Scenario for Helm 3 3. Import Resellers to PA The ppa-transfer tool has the following limitation: It allows you to transfer reseller accounts to PA but it does not automatically transfer reseller plans. Therefore, to seamlessly import existing reseller accounts from your servers, you should first manually create reseller plans in panel that correspond to the ones on your servers, and subscribe the resellers to these plans after the transfer. See the detailed instructions below. To import resellers to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Generate a transfer list file called migration-list, by issuing the following command: # ppa-transfer generate-migration-list config.ini 3. Edit the transfer list file migration-list (located in your session directory) to exclude reseller accounts that you do not want to transfer to PA. To exclude a certain account from transfer, comment out or delete the corresponding line from the list. The lines look like Reseller: <reseller s username>. 4. Perform the transfer of reseller accounts to the PA management node by running the command: # ppa-transfer import-resellers config.ini All reseller accounts that are present in your hosting solution will be transferred to PA. 5. Subscribe the transferred resellers to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates. 6. Configure hosting service templates on behalf of the reseller. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

Transfer Scenario for Helm 3 85 4. Import Plans to PA The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually. To import plans to PA: 1. Create service plans (templates) in PA that correspond to hosting plans on your Panel servers. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 2. Configure subscription provisioning by assigning proper provisioning attributes to the templates. The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers. 5. Generate a Transfer List A transfer list defines the list of objects (accounts and subscriptions) that should be transferred from the source Helm server to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the generation, it contains all objects that are present on the source Helm server (see the example below). To generate the transfer list, run the following command: # ppa-transfer generate-migration-list config.ini After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini file. You will need this file during the subsequent transfer steps. Transfer List Structure After generation, the list contains all subscriptions that are present on source servers. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related. The list comprises a number of sections - one section per each reseller. The sections are marked with the line Reseller: Reseller s name. Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with the line Plan: Plan name. Note that plan names cannot contain the # symbol.

86 Transfer Scenario for Helm 3 Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers subscriptions. Customer account names are marked with the line Customer: customer s name. By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list. If a customer does not have any domains, or has a domain with disabled web and FTP services, the migration tool creates a subscription with a name like <customer_package_name>.package. Each subscription must be assigned to a customer. By default, administrator s subscriptions are assigned to a special customer account called ppa-admin. Reseller s subscriptions are assigned to a special customer account called ppa- <reseller_username>. If such customer accounts are already present in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts. You can reassign all subscriptions (including the administrator s and resellers subscriptions) to any customers using the transfer list. Note: You can assign subscriptions to non-existent customer accounts. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them. An Example of the List # The list of subscriptions # These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer. # Administrator s service plans and subscriptions Plan: Bronze hosting Plan: Silver hosting # Resellers Reseller: johns_123 # The subscriptions that are not assigned to a certain service plan. They must be moved to a section of a certain service plan of this reseller. Customer: ppa-johns_123 notassigned1.tld # Reseller s service plans Plan: Unlimited Customer: ppa-johns_123 # The subscriptions of this reseller reseller-subscription1.tld reseller-subscription2.tld # The customers of this reseller subscribed to this plan Customer: johndoe # The subscriptions of this customer reseller1-customer1-subscription1.tld Reseller: toms # Reseller s service plans Plan: Reseller Plan 2

# The customers of this reseller subscribed to this plan Customer: katie_23 # The subscriptions of this customer reseller2-customer1-subscription1.tld Transfer Scenario for Helm 3 87 6. Associate Subscriptions from Helm with Plans in PA In this step, you should associate the subscriptions that are present on your Helm server with the service plans you have created in PA in the previous step. This is done by adjusting the transfer list file. To associate subscriptions with service plans, edit the transfer list file. The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions. Note that the tool will not start the transfer until there are subscriptions that are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding lines or delete them. Note: All plans from the list must be present in PA. Otherwise, the tool will be unable to complete the migration. For example, to associate a custom subscription called admins-subscription.tld with the Gold hosting plan, move the corresponding line under the plan section. Before # Custom subscriptions Customer: ppa-admin admins-subscription.tld After Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting

88 Transfer Scenario for Helm 3 7. Check for Possible Conflicts Before performing the transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppatransfer tool and includes a number of checks concerning various aspects of hosting panels functionality. Below we describe the most important checks that may require your attention: Check for customer / reseller accounts with the same e-mails and contact names. There are three account parameters that the tool uses to identify an account: username, e-mail, and contact name. Let s take a closer look at how the system behaves when these parameters match for different accounts: Usernames, e-mails, and contact names are the same. The system considers such accounts to represent the same person or company: Only one of them will be transferred to PA. The priority is given to the account from the panel that is listed first in the sources string of config.ini. Accounts from other panels are ignored: Their subscriptions are also registered in PA, but these subscriptions become associated with the customer / reseller account which had the priority during the transfer. If you want each of such accounts to be transferred to PA, specify other e-mail and username for conflicting accounts. Usernames and contact names are the same, e-mails are different. The move to PA will be impossible until you specify another username for conflicting accounts. Usernames and e-mails are the same, contact names are different. The move to PA will be impossible until you specify the same contact names (if these are the same persons) for conflicting accounts. E-mails are the same, usernames and contact names are different. The move to PA will be impossible until you specify other e-mails for conflicting accounts. To perform the preliminary check: ppa-transfer check config.ini Based on the check results, the tool generates a report. The report contains messages of two types: WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when a certain issue blocks the transfer. You must resolve all issues marked as ERROR before performing the transfer.

Transfer Scenario for Helm 3 89 8. Run Transfer Once all preparation steps are done, you can run the transfer process. To run the transfer: 1. Issue the following command: ppa-transfer transfer-accounts config.ini The tool performs the transfer of your hosting data to certain service nodes. 2. Test the transferred domains: ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that. 3. If any issues were found by the tool, resolve them and re-run the command in step 2 to verify they are resolved. The tool does not require you to resolve all of these issues. You can resolve only the important ones. Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example: ppa-transfer test-all config.ini--skip-dns-forwarding-test-- migration-list-file migration-session/successfulsubscriptions.1385955582.55

90 Transfer Scenario for Helm 3 9. Redirect DNS to the New Servers As the DNS service is relocated to the PA DNS server, you should update all your NS records on the registrar s DNS server with the IP addresses of your PA DNS servers. Also, make sure that DNS propagation has ended. This means that you should wait for the period of time which is equal to the sum of TTL and SOA refresh interval. 10. Verify the Transferred Data To check the operability of Web, mail, DNS, and FTP services for each transferred domain: ppa-transfer test-all config.ini--skip-dns-forwarding-test After you run the command, the tool will report the results of the check. The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check.

Transfer Scenario for Helm 3 91 11. Finalize the Synchronization of Content To complete the synchronization of content between the source and the destination servers, do the following: 1. Copy the content that could be added by your customers during the transfer process from your source servers. To copy mail content: ppa-transfer copy-mail-content config.ini To copy website content: ppa-transfer copy-content config.ini To copy databases: ppa-transfer copy-db-content config.ini In this step, the tool will update the content of the transferred subscriptions with any changes that were made during the transfer. Note that the tool makes a full copy of databases (as opposed to mail and web content where only new content is copied), which may require significant time. 2. Check that the transfer completed successfully by issuing the command ppa-transfer test-all config.ini--skip-dns-forwarding-test. The test-all command checks the following: Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check.

C H A P T E R 9 Transfer Scenario for Helm 4.2.2 The transfer of hosting data requires you to have a working PA environment with service nodes that can be used as a replacement for your existing servers: All hosting data are transferred to particular PA nodes. Mapping of Business Objects In Helm Admin Customer with Account Role Reseller Domain Customer with Account Role User Account Login Plan In PA Provider Reseller Subscription Customer User Service Template

Transfer Scenario for Helm 4.2.2 93 Migration of the following hosting features and settings is supported: Database Service: Microsoft SQL Server Microsoft SQL Server 2005 Microsoft SQL Server 2008 MySQL 4 MySQL 5 FTP Service Microsoft FTP Mail Service SmarterMail Web Service: Microsoft IIS 5/6 Microsoft IIS 7 Domain Aliases Sub Domains Default Docs Scripting Support Virtual Directories MIME Types Custom Error Pages Email Accounts (POP3) Mail Aliases. Note that unlike in PA, aliases in Helm may refer to any email address. Thus, they are migrated as mail forwarders. Known Limitations for Transfers from Helm Migration of the following items is not supported: DNS records are not migrated from Helm. Instead, PA creates new zone definitions based on its own DNS zone template. You can pre-configure the DNS template from PA administration panel. ASP.NET 1.1 is not supported. Sites using ASP.NET 1.1 will have to work with ASP.NET 2.0 after transfer. Please consider this when checking the transferred sites. Parked domains. PA does not support parked domain. Thus, parked domains are migrated to domains without web hosting service. After migration, database users will have the database administrator privileges. The privileges of database users that were granted before migration are not restored.

94 Transfer Scenario for Helm 4.2.2 Known Problems Domains with suspended web service are migrated as suspended domains. FTP user permissions are not restored. Performing the Data Transfer The process of transferring hosting data consists of the following steps: 1. Prepare source servers. (on page 95) Prepare source servers for migration. 2. Configure the ppa-transfer tool. (on page 96) The tool is configured with the help of a configuration file. It defines various communication parameters such as server IP addresses, the administrator s credentials, and so on. 3. Import resellers to PA. (on page 98) The ppa-transfer tool does not fully automate the transfer of resellers to PA: It automatically transfers reseller accounts while you need to manually configure these accounts and reseller plans before transferring resellers customers and domains. 4. Import plans (templates) to PA. (on page 99) Service plans are not automatically registered in PA during transfer. Therefore, you should either create your plans in PA manually or use the ppa-transfer tool for this purpose. 5. Create a transfer list. (on page 100) A transfer list is a file that specifies what objects (plans, reseller accounts, and subscriptions) should be transferred to PA from source servers. 6. Associate subscriptions and plans. (on page 102) Associate subscriptions with certain imported plans. 7. Check for possible conflicts and limitations. (on page 103) Before moving to PA, we strongly recommend that you perform a preliminary check for possible transfer conflicts. Based on the check results, the tool generates a report with all detected conflicts. 8. Run the transfer process. (on page 104) Once all preparation steps are completed, you can run the transfer. In this step, the tool transfers all subscriptions from your existing servers to registered PA service nodes. 9. Redirect DNS to the new servers. (on page 105) After DNS services are relocated to PA, you need to update all your NS records on the registrar s DNS servers with the IP address of your PA DNS server. 10. Verify that the data were transferred correctly. (on page 105) The operability of web, mail, DNS, and FTP services for each transferred domain is checked. 11. Finalize the synchronization of content. (on page 106) Ensure that any changes to the content made by your customers during the transfer process are transferred as well.

Transfer Scenario for Helm 4.2.2 95 In this chapter: 1. Prepare Source Servers... 95 2. Configure the Tool... 96 3. Import Resellers to PA... 98 4. Import Plans to PA... 99 5. Generate a Transfer List... 100 6. Associate Subscriptions from Helm with Plans in PA... 102 7. Check for Possible Conflicts... 103 8. Run Transfer... 104 9. Redirect DNS to the New Servers... 105 10. Verify the Transferred Data... 105 11. Finalize the Synchronization of Content... 106 1. Prepare Source Servers The Helm Control Panel Server s database is usually configured to accept only local connections. You need to switch on remote connections on the instance of SQL Server 2005/2008 and to switch on the SQL Server Browser service. To do this, use the SQL Server 2005/2008 Surface Area Configuration tool. The Surface Area Configuration tool is installed during the installation of SQL Server 2005/2008. To switch on remote connections for the Helm database: 1. Go to Start > Programs > Microsoft SQL Server 2005/2008 > Configuration Tools > SQL Server Surface Area Configuration. 2. Click Surface Area Configuration for Services and Connections. 3. Expand Database Engine, click Remote Connections, click Local and remote connections, click the appropriate protocol that should be enabled for your environment, and then click Apply. 4. Click OK when you receive the following message: Changes to Connection Settings will not take effect until you restart the Database Engine service. 5. In Surface Area Configuration for Services and Connections, expand Database Engine, click Service, click Stop, wait until the MSSQLSERVER service stops, and then click Start to restart the MSSQLSERVER service.

96 Transfer Scenario for Helm 4.2.2 2. Configure the Tool As the ppa-transfer tool communicates with a number of servers, you should provide it with server IP addresses, administrators credentials, and other information. The tool is configured with the help of the config.ini file, which is not created by default. For your convenience, the directory /etc/ppa-migrator/ contains a template file called config.ini.helm.template that you can use as a basis for creating your own config.ini. To configure the tool: 1. Create a config.ini file based on the template. For example: cp /etc/ppa-migrator/config.ini.helm.template config.ini 2. Edit the config.ini file to configure the tool. The description of file sections is provided below. The Structure of the Configuration File The config.ini file consists of several sections, which contain information about your PA management node and various aspects of data transfer. The names of the sections [GLOBAL] and [ppa] are predefined by the tool and you should not change them. The configuration file should also contain a [helm] section with information about your Helm server. Each section has a number of settings of two types: Mandatory. You must define these settings. Optional. You do not have to define these settings. The value that will be assumed when you do not define a setting is specified in the configuration template file, in the setting s description. That description also has a commented line with the setting and its default value: if you want to change a value, uncomment that line and change the value in it. The meaning of each setting is described in the configuration template file. An Example of the Configuration File Let us take a look at the example of the config.ini file. In this example, we are going to transfer data from a single Helm server. The PA installation in this example has webmail on a separate service node with IP address 192.168.0.1. [GLOBAL] source-type: helm [ppa] ip: 192.168.0.20 panel-username: admin

Transfer Scenario for Helm 4.2.2 97 panel-password: setup ssh-username: root ssh-auth-type: password ssh-password: 123qwe webmail-ip: 192.168.0.21 [helm] ip: 192.168.0.200 windows-username: Administrator windows-password: password db-instance-name: HELM db-port: 1433 db-name: Helm4DB db-user: sa db-password: password

98 Transfer Scenario for Helm 4.2.2 3. Import Resellers to PA The ppa-transfer tool has the following limitation: It allows you to transfer reseller accounts to PA but it does not automatically transfer reseller plans. Therefore, to seamlessly import existing reseller accounts from your servers, you should first manually create reseller plans in PA that correspond to the ones on your servers, and subscribe the resellers to these plans after the transfer. See the detailed instructions below. To import resellers to PA: 1. Create reseller plans (templates) in PA that correspond to reseller plans (templates) in your hosting solution. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Reseller Service Templates. 2. Generate a transfer list file called migration-list, by issuing the following command: # ppa-transfer generate-migration-list config.ini 3. Edit the transfer list file migration-list (located in your session directory) to exclude reseller accounts that you do not want to transfer to PA. To exclude a certain account from transfer, comment out or delete the corresponding line from the list. The lines look like Reseller: <reseller s username>. 4. Perform the transfer of reseller accounts to the PA management node by running the command: # ppa-transfer import-resellers config.ini All resellers that exist in your hosting solution will be transferred to PA. 5. Subscribe the transferred resellers to the newly created reseller plans. Learn how to do this in the Plesk Automation: Operations Guide, section Subscribing Resellers to Templates. 6. Configure hosting service templates on behalf of the reseller. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates.

Transfer Scenario for Helm 4.2.2 99 4. Import Plans to PA The ppa-transfer tool does not perform the transfer of service plans to PA. Therefore, you should do this manually. To import plans to PA: 1. Create service plans (templates) in PA that correspond to hosting plans on your Panel servers. Learn how to do this in the Plesk Automation: Operations Guide, section Creating Shared Hosting Templates. 2. Configure subscription provisioning by assigning proper provisioning attributes to the templates. The provisioning attribute is a tag that links a plan and nodes on which the services included into the plan should be set up. Learn more about attributes in the Plesk Automation: Operations Guide, chapter Customers and Resellers.

100 Transfer Scenario for Helm 4.2.2 5. Generate a Transfer List A transfer list defines the list of objects (accounts and subscriptions) that should be transferred from the source Helm server to PA. The transfer list file can be automatically generated by the ppa-transfer tool. By default, after the generation, it contains all objects that are present on source Helm server (see the example below). To generate the transfer list, run the following command: # ppa-transfer generate-migration-list config.ini After you run the command, the tool will create the migration-list file in the session directory defined in your config.ini. You will need this file during further transfer steps. Transfer List Structure After generation, the list contains all subscriptions that exist on source servers. In addition, the file contains plans, reseller and customer accounts to which the subscriptions are related. The list comprises a number of sections - one section per each reseller. The sections are marked with a line Reseller: Reseller s name. Each section consists of a number of subsections - one subsection per each service plan of the reseller. These subsections are marked with a line Plan: Plan name. Note that plan names cannot contain the # symbol. Each plan subsection contains a list of customer accounts subscribed to that plan, and the domain names of the customers subscriptions. Customer account names are marked with a line Customer: customer s name. By default, customer accounts are listed below the corresponding reseller accounts. You can move the customer account to other resellers, including the administrator, using the transfer list. Each subscription must be assigned to a customer. By default, administrator s subscriptions are assigned to a special customer called ppa-admin. Reseller s subscriptions are assigned to a special customer called ppa- <reseller_username>. If such customer accounts already exist in PA, the migration tool will transfer subscriptions without checking whether the subscriptions belong to those accounts. You can reassign all subscriptions (including the administrator s and resellers subscriptions) to any customers using the transfer list. Note: You can assign subscriptions to non-existent customers. In such a case, the migration tool will create the corresponding customer accounts in PA (without any personal information prefilled) and will transfer subscriptions to them.

Transfer Scenario for Helm 4.2.2 101 An Example of the List # The list of subscriptions # These subscriptions must be moved to a section of a certain service plan. Otherwise, the tool will not start transfer. Customer: ppa-admin admins-subscription1.tld Customer: bobs customer1-subscription1.tld customer1-subscription2.tld # Administrator s service plans and subscriptions Plan: Gold hosting Customer: ppa-admin admins-subscription2.tld Customer: jacks customer2-subscription1.tld customer2-subscription2.tld Plan: Bronze hosting Plan: Silver hosting # Resellers Reseller: johns_123 # The subscriptions that are not assigned to a certain service plan. They must be moved to a section of a certain service plan of this reseller. Customer: ppa-johns_123 notassigned1.tld # Reseller s service plans Plan: Unlimited Customer: ppa-johns_123 # The subscriptions of this reseller reseller-subscription1.tld reseller-subscription2.tld # The customers of this reseller subscribed to this plan Customer: johndoe # The subscriptions of this customer reseller1-customer1-subscription1.tld Reseller: toms # Reseller s service plans Plan: Reseller Plan 2 # The customers of this reseller subscribed to this plan Customer: katie_23 # The subscriptions of this customer reseller2-customer1-subscription1.tld

102 Transfer Scenario for Helm 4.2.2 6. Associate Subscriptions from Helm with Plans in PA In this step, you should associate the subscriptions that are present on your Helm server with the service plans you have created in PA in the previous step. This is done by adjusting the transfer list file. To associate subscriptions with service plans, edit the transfer file. The association is performed by placing the corresponding subscription line under a certain plan section, or placing a line describing a plan (Plan: <plan name>) above the lines describing subscriptions. Note that the tool will not start the transfer until there are subscriptions that are not associated with plans. If you do not want to associate certain subscriptions with plans, comment out the corresponding lines or delete them. Note: All plans from the list must exist in PA. Otherwise, the tool will be unable to complete the migration. For example, to associate the custom subscription admins-subscription.tld with the Gold hosting plan, move the corresponding line under the plan section. Before # Custom subscriptions Customer: ppa-admin admins-subscription.tld Plan: Gold hosting Customer: bob customer1-subscription1.tld Plan: Silver hosting After Plan: Gold hosting Customer: ppa-admin admins-subscription.tld Customer: bob customer1-subscription1.tld Plan: Silver hosting

Transfer Scenario for Helm 4.2.2 103 7. Check for Possible Conflicts Before performing the transfer, we strongly recommend that you perform a preliminary check for possible conflicts that can cause issues during the data transfer process or even make switching to PA impossible. Such a check is performed by the ppa-transfer tool and includes a number of checks concerning various aspects of hosting panels functionality. Below we describe the most important checks that may require your attention: Check for customer / reseller accounts with the same e-mails and contact names. There are three account parameters that the tool uses to identify an account: username, e-mail, and contact name. Let us look closer at the system behavior when these parameters match for different accounts: Usernames, e-mails, and contact names are the same. The system considers such accounts to represent the same person or company: Only one of them will be transferred to PA. The priority is given to the account from the panel that is listed first in the sources string of config.ini. Accounts from other panels are ignored: Their subscriptions are also registered in PA, but these subscriptions become associated with the customer / reseller account which had the priority during the transfer. If you want each of such accounts to be transferred to PA, specify other e-mail and username for conflicting accounts. Usernames and contact names are the same, e-mails are different. The move to PA will be impossible until you specify another username for conflicting accounts. Usernames and e-mails are the same, contact names are different. The move to PA will be impossible until you specify the same contact names (if these are the same persons) for conflicting accounts. E-mails are the same, usernames and contact names are different. The move to PA will be impossible until you specify other e-mails for conflicting accounts. To perform the preliminary check: $ ppa-transfer check config.ini Based on the check results, the tool generates a report. The report contains messages of two types: WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when a certain issue blocks the transfer. You must resolve all issues marked as ERROR before performing the transfer.

104 Transfer Scenario for Helm 4.2.2 8. Run Transfer Once all preparation steps are done, you can run the transfer process. To run the transfer: 1. Issue the following command: ppa-transfer transfer-accounts config.ini The tool performs the transfer of your hosting data to certain service nodes. 2. Test the transferred domains: ppa-transfer test-all config.ini--skip-dns-forwarding-test The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that. 3. If any issues were found by the tool, resolve them and re-run the command in step 2 to verify they are resolved. The tool does not require you to resolve all of these issues. You can resolve only the important ones. Note that this command allows specifying a different transfer list, which can be useful when a transfer has failed for many domains, and you do not want to test these domains. In such a case, specify the latest list with successfully transferred domains, for example: ppa-transfer test-all config.ini--skip-dns-forwarding-test--migration-list-file migrationsession/successful-subscriptions.1385955582.55

Transfer Scenario for Helm 4.2.2 105 9. Redirect DNS to the New Servers As the DNS service is relocated to the PA DNS server, you should update all your NS records on the registrar s DNS server with the IP addresses of your PA DNS servers. Also, make sure that DNS propagation has ended. This means that you should wait for the period of time which is equal to the sum of TTL and SOA refresh interval. 10. Verify the Transferred Data To check the operability of web, mail, DNS, and FTP services for each transferred domain: # ppa-transfer test-all config.ini After you run the command, the tool will report the results of the check. The test-all command helps you verify that the transferred domains are operating properly. However, it does not check whether mail can be sent and received. You should manually check that. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. After resolving all issues, we recommend that you restart the check.

106 Transfer Scenario for Helm 4.2.2 11. Finalize the Synchronization of Content To complete the synchronization of content between the source and the destination servers, do the following: 1. Copy the content that could be added by your customers during the transfer process from your source servers. To copy mail content: ppa-transfer copy-mail-content config.ini To copy website content: ppa-transfer copy-content config.ini To copy databases: ppa-transfer copy-db-content config.ini In this step, the tool will update the content of the transferred subscriptions with any changes that were made during the transfer. Note that the tool makes a full copy of databases (as opposed to mail and web content where only new content is copied) which may require significant time. 2. Check that the transfer completed successfully by issuing the command ppa-transfer test-all config.ini--skip-dns-forwarding-test. The test-all command checks the following: Websites. It checks the main page and links to the same website (or relative links) located on the main page. DNS. It checks that all the main DNS records are present in the DNS zone of the domain and point to the correct server. Mail. For each migrated domain, it checks all mail accounts and the number of transferred email messages. User accounts. On behalf of system users, it tries to log in via FTP to each subscription at the destination server. Databases. It checks whether all databases are present on the destination server. After you run the command, the tool will report the results of the check. If all domains were transferred correctly, the report will show All domains were transferred correctly. Otherwise, it will show all detected issues and a short summary on the issues. For each issue that might need resolving, the tool will suggest a solution. 3. Remove the rsync software from the source Windows servers.

C H A P T E R 10 Troubleshooting The ppa-transfer tool records all information about performed operations to the info.log file located in the current directory where you run the tool. The log file contains messages of three types: INFO. Typically, these messages indicate that the tool started performing a certain action. WARNING. These messages warn you about the potential issues that may affect your further work in PA but are not critical for the transfer process. ERROR. These messages appear when the tool is unable to finish the transfer. In case of ERROR messages, you can also check the debug.log file located in the same directory as the one containing the info.log. This file can provide you with additional information about a certain error. You can use the information from the log file to resolve the issues that occurred during the data transfer. Next in this chapter you can find a list of known issues and limitations of current implementations of the transfer process. In this chapter: Known Issues and Limitations... 107 Known Issues and Limitations Issue/Limitation DNS forwarding does not work for subdomains transferred from Plesk 9 and earlier. Notes You must set up DNS forwarding for these subdomains manually after the transfer. PA usernames are case-sensitive as opposed to the usernames on Plesk for Windows. This can confuse users after their account is transferred to PA. For example, a user with the username John got used to logging in to Plesk using the john username. He will fail to log in to his account in PA after the transfer. You can make usernames in PA caseinsensitive by switching off the Case-sensitive usernames option in System > Settings > System Properties.

108 Troubleshooting Migration of sites created with SiteBuilder from Plesk 8 and Plesk 9 is not fully supported. The migration tool does not fully support migration of websites from Parallels Business Automation Standard. Mailman is not supported. Atmail webmail is not supported. Restricted subscription access for auxiliary users is not supported. Auxiliary users are not transferred from Parallels Business Automation Standard. Customers must have unique e-mail addresses. Tomcat applications are not transferred. Auxiliary users and user roles owned by the Panel administrator are not transferred. Reseller accounts are always active after the transfer. If there is no password specified for a mailbox, the content of this mailbox will not be transferred. Mail autoresponder attachments are not transferred. Currently, PA does not support the DomainKeys spam protection system. DNS zone transfer lists are not transferred. The content of sites created with SiteBuilder under Plesk 8 and Plesk 9 will be transferred to PA but customers will be unable to work with these sites using Presence Builder. There will be no Edit the site in Presence Builder button in the Hosting Panel. Sites that are hosted on standalone Presence Builder nodes and are registered in PBAS are not migrated. The tool stops if it detects the usage of mailing lists on any domain. You can continue with migration without mailing lists using the--omit-maillists option. After migrating to PA 11.5, the links to webmail in the Hosting Panel will open the Horde IMP webmail. Auxiliary users who are restricted to some subscriptions will be disabled after migration to prevent unauthorized access to other subscriptions. Panel allows several customers to have the same e-mail address, but this is prohibited by PA. Ensure that e-mail addresses of your customers and resellers are unique. For example, if a reseller was suspended on a source Panel, the corresponding reseller on a target panel is active after the transfer. If your Panel s mail autoresponder is set up to respond with some files in the attachment, these files will not be transferred to PA. The support for DomainKeys will be added soon. PA does not support the zones transfer feature of Plesk for Windows.

Copyright Notice Parallels IP Holdings GmbH Vordergasse 59 CH-Schaffhausen Switzerland Phone: +41 526320 411 Fax: +41 52672 2010 Global Headquarters 500 SW 39 th Street, Suite 200 Renton, WA 98057 USA Phone: +1 (425) 282 6400 Fax: +1 (425) 282 6445 EMEA Sales Headquarters Willy-Brandt-Platz 3 81829 Munich, DE Phone: +49 (89) 450 80 86 0 Fax:+49 (89) 450 80 86 0 APAC Sales Headquarters 3 Anson Road, #36-01 Springleaf Tower, 079909 Singapore Phone: +65 6645 32 90 Copyright 1999-2015 Parallels IP Holdings GmbH. All rights reserved. This product is protected by United States and international copyright laws. The product s underlying technology, patents, and trademarks are listed at http://sp.parallels.com/about/legal/. Microsoft, Windows, Windows Server, Windows NT, Windows Vista, and MS-DOS are registered trademarks of Microsoft Corporation. Linux is a registered trademark of Linus Torvalds. Mac is a registered trademark of Apple, Inc. All other marks and names mentioned herein may be trademarks of their respective owners.