We are using an Azure Classic Virtual Machine!! It does not show 'AutoShutDown' Blade. Is this feature not available for Classic VM? When I searched, there is also an option to use Runbook in Automation Account to do this. Is anyone used this with classic VM?
This feature is not available with classic vms. its 2019, you should migrate to ARM anyway. but you could use custom powershell runbook to shutdown classic vms using a schedule.
you'd need to tag the resource groups (cant tag classic resources) and invoke the runbook hourly. this would be a nice starting point. in fact it does what you ask for.
Related
My goal is to have a VM to run builds for Azure DevOps with a user-assigned managed identity so we can keep everything connectionStringLess.
I have just created an Azure Lab and a VM in it.
The reason for this in the lab is so we can shut it down during nights and weekends.
However, I can't find the option to assign managed identities to it.
If possible, how do I do it?
Looks the lab VM (Microsoft.DevTestLab/labs/virtualmachines) does not support MSI currently, you need to use the azure VM(Microsoft.Compute/virtualMachines).
Reference - Services that support managed identities for Azure resources.
Besides, I notice you use the lab VM for auto-start/stop reason, actually the Azure VM also supports that, see Start/Stop VMs during off-hours solution in Azure Automation, not only schedule VMs to start and stop, but also other features.
Is there any way in which I can automate stopping my VM on a Friday and starting this back up again on the Sunday evening at specified times?
I’m aware this is possible via the VM blade and DevTest labs but their only option is daily, whereas I want this only shut down in the weekends.
Any input will be greatly appreciated. Thanks
Given that you need more precise control over scheduling than is possible in the Azure VM Auto-Shutdown blade or Azure Dev-Test Labs, you can accomplish startup / shutdown on specific days via RunBooks in an Azure Automation Resource.
Create (or choose an existing) Azure Automation Account resource
In the new Automation resource, go to the Runbooks blade
Click "Browse Gallery"
Search for and import "Stop Azure V2 VMs" and "Start Azure V2 VMs" runbooks
Schedule the new runbooks to run as needed
This walkthrough shows how to setup your runbooks with a specific schedule and parameters to target your virtual machine(s).
I would recomment to you, to read this:
http://azurecorner.com/start-stop-windows-azure-vms-according-time-schedule/
We are using Azure Automation DSC and were able to do simple things like create Automation account, create Resource group, VM creation and even able to deploy a web site on the target VM. All using powershell scripting.
How can we deploy Azure Cloud Services (web role / worker role)? what are the cmdlets? Any pointers? Please help.
What more things can be achieved using this? Moreover what limitations we can expect here.
Best Regards
Azure DSC is really focused on Azure's Infrastructure as a Service (IaaS) offering. Basically you can configure virtual servers (Windows and Linux) hosted on Azure.
To manage configurations for other services in Azure it is recommended to utilize Azure Resource Manager (ARM) which will allow you to define and configure Azure services in JSON.
Microsoft offers a lot of Quick Start ARM templates that can be accessed at the Azure Quickstart site.
I have started exploring Azure Site Recovery with VMware as a disaster recovery solution for our customers. The main doubt I have is on how to automate failovers. I.e. how can I tell Azure to check if an on-prem VM is offline and automatically initiate the failover process? Do I need something like OMS to make it happen or should Automation runbooks or something similar be enough?
OMS does not have the solution to automate. But, automation runbooks like you guessed are supported by ASR. However you cannot use automation for individual VM's per se. You can use automation on recovery plans and have one VM as part of that plan.
This should give you some insight.
[1]: https://azure.microsoft.com/en-us/documentation/articles/site-recovery-runbook-automation/
In Azure there are 2 options available to create virtual machines.
A. normal VM
B. Classic VM
Does anybody know what is the difference between both option? When do we use one over other?
Short answer to your question is Normal VM or Virtual Machines is the new way of deploying your Virtual Machines whereas Classic VM or Virtual Machines (Classic) is the old way of deploying them. Azure is pushing towards the new way of deploying resources so the recommendation would be to use it instead of old way. However please keep in mind that there're some features which are available in the old way that have not been ported on to the new way so you just have to compare the features offered and only if something that you need is not available in new way, you use the old way.
Now comes the long answer :)
Essentially there's a REST API using which you interact with Azure Infrastructure.
When Azure started out, this API was called Service Management API (SMAPI) which served its purpose quite well at that time (and to some extent today). However as Azure grew, so does the requirements of users and that's where SMAPI was found limiting. A good example is access control. In SMAPI, there was access control but it was more like all-or-none kind of access control. It lacked the granularity asked by users.
Instead of patching SMAPI to meet user's requirement, Azure team decided to rewrite the entire API which was much simpler, more robust and feature rich. This API is called Azure Resource Manager API (ARM). ARM has many features that are not there in SMAPI (my personal favorite is Role-based access control - RBAC).
If you have noticed that there are two Azure portals today - https://manage.windowsazure.com (old) and https://portal.azure.com (new). Old portal supports SMAPI whereas new portal supports ARM. In order to surface resources created via old portal into new portal (so that you can have a unified experience), Azure team ended up creating a resource provider for old stuff and their names will always end with (Classic) so you will see Virtual Machines (Classic), Storage Accounts (Classic) etc. So the resources you create in old portal can be seen in the new portal (provided the new portal supports them) but any resources you create in the new portal using ARM are not shown in the old portal.
The Azure Virtual Machine (classic) is based on the old Azure Service Management Model (ASM). Which revolved around the concept of a cloud service. Everything was contained inside a cloud service, and that was the gateway to the internet. While it is still used (extensively) Azure is now moving over to the Azure Resource Management Model (ARM).
ARM uses the concept of declarative templates to configure an entire solution (rather than individual components) So you can create an entire Sharepoint stack, rather than just a singular machine.
ARM also has a much more logical approach to networking. Instead of having a monolithic VM in an obscure cloud service. You have a VM, that you attach a network card to. You can then put the Network card into a VNet and attach a public IP (if you need one)
Unless you have a compelling reason to use ASM (classic) You should create your solution using ARM. As this is the MS recommendation going forward (todo find a link to that) It also means that you can create templates for your deployments, so you can have a repeatable solution.
On the negative, the old portal manage.windowsazure.com can not manage anything that is deployed using ARM, and there are still parts of ASM that haven't been migrated over to ARM yet. For instance you cannot configure Azure VM backup, since Azure backup is ASM and it can't 'see' ARM VMs
It very largely depends on your circumstances though, what it is you are planning for, the method you are going to deploy with. If you are just looking to stand a machine up to do a single task, it makes very little difference. If you are looking to deploy into an environment that will have some concepts of DevOps going forward, then ARM is the way to go.
The one big differences is for resource management. For that new version is called Azure Resource Manager VM (ARM VM).
ARM VM is better in terms of;
Classic VM must be tied with Cloud Service, and Cloud Service consumes resource limitation and not-so-flexible network configuration.
ARM VM is managed under Azure Resource Manager (ARM) which can be organized with/without other Azure services. ARM is like a folder of Azure services, and it gives you more fine-grained resource management.
Classic VM can be migrated to ARM VM version, but you have to afford service downtime. To migrate from classic VM, read the official article: Considerations for Virtual Machines.
Azure provides two deploy models now: Azure Resource Manager(Normal) and Azure Service Management(Classic) and some important considerations you should care when working Virtual Machines.
Virtual machines deployed with the classic deployment model cannot be included in a virtual network deployed with Resource Manager.
Virtual machines deployed with the Resource Manager deployment model must be included in a virtual network.
Virtual machines deployed with the classic deployment model don't have to be included in a virtual network.