Kevin Remde's IT Pro Weblog
IT Pro Resources
TechNet EventsMicrosoft Security Response CenterMicrosoft Virtual AcademyKevin’s Evaluation Download Center
IT Pro Evangelist Blogs
Blain Barton Blain Barton's Blog@BlainBar
Brian LewisMy Thoughts on IT...@BrianLewis_
Dan Stolts IT Pro Guru Blog@ITProGuru
Jennelle Crothers TechBunny@jkc137
Kevin RemdeFull of I.T.@KevinRemde
Tommy PattersonVirtually Cloud 9@Tommy_Patterson
Yung Chou Yung Chou on Hybrid Cloud@YungChou
Welcome to another in our series entitled “Modernizing Your Infrastructure with Hybrid Cloud”. As you may be aware, this week the theme is “Management and Automation”. As a part of that theme I’m sharing with you an introduction to Desired State Configuration (DSC); more completely called Windows PowerShell Desired State Configuration.
DSC is a relatively new (less-than-a-year-old) technology, introduced with PowerShell v4.0, that lets IT define what the configuration of a server will be, apply that configuration, and then verify (and remediate) so that the configuration is still in place and as-desired.
“So, it’s like System Center Configuration Manager?”
No. It’s built-in as a part of Windows, and is configured and implemented using PowerShell. Sound interesting?
Good. In the context of one blog article naturally I won’t be able to go into every detail, but I hope that this article, some simple examples, and some additional resources at the end will get you excited for trying this out. And ultimately that you’ll see the immense value that this will give your IT and, of course, you’re business.
A Simple Example
For our quick example let’s assume a couple of things. I’ve enabled the Windows PowerShell DSC feature on a server named “Server1”. Server1 is a member server in my domain. I’ll be using an administrative account from another server (called Admin) to apply configuration to Server1.
I open up the PowerShell ISE and enter the following text. Can you tell what it’s doing from what the text says?
“It looks like it’s defining something that’s a ‘Configuration’ and calling it ‘IISWebsite’. And for your server named Server1, it’s laying out what Windows Features should be installed!”
Exactly! And in this PowerShell session, when I execute the configuration, I end up with a .MOF file, which is a definition on behalf of how Server1 should have the Web Server and ASP.NET 4.5 installed and running. All I need to do is run the Start-DSCConfiguration PowerShell cmdlet with the proper parameters referring to the .MOF file and pointing to Server1, and DSC configures the features and enforces that they always be there as I desired In fact, even if I or another administrator were to manually remove the ASP.NET 4.5 feature from the server, after a period of time the state would be re-evaluated and the configuration would be fixed!
What if, like those “WindowsFeature” sections, I were to add a “File” section like this:
Basically what I’m saying is, “Here’s the source folder of content that I want you to make sure is always found under this destination.” Ah.. and doesn’t the path look like it might be a web site folder? Yes! This configuration not only enforces that IIS be installed and running, but that the contents of a web application be always there and that the destination code always matches what is coming from the source! Someone could go in there and, say, delete some of the web content, but DSC would fix it automatically!
“Hey Kevin… What’s a .MOF file?”
Yeah.. this was a very quick, very simple example. Let me go through and briefly describe the parts that make up DSC…
The Parts – Configuration
The configuration is what we built in my earlier example. It’s a PowerShell definition that, using “Resources” (defined next) specify how things should be configured; our “desired state” for the configuration of a target server.
The Parts - Resources
In our example above, you notice that I’m defining what Windows Features are to be installed. I can do this because there is a built-in DSC “Resource” called “WindowsFeature”. From the TechNet Documentation, “Resources are building blocks that you can use to write a Windows PowerShell Desired State Configuration (DSC) script.” Windows comes with a number of these built-in resources that know how to specifically work with, configure, and enforce various aspects of the operating system. Resources for working with the registry, the file system, Windows Features, services… and many more, are included in the list of built-in DSC resources.
But it gets even better. These resources are just PowerShell modules. And just as you have the ability to create your own modules to extend PowerShell, you also have the ability to create your own custom resources!
The Parts - The .MOF file
This is the file that contains the configuration to be applied. It’s the result of executing the configuration definition in PowerShell, and is in a standard format as defined by the DTMF.
“Hey Kevin - Why do we even really need a .MOF file? Can’t Microsoft just do what it needs to do directly from PowerShell?”
I’m sure they could. But the beauty of using the .MOF is that because it’s a DTMF standard, it is formatted in a way can be applied to different machine types and for various purposes. In fact, at TechEd in Houston earlier this year I saw Jeffrey Snover actually use DSC to create a .MOF that then configured a Linux server running an Apache web server. (Yeah.. we’re “open” like that these days!)
The Parts - How It’s Deployed
The full name, “Windows PowerShell Desired State Configuration” is a hint about how you enable the DSC capability. It is a feature of Windows Server 2012 R2, found here in the Add Roles and Features Wizard:
When you check the box, you’ll notice that it will also install some Web components to your server…
This is because one of the ways DSC configurations are securely pulled is to use IIS.
The Parts - Push-me-Pull-You?
One important aspect of DSC is that it becomes even more powerful when you can distribute configurations, or maintain consistent configurations among many machines, all from a smaller number of source locations. DSC allows either a simple “push” distribution, which is simple and more manual, and a “pull” distribution where not only do you apply a configuration to a machine but you also tell it where it should be looking for its configuration and any changes going forward. Pulling can take place over HTTP (not recommended), HTTPS (recommended), or SMB Share permissions (okay because it’s authenticated access).
“Why isn’t HTTP recommended?”
Think about the damage someone could do if they hijacked DNS and then pointed to and automatically applied someone else’s version of a server configuration to your servers. Scary prospect, indeed.
The Parts – The Local Configuration Manager
The Local Configuration Manager is “the Windows PowerShell Desired State Configuration (DSC) engine. It runs on all target nodes, and it is responsible for calling the configuration resources that are included in a DSC configuration script.” So basically when you’ve enabled the DSC feature on a server, this is the service that either takes the pushed configuration, or pulls the configuration, and then applies it as defined in the most recent .MOF file.
For More Information…
Like many of you, I find that I learn best by looking at other people’s examples. And thankfully in the case of PowerShell and DSC there is a really big community already formed and willing to share what they have done with the rest of us. Here are some of the places I recommend you check out and save to your favorites if you’re really going to get serious about using Desired State Configuration:
If you want to try it out in a virtualized lab environment:
And finally, don’t forget to check in frequently at our “Modernizing Your Infrastructure” series landing page, to see all the great articles our team has created and resources we’ve shared.
This is pretty cool.
As the title says: System Center 2012 R2 Data Protection Manager is now an application that Microsoft will support when running inside a virtual machine in Microsoft Azure.
I’m sure they won’t mind me sharing this.. but here is the text from an e-mail I received on the subject that spells it out nicely:
We are pleased to announce that System Center Data Protection Manager (DPM) is now supported to run in Azure as an IaaS virtual machine. This announcement allows customers to deploy DPM for protection of supported workloads running in a Azure IaaS virtual machines. Customers with a System Center license can now protect workloads in Azure. Read more about it on the DPM blog. Support for multiple virtual machine sizes Choose the size of the virtual machine instance that will run DPM, based on number of workloads and the total data size to be protected. Start with just an A2 size virtual machine, and upgrade to a larger size to scale up and protect more workloads. Support for Microsoft Azure Backup Protect your data to Microsoft Azure Backup and get longer retention with the flexibility of scaling storage and compute separately. The Microsoft Azure Backup agent works seamlessly with DPM running in an Azure IaaS virtual machine. Familiar management using the DPM console With DPM running in an Azure IaaS virtual machine, you get the same experiences and capabilities that you are familiar with.
We are pleased to announce that System Center Data Protection Manager (DPM) is now supported to run in Azure as an IaaS virtual machine. This announcement allows customers to deploy DPM for protection of supported workloads running in a Azure IaaS virtual machines. Customers with a System Center license can now protect workloads in Azure. Read more about it on the DPM blog.
Support for multiple virtual machine sizes
Choose the size of the virtual machine instance that will run DPM, based on number of workloads and the total data size to be protected. Start with just an A2 size virtual machine, and upgrade to a larger size to scale up and protect more workloads.
Support for Microsoft Azure Backup
Protect your data to Microsoft Azure Backup and get longer retention with the flexibility of scaling storage and compute separately. The Microsoft Azure Backup agent works seamlessly with DPM running in an Azure IaaS virtual machine.
Familiar management using the DPM console
With DPM running in an Azure IaaS virtual machine, you get the same experiences and capabilities that you are familiar with.
So, here’s what you should do:
Yesterday in our “Modernizing Your Infrastructure with Hybrid Cloud” series, Matt Hester described how to create a virtual network “in the cloud” in Microsoft Azure in order to support cloud-based Virtual Machines and their ability to communicate with each other and with the outside world. We of course have the ability to connect to our VMs individually using Remote Desktop connections, but if we’re going to treat the location of these cloud based machines as just an extension of our own datacenter, we’re going to want to have a secured connection to them.
That’s what the VPN Gateway is all about.
In this article I’m going to show you step-by-step how to connect your Azure virtual network to your on-premises network. Here are the steps we’ll go through:
And as an added bonus, I might throw in a little something extra.
I hope you’ll think so. But for starters, let’s begin where Matt left off. I have an Azure subscription with a virtual network named AzureNet1, located in the South Central US datacenter region. In my scenario, I want to connect this Azure network to my Fabrikam office (Fabrikam was recently purchased by Contoso). Once the connection is established, I will want to join servers in that office to the contoso.com domain.
Here’s what the AzureNet1 network dashboard tab currently looks like. Note the two virtual machines currently in this network; a domain controller and an application server.
As you can see on the configure tab, I’ve set up two subnet ranges (their purposes are obvious based on the names I’ve given them) as part of an 8-bit-masked 10.x.x.x subnet.:
Notice that I’ve also defined my DNS server as 10.0.0.4. My domain controller has that address.
Collect Some Information
Before we start adding the site-to-site connection, I need to collect some information so that I can carefully use it to make the correct configurations. As you probably know first-hand, when doing networking configuration it’s easy to make simple little mistakes that cause everything to NOT work, so let’s make quick note of a couple of important items:
Your local network address range refers to the addressing of your local network. By that name, though, it’s a little misleading. “Local” assumes you’re connecting your Azure network to some “Local” office. But in reality it could be some other branch office or even another virtual network somewhere else in the Azure world. So, just think of “local network” as being “the network I’m connecting to my Azure network”. And I’ll keep using “local network” in “quotes” throughout the rest of this article for just that reason.
In our example, my Fabrikam network is 192.168.0.0 with a 16-bit subnet mask. (192.168.0.0/16)
The Gateway Address is the externally accessible IP address of the gateway. In the Fabrikam network, let’s say that I have a VPN device connected to the Internet with an external Internet-exposed address of 220.127.116.11. I will also have a gateway address on the AzureNet1 gateway, but that address will be assigned when I create the gateway for my virtual network. So, in simple terms, the gateway address is the connection point on either end of the VPN connection.
Define the “Local Network”
Before enabling the site-to-site connectivity and creating the gateway, we need to define the “local network” Fabrikam, so that our network knows what addresses it will be routing to over the VPN through the gateways.
To define my “local network” (which I’ll name “Fabrikam”), I clicked on +New in the bottom-left corner of the Azure portal, and selected Network Services –> Virtual Network –> Add Local Network.
I give my local network a name, an optionally the gateway address (I can add it later if I don’t know it right now.)
Then on the next screen I add the address spaces that exist at my “local network” at Fabrikam.
Once created, you’ll see it in the list on the local networks tab.
Back on my AzureNet1 network and on the Configure tab, now I can check the box to enable Site-to-Site Connectivity. Notice that a couple of things change. I now will choose which “local network” I’m going to connect to (Fabrikam), and it also requires (and defines) a “Gateway Subnet” for me.
“Hey Kevin.. What’s that ‘ExpressRoute’ option?”
That’s actually what my friend Keith Mayer is going to cover in tomorrow’s article in the series. I’ll include the link to his article after it’s published.
UPDATE: Here is Keith’s article - Modernizing Your Infrastructure with Hybrid Cloud - Step-by-Step: Cross-Premises Connectivity with Azure ExpressRoute (Part 16)
Anyway, after checking Connect to the local network, clicking Save starts the process of updating the network configuration. After a couple of minutes it completes, and now back on the dashboard tab we see this:
This means the gateway is in defined, but not actually created. That’s our next step.
Create the Gateway
At the bottom of the dashboard screen, click on Create Gateway.
Notice when you click it that you are given a choice between a static and dynamic routing VPN gateway.
“What’s the difference?”
Your choice will be based on a number of factors. Often the VPN hardware you are using will limit you to one or the other. A static routing VPN gateway is one that routes traffic based on policy definitions (which is why it’s often referred to as a Policy-based VPN). Packets are routed through the gateway based on a defined policy; an “access list”. A dynamic routing VPN gateway, also known as a “route-based VPN”, is a simple forwarding of packets between two networks. If the network doesn’t locally contain the destination for this packet, I’ll assume the gateway knows where to send it. And if it’s known by the gateway as existing on the other network, it sends it securely through the tunnel. For more information about these choices, and about various devices and gateway types that support either static or dynamic VPN gateways, check out this excellent documentation. Even if your device is not on that list, it may still work if your hardware supports
In my scenario I’m creating a simple tunnel to a device that supports the other end of dynamically routed VPN, so I’ll choose Dynamic Routing. Creating the gateway does take a good amount of time (as much as 15 minutes), so be patient. Eventually our display will go from this:
…and eventually, this:
Notice that we’ve been assigned an official actual external gateway IP address. We’re still not actually connected. (Connected would be GREEN in color.) We haven’t addressed the configuration of the “local network” side of our connection yet. At the bottom of the page you see a Connect button:
But let’s not click that just yet. We still need to…
Configure the Local VPN Device
Other than collecting some information about our Fabrikam network, we’ve only focused on the AzureNet1 side of our VPN tunnel. We still need to create the gateway on our Fabrikam network.
On the AzureNet1 dashboard, notice this hyper-link towards the right-side of the page:
Clicking on Download VPN Device Script this brings up a very interesting page that allows us to specify what kind of hardware (or software) we have on the “local network” side of our connection. The beauty of this is that, based on our selection of hardware (or even Windows Server 2012 and 2012 R2 Routing-and-Remote-Access (RRAS) working as your gateway), you are generating a script that can then be used to automatically configure your gateway on the “local network” side.
Once we’ve selected our Vendor, Platform, and Version, and clicked the check mark, we’re immediately sent a text file containing the configuration script for our selected device.
Use this script to configure your device, establish the connection from the local network, and then come back to the Azure network dashboard and click connect. And if you’ve done everything correctly, you should see something happy (and GREEN) like this:
“What kind of hardware do you have on Fabrikam’s network, Kevin?”
I don’t know. I’m not actually using a local network. For this demonstration, I’ve actually connected my AzureNet1 network, which is located in the South Central US datacenter region to a Fabrikam virtual network that host in the Central US datacenter region and manage through an entirely different Azure subscription. So.. I’m doing Site-to-Site between two Azure virtual networks. That’s my “something extra” that I promised earlier. Now I’m going to show you what I needed to do to make that connection work.
Connecting two Azure networks via a Site-to-Site VPN requires two things:
I’ve already showed you where you choose Dynamic Routing when you create the gateway. And other than the shared key, everything else I did for configuring the Fabrikam network was identical to what I configured in AzureNet1, except that my network in Fabrikam is 192.168.0.0/16 – identical to what I defined the “Fabrikam” “local network” to be on this side. IMPORTANT: These have to match. The range and mask have to be correct and consistent on both ends both the “local network’' definition and the actual network (or Azure virtual network as in my case) for this to work.
Also in the definition of the “local network” on either side was the specification of the Gateway IP Address. Again, ordinarily, your configuration script is populated with the Azure virtual gateway’s IP address. But in this instance, I need to create the gateway first, and let it fail connecting, just so I can see what the actual assigned gateway IP address on that side of the connection is going to be. Then I can take that address and configure it into the “local network” definition on the other side.
As for the shared private key.. Notice at the bottom of the AzureNet1 dashboard that there is a Manage Key button:
If I click this, I can see (and copy) the generated long key. I’ll copy it to the clipboard.
This key was created when we created the gateway, and is included for you in the configuration script on behalf of your “local network” device. But…
“We don’t have a local network device!”
Bingo. And we also don’t (as of this writing) have a way to use the Azure portal to set the shared key in and the configuration of the virtual network! But we will need to do that to at least one end of the tunnel to make sure they match. (Or both if we want to just use our own text as the shared key.)
This is where PowerShell comes in.
I’ve installed the Azure PowerShell cmdlets onto my local system, and then in PowerShell I connected to my Azure subscription where the Fabrikam virtual network resides. And now I use the following PowerShell command to set the shared key for the gateway connected the Azure network Fabrikam to the (from this point of view) “local network” named AzureNet1.
Set-AzureVNetGatewayKey -VNetName fabrikam -LocalNetworkSiteName AzureNet1 -SharedKey 2kDsdqXnxeXrGjI4r4rLltKKT1g9E9gY
Set-AzureVNetGatewayKey -VNetName fabrikam -LocalNetworkSiteName AzureNet1 -SharedKey 2kDsdqXnxeXrGjI4r4rLltKKT1g9E9gY
(For the Windows PowerShell command-line tools, go to the Azure downloads page, and scroll down to “Windows PowerShell” section. Instructions for setting this up are found there as well.)
That’s how I was able to get the common shared key into the other side of my connection. After this command completes, and soon after clicking Connect in the dashboard, I was happily sending data back and forth.
“But Kevin… Prove to us that you have the connection established! Finish your domain-joining scenario!”
In the AzureNet1 network I have two servers. One is a domain controller, and the other is a member server. All machines here are assigned their DNS server as 10.0.0.4. They reside in the South Central US datacenter region.
On my Fabrikam network (which, you’ll recall remember, resides in the Central US datacenter region, so not in the same location as the AzureNet1 network and machines) I have one server that I’ve just created:
Importantly, I’ve also created a “DNS Server” designation here, and assigned to the Fabrikam network, with the 10.0.0.4 address. Note the configure tab of the Fabrikam network.
In this way my machines in this Fabrikam network will be assigned 10.0.0.4 as their DNS server, and so will know how to find the DC in the AzureNet1 network. To verify this I can establish a remote desktop connection to my new karContosoDC2 server and look at the status of the network adapter:
Trusting that my VPN is happily and dynamically routing traffic between Fabrikam and AzureNet1, and knowing that my new server in Fabrikam is going to look for DNS at the domain controller in AzureNet1, I attempt to join the domain:
I am asked for domain credentials (a very good sign!)…
I’m in! That’s proof that I have successfully connected these two virtual networks!
For more information on configuring secure cross-premises connectivity, check out the official documentation here:http://msdn.microsoft.com/en-us/library/azure/dn133798.aspx
Here are some more specific configurations and their documents:
And be sure to keep watching http://aka.ms/ModernCloud for the full series of articles on modernizing your infrastructure.
Keith Mayer and I continue our series on “Modernizing Your Infrastructure with Hybrid Cloud”. In today’s episode we discuss various options for networking. Tune in as we go in depth on what options are available for hybrid cloud networking as we explore network connectivity and address concerns about speed, reliability and security.
Shortened URL if you would like to share on Twitter or Facebook, etc.