azure portal

Azure – Cost Management Better Than Ever Using Cloudyn (Registration)

Microsoft’s acquisition of Cloudyn will help Azure customers manage and optimize their cloud usage. Read more about the acquisition here. A message from Sharon Wagner, CEO of Cloudyn.

About Cloudyn

Azure Cost Management by Cloudyn empowers organizations to monitor cloud spend, drive organizational accountability, and optimize cloud efficiency so they can accelerate future cloud investments with confidence.

Microsoft’s acquisition of Cloudyn will help Azure customers and partners as they face the challenges of growing their multi-cloud environments. It will enable them to gain visibility, understand and optimize cloud consumption, as well as accurately project future usage.

Microsoft will continue to support multi-cloud environments, including Azure, AWS, and GCP. Azure Cost Management by Cloudyn is available for free to customers and partners managing Azure spend. Additional premium capabilities are available at no cost through June 2018, once they will become paid features.

Let us look into how to sign up to Cloudyn if you are an Azure customer

Step 1: Login to your Azure Subscription via the Azure portal. Select the “Cost Management + Billing” blade. Then select “Cost Management” from the options on the left-hand side of the pane.

Click on “Go to Cost Management”

Step 2: Once you click the”Go to Cost Management” button, you will be redirected to Cloudlyn’s page to set up your Cost Management details.

Enter your organization name and the type of Azure access you have on your Azure account. I have a personal subscription, so I have chosen as “Azure Individual Subscription Owner.”

Step 3: Cloudlyn Account name and Tenant ID will be automatically populated. Now, select the offer-ID from the drop-down list.

If you do not know your Offer-ID, then go back to your Azure portal. Click on “Subscriptions,” that should provide you the type of subscription that you have.

Step 4: Click “Next”

Step 5: Click “Next”

Step 6: We are done with the registration with Cloudlyn. Cloudlyn needs about 2 hours for collecting the data.

If you find the content valuable, do consider sharing with your friends and colleagues.

Click here to download my PowerShell scripts for Free !!

Azure – PowerShell in Azure Cloud Shell

Today we are looking into PowerShell in Azure Cloud Shell. This is still in public preview as of this writing.

If you are wondering why Microsoft would introduce a PowerShell console inside the Azure Cloud Shell, then have a look at the below features:

Features

Browser-based shell experience

Cloud Shell enables access to a browser-based command-line experience built with Azure management tasks in mind. Leverage Cloud Shell to work untethered from a local machine in a way only the cloud can provide.

Choice of preferred shell experience

Azure Cloud Shell gives you the flexibility of choosing the shell experience that best suits the way you work. Linux users can opt for a Bash experience, while Windows users can opt for PowerShell.

Pre-configured Azure workstation

Cloud Shell comes pre-installed with popular command-line tools and language support so you can work faster.
View the full tooling list for Bash experience and PowerShell experience.

Automatic authentication

Cloud Shell securely authenticates automatically on each session for instant access to your resources through the Azure CLI 2.0.

Connect your Azure File storage

Cloud Shell machines are temporary and as a result, require an Azure file share to be mounted as clouddrive to persist your $Home directory. On the first launch, Cloud Shell prompts to create a resource group, storage account, and file share on your behalf. This is a one-time step and will be automatically attached for all sessions. A single file share can be mapped and will be used by both Bash and PowerShell in Cloud Shell.

Below are some conditions that we have to remember:

Cloud Shell runs on a temporary machine provided on a per-session, per-user basis
Cloud Shell times out after 20 minutes without interactive activity
Cloud Shell can only be accessed with a file share attached
Cloud Shell uses the same file share for both Bash and PowerShell
Cloud Shell is assigned one machine per user account
Permissions are set as a regular Linux user (Bash)

Now that we have some background knowledge on the PowerShell in Cloud Shell, let us dig more into the usage of it:

To access the Cloud Shell, click on the PowerShell icon in the Azure portal:

Once you click on the icon, a pane is opened at the bottom of the screen as shown below. You can choose from two options – BASH or PowerShell. Since we are interested in learning PowerShell in CloudShell, let us choose PowerShell as our desired option.

When you are starting for the first time, the Shell will configure an Azure File Storage. Cloud Shell machines are temporary and as a result, require an Azure file share to be mounted as clouddrive to persist your $Home directory. Alternatively, if you have multiple subscriptions, you will be allowed to choose your favorite subscription to work with.

Azure Authentication, Resource Group, Storage Account and File Storage are automatically created as shown below:

Testing an Azure command. Works perfectly.

If you are idle for more than 20 minutes, you will be kicked off the session, and you will have to start the session again:

Discovering the drives under PowerShell in Cloud Shell:

Now let us execute the Get-ChildItem cmdlet and see what we can find.

As we can see, running the Get-ChildItem in the current scope will list out the subscriptions that your account is associated with.

Traversing one step deeper into the directory, we can see the resources related to the subscription.

Let us get into the “StroageAccounts” directory to confirm if we get to see a list of Storage Accounts under the selected subscription:

PowerShell cmdlets to manage PowerShell in Cloud Shell:

From the below information, we can see that Microsoft provides us two cmdlets to work with the cloud shell.

Get-CloudDrive provides the details of the “Azure File Share” that was created when the cloud shell started. You may continue to use the cloud share. However, if you want a new one, you can dismount and create a new one using the Dismount-CloudDrive cmdlet.

Note: Once you dismount the Azure file share, your current session will be restarted to set up a new cloud share.

Assumption:

I am assuming that Microsoft is using container service infrastructure to provide a session. You will get the below windows path when you query for the temp drive:

C:\Users\ContainerAdministrator\AppData\Local\Temp

Note the administrator is a “ContainerAdministrator.” The container here could be a Windows Server or a Windows Container. I am assuming it is a Windows Container since the underlying “image” comes pre-packaged with below tools and a temporary one. A typical use case scenario for Container technology.

If the content is valuable to you, do consider sharing it with your friends and colleagues.

Did I miss out anything? Let me know in the comments section.

Download my PowerShell scripts for Free!

Azure – Configure Storage Spaces for Azure VM for increased disk performance

This blog will walk you through on how to configure Storage Spaces for Azure Virtual Machine (Windows). Finally, we get to see some IOPS benchmarks.

Each data disk (Standard Storage Account) has about 500 IOPS. In this example, we are going to create a Storage Space by attaching 4 data disks to a Standard A2 sized Azure VM. In theory, this should increase the IOPS to 2k. (500 x 4 = 2000)

Configuring Storage Spaces for Azure windows VM

Step 1: Attach four data disks to your virtual machine.

From the azure portal, select your virtual machine >> Click on “Disks” >> click on the “+ Add data disk” >> Fill out the details accordingly >> Save the disk.

Repeat this process 3 more times and we will have 4 data disks attached to our virtual machine as shown below:

Inside the VM, we can see the disks attached:

4_disk_not_initialized

Step 2: Login to the virtual machine and run the following PowerShell cmdlets. This will configure Storage Space and will create a drive for you.

In our example, we will configure one volume. Hence, only one storage pool. If you are implementing SQL Server or any other architecture, you may need more than one storage pool.

New-StoragePool –FriendlyName StoragePool1 –StorageSubsystemFriendlyName “Storage Spaces*” -PhysicalDisks (Get-PhysicalDisk -CanPool $True)

Retrieve the disks from the pool and store it in a variable:

$Disks = Get-StoragePool –FriendlyName StoragePool1 -IsPrimordial $False | Get-PhysicalDisk

Create a new virtual disk using all the space available from the storage pool using a Simple configuration. The interleave is set to 256KB. We are also setting the number of columns to be equal to the number of disks in the pool

New-VirtualDisk –FriendlyName VirtualDisk1 -ResiliencySettingName Simple –NumberOfColumns $Disks.Count –UseMaximumSize –Interleave 256KB -StoragePoolFriendlyName StoragePool1

Format the disk with NTFS filesystem and a 64KB allocation unit size.

Get-VirtualDisk –FriendlyName VirtualDisk1 | Get-Disk | Initialize-Disk –Passthru | New-Partition –AssignDriveLetter –UseMaximumSize | Format-Volume –AllocationUnitSize 64KB

Below is a snippet of the PowerShell console after executing the above cmdlets.

Finally, we can see the drive. A drive named “E” will be created with a free space of ~4TB.

Benchmark Tests

Obviously, this works. However, I have run IOPS test to have a visual. You may choose any standard benchmark testing tools. To keep it simple, I have used a PowerShell script authored by Mikael Nystrom, Microsoft MVP. This script is a wrapper to the SQLIO.exe. You may download the PowerShell script and SQLIO.exe file, HERE.

Download the archive file to your local system and copy it to the server. Extract the contents to any folder.

Below is a sample script to estimate IOPS:

.\DiskPerformance.ps1 -TestFileName test.dat –TestFileSizeInGB 1 -TestFilepath F:\temp -TestMode Get-SmallIO -FastMode True -RemoveTestFile True -OutputFormat Out-GridView

Feel free to tweak the parameter values for different results.

Explaination of parameters:

-TestFileName test.dat

The name of the file, it will create the file using FSUTIL, but it checks if it exists and if it does it stops, you can override that with the –RemoveTestFile True

–TestFileSizeInGB 1

Size of the file, it has fixed values, use the TAB key to flip through them

-TestFilepath C:\VMs

The folder can also be an UNC path, it will create the folder so it does not need to exist.

-TestMode Get-SmallIO

There is too test modes Get-LargeIO or Get-SmallIO, you use Get-LargeIO to measure the transfer rate and you use Get-SmallIO to measure IOPS

-FastMode True

Fast mode true runs each test for just 10 seconds, it gives you a hint, if you don’t set it or set it to false it will run for 60 sec (it will take a break for 10 sec between each run)

-RemoveTestFile True

Removes the test file if it exists

-OutputFormat Out-GridView

Choose between Out-Gridview or Format-Table

IOPS for C drive on Azure VM [OS Disk]:

C_drive

IOPS for D drive on Azure VM [Temporary Disk]:

D_drive

IOPS for E drive on Azure VM [Standard data disk]:

E_drive

IOPS for F drive on Azure VM [Storage Spaces]:

F_drive

We can use this storage strategy when we have a small amount of data but the IOPS requirement is huge.

Example scenario:

You have 500GB of data, and the IOPS for that data exceeds 1K. Storing 500GB of data in one data disk will create IOPS problems since each data disk has a 500 IOPS limit. But, if we combine 4 disks and create a storage space, the IOPS will increase to ~2k [we have to consider latency etc., to have a correct figure]. Since we are using the same Standard A2 virtual machine and Azure charges for the overall data and not per disk, the pricing will be the same.

Azure – Configure a Point-To-Site Connection to a Vnet using Azure Portal

A Point-To-Site(P2S) configuration lets you create a secure connection from an individual client computer to a virtual network. A P2S connection is useful when you want to connect to your VNET from a remote location, such as from home or a conference, or when you only have few clients that need to connect to virtual network.

P2S connections do not require a VPN device or a public-facing IP address to work. A VPN connection is established by starting the connection from client computer.

Below are the operating systems that we can use with Point-To-Site:

Windows 7 (32-bit and 64-bit)
Windows Server 2008 R2 (64-bit only)
Windows 8 (32-bit and 64-bit)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 (64-bit only)
Windows Server 2012 R2 (64-bit only)
Windows 10

This blog walks you through creating a Vnet with Point-To-Site connection in the Resource Manager deployment model using the Azure Portal.

This is a 9 step process:

PART 1 – Create Resource Group

PART 2 – Create Virtual Network

PART 3 – Create Virtual Network Gateway

PART 4 – Generate Certificates

PART 5 – Add The Client Address Pool

PART 6 – Upload the Root certificate .cer file

PART 7 – Download and install the VPN client configuration package

PART 8 – Connect To Azure

PART 9 – Verify your connection

Below are the values that we will use to configure the Point-To-Site connection:

Name: VNet1
Address space: 192.168.0.0/16
For this example, we use only one address space. You can have more than one address space for your VNet.
Subnet name: FrontEnd
Subnet address range: 192.168.1.0/24
Subscription: If you have more than one subscription, verify that you are using the correct one.
Resource Group: TestRG
Location: East US
GatewaySubnet: 192.168.200.0/24
Virtual network gateway name: VNet1GW
Gateway type: VPN
VPN type: Route-based
Public IP address: VNet1GWpip
Connection type: Point-to-site
Client address pool: 172.16.201.0/24
VPN clients that connect to the VNet using this Point-to-Site connection receive an IP address from the client address pool.

PART 1 – Create Resource Group

Click on “Resource Groups” from the side pane >> Click on “ADD” >> Fill in the details >> Click on “CREATE”

PART 2 – Create Virtual Network

Click on “New” >> Search for “Virtual Network” >> Click on “Virtual Network” from the results.
Select “Resource Manager” in the drop down >> Click on “Create”
Fill in the details as below.

Name: Name of your Virtual Network.

Address Space: Address Space of your Virtual Network.

Subnet Name: Name of the default subnet (You can add more subnets later)

Subnet Address Range: The range of the subnet.

Subscription: If you have multiple subscriptions, you can select them from drop down list.

Resource Group: Select the Resource Group that you just created “TestRG”

Location: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will reside.

Add Additional Address Space (Optional)

Click on the Vnet >> under “Settings” click on “Address Space” >> Add the address space that you want to include >> Click on “Save”

Add Additional Subnets (Optional)

Create A Gateway Subnet

Before connecting your virtual network to gateway, we need to first create the gateway subnet for the virtual network to which you want to connect.

Navigate to the virtual network to which you want to connect the gateway. “Vnet1” in our case.
Select the Vnet “Vnet1” >> Under the “Settings” >> select “Subnets” >> In the next pane, click on “+Gateway Subnet” >>
The Name for your subnet will be automatically filled with the value “GatewaySubnet”. This value is required in order for the Azure to recognize the subnet as Gateway Subnet. Fill in the address range that matches your configuration.

GatewaySubnet: 192.168.200.0/24 (In our case)
Click “OK” to create the Gateway Subnet.

Specify A DNS Server (Optional)

You can either choose the Azure-DNS (default one) or your own custom DNS for the name resolution.

Click the Virtual Network “Vnet1” >> Under the “Settings” >> Click on “DNS Server”
You can see that we have two options, Select “Custom” if you have your own DNS server.

But we will go ahead with the default one for our set-up

PART 3 – Create Virtual Network Gateway

Point-To-Site connection require the following settings:

Gateway Type: VPN
VPN Type: Route-Based

In the Azure portal >> Click on “+” (New) >> Search for “Virtual Network Gateway” from the market place >> Select the “Virtual Network Gateway” from the list. >> Click on “Create” Button.
Provide the Virtual Gateway Name. VNet1GW in our case.

Name: Virtual Gateway name (Vnet1GW)

Gateway Type: VPN

VPN Type: Route-Based

SKU: Standard

Virtual Network: The Vnet to which this Gateway has to be attached,

Public IP Address: Public IP to the Virtual Gateway. This will be dynamically assigned.

Subscription: Select the correct subscription.

Resource Group: Select the correct resource group. (TestRG in our case)

Location: Adjust the location, where your Vnet is located.
Connect this Virtual Gateway to our Virtual Network.
Associate a public IP address to the Virtual Gateway

Click on the “Public IP Address” >> Click on “Create New” >> Provide a name for your Public IP. >> Click on “OK”
The settings will be validated. Creating a gateway can take upto 45 minutes. You may have to refresh the portal to see the complete status.
After the gateway has been created, you can view the IP assigned to it by looking at the virtual network in the portal. The gateway will appear as a connected device.

PART 4 – Generate Certificates

Certificates are used by Azure to authenticate VPN clients for Point-To-Site VPNs. You export the public certificate data (not the private key) as a Base-64 encoded X.509.cer file from either a root certificate generated by an enterprise certificate solution, or a self signed root certificate. You then import the public certificate data from the root certificate to Azure. Additionally, you need to generate a client certificate from the root certificate for clients. Each client that wants to connect to the virtual network using a P2S connection must have a client certificate installed that was generated from the root certificate.

Create a self-signed certificate

Install the Windows Software Development Kit

Windows 10 → https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

Windows 7 → https://www.microsoft.com/en-in/download/details.aspx?id=8279 (.NET 4)

https://www.microsoft.com/en-in/download/details.aspx?id=3138 → (.NET 3.5 SP1)
After installation, you can find the makecert.exe utility under the path: C:\Program Files (x86)\Windows Kits\10\bin\x64
Create and install a certificate in the Personal certificate store on your computer. The following example creates a corresponding .cer file that you upload to Azure when configuring P2S. Run the following command, as administrator. Replace ARMP2SRootCert and ARMP2SRootCert.cer with the name that you want to use for the certificate.

makecert -sky exchange -r -n "CN=ARMP2SRootCert" -pe -a sha1 -len 2048 -ss My "ARMP2SRootCert.cer"

The certificate will be located in your certificates – Current User\Personal\Certificates.

I am using Windows 7, so the “makecert.exe” is stored in → C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin

Command:

cd ‘C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin’

PS C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin> .\makecert.exe -sky exchange -r -n “CN=P2SRootCert” -pe -a sha1 -len 2048 -ss My “P2SRootCert.cer”

Open “Run” and enter certmgr.msc, this will open the Certificate Manager Tool, If you can browse into the “Personal” >> “Certificates”, you can see your self-signed certificate.

Obtain the Public Key

As part of the VPN Gateway configuration for Point-To-Site connections, the public key for the root certificate is uploaded to Azure.

To obtain the .cer file from the certificate, open certmgr.msc. Right click the self-signed root certificate, click “all tasks”, and then click export. This opens the Certificate Export Wizard.
In the Wizard, click Next, select No, do not export the private key, and then click Next.
On the Export File Format page, select Base-64 encoded X.509 (.CER). Then, click Next.
On the File to Export, Browse to the location to which you want to export the certificate. For File name, name the certificate file. Then click Next.
Click Finish to export the certificate.

You can see that the certificate file is now exported to the destination folder.

Create and install client certificates

Part A – Generate a client certificate from a self-signed certificate

The following steps walk you through one way to generate a client certificate from a self-signed certificate. You may generate multiple client certificates from the same certificate. Each client certificate can then be exported and installed on the client computer.

1. On the same computer that you used to create the self signed certificate, open Powershell / Command prompt as administrator.

2. In this example, “ARMP2SRootCert” refers to the self-signed certificate that you generated.

Change “ARMP2SRootCert” to the name of the self-signed root that you are generating the client certificate from.
Change ClientCertificateName to the name you want to generate a client certificate to be.

Modify and run the sample to generate a client certificate. If you run the following example without modifying it, the result is a client certificate named ClientCertificateName in your Personal certificate store that was generated from root certificate ARMP2SRootCert.

Sample:
makecert.exe -n “CN=ClientCertificateName” -pe -sky exchange -m 96 -ss My -in “ARMP2SRootCert” -is my -a sha1
Our Command:
makecert.exe -n “CN=myClientCertificate” -pe -sky exchange -m 96 -ss My -in “P2SRootCert” -is my -a sha1

3. All certificates are stored in your ‘Certificates – Current User\Personal\Certificates’ store on your computer. You can generate as many client certificates as needed based on this procedure.

Part B – Export a Client Certificate

To export a client certificate, open certmgr.msc. Right-click the client certificate that you want to export, click all tasks, and then click export. This opens the Certificate Export Wizard.
In the Wizard, click Next, then select Yes, export the private key, and then click Next.
On the Export File Format page, you can leave the defaults selected. Then click Next.
On the Security page, you must protect the private key. If you select to use a password, make sure to record or remember the password that you set for this certificate. Then click Next.
On the File to Export, Browse to the location to which you want to export the certificate. For File name, name the certificate file. Then click Next.
Click Finish to export the certificate.

Part C – Install a client certificate

Each client that you want to connect to your virtual network by using a Point-to-Site connection must have a client certificate installed. This certificate is in addition to the required VPN configuration package. The following steps walk you through installing the client certificate manually.

Locate and copy the .pfx file to the client computer. On the client computer, double-click the .pfx file to install. Leave the Store Location as Current User, then click Next.
On the File to import page, don’t make any changes. Click Next.
On the Private key protection page, input the password for the certificate if you used one, or verify that the security principal that is installing the certificate is correct, then click Next.
On the Certificate Store page, leave the default location, and then click Next.
Click Finish. On the Security Warning for the certificate installation, click Yes. The certificate is now successfully imported.

PART 5 – Add The Client Address Pool

1. Once the virtual network gateway has been created, navigate to the Settings section of the virtual network gateway blade. In the Settings section, click Point-to-site configuration to open the Configuration blade.

2. Address pool is the pool of IP addresses from which clients that connect will receive an IP address. Add the address pool, and then click Save.
Here I am using 125.16.167.155/32 as my Address Pool, which is the public IP address of my laptop / network

PART 6 – Upload the Root certificate .cer file

After the gateway has been created, you can upload the .cer file for a trusted root certificate to Azure. You can upload files for up to 20 root certificates. You do not upload the private key for the root certificate to Azure. Once the .cer file is uploaded, Azure uses it to authenticate clients that connect to the virtual network.

Navigate to the Point-to-site configuration blade. You will add the .cer files in the Root certificate section of this blade.
Make sure that you exported the root certificate as a Base-64 encoded X.509 (.cer) file. You need to export it in this format so that you can open the certificate with text editor.
(Best way to do this is to create a copy of the root certificate to a temp location and change the file type to .txt, so you can easily open the file with notepad)
Open the certificate with a text editor, such as Notepad. Copy only the following section:
Paste the certificate data into the Public Certificate Data section of the portal. Put the name of the certificate in the Name space, and then click Save. You can add up to 20 trusted root certificates.

PART 7 – Download and install the VPN client configuration package

Clients connecting to Azure using P2S must have both a client certificate, and a VPN client configuration package installed. VPN client configuration packages are available for Windows clients.
The VPN client package contains information to configure the VPN client software that is built into Windows. The configuration is specific to the VPN that you want to connect to. The package does not install additional software.

On the Point-to-site configuration blade, click Download VPN client to open the Download VPN client blade.
Select the correct package for your client, then click Download. For 64-bit clients, select AMD64. For 32-bit clients, select x86.
Install the package on the client computer. If you get a SmartScreen popup, click More info, then Run anyway in order to install the package.
Click on Close, if any antivirus pops-up. Then click on Yes, to continue the installation of VPN Client.
On the client computer, navigate to Network Settings and click VPN. You will see the connection listed. It will show the name of the virtual network that it will connect to and looks similar to this example:

PART 8 – Connect To Azure

To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may appear that refers to using the certificate. If this happens, click Continue to use elevated privileges.
On the Connection status page, click Connect to start the connection. If you see a Select Certificate screen, verify that the client certificate showing is the one that you want to use to connect. If it is not, use the drop-down arrow to select the correct certificate, and then click OK.
Your connection should now be established.

PART 9 – Verify your connection

To verify that your VPN connection is active, open an elevated command prompt, and run ipconfig/all.
View the results. Notice that the IP address you received is one of the addresses within the Point-to-Site VPN Client Address Pool that you specified in your configuration. The results should be something similar to this:

Azure – RDP from Linux box to Azure Virtual Machine (Windows Server)

This topic is pretty straight forward. Once you have your Azure Windows Server spun up, you can connect to it using RDP tool if your source is a Windows operating System.

But when you are in Linux the story is different, as it does not have the RDP tool. We have plenty of open source tools that we can use to make a connection from Linux Box to Windows Server.

Since we are discussing about Azure, I am using an Azure VM. Below is the details of that machine:

VM Details

We are going to use the “RDesktop” tool to connect from Linux to Windows. Installation of RDesktop is pretty simple. You may google/bing for assistance, or check this link for the complete installation guide in RedHat/CentOS/Fedora Operating System.

Once you have your RDesktop setup. Enable the RDP port- 3389 in your Azure virtual Machine. You can achieve this by adding “Inbound Security Rules” into your Network Security Group, via the Azure Portal.

For demo purposes, I am allowing all incoming traffic for the port – 3389. However, incase of production environment, you may have to provide appropriate rules for your NSG (Network Security Group) and ACLs (Access Control List) for better security.

NSG_Allow_All

Once RDesktop and RDP ports are configured. You may now run the RDesktop command to connect to your Virtual Machine.

Command: sudo rdesktop <IP Address>

rdesktop_fail

As you can see in the above screenshot, the connection fails. This is an expected behavior, because by default the RDP connection is set to “Allow connections only from computers running Remote Desktop with Network Level Authentication”

NLA_Enabled