Category Archives: Windows Azure

Compare installed vs available Microsoft Azure PowerShell versions

When running Microsoft Azure PowerShell certain cmdlets and functions are only available in the latest version of Azure PowerShell. So how do you know if you have the latest version? Well, this snippet will check your currently installed version and then ask the Web Platform Installer for the available version. It’ll then display the version numbers, letting you know if you’re current or not.

Just paste the entire code snippet into your PowerShell-prompt or embed it and just call the function.

— Begin snippet —

function Get-WindowsAzurePowerShellVersion
{
[CmdletBinding()]
Param ()

## - CHECK INSTALLED VERSION
Write-Host "`r`nInstalled version: " -ForegroundColor 'Yellow';
(Get-Module -name "Azure" | Where-Object{ $_.Name -eq 'Azure' }) `
| Select Version, Name, Author | Format-List;

## - CHECK WEB PI FOR AVAILABLE VERSION
Write-Host "Available version: " -ForegroundColor 'Green';
[reflection.assembly]::LoadWithPartialName("Microsoft.Web.PlatformInstaller") | Out-Null;
$ProductManager = New-Object Microsoft.Web.PlatformInstaller.ProductManager;
$ProductManager.Load(); $ProductManager.Products `
| Where-object{
($_.Title -like "Microsoft Azure Powershell*") `
-and ($_.Author -eq 'Microsoft Corporation')
} `
| Select-Object Version, Title, Published, Author | Format-List;
};
Get-WindowsAzurePowerShellVersion

— End of snippet —

Azure PowerShell

Using different pre-shared keys for Azure virtual network tunnels

I get loads of questions on Azure networking, some of them are good and others are just a lack of the will to RTFM. But this one actually had me trying it out cause I wasn’t sure of the possibility.

The question was: Can you have different pre-shared keys on the tunnels in Azure?

Looking around I found lots of examples of multiple tunnels, but all with the same PSK (Pre-Shared Key).

No better way than trying then, is there?

The setup is three different virtual networks:

A-net, B-net and C-net.

01-virtual-networks

There is four different local networks. A local network is a definition of the address range and gateway address that you use to connect a vnet to.

We’ve got:

A-BC-local (connecting A to B with multihop-routing to C)
A-net-local (connecting B to A)
C-AB-local (connecting C to B with multihop-routing to A)
C-net-local (connecting B to C)

So it’s A – B – C if you didn’t figure that out ūüôā
02-local-networks

A connected to A-BC-local.

03-anet

B connected to both A and C.

04-bnet

C connected to B.

05-cnet

When they’re all configured they won’t connect since the newly created gateways have automatically set PSK’s. You’ll need to use PowerShell to set the PSK for each tunnel.

 

Set-Azurevnetgatewaykey -vnet A-net -localnetworksitename A-BC-local -sharedkey 456
Set-AzureVnetGatewayKey -vnet B-net -localnetworksitename A-net-local -sharedkey 456
Set-Azurevnetgatewaykey -vnet B-net -localnetworksitename C-net-local -sharedkey 123
Set-azurenvetgatewaykey -vnet C-net -localnetworksitename C-AB-local -sharedkey 123

This will set the tunnel from a-b to 456 on both a-gw and b-gw. B to C will have 123.

Then connect the networks using

Set-AzureVnetGateway -vnet A-net -localnetworksitename A-BC-local -connect
Set-AzureVnetGateway -vnet C-net -localnetworksitename C-AB-local -connect

Conclusion: You can set your own PSK for each tunnel, no matter if it’s to on-premises or between networks in Azure.

Connecting to your Azure site-to-site VPN over NAT

Creating a site-to-site connection to your Azure virtual network is desired in a lot of scenarios. Think hybrid cloud, new workloads, communicating with internal systems from Azure and so on. And in demo scenarios when you’re out travelling you might need that access too. Well, looking at the list of supported devices (below) we can find Windows RRAS for example.

Supported VPN devices: https://msdn.microsoft.com/en-us/library/azure/jj156075.aspx

And reading the guide (below) we’ll see how it’s actually done.

Configure Site-to-site VPN: https://msdn.microsoft.com/en-us/library/azure/dn133795.aspx

According to the last link you’ll need an external IPv4 that’s not behind NAT: “Obtain an externally facing IPv4 IP for your VPN device. This IP address is required for a site-to-site configuration and is used for your VPN device, which cannot be located behind a NAT.

That last statement has been discussed quite a lot, and when you read the RFC (RFC 3715, http://tools.ietf.org/html/rfc3715)¬†¬†of course that IPsec connection will work over NAT. It’s just not supported by Microsoft, meaning that we can’t help you configuring your firewall to allow passthrough, hence we want your gateway to be directly connected to the internet.

For IPsec to traverse your NAT you’ll need to forward some ports (often called port forwarding in your router).

IKE РUDP 500
Encapsulating Security Payload (ESP) – IP protocol 50
Authentication Header (AH) – IP protocol 51
IPsec NAT traversal – UDP 4500

My setup consists of a Telia router with an external IP of 78.72.172.xx, my internal ip range is 192.168.1.0/24. This is added as a local network in Azure.

azure_local2

I then create a new virtual network in Azure and create a dynamic gateway. This will be assigned an ip address.

azure_vnet_disconnected

After that I’ve installed a VM on my local network running Windows Server 2012 R2 and configured it with RRAS. If you download the VPN device configuration script from the Azure portal it’ll set everything up for you, including installing the role. I’ve also configured the port forwarding in my router.

portforward

 

As you can see in the screenshot above the rule “IPSEC_500” forwards all traffic to 192.168.1.150.

Once you have your port forwarding up and running you can have your RRAS server connect.

rras_connected

Give the portal some time (or refresh it) and it’ll show connected too

azure_vnet_connected

I’ve deployed two VM’s in Azure and turned off the firewall to be able to verify connectivity using ping.

 

connected

 

In the screenshot above I’ve verified connectivity to 10.0.0.5 in Azure with ping, and I’ve done a traceroute. The timeout is from the Azure gateway that doesn’t respond to ICMP. Internal address of RRAS server can be seen in the lower window.

Note that this is unsupported by Microsoft – but works according to RFC.

TechDays 2014 – Sessionsmaterial

H√§r kommer som utlovat (dock senare √§n sagt) sessionsmaterialet fr√•n min Azure-session p√• Techdays 2014. Jag skyller min sena postning p√• att jag faktiskt ramlade av scenen…

I filen hittar du ppt-presentationen. Du hittar även 4 XLM-filer för nätverkskonfigurationen i Azure. Notera att dessa inte går att importera i din befintliga subscription om du redan har nätverk konfigurerade, men du kan å andra sidan kika på hur jag löst det med flera nätverk eller multi-hop-routingen i fil 3 och 4. I PowerShell-filen hittar du hur du gör en virtuell maskin med flera nätverkskort och hur du konfigurerar Network Security Groups. Frågor? Posta dom i kommentarsfältet!

För att förgylla er dag kan jag även bjuda på inspelningen av min session, särskilt då fallet. Spola fram till 12:55 i filmen.

Presentationsmaterial: Presentationsmaterial TechDays2014

Creating and uploading your Azure RemoteApp template image

Creating and uploading the image for RemoteApp turned out to be a challenge for some odd reasons. For the script Upload-AzureRemoteAppTemplateImage.ps1 to work you need to make sure you fulfill the prereqs it needs. Which can be found if you read the script ūüėČ

If Upload-AzureRemoteAppTemplateImage.ps1 fails for “odd” reasons you need to make sure that you’re running PowerShell as Admin and that you’re starting “Windows Azure PowerShell” or have the Azure module loaded.

Here’s my short list of what you need to do:

  • Create a new Hyper-V VM with a 40 GB FIXED dynamic (now supported) size disk.
  • Install Windows Server 2012 R2 (only OS supported)
  • Install RDSH role and Desktop Experience feature (both needed)
  • Reboot (needed to make sure application installations are aware of RDS)
  • Login
  • Install the applications you want to publish to your users
  • From an elevated CMD, run “fsutil behavior set disableencryption 1” (disables EFS encryption of file system)
  • Reboot (makes sure EFS disable is written to registry)
  • Login
  • Run “sysprep /oobe /generalize /shutdown”

Once your machine is turned off you need to start PowerShell as administrator with the Azure cmdlets.

Run the script provided by the portal, find your VHD-file and you should be on your way!

Uploading the file

upload4

 

 

The portal states the template status as “uploading”

upload3

Connecting an Azure RemoteApp virtual network to a virtual network

So you finally got your trial approved for RemoteApp and thought you’d connect your RemoteApp virtual network to the rest of your infrastructure in Azure? Well, I stepped in that pile too. But solved it in the usual way, with PowerShell and the new multi-vnet Configuration ability.

You need at least one existing virtual network, and you need to configure a virtual network in the RemoteApp part of the portal.

Click RemoteApp -> Virtual Networks -> Create

Enter a name for your network and select region.

01

Enter the address space you want for your RemoteApp server(s) and the address space for your local networks. With local networks I mean either your on-premises network or the other networks you have defined in Azure. In my case I’ll be connecting my RemoteApp network to my other networks in Azure.

02

Enter the DNS-servers you want your RemoteApp server to receive from DHCP. This is so your applications can resolve your local hostnames, for SQL connectivity or any other type of traffic. You also need to specify the address of the VPN device. I’ve entered the address to my gateway in Azure. If you’re connecting multiple virtual networks you MUST select “Dynamic” for VPN gateway type. Static routing only works between two networks in Azure.

03

Network created, now waiting for VPN Configuration.

04

Now we’ll click on “Manage key” and copy the address for the gateway. You might as well copy the key to a notepad file while you’re at it.

05

Add your RemoteApp network as a local network in the “Networks” part of the portal. Specify the gateway address you just copied.

08

When it’s saved, export the network configuration from the portal. Open the XML-file and edit the corresponding Virtual network, adding a connecction to your newly created “local” network. Mine is named RemoteAppVnet as you can see below.

09

Import your configuration to Azure. Networks -> New -> Network Services -> Import configuration

import

Once your information is imported you’ll see your new network as “Not connected” in the overview in the virtual network.

Open PowerShell (with the Azure cmdlets) and run the following two commands. Substituting the vnetname and local network name and key for your values of course.

07

Once those are run your networks should be connected and all green!

06

How to configure multiple virtual network connections in Azure

When using infrastructure as a service in Microsoft Azure you could earlier only have one virtual network, which would be like it’s own little isolated island. A while back Microsoft enabled for its customers to connect multiple virtual networks together, both in the same datacenter, same region, cross region and cross subscription. This enables a whole lot of new scenarios, for example building your own global datacenter on top of Azure infrastructure.

So how do you go about doing it? Well, you need to start with planning. I know it’s boring but if you don’t you could end up having to tear everything down just to rebuild it, doesn’t sound too much fun either.

What you need before starting:

An ip-plan
A VPN device with a public IPv4 address (not necessary, but will let you enable a hybrid cloud scenario)
PowerShell cmdlets for Azure installed and configured

My ip-plan looks like this:

Local network name Subnet
HomeNet 10.0.0.0/24
AzureNet-Local 10.0.1.0/24
USNet-Local 10.0.2.0/24
JNNet-Local 10.0.3.0/24

Of the networks above HomeNet is my physical network location. The other three networks exists only in Azure. What you must make sure when you plan is that no range overlap anywhere, no matter if it’s in Azure or at any physical locations.

 

Once you’ve planned that I have a separate table for my topology so I know which networks to connect. When starting off you won’t know your gateway ip, so don’t worry.

Virtual Network Subnet Gateway Local network
AzureNet 10.0.1.0/24 137.117.227.xxx HomeNet 10.0.0.0/24
USNet 10.0.2.0/24 168.61.160.xxx JNNet 10.0.3.0/24
JNNet 10.0.3.0/24 23.97.77.xxx USNet 10.0.2.0/24

 

Getting started

Starting off I already have one network called AzureNet (10.0.1.0/24) which is connected to my physical network Homenet (10.0.0.0/24). You can follow this guide even if you don’t have that, just repeat the process.

vlcsnap-2014-06-13-09h38m57s199

 

 

Let’s create a new virtual network first

In the portal, click New -> Network Services -> Virtual Network -> Custom Create

Name your network and select a location. South Central is in Brazil so I’ve named my network BRnet.

 

newnet01

 

 

Select (or enter) your DNS servers ip and name for local name resolution.

newnet02

 

 

Enter your address space. Make sure there’s no overlapping subnets anywhere. Very important!

newnet03

 

 

Repeat this process for all the virtual networks you need.

When all your virtual networks are created it’ll look like this. Note the different locations in my setup, placing my networks in Japan, USA and Amsterdam.

vlcsnap-2014-06-13-09h38m43s56

 

 

Local networks

When the virtual networks are done we’ll create local networks of the virtual networks. This is because to be able to connect the networks they need to be defined as “local” in Azure.

 

vlcsnap-2014-06-13-09h40m17s223

 

 

Name your network, and specify 1.2.3.4 as VPN device address.

vlcsnap-2014-06-13-09h40m28s87

 

 

Specify the address space that you’ve planned beforehand.

vlcsnap-2014-06-13-09h40m51s54

 

 

Repeat this for each virtual network, re-defining it as local.

When you’re done it’ll look like this

vlcsnap-2014-06-13-09h41m17s60

 

 

Switch back to your virtual networks in the portal and go into the configure tab. Check the “connect to the local network”-box and select the corresponding “local network” that you planned before. Click save at the bottom. Repeat this process for each virtual network connecting it to the designated “local” network.

vlcsnap-2014-06-13-09h42m01s246

 

 

Next step is to create the dynamic gateway. You get the message “The gateway was not created” in the portal. At the bottom click “Create gateway” and select “Dynamic”. Do this for all your virtual networks. It’ll take 10-25 minutes to finish for each gateway. Coffee time!

vlcsnap-2014-06-13-09h42m39s112

 

 

When they’re all done, note the gateway ip address in your table for all your networks/gateways.

vlcsnap-2014-06-13-09h39m08s45

 

 

Edit your local networks and add the gateway ip address for each network.Click on the network, click Edit and enter your gateway ip.

vlcsnap-2014-06-13-09h44m40s40

 

 

When all virtual networks and their corresponding local networks are created it’s XML-time. Get some more coffee!

Click the Export-button and save the file.

Open it in Notepad / Notepad++ (if you haven’t tried it you must)

In the XML you’ll find the section <LocalNetworkSites> which contains all the networks defined as local.

<LocalNetworkSites>
<LocalNetworkSite name="AzureNet-Local">
<AddressSpace>
<AddressPrefix>10.0.1.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>137.117.227.238</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="HomeNet">
<AddressSpace>
<AddressPrefix>10.0.0.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>178.78.193.167</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="JNNet-Local">
<AddressSpace>
<AddressPrefix>10.0.3.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>23.97.65.15</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="USNet-Local">
<AddressSpace>
<AddressPrefix>10.0.2.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>168.61.160.90</VPNGatewayAddress>
</LocalNetworkSite>
</LocalNetworkSites>

If you look further down in the XML you’ll find the section <VirtualNetworkSites>. This contains subsections for each virtual network site <VirtualNetworkSite>, and in that section in turn you’ll see where to define the connections to each network.

 

<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="HomeNet">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="JNNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="USNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>

So for each virtual network you’ll need to copy and paste each local network as above.

If you look at my complete XML I’ve marked those sections in red.

<NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<Dns>
<DnsServers>
<DnsServer name="cmdc01" IPAddress="192.168.1.4" />
<DnsServer name="cmdemodc01" IPAddress="192.168.1.10" />
<DnsServer name="DC01" IPAddress="10.0.0.10" />
<DnsServer name="DC02" IPAddress="10.0.1.4" />
</DnsServers>
</Dns>
<LocalNetworkSites>
<LocalNetworkSite name="AzureNet-Local">
<AddressSpace>
<AddressPrefix>10.0.1.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>137.117.227.238</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="HomeNet">
<AddressSpace>
<AddressPrefix>10.0.0.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>178.78.193.167</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="JNNet-Local">
<AddressSpace>
<AddressPrefix>10.0.3.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>23.97.65.15</VPNGatewayAddress>
</LocalNetworkSite>
<LocalNetworkSite name="USNet-Local">
<AddressSpace>
<AddressPrefix>10.0.2.0/24</AddressPrefix>
</AddressSpace>
<VPNGatewayAddress>168.61.160.90</VPNGatewayAddress>
</LocalNetworkSite>
</LocalNetworkSites>
<VirtualNetworkSites>
<VirtualNetworkSite name="AzureNet" AffinityGroup="AzureNet">
<AddressSpace>
<AddressPrefix>10.0.1.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
<AddressPrefix>10.0.1.0/27</AddressPrefix>
</Subnet>
<Subnet name="Contoso-Subnet">
<AddressPrefix>10.0.1.200/27</AddressPrefix>
</Subnet>
<Subnet name="GatewaySubnet">
<AddressPrefix>10.0.1.32/29</AddressPrefix>
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="DC01" />
<DnsServerRef name="DC02" />
</DnsServersRef>
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="HomeNet">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="JNNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="USNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
</VirtualNetworkSite>
<VirtualNetworkSite name="CMDemo" AffinityGroup="CMDemo-AFG">
<AddressSpace>
<AddressPrefix>192.168.1.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Infra">
<AddressPrefix>192.168.1.0/26</AddressPrefix>
</Subnet>
<Subnet name="Mgmt">
<AddressPrefix>192.168.1.64/26</AddressPrefix>
</Subnet>
<Subnet name="Clients">
<AddressPrefix>192.168.1.128/27</AddressPrefix>
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="cmdc01" />
</DnsServersRef>
</VirtualNetworkSite>
<VirtualNetworkSite name="JnNet" AffinityGroup="JnNet-AFG">
<AddressSpace>
<AddressPrefix>10.0.3.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
<AddressPrefix>10.0.3.0/28</AddressPrefix>
</Subnet>
<Subnet name="Subnet-2">
<AddressPrefix>10.0.3.24/29</AddressPrefix>
</Subnet>
<Subnet name="Subnet-3">
<AddressPrefix>10.0.3.32/27</AddressPrefix>
</Subnet>
<Subnet name="GatewaySubnet">
<AddressPrefix>10.0.3.16/29</AddressPrefix>
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="DC01" />
</DnsServersRef>
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="USNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="AzureNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
</VirtualNetworkSite>
<VirtualNetworkSite name="UsNet" AffinityGroup="CentralUS-AG">
<AddressSpace>
<AddressPrefix>10.0.2.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
<AddressPrefix>10.0.2.0/28</AddressPrefix>
</Subnet>
<Subnet name="Subnet-2">
<AddressPrefix>10.0.2.24/29</AddressPrefix>
</Subnet>
<Subnet name="GatewaySubnet">
<AddressPrefix>10.0.2.16/29</AddressPrefix>
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="DC02" />
</DnsServersRef>
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="JNNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
<LocalNetworkSiteRef name="AzureNet-Local">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>

Note that for each network there is a corresponding section of <ConnectionsToLocalNetwork>.

When you’re done save the file and then it’s time to import it!

import

 

 

Wait for your networks to configure. Then it’s PowerShell-time!

Fire up PowerShell with the Azure cmdlets.

Run the cmdlet “Set-AzureVNetGatewayKey -VNetName AzureNet -LocalNetworkSiteName JNNet-Local -SharedKey a1b2c3d4” for each virtual network setting the key for each local network.

So I’d run:

Set-AzureVNetGatewayKey -VNetName AzureNet -LocalNetworkSiteName JNNet-Local -SharedKey a1b2c3d4
Set-AzureVNetGatewayKey -VNetName AzureNet -LocalNetworkSiteName USNet-Local -SharedKey a1b2c3d4
Set-AzureVNetGatewayKey -VNetName AzureNet -LocalNetworkSiteName HomeNet -SharedKey a1b2c3d4
Set-AzureVNetGatewayKey -VNetName JNNet -LocalNetworkSiteName USNet-Local -SharedKey a1b2c3d4
Set-AzureVNetGatewayKey -VNetName JNNet -LocalNetworkSiteName AzureNet-Local -SharedKey a1b2c3d4

And so on, switching the virtual network and the local network according to your topology.

When you’re done with that it’s time to connect your networks:

Set-AzureVNetGateway -VNetName AzureNet -LocalNetworkSiteName JNNet -Connect

And as before, substitute the vnetnames and local network names.

Once done it’ll (hopefully) look like this:

vlcsnap-2014-06-13-09h46m22s38

 

 

How did you do? Let me know in the comments!

Why Microsoft Azure should be on top of your learning list

Today was the opening keynote of TechEd in Houston. Regardless of what’s earlier been said about Houston there wasn’t any problems detected today. Instead Microsoft launched a number of new features in and around Azure.

So what’s been said today? And what does it mean for the IT-pro?

Bigger VM’s

A8 and A9. More CPU, more ram, faster interconnects. This allows those companies running HPC workloads or data mining to finish faster.

Azure Files

Your own SMB share in Azure. Accessible from multiple Virtual Machines simultaneously.

Microsoft SCEP and Symantec/Trend Micro partnership

Protecting your VM’s and cloud services. And not only with our products but with Symantec or Trends products. You can choose.

Network improvements

Internal Load balancing –¬†load balancing with private IP’s

Multiple site-to-site VPN, and VNET-to-VNet connectivity.

Reserved IP’s and public IP’s for VM’s

Azure Site Recovery

Replicate your virtual machines to Azure and failover if you need to. A secondary site for EVERYONE…

Azure RemoteApp

Remote applications from Azure to your devices and computers.

And that’s not even the complete list. You can sign up for the preview features here!

So what does this mean for the IT-pro?

The landscape for the IT-pros is rapidly changing. A few years ago virtualization in-house was the frontline of IT, but those days are quickly vanishing. To stay relevant now, and in the future, a knowledge of hybrid cloud, PowerShell and people centric IT (as it’s called) will be needed. The business side of many companies are buying cloud services today, it might be projektplace or salesforce but the step to getting their own VM isn’t that big. If you can’t deliver services from IT as cheap and rapidly as cloud services can do it it’s time to start thinking about how to solve that problem.

If someone had told me 10 years ago, or 20 years ago when I started in this industry that I’d deploy servers on the internet through a web page I would’ve laughed.

Today I can deploy 50 servers in less than 15 minutes with 5 lines of PowerShell.

How are you going to stay ahead of the game?

Azure Automation – Using the assets

After yesterdays post about getting started I’ve gotten some questions about the assets library. Thought I’d explain how to use some of the assets (or at least how I’ve figured it out I’d say, might be totally off but at least it works)…

Looking at the assets library we have a “Connection”-object containing our subscription ID. This could be an ID to another subscription, might be useful for IT to deploy services to a developers subscription or something like that.

We also have a “Certificate”-object where we also uploaded the corresponding certificate to our collection of management certificates in Azure, this needs to be done on the right subscription then if you’re managing multiple ones, keep that in mind…

Automation assets

 

 

 

 

 


<# .DESCRIPTION .NOTES Author: Joachim Nässlander, TSP Datacenter, Microsoft #>

workflow Start_Azure_Demo_VM
{
param()

$MyConnection = “Internal Subscription Connection” # <— The name of your Connection object in assets
$MyCert = “InternalSubscriptionCertificate” # <— The name of your Certificate object in assets

# Get the Azure Automation Connection
$Con = Get-AutomationConnection -Name $MyConnection¬†# <— Connect to your subscription
$SubscriptionID = $Con.SubscriptionID
$ManagementCertificate = $Con.AutomationCertificateName
$Cert = Get-AutomationCertificate -Name $Con.AutomationCertificateName # <— Get the certificate from assets

write-output “Subscription ID: $SubscriptionID”

write-output “Certificate Name: $Con.AutomationCertificateName”

}

 

And since this is the internet. How are you using Azure Automation and the assets library, feel free to comment!

Have a nice weekend, and don’t miss The Fratellis to keep you company over a beer!

Getting started with Azure Automation

Azure automation is currently in preview so you might not see it in your portal if you haven’t enrolled already. You can enroll for Azure Automation at http://azure.microsoft.com/en-us/services/preview/and also find all other services currently in preview. It’s a good place to frequently check out, fun things emerge here!

So what is Azure Automation? Well, it’s the ability to run PowerShell workflow scripts from Azure, targeted at your Azure resources.

Once you’re enrolled into the preview program you can create your first automation account. An account can be seen as a container that you can fill with runbooks and assets needed by the runbooks. An asset can be for example a certificate allowing you to connect to your (or another) Azure subscription.

 

Automation dashboardThe overview over your runbooks looks like this. It’ll show you the number of runbooks, number of activites,¬† number of minutes you’ve ran your scripts and a whole lot more.

 

 

 

 

 

 

 

Now that you’re enrolled you might want to quickly just test it out, personally I love just getting a feel for things before diving into documenation. You can find example scripts and a how-to at http://azure.microsoft.com/en-us/documentation/articles/automation-create-runbook-from-samples/. One thing to note when creating your runbook is that your scripts name in the portal need to correspond to your workflow name. Ie if your workflow is named “Join-Servers-Domain” your runbook must be named the same.

 

Automation runbooks overviewLooking more at the portal, if you click “runbooks” up top, you can see your runbooks listed with their latest run time and status. This gives you a quick overview without having to look at each runbook individually.

 

 

 

Detailed view of runbook

Selecting one specific runbook gives you a chart over how it has ran over the some periods of time. Here you can also drill down into each script run and view script output and any input parameters.

 

 

 

 

 

Published runbookClicking on “author” while in detailed view takes you to the published version of the script. Here you can view your script and start it manually if you want to.

 

 

 

 

 

Runbook draftIf you opt for “draft” instead you’ll be able to edit your script and insert things from your assets library or other runbooks, allowing for runbooks to interact with each other. Here you can also test your runbook before publishing it.

 

 

 

 

 

Automation assetsThe assets library contains building blocks needed for your scripts to function properly. And it’ll make it easier for you to develop scripts for multiple subscriptions too.

In my example we have:

  • Connection to a subscription
  • A certificate which allows us to connect to this subscription (find a guide for that here)
  • PowerShell credentials so we don’t have to enter username/password each time
  • A module containing PowerShell cmdlets

 

 

You can read more about getting started with PowerShell workflows at http://technet.microsoft.com/en-us/library/jj134242.aspx.