Hi there, welcome back. In this demonstration, I'm going to walk you through the process of deploying a Windows virtual machine using the Azure portal. When we deploy it, we're going to deploy into the availability set that we set up earlier.

So on the screen here, I'm logged into my Azure Portal, and I'm in my VM course resource group that I created prior to creating my availability set. I'm also logged in as my administrator. To begin the process of our VM deployment.

From my resource group here, I can either go out to the hamburger and create a new resource, or I can click add here along the top menu bar. From the marketplace, I can either search for what I'm looking for, or I can just select my Windows Server 2016 data center from the popular list, which is what I'm going to do here.

To complete the deployment of my virtual machine, I need to provide some information in several of these tabs. Some of these tabs are optional. And we'll go through each of these and touch on what's important. When we launch the virtual machine deployment, we're presented with the basic tab.

On this basics tab, we start things off by telling Azure which subscription and resource group will host our virtual machine. You'll have to provide this information for just about any resource you deploy in Azure. So we're going to deploy into the lab subscription and into our VM course resource group.

We then need to give our VM a name, so I'll just call it VM one. If we hover over the icon here, we can see that a virtual machine has two distinct names. It has the virtual machine name and the guest hostname. That's the name within the operating system.

Now when you create a VM in the portal, the same name that you specify here, is used for both the virtual machine name and the hostname. It's also important to note that as you can see here on this pop up, the virtual machine name cannot be changed after the VM is created. You can however, change the hostname within the OS once you've logged into it.

So we'll call this VMO one and we'll deploy into central US. This availability option here, if we hover over it gives us the ability to deploy our virtual machine into either an availability zone or an availability set. We talked about the differences between these two earlier.

What we're going to do here for this exercise is deploy into an availability set. When we select it, we're then prompted with another drop down, where we can choose from any previously deployed availability sets. We can see here I have my avail set, so we'll select it. And if we didn't have any availability sets here, we did have an option here to create a new one. We can see in our image here that we're deploying a Windows Server 2016 data center server, although we could drop down here and select some other image to deploy from. But we'll leave it here at 2016. And the spot instance, option here allows you to purchase unused Azure compute capacity, and it allows you to do that at a discounted rate.

Now, that being said, you don't want to deploy Virtual Machines using spot instances unless they can tolerate an outage. If we click on learn more about spot instances here, we can see right out of the gate that Microsoft allows you to use spot instance VMs to take advantage of unused capacity at a cost saving.

The very next sentence here is that at any point in time, when Azure needs that capacity back, Azure is going to evict your spot instance. So what this means is that spot Vms and Microsoft mentions it here. It mentions here that spot VMs are good for workloads that can handle interruptions. And what that means is a VM that batch processes jobs or something that you use in a dev test environment, would be good for spot VMs but anything that can't tolerate an interruption would be something that you don't want to use spot VM instances for.

So let's close this out. We'll leave this set to No. And then our sizing here, the default size is DS1V2 which is one virtual CPU and three and a half gig of RAM. We can change the size if we want to. And we can see here based on our default filters, the only VMs that are available to us in the small range, Gen two, which are general-purpose machines that support premium discs.

We have a small list of machines here to choose from. If we clear our filters here, we can then see we have the full gamut of VMs that we can take a look at, and possibly deploy if we want to. So let's go back and restore our default filters because I want you to deploy a machine that has premium disk.

So what we'll do for this exercise is deploy a DS2V2 virtual machine, which has two processors and seven gig of RAM. It also supports eight data disks. So we'll go ahead and select this new size. And then we need to provide some administrator information. This administrator account info is the local admin for the virtual machine. As we scroll down here, we can see we then have to configure some inbound port rules and some inbound ports in the default configuration, which is what we're going to do here, this VM will be accessible over the internet via RDP. And you're going to get a little yellow box here with a warning that essentially tells you that, hey, this is probably a bad idea unless you're just doing some basic testing.

This is because what this does is allow RDP to anyone from the internet. This, in turn, leaves your machine open to attacks, and the only thing protecting it is a user and password combination. It's not something you'd want to do in a production environment. Certainly, if we select the drop down for inbound ports, we can see that we can also allow HTTP, HTTPS, and SSH. We'll leave this alone at RDP for now. And if we wanted to allow other ports, we could then go in and configure those later on through a network security group. We'll leave this default setting here and then down the bottom here is Where you can configure your Azure hybrid benefit.

This is essentially the option you have. If you already own Windows licenses with an active SA or Windows Server subscription. You can use this hybrid benefit to save on your licensing costs. We don't have any licensing here, so we'll select No.

Now if I wanted to create a default VM, I could stop here and click review and create. Azure would make some assumptions for me and spin up the VM. But what I wanna do here is walk you through some of these tabs. So instead of reviewing and creating, we'll go ahead and click next for discs.

Now on this disk page, we can specify the disk options for our OS disk, and we can create data disks. If we hover over OS disk type here, we can see that this option allows us to choose between managed disk types to support our workloads. The options we have are standard HDD, standard SSD and premium SSD.

If we're looking for high IOPS for our VM, for example, maybe it's running, it's going to run SQL, then we can select premium SSD. Standard SSD is the recommended OS disc type for most workloads. Standard HDD would be good for test environments or really low end servers.

Obviously, the HDD disks are backed by magnetic disk, while the SSD options are backed by solid state disks. For this demonstration, we'll go with a standard HDD. Now when I do that, I get a prompt here that tells me that my selected VM size supports premium disks. And remember, we ensured we selected a VM size earlier that did support premium discs. And I did that too.

So we get this prompt. What this is telling me here is that if I select a standard HDD disk, I'm going to lose out on the connectivity SLA. What Microsoft here is telling me is that we should use a premium SSD if we have high IOPS workloads. It also tells me here that virtual machines that use premium SSD disks qualify for the 99.9% connectivity SLA.

I'm not worried about the SLA for this demonstration. So I'll leave this here at standard HDD. We can also see here, this enable ultra disk compatibility is designed for delivering high throughput. We can see here that we don't have access to ultra disk compatibility, because it's not available for this VM size or this location. So we're fine here.

We'll leave that default it and then what we'll do here is create a data desk and generally speaking, you'll want to create data discs because you want to leave your OS disk, just for that the OS. So to create a data disc, we'll go ahead and click create and attach a disk. And then in the name box, it gives it a default name, which we can change. I'll leave this alone. And then in the source type, we can create a disk from either a snapshot of another disk, a blob that's in a storage account or we can create an empty disk.

If we select the drop down here we can see the options snapshot, storage blob, or none an empty disk. We'll create our empty disk here. And we can see the default is one terabyte premium SSD. We can also change this size, which I'm going to do and I'll drop this down to standard HDD as well.

This is a lab environment so I'm not trying to go broke using SSD everywhere. When we do this, we can either select a pre-configured size, or we can customize the size. So I'll just create a 10 gig data disk. And we can okay. We can see it's now 10 gig and we'll okay it.

When we create our data disk, we have the option of setting our host caching, we can set the caching for the disk to none read-only or read-write. Let me close my safe password here. The default here is read-only. So we'll leave the read-only at its default here.

With our disk configured, let's go ahead and click next for networking. And on this tab, we need to specify our network interface information. We need to configure our port information and security information and then some additional accelerated networking and load balancing options.

The virtual network if we hover over here, we can see that it operates much like a traditional network in a physical data center. VMs on the same virtual network can access each other by default, there's nothing blocking communications. When you deploy a virtual network, which is necessary for a VM, you will also have to specify a subnet.

We can see since we have no virtual networks deployed already, it's creating a new virtual network for us. If I select the drop down here, I can see I do have some other virtual networks and other resource groups that are available. But for this exercise we'll allow it to create the new virtual network called VM course dash v-net.

When it creates the new virtual network. It's also going to create a default subnet. If we hover over the icon for the subnet, we can see that a subnet is a range of IP addresses that falls within the virtual network. So whatever range is defined for the subnet needs to fall within the address space that is defined for the virtual network.

We're allowing Azure to do this for us. So Azure will make sure it falls within the correct range. The public IP address allows us to access the VM from outside the local network, we have two options here, we can create a new public IP, or we can set it to none.

If we set it to none, we can't remote to it from the internet, we can only access it via the internal address from the virtual network that it's on or maybe over a VPN that's connected to it. We don't have any that infrastructure in place. So we'll allow it to create the new public IP called VM or one IP. We could also create one manually here on our own. So I'll close this.

The network security group here is a set of rules that we can use to allow or deny inbound and outbound traffic to and from our virtual machine. Now in this pop up here, what Microsoft is actually doing is recommending that in order to simplify management of our security rules, they're telling us that what we should do is associate the network security group to individual subnets, rather to specific interfaces on VMs. Because if you define a NIC network security group here for this VM, and then we create a Nic network security group for the next VM that we create, and the one we created for that, and the one after that, you now have a whole bunch of VMs with separate Nic network security groups that need to be managed by creating a single network security group and assigning it to the subnet that hosts those VMs you only have one to manage.

For this exercise, we'll let it create a basic Nic network security group for us. Then we have the same option here for public inbound ports. If we hover over the icon here, this setting tells us what we can allow into our VM. We can either block everything, or we can allow selected ports. We're going to allow RDP by default. And again, we get the notice here that this is a bad idea. That's fine, it's a test environment. And then if we hover over accelerated networking, we can see that what we can do here is enable low latency and high throughput networking for this network interface. I'm not worried about that right now for this demonstration, so we'll leave this set to the default on.

And then under load balancing, if we change the option here to yes, we can configure a load balancer for our virtual machine. Now this load balancer doesn't get us everything we want unless we add a second or third or fourth VM to that load balancer. We're not going to do any load balancing for this demonstration. So we'll turn load balancing off.

If we click next for management here, we can see that we have some management information we can provide, we can see that Azure is telling me that I already have Azure Security Center, protecting my subscription. And then I can also down here, configure some monitoring and some identity-related settings.

Further down, we can configure the auto-shutdown and backup. So let's bounce back up here. And the boot diagnostics, if we hover over it allows you to capture serial output and screenshots of the VM. For example, when it's booting up, this helps troubleshoot any issues that the VM has at boot up time.

The OS guest diagnostics allow you to capture metrics for every minute of the virtual machine is running. Now, because we have boot diagnostics on, we're also prompted for a diagnostics storage account. This is because we need a storage account to host the data that diagnostics is going to dump out.

You'll notice if I turn this off, we now have new monitoring, so we have no requirement for a storage account. If we turn boot diagnostics back on, it's asking me for a diagnostic storage account. If I select the drop down, you can see I have a couple different ones that are available, but we have none in this resource group.

So what I'll do is all allow this to create a new diagnostics storage account. The default option for OS guest diagnostics is off so we'll turn this on. Now under the identity section here, we can configure a system-assigned managed identity and Azure Active Directory options, if we hover over the icon here, we can see that a system-assigned managed identity allows Azure resources to authenticate to cloud services like Key Vault, without needing to store credentials in any kind of code.

Essentially, if you use a system-assigned managed identity, permissions can be granted via the role-based access control right to the resource. We're not going to use system-assigned managed identity here, nor are we going to use the option to log in with Azure Active Directory credentials.

If we hover over the icon here, we can see that this option allows us to use our corporate AD credentials to log into the VM enforce MFA and to enable access via our back roles. We can see that this image doesn't support login with Azure Active Directory anyway, so it's off. And then these last two options are pretty self-explanatory, we can configure auto shutdown, which allows us to configure the virtual machine to automatically shut down at a particular time of day.

If we click on here, we can specify the time that we want our VM to shut down, along with the timezone. We also have to tell Azure if we want a notification prior to shut down and where that notification should go. We're not going to auto shut down this VM, so we'll turn that back off and then of course, we have the backup option here, which allows us to configure our virtual machine to be backed up using Azure backup.

If we click on, we could then create the recovery services vault that Azure backup needs, and then we could create a backup policy. We're not too worried about backup right now so we'll leave this off and then we'll go to advanced.

In this advanced section here, we can configure extensions, we can configure cloud in it, we can look at Azure dedicated hosts and we can configure proximity placement groups, and then select the VM generation we want to use. Extensions are used to provide post-deployment configuration and automation.

If we hover over the icon here, we can see that we can add new features, or even anti virus protection to the VM through an extension. For example, if we select an extension to install, we have a bunch of different windows features here or Windows applications or agents that we can install. If we wanted to install Microsoft anti-malware, we would select anti-malware and create it.

Now anti-malware is built into defender now so there's no need for anti-malware, so we'll close this out. But this is where you would select what you want to be installed on your VM at the time of deployment. We're not going to use any extensions here, and then clouding it is a way to customize Linux VMs when they boot for the first time, this is a Windows VM so it's telling us that the selected image doesn't support cloud in it, makes sense.

Dedicated hosts allow you to provision a physical server within Azure Data Center. And that physical server is dedicated to your specific Azure subscription. When you configure a dedicated host, what you're doing is ensuring that only VMs from your subscription run on that host, rather than have them shared out across other customers within the Azure landscape.

Now we've got a little icon here that tells us that we can't even use dedicated hosts because we're using an availability set. So keep that in mind, if you deploy in an availability set you can't use dedicated hosts. And then the proximity placement group is something we talked about earlier, it allows you to group those Azure resources physically closer together within the same region.

Under proximity placement group, we have a notice here that the selected availability set is not in a proximity placement group. It's telling us here that if we want to use a proximity placement group, we either can't use an availability set or we need to create a new availability set and this is because the existing one isn't already in the proximity placement group. We're not using a proximity placement group so I'm not worried about it. And then lastly we have the VM generation.

The generation two VMs as you can see here, support features like UEFI-based boot architecture, higher memory and larger OS disk size limits. If we hover over VM generation here, we can see here that our choice to create a generation one or generation two VM is going to depend on the OS and the boot method we want to use.

The key takeaway here is that generation two VMs support most 64-bit versions of Windows, and more current versions of Linux and FreeBSD. We'll leave this set to gen one and then we'll go into tags. And this is where you can tag your machines. Let's say you have a department that needs five VMs, what you can do here is create a tag called department, which I've already created in a previous demonstration for another lab and then what we could do is specify that this VM is for the finance department.

Tagging is a good way to bill back within an organization. So for example, if the finance department asks for 15 virtual machines for some cockamamie application, then you can tag all 15 of those VMs with the Finance Department tag so when it comes time to pay the Azure bill, you can go back to the finance department and say hey, back up for these 15 VMs you asked for.

So it allows you to group your VMs for billing and for management, and for better reporting. So we'll leave this tagged at the finance department and then we can review and create our virtual machine. At this point, we get the validation and Azure is telling us we're good to go but it is giving us a warning here, that again, we have RDP open to the internet.

It's obviously a recurring theme, because they don't want you opening your machines to the internet over RDP, unless you're just doing testing. So we can review our settings here and then if we're happy with our settings, we can click Create.

The deployment of a virtual machine usually takes a good 15 or 20 minutes but what I'll do here is I'll call it a wrap because in the next lesson, we're going to deploy a Linux machine. So before we kick off the Linux deployments, I'll show you the running VM that we've created in this demonstration.

So let's call it a wrap and I'll see you over there.