Azure – Which Public and Private IPs are In Use and By Which VM…?

2017-08-03T03:01:59+00:00 August 10th, 2017|Azure, blog, Cloud, PowerShell|

In my recent thread of simple-but-handy Azure PowerShell tools, I realized one important thing was missing: A tool that grabbed all the public & private IP addresses in use by VMs (plus some additional info).

I searched around, and found an old post by fellow Coreteker Will Anderson, where he’d solved the problem.  Unfortunately, PowerShell had changed since then, and his suggestion didn’t work anymore.  Fortunately however, Will Anderson is now on the other end of Skype from me, so after a quick explanation he gave me some advice on how to fix it within the new PowerShell behavior.  And of course, it would just be wrong not to post if back to the community…

So here is my script, with help from Will and another blogger Rhoderick Milne, where I found some additional input.  When executed, this script writes some quick handy info to screen, as in this lab example:

…which might be enough for you if you just want a quick review, but then it also dumps my preferred info for each VM to a csv, as follows: “Subscription”, “Mode”, “Name”, “PublicIPAddress”, “PrivateIPAddress”, “ResourceGroupName”, “Location”, “VMSize”, “Status”, “OsDisk”, “DataDisksCount”, “AvailabilitySet”

Just paste the below  into a script file, change the subscription name in the variable to your choice, and execute.  If you don’t know which subscription name to use, you can always run “Get-AzureRmSubscription” after you run “Login-AzureRmAccount” and find it in the list.  So grab the code, hack at it, and let me know where you take it!

# Thanks for help from Will Anderson, Rhoderick Milne for the assistance.
#
# Get Date; Used only for output file name.
$Date = Get-Date
$NOW = $Date.ToString("yyyyMMddhhmm")
#
# Variables
$MySubscriptionName = "Windows Azure  MSDN - Visual Studio Premium"
$VmsOutFilePath = "C:\temp"
$VmsOutFile = "$VmsOutFilePath\VmList-$NOW.csv"
#
$NeedToLogin = Read-Host "Do you need to log in to Azure? (Y/N)"
if ($NeedToLogin -eq "Y")
{
  Login-AzureRmAccount
  Select-AzureRmSubscription -SubscriptionName $MySubscriptionName
}
elseif ($NeedToLogin -eq "N")
{
  Write-Host "You must already be logged in then.  Fine. Continuing..."
}
else
{
  Write-Host ""
  Write-Host "You made an invalid choice.  Exiting..."
  exit
}
#
$vms = Get-AzureRmVm 
$vmobjs = @()
foreach ($vm in $vms)
{
  #Write-Host ""
  $vmname = $vm.name
  Write-Host -NoNewline "For VM $vmname... "
  Start-Sleep 1
  $vmInfo = [pscustomobject]@{
      'Subscription'= $MySubscriptionName
      'Mode'='ARM'
      'Name'= $vm.Name
      'PublicIPAddress' = $null
      'PrivateIPAddress' = $null
      'ResourceGroupName' = $vm.ResourceGroupName
      'Location' = $vm.Location
      'VMSize' = $vm.HardwareProfile.VMSize
      'Status' = $null
      'OsDisk' = $vm.StorageProfile.OsDisk.Vhd.Uri
      'DataDisksCount' = $vm.StorageProfile.DataDisks.Count
      'AvailabilitySet' = $vm.AvailabilitySetReference.Id }
  $vmStatus = $vm | Get-AzureRmVM -Status
  $vmInfo.Status = $vmStatus.Statuses[1].DisplayStatus
  $vmInfoStatus = $vmStatus.Statuses[1].DisplayStatus
  Write-Host -NoNewline "Get status `("
  if ($vmInfoStatus -eq "VM deallocated")
  {
    Write-Host -ForegroundColor Magenta -NoNewline "$vmInfoStatus"
  }
  elseif ($vmInfoStatus -eq "VM stopped")
  {
    Write-Host -ForegroundColor Yellow -NoNewline "$vmInfoStatus"
  }
  elseif ($vmInfoStatus -eq "VM generalized")
  {
    Write-Host -ForegroundColor Gray -NoNewline "$vmInfoStatus"
  }
  else
  {
    Write-Host -ForegroundColor White -NoNewline "$vmInfoStatus"
  }
  Write-Host -NoNewline "`)... "
  $VMagain = (Get-AzureRmVm -ResourceGroupName $vm.ResourceGroupName -Name $vmname)
  $NifName = ($VMagain.NetworkProfile[0].NetworkInterfaces.Id).Split('/') | Select-Object -Last 1
  $MyInterface = (Get-AzureRmNetworkInterface -Name $NifName -ResourceGroupName $VMagain.ResourceGroupName).IpConfigurations
  $PrivIP = $MyInterface.privateipaddress
  $vmInfo.PrivateIPAddress = $PrivIP
  Write-Host -NoNewline "Getting Private IP `($PrivIP`)... "
  try
  {
    $PubIPName = (($MyInterface).PublicIPAddress.Id).split('/') | Select-Object -Last 1
    $vmPublicIpAddress = (Get-AzureRmPublicIpAddress -Name $PubIPName -ResourceGroupName $Vmagain.ResourceGroupName).IpAddress 
    Write-Host -NoNewline "Getting public IP `("
    Write-Host -ForegroundColor Cyan -NoNewline "$vmPublicIpAddress"
    Write-Host -NoNewline "`)... "
    $vmInfo.PublicIPAddress = $vmPublicIpAddress
  }
  catch
  {
    Write-Host -NoNewline "No public IP... "
  }
  Write-Host -NoNewline "Add server object to output array... "
  $vmobjs += $vmInfo
  Write-Host "Done."
}  
Write-Host "Writing to output file: $VmsOutFile"
$vmobjs | Export-Csv -NoTypeInformation -Path $VmsOutFile
Write-Host "...Complete!"



I hope that helps!

New Series – Using PowerShell, Azure Automation, and OMS

2017-08-11T19:15:26+00:00 August 3rd, 2017|Azure, blog|

I’ve just recently begun releasing my new blog series on PowerShell.org – Using PowerShell, Azure Automation, and OMS.  This series is designed to help you become familiar with using Microsoft’s Operations Management Suite’s alerting capability to trigger runbooks in Azure Automation.  I highly encourage you to read through the series as it releases over the next couple of weeks.

Part I – Azure Automation Account Creation and Adding Modules – This article walks you through creating a new Azure Automation account and uploading your own custom modules to Azure for use in your on-prem and cloud-based solutions.

Part II – Configuring Azure Automation Runbooks And Understanding Webhook Data – Walks you through creating your first Azure Automation runbook and breaking down Operations Management Suite’s Webhook data.

Part III – Utilizing Webhook Data in Functions and Validate Results – Takes you through utilizing OMS Webhook data and passing it to your functions in Azure Automation to automatically remediate issues for you.

I’ll be updating the links here as the articles go live.  I hope you enjoy the series!

 

Error Code 0xC1900208 and Workaround…

2017-07-27T01:15:46+00:00 August 2nd, 2017|blog, Windows 10|

Windows 10 Compatibility checks + Intel Display Adapters + KB4022719 = 0xC1900208

If you’re in the middle of upgrade testing, you may be very well versed in the 0xC1900208 error code, which indicates a compatibility check failure for the Windows 10 in-place upgrade process.  When reviewing the compatibility results, you may find that your system reports you’ll have issues with your display adapter in Windows 10.  The block is a hard block and the upgrade will not proceed.

The failure may be due to the June Rollup KB4022719, which takes one step forward and resolves a compatibility issue with AMD display adapters, but also creates a new compatibility failure for Intel Display adapters.

Microsoft has not noted this in the comments and do not seem to be issuing any fixes yet.  The recommendation is to uninstall the display adapters as opposed to uninstalling the security updates.

I was recently at a customer site where this issue presented itself on HP 850 Model G1/G2/G3 devices and a workaround needed to be developed for their in-place upgrades to succeed.  Instead of asking users to uninstall the display adapter and driver manually prior to the upgrade, we decided to take advantage of the devcon.exe file that comes with the Windows Driver Kit.

A Link to DevCon.exe information: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon

High-Level Steps

Three steps were required to provide this workaround:

  1. Device Installation settings must be configured to never install driver software from Windows Update (as in the figure below).  This prevents the system from connecting online and reinstalling the driver after you uninstall.
  2. The display adapter needs to be removed.
  3. The OEM driver needs to be deleted.

Additional Details

Step 1 can be automated in a task sequence step using the REG command:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching /t REG_DWORD /v SearchOrderConfig /d 0x0 /f

For steps 2 and 3, a custom script was developed in PowerShell that utilizes devcon.exe to remove the associated display adapter and delete the OEM driver associated with the specific hardware.  The commands are as follows:

Devcon.exe remove <hardware ID>

Devcon.exe dp_delete <OEMDriver.INF>

To Find the Hardware ID for the models that are failing to pass the compatibility checks, we simply opened device manager and viewed the properties of the display adapter causing the issue.  On the details tab, you can review the Hardware ID property and grab the ID listed first in the list (see figure below).

Once we obtained the hardware ID, we then parsed through all drivers using the following command and scriptomagically grabbed the appropriate INF file name to delete.  The Command to parse is devcon.exe dp_enum.

So a quick sample of the commands would be as follows:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching /t REG_DWORD /v SearchOrderConfig /d 0x0 /f

devcon.exe remove "*pci\ven_8086&dev_1616&subsys_2216103c&rev_09*"

devcon.exe dp_delete OEM56.inf

The reg add command replaces whatever value is in the SearchOrderConfig with the appropriate value to tell the system NOT to go to windows update for driver updates.  The second command will remove the device associated with the hardware ID you specified.  The third command will remove the driver associated with the display adapter.  Note that in the above list of commands, OEM56.inf is just an example.  You will need to enumerate all your installed devices to determine which INF file to remove.

So, in summary:

Intel Display Adapters in, at least, certain HP models, no longer pass compatibility checks with Windows 10 v1703.  You must turn off automatic updating of display adapters in Windows, remove the display adapter, remove the driver associated with the display adapter (so that it will not find the local copy), and then run your upgrade.  Doing so will allow your system to pass the compatibility check that is now failing since the June Rollup was deployed.

Hopefully this will save some of you the headaches and troubleshooting steps we ran into.

Happy Upgrading!