Posted on

Serial Console access on Azure Virtual Machine

Finally come the day that Microsoft was able to announce this feature. Accessing the serial console on an Azure VM is a huge step forward. But why is so important? It’s huge! Sometimes when our friend Mr Murphy comes and makes everything goes south, you are in a certain way limited on the diagnostic tools that you have, to troubleshoot the cause of that machine is not booting. Have access to the boot of the server (Linux or Windows) is crucial at this time. Serial Console access will end those day of redeploy a VM using the same disk, when this option is viable, off course. You can see the announcement here.

But let’s dive into the Accessing the Serial Console. On each VM that you have running on Azure, under the SUPPORT + TROUBLESHOOTING, you will find the Serial console (preview).

When you click on that, automatically start to connect to the Serial Console of that VM.

After a few seconds, finishes the connection. And show me this screen. But I can’t do anything.

If you scroll up, then some light at the end of the tunnel. OK, I need to enable the SAC (Special Administrative Console) on the server.

To access the Serial Console on the server you need the enable it. To enable, just follow the steps below:

  1. Connect to your VM through RDP (in this case a Windows VM)
  2. Open the cmd with elevated (administrative privileges)
  3. From the cmd prompt run the following commands
    bcdedit /ems {current} on
    bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
  4. Reboot the VM

And then, you have access to the serial console of your server.

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Posted on

Azure VNet-to-VNet VPN configuration – Part 3

In this blog post series, I will cover what you need to configure to create a VNet-to-VNet VPN between to Azure regions on the same subscription. Although is about the same configuration if you want to configure two different VNets on different subscriptions. You can see the part 1 post here and the part 2 here.

So, at this moment I have both networks setup with their gateways configured. Although I need to connect them to each other. For this I only have to choose one of them to setup the connection. Because I’m on the same subscription, this is one of the difference. If I want to connect different VNets on different subscription, I have to setup the connection on both sides. What they need to have in common is the Shared Key.

It’s exactly the same when setup a Site-to-Site VPN. One of the requirements after setup the networks, is connecting them with the Shared Key

How to connect two VNet gateways using Azure Portal

After this running successful, we need to connect both networks. To be able to do it just follow the steps bellow:

  1. On the VNet created, navigate to Connections (in this case I used the network that I configured with PowerShell – SW-EUS2-WUS2-VPN)
  2. Click Add
  3. When the Add connection blade open, you need to configure all the requirement fields:
    1. Name – This is where you insert the name of the VPN connection.
    2. Connection type – This is where you define which of connection want to use. VNet-to-VNet is used between two networks on Azure, Site-to-Site is used between a Azure network and on premise network. ExpressRoute is used between an Azure network and an existing circuit.
    3. First virtual network gateway – This is the network that you are configuring from.
    4. Second virtual network gateway – This where you want to connect. In this case, is the other region.
    5. Shared key – This is the key that is shared on both side to stablish the connection. This key only accepts number and/or letters.
  4. Then click OK
  5. After the connection it’s created, it will connect automatically.

 

 

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Posted on

Enhancements on Azure Portal Notifications

If you are like me and your Azure Portal is your center on your day, you probably see this enhancement of the notifications. I found very useful and make my day way more productive when I need to setup new resources/environments.

Be able to deploy different resources through the Azure Portal and from the notifications access those resources is something that I did think why Microsoft doesn’t improve those little details, but guess what? They listen! WOW.

So, from the notification you can now, access direct where the resource is located, as well as pin to the dashboard.

In some case this could be very useful for some Azure Administrators that use the Azure Portal, because they can easily jump into the Resource Group, where you create the resource, instead of going back to the main menu and navigate to where the resource is. Another aspect is on the visualization on the Azure Portal notification areas, because now you have these two buttons, now you can identify way better what you deployed and find the resource that you are looking for.

You might think, why did I spend time writing this blog post, and the answer is very simple. THEY DID LISTEN! LOL! And besides that, this little thing makes, at least me, my days way better. Could not be much for you, but it’s for me.

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Posted on

Deploy ARM Templates using Key Vault

I’ve been deploying to Azure a lot of resources, one of my favorite things is to create templates where I can reuse for other situations. But sometimes, and in some situations, you need to increase the security. That is where I started to leverage the Key Vault to store my secrets.

Over the years, I have been creating a linked template reference where the main template passes parameters and the key vault references to the linked template. Although the template is uploaded to a storage blob container.

Let me exemplify. Imagine that you have the following scenario, you want to leverage the Azure Portal to deploy ARM Templates and you want to use the Key Vault to store the secrets. How I can do it? Although, your Manager concern is, since the URI is public how I can protect the storage container?

The way that I have been getting around on this situation is using private blob storage in conjunction with SAS.

Step 1 – Use Azure File Copy to copy your template to the storage account. Azure File Copy will give you a SAS token. Then use the token to deploy.

Step 2 – On Azure Resource Group Deployment, you have an option to override the template parameters.

Step 3 – You only need to append the SAS token to the final URL.

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga