Do not forget to add needed PowerShell Modules to your Azure Automation account

Posted on September 18, 2017 by workinghardinit

When you start automating Azure from the comfort of your desktop or laptop, things are slow going at first. You are constantly finding out things that do not work. Then you learn about the modules that you need to install, import. The dependencies that you need to take care of and the various ways of handling authentication to access the resources, you need.

Therefore, you put in the time, set up your PC/laptop (or multiple of those, you know how it goes as mobile, flexible IT professional) with the tools several editors from notepad++ over PowerShell ISE with or without plugins and Visual Code to full blown Visual Studio. You fight where you are with what you got, sometimes that is a lot, sometimes very little but it all takes time to set up.

Once you figured out how to automate with PowerShell against Azure, you learn not all code should live on premises and/or be run from there. There are solutions for that. You learn about run books, hybrid run books, workflows and Azure Automation accounts. For your comfort, you might integrate run books into your PowerShell ISE with Azure Automation ISE add-on.

Cool. You write your script, you test it, and decide you are golden and ready to use it. Happily, you deploy your run book only to find it does not work at all. You are beaten around the head with errors about missing functions like there is no tomorrow. Not because of authentication issues or so with ARM, you figured out already that an automation account with AzureRunAsConnections is how you get things done. Just plain missing function names like below.

Get-AzureRmLocalNetworkGateway : The term ‘Get-AzureRmLocalNetworkGateway’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At updatedynipvpn:27 char:27 + + CategoryInfo : ObjectNotFound: (Get-AzureRmLocalNetworkGateway:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException

Your automation account as a limited set of preconfigured modules available by default. However, you’ll often find you’ll need more. In our example case that is AzureRM.Network and AzureRM.profile on which AzureRM.Network has a dependency.

That is quite annoying when it happens but remember all the work you had to do to prep your scripting environment. Well there is a little extra work to do in Azure as well. You can add these modules or resources via “Shared Resources”, “Add a Module” under your automation account.

Once you have added them and they have been deployed you will find them under the CMDLETS tree branch of your run book, which gives you a handy list of what available to your automation account.

When you try to run your script now it should come alive. If it does not a little patience can do miracles. The portal test run-time environment is not always immediately up to speed with what has changed.

So remember, do not forget to prep the Azure automation environment just like your PC and remember to add the modules you need in order for your scripts to run. You might expect the entire library to be available out of the box but it is not.

Happy automating!

Back from the Cloud and Datacenter Conference Germany 2017

Posted on May 6, 2017 by workinghardinit

I just got back from a very successful Cloud & Datacenter Conference Germany, 2017 edition. I took some vacation days to go educate myself with the help of my peers and the excellent speakers. The people have a wealth of expertise and experience in real world solutions that address the challenges we face today. All this without marketing or too ego. Just pure knowledge sharing about the facts and realties. Take a look here at the wealth of industry experts that were attending and presenting.

The attendees were amongst the better educated customers & partners you encounter in the field. This is great as this gives everybody good feedback and insight in the challenges we all face. I’d say there are definitely very pragmatic patterns in how businesses deal with the evolving cloud & datacenter ecosystem successfully. Cyber security is also part of that. I’m happy to see the insights shared with us by an expert lite Tudor Damian reminding us to always keep security in mind and showing us and that Microsoft is indeed making serious efforts to protect us in an IT environment they approach with the assumption that Ii t is compromised.

I did my part for the conference with a session on Failover Clustering Evolved (in Windows Server 2016) as well as with a presentation called SMB Direct – The Secret Decoder Ring for the Hyper-V Community day event the day before the conference. That was also awesome and I had a great response to the session and interest in our experiences with RDMA. Oh yes, I also got some hands on training in filming to the delight of my fellow MVPs Winking smile .

If it’s up to me, I’ll be back in 2018!

Conferences, Presenting & Learning Q4 2016

Posted on October 6, 2016 by workinghardinit

After MS ignite 2016 we’re prepping our Windows 2016 rollout that will start the day we have the Volume license bits. All this in combination with a continued public cloud development and deployment. We’ve seen success with native born in the loud apps and are now working on moving some existing workloads over there. The reason for the latter is that some of the IAAS private hosters at our disposal are unable to deliver the quality and level of services required to server the needs of some real time services. Not to mention that some of them make public cloud look cheap on top of the fact that ordering a VM takes weeks and the solutions can barely be called “cloud”. Well you can, but that doesn’t make it so. Basically is only fit for workloads you don’t really care about but for those they are way too expensive. So it’s Public Cloud for the win here.

But between these efforts I’ll be learning and sharing experiences with my pears until it’s time to take a few weeks of at the end of the year.

On October the 26th I’ll be attending and presenting at the Windows Server 2016 Launch Event In Ireland #WSL16 which is being organized by MicroWarehouse IT distributor.

Aidan Finn works there with great drive and success as their technical evangelist. He’s tapped in to his network of global experts to line up some great and diverse content on both Windows Server 2016 and Azure for cloud deployments.

Soon after that I’ll be flying over the big pond (go west young man, go west!) to attend the Microsoft MVP Global Summit 2016 and engage in some serious feedback, planning with Or Microsoft PMs and discuss the roadmaps and vision for the next year.

On November the 22nd I’ll be attending Experts Live in the Netherlands where I’ll also be presenting. The title of my session is Get your work/life balance in check with Hyper-V 24/7/365 High Availability. And the aim is to show you how clustering and Hyper-V have evolved to deliver better high availability, higher resiliency to failure, operational optimizations and better trouble shooting capabilities. Experts live is really one of the best and larger community events in Western Europe, and I always look forward to attending.

That will conclude my conference and presenting schedule for the year. Well unless another opportunity to attend and share knowledge appears that’s to good to be turned down. The remainder of the year will be spent on moving to Windows 2016 and diving deeper into Azure ARM & automation.

A First look at Cloud Witness

Posted on August 3, 2016 by workinghardinit

Introduction

In Windows Server 2012 R2 Failover Clustering we have 2 types of witness:

Disk witness: a shared disk that can be seen by all cluster nodes
File Share Witness (FSW): An SMB 3 file share that is accessible by all cluster nodes

Since Windows Server 2012 R2 the recommendation is to always configure a witness. The reason for this is that thanks to dynamic quorum and dynamic witness. These two capabilities offer the best possible resiliency without administrator intervention and are enabled by default. The cluster dynamically assigns a quorum vote to node when it’s up and removes it when it’s down. Likewise, the witness is given a vote when it’s better to have a witness, if you’re better off without the witness it won’t get a vote. That’s why Microsoft now advises to always set a witness, it will be managed automatically. The result of this is that you’ll get the best possible uptime for a cluster under any given circumstance.

This is still the case in Windows Server 2016 but Failover clustering does introduce a new option witness option: cloud witness.

Why do we need a cloud witness?

For certain scenarios such a cluster without shared storage and especially when a stretched cluster is involved you’ll have to use a FSW. It’s a great solution that works as well as a disk witness in most cases. Why do I say most? Well there is a scenario where a disk witness will provide better resiliency, but let’s not go there now.

Now the caveat here is that you’ll need to place the FSW in a 3^rd independent site. That’s a hard order for many to fulfill. You can put in on the desktop of the receptionist at a branch office or on a virtual machine on the cluster itself but it’s “suboptimal”. Ideally the FSW is independent and high available not dependent on what it’s supposed to support in achieving quorum.

One of the other workarounds was to extend AD to Azure, deploy a SOFS Cluster with an non CA file share on a cluster of VMs in Azure and have both other sites have access to it over VPN or express route. That works but in a time of easy, fast, cheap and good solutions it’s still serious effort, just for a file share.

As Microsoft has more and more use cases that require a FSW (site aware stretched clusters, Storage Spaces Direct, Exchange DAG, SQL Availability Groups, workgroup or multi domain clusters) they had to find a solution for the growing number of customers that do not have a 3^rd site but do need a FSW. The cloud idea above is great but the implementation isn’t the best as it’s rather complex and expensive. Bar using virtual machines you can’t use Azure file services in the cloud as those are primarily for consumption by applications and the security is done via not via ACLing but access keys. That means the security for the Cluster Name Object (CNO) can’t’ be set. So even when you can expose a cloud file to on premises to Windows 2016 (any OS that supports SMB 3 actually) by mapping it via NET USE the cluster GUI can’t set the required security for the cluster nodes so it will fail. And no you can’t set it manually either. Just to prove this I tried it for you to save you the trouble. Do NOT even go there!

So what is possible? Well come Windows Server 2016 Failover Clustering now has a 3^rd type of witness. The cloud witness. Functionally wise it’s like a FSW. The big difference it’s a dedicated, cloud based solution that mitigates the need and costs for a 3^rd data center and avoids the cost of the workarounds people came up with.

Implementing the cloud witness

In your Azure subscription you create a storage account, for this purpose I’ve create one named democloudwitness in my resource group RG-Demo. I’m using a separate storage account to keep thing tidy and separated from my other demo storage accounts.

A storage account gets two Access keys and two connection strings. The reason for this is that we you need to regenerate the keys you can have your workloads use the other one this can be done without down time.

In Azure the work is actually already done. The rest will happen on premises on the cluster. We’ll configure the cluster with a witness. In PowerShell this is a one liner.

If you get an error, make sure the information is a correct and you can reach Azure of HTTPS over the internet, VPN or Express Route. You normally do not to use the endpoint parameter, just in the rare case you need to specify a different Azure service endpoint.

The above access key is a fake one by the way, just so you know. Once you’re done Get-ClusterQuorum returns Cloud Witness as QuorumResource.

In the GUI you’ll see

When you open up the Blobs services in your storage account you’ll see that a blob service has been created with a name of msft-cloud-witness. When you select it you’ll see a file with a GUID as the name.

That guid is actually the same as your cluster instance ID that you can find in the registry of your cluster nodes under the HKLM\Cluster key in the string value ClusterInstanceID.

Your storage account can be used for multiple clusters. You’ll just see extra entries each with their own guid.

All this consumes so few resources it’s quite possibly the cheapest ever way of getting a cluster witness. Time will tell.

Things to consider

• Cloud Witness uses the HTTPS REST (NOT SMB 3) interface of the Azure Storage Account service. This means it requires the HTTPS port to be open on all cluster nodes to allow access over the internet. Alternatively an Azure Site-2-Site VPN or Express Route can be used. You’ll need one of those.

• REST means no ACLing for the CNO like on a SMB 3 FSW to be done. Security is handled automatically by the Failover Cluster which doesn’t store the actual access key, but generates a shared access security (SAS) token using the access key and stores it securely.

• The generated SAS Token is valid as long as the access key remains valid. When rotating the primary access key, it is important to first update the cloud witness (on all your clusters that are using that storage account) with the secondary access key before regenerating the primary access key.

• Plan your governance between cluster & Azure admins if these are not the same. I see Azure resources governance being neglected and as a cluster admin it’s nice to have some degree of control or say in the Azure part of the equation.

For completeness I’ll mention that the entire setup of a cloud witness is also very nicely integrated in to the Failover Cluster GUI.

Right click on the desired cluster and select “Configure Cluster Quorum Settings” from menu under “More Actions”

Click through the startup form (unless you’ve never ever done this, then you might want to read it).

Select either “Select the quorum witness” or “Advanced quorum configuration”

We keep the default selection of all nodes.

We select to “Configure a cloud witness”

Type in your Azure storage account name, your primary access key for the “Azure storage account key” and leave the endpoint at its default. You’ll normally won’t need this unless you need to use a different Azure Service Endpoint.

Click “Next”to review what you’re about to do

Click Next again and let the wizard run.

You’ll get a report when it’s done. If you get an error, make sure the information is a correct and you can reach Azure of HTTPS over the internet, VPN or Express Route.

Conclusion

I was pleasantly surprised by how it easy it was to set up a cloud witness. The biggest hurdle for some might be access to Azure in secured environments. The file itself contains no sensitive information at all and while a VPN or Express Route are secured connectivity options this might not be allowed or viable in certain environments. Other than this I have found it to be very reliable, effective cheap and easy. I really encourage you to test it and see what it can do for you.

Working Hard In IT

My view on IT from the trenches

Category Archives: Azure

Do not forget to add needed PowerShell Modules to your Azure Automation account

Conferences, Presenting & Learning Q4 2016