Eric Spooner Azure Networking

Multi VIP Load balancer in ARM

Eric Spooner — Fri, 11 Mar 2016 12:10:13 GMT

I get this question more than a person would think. How can I add a new VIP to an ARM Load Balancer. Below is my script I use. You can add up to 20 by default without contacting support. For most of this you can rinse and repeat. Make sure that your servers that are going to be in the back end pool are in the same availability set. This will make life easier down the road should you go to add more servers, or update anything. Powershell script: #Set Resource group and location. Update to your values. $RG='MultiLBTest' $Location='centralus' New-AzureRmResourceGroup -Name $RG -Location $Location #Create new public IP's Just update the name for each one you want to add. $PIP1=New-AzureRmPublicIpAddress -Name PIP1 -ResourceGroupName $RG -Location $Location -AllocationMethod Static $PIP2=New-AzureRmPublicIpAddress -Name PIP2 -ResourceGroupName $RG -Location $Location -AllocationMethod Static $PIP3=New-AzureRmPublicIpAddress -Name PIP3 -ResourceGroupName $RG -Location $Location -AllocationMethod Static $PIP4=New-AzureRmPublicIpAddress -Name PIP4 -ResourceGroupName $RG -Location $Location -AllocationMethod Static $PIP5=New-AzureRmPublicIpAddress -Name PIP5 -ResourceGroupName $RG -Location $Location -AllocationMethod Static #Creations of the FE Configes Update the number of FE Configs you want to create. This will increase with Public IP's and be added to the LB as shown down below. $FEConfig=New-AzureRmLoadBalancerFrontendIpConfig -Name FEConfig1 -PublicIpAddressId $PIP1.Id $FEConfig1=New-AzureRmLoadBalancerFrontendIpConfig -Name FEConfig2 -PublicIpAddressId $PIP2.Id $FEConfig2=New-AzureRmLoadBalancerFrontendIpConfig -Name FEConfig3 -PublicIpAddressId $PIP3.Id #Creation of the BEPools $BEPool=New-AzureRmLoadBalancerBackendAddressPoolConfig -Name BEPool #Creation of the LB $lb=New-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG -Location $Location -FrontendIpConfiguration $FEConfig,$FEConfig1 -BackendAddressPool $BEPool #Updating with the configuration from Azure $lb=Get-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG #Adding FE Configurations ot the LB $lb.FrontendIpConfigurations.Add($FECOnfig2) $Set=Set-AzureRmLoadBalancer -LoadBalancer $lb #Updating with the configuration from Azure $lb=Get-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG #Adding Probes $fec=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FEConfig.Name -LoadBalancer $lb $fec1=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FECOnfig2.Name -LoadBalancer $lb $BEP=Get-AzureRmLoadBalancerBackendAddressPoolConfig -Name $BEPool.Name -LoadBalancer $lb $Probe=New-AzureRmLoadBalancerProbeConfig -Name Probe2 -Protocol Tcp -Port 80 -IntervalInSeconds 5 -ProbeCount 2 $lb.Probes.Add($Probe) $Set=Set-AzureRmLoadBalancer -LoadBalancer $lb #Getting values from Azure for Rules $lb=Get-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG #Need to have $fec1 $fec2 etc for each Front End Config in the Load balancer. Only update the $FECOnfig(1234567).Name for each. $fec=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FEConfig.Name -LoadBalancer $lb $fec1=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FECOnfig2.Name -LoadBalancer $lb $BEP=Get-AzureRmLoadBalancerBackendAddressPoolConfig -Name $BEPool.Name -LoadBalancer $lb $Probe=Get-AzureRmLoadBalancerProbeConfig -Name Probe1 -LoadBalancer $lb #Adding LB rules $LBRule1=New-AzureRmLoadBalancerRuleConfig -Name Rule1 -FrontendIpConfigurationId $fec.Id -BackendAddressPoolId $BEP.Id -ProbeId $Probe.Id -Protocol Tcp -FrontendPort 80 -BackendPort 80 $lb.LoadBalancingRules.Add($LBRule1) $Set=Set-AzureRmLoadBalancer -LoadBalancer $lb #Adding LB Rule to FE Config $lb=Get-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG $fec1=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FEConfig1.Name -LoadBalancer $lb $Probe=Get-AzureRmLoadBalancerProbeConfig -Name Probe1 -LoadBalancer $lb $LBRule1=New-AzureRmLoadBalancerRuleConfig -Name Rule2 -FrontendIpConfigurationId $fec1.Id -BackendAddressPoolId $BEP.Id -ProbeId $Probe.Id -Protocol Tcp -FrontendPort 80 -BackendPort 81 $lb.LoadBalancingRules.Add($LBRule1) $Set=Set-AzureRmLoadBalancer -LoadBalancer $lb #Adding LB Rule to additional configs $lb=Get-AzureRmLoadBalancer -Name LBTest1 -ResourceGroupName $RG $LBRule=Get-AzureRmLoadBalancerRuleConfig -Name Rule1 -LoadBalancer $lb $fec1=Get-AzureRmLoadBalancerFrontendIpConfig -Name $FEConfig1.Name -LoadBalancer $lb $lb.FrontendIpConfigurations.Add($fec1) $Set=Set-AzureRmLoadBalancer -LoadBalancer $lb

OpenVPN Point to Site with Azure ARM VM

Eric Spooner — Fri, 11 Mar 2016 12:03:54 GMT

I put this together before Point to Site was an option/supported in ARM. This gives you an option if you just need a Point to site for a small number of people. Required: OpenVPN complete Install on server. Including the RSA to allow us to build our own certs for connection of tunnel. Routing and Remote Access. This is required in the LAN Router Configuration. This will allow our traffic from OpenVPN to hit the Vnet. Azure VM of any size with at least 1 network adaptor. To Begin we’ll need to provision our VM. I’m including the script. I use Powershell ISE. This needs to be updated as needed for your environment. #Update the values below inside the single quotes to set their value for your subscription and VM. #This script does not create a storage or resource group. It assumes you have one created. If you would $location='AzureDCLocation' $RG='ResourceGroupName' $NetworkName='VirtualNetworkName' $SubnetName='SubnetNameForVM' #This Value is optional. Simply add -AvailabilitySetId $AvailabilitySet.Id to line 32 and uncomment line 26. #$NewAVSetName='AvailabilitySet(optional)' $StorageName='StrorageAccountName' $PIPName='PublicIPName' $Nic1Name='NetworkCard1Name' #Network Card 2 is optional. See requirements for 2+Nic machines here https://azure.microsoft.com/en-us/blog/multiple-vm-nics-and-network-virtual-appliances-in-azure/ #Uncomment the NIC below and line 36 to enable multiple NICs. #$Nic2Name='NetworkCard2Name' $VMName='VM Name For Portal' $VMComputerName='VM ComputerName' $VHDName='Name for VHD' $PIPDNSName='Public IP DNS Name' #Update the VM size to whatever VM you would like. I use Standard_D1, but you can use anything. $VMSize='Standard_D1' $PrivateIP='InternalIP Address' $network=Get-AzureRmVirtualNetwork -Name $NetworkName -ResourceGroupName $RG $subnet=Get-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $network #$AvailabilitySet=New-AzureRmAvailabilitySet -ResourceGroupName $RG -Name $NewAVSetName -Location $location $Cred=Get-Credential $Stor=Get-AzureRmStorageAccount -ResourceGroupName $RG -Name $StorageName $pip=New-AzureRmPublicIpAddress -Name $PIPName -ResourceGroupName $RG -Location $location -DomainNameLabel $PIPDNSName -AllocationMethod Dynamic $nic1=New-AzureRmNetworkInterface -Name $Nic1Name -ResourceGroupName $RG -Location $location -SubnetId $subnet.Id -EnableIPForwarding -PublicIpAddressId $pip.Id -PrivateIpAddress $PrivateIP $nic2=New-AzureRmNetworkInterface -Name $Nic2Name -ResourceGroupName $RG -Location $location -SubnetId $subnet.Id -EnableIPForwarding $VM=New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize $VM=Set-AzureRmVMOperatingSystem -Windows -ComputerName $VMComputerName -Credential $Cred -EnableAutoUpdate -ProvisionVMAgent -VM $VM $VM=Set-AzureRmVMSourceImage -VM $VM -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2012-R2-Datacenter -Version "latest" $VM=Add-AzureRmVMNetworkInterface -Id $nic1.id -VM $VM -Primary #$VM=Add-AzureRmVMNetworkInterface -Id $nic2.Id -VM $VM $OSDiskUri=$Stor.PrimaryEndpoints.Blob.ToString() + 'vhds/' +$VHDName +'.vhd' $VM=Set-AzureRmVMOSDisk -Name $VHDName -VhdUri $OSDiskUri -Caching ReadWrite -CreateOption fromImage -VM $VM New-AzureRmVM -ResourceGroupName $RG -Location $location -VM $VM $P2SVPNAddressSpace='Point to Site address space example 10.0.0.0/23' $InternalNICIP='Internal NIC IP' $RouteTableName='Name of the Route Table' $RouteConfigName='Name of this Route Configuration' $VNetSubnetPrefix=$subnet.AddressPrefix $RouteConfig=New-AzureRmRouteConfig -Name $RouteConfigName -AddressPrefix $P2SVPNAddressSpace -NextHopType VirtualAppliance -NextHopIpAddress $InternalNICIP New-AzureRmRouteTable -Name $RouteTableName -ResourceGroupName $RG -Location $location -Route $RouteConfig $RT=Get-AzureRmRouteTable -ResourceGroupName $RG -Name $RouteTableName Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $network -Name $subnet.Name -RouteTableId $RT.Id -AddressPrefix $VNetSubnetPrefix Now that we have our VM and route created/defined we can move onto installing OpenVPN and RRAS. Download OpenVPN from https://openvpn.net/index.php/open-source/downloads.html. Install selecting all options. Once install is completed we walk through the documentation to create our server and client certs as well as the CA for the connections. Here are the instructions: https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide. Once we have created all the files needed, we have to update our config file to have our address space we are going to use for the point to site. If defaults were used this can be found in C:\Program Files\OpenVPN\config\server.ovpn In there we can find the line server 10.8.0.0 255.255.255.0 and replace the 10.8.0.0 255.255.255.0 with our address space we want to have clients assigned out. Then we need to find the following lines: ;push "route 192.168.10.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" We will remove the ; and update the address to the Vnet’s Address space in Azure. If we only have 1 address space or want to limit traffic we can add/remove a line or leave it commented out with the ;. Now that we have our server configuration file, we can try to start the server by right clicking the file and Start OpenVPN on this config file. This should launch a command window and give us any errors we may have in our configuration or build the tunnel up. If the tunnel is working we can start the service which will use this config, or we can continue with this for our test. The client files will have to be copied to the client test machine. Next we will need to get Routing and Remote access enabled on our server so that we can do LAN routing. In Server manager add Roles and Features. Then step through till Roles and Select Remote Access. Continue through accepting any pop ups. Once on the Role Services select Routing. Accept the Prompt. Then click next until you see Install and click Install. Once this is complete you can launch the wizard and tell it to configure routing or launch Routing and Remote access out of mmc or from the start menu. Once in routing and remote Access right click the server and “Configure an Enable Routing and Remote Access. You will select Custom for the type and then just check the box “LAN Routing” Click next and finish it will ask you if you want to start tell it yes. You are done with the server, and will now just need to build out client configuration files to deploy. Have fun!

Moving an ARM VM to a new Vnet

Eric Spooner — Fri, 11 Mar 2016 11:58:24 GMT

I'm posting this for a college of mine: Credited Eric Ashton From time to time it might make sense to move a VM from one VNET to another. In the classic Azure portal this was fairly easy. We could remove the Virtual machine in the classic portal (which left the VHD behind in the storage account) and then create a new VM from “My Disks” to reattach the VHD and specify the new VNET. In the newer ARM portal this option doesn’t currently exist. We can however use some PowerShell magic to move a Virtual Machine in ARM to a new VNET. In my example scenario I have a VM named “CentralVm” that lives in the Central US region, and I want to move it into a VNET called “vnetEast” in the East US region. Because my VM resides in a storage account in the Central region, and the VNET I want to move the VM into is in the East US region, I will first need to move the VHD for the VM from the storage account in the Central region into a storage account in the East US region. If you are in a situation where you need to move a VM to a new VNET within the same region, you can skip down to the third script (step 5). Before we begin we should gather some information from the Azure portal about the virtual machine we want to move, and about the VNET we want to move to. My VM details: VMNAME: CentralVm Region: Central US Resource Group: rgCentral VM Size: Standard_DS11 The StorageAccount that holds the VHD for the VM: rgcentral8983 Name of the VHD in the rgcentral8983 storage account for this VM: CentralVM2016118102459 Full path of the VHD in the rgcentral8983 storage account: https://rgcentral8983.blob.core.windows.net/vhds/CentralVM2016118102459.vhd Access Key for storage account source: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The details of the VNET I want to move my VM into: VNET Name: vnetEast Region: East US Resource Group: rgEast Subnet in vnetEast that I intend the VM to be in after the move: AppSubnet A Storage account in the East US region where I will need to move the VHD for my VM into: rgeast9618 Access Key for storage account destination: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Now that we have the required information we can use the following scripts to move my VM named "CentralVm" into the new VNET vnetEast.

Since I will be detaching and reattaching the VHD for this VM I need to shut down CentralVm.
Next I will be delete the VM in the portal. This will remove the VM from the portal, however the VHD for the VM will still reside in the rgcentral8983 storage account.

At this point, if you do NOT need to move your VM to a different region you can skip down to step 5 (The VM/VHD reattach script)

Now that CentralVm has been shut down and deleted from the azure portal, I am ready to move the detached VHD from the rgcentral8983 storage account (Central region) to the rgeast9618 storage account in the (East US region)

# MOVE VHD FROM ONE STORAGE ACCOUNT TO ANOTHER # ### Source VHD - authenticated container ###



$srcUri = "https://rgcentral8983.blob.core.windows.net/vhds/CentralVM2016118102459.vhd"

 

### Source Storage Account (Central) ###

$srcStorageAccount = "rgcentral8983"

$srcStorageKey = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”

 

### Target Storage Account (East) ###

$destStorageAccount = "rgeast9618"

$destStorageKey = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”

 

### Create the source storage accountcontext ###

$srcContext = New-AzureStorageContext –StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey

 

### Create the destination storage account context ###

$destContext = New-AzureStorageContext –StorageAccountName $destStorageAccount -StorageAccountKey $destStorageKey

 

### Destination Container Name ###

$containerName = "vhds"

 

### Start the asynchronous copy - specify the source authentication with -SrcContext ###

$blob1 = Start-AzureStorageBlobCopy -srcUri $srcUri `

-SrcContext $srcContext `

-DestContainer $containerName `

-DestBlob "CentralVM2016118102459.vhd" `

-DestContext $destContext

 

	This should run without an error. We can then watch the copy progress with the following script:

 

 

### Retrieve the current status of the copy operation ###

$status = $blob1 | Get-AzureStorageBlobCopyState

 

### Print out status ###

$status

 

### Loop until complete ###

While($status.Status -eq "Pending"){

$status = $blob1 | Get-AzureStorageBlobCopyState

Start-Sleep 10

### Print out status ###

$status

}

 

 

 

	Once we see the message that the copy has been completed, we are ready to create a new VM in the East US region using the VHD that we just copied over.

 

## Create new VM from detached VHD ##

 

#This is the ResourceGroup that holds the VNET we are trying to load the VM into

$RG='rgEast'

 

#Name of the VNET we are trying to load the VM into

$NetworkName='vnetEast'

 

#Subnet in the vnet we are trying to move the VM into

$SubnetName='AppSubnet'

 

#New Public IP name

$PIPName='MovedVMpip'

 

#New Nic name that will get created in the VNET we are moving the VM to

$Nic1Name='MovedVMnic'

 

#New Virtual Machine Name

$VMName='CentralVm'

 

#The storage account that holds the VHD we are trying to make a new VM from.

$storageaccount='rgeast9618'

 

#Name of the VHD that resided in the $storageaccount

$VHDName='CentralVM2016118102459'

 

#New Public IP DNS name

$PIPDNSName='movedvmdns'

 

#VMSize

$VMSize='Standard_DS11'

 

#The resource group that $storageaccount resides in

$StorageRg='rgEast'

#The location where $storageaccount resides

$Location='eastus'

 

$network=Get-AzureRmVirtualNetwork -Name $NetworkName -ResourceGroupName $RG

$subnet=Get-AzureRmVirtualNetworkSubnetConfig -Name $SubnetName -VirtualNetwork $network

$Stor=Get-AzureRmStorageAccount -ResourceGroupName $StorageRg -Name $storageaccount

$pip=New-AzureRmPublicIpAddress -Name $PIPName -ResourceGroupName $Rg -Location $Location -DomainNameLabel $PIPDNSName -AllocationMethod Dynamic

$nic1=New-AzureRmNetworkInterface -Name $Nic1Name -ResourceGroupName $Rg -Location $Location -SubnetId $subnet.Id -EnableIPForwarding -PublicIpAddressId $pip.Id

 

$VM=New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize

 

$VM=Add-AzureRmVMNetworkInterface -Id $nic1.id -VM $VM -Primary

$OSDiskUri=$Stor.PrimaryEndpoints.Blob.ToString() + 'vhds/' +$VHDName +'.vhd'

$VM=Set-AzureRmVMOSDisk -Name $VHDName -VhdUri $OSDiskUri -Caching ReadWrite -CreateOption attach -Windows -VM $VM

 

New-AzureRmVM -ResourceGroupName $RG -Location $location -VM $VM

 

#Stop Script

==========================================================
Done! Now when we look in the portal we will find that our VM has been recreated and resides in the target region/vnet.