You are browsing the archive for DC.

Replica DCs on Azure – Initialize and format the additional data disk

11:34 am in Azure, Cloud, DC, IaaS, PowerShell by Wim Matthyssen

 

This blog post is part of the step-by-step to deploy replica DCs on Microsoft Azure which can be found here: http://scug.be/wim/2015/09/28/deploying-replica-dcs-in-windows-azure/

Before we can promote the servers to DCs, we need to initialize and format the additional data disk that we added with the VM creation script to store the Active Directory Database and logs. I will explain how you can do this trough the GUI and via PowerShell.

Initialize and format the additional data disk trough the GUI

1) Logon to your Azure IaaS VM trough RDP, open Run and type diskmgmt.msc, press OK

clip_image001

2) The Disk Management console will open and a screen will pop-up to initialize the additional data disk. Select disk 2 and GPT as the partition style, press OK

clip_image002

3) Right-click Disk 2 and select New Simple Volume…

clip_image004

4) Click Next

clip_image005

5) Click Next on the Specify Volume Size page

clip_image006

6) Choose E as the drive letter and press Next

clip_image007

7) Fill in a name for the Volume label (in my case I use AD) and click Next

clip_image008

8) Click Finish

clip_image009

clip_image011

Initialize and format the additional data disk trough PowerShell

1) Logon to the Azure IaaS VM trough RDP and open PowerShell as an administrator.

2) Run following PowerShell cmdlet:

clip_image013

3) To confirm type Y and press Enter

 

clip_image015

clip_image017

clip_image019

That ends the fourth 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)

Replica DCs on Azure – Create the Active Directory site for the Azure VNet

2:35 pm in Azure, Cloud, DC, hybrid cloud by Wim Matthyssen

This blog post is part of the step-by-step to deploy replica DCs on Microsoft Azure which can be found here: http://scug.be/wim/2015/09/28/deploying-replica-dcs-in-windows-azure/

In this part I will create the site in Active Directory Sites and Services that represents the network region corresponding to the VNet created in Azure. This will help optimize authentication and replication of directory data between DCs in all sites.

1) Logon to an on-premise DC as a domain administrator, then click Start, click Administrative Tools and then double-click Active Directory Sites and Services. This will open the Active Directory Site and Services Management console (MMC)

clip_image001

clip_image003

clip_image005

2) Right-click Sites and click New Site

clip_image007

3) In the Name field type AZU-VNET-1 (this is the name of the VNet created in a previous post), select DEFAULTIPSITELINK and click OK

clip_image008

4) Click OK to confirm the site was created

clip_image009

clip_image011

5) Right-click Subnets, and then click New Subnet

clip_image013

6) In the Prefix field type 10.1.0.0/16 (this is the VNet adress space created in a previous post), select the AZU-VNET-01 site object and click OK

image

clip_image016

That ends the third 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)

Replica DCs on Microsoft Azure – Create the VMs with Azure PowerShell

4:43 pm in Azure, Cloud, DC, IaaS, PowerShell, Public Cloud by Wim Matthyssen

This blog post is part of the step by step to deploy replica DCs on Azure which can be found here: http://scug.be/wim/2015/09/28/deploying-replica-dcs-in-windows-azure/

In this part I will setup the replica DC VMs with the use of an Azure PowerShell script. To do so follow the steps below:

1) Download the Built_DCs.xlsx file here. When downloaded rename the extension from .xlsx to .csv and adjust the file to your needs. In my example I saved it in the following folder C:\Temp\Azure_setup_DC

 

clip_image003

2) To check if the Cloud Service name used in the .csv already exists on Azure, run the below PowerShell cmdlet. If the name exists, the cmdlet returns $True. If the name does not exist and can be used, it returns $False

 
3) Deploy both Azure IaaS VMs with the following Azure PowerShell script, in my example named Azure_built_DCs.ps1. This file is also stored under the folder C:\Temp\Azure_setup_DC. This script accesses the previously created Built_DCs.csv file were all necessary variables are declared. Both VMs will be built from the Azure Windows Server 2012 R2 Datacenter image, will be placed in an Availability Set and an extra data disk will be attached (stored in the azudata01 Storage Account) with a size of 1023 GB and the host-cache mode set to None

 

clip_image005

4) When the script has run you can verify if all settings are applied correctly from the Azure classic portal

clip_image007

clip_image009

clip_image011

clip_image013

5) You should also be able to RDP into both VMs

clip_image015

image

That ends the second 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)

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: http://scug.be/wim/2015/09/28/deploying-replica-dcs-in-windows-azure/

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

clip_image002

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”

clip_image004

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

clip_image006

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

clip_image008

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

clip_image010

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

clip_image012

clip_image014

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

clip_image016

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:

clip_image002

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)