There are already a few blog posts available about how to shutdown virtual machines in Azure. I listed some of them at the bottom of this post, but anyhow – I wanted to try it on my own and wrote a short documentation about it.
There are different ways how to automatically shutdown a virtual machine in Azure:
- Automation account (preferred way for existing VMs)
- DevTest-Labs (preferred for development and test environments)
- Install a script on your servers
Update December 1, 2016: there is a new feature available that allows to configure the auto shutdown directly as a virtual machine configuration – see: Auto shutdown Azure virtual machines. If you want to shutdown multiple virtual machines and/or control it from a central point – continue reading this article.
The Azure active directory domain services are currently in preview, but you can already use it to connect your virtual machines to it. One of the main limitations right now is, that it works only with the classic deployment model. You can only use a virtual network that is created in the classic mode and also the virtual machine that should be connected to the AD must part of this virtual network. As the network is in classic mode, the virtual machine also needs to be created in classic mode. But let’s start to find out, what the Azure active directory domain services are.
The bigger your applications are, the more settings you’ll have in the web.config file. If you run your webapp in Azure and there are a lot of settings, then it’s annoying to set all the values manually. It would be much easier, if Azure would automatically show all app settings in the section in the azure portal and you just need to adapt them. Unfortunately there this doesn’t work out of the box and therefore the application settings will look like:
Logging is highly important if you want to build maintainable solutions. There are frameworks like Log4Net that you can use for it, but I prefer to use the out of the box Azure logging mechanism:
System.Diagnostics.Trace.WriteLine("Writes a verbose message.");
System.Diagnostics.Trace.TraceInformation("Writes an info message.");
System.Diagnostics.Trace.TraceWarning("Writes a warning message.");
System.Diagnostics.Trace.TraceError("Writes an error message.");
This post shows a Powershell script that connects to Azure and exports all resources from multiple subscriptions to a CSV file. It also shows how this script can be used inside of a scheduled task which creates the CSV file on a daily base.
Exporting all the resources can be achieved with the following commandlets:
Add-AzureRmAccount # login to your azure account
Set-AzureRmContext -SubscriptionID $subscriptionId # set/change the subscription
Get-AzureRmResource | Export-CSV "c:\temp\data.csv" # get the resources and export it to CSV file
This script just exports the data of one subscription and simply writes it to a csv file. If we want to have a reusable script which exports the data of all of my subscriptions, then we should extend it:
In an Azure ServiceBus you can create multiple subscriptions for one topic. Such a subscription has the possibility to filter messages. So only the messages that match the criterias are “forwarded” to the subscription. Let’s have look on how filters work.
In this post I will use the ServiceBus Explorer to connect to an existing ServiceBus namespace. If you want to know how to create a ServiceBus namespace, a topic plus subscription and connect to it with the ServiceBus explorer – then read my previous blog post about it: How to create a topic with testdata in Azure ServiceBus
In this blogpost I will describe how to create a ServiceBus and a Topic in Microsoft Azure and how to push some sample data with the ServiceBus Explorer to it. In a following post I will describe how to work with ServiceBus filters.
Before you create the servicebus, you should download the servicebus explorer tool which you can find here: https://code.msdn.microsoft.com/windowsapps/Service-Bus-Explorer-f2abca5a
When you connect to Azure, e.g. the Azure ServiceBus Explorer to the ServiceBus (https://code.msdn.microsoft.com/windowsapps/Service-Bus-Explorer-f2abca5a), you will probably deal with proxy issues. I sometimes got the following error:
An error occurred attempting to access the account:
The remote server returned an error (407): Proxy Authentication Required
This is a step by step tutorial of how to programmatically read azure active directory groups with a c# client application.
- Create a new Visual Studio console application
- Add the following NuGet packages to your project:
- Check the code at GitHub
- Add a reference to System.Configuration to your project (needed for the AppConfigConfiguration.cs)
- Configure your application in the Azure portal (see below)
- Set configuration of the MyConfiguration.cs (see below)
- Run the sample