H.1 Migration of Workloads to Azure Cloud

H.1.1 Assigning a Reserved IP Address to a Migrate Server in Azure

In Azure, the Dynamic assignment method is the default setting for the public IP address. The IP address can change every time the server is stopped and started. You should modify the setting to use the Static assignment method. Using a reserved IP address ensures that Azure allocates and reserves an IP address for the life of the resource.

NOTE:A change in IP address on the PlateSpin Server breaks the heartbeat communications with source workloads.

To apply a reserved IP address to an existing Migrate Server in Azure that has a dynamic IP address:

  1. Specify Static as the assignment method for the public IP address of the Migrate Server resource:

    1. Go to the appropriate Azure Portal and log in to your Azure account:

    2. Open Resources, select the Migrate Server resource, then select Stop.

    3. In the information for the Migrate Server, select the public IP address.

    4. In the Public IP Address Configuration panel under Settings, select Configuration.

    5. Specify Static as the assignment method for the Public IP address.

    6. Click Save.

      Azure allocates and reserves an IP address from a pool of its available IP addresses in the Azure location where you deploy the Migrate server.

    7. Start the Migrate Server resource.

      Heartbeat communications for existing migration jobs will be broken until you modify the server IP address stored in the OFX Controller configuration file on the source workload.

  2. For each source workload that has already been configured for migration on the Migrate Server, use the Migrate Agent to set the new IP address:

    migrateagent.cli.exe config /setting=psserver:<new_ipaddress_or_dns_name>

    The psserver option stops the OFX Controller (ofxcontroller) service, modifies the OfxController.exe.config file with the new address, and restarts the service. Heartbeat communications now work with the server’s new IP address.

H.1.2 Install Azure Agent Option Is Not Available for a Source Linux Workload

Issue: For workload migrations to Azure, the Install Azure Agent option is deselected and dimmed (not available) for selection when you configure a source Linux workload. The message indicates that Python 2.7 is required. You installed Python 2.7, but the option is still not available.

Workaround: Python 2.7 must be installed on the source workload prior to discovery to make the information available to PlateSpin Migrate. After you update Python to version 2.7, remove the workload from PlateSpin Migrate, then re-add/rediscover the workload. The Install Azure Agent option will be available when you configure the workload migration.

H.1.3 Outbound Email Stuck after Migrating Microsoft Exchange Server 2016 to Azure Cloud

Issue: After you migrate a Microsoft Exchange 2016 server to Microsoft Azure, the user’s outgoing messages get stuck in the Drafts folder of their Microsoft Outlook application.

Fix: After you migrate a Microsoft Exchange Server workload to Microsoft Azure, ensure that you modify the Exchange internal and external DNS settings to use Microsoft Hyper-V Network Adapter. See KB Article 7021909.

H.1.4 Azure Target VM Launched in Safe Mode After Successful Cutover of a Workload

Issue: If you choose to migrate a Windows Small Business Server 2011 workload to Azure, the cutover completes but the target VM in Azure is launched in Safe Mode.

Fix: To boot the target VM in Normal Mode:

  1. Run msconfig.

  2. Deselect the Boot > Safe boot option.

  3. Reboot the VM.

H.1.5 Linux Disks or Partitions on the Target Are in a Different Order Than on the Source

Issue: Because Azure controls the mapping of devices, Linux disks might be created in a different order on the target workload than they are on the source workload. All migrated disks and partitions are present; only the disk order differs.

Workaround: None. The target VM is fully functional.