One method to manage your Azure IaaS VMs is through PowerShell. By using a combination of the Azure PowerShell module and native PowerShell remoting, you can control VMs in Azure just as you would your on-premise VMs. In this article, we’ll go over some common scenarios you may find yourself in when configuring Azure VMs with PowerShell.

In actuality, Azure VMs can be treated exactly the same as on-premises VMs, with a few prerequisites. If you’re not using Azure PaaS services, an IaaS VM is exactly the same as a Windows Server sitting in Hyper-V or VMware in your local datacenter. The only difference might be in the way your network topology is configured.

NOTE: To follow along with the code samples, you will need to have the Azure PowerShell module installed.

Let’s say you’ve already got a few VMs provisioned in Azure and would like to connect and configure them. There are two ways to do this via PowerShell remoting:

  • Internal, private communication
  • Over the public Internet

In this article, we’ll discuss some challenges you might face when you already have an internal, private connection to your Azure IaaS VMs set up.

If you’re using Azure IaaS as an extension of your private datacenter, you will probably choose to set up a connection between your datacenter and Azure. There are a number of different ways to do this: setting up a point-to-site VPN or site-to-site VPN, or removing the VPN completely and setting up a connection directly to Azure. In any case, I’m going to assume you have some kind of connection to your Azure VMs.

Once you have this connection in place, you can begin to connect to your Azure VMs via their internal IP. Suppose you have a v2 VM in Azure called BAPP07GEN35. This VM is in a workgroup, so you’ll first need to create a DNS record for it. However, when it was provisioned, the IP was dynamically assigned. We need to figure out what this IP is.

Each Azure VM has a network interface assigned to it, with a private IP address. We need to first find the network interface attached to that Azure VM and then find the IP address that it has.

To do this, we’ll ensure that we can find that VM using the Get-AzureRmVm cmdlet and specify the name of the VM and the resource group it was assigned to. Here, I’m getting the VM that’s inside of the MyRG resource group:

$vm = Get-AzureRmVm -Name 'BAPP07GEN35' -ResourceGroupName 'MyRG'

Once I have the VM assigned to $vm, I can then pass this to the Get-AzureRMNetworkInterface cmdlet and find the attached network interface.

$vm | Get-AzureRmNetworkInterface -ResourceGroupName $vm.ResourceGroupName

This will allow me to dive into the network interface and discover the IP address that it currently holds.

$ipAddress = ($vm | Get-AzureRmNetworkInterface -ResourceGroupName $vm.ResourceGroupName).IpConfigurations.PrivateIpAddress

Now that we have the internal IP address, we can easily create a DNS record on your internal DNS server.

Add-DnsServerResourceRecord -ZoneName 'mydomain.local' -A -Name $vm.Name -IPv4Address $ipAddress

Next, since this VM is in a workgroup, we’ll need to ensure the name is in our WSMAN trusted hosts list.

Set-Item -Path wsman:\localhost\Client\TrustedHosts -Value $vm.Name -Force

Next, we’ll need to pass a credential to the remote machine, but maybe we’ve forgotten the admin username we used when the VM was created. No problem. We can use PowerShell to find this out.

$adminUsername = $vm.osProfile.AdminUsername

I’m hoping you have the password! If so, let’s create a PSCredential object.

$cred = Get-Credential -Username $adminUsername -Message 'Input password'

Now we can pass this credential object to our Azure VM along with whatever code we’d like to execute on it.

Invoke-Command -ComputerName $vm.Name -ScriptBlock {<# Run some code here #>}

This should successfully run whatever code you have in the script block.

If you were paying attention, you may have noticed that the actual method to connect to Azure VMs via PowerShell remoting is identical to your traditional on-premise machines. The only difference, as you’ve seen, is that you will come across various configuration items that might be Azure-specific, and you will need to take them into account.


Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account