Richard Spitz - Cloud Solution Architect at Microsoft https://docs.microsoft.com/archive/blogs/rspitz/feed.xml Thu, 24 Jan 2019 01:01:16 GMT en-US hourly 1 Synchronously copy all managed disks of an Azure Virtual Machine to Azure Storage Accounts in multiple Azure regions https://docs.microsoft.com/archive/blogs/rspitz/synchronously-copy-all-managed-disks-of-an-azure-virtual-machine-to-azure-storage-accounts-in-multiple-azure-regions Thu, 24 Jan 2019 00:59:41 GMT https://blogs.technet.microsoft.com/rspitz/?p=605 https://github.com/richardspitz/imagefactory Leave me a comment  either on here or on the repo and let me know what you think! Richard Spitz Cloud Solution Architect Microsoft Silicon Valley]]> How to study for the "70-535: Architecting Microsoft Azure Solutions" certification https://docs.microsoft.com/archive/blogs/rspitz/how-to-study-for-the-70-535-architecting-microsoft-azure-solutions-certification Wed, 23 May 2018 14:11:33 GMT https://blogs.technet.microsoft.com/rspitz/?p=555 Mark Russinovich (I joined Microsoft the same year he did!) and his suite of Sysinternals tools, that are still saving many a sysadmin on a daily basis. In much the same way, studying for and passing 70-535 gives me a sense of validation and satisfaction in the fact that several years ago when I first heard about the Cloud Solution Architect role at Microsoft, I knew that was the next role for me. However, one of the key challenges to (officially) testing your knowledge of Azure is that same rapid transformation that makes it better each day. How do you learn about a platform and the services it offers when what you learn today may be obsolete six months down the line? Here are my recommendations for a 70-535 study plan that not just helps you pass the exam, but gives you a new appreciation for just how many services Microsoft Azure has to offer. Microsoft certifications, like most professional IT certifications are meant to prove your skills on the platform in question and experience counts. If you've not worked on Azure before and would like to start preparing for the certification right away, my advice is to take a step back and either find Azure work inside your organization or set aside a few months to get some hands-on in your spare time.
  1. If you don't already have an Azure subscription, check if your organization has Visual Studio subscriptions (formerly MSDN subscriptions) for employees, which give you access to USD150 of credit a month. If not, sign up for a free trial of Azure.
  2. Book the exam as the first step, but not more than a month out.
  3. Review the 70-535 Exam page for the "Skills measured" section.
  4. Check the page for the latest Exam 535 change document (currently 22 March 2018) that is linked on the same page.
  5. Download and print the change document. Use this to check services off the list, as you're done learning about them. In addition to being a checklist, it also calls out changes (in red) and new additions (blue) since the last update to the exam.
  6. Buy the kindle version of Sjoukje Zaal's exam guide and use this as the starting point for each topic. This currently appears to be the only 70-535 guide out there at the moment. (Haishi Bai and co have one coming out on 14 June 2018 as well which might be worth checking out. I have his Service Fabric book which is quite good)
  7. Find an order you feel comfortable with and begin right away. I started with "Design Networking Implementation" since that's my primary area of expertise.
  8. For each service that you read about in the book whether or not the book has a sample, navigate to the official Azure documentation and play around with the "Quickstart" samples. The official Azure documentation is without a doubt the definitive source for whichever service you're learning about. What's more, the documentation is now GitHub-based and therefore as nimble as can be. I found that within days, I'd understood and knew how to configure services that I'd only previously heard about, whether it was setting up an IoT Hub Device Provisioning Service, deploying Service Fabric Linux container applications or building a data pipeline using Data Factory. Here's how I recommend you navigate to these samples:  
    • Click "Products" and search for the service you'd like to learn about.
     
    • Click "Documentation".
     
    • Pick a Quickstart!
  9. Even though the documentation has the option to "Copy" commands (PowerShell, CLI), type these out manually to get a feel for them.
  10. For Quickstarts with options to use the Azure Portal, PowerShell or CLI, be sure to use the portal first as the portal UI offers a more "rememberable" experience especially in terms of the options available. Once you've deployed a service using the portal, you could deploy once more using either PowerShell or the Azure CLI. Use a good mix of both tools.
  11. Delete or stop services such as Virtual Machines to prevent them from using up all your free credit!
  12. Don't shy away from deploying a Quickstart if the exam guide does not include one or the Azure documentation appears complex. Deploy as many services as possible in as many ways as possible and you'll know exactly what to answer come exam time.
  13. The menu on the documentation page will almost always have a "Concepts" page. Be sure to peruse it to get a deeper understanding of the service.
  14. For services that enable connectivity to on-premises resources such as Active Directory Domain Controllers (Azure AD Connect), On-Premises Data Gateway (Azure Analysis Services, Logic Apps), WCF or newer relay based applications (Service Bus Relay), deploy those resources inside Azure Virtual Machines. Using this approach, you'll be able to get hands-on with pretty much any Azure service other than ExpressRoute.
  15. Be sure to check out and familiarize yourself with ARM templates. An excellent source is: https://github.com/Azure/azure-quickstart-templates
  16. Finally, refer back to the exam guide for topics such as best practices and architectural know-how, which are covered in the Azure documentation as well but the guide brings various sources together on one page.
That's it for now. I will add to this list if I recollect other tips and tricks that helped me pass the 70-535 exam. Best of luck! Richard Spitz Cloud Solution Architect Microsoft]]> PowerShell script to determine if an IP Range is part of the Azure Datacenter IP Range https://docs.microsoft.com/archive/blogs/rspitz/powershell-script-to-determine-if-an-ip-range-is-part-of-the-azure-datacenter-ip-range Fri, 02 Mar 2018 13:10:35 GMT https://blogs.technet.microsoft.com/rspitz/?p=495 an XML document that contains the IP address ranges (including Compute, SQL and Storage ranges) used in the Microsoft Azure Datacenters. An updated file is posted weekly which reflects the currently deployed ranges and any upcoming changes to the IP ranges. Working with Virtual Network Service Endpoints, I found that enabling the Microsoft.SQL endpoint (Azure SQL Database) added a route to my Azure Virtual Network's route table with a set of public IP ranges, all of which presumably are attached to the Azure SQL Database infrastructure.     However, "presumably" doesn't quite cut it when it comes to configuring firewalls. Clicking Download will fetch you a CSV file with the last row giving you the Azure SQL Database Infrastructure IP Ranges. A nifty bit of manual text editing later, this is what I had:     Notice I've added in a couple of dummy IP addresses, 1.1.1.1/32 and 2.2.2.2/32, to exhibit how the output is presented if IP Ranges don't belong to the Azure Datacenter IP Ranges. If you've worked with networks and IP addresses, you'll know that these tend to be some of the most misunderstood concepts in IT. I found this out for myself when many years ago, I needed to understand how Hyper-V Network Virtualization worked. The point being, determining which IP range fits into which other IP Range is something best left to PowerShell! Why PowerShell? Because it has been a while since I wrote my last script and did not want to pass on the chance to brush up my skills. The most important part of the script is, of course, the logic that checks whether one IP Range is a part of another. Before you set out to write any script, a best practice is to check if one exists on the Internet and play around with it. It didn't take to long to come across what, in my opinion, is a perfectly written piece of code that I could just plug my script into. Shout-out to Luben Kirov from GI Architects, whose code is available here: https://www.gi-architects.co.uk/2016/02/powershell-check-if-ip-or-subnet-matchesfits/ I simply dropped all his code into a PSM1 file - a PowerShell Module - and import it in my script to use the checkSubnet function. That done, all I had to do was build the plumbing around that function, using the Azure Datacenter IP Range XML, the input file I created above and a whole lot of For Loops. Finally, it pays to always output an object at the end of the script. Why, you may ask. Because if you don't, Ed "The Microsoft Scripting Guy" Wilson will hunt you down and make you do it. Also, because there are so many other advantages - creating reports, passing your script on a pipeline, never again using Write-Host. The end result:     Here's the script, quick and dirty - no error checking, just a tiny bit of optimization. As always, let me know in the comments if this helps you! Richard Spitz Cloud Solution Architect Microsoft  

# ******************************************************************************************************************************

# Script to check a set of IP Address Ranges and determine if they belong to the Azure DataCenter IP Address Ranges

# Author: Richard Spitz, Cloud Solution Architect, Microsoft

#

# Usage: Check-AzurePublicIP.ps1 -AzurePublicIPFilePath <Path to Azure Public IP file> -InputFilePath <Path to Input IP Range>

#

# Example: Check-AzurePublicIP.ps1 -AzurePublicIPFilePath ".\PublicIPs_20180226.xml" -InputFilePath ".\AzSQLSvcEndpoints.txt"

#

# Prerequisites: See ***DO THIS*** comments below

#

# ******************************************************************************************************************************

 

# ***DO THIS***

# Download the latest Azure Datacenter Public IPs list from https://www.microsoft.com/en-us/download/details.aspx?id=41653

# InputFile needs to be a text file with the Public IP ranges you want to check, with each value on a new line

param (

        [string]$AzurePublicIPFilePath =  ".\PublicIPs_20180226.xml",

 

        [string]$InputFilePath = ".\AzSQLSvcEndpoints.txt"

 

       )

 

# ***DO THIS***

# Save the entire code from https://www.gi-architects.co.uk/2016/02/powershell-check-if-ip-or-subnet-matchesfits/

# to CheckSubnet.PSM1 in the same directory as this script file

Import-Module .\CheckSubnet.psm1

 

[xml]$AzurePublicIPs = Get-Content -Path $AzurePublicIPFilePath

$inputFile = Get-Content -Path $InputFilePath

[int]$rangeFound = 0

[string]$range = ""

[string]$region = ""

$outputObjectArr = @()

 

# Loop through the Input file, which contains IP ranges to check

For($l = 0; $l -lt $inputFile.Length; $l++)

{

    # Indicate progress

    Write-Host "." -NoNewline

 

    # Reset RangeFound Counter for every new IP Range from the InputFile

    $rangeFound = 0

   

    # Loop through each Region node within the XML object

    For($i = 0; $i -lt $AzurePublicIPs.AzurePublicIpAddresses.Region.Length;$i++)

    {

 

        # Loop through each IP Range within the XML object, to test the Subnet within it

        For($j = 0; $j -lt $AzurePublicIPs.AzurePublicIpAddresses.Region[$i].IpRange.Length; $j++)

        {

   

            # Store current IP Range Subnet as a string

            [string]$currentPublicIP = $AzurePublicIPs.AzurePublicIpAddresses.Region[$i].IpRange[$j].Subnet

 

 

            # Quick and dirty first octet check optimization that cuts down script execution time

            If(($currentPublicIP.Split("."))[0] -like ($inputFile[$l].Split("."))[0])

            {

 

            # Test the "Condition" property of the returned object from the checkSubnet function (which is

            # defined within the CheckSubnet.psm1 module we imported). If true, increment a counter to

            # indicate that our IP Range was found

                If((checkSubnet $currentPublicIP $inputFile[$l]).Condition)

                {

       

                    $rangeFound++

 

                    # Store values to report later

                    $range = $currentPublicIP

                    $region = $AzurePublicIPs.AzurePublicIpAddresses.Region[$i].Name

       

                }

           

            }

   

        }

 

    }

 

    # Create a new object with details and add it to list of output objects, using the "Exists" NoteProperty to

    # indicate whether the Input IP Range exists within the Azure IP Range or not

    If($rangeFound)

    {

       

        $tempObj = New-Object -TypeName PSObject

        $tempObj | Add-Member -MemberType NoteProperty -Name InputIPRange -Value $inputFile[$l]

        $tempObj | Add-Member -MemberType NoteProperty -Name AzureIPRange -Value $range

        $tempObj | Add-Member -MemberType NoteProperty -Name Region -Value $region

        $tempObj | Add-Member -MemberType NoteProperty -Name Exists -Value "Yes"

        $outputObjectArr += $tempObj

        Remove-Variable tempObj

       

    }

    else

    {

       

        $tempObj = New-Object -TypeName PSObject

        $tempObj | Add-Member -MemberType NoteProperty -Name InputIPRange -Value $inputFile[$l]

        $tempObj | Add-Member -MemberType NoteProperty -Name AzureIPRange -Value "N.A."

        $tempObj | Add-Member -MemberType NoteProperty -Name Region -Value "N.A."

        $tempObj | Add-Member -MemberType NoteProperty -Name Exists -Value "No"

        $outputObjectArr += $tempObj

        Remove-Variable tempObj

       

    }

 

}

 

# Dispay Output

Write-Host " "

$outputObjectArr

 

 ]]> Just enough BGP to get your Azure dual-redundancy, active-active VPN gateways up and running https://docs.microsoft.com/archive/blogs/rspitz/just-enough-bgp-to-get-your-azure-dual-redundancy-active-active-vpn-gateways-up-and-running Mon, 19 Feb 2018 15:33:02 GMT https://blogs.technet.microsoft.com/rspitz/?p=325 dual-redundancy: active-active VPN gateways for both Azure and on-premises networks option to connect your Azure Virtual Network to your on-premises network using the Azure Virtual Network Gateway. No Azure ExpressRoute here. For the purpose of this walk-through, my entire setup is in Azure however you could replace the second Azure Virtual Network Gateway (in VNET2) with your on-premises VPN device. I am not using VNET Peering specifically to illustrate how Azure to on-premises connectivity can be configured. This post also assumes some familiarity with basic networking concepts such as IP addresses, address spaces, subnets and Azure services such as Azure Virtual Networks and Virtual Network Gateways. If you're not familiar with the Azure Virtual Network Gateway, you can get started with the official Azure documentation for this service. We will use the Azure Portal, as I see cross-premises connectivity configuration as a one-time or one-off configuration and potentially not worth the effort required to understand Azure PowerShell, if you're not already familiar with it. That said, I'm a big fan of the Azure CLI, Azure PowerShell and ARM templates for any task that has even the slightest possibility of being repeatable. You could also argue that maintaining a record of the configuration is much easier to do with these technologies than with screenshots of the Azure Portal (which is bound to change over time), in which case, the article you should peruse is this one. Before beginning the configuration, I needed to understand what BGP - Border Gateway Protocol and ASN - Autonomous System Number are, and what I had to enter into my Azure Virtual Network Gateway configuration for the BGP and ASN fields. Without giving you the "Network Guru" version (I'm as far from one as can be), BGP is the protocol that network routers (on the internet and also on private networks) use to "exchange" routes and router "availability" information. As far as router availability goes, there's nothing for us to configure here and so we move on to the routes that are exchanged. It also helps to take note of the fact that you're almost certainly configuring this on a private network - your "private" Azure Virtual Network to your "private" on-premises network. This internet/private difference matters, as we'll see later on, with ASN. The aforementioned routes that need to be exchanged are nothing but the address spaces/networks/subnets behind your Azure Virtual Network Gateway. Before BGP, these were the static "Address Prefixes" you'd include in your "Local Network Gateway" to let the router at the other end know that to reach these networks, they'd need to route the traffic via you. With BGP, there is no need to statically specify these address spaces/networks/subnets. BGP automatically exchanges this information with your router's "peers". So what you need to specify instead of a static address space, is actually the "BGP Peer IP address" of the router being represented by the "Local Network Gateway" in CIDR format (example: 192.168.0.228/32). For your on-premises VPN device (router), your network admin should give you this. This address is a private IP address and differs from the public IP addresses of the on-premises VPN devices and Azure Virtual Network Gateway that are used to set up the IPsec tunnel. Coming to ASN (or AS Number), my "just enough" explanation is that this is a unique number assigned to your on-premises VPN device (router) as well as Azure VPN Gateway by your on-premises network admin/team. Why should it be issued by them? Because just like an IP address space/network/subnet, this needs to be unique across your entire private/corporate network. Why does it need to be unique? When BGP on a router learns about a route that has its own ASN in its path then it will be discarded. On then, to the key difference between an Internet ASN and a private ASN. The former can only be issued by IANA, while the latter is issued by your network team (or for testing, you could use a private ASN except these. I generally use 65516 for one Azure VPN Gateway and 65521 for the other one that mimics my on-premises VPN device). With that lengthy but necessary primer out of the way, it's time to move on to the walk-through. This is our proposed network architecture:     We start by creating our Virtual Networks, VNET1 in Southeast Asia and VNET 2 in US East 2. In each Virtual Network, create the Gateway subnet. Shown below is the Gateway Subnet creation for VNET1.Perform the same set of steps for VNET2, but use 10.0.1.240/28 as the Address range. Leave other settings at their default values. For each of the Virtual Networks, create a Virtual Network Gateway. Remember to use the VpnGw1 or higher SKU. The lower SKUs don't support this configuration. Shown below is the Virtual Network Gateway creation for VNET1.Perform the same set of steps for VNET2, but use 65521 as the ASN. For both Gateways, create new "Basic" Public IPs following the on-screen UI "blades", for First and Second IP configurations.To locate the appropriate VNET, first set the "Location" property to Southeast Asia (VNET1)/East US 2 (VNET2).   Next we create a "Local Network Gateway" per instance of the remote Azure Virtual Network Gateway. The Local Network Gateway is nothing but a means to save the configuration for the remote (or on-premises) VPN device. Referring to the network architecture diagram at the beginning of this post, each instance of the Azure Virtual Network Gateway on VNET2 is the remote (assume on-premises) VPN device for the Azure Virtual Network Gateway on VNET1. As the Azure Virtual Network Gateway on VNET2 is active-active, we need to configure two Local Network Gateways, each representing one instance. The details we configure for our Local Network Gateway to be used by the Azure Virtual Network Gateway in VNET1 are those from the Azure Virtual Network Gateway in VNET2. LocalNetworkGateway1-SEAsia: IP Address: 52.232.247.238 (Public IP Address of first instance of remote Azure Virtual Network Gateway) Address Space: 10.0.1.244/32 (First BGP Peer IP Address in CIDR format) ASN: 65521 (ASN of Azure Virtual Network Gateway in VNET2) BGP Peer IP Address: 10.0.1.244 (First BGP Peer IP Address) Resource Group: VNET1RG (Resource Group of VNET1) Location: Southeast Asia (location of VNET1)     Next, using the second set of IP addresses, we configure the Local Network Gateway for the second instance of the Azure Virtual Network Gateway in VNET2: LocalNetworkGateway2-SEAsia:
IP Address: 52.232.247.4 (Public IP Address of second instance of remote Azure Virtual Network Gateway) Address Space: 10.0.1.245/32 (Second BGP Peer IP Address in CIDR format) ASN: 65521 (ASN of Azure Virtual Network Gateway in VNET2) BGP Peer IP Address: 10.0.1.245 (Second BGP Peer IP Address) Resource Group: VNET1RG (Resource Group of VNET1) Location: Southeast Asia (location of VNET1)
      Now, we create the Local Network Gateways for the Azure Virtual Network Gateway in VNET2, treating the Azure Virtual Network Gateway in VNET1 as the remote VPN device. Using the guidance above, collate the values from the Azure Portal required for the configuration using the Azure Virtual Network Gateway in VNET1. LocalNetworkGateway1-EastUS2:
IP Address: 52.187.135.207 (Public IP Address of first instance of remote Azure Virtual Network Gateway) Address Space: 192.168.1.244/32 (First BGP Peer IP Address in CIDR format) ASN: 65516 (ASN of Azure Virtual Network Gateway in VNET2) BGP Peer IP Address: 192.168.1.244 (First BGP Peer IP Address) Resource Group: VNET2RG (Resource Group of VNET2) Location: East US 2 (location of VNET2)
LocalNetworkGateway2-EastUS2: IP Address: 52.163.240.185 (Public IP Address of second instance of remote Azure Virtual Network Gateway) Address Space: 192.168.1.245/32 (Second BGP Peer IP Address in CIDR format) ASN: 65516 (ASN of Azure Virtual Network Gateway in VNET2) BGP Peer IP Address: 192.168.1.245 (Second BGP Peer IP Address) Resource Group: VNET2RG (Resource Group of VNET2) Location: East US 2 (location of VNET2)   Finally, from a configuration standpoint, we need to create a "Connection" from each Azure Virtual Network Gateway to a Local Network Gateway, which represents each instance of the remote VPN device.   Though we only need to create one "Connection" from the Azure Virtual Network Gateway to one instance of the remote VPN device, internally, the Azure Virtual Network Gateway sets up two IPsec tunnels to the instance of the remote VPN device - one from each instance of the Azure Virtual Network Gateway. This means at the end of the configuration, we have full-mesh connectivity.   First Connection: Connection type: Site-to-site (IPsec) (Type of tunnel for on-premises VPN device connectivity) Resource Group: VNET1RG (Resource Group of VNET1) Location: Southeast Asia (Location of VNET1) Virtual Network Gateway: VNET1-GW (Azure Virtual Network Gateway in VNET1) Local Network Gateway: LocalNetworkGateway1-SEAsia (Local Network Gateway representing first instance of Azure Virtual Network Gateway in VNET2) Connection Name: AUTO POPULATED Shared key (PSK): USE YOUR OWN STRONG KEY (use SAME value for all subsequent Connections) Enable BGP: Checked       Similarly, create another connection. Second Connection: Connection type: Site-to-site (IPsec) (Type of tunnel for on-premises VPN device connectivity) Resource Group: VNET1RG (Resource Group of VNET1) Location: Southeast Asia (Location of VNET1) Virtual Network Gateway: VNET1-GW (Azure Virtual Network Gateway in VNET1) Local Network Gateway: LocalNetworkGateway2-SEAsia (Local Network Gateway representing the second instance of Azure Virtual Network Gateway in VNET2) Connection Name: AUTO POPULATED Shared key (PSK): USE YOUR OWN STRONG KEY (use SAME value as previous connection) Enable BGP: Checked Now, switching over to the Azure Virtual Network Gateway in VNET2, we create two more Connections. First Connection: Connection type: Site-to-site (IPsec) (Type of tunnel for on-premises VPN device connectivity) Resource Group: VNET2RG (Resource Group of VNET2) Location: East US 2 (Location of VNET2) Virtual Network Gateway: VNET2-GW (Azure Virtual Network Gateway in VNET2) Local Network Gateway: LocalNetworkGateway1-EastUS2 (Local Network Gateway representing first instance of Azure Virtual Network Gateway in VNET1) Connection Name: AUTO POPULATED Shared key (PSK): USE YOUR OWN STRONG KEY (use SAME value for all subsequent Connections) Enable BGP: Checked Second Connection: Connection type: Site-to-site (IPsec) (Type of tunnel for on-premises VPN device connectivity) Resource Group: VNET2RG (Resource Group of VNET2) Location: East US 2 (Location of VNET2) Virtual Network Gateway: VNET2-GW (Azure Virtual Network Gateway in VNET1) Local Network Gateway: LocalNetworkGateway2-EastUS2 (Local Network Gateway representing the second instance of Azure Virtual Network Gateway in VNET1) Connection Name: AUTO POPULATED Shared key (PSK): USE YOUR OWN STRONG KEY (use SAME value as previous connection) Enable BGP: Checked   That's it! You should now have dual-redundancy, active-active VPN gateways configured and running. But wait, you'd like to verify all your hard work, after all. Take a look at both your Azure Virtual Network Gateways. Under connections, this is what you should see:       ...and BGP and all that talk about exchanging routes and so on? Install Azure PowerShell and log into Azure: Add-AzureRmAccount Then run: Get-AzureRmVirtualNetworkGatewayBGPPeerStatus -ResourceGroupName VNET1RG -VirtualNetworkGatewayName VNET1-GW     Bonus Tip: Check out this Azure PowerShell cmdlet. It generates a VPN device specific configuration script for your Azure Virtual Network Gateway configuration that you could share with your network team to configure the on-premises VPN device. Get-AzureRmVirtualNetworkGatewayConnectionVpnDeviceConfigScript -DeviceFamily "IOS (ISR, ASR)" -DeviceVendor Cisco -FirmwareVersion "15.x (IKEv2)" -Name VNET1-GW-LocalNetworkGateway1-SEAsia -ResourceGroupName VNET1RG   If you're wondering what VNET1-GW-LocalNetworkGateway1-SEAsia in the command is, it's the auto-generated name for one of the connections we configured. Navigate to Azure Virtual Network Gateway --> Connections to get this value. To get the supported VPN device details to plug into the command above, run this Azure PowerShell cmdlet: Get-AzureRmVirtualNetworkGatewaySupportedVpnDevice -ResourceGroupName VNET1RG -Name VNET1-GW   If this article helped you, let me know in the comments section. Richard Spitz Cloud Solution Architect Microsoft]]> How to hot-add a Shared VHDX https://docs.microsoft.com/archive/blogs/rspitz/how-to-hot-add-a-shared-vhdx Fri, 24 Jan 2014 06:55:00 GMT https://blogs.technet.microsoft.com/rspitz/2014/01/24/how-to-hot-add-a-shared-vhdx/ Shared VHDX, a new feature in Windows Server 2012 R2, is a boon for administrators wanting to create a Failover Cluster running in Hyper-V virtual machines. Create a VHDX, attach it to the SCSI Controller of a virtual machine, tick "Enable virtual hard disk sharing" under Advanced Features of the Hard Drive (Click the little '+' to access Advanced Features). Repeat for as many virtual machines you want, power them up and you're good to go!

Now you've set up your Failover Cluster and everything's just jolly. Then you get a request to add more storage capacity to the Failover Cluster. At this point, you're thinking - No Sweat! You fire up Hyper-V Manager, create a new VHDX, then go to Failover Cluster Manager to attach it to the first virtual machine as shared, go to the second virtual machine, do the same thing.

BOOM!

Error applying Hard Drive changes

'VM2' failed to add device 'Virtual hard Disk'. (Virtual machine ID XYZ)

Failed to open attachment 'C:\ClusterStorage\Volume1\SharedDisk.vhdx'. Error: 'The requested operation cannot be performed on the virtual disk as it is currently used in shared mode.'. 

Wow - so much for 'No Sweat'! What's going on here?!?

What's going on is that you've very likely not checked the "Enable virtual hard disk sharing" checkbox under Advanced Features before hitting the "Apply" button. Ensure that you've done that and you're good to go.

If you can't be bothered with the GUI, there's always PowerShell!

For every virtual machine that you want to add the Shared VHDX to, run this command (Import the Hyper-V module if you haven't already done so - 'Import-Module Hyper-V'):

Add-VMHardDiskDrive -VMName VM2 -Path C:\ClusterStorage\Volume1\SharedDisk.vhdx -ShareVirtualDisk

If you have Clustered Hyper-V, remember to run the command on the node where the virtual machine is hosted.

That's all, Folks!

Thanks to my colleague and buddy Surinder Singh for pointing this out to me. You really do learn something new everyday.

]]> My First (Useful) PowerShell Script! https://docs.microsoft.com/archive/blogs/rspitz/my-first-useful-powershell-script Fri, 26 Jul 2013 00:19:00 GMT https://blogs.technet.microsoft.com/rspitz/2013/07/26/my-first-useful-powershell-script/ Heard of PowerShell? No? Just Kidding! Even if you run your IT department under a rock or on Mars, you've heard of PowerShell - It's that ubiquitous!

I've always been interested in picking it up as a skill, it is an extremely useful skill to have, however, I've never had the time and when I've had the time, I've been lazy. The question always was when will I find the time? Well, as the old adage goes, there's no time like the present.

I was in the process of configuring my new work laptop, running Windows 8, with Client Hyper-V. I had all my Sysprep'ed VHD/VHDX files in a folder and was about to follow this process to create new virtual machines:

  1. Create a new differencing disk, with the parent disk being one of the sysprep'ed VHD/VHDX files (I have one for every version of Windows)
  2. Create a new virtual machine and point it to the VHD/VHDX create in the previous step.

These steps are all well and good if you only want to set up a couple of virtual machines. However, if you find yourself performing these steps over and over again, you'll come to hate that little 'Next' button on the New Hard Disk or New Virtual Machine wizards. Enter PowerShell.

I fired up the PowerShell ISE (Enable Admin Tools on the Start Screen - Settings - Tiles), built the commands using the Command Add-On (View Menu - Show Command Add-on) and voila! My first PowerShell Script!

$VMOS = $args[0]
$VMName = $args[1]
$DiskExtn = ".vhd"

if ($VMOS -eq "WIN2012") {$DiskExtn = ".vhdx"}
elseif($VMOS -eq "WIN8") {$DiskExtn = ".vhdx"}

$VHDParentPath = "C:\HyperV\BaseVHDs\" + $VMOS + $DiskExtn
$VHDPath = "C:\HyperV\VHDs\" + $VMName + $DiskExtn
$VMPath = "C:\HyperV\VMs\" + $VMName

New-VHD -ParentPath $VHDParentPath -Path $VHDPath
New-VM -VHDPath $VHDPath -MemoryStartupBytes 1073741824 -Name `
$VMName -Path $VMPath -SwitchName VM2VM

That's it. 15 minutes, a bit of Binging for PowerShell Syntax and I can now create a new virtual machine with any version of Windows, in a few keystrokes and 10 seconds.

]]> Field, Here I Come! https://docs.microsoft.com/archive/blogs/rspitz/field-here-i-come Wed, 24 Jul 2013 10:01:00 GMT https://blogs.technet.microsoft.com/rspitz/2013/07/24/field-here-i-come/ Now and again, a colleague or customer points to my blog, having run into one of the issues I've described in a post. It's at these times that I remember I have a blog! My last post was over two years ago, but I won't make any excuses for not posting and will get right back into it.

I have moved into a new role at Microsoft, as a Premier Field Engineer and will be responsible for delivering workshops, health checks, deployments and onsite support to Microsoft's Premier Customers in India. This role takes me away from the world of troubleshooting I've known for the last 8 years and, clichéd as it may sound, shows me the bigger picture from conceptualization to design and then implementation and finally maintenance. 

The theme of my blog so far has been troubleshooting issues and while I will post a weird and undocumented-anywhere-else issue that I've resolved every once in a while, the majority will deal with new features in Windows, configuring those features, tuning them if required and the like.

My areas of expertise are Failover Clustering and Virtualization using Hyper-V, however, I look forward to dabbling in capacity planning, performance tuning and deployment.

With that said, I'm going back to hit the (e)books and will have something up here soon. I promise!

]]> Cluster service fails to start on Windows Server 2008 SP2, cluster.log contains “Too many failures while attempting to start RHS process.” https://docs.microsoft.com/archive/blogs/rspitz/cluster-service-fails-to-start-on-windows-server-2008-sp2-cluster-log-contains-too-many-failures-while-attempting-to-start-rhs-process Thu, 24 Nov 2011 02:48:00 GMT https://blogs.technet.microsoft.com/rspitz/2011/11/24/cluster-service-fails-to-start-on-windows-server-2008-sp2-cluster-log-contains-too-many-failures-while-attempting-to-start-rhs-process/ It’s been a while since my last post – not due to the dearth of interesting issues to blog about, rather, there have been TOO many issues, interesting and otherwise. Too many issues == too much work!

Nonetheless, this particular issue was interesting enough to make me take some time out, despite my busy schedule, and write about it.

On one node of a Windows Server 2008 SP2 Failover Cluster, the Cluster service would start, then terminate within a few seconds. If you run a cluster log /g and review C:\Windows\Cluster\Reports\cluster.log, you’ll see this:

 

00001928.00000f2c::2011/11/23-07:05:30.498 INFO  [RCM] Created monitor process 5828 / 0x16c4
00001d10.00001228::2011/11/23-07:05:31.496 INFO  [RHS] Initializing.
00001928.00000f2c::2011/11/23-07:05:31.590 INFO  [RCM] Created 32-bit monitor process 3800 / 0xed8
00001928.00000f2c::2011/11/23-07:05:35.068 WARN  [RCM] rcm::RcmMonitor::StartMonitor: Retrying...
00001928.00000f2c::2011/11/23-07:05:35.068 INFO  [RCM] Created 32-bit monitor process 5340 / 0x14dc
00001928.00000f2c::2011/11/23-07:05:38.656 WARN  [RCM] rcm::RcmMonitor::StartMonitor: Retrying...
00001928.00000f2c::2011/11/23-07:05:38.656 INFO  [RCM] Created 32-bit monitor process 9564 / 0x255c
00001928.00000f2c::2011/11/23-07:05:42.337 WARN  [RCM] rcm::RcmMonitor::StartMonitor: Retrying...
00001928.00000f2c::2011/11/23-07:05:42.337 INFO  [RCM] Created 32-bit monitor process 10092 / 0x276c
00001928.00000f2c::2011/11/23-07:05:45.956 WARN  [RCM] rcm::RcmMonitor::StartMonitor: Retrying...
00001928.00000f2c::2011/11/23-07:05:45.956 INFO  [RCM] Created 32-bit monitor process 7376 / 0x1cd0
00001928.00000f2c::2011/11/23-07:05:48.608 ERR   [CORE] Node 1: exception caught ERROR_SUCCESS(0)' because of 'Too many failures while attempting to start RHS process.'
00001928.00000f2c::2011/11/23-07:05:48.624 ERR   Exception in the InstallState is fatal (status = 0)
00001928.00000f2c::2011/11/23-07:05:48.624 ERR   FatalError is Calling Exit Process.
00001928.000027d4::2011/11/23-07:05:48.624 INFO  [CS] About to exit process...
00001d10.00001228::2011/11/23-07:05:48.640 WARN  [RHS] Cluster service has terminated.
00001d10.00001228::2011/11/23-07:05:48.671 INFO  [RHS] Exiting.

 

From the log snippet, we can see that the 64 bit RHS.exe was launched with Process ID 5828, but after multiple attempts, the Cluster service is not able to launch the 32 bit RHS.exe process.

The RHS.exe process is critical to the functioning of the cluster and if it cannot launch, the Cluster service cannot run. As this is a 64 bit version of Windows, we have a 64 bit version of RHS.exe – for 64 bit Resource DLLs and a 32 bit version – for 32 bit Resource DLLs. You can think of Resource DLLs as an interface between the Cluster service and the applications(SQL, Exchange, SAP) or components(IP Address, Network Name, Physical Disks) which have Cluster resources. These DLLs provide the Cluster service with “entry points” to control the applications and components through their Cluster resources. Examples of these entry points are Open, Close, Online, Offline.

Now we know that the Cluster service fails to start on this node because it cannot launch the 32 bit RHS.exe process. Our attention therefore turns to why the 32 bit RHS.exe fails to launch.

If the Cluster service fails to launch, would we be able to launch it manually? Let’s give it a shot.

We’ve got to remember that this is the 32 bit RHS.exe, which is in C:\Windows\SysWOW64 – not C:\Windows\Cluster, which contains the 64 bit RHS.exe

Open an elevated (Administrator) command prompt, change directory to C:\Windows\SysWOW64 and run RHS.exe. Immediately, we get this error:

 

dbghelp

 

There we go! The Cluster service is not able to launch it and neither are we able to do so, manually.

Why am I excited? Because the pop-up message mentions a certain “dbghelp.dll”. The first place to look for this file would be the C:\Windows\SysWOW64 – because that’s where RHS.exe is as well.

When I browsed through the folder to look for dbghelp.dll, we found that the file was present but there was also a dbghelp.dll.old file that caught my attention.

Dbghelp.dll was about 1300kb and dbghelp.dll.old was 780kb. That’s interesting. Why? Because my lab Windows Server 2008 SP2 system has the 780kb dbghelp.dll, but not the 1300kb file.

Turns out that the Application team had a specific requirement to use the 1300kb dbghelp.dll while upgrading their clustered application, so they switched out the original file, put this one in and forgot about it. Their application may have been compatible with this new dbghelp.dll, however, RHS.exe was not, and that’s why it failed to start.

Resolving the issue now that we know the root cause is a matter of renaming the 1300kb dbghelp.dll to something else, taking ownership of the 780kb dbghelp.dll.old file, giving Administrators FULL CONTROL, renaming this file to dbghelp.dll, changing the ownership back to NT SERVICE\TrustedInstaller and changing Administrators permissions back to only Read and Read & Execute. PHEW! Issue resolved!

]]> Certain icons do not appear the first time you open Control Panel on Windows 7 https://docs.microsoft.com/archive/blogs/rspitz/certain-icons-do-not-appear-the-first-time-you-open-control-panel-on-windows-7 Thu, 16 Jun 2011 01:43:00 GMT https://blogs.technet.microsoft.com/rspitz/2011/06/16/certain-icons-do-not-appear-the-first-time-you-open-control-panel-on-windows-7/ I was over at the NTDebugging blog the other day and while browsing through the posts, I came across this one, written quite brilliantly by Matt Burrough

Control Panel Policy and the Missing Icon
https://blogs.msdn.com/b/ntdebugging/archive/2011/04/22/control-panel-policy-and-the-missing-icon.aspx

After reading a few lines, I realized why this post had piqued my interest. A colleague of mine was working on a similar issue – where System Center Configuration Manager (SCCM) control panel icons weren’t visible the first time you opened the control panel after a reboot. He was discussing this case with another colleague and I happened to overhear a bit of the conversation.

If you want to understand the cause of the issue and how he debugged it, I highly recommend that you head on over to Matt’s post. If you’d rather just fix this issue and get it over with, here’s the lowdown.

This issue only occurs when you have the “Hide specified control panel applets” or “Show only specified control panel applets” settings enabled via a group policy. In our case, the “Hide specified control panel applets” setting was enabled. This policy results in Windows attempting to read the System.ApplicationName property of every control panel icon, to determine if they should be hidden or visible. Problem is, if some of the icons do not have this property set in the registry, these icons are not displayed the first time around. Close and open control panel and they’re there. A bit odd. This is the result of an issue in the way Windows handles the missing System.ApplicationName property. As Matt mentions, the Windows development team have been made aware of this.

How do we fix this so that the missing icons appear every time the control panel is opened?

You need to create the System.ApplicationName registry key under

HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Extended Properties

Under this key, create a new string value with the name set to the path to the CPL file and value set to the System.ApplicationName property of the CPL item.

Matt’s post mentions that since the Mail icon is a inbuilt item, it's System.ApplicationName is known.

However, in our case, all missing control panel icons belong to SCCM. A search of the registry failed to locate any information about whether the SCCM CPL items even had a System.ApplicationName.

After a few moments wondering how we’re going to get past this hurdle, it came to me. Windows doesn’t display the icons the first time around only when it cannot find their System.ApplicationName property. It doesn’t matter what the System.ApplicationName property is set to, just as long as it is not in the list of hidden icons, set via group policy.

We set the System.ApplicationName property for the SCCM control panel icons in this way:

  • Configuration Manager – SMSCFGRC
  • Program Download Monitor – SMSPDM
  • Run Advertised Programs – SMSRAP
  • Remote Control – SMSRCCPL

We rebooted the system and opened the control panel. All icons are visible the first time itself. Issue worked around!

]]> How to run a script when a Resource Group fails over to the passive node of a Windows Server 2003 based MSCS Cluster https://docs.microsoft.com/archive/blogs/rspitz/how-to-run-a-script-when-a-resource-group-fails-over-to-the-passive-node-of-a-windows-server-2003-based-mscs-cluster Mon, 30 May 2011 08:19:00 GMT https://blogs.technet.microsoft.com/rspitz/2011/05/30/how-to-run-a-script-when-a-resource-group-fails-over-to-the-passive-node-of-a-windows-server-2003-based-mscs-cluster/ Having recently scripted the Cluster WMI Namespace (for fun) and blogged about it with my Cluster WMI Notifications post, I saw an opportunity to put that experience into practice here. We had a 2 node Active-Passive MSCS Cluster and the requirement was to run a custom script that did some work when a Resource Group failed over to the passive node. My plan was to kick off the custom script when we received a notification that the Resource Group had come online on the passive node.

A quick assessment of the proposed solution exposed its main flaw – that is – the script would be external to the cluster and would need to be managed separately. Any number of things could go wrong and prevent the custom script from running, which is a big no-no in a production environment.

So while I did learn a lot from testing WMI Notifications for the Cluster Namespace, it wasn’t suited to this scenario.

On then, to the next out of the box idea. Or not so out of the box. Remember a resource type called “Generic Script”? Sounds exactly like what is required here.

However, you can’t just write a script, create a “Generic Script” resource and point it to the script. If you try – as I did, while doing my research, you’ll find that the entire Cluster Administrator hangs just as you hit the Finish button on the “New Resource” wizard. This is because – as you’ll soon find out – the “Generic Script” resource DLL is looking for the Open entry point.

Scouring the internet got me this MSDN link:

Using the Generic Script Resource Type
https://msdn.microsoft.com/en-us/library/aa373089(v=VS.85).aspx

Any script that is to be configured as a “Generic Script” resource will need to contain functions named Open, Online, LooksAlive, IsAlive, Offline, Close and Terminate. These are the functions that the Cluster Resource Monitor will call to perform the relevant operations. In this way, it is different from a typical script in the same way an executable is different from a DLL. They both contain runnable code, but one can run by itself, whereas the other can’t.

For our purpose, we’ve got to call a custom script when the resource comes online on the passive node – which happens when the active node fails. This means that you put the custom script code directly into the Online function or call the custom script from a line of script in the Online function. Once the “Generic Script” resource comes online, it says online even after the script has run. This is good because you wouldn’t want the resource to go offline after it has finished its work. If it did, it would raise all kinds of  alarms in monitoring software, such as “Resource Group ABC is partially offline” and so on.

Another interesting discovery for me on this case was the Resource object and its LogInformation method. You can use this to log entries to the Cluster log, from the script, so you can see which entry points are called and when. This will give you an even clearer idea of where to place your custom script, if you need to call it more often (to check for any relevant condition).

Also, the precondition to running the custom script is that we’re on the passive node. This is a basic task for VBScript. What you want to do is get the computer name from WMI, compare it to the passive node name and run the custom script if we’re on the passive node or do nothing if we’re on the active node.

Here’s the script. After it, you’ll find some more information about how to configure it and some pitfalls to avoid. 

'======================================================
' File name: GenericScriptRes.vbs
' 
'Run custom script only on a particular node when group
'comes online.
'======================================================

Function Open( )
Open = 0
End Function

Function Online( )
Resource.LogInformation "Entering Script Online"
On Error Resume Next

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set nodeInfo = objWMIService.ExecQuery("Select Name from Win32_ComputerSystem")

For Each objNode in nodeInfo

        If objNode.Name = "WIN2K3NODE2" Then
                Resource.LogInformation "Custom Script will run here. "

                ' PLACE CUSTOM SCRIPT HERE

        Else
                Resource.LogInformation "Custom Script will not run here. "
        End If

Next

Online = 0
End Function

Function Offline( )
Resource.LogInformation "Entering Script Offline"
Offline = 0
End Function

Function Close()
Close = 0
End Function

Function Terminate( )
Terminate = 0
End Function

Function LooksAlive( )
'Resource.LogInformation "Entering Script LooksAlive"
LooksAlive = true
End Function

Function IsAlive( )
'Resource.LogInformation "Entering Script IsAlive"
IsAlive = true
End Function

'======================================================

I’ve commented out the LooksAlive() and IsAlive() Resource.LogInformation calls because these functions are called every 5 seconds and 1 minute respectively. They should only be uncommented when testing, or else your Cluster.log file will be flooded with these entries. Also, these functions return “true” rather than “0” like the others, as recommended by the the MSDN article that details the Scripting Entry Points.

This article also mentions that the scripts should be stored locally rather than on a shared disk. Since the resource should come online on both nodes (but only run on the passive node), you can drop the script into “C:\Windows\Cluster” or another location on both nodes so long as the path to the script file remains the same.

Another point worth noting is that the resource can go through an offline-online cycle on the passive node (most likely through manual intervention) which means that the custom script may run more than once. This is not a problem if the custom script actions perform a static activity such as updating the node name in a file referenced by another application. However, if it performs an activity that needs to occur only once after the initial failover, additional checks need to be put in place to prevent it from running again on the same node. One example of a check can be to create a tag or placeholder file on the shared storage before the Online function exits and then put a check at the beginning of the same function that checks for the file and doesn’t run the script if it is present. To clear this file when the Resource Group fails over to the active node, you could put in a snippet of code – again in the Online function – that checks if the node is the Active node and then deletes the file.

That’s it then. The MSDN articles I’ve linked to will give you all the information you need to have about the “Generic Script” resource.

]]>