For most of the usage, Azure Update Management helps to improve your patch management. However, clusters are not handled for the moment (a shame for my S2D clusters). Some features are missing such as run an update process “now” and the information are not assessed immediately after an update. Despite all these lacks, I use only Azure Update Management to handle Windows Update in my lab and I try to convince my customers to use this product instead of WSUS. In this topic I’ll show you how to deploy and use Azure Update Management.

Azure resources creation

The following Azure resources are required to deploy Azure Update Management:

• Log Analytics workspace
• Azure Automation Account

So I create these resources from the Azure Marketplace.

Then, once you created the Azure Automation Account and the Log Analytics workspace, open the Azure Automation Account blade and navigate to Update Management. Select the Log Analytics workspace and click on Enable.

Connect on-prem machines to Azure Update Management

Open Log Analytics Workspace blade. In overview pane, locate Connect a data source. Then click on Windows, Linux and others sources.

Then download the Windows Agent. Copy the workspace ID and the primary key: you need these information to complete the agent installation.

Once you downloaded the agent binaries, run the installation. Check the box saying Connect the agent to Azure log analytics (OMS).

Next specify the workspace ID and key. Select Azure Commercial.

N.B: You can also install the agent by using a command line:

setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE=0 OPINSIGHTS_WORKSPACE_ID= OPINSIGHTS_WORKSPACE_KEY= AcceptEndUserLicenseAgreement=1

It can take a while before information are pulled up in Azure. Once the agent is detected in Azure Update Management, you should get a message saying that a machine does not have “Update Management” enabled. Click on the link beside.

Choose the option you want and click on OK.

Once you have enabled update management of machines, you should get information about update states on your On-Prem computers.

Create an update deployment

Now that machines are well reported in the Update Management portal, we can create an update deployment to install the updates. Click on Schedule update deployment. First provide a name for this update deployment. Then, select machine to update and click on Machines. Select machine you want to upgrade.

Then configure the schedule. For this rule I choose to run it once a time. As you can see also in the below screenshot, you can specify a pre and post script.

Finally, specify the maintenance window and the reboot options as specified in the following screenshot.

Once the schedule update is created, you can retrieve it in scheduled update deployments tab.

Create a recurring update deployment

You can also create a recurring update deployment to install automatically updates each month. Create a new update deployment and this time in schedule settings choose recurring.

Several scheduled update deployments can be created as you can see in the following screenshot.

When a deployment update is running, you can see the progression in Update Deployments tab.

Finally, when update process is finished, you have to wait almost 30mn to get the new assessment from on-prem machines. After updates are installed you should get all your machines compliant.

The post Getting started with Azure Update Management to handle Windows updates appeared first on Tech-Coffee.

All VMs must be able to communicate through NE01-VMProject1 which is the hub. A peering will be established between NE01-NET – NE02-NET and NE01-NET – NE03-NET. To prepare this topic, I’ve already created the following resources:

• Resource groups
• Virtual machines
• Virtual networks

As you can see below, the VM NE01VM1 is connected to NE01-NET virtual network with the IP 10.11.0.4.

The VM NE02VM1 is connected to NE02-NET virtual network with the IP 10.12.0.4.

Because no peering is created, a VM cannot ping another:

Create the peering

First, I edit Peerings from NE02-NET.

I call it NE02-NET-NE01-NET and I select the virtual network NE01-NET. For the moment, I leave default configuration.

From NE01-NET virtual network, I do the same thing to peer it to NE02-NET. I leave also the default configuration for the moment.

When peers are created, you should get the peering status to Connected.

Now, VM from NE01-VMProject1 and NE02-VMProject2 are able to communicate:

So, I create the peers between NE03-VMProject3 and NE01-VMProject1. I repeat the same steps as previously. I create a peer from NE01-NET to connect to NE03-NET.

Then I create a peer from NE03-NET to connect to NE01-NET.

From this point, VMs from NE03-VMProject3 are able to communicate with NE01-VMProject1 VMs and VMs from NE02-VMProject2 can ping VM from NE01-VMProject1. However, VM from NE03-VMProject3 can’t communicate with NE02-VMProject2 because gateway and routes are missing:

Create virtual gateway and route tables

First, create a virtual gateway in your hub network (NE01-NET) with the following settings. The gateway takes the 4^th IP address in gateway subnet. You need this information for later. So, in this example, the internal IP address of this virtual network gateway is 10.11.1.4.

Then in NE02-VMProject2 and NE03-VMProject3, create a route table resource with the following settings:

Now, navigate in route table resource and click on Routes. Click on Add.

Configure the route as the following:

Now, click on Subnet and Associate.

Associate the NE02-NET-ROUTE to NE02-NET virtual network and NE03-NET-ROUTE to NE03-NET.

Configure hub peers

Now we need to allow gateway transit in each hub peer. Open each peering configuration in NE01-NET and Allow gateway transit as below.

Configure spoke peers

In each spoke peer (NE02-NET and NE03-NET), enable Use remote gateways option.

Wait a few minutes and then all VMs should be able to communicate.

The post Create a Hub-and-Spoke topology with Azure Virtual Network Peering appeared first on Tech-Coffee.

Requirement

To follow this topic, you need:

• An On-Prem file server (physical or virtual) running on Windows Server 2012R2, 2016 or 2019.
• An Azure account

Azure side configuration

First, create a Storage Account. I don’t need performance, so I choose a standard performance account with cool access tier. Regarding the Replication, you must choose regarding the SLA you require.

Once the storage account is created, open its properties and create a file share. I called mine branch1.

Open the Azure marketplace and look for Azure File Sync.

Create the resource in the same location as the storage account. Usually I add Azure File Sync in the same resource group than the storage account.

Once Azure File Sync is created, you can browse registered servers and click on Azure File Sync agent link.

Download the agent for your Windows Server version. I downloaded the version for Windows Server 2019 because my On-Prem server is running on Windows Server 2019. Download the file and copy it to the On-Prem server.

Implement agent in On-Prem Server

Connect to the On-Prem server and run the following cmdlet to install AzureRM PowerShell cmdlet.

Then run the Azure File Sync agent setup.

Once the agent is installed, the following window is raised. Specify your tenant ID and click on sign-in. Another pop-up is raised to ask you credentials.

Next choose the Azure Subscription, the resource group and the Storage Sync Service.

Once you are registered, your server should be present in Azure File Sync (registered server tab). My Windows Server is running on Windows Server 2019 but operating system in Azure File Sync is Windows Server 2016 :).

To finish, I create a folder in P:\ called AFS. This folder will be synchronized with Azure File Sync. I copy files in this folder.

Manage Azure File Sync

Now that Azure File Sync is installed, agent is ready and file are presents somewhere in the On-Prem server, we can sync data between On-Prem and Azure. To create the synchronization job, navigate to Sync Groups in Azure File Sync.

Provide a name for this Sync Group and select the storage account and the Azure File Share that you created at the beginning.

Now that the cloud endpoints is created, we can add servers to the sync group. So, click on Add server endpoint.

Select the On-Prem server, the path to synchronize (P:\AFS) and enable the cloud tiering if you wish.

Once the synchronization has run, you should retrieve files in the storage account.

Conclusion

In large company with branch office, DFS-R is often implemented to replicate branch office data to main datacenter (in a single way). Now Microsoft provides a new solution to replace DFS-R with Azure File Sync. Thanks to Cloud Tiering, your On-Prem file servers don’t require plenty of storage. Data can be accessed from everywhere because they are stored in Azure. It’s a nice hybrid cloud scenario.

The post Getting started with Azure File Sync appeared first on Tech-Coffee.

Requiements

To be able to follow this topic, you need the following:

• An Azure subscription
• A running Windows Admin Center (1809 at least).

Register Windows Admin Center in Microsoft Azure

From a web browser (Edge or Chrome), open Windows Admin Center and click on the wheel at the top right corner. Then click on Azure and Register.

Then copy the code and click on Device Login and past the code you just copied. A Microsoft login pop-up should be raised: enter your Azure Credentials.

If you have several tenant, choose the right one. You can find the tenant ID from the Azure Portal by clicking on Switch Directory. If you have already register a Windows Admin Center before, you can reuse the Azure AD App by selecting the option.

Now you are asked to grant permissions to the Azure AD App. Open an Azure Portal from the browser of your choice.

Then navigate to App Registrations and select your Windows Admin Center App. Edit its settings and click on Required permissions. Finally click on Grant Permissions.

If the Windows Admin Center works well, you should have the following information.

Now you can enjoy Azure Hybrid features such as Azure Backup from Windows Admin Center.

If you wish, you can also use Azure Active Directory to authenticate users and administrators on Windows Admin Center.

Conclusion

With Windows Server 2019 and Windows Admin Center has promised to simplify hybrid scenario. Thanks to Windows Admin Center we are able to configure On-Prem hosts in Azure Site Recovery and Azure Backup. The “hybrid” extensions of Windows Admin Center are still in preview. Just by upgrading extensions, we’ll have more features. This is why Windows Admin Center is a good product (and it’s free !)

The post Register Windows Admin Center in Microsoft Azure appeared first on Tech-Coffee.

• Deploy a Windows Server 2016 RDS Farm in Microsoft Azure
• Create Microsoft Azure networks, storage and Windows image
• Deploy the Microsoft Azure Virtual Machines
• Configure Domain Controllers
• Deploy the RDS farm
• Configure File Servers for User Profile Disk (UPD)
  
• RDS final configuration

I’ll deploy this file service by using only PowerShell. Before following this topic, be sure that your Azure VM has joined the Active Directory and they have two network adapters in two different subnets (one for cluster and the other for management). I have also fixed the IP addresses from Azure portal.

Deploy the cluster

First of all, I install these features in both file server nodes:

install-WindowsFeature FS-FileServer, Failover-Clustering -IncludeManagementTools

Then I install the RSAT of Failover Clustering in the management VM.

Install-WindowsFeature RSAT-Clustering

Next I test if the cluster nodes can manage Storage Spaces Direct

Test-Cluster -Node "AZFLS0","AZFLS1" -Include "Storage Spaces Direct", Inventory,Network,"System Configuration"

If the test is passed successfully, you can run the following cmdlet to deploy the cluster with the name UPD-Sto and the IP 10.11.0.29.

New-Cluster -Node "AZFLS0","AZFLS1" -Name UPD-Sto -StaticAddress 10.11.0.29 -NoStorage

Once the cluster is created, add the Cluster Name Object (UPD-Sto) the right to create computer object on the OU where it is located. This permission is required to create the CNO for SOFS.

Enable and configure S2D and SOFS

Now that the cluster is created, you can enable S2D (I run the following PowerShell on a file server node by using Remote PowerShell).

Enable-ClusterS2D

Then I create a new volume formatted with ReFS and with a capacity of 100GB. This volume has the 2-Way Mirroring resilience.

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName UPD01 -FileSystem CSVFS_REFS -Size 100GB

Now I rename the folder Volume1 in ClusterStorage by UPD-01

rename-item C:\ClusterStorage\Volume1 UPD-01

Then I a add the role Scale-Out File Server role in the cluster and I call it SOFS.

Add-ClusterScaleOutFileServerRole -Name SOFS

To finish I create a folder called Profiles in the volume and I share it for everyone (not recommended in production) and I call the share UPD$

New-Item -Path C:\ClusterStorage\UPD-01\Profiles -ItemType Directory
New-SmbShare -Name 'UPD$' -Path C:\ClusterStorage\UPD-01\Profiles -FullAccess everyone

Now my storage is ready and I am able to reach \\SOFS.homecloud.net\UPD$

Next topic

In the next topic, I will deploy a session collection and configure it. Then I will add the certificate for each Remote Desktop components.

The post RDS 2016 Farm: Configure File Servers for User Profile Disks appeared first on Tech-Coffee.

• Deploy a Windows Server 2016 RDS Farm in Microsoft Azure
• Create Microsoft Azure networks, storage and Windows image
• Deploy the Microsoft Azure Virtual Machines
• Configure Domain Controllers
• Deploy the RDS farm
  
• Configure File Servers for User Profile Disk (UPD)
• RDS final configuration

Deploy the Azure SQL database

In the previous topics, we have not deployed the Azure SQL database. In this part, I will deploy this component. In Microsoft Azure, open marketplace and look for SQL Database. Create a blank database and create a new SQL Server. I have called the SQL server sql-rds and the database DBA-Broker.

Deploy RDS 2016 Farm

Once all your VM has joined the Active Directory, you can create a new Remote Desktop deployment based on session. The first broker server is AZRDB0, the first RD host server is AZRAH0 and the first RD access server is AZRDA0. From AZRDB0, I run the following cmdlet:

New-RDSessionDeployment -ConnectionBroker AZRDB0.homecloud.net `
                        -SessionHost AZRAH0.homecloud.net `
                        -WebAccessServer AZRDA0.homecloud.net

Next, in the Server Manager of AZRDB0, add all servers of the RDS farm.

Then, I add additional server to the RDS Farm. First, I add two license servers. Each server will have some licenses, so even if a server is down, a license server is available.

Add-RDServer -ConnectionBroker AZRDB0.homecloud.net -Server AZRDB0.homecloud.net -Role RDS-LICENSING
Add-RDServer -ConnectionBroker AZRDB0.homecloud.net -Server AZRDB1.homecloud.net -Role RDS-LICENSING

Then I add an additional RD host server:

Add-RDServer -ConnectionBroker AZRDB0.homecloud.net -Server AZRAH1.homecloud.net -Role RDS-RD-SERVER

And I add an additional RD Web Access server:

Add-RDServer -ConnectionBroker AZRDB0.homecloud.net -Server AZRDA1.homecloud.net -Role RDS-WEB-ACCESS

In Server Manager, if you browse the Remote Desktop Deployment, you should have the following diagram.

Configure the RD Broker in High Availability

Before configuring the RD Broker in High Availability mode, go back to the Azure Portal and open the SQL database settings. Click on the link connection strings.

Then create two DNS records where each DNS record is associated to one RD broker.

N.B: you can use an Azure Load Balancer instead of DNS round-robin for the RD Broker. For more information, you can read this topic.

Then install the SQL Native Client on each RD Broker server. Next run the following cmdlet. Replace in the Connection String the SQL server and database name.

Set-RDConnectionBrokerHighAvailability -ConnectionBroker 'azrdb0.homecloud.net' `
                                       -DatabaseConnectionString 'Driver={SQL Server Native Client 11.0};Server=tcp:sql-rds.database.windows.net,1433;Database=DBA-Broker;Uid=master@sql-rds;Pwd={DATABASE PASSWORD};Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;' `
                                       -ClientAccessName 'broker.homecloud.net'

To finish, run the following cmdlet to add an additional RD Broker server:

Add-RDServer -ConnectionBroker AZRDB0.homecloud.net -Server AZRDB1.homecloud.net -Role RDS-CONNECTION-BROKER

If you come back to the deployment overview In Server Manager, the RD Connection Broker should be marked as a High Availability Mode.

Configure RD Gateway

To add RD Gateways, click on the + symbol in the deployment overview. Then select both RD Gateway servers and add them to selected box.

Provide an SSL certificate name which should be the FQDN of the RD Gateway servers.

Then click on add to start the RD Gateway deployment.

Now the deployment overview should look like that :

In each RD Gateway server, open the RD Gateway console and edit the server properties. Then navigate to Transport Settings and disable UDP.

In Server Farm tab, add both servers and click on Apply.

Repeat these steps for each RD Gateway server.

Deploy the Load Balancer

A Load Balancer is required for the RD Web Access and the RD Gateways. You can use also an Azure Load Balancer for the RD Broker. But in this example I deploy an Azure Load Balancer for RD Web Access and Gateway. Open the marketplace and specify load balancer in the search box.

Provide a name to the Load Balancer and select public. Select the Public IP address previously created from the JSON template.

Once the Azure Load Balancer is created, open the Backend Pools settings. Then click on Add.

Specify a name for the backend pool and select associated to Availability Set. Select the RD Access availability set and add both virtual machines.

Next add a Health probe based on TCP 443 (HTTP / 443 is currently not supported).

Add also a load balancing rule based on TCP. Specify the public TCP port and the backend port. Then select the health probe.

Now you can try the public IP (https://<IP>/rdweb). You should get the Remote Web Access authentication page.

What is missing?

For the moment, no certificate has been deployed. So, you should have some security alerts in the web browser and the RD Gateway still not working. We will configure these certificates in another topic.

Next topic

In the next topic, I’ll deploy a SOFS cluster based on Storage Spaces Direct to store User Profile Disk.

The post RDS 2016 Farm: Deploy RDS 2016 farm in Azure appeared first on Tech-Coffee.

• Deploy a Windows Server 2016 RDS Farm in Microsoft Azure
• Create Microsoft Azure networks, storage and Windows image
• Deploy the Microsoft Azure Virtual Machines
• Configure Domain Controllers
  
• Deploy the RDS farm
• Configure File Servers for User Profile Disk (UPD)
• RDS final configuration

Prepare the On-Prem Active Directory

In the following screenshot, you can find the current sites and services configuration. I have two sites with a replication link.

Now I’m going to create a new site, subnets, and a new replication link with PowerShell:

$OnPremSite = "Lyon-HyperV"
$AzureSite  = "Azure"
$AzureDesc  = "Azure AD Site"

Try {
    New-ADReplicationSite -Name $AzureSite `
                          -Description $AzureDesc `
                          -ErrorAction Stop

    New-ADReplicationSubnet -Name 10.11.0.0/24 `
                            -Site $AzureSite `
                            -ErrorAction Stop

    New-ADReplicationSubnet -Name 10.11.1.0/24 `
                            -Site $AzureSite `
                            -ErrorAction Stop

    New-ADReplicationSiteLink -Name $($OnPremSite + "-" + $AzureSite) `
                              -ReplicationFrequencyInMinutes 15 `
                              -InterSiteTransportProtocol IP `
                              -SitesIncluded $OnPremSite, $AzureSite `
                              -Cost 200
                              -ErrorAction Stop
}
Catch {
    Write-Output $Error[0].Exeption.Message
}

The following screenshot presents the sites and services configuration after that I have run the script.

Below you can find the subnets configuration.

Azure VM configuration

First of all, I set to static the IP address of my domain controllers:

• AZADS0: 10.11.0.20
• AZADS1: 10.11.0.21

Then I change the DNS configuration. AZADS0 is bound to On-Prem domain controllers.

AZADS1 is bound to AZADS0 and an On-Prem domain controller.

Thanks to this configuration, both domain controllers are able to resolve the On-Prem domain DNS name (called homecloud.net).

Operating system configuration

Now I’m connecting to each domain controller (across the private IP because VPN is established) and I create a new volume on the data disk. I run the following PowerShell cmdlet:

Initialize-Disk -Number 2
New-Volume -DiskNumber 2 -FriendlyName Data -FileSystem NTFS -DriveLetter E

Then I install the domain service and DNS role:

Install-WindowsFeature AD-Domain-Services, DNS -IncludeManagementTools

Next I add promote the server as a domain controller:

Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "E:\NTDS" `
-DomainName "homecloud.net" `
-InstallDns:$true `
-LogPath "E:\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Azure" `
-SysvolPath "E:\SYSVOL" `
-Force:$true

Once each Azure domain controllers are promoted, I open again the Active Directory Sites and Services. You can see now that both Azure Domain Controllers are located in Azure AD site.

Next topic

In the next topic, I will deploy the RDS Farm with all roles in High Availability. I’ll try to make the most PowerShell possible.

The post RDS 2016 Farm: Configure Domain Controllers appeared first on Tech-Coffee.

Architecture overview

Currently I have an On-Premise datacenter with two domain controllers which host the int.homecloud.net directory. The network subnet is 10.10.0.0/24. In the Microsoft Azure side, I will deploy a Virtual Network with a subnet 10.11.0.0/24. Two Azure VM will be deployed in this network.

Then I will implement a Site-To-Site VPN based on IPSec to connect my datacenter to Virtual Network hosted in Microsoft Azure. Then I will add Azure domain controllers to my domain.

Prerequisites

To deploy this lab, I have created a resource group called HybridAD with:

• A Storage Account called hybridadstorage (Local Redundant Storage)
• A Virtual Network called HybridADNetwork with a subnet 10.11.0.0/24.
• 2x Basic_A1 VM with an IP in 10.11.0.0/24 network (static IP) and a public IP

In On-Premise datacenter, I have two domain controllers already configured to host the int.homecloud.net domain.

Configure the Site-to-Site VPN

First of all, we have to connect the datacenter to virtual network in Microsoft Azure. First of all, I add the gateway subnet from the virtual network settings. In subnet settings, just click on + Gateway subnet.

Once the gateway subnet is added, you can open the marketplace and look for Virtual Network Gateway.

Then set the network gateway settings. Select your virtual network and create a new Public IP Address as below. Then choose the Gateway type and the VPN type. Route-based refers to dynamic routing and policy-based refers to static routing.

Once the creation of the virtual network gateway is running, open again the marketplace and this time I select local network gateway.

Specify the name, the public IP address of your datacenter and the local address spaces.

Now that both gateways are registered, we can create the connection. Open the virtual network gateway settings. Select connections and click on Add. Specify the name of this connection and then select Site-To-Site (IPSec). Specify your virtual network gateway and the local network gateway. Then give a shared key.

Now you have to configure your gateway. You can refer to this documentation about the gateway. There are validated gateway and the others. In my side I have an Ubiquiti Edgerouter ER3-Lite. This device is not in the validated gateway. I have run this configuration in my gateway:

set vpn ipsec disable-uniqreqids
set vpn ipsec esp-group esp-edgemax
set vpn ipsec esp-group esp-edgemax lifetime 3600
set vpn ipsec esp-group esp-edgemax pfs disable
set vpn ipsec esp-group esp-edgemax mode tunnel
set vpn ipsec esp-group esp-edgemax proposal 1
set vpn ipsec esp-group esp-edgemax proposal 1 encryption aes256
set vpn ipsec esp-group esp-edgemax proposal 1 hash sha1
set vpn ipsec esp-group esp-edgemax compression disable
set vpn ipsec ike-group ike-edgemax
set vpn ipsec ike-group ike-edgemax lifetime 28800
set vpn ipsec ike-group ike-edgemax proposal 1
set vpn ipsec ike-group ike-edgemax proposal 1 dh-group 2
set vpn ipsec ike-group ike-edgemax proposal 1 encryption aes256
set vpn ipsec ike-group ike-edgemax proposal 1 hash sha1
set vpn ipsec ipsec-interfaces interface pppoe0
set vpn ipsec logging log-modes all
set vpn ipsec nat-traversal enable
set vpn ipsec site-to-site peer 13.94.252.98
set vpn ipsec site-to-site peer 13.94.252.98 local-address any
set vpn ipsec site-to-site peer 13.94.252.98 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 13.94.252.98 authentication pre-shared-secret <Secret>
set vpn ipsec site-to-site peer 13.94.252.98 connection-type initiate
set vpn ipsec site-to-site peer 13.94.252.98 default-esp-group esp-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 ike-group ike-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 esp-group esp-edgemax
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 local prefix 10.10.0.0/24
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 remote prefix 10.11.0.0/24
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 allow-nat-networks disable
set vpn ipsec site-to-site peer 13.94.252.98 tunnel 1 allow-public-networks disable
commit
save

Once the connection is established, the status of the connection is connected.

On the gateway side, I have the below status:

Prepare your Active Directory

Now that connection is established, we can configure the Active Directory. First I create a new site called Azure. Then I associate the 10.11.0.0/24 subnet to this site. To finish, I create a site link called OnPrem-Azure. In this way, VMs in the subnet 10.11.0.0/24 will request domain controllers in this network (except when they are both down).

Deploy domain controllers in Azure

Temporarily, I set the DNS Servers to my both local domain controllers. To change the DNS Settings, open the virtual network settings and select DNS Servers. Once the DNS Servers are set, reboot your Azure VMs in order to they take the new configuration.

Then install and configure the Active Directory Domain Service role. For that, I use a PowerShell script:

Install-WindowsFeature AD-Domain-Services
Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-Credential (Get-Credential) `
-CriticalReplicationOnly:$false `
-DatabasePath "D:\NTDS" `
-DomainName "int.HomeCloud.net" `
-InstallDns:$true `
-LogPath "D:\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Default-First-Site-Name" `
-SysvolPath "D:\SYSVOL" `
-Force:$true

Once the servers have rebooted, you can refresh the sites and services view. In Azure site, you should have two others domain controllers.

Final modification

Now that Azure domain controller can be managed locally through the site-to-site connection, I remove the public IP. I don’t want these VMs are accessible from the Internet.

Then I changed the DNS Servers settings to the final configuration. I specify both Azure domain controllers IP addresses. In this way, Azure VMs will contact Azure domain controllers for DNS requests.

Test

To test my solution, I deploy a new virtual machine in Azure by using this script:

# Set values for existing resource group and storage account names
$rgName="HybridAD"
$locName="West Europe"
$saName="hybridadstorage"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
# Set the existing virtual network and subnet index
$vnetName="HybridADNetwork"
$subnetIndex=0
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
# Create the NIC.
$nicName="VMRDS02-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id
# Specify the name, size, and existing availability set
$vmName="VMRDS02"
$vmSize="Basic_A1"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize
# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Then I connect to this server to open a PowerShell session. I run ipconfig to check the dns servers configuration.

Now I join the Active Directory.

It’s working but now I have to check if the server requests an Azure domain controller. I open the below registry key to check the VM current AD site. In the below example, my VM is mapped to the Azure AD site.

Conlusion

An Active Directory extended between On-Premise and Microsoft Azure rely on site-to-site VPN, either IPSec or ExpressRoute. Once the connectivity between both locations is established, you have just to create an Active Directory site, subnet and link. Depending on your VPN throughput, you can increase or decrease the replication frequency. If you have a high speed and low latency link such as express route, you can replicate once changes have occurred as two domain controllers in the same site. Active Directory is often a basic service, so it is convenient to install domain controllers at the closest location of the domain machine (also in Azure).

The post Extend Active Directory to Microsoft Azure appeared first on Tech-Coffee.

In this topic,  I will address the following resources in Azure Resource Manager (ARM):

• Azure VMs
• Availability Sets
• Load-Balancers

Lab overview for Highly Available IaaS 3-tier service

N.B: In this topic, I use PowerShell cmdlets to manage Azure resources. You can have further information here.

The goal of this lab regards the deployment of a 3-tier service:

• First tier: Web Servers
• Second tier: Application Servers
• Third tier: Database Servers

The user will connect to the Web Servers load-balancer. Then the Web Servers will connect to the application servers across the application load-balancer. Then Application servers will send a request to SQL Servers. The availability Set will be configured on each server role to support the 99,95% SLA.

Regarding the network, the virtual network is split into two subnets called external and internal subnet. All VMs are stored in the same storage account.

I have created the resource groups, the storage account and the virtual network. It only remains to create availability set, Azure VMs and load-balancer.

Availability Set

Usually to support High Availability, we use two servers that host the same role or/and application. Then these servers are spread across several racks, rooms or hypervisors (in case of VMs). In this way, even if an outage occurs, the others servers continue to deliver the service. In Azure, we use the Availability Set to spread in the datacenter, the Azure VMs which deliver the same service.

With Availability Set comes two concepts:

• Fault Domain: this is a physical unit for the deployment of an application. Thanks to fault domain, VMs are deployed on different servers, racks and switches to avoid a single point of failure.
• Update Domain: this is a logical unit for the deployment of an application. Servers which are associated with the same availability set will be arranged in the rack. In this way, one update domain will be unavailable at the same time when Microsoft makes an update. So servers in the remaining update domains continue to deliver the service.

To support the 99,95% SLA, I will create an availability set for each tier. To create the Availability Set from the portal, go to the Marketplace and select Availability Set. You can then specify the availability set name, the number of fault and update domains and the resource group.

You can do the same thing with PowerShell.

New-AzureRmAvailabilitySet -ResourceGroupName LabHAIaaS -Name AppTier -Location "West Europe" -PlatformUpdateDomainCount 2 -PlatformFaultDomainCount 2

Once I have created availability sets, I have three new resources in the resource group:

Azure VMs creation

N.B: At this moment, you can’t associate availability set to a VM already created (in Azure Resource Manager) from PowerShell or from the portal.

Now I will create Azure VMs with the availability set association. You can create it by using the portal:

Below you can find PowerShell cmdlets to create an external virtual machine: (the public IP is needed to connect to VMs from the portal. If you have a Site-to-Site VPN, you shouldn’t need the public IP)

# Set values for existing resource group and storage account names
$rgName="LabHAIaaS"
$locName="West Europe"
$saName="labhaiaasvm"
$AVName = "WebTier"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."

# Set the existing virtual network and subnet index
$vnetName="LabHAIaasNetwork"
$subnetIndex=1
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

# Create the NIC.
$nicName="ExtVM06-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id

#Availabiloty Set
$AvID = (Get-AzureRmAvailabilitySet -ResourceGroupName $RGName -Name $AvName).id

# Specify the name, size, and existing availability set
$vmName="ExtVM06"
$vmSize="Standard_A0"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $AvID

# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Once all Azure VMs are created, I have 6 VMs in the resource group with their own network interfaces.

In the below example, you can see that Azure VMs that belong to the WebTier availability set are spread between two fault and update domains.

Implement the external load-balancer

Now that Azure VMs are created and are in availability sets, we can create the Load-Balancer. First, I create the external Load-Balancer for the Web servers (WebTier). Open the marketplace and type Load-Balancer. Then create it and chose the Public scheme. Create a public static IP as below and select the resource group.

Once the load-balancer is created, open settings and select Backend Pools.

Then create a backend address pool, and choose the WebTier availability Set and the Azure VMs as below.

Now you can create a probe to verify the health of your application. In the below example I create a probe for a web service which listens on HTTP/80.

Once the probe is created, we can create a load-balancing rule related to the probe health. If a server is not healthy, the load-balancer will not route traffic to this server.

Implement internal Load Balancer

As the external Load-Balancer, create again a load-balancer but this time select the Internal scheme. Then select the virtual network and the internal subnet (where are the application servers). To finish, select the resource group and set a static IP address.

Next, open the settings of this load-balancer and select Backend Pools.

Then create a backend pool and select the AppTier availability set and its Azure VMs.

Then I create a probe to verify the health of the application on port TCP/1234.

To finish, I create the load-balacing rule based on the previous probe to route the traffic to healthy servers.

The post Deploy highly available IaaS service in Azure Resource Manager appeared first on Tech-Coffee.

In this topic, I’ll talk about Azure IaaS and how to deploy a first virtual machine in ARM from scratch. I’ll show you how to deploy resources by using GUI or PowerShell. Covered features will be:

• Resource group
• Storage account
• Virtual Network
• Azure VMs

Install Azure RM PowerShell module

To install the PowerShell module and to manage resource by using ARM, you have to download and install the module. By using PowerShell v5, you can run the below commands:

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM
Install-AzureRM
# Import AzureRM modules for the given version manifest in the AzureRM module
Import-AzureRM

Logon to Azure Portal and select the subscription

To logon to the Azure Portal by using the web browser, you can browse to https://portal.azure.com. By using PowerShell, you can run the below command:

Add-AzureRMAccount

If like me, you have multiple subscriptions associated to your tenant, you have to select the right one. If you use the web browser, you can select the subscription by clicking on your name on top right.

In PowerShell, you have to use this cmdlet:

Select-AzureRMSubscription

But before running this command you need to get the subscription id by using Get-AzureRMSubscription:

Once you have the subscription ID you can use the Select-AzureRMSubscription as below:

Create the resource group

All resources that I will create will belong to the same resource group. This resource group will contain the storage account, the virtual network and the Azure VMs (and its NICs).

To create the resource group by using the GUI, click on resource groups and select add. Then give a name to your resource group and chose the location.

By using PowerShell, you have just to run the below command:

New-AzureRmResourceGroup -Name MyRG -Location "West Europe"

Now I have my resource group which is ready.

Create the storage account

To have more information about how works storage account, you can read this topic.

To create a Storage Account by using the GUI, just select new Data + Storage and select Storage account.

Then give a name (lower case, no special char) to your storage account and choose the storage account type. Then select the resource group that you have previously created.

To create the same storage account by using PowerShell, you can run the below command:

New-AzureRmStorageAccount -ResourceGroupName MyRG `
                          -Name stoaccountlab `
                          -Type Standard_LRS `
                          -Location "West Europe"

Then your storage account is created:

Create the virtual network

The virtual network is required to connect Azure VM to the network. The virtual network is an address space (as 10.0.0.0/8) that have to be split in the subnet. Then Azure VM will belong to a subnet.

To create the virtual network, just click on New, Networking, Virtual Network and create.

Then give a name to the virtual network, specify the address space, the subnet name and its address range. Select the resource group that you have previously created and select the location.

New-AzureRmVirtualNetwork -Name MyNetwork -ResourceGroupName MyRG -Location "West Europe" -AddressPrefix 192.168.0.0/16
$VirtualNetwork = Get-AzureRmVirtualNetwork -Name MyNetwork -ResourceGroupName MyRG
Add-AzureRmVirtualNetworkSubnetConfig -Name Internal -VirtualNetwork $VirtualNetwork -AddressPrefix 192.168.0.0/24
Set-AzureRmVirtualNetwork -VirtualNetwork $VirtualNetwork

You can see the subnets in the virtual network, you can click on settings and select subnets. You can add more subnets by clicking on Add.

Create the Azure VM in Resource Manager

In this example I will create a Windows Server 2012R2 Azure VM. Its virtual disk will be stored in the storage account that we have created and connected in the above subnet. To create the VM, just click on New, Compute and select the Windows Server 2012 R2 Datacenter image.

Then specify the basic settings of the VM as its name, a username and password. Specify also the resource group that we have created previously.

Next chose the size of the VM and click ok.

To finish, specify the storage account, the virtual network and the subnet. The public IP is required if you need to access to your VM from an IP address. The network security group enable you to deploy filter as a firewall.

Once you have finished to set your VM, you can jump to summary section and click on OK to launch the VM creation.

You can do the same thing by using PowerShell but it is a little bit more complex than previous PowerShell operations.

# Set values for existing resource group and storage account names
$rgName="MyRG"
$locName="West Europe"
$saName="stoaccountlab"
# Ask for VM credential
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
# Set the existing virtual network and subnet index
$vnetName="MyNetwork"
$subnetIndex=0
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName

# Create the NIC.
$nicName="VM01-NIC"
$pip=New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic=New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id

# Specify the name, size, and existing availability set
$vmName="VM01"
$vmSize="Basic_A1"
$vm=New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize

# Specify the image and local administrator account, and then add the NIC
$pubName="MicrosoftWindowsServer"
$offerName="WindowsServer"
$skuName="2012-R2-Datacenter"
$vm=Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
$vm=Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

# Specify the OS disk name and create the VM
$diskName="OSDisk"
$storageAcc=Get-AzureRmStorageAccount -ResourceGroupName $rgName -Name $saName
$osDiskUri=$storageAcc.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $diskName + ".vhd"
$vm=Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm

Once the script has run, the VM is created with a public IP and a private IP. This VM belongs to MyRG resource group.

And as you can see, all resources that I have created previously are in MyRG resource group.

Conclusion

I think the new Azure deployment model is more flexible than the old. First, Cloud Services are not required anymore for IaaS and it is a great thing. Secondly the resource group are great to manage the lifecycle of an application because you can update resources without impact on other application in others resource groups. Thirdly you can use a JSON to deploy consistently on AzureStack and Microsoft Azure. To finish, cmdlets are the same than the old deployment model except that the commands contain RM (ex: Get-AzureRMVM). So why not move to the new deployment model? J

The post Getting started with Azure IaaS in Resource Manager appeared first on Tech-Coffee.