I have been reading about LocalDB and how it can not be used in Azure Roles (since they do not persist if the role stops working) and that you should move towards either Azure SQL or Azure Storage.
However, is it possible to use the LocalDB in a Windows Azure VM? Because I do not currently have access to a Azure Account I am not able to test this myself.
Kind regards
Tom
Azure VM should work fine, since it is fully persisted and largely compatible with regular Windows. Note that I'm referring to the new Azure VM feature, not the old Azure VM Role, since the VM Role was not fully persisted. Just clarifying the answer in case someone doesn't read the question too carefully.
Related
We are trying to migrate a VM in a private cloud to azure. This VM has multiple web applications and databases. We don't have access to the virtualization, just access to this single VM.
Can anyone suggest how we can do the migration to azure with just having access to the VM itself?
Regards
Anup
As far as I know and as per the document, we can't migrate Single VM without having access to Virtualization.
Because while processing Migration you need to generate Project Key where you need to have access Virtualization.
You can go through the Microsoft Document for further details.
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.
The VM Role preview in Windows Azure ends on May 31, 2013 and Microsoft urges to migrate VM Roles to "proper" Virtual Machines that are in General Availability as described here:
http://msdn.microsoft.com/library/3dae01d2-2397-47ed-a134-f9ffe58a9b52.aspx
But how do I know which of the Virtual Machines running in Azure are VM Roles and which are Windows Azure Virtual Machines?
I wrote a blog post that may help: Do I have VM Roles that I should migrate? at http://blogs.msdn.com/b/benjguin/archive/2013/04/19/do-i-have-vm-roles-that-i-should-migrate.aspx
You probably see it easily in the portal, but an easy check could be to store something on your disk and stop/delete and recreate the machine. If the file is no longer there, that means it's a VM role.
I also believe you cannot see VMRole in the new portal (and only in the old portal)
Is it possible to use an Azure virtual machine as an Active Directory server with ADFS 2.0 and integrate it with ACS ?
Regards ,
James Roeiter
Having AD server (with RMS also) in cloud is an ask which I have heard time to time from Azure users and it sure is a great addition to have it running in Windows Azure or any cloud. Various organization's IT is asking the same as well however As of now with current Windows Azure it is not possible.
A few might suggest that using Windows Azure VM Role however, I would say that there are concern over that as well do to persistence and other issues so I would say it is not possible with Windows Azure VM Role as well and there are other issues related with Active Directory product as well to run in Cloud scenarios.
If I answer it directly, I would say as of now it is not supported and suggested scenario to have AD on Windows Azure and will not work due to various reasons.
You can now install AD on Azure in a persistent state. Its still preview but I have just got an standalone AD on a separate network on Azure. I haven't finished wiring up ADFS and ACS but given a little time to get my head around it and I will be there.
Why would you like to put your AD server in Azure? If it just for testing - you can. However the current state of Windows Azure only allows you to have a VM Role, which is Stateless. That means, you may prepare your VM with the AD, all configured for ACS and fill up with users. However you can't rely on any changes to be persisted (including password changed, user edits). VM Role is stateless, which means you will lose your changes once the role is recycled or rebooted, or healed.
So the final answer for the current Windows Azure offering would be - don't do that now, unless you want to just play around and see if it works.
** EDIT **
I am not an AD expert, what I managed to do and have an "in-house-virtualized" lab is to have ADFS on VM integrated with ACS. Another VM running Windows 7, which is domain joined to my AD. Then a web deployed application which leverage ACS with ADFS integration. Everything works fine.
As for storing AD data on external persistent storage - I don't know if it is possible, and how to configure that (already told you I am not AD expert). But if you know how to configure the storage for AD, and if you can store it in an SQL Azure, it is worth to give it a try.
And, finally, as Sandrino mentioned read the provided link to ZDNet's blog post, which has information you might find helpful.
How can we configure VM Role on Azure Emulator? Is this possible or do i need to do my testing on Windows Azure Management Portal.
Thanks,
Mrinal Jaiswal
On Azure F&Q its written that Emulator supports VM role but to much dismay it doesn't. I talked to Microsoft Tech team and got this answer.
One good thing they told me was, if i want to use VM on Azure it will be better if i use extra-small deployment it will increase my compute hours and i can host 2 extra-small VM role on azure in free trail account.