The completion of your IT transformation from data center to full cloud adoption can often be hindered by your desktop administration. While in the past virtual desktops have largely delivered on their promise to bring standardization, reduce the proliferation of applications and simplify desktop management, they have also had their share of challenges. As an administrator you had few options to:
Create multiple VM pools with customized images for different user roles
Overload virtual machine images with more apps than needed and hide or block them from the user making the image bigger
Utilize dynamic app streaming which required additional infrastructure to be managed.
With Windows Virtual Desktop, Microsoft Azure has transformed virtual desktop delivery by completely separating the user profile data and application delivery from the Operating System to deliver a user experience that parallels that of a physical device, simplifies desktop administration further, and maintains the management of the underlying physical infrastructure.
Benefits of adopting Azure Windows Virtual Desktops (WVD):
Support for Windows 10 and Windows 7 virtual desktops – the only way to safely run Windows 7 after its End of Life (Jan. 14, 2020)
No need to overprovision hardware by aligning costs to business needs – transition from costly CAPEX hardware purchases to OPEX cloud consumption-based model
Simplify user administration by using Azure Active Directory (AAD) – leverage additional security controls like multifactor authentication (MFA) or conditional access
Highly secure with reverse connect technology – eliminates the need to open inbound ports to the VMs, and all user sessions are isolated in both single and multi-session environments
Utilize Microsoft Azure native services – Azure Files for file share and Azure NetApp Files for volume level backups
To help you with the transition from standard desktops or an existing on-premises RDS deployment to Microsoft Azure, 2nd Watch has developed Windows Virtual Desktop Foundations. Windows Virtual Desktop Foundations provides you the blueprints necessary to set up the WVD environment, integrate with Azure native services, create a base Windows image, and train your team on how to create custom images.
With 2nd Watch Windows Virtual Desktop Foundations, you get:
Windows Virtual Desktop environment setup
Integration with Azure native services (AAD and AZ Storage for profiles)
The simple way to describe Azure Cloud Shell is an on-demand Linux VM with a managed toolset that is accessible from virtually anywhere. You can access it via the Azure Portal, shell.azure.com, the Azure Mobile App, and Visual Studio Code. Pricing is simple. you only need to pay for storage that is used to persist your files between Cloud Shell sessions. Finally, Cloud Shell offers two shell experiences – Bash and PowerShell – however you can access PowerShell from Bash and Bash from PowerShell, so just choose whatever you are most comfortable with.
Cloud Shell contains the following tools:
Linux Tools– bash, zsh, sh, tmux, dig
Azure Tools– Azure CLI, AzCopy, Service Fabric CLI
Databases– MySQL client, PostgreSQL client, sqlcmd utility, mssql-scripter
Other– iPython Client, Cloud Foundry CLI, Terraform, Ansible, Chef InSpec
You are probably thinking to yourself, that’s great, but what can I use it for? Good question…
Got a bunch of Azure management scripts that you have developed and need to be able to run? Cloud Shell is a great way to run and manage those scripts. You can leverage git for version control and run PowerShell, Bash, or Python scripts whenever and wherever you are. For example, you are grabbing some lunch and the boss sends you an email asking how many VMs are currently running in your environment and wants the answer right now. Being that this isn’t the first time that the boss has asked this question, you have already created a script that will send a report with how many VMs are currently running. So, you load the Azure Mobile App on your phone, connect to Cloud Shell to run the script and get back to your lunch without having to run back to the office.
Are you an Azure CLI master? Cloud Shell has you covered! Cloud Shell always has the latest version of the Azure CLI without you ever having to maintain a VM or update your local installation.
Need to deploy an agent to a bunch of VMs but don’t want to manage a Configuration Management tool? Once again, Cloud Shell has you covered. Use the built-in Ansible to run a playbook that deploys the agent you need installed.
Do you run a multi-cloud shop? Need to deploy things to both Azure and AWS? Then you are in luck! With Cloud Shell you can use Terraform to deploy both Azure and AWS resources. Another multi-cloud idea would be to install the AWSPowerShell.NetCore PowerShell module to be able to perform day-to-day tasks and automation of AWS.
There are some limitations of Cloud Shell, such as your Cloud Shell session being temporary. It will be recycled after your session is inactive after 20 minutes.
The pricing for Azure Cloud Shell is great. Like I mentioned before, you only pay for storage. Storage is used to persist data between instances of Cloud Shell. If you install a PowerShell module or use git to clone a repo, the next time you fire up Cloud Shell, those files are still there.
I love an all you can eat buffet. One can get a ton of value from a lot to choose from, and you can eat as much as you want or not, for a fixed price.
In the same regards, I love the freedom and vast array of technologies that the cloud allows you. A technological all you can eat buffet, if you will. However, there is no fixed price when it comes to the cloud. You pay for every resource! And as you can imagine, it can become quite costly if you are not mindful.
So, how do organizations govern and ensure that their cloud spend is managed efficiently? Well, in Microsoft’s Azure cloud you can mitigate this issue using Azure resource policies.
Azure resource policies allow you to define what, where or how resources are provisioned, thus allowing an organization to set restrictions and enable some granular control over their cloud spend.
Azure resource policies allow an organization to control things like:
Where resources are deployed – Azure has more than 20 regions all over the world. Resource policies can dictate what regions their deployments should remain within.
Virtual Machine SKUs – Resource policies can define only the VM sizes that the organization allows.
Azure resources – Resource policies can define the specific resources that are within an organization’s supportable technologies and restrict others that are outside the standards. For instance, your organization supports SQL and Oracle databases but not Cosmos or MySQL, resource policies can enforce these standards.
OS types – Resource policies can define which OS flavors and versions are deployable in an organization’s environment. No longer support Windows Server 2008, or want to limit the Linux distros to a small handful? Resource policies can assist.
Azure resource policies are applied at the resource group or the subscription level. This allows granular control of the policy assignments. For instance, in a non-prod subscription you may want to allow non-standard and non-supported resources to allow the development teams the ability to test and vet new technologies, without hampering innovation. But in a production environment standards and supportability are of the utmost importance, and deployments should be highly controlled. Policies can also be excluded from a scope. For instance, an application that requires a non-standard resource can be excluded at the resource level from the subscription policy to allow the exception.
A number of pre-defined Azure resource policies are available for your use, including:
Allowed locations – Used to enforce geo-location requirements by restricting which regions resources can be deployed in.
Allowed virtual machine SKUs – Restricts the virtual machines sizes/ SKUs that can be deployed to a predefined set of SKUs. Useful for controlling costs of virtual machine resources.
Enforce tag and its value – Requires resources to be tagged. This is useful for tracking resource costs for purposes of department chargebacks.
Not allowed resource types – Identifies resource types that cannot be deployed. For example, you may want to prevent a costly HDInsight cluster deployment if you know your group would never need it.
Azure also allows custom resource policies when you need some restriction not defined in a custom policy. A policy definition is described using JSON and includes a policy rule.
This JSON example denies a storage account from being created without blob encryption being enabled: