Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

How to reassociate orphaned virtual machines with a service instance or VM role in System Center 2012 R2 with Update Rollup 7


View products that this article applies to.

If you have Microsoft System Center 2012 R2 Update Rollup 7 or a later version in your Virtual Machine Manager (VMM) environment, you can now reassociate an orphaned virtual machine with its Service or VM role after the host server is recommissioned to VMM. This is helpful if Service or VM role VMs are orphaned during the host add or remove cycle. This is helpful also to implement Recovery and Backup scenarios for Services and VM roles.

What was the issue previously?

  • Sometimes, a host or a cluster can be decommissioned from VMM and must be restored. If such hosts or clusters had hosted virtual machines that were part of any Service or VM role, there was no option before UR7 for VMM administrators to reassociate the VMs to their respective Service or VM roles.
  • If Site Recovery Services are used when the primary site goes down, virtual machines are recovered at the secondary site. After the Service Templates became available at the secondary site, it was not possible previously to associate the recovered virtual machines to the newly deployed service instance.

↑ Back to the top


How do I reassociate the virtual machine?

By using the following cmdlet, you can now reassociate the virtual machine to its Service or VM role.

Parameter Set: Service
Join-SCVirtualMachine [–VM] <VM> -ComputerTier <ComputerTier> [<CommonParameters>]

Parameter Set: VM Role

Join-SCVirtualMachine [–VM] <VM> -VMRole <CloudVMRole> [<CommonParameters>]
This cmdlet runs a Re-associate task on VMM. This task performs a set of validations that help confirm the compatibility of the virtual machine with the service template. Click here to see the list of validation checks.

Parameter details

-VM <VM>
This parameter indicates the orphaned virtual machine that should be joined to a Service or VM role.

Aliases None
Required? True
Position? 1
Default Value None
Accept Pipeline Input? True (ByValue)
Accept Wildcard Characters? False
-ComputerTier <ComputerTier>
Use this parameter to specify the computer tier of a service instance to which the virtual machine should be joined.
Aliases None
Required? True
Position? Named
Default Value None
Accept Pipeline Input? False
Accept Wildcard Characters? False
-VMRole <CloudVMRole>
Use this parameter to specify the VM role to which the virtual machine should be joined.
Aliases None
Required? True
Position? Named
Default Value None
Accept Pipeline Input? False
Accept Wildcard Characters? False

Examples

Example 1: Joining an orphaned virtual machine to a service tier

$vm = Get-SCVirtualMachine –Name "PS-Web-001"
$ct = Get-SCComputerTier –Name "MyService-WebTier"
Join-SCVirtualMachine –VM $vm –ComputerTier $ct

Example 2: Joining an orphaned virtual machine to a VMRole

$vm = Get-SCVirtualMachine –Name "PS-Web-001"
$vmRole = Get-CloudResource –Name "PetShop"
Join-SCVirtualMachine –VM $vm –VMRole $vmRole

Screen shots

The following screen shot shows the behavior of VMM before this functionality was introduced. The Services pane in VMM shows that the virtual machines for the service instance are missing.



The following screen shot shows the behavior after the virtual machines are reassociated to the service instance.



↑ Back to the top


Assumptions made before you reassociate the virtual machine

  • It is assumed that the virtual machine is running, and that all the guest applications and services that are running on it are intact.
  • The computer tier to which the virtual machine is being joined must run at less than its maximum instance count. The upgrade domain for the join operation resembles a scale-out.
  • The virtual machine that is reassociated must be the one that was originally part of a Service or VM role deployment. Also, it must not be changed in such a manner that it fails the VMM validation check. (See the "List of validation checks" section for a full list of checks).
A word of caution

The process of joining a virtual machine to a Service or VM role that uses load balancers is not supported. If you try to join a virtual machine to such a Service or VM role, the user must configure any load balancer settings manually.

↑ Back to the top


List of validation checks

The following is the list of validation checks that are performed to verify compatibility of the virtual machine with the service template.

Virtual machine and ComputerTier status

The virtual machine has to be in a running state, and the computer tier has to be in a deployed state. Also, because this operation resembles a scale-out, the total number of virtual machines for the tier should not exceed its maximum limit.

  • Check whether the virtual machine is in a running state.
  • Check whether the virtual machine is already associated to a computer tier.
  • Check whether the computer tier is in Deployed state.
  • Check whether the VMInstanceCount value of the tier is less than the maximum.
Verifying virtual machine scope

A service can be deployed on a Cloud or a HostGroup. The virtual machine should be in scope of the Cloud or HostGroup in which the service is deployed.
  • Check whether the virtual machine is in the scope of the service instance.
  • Check whether the owner of the virtual machine is the same as the owner of the service instance.
  • Check whether the UserRole of the virtual machine is the same as that of the service instance.
Networking checks

Basic minimal checks are performed on the virtual machine networks and IP address types that are expected on a virtual machine.
  • If there is a virtual network adapter (Virtual Network Interface Card, or vNIC) on the virtual machine that matched the virtual machine network, check for every network adapter that is defined by the template.
  • Check IP Address types.
Verifying guest agent state

If the virtual machine template of the computer tier requires the guest agent to be present on the virtual machine, the following checks are performed:
  • Verify that there is a guest agent installed on the virtual machine.
  • Check whether the guest agent is responding (heartbeat).
  • Verify the guest agent version.
Note If a computer tier has one or more LBVips (Load Balancer VIPs) associated with it, and the tier machine instance count is zero (0), this cmdlet cannot be used to associate a virtual machine to such a tier.

That is, for a computer tier having LBVips, the virtual machine that is being associated cannot be the first virtual machine of the tier. It must have at least one existing virtual machine that can be obtained by scaling out that tier. In this situation, we recommend that you scale-out the tier to have at least one virtual machine. You do this to avoid issues that affect NLB clusters in which the tier might not have any NLB node and we try to add a VIP member that eventually fails.

↑ Back to the top


Keywords: kbsurveynew, kbinfo, kbhowto, kb

↑ Back to the top

Article Info
Article ID : 3083085
Revision : 1
Created on : 1/7/2017
Published on : 7/30/2015
Exists online : False
Views : 339