How to fix Azure Classic Cloud Service prepare failure while using in-built ARM migration feature

Introduction:

Over the years, Azure Cloud Services (classic) has played a central role in Microsoft’s cloud offerings. However, as technology advances, there arises a demand for more sophisticated and efficient services. To address this, Microsoft has introduced Azure Cloud Services (extended support) as a successor to the classic model. It provides comparable functionality while adding extra benefits and features. This transition is essential for businesses to remain current with technology, enhance their cloud management capabilities, and be well-prepared for the future.

Cloud Services (extended support) is a highly anticipated and essential platform enhancement for Azure early adopter customers who are transitioning to Azure Resource Manager (ARM).

Cloud service in-built migration is a feature that allows you to migrate your cloud service deployments from the classic deployment model to the Azure Resource Manager deployment model. This can help you take advantage of the benefits of the Resource Manager model, such as role-based access control, tags, and policy.

However, sometimes the migration process may fail with an error message that says, "cloud service must be within a virtual network to be migrated". This means that your cloud service is not associated with a virtual network in the classic model, and you need to create one and link it to your cloud service before you can migrate.

In late 2018, Azure started automatically creating new deployments (without customer specified virtual network) into a platform created “default” virtual network. These default virtual networks are hidden from customers.

If you created your cloud service before 2018, it is possible that you never specified a virtual network for it, and it was deployed in the Azure public cloud without any isolation. This can cause problems when you try to migrate your cloud service to the ARM model, because the migration process requires a virtual network to map the network configuration of your cloud service. Hence, any cloud service deployment prior to 2018 would not support in-built migration to CSES.

https://learn.microsoft.com/en-us/azure/cloud-services-extended-support/in-place-migration-technical-details#migration-of-deployments-not-in-a-virtual-network

Therefore, you need to create a virtual network in the classic model and link it to your cloud service before you can migrate it. This will not affect the functionality or availability of your cloud service, but it will enable you to move it to the ARM model more easily.

In this blog post, we will show you how to do that, and what steps to take if you encounter similar issues during the migration process.

Pre-requisites:

• You need to have an Azure subscription and an Azure account with sufficient permission to create and manage cloud services and virtual networks.

• You need to have the name and location of your cloud service that you want to migrate. You can find them in the Azure portal or by using the Get-AzureService cmdlet - Get-AzureService (Azure) | Microsoft Learn

Symptom:

Cloud service inbuilt migration fails with below error:

Deployment <guid-value> in cloud service <cloud-service-name> must be within a virtual network to be migrated.

Solution:

Solution-1:

One solution to this scenario and the easiest way is to consider redeploying cloud service application directly in Azure Resource Manager (i.e. new cloud service extended support) by creating a VNET and associating the same to cloud service via service configuration file.

Sample configuration only with VNET & subnet details that can be added in the CSCFG file is shown below:

<Networkconfiguration>
    <Virtualnetworksite name="Your_RG-vnet">
        <Addressassignments>
            <Instanceaddress rolename="WebRoleSite">
                <Subnets>
                    <Subnet name="test"></Subnet>
                </Subnets>
            </Instanceaddress>
        </Addressassignments>
    </Virtualnetworksite>
 </Networkconfiguration>

The following example shows the complete NetworkConfiguration element and its child elements.

<ServiceConfiguration>
 <NetworkConfiguration>
  <AccessControls>
   <AccessControl name="aclName1">
    <Rule order="<rule-order>" action="<rule-action>" remoteSubnet="<subnet-address>" description="rule-description"/>
   </AccessControl>
  </AccessControls>
  <EndpointAcls>
   <EndpointAcl role="<role-name>" endpoint="<endpoint-name>" accessControl="<acl-name>"/>
  </EndpointAcls>
  <Dns>
   <DnsServers>
    <DnsServer name="<server-name>" IPAddress="<server-address>" />
   </DnsServers>
  </Dns>
  <VirtualNetworkSite name="Group <RG-VNet> <VNet-name>"/>
  <AddressAssignments>
   <InstanceAddress roleName="<role-name>">
   <Subnets>
    <Subnet name="<subnet-name>"/>
   </Subnets>
   </InstanceAddress>
   <ReservedIPs>
    <ReservedIP name="GROUP <ResourceGroupNameOfReservedIP> <reserved-ip-name>"/>
   </ReservedIPs>
  </AddressAssignments>
 </NetworkConfiguration>
</ServiceConfiguration>

Here is a quick reference guide for the pre-requisites to ensure a successful Cloud Services (extended support) deployment- Prerequisites for deploying Azure Cloud Services (extended support) | Microsoft Learn

Solution-2:

Migrate via creating new Staging deployment and VIP Swap. For this approach:

1. Create a non VNET classic cloud service in the same region as the VNET you want to migrate and in the Azure portal, select the 'Staging' drop-down.

2. Create a deployment with the same configuration as existing deployment by selecting 'Upload' next to the staging drop-down. The platform creates a Default VNET deployment in staging slot. Once staging deployment is created, the URL, IP address, and label populate.

3. After verifying the data, select 'Swap' to swap the production and staging deployments. This operation swaps both the deployments. After swapping, you'll find staging deployment in production slot with the DNS and IP address of production deployment.

4. You can now safely delete the staging slot and trigger the Cloud Service Migration Operation.

5. Use this reference for step-by-step guide - Migrate cloud services not in a virtual network to a virtual network | Microsoft Learn

Solution-3:

Migrate the cloud service without VNET using PowerShell. For this approach:

1. Get the deployment name for the Cloud Service you want to migrate:

     $serviceName = "My Service"
     $deployment = Get-AzureDeployment -ServiceName $serviceName
     $deploymentName = $deployment.DeploymentName

2. Validate that you can migrate the Cloud Service by using the commands below:

    $validate = Move-AzureService -Validate -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork
    $validate.ValidationMessages

3. Once validation is successful or has just warnings, you can move on to the Prepare step.

    Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName -CreateNewVirtualNetwork

4. Check the configuration for the prepared Cloud Service (extended support).

• If you're ready to complete the migration, commit the migration:

    Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName

• If you're not ready for migration and you want to go back to the old state, abort the migration.

    Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName

We hope this blog post has helped you resolve the issue of cloud service in-built migration error. If you have any questions or feedback, please leave a comment below or contact us at [email protected].