can anyone brief me about difference between both? Points that I am expecting in answers
can we install Software
Who is the owner
Can I access my local files and software into cloud machine?
any addons from your side will be more than helpful!
Azure Virtual Machine
An Azure VM gives you the flexibility of virtualization without having
to buy and maintain the physical hardware that runs it. However, you
still need to maintain the VM by performing tasks, such as
configuring, patching, and installing the software that runs on it.
We can install the applications in Azure VM. Use Set-AzVMExtension in PowerShell to install the Custom Script Extension.
To know more in detail, please refer below link:
Tutorial - Install applications on a Windows VM in Azure - Azure Virtual Machines | Microsoft Docs.
By default, the users who created the VM with Owner or Contributor roles are considered VM owners.
To know more in detail, please refer below link:
VM Owner Detection for Azure (commvault.com).
It is possible to access local files in Azure VM.
Azure Windows Virtual Desktop
Windows Virtual Desktop (WVD) is an Azure service that, combined with appropriate licenses, services, and resources, delivers a complete
virtualized multi-user Windows 10 (or a single-user Windows 7)
experience together with Office 365 ProPlus. WVD includes centralized
management and monitoring; system administrators can quickly deploy and manage desktops, apps, and Windows servers in the Azure Cloud.
We can install the applications in Azure Windows Virtual Desktop.
To know more in detail, please refer below link:
https://www.rebeladmin.com/2020/07/step-step-guide-publish-applications-using-windows-virtual-desktop-spring-2020-release/
Azure Windows Virtual Desktop doesn't have a specific Owner role. You can use the general Owner role for the service objects.
Related
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)
Microsoft Azure cloud supports three roles Web, Worker and VM with different capabilities to be utilized by application developers.
If I understand correctly when we use Web or Worker role, Azure acts more like PaaS while using VM role puts Azure in IaaS role.
Web, Worker roles has the advantage of OS/Platform being managed by the Fabric Controller (updates to OS etc), where with VM we have to manage those ourselves.
My question is, if we implement a private cloud using solutions provided by Microsoft, Can we still create Web/Worker roles on our private cloud, or is it limited to VM roles?
Cloud Services, which you're describing, are comprised of Web / Worker / VM roles, with Web and Worker OS's maintained by Microsoft and VM Role maintained by you (with multiple instances all based off the baseline image you upload). In all three cases, any type of new image creation is like starting fresh: changes made to the OS while running are not permanently persisted. VM Role does not put Windows Azure into IaaS mode, as the fabric is still using a single baseline image to manage role instances. IaaS, with Virtual Machines, is a bit different, with the Virtual Machines constructable in the cloud (vs. VM Role that requires them to be built locally and then uploaded). Further, any change to a Virtual Machine is persistent. When scaling to multiple instances, you'd need to make VHD copies from your master image, and then each instance would be living on its own (e.g. a change to one Virtual Machine will not show up in the other Virtual Machines).
Having said all that: You have access to Cloud Services (web/worker/vm role) only in Windows Azure today; there's no way to run these locally.
Recently we announced the availability of Windows Azure services for Windows Server. You'll see that there is a subset of Windows Azure features runnable on Windows Server:
Web Sites
Virtual Machines
Service Management Portal and API
The answer is not yet. WebRole and WorkerRole PAAS are relying on Azure Fabric Controller and that thing does not yet run on premise outside of Microsoft's control, as far as I know.
Yea as far as I'm aware you can, I haven't tried it myself, you need to create a VNET and then create your Cloud Services within your VNET, Michael Washam has a good post detailing it: Connecting Web or Worker Roles to a Simple Virtual Network in Windows Azure
We're trying to get the cpu percentage,disk read throughput,etc programmatically using powershell commands for metrics in azure but we are not able to get any of the commands according to new release.
First of all are you trying to get performance details from Web/Worker Role or New preview release of Windows Azure Virtual Machines?
With Windows Azure Virtual Machine:
You have full access to your Azure VM and configure it the way you would do in any remote VM and the get the performance data out of it. With Windows Azure Virtual Machine if you want to get Performance data from Powershell you would need to do the following:
Configure to Azure VM to have PowerShell Remote Access
Configure Azure VM port settings so you can connect from on-premise machine (this is must and you should know that open port will open connection to VM outside)
Configure Azure VM to collect performance data
Connect from your on-premise machine using PowerShell and collect performance data
You can find several resources on Internet to do above task.
With Web/Worker Role:
Even when you are using new Powershell cmdlets with Windows Azure, older commands are still accessible and working as expected. To get Performance metrics from Azure Here are some resources for your to try:
Windows Azure Diagnostics and PowerShell – Performance Counters:
Part 1 | Part 2
How To Easily Enable Windows Azure
Diagnostics Remotely
I would like to create vhd file for Machine which i have connected from Auzre portal remotely.
I had gone through VM roles in window azure and came to point that first i required to take image of machine and for that requires Hyper-v Manager but it is also available on Window server 2008 R2 , so i have configured os of my deployment to R2 but still there is no option of Hyper-v Manager.
Not sure I completely understand your question, but I think you're asking about managing your VHDs in Windows Azure with Hyper-V running in Windows Azure. Is that correct?
In Windows Azure, there's no Hyper-V Manager that you access. You only use Hyper-V locally, on a local Windows 2008 server, to create your VHDs. These VHDs are then uploaded to Windows Azure.
I suggest you download the Windows Azure Platform Training Kit and run through the Virtual Machine Role lab, as it shows all the necessary steps. You'll see that all Hyper-V access is done on-premise, not in Windows Azure. Once the vhd is created:
Mount a drive containing the Windows Azure extensions, and install those to your vhd.
Run the csupload command line tool (part of the Windows Azure SDK) to upload your vhd to your Windows Azure account.
Create a new Windows Azure project in Visual Studio, adding a VM Role, configuring it to look into your subscription and letting you select the vhd you just uploaded.
Create a new Hosted Service via the portal, then uploading the newly-created Windows Azure deployment package.
There are more details to each of those steps, which are all spelled out in great detail in the VM Role lab mentioned above.