You are browsing the archive for 2015 September.

Replica DCs on Microsoft Azure – Create the Cloud Service and Storage Accounts

7:49 pm in Azure, Cloud, DC, IaaS, PowerShell by Wim Matthyssen

This blog post is part of the step by step to deploy replica DCs on Azure which can be found here:

In this part I will setup the Cloud Service that acts as a container to store my replica DC VMs. This Cloud Service which is part of my Azure virtual network (VNET), provides a unique public DNS name, a public IP address (VIP), and a set of endpoints to access the DC VMs over the Internet (those endpoints will be deleted at the end of the blog series for security reasons).

So, first of all let us create the Cloud Service in the virtual network via Custom Create:

1) In the Azure Management Portal, click New -> Compute -> Cloud Service -> Custom Create


2) In the field URL, enter a unique name to use in the public URL for accessing your cloud service. In my example I use “contoso-azure-dc”. Secondly, in the field Region or Affinity Group, select the geographic region or affinity group to deploy the cloud service to. In my example I use “West Europe”


3) Click Create Cloud Service and as you can see the Cloud Service is successfully created


You can also use Azure PowerShell (run as Administrator) to create the Cloud Service:


Before we create the necessary Storage Accounts, first some remarks:

  • The Active Directory database and logs will be placed on a separate data disk (with NO caching)
  • Data disks should always be the maximum allowable size (1 TB), keep in mind that you only pay for what you use (16 TB total per VM)
  • In my example I use Locally Redundant Storage (stores 3 replicas of your data within the primary location)
  • In the Standard Tier maximum IOPs is 500 IOPs per disk, if higher IOPs are needed you can use Storage Spaces
  • Keep in mind that the D: drive named “Tempory Storage” is a tempory drive (local storage), never place critical unreplicated data on it (modify persistent drive letters to avoid D:)
  • I always use separate Storage Accounts to store OS disks and data disks. This reduces the number of custom images to be copied to the Storage Accounts and you have a better overview of all your different disks
  • Azure support suggests to don’t have more than 40 disks (total of 20,000 IOPs) per Storage Account
  • You can have 100 Storage Accounts and 4,000 Active Disks per Subscription as recommended limits

So now it is time to create the necessary Storage Accounts:

1) In the Azure Management Portal, click New -> Data Services -> Storage -> Quick Create

In URL, enter a name for your storage account. In my example I use “azuos1”. In Location/Affinity Group, select a location for your storage account. In my example I use “West Europe”. As Replication Mode I select “Locally Redundant”. At the end click Create Storage Account


2) Repeat the same steps to create the second Storage Account. In my example I use “azudata1”“West Europe”“Locally Redundant”



You can also use Azure PowerShell (run as Administrator) to create the Storage Accounts:


That ends the first part of this series. Please continue through the rest of the series to complete the setup (if all are available).

Till next time!

Wim Matthyssen (@wmatthyssen)

Deploying replica DCs in Microsoft Azure

7:22 pm in Azure, Cloud, DC, IaaS by Wim Matthyssen

Hi all, my next blogs posts are a step by step series on how to deploy additional domain controllers (replica DCs) on IaaS virtual machines (VMs) in Microsoft Azure to extend the on premise Active Directory domain to Azure. The different parts provide details about the process of creating the necessary Cloud Service, creating the necessary Storage Accounts, deploying the servers, configuring Active Directory Domain Services (AD DS) and all other necessary steps for a secure and stable expansion of your AD to Azure.

So bookmark this post to get regular updates when new topics are available!

Below, you can find the setup Visio diagram:


Before we get started there are a number of import remarks you should know about before deploying this solution. Please read them all carefully.

  • A Site-to-Site (S2S) VPN needs to be set up (ExpressRoute is also an option if a faster and more secure connection is needed) to connect the Azure Virtual Network (VNet) with the on-premises network (Cross-Premisse Connectivity)
  • You need to provide your own DNS infrastructure to support AD DS on an the Azure VNet because the Windows Azure-provided DNS infrastructure does not support some features that AD DS requires, such as dynamic SRV resource record registration.
  • It is a good idea to create a site in Active Directory that represents the network region corresponding to the VNet. That helps optimize authentication, replication, and other DC location operations.
  • In this series I will use IaaS V1 VMs to set all things up.
  • You should shut down and restart a VM that runs the DC role in Azure within the guest operating system instead of using the Shut Down option in the Azure Management Portal. Today, using the Management Portal to shut down a VM causes the VM to be deallocated. A deallocated VM has the advantage of not incurring charges, but it also resets the VM-GenerationID, which is undesirable for a DC. When the VM-GenerationID is reset, the invocationID of the AD DS database is also reset, the RID pool is discarded, and SYSVOL is marked as non-authoritative.
  • By default, the AD DS installation process installs the AD DS database and SYSVOL in the %systemroot% folder, which is NOT recommended for Azure. So ensure that the DCs have an additional data disk (With NO caching) added to the DCs VMs. Store the NTDS and SYSVOL content on this data disk. This is to prevent data corruption in case of recovery, as data disks with NO caching ensures that the all the committed transactions are written to the database/disk. Because failure to disable write caching may, under certain circumstances, introduce USN rollback resulting in lingering objects and other problems.
  • For security reasons it is advisable to install an antivirus on every VM running on Azure. For an additional cost antivirus extensions can be added to all VMs trough the Azure Management Portal.
  • Windows Azure does not push Windows Updates to Windows Azure VMs since these machines are intended to be managed by the user. This is just like any on-premises machine.
  • Hackers utilize brute force tools that try frequently used usernames and passwords.  So the first step is to make sure and utilize complex usernames and passwords for your VMs. That’s why using a local admin with the name Administrator is not a good idea.
  • Its preferable to have the Global Catalog (GC) and DNS roles on the replica DCs. This reduces the traffic going to the GCs on-premises for evaluating the universal group membership. And you know, inbound data to Azure is free, but outbound data is charged based on the total amount of data moving out of the Windows Azure datacenters via the Internet in a given billing cycle (first 5 GB of outband data per billing month are free).
  • Endpoints allow you to communicate with your Azure VM from the Internet.  When creating a Windows VM in Azure, two endpoints get created by default to help you manage the VM – Remote Desktop and PowerShell.  The first recommendation is to eliminate any endpoints you do not need and to only add them when and while you need them.  If you must have an endpoint open, the recommendation is to change the public port that is used whenever possible. Creating a S2S VPN connection between your on-premises network and your VNet in Azure gives you a secure, dedicated, IPsec tunnel for communicating.  With a S2S VPN connection in place, you can completely remove certain public endpoints and then just connect via the internal ports like you would with any other machine on your internal network.  For example, you could remove the Remote Desktop endpoint in your VM and then just connect directly to the VM over the standard RDP port 3389 via the secure VPN tunnel.

Herewith you will find my blog series topics to get all things up and running:

1) Create the Cloud Service and Storage Accounts

2) Create the VMs with Azure PowerShell

3) Create the Active Directory site for the Azure VNet

4) Initialize and format the additional data disk

5) Adjustment of some server settings before promoting the DCs

6) Add the Active Directory Domain Services role

7) Promote the Azure IaaS VMs to a Domain Controller

8) Domain Controller Health Check

9) Manage the Time Configuration settings on the DCs

10) Transferring FSMO roles to the IaaS DCs

11) Switch DNS servers for the VNet

12) Removing the Azure Endpoints

Hope it helps!

Wim Matthyssen (@wmatthyssen)

How to use mRemoteNG to connect to multiple Client Hyper-V VMs with RDP in a tabbed view

7:56 pm in Client Hyper-V, RDP, Windows 10 by Wim Matthyssen

From Windows 10, Client Hyper-V supports nested virtualization (basically it means that it allows you to run Hyper-V in a Hyper-V virtual machine), something many people were awaiting for a longtime. It also brings other nice new features to the built-in hypervisor like:

  • Windows PowerShell Direct
  • Hot add and remove network adapters and memory
  • Linux secure boot
  • Integration Services delivered through Windows Update
  • A new virtual machine configuration file format .VMCX

I’ve you’re interested in reading more, you can do so via following link:

Because of all those nice improvements I decided to create my new demo and testing environment with it on my notebook. When Client Hyper-V (optional feature) was installed and the VMs for the complete infrastructure were built, I had the ability to connect to those VMs via two mechanisms: the VM console (VMConnect) and Remote Desktop (RDP).

The VM Console provides a single monitor view of the VM with resolution up to 1600 x 1200 in 32-bit color. This console also provides you with the ability to view the VM’s booting process. You can use it by opening the Hyper-V Manager, right clicking a VM, and select Connect…


If you want a richer experience, you can connect to a VM using an RDP connection. Then the VM will take advantage of the capabilities available on your notebook (multi monitor use, full media capability, shared clipboard, USB redirection and much more). You can use it by opening Run and typing mstsc (like everyone probably knows).


Because you’re mostly working with more than one server in a lab environment, it’s not so easy and practical to use the VM Console. Simply because there is no tool available to manage multiple VM Console connections in a tabbed view, which allows you to switch easily between all those running VMs.

When you use RDP instead to connect to those VMs several of such tools (free or paid) are available:

Before we start, first some practical information and tips:

  • I will be using mRemoteNG to use multiple RDP connections in a tabbed view
  • The IP range used is
  • Two VMs will be used in this example: GR-DC-01 and GR-DC-02
  • In all steps PowerShell is used with administrator rights
  • When you use a generation 2 VM, set the Firmware setting to Boot from Hard Drive
  • To use an RDP connection from your notebook to a VM running in Client Hyper-V an internal virtual switch needs to be connected to the VM

1) First of all an internal virtual switch needs to be created on the host. So open PowerShell and run the following command:

New-VMSwitch -Name InternalRDP -SwitchType Internal -Notes 'RDP connection'


2) You can check if the virtual switch is created correctly by opening up your Hyper-V Manager and click on Virtual Switch Manager


3) Still on the host, assign the static IP address to the network adapter that was created for the virtual switch “InternalRDP”. Open up PowerShell and run following commands:

#Retrieve the wright network adapter

$netadapter = Get-NetAdapter -Name “vEthernet (InternalRDP)”

#Disable DHCP

$netadapter | Set-NetIPInterface -DHCP Disabled

#Configure the IP address

$netadapter | New-NetIPAddress -AddressFamily IPv4 -IPAddress -PrefixLength 24 -Type Unicast



4) Connect both VMs to virtual Network Adapter to the InternalRDP virtual switch by use of PowerShell

#Add Networks

Get-VMNetworkAdapter GR-DC-01| Connect-VMNetworkAdapter –SwitchName InternalRDP

Get-VMNetworkAdapter GR-DC-02| Connect-VMNetworkAdapter –SwitchName InternalRDP



5) Logon to both VMs with the VM Console and rename the network adapters with PowerShell

Get-NetAdapter -Name Ethernet | Rename-NetAdapter -NewName Internal –PassThru



6) On VM GR-DC-01 assign the fixed IP address with subnet mask for the “Internal” network adapter


7) On VM GR-DC-02 assign the fixed IP address with subnet mask for the “Internal” network adapter

8) Enable RDP on both VMs


9) If the Windows Firewall is enabled, don’t forget to adjust the necessary Inbound Rules to allow RDP


10) Open mRemoteNG, right click Connections and select “New Connection”. Create two new connections named “GR-DC-01” and “GR-DC-02”. When created fill in all necessary info like shown in the screenshot below (I log in with the local administrator, that’s why I filled in .\ for the domain).


11) Click both connections and you will see that you can use both VMs in a tabbed view by using RDP



That’s all, hope it helps!

Wim Matthyssen (@wmatthyssen)

Certificate error while setting up a P2S VPN connection to Azure

11:24 am in Azure, Cloud, VPN by Wim Matthyssen

While studying for Microsoft Exam 70-533 (Implementing Microsoft Azure Infrastructure Solutions) I encountered a problem while setting up a point-to-site (P2S) VPN connection with Azure. The problem was with the self-singed certificate.


In this blog post I will show you how to fix this and setup a working P2S VPN connection from your workstation to Azure.

Herewith the necessary requirements and tips:

  • To setup the virtual network and the gateway I’ve used the Azure Management Portal
  • In this example the virtual network is named azurevnet with an address space of There are 3 subnets namely VM1 (, VM2 ( and the Gateway (
  • GR-DC-01 is deployed from the Windows Server 2012 Datacenter OS image and connected to the VM1 virtual network subnet.
  • To create the self-signed authentication root and client certificate I used makecert.exe which is available if you installed any version of Visual Studio. You can find it under the following directory: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin. I copied it to my C:\Tools (this folder is added to the PATH environment variable to make it available from any location) folder for easy access. If you don’t have Visual Studio you can always install Visual Studio Express, which you can download over here:
  • Microsoft recommends to create a separate client certificate for each client that is going to connect via P2S. When you do this and keep track of them, it’s easier to invalidate a single client certificate when you need to revoke someone’s access.

1) To create the Root Certificate open a command prompt as administrator and run:

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


In my example this command will create the root certificate directly under the C: root


2) As a next step upload this self-signed root certificate to the virtual network certificates section on Azure




3) To create the Client Certificate open a command prompt as administrator and run:

makecert.exe -n "CN=AzureClientCert" -pe -sky exchange -m 96 -ss My -in "AzureRootCert" -is my -a sha1

This creates and installs the client certificate to your local computer


4) Now open run an type mmc and add the “Certificates” Snap in for “My user account”



5) Go into “Personal”“Certificates” and see if both the client and the root certificate are present


6) If so were ready to install the client VPN package. To do this go back to Azure and navigate to the dashboard of the virtual network. Under “Quick Glance” at the right side, as you can see a 32-bit and 64-bit Client VPN Package are available.


7) Download the appropriate package for your workstation and install it. It might be blocked because the file comes from a location outside your computer but it’s save to run it.

8) Now were ready to connect to Azure. Click the network icon in the system tray, and as you can see you are able to select the azurevnet virtual network. Click it, and in the opened screen click azurevnet connection and choose “Connect” (this is for Windows 10 users).



9) A new dialog box should pop up where you need to press “Connect” again


10) If all went well you are now connected to you Azure environment



11) As you can see, I’m now able to RDP into my VM1 VM via the dynamic IP address (DIP)



Hope it helps!

Wim Matthyssen (@wmatthyssen)