You are browsing the archive for IaaS.

Azure IaaS: Build a VM from a Bring your Own License (BYOL) image with Azure PowerShell

9:16 am in ARM, Azure, Azure Hybrid Use Benefit, BYOL, Cloud, IaaS, PowerShell by Wim Matthyssen

For all people who do not yet know, with the Azure Hybrid Use Benefit you can use your on-premises Windows Server licenses that includes Software Assurance for Windows Server (Standard and Datacenter Editions) virtual machines (VM) in Azure. More recently also Azure Hybrid Use Benefits for Windows Client which includes Windows 10 (only Enterprise customers with Windows 10 Enterprise E3/E5 per user or Windows VDA per user – User Subscription Licenses or Add-on User Subscription Licenses – are eligible) came in Preview.

By using your existing licenses, you only pay for the base compute rate (equal to the Linux rate for VMs) without the Windows licenses cost, which can save you up to 40 %.

You can download the Azure Hybrid Use Benefit datasheet here

clip_image002

These days it’s even simpler to deploy a new Azure server VM whit your own on premise license via the Windows Server BYOL images available in the Azure Marketplace. There are images available for the following Server Oss (*be aware that not all Azure Subscriptions can use the BYOL images):

  • Windows Server 2008 R2 SP1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016 (not available in all regions)

You can search for the Windows Server images by running following PowerShell command:

clip_image004

In the above screenshot, you can see that some Skus now contain the BYOL suffix.

You can search for the Windows Client images by running following PowerShell command:

clip_image006

To build a VM with from a BYOL image you can run following Azure PowerShell script (adjust all variables for your own use):

clip_image008

The script is also available on Microsoft TechNet

When the script is completed and the VM is build, you can log into the VM via remote desktop. Like you can see the VM is not registered and you’ll able to use your own Windows product key.

clip_image010

Hope this comes in handy!

Wim Matthyssen (@wmatthyssen)

Azure IaaS: VM status Running (Installing Extensions)

6:13 am in ASM, Azure, Azure PowerShell, Cloud, IaaS, Installing Extension, Microsoft, Public Cloud by Wim Matthyssen

Last week while migrating Azure IaaS VMs from ASM to ARM, I noticed that one VM was showing the status “Running (Installing Extension)” in the Azure Classic portal. When I tried to connect to that specific VM with RDP no connection could be made. This status also prevented me from doing some automation activities, the VM however still responded to a ping.

clip_image002

When I opened the DASHBOARD page of the VM and looked at the extensions, I saw that the Microsoft.Compute.VMAccessAgent showed following error:

clip_image003

The simplest way I found to resolve this error was to delete the extension, and add it back. To do so login to the Azure portal with your Azure account. Go to Virtual Machines and click on the specific VM. On the opened blade select Extensions, right click the VMAccessAgent and click Delete. When asked to delete the extension select Yes

clip_image005

clip_image006

clip_image007

clip_image008

To reinstall the VMAccess extension open PowerShell ISE, connect to your Azure subscription with your Azure account and run the following command (replace cloud service name and VM name by your own)

clip_image010

To check the current status of the extension, run following command (replace cloud service name and VM name by your own):

clip_image012

Or you can also check trough both Azure portals

clip_image014

clip_image016

After the reinstallation of the VMAccessAgent, it ran with STATUS Success and I was able to reconnect to the VM with RDP. This concludes this blog post, hope it helps whenever you have this issue.

Wim Matthyssen (@wmatthyssen)

2016: My blog year in an overview

2:37 pm in Azure, Azure Backup, Azure RemoteApp, Client Hyper-V, Cloud, DC, Hyper-V, IaaS, PowerShell, Private Cloud, Public Cloud, Replica DC, SCAC 2012 R2, SCVMM 2012 R2, System Center 2016, W2K12R2, Windows 10 by Wim Matthyssen

Hi all,

As a blogger completely focused on Microsoft technologies, it was a fun year of writing about all those interesting and ever changing products and services. As we almost end the year 2016 and are preparing for 2017 to start, I wanted to make a list of all the blog posts I wrote throughout the twelve months of 2016. During the year, I’ve published 26 blog posts mostly about Azure, the System Center Suite and Hyper-V. Below you can find them all divided by technology.

 

clip_image002

Azure Compute – IaaS (ASM)

Step-by-step: Move an Azure IaaS VM between different Azure Subscriptions

Clean up Azure PowerShell when using different Azure subscriptions

Replica DCs on Azure – Removing the Azure Endpoints

Replica DCs on Azure – Transferring FSMO roles to the IaaS DCs

Replica DCs on Azure – Manage the Time Configuration settings on the DCs

Replica DCs on Azure – Domain Controller Health Check

Replica DCs on Azure – Promote the Azure IaaS VMs to a domain controller

Replica DCs on Azure – Add the Active Directory Domain Services role

Replica DCs on Azure – Adjustment of some server settings before promoting the DCs

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

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

Step by step: Change the drive letter of the Temporary Storage on an Azure IaaS v1 VM

 

Azure Networking

How to connect an Azure ARM VNet to an ASM VNet using VNet Peering

Replica DCs on Azure – Switch DNS servers for the VNet

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

 

Azure Backup

Microsoft Azure Backup Server: Install a new version of the Microsoft Azure Recovery Services Agent

Microsoft Azure Backup Server: System State backup fails with WSB Event ID: 546

Microsoft Azure Backup Server: System State backup fails with the message replica is inconsistent

Step by step: How to install Microsoft Azure Backup Server (MABS)

 

Azure RemoteApp

An RDP connection to the Azure RemoteApp custom VM fails with the following error: “No Remote Desktop License Servers available”

 

Windows 10

How to deploy Windows 10 from a USB flash drive

 

System Center

System Center 2016 evaluation VHDs download links

Step by step: How to connect SCAC 2012 R2 to SCVMM 2012 R2 and Microsoft Azure

Step by step: Installing SCAC 2012 R2

 

Hyper-V

A list of tools that can be used to do a V2V from VMware to Hyper-V

Client Hyper-V – Using nested virtualization to run Client Hyper-V on a Windows 10 VM

 

Before I wrap up this blog post, I want to thank you all for reading my blog posts in 2016, and I really hope you will keep doing so in 2017. I wish you all a healthy, successful and outstanding New Year! See you all in 2017!

Wim Matthyssen (@wmatthyssen)

Step-by-step: Move an Azure IaaS VM between different Azure Subscriptions

11:22 am in Azure, Azure subscription, Cloud, IaaS, Microsoft Azure Storage Explorer, Public Cloud by Wim Matthyssen

From time to time, customers ask me to migrate Azure IaaS virtual machines (VMs) between Azure Subscriptions (for example moving a VM between the Dev subscription and the Prod subscription). There are several ways to accomplish this move, you can use Azure PowerShell or Azure Site Recovery (ASR), but mostly I do it the way that I will describe below.

1) First of all, you need to download an Azure Storage Explorer which enables you to move the VHD (page blob) which is used by the IaaS VM from one storage account (Azure Subscription 1) to another (Azure Subscription 2). Mostly I use the Microsoft Azure Storage Explorer which you can download for free via following link: http://storageexplorer.com/

clip_image002

2) When downloaded and installed you’ll need to add the two Azure Blob Storage Accounts, the one you want to move the VHD from and the one you want to move the VHD to. Open up the Microsoft Azure Storage Explorer, right click Storage Accounts and select Connect to Azure storage…

clip_image004

3) To find the Storage Account name and the Account key, just logon to the Classic Azure portal (https://manage.windowsazure.com/). Go to STORAGE select the correct Storage Account and click MANAGE ACCESS KEYS.

clip_image006

clip_image007

4) Fill in the correct Account name (STORAGE ACCOUNT NAME) and the Account key (PRIMARY ACCESS KEY)

clip_image009

clip_image011

5) Repeat steps 3 to 5 also for the Storage Account in the other Azure Subscription. At the end two Storage Accounts should be available to use in the Microsoft Azure Storage Explorer

clip_image013

6) Now stop the VM (logon trough RDP and choose shutdown) and you are good to copy/paste your VM’s VHD from one Storage Account to another

clip_image015

7) Open up Microsoft Azure Storage Explorer, right click the VHD for the VM you just stopped and select Copy

clip_image017

8) Open the other Storage Account’s Blob container (in my example azureos01 – Blob Containers – vhds) and select Paste. Be aware that this copy can take some time depending on the size of the VHD

clip_image019

clip_image021

clip_image023

9) When the VHD is completely copied, open the Azure classic portal and logon to the second Azure Subscription. Go to VIRTUAL MACHINES, then DISKS and select CREATE A DISK

clip_image025

10) Fill in a NAME (for example AZ-VM-SUB2) and select the correct VHD URL from the storage you just moved your VHD file to. Mark “The VHD contains an operating system.” and select Windows. Click the check mark to finish

clip_image026

clip_image028

clip_image030

clip_image032

11) As the next step create a new VM. Click NEW – COMPUTE – VIRTUAL MACHINE – FROM GALLERY

clip_image034

12) Select MY DISKS and select the newly created disk (in my example AZ-VM-SUB2)

clip_image036

13) In the next screen choose a proper VIRTUAL MACHINE NAME, the TIER and the VM SIZE

clip_image038

14) Create a new CLOUD SERVICE or select an existing one, choose the correct VNET and SUBNET. If an AVAILIBILITY SET is required, select or create it

clip_image040

15) Select the ENDPOINTS you require and finally press the check mark icon to start provisioning the VM

clip_image042

16) Like you can see the VM is created and starts Running. You should now able to connect to it again with RDP

clip_image044

image

17) If the VM looks and reacts like it should, you can delete the original VM with the attached VHD in the first Azure Subscription. Also don’t forget to delete the Cloud Service

This concludes this blog post, hope it helps!

Wim Matthyssen (@wmatthyssen)

Replica DCs on Azure – Removing the Azure Endpoints

10:04 am in Azure, Azure Endpoints, Cloud, DC, hybrid cloud, IaaS, PowerShell, RDP, Replica DC, W2K12R2 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/

All VMs that you create in Azure can automatically communicate using a private network channel with other VMs in the same cloud service or VNet. However, other resources on the Internet or resources from other VNets require endpoints to handle the inbound network traffic to those VMs. That’s why when you create a new Azure  IaaS v1 VM (Azure Service Manager deployment model), Azure automatically creates two endpoints: Remote Desktop and Windows PowerShell Remoting. Both endpoints consist of a protocol (TCP or UDP) and have a public (for example 54036) and a private (for example 3389) port. The public port is used by the Azure load balancer to listen for incoming traffic to the IaaS VM from the Internet. The private port on the other hand is used by the IaaS VM itself to listen for incoming traffic to an application or service running on the VM.

After the creation of this new VM it’s possible to create additional endpoints if needed. The VM deployment wizard provides pre-defined endpoint configurations not only for Remote Desktop and PowerShell, but also for SSH, FTP, SMTP, DNS, HTTP, POP3, IMAP, LDAP, HTTPS, SMTPS, IMAPS, POP3S, MSSQL and MySQL. If the needed service isn’t in this list,  you can also  also create your own service endpoint and define the protocols and ports needed.

You can manage and isolate the incoming traffic to the public ports of these endpoints by configuring access control list (ACL) rules. By using ACLs, you can for example, only permit access to a specific service from a set of trusted hosts or networks.

However, for security best practices, it’s always advisable when an IaaS VM is configured and a Site-to-site VPN (S2S) exists, to remove all endpoints you don’t need (like RDP) and only to use them when their really needed (for example to access a IIS hosted website from the Internet on port 443). When the S2S is in place, you can connect to the VM through the use of the standard local RDP port (3389) via the secure IPsec VPN tunnel instead of connecting over the public Internet.

In this blog post I will show you how you can delete the RDP and PowerShell endpoint manually by making use of the Azure Classic Portal (AZGR-DC-01) and how to do it with the use of Azure PowerShell (AZGR-DC-02). So, let’s get started.

Manually remove the Azure Endpoints through the Azure Classic Portal

1) Logon to the Azure Classic Portal as a Service administrator or Co-administrator

2) In the navigation pane, click VIRTUAL MACHINES and then click the name of the VM where the endpoint needs to be deleted (AZGR-DC-01)

clip_image002

3) Select ENDPOINTS

clip_image004

4) Select the Remote Desktop endpoint and click DELETE

clip_image006

5) Select YES when asked Are You sure that you want to delete endpoint Remote Desktop? This will start the deletion process

clip_image008

clip_image010

clip_image012

6) When the Remote Desktop endpoint is successfully deleted, you can test or you’re still able to RDP to the VM over the Internet. First of all, like you can see the CONNECT button is disabled

clip_image014

7) If we try to connect through the previously downloaded RDP file, no connection is possible

clip_image016

clip_image017

clip_image018

clip_image019

8) However, when we logon to GR-DC-01 and open mstsc via Run, we are still able to RDP to AZGR-DC-01 like it should, because we connect over the internal network

clip_image021

clip_image022

clip_image024

9) You can also repeat the above steps, to delete the Remote PowerShell endpoint

 

Remove the Azure Endpoints through the use of Azure PowerShell

1) Open Windows PowerShell ISE, logon with your Azure account and select the correct Azure Subscription

2) Run following Azure PowerShell cmdlet:

clip_image026

3) Run following cmdlet to check the existing endpoints for the VM

clip_image028

4) Like you can see only the Remote PowerShell endpoint still exists, which we also can verify in the Azure Classic Portal

clip_image030

5) To delete the PowerShell endpoint run following cmdlet:

clip_image032

6) After running this cmdlet no endpoint longer exist for the AZGR-DC-02 VM

clip_image034

clip_image036

That ends the final part of this series. If had a lot of fun while writing these series and I really hope, it’s useful for some people. If someone has any questions about the series or a specific part of it, you can always contact me through my Twitter handle.

Till next time!

Wim Matthyssen (@wmatthyssen)

Replica DCs on Azure – Switch DNS servers for the VNet

7:18 am in Azure, Cloud, DC, DNS, hybrid cloud, IaaS, Replica DC, W2K12R2 by Wim Matthyssen

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

After we successfully installed both IaaS virtual machines (VMs) as DCs there are still some Azure related actions we can perform. One of them is changing the DNS servers used in the VNet (AZU-VNET-01) to primary use the DNS installed on both IaaS DCs. By doing this we will minimize the data (DNS related actions) out of the Azure data center, which will reduce Azure network costs. We can do this changes through use of the Azure Classic Portal or via the network configuration file (NetworkConfig.xml). I will show both steps below, so let’s get started.

By making use of the Azure Classic Portal

1) Logon to the Azure Classic Portal as a Service administrator or Co-administrator

2) In the navigation pane, click Networks and then click the name of your VNet (AZU-VNET-1)

image

3) Click Configure

image

4) In the dns servers section, delete the on premise DC (GR-DC-01) by clicking the X next to the IP ADDRESS

image

image

5) To add and register both Azure IaaS DNS servers (AZGR-DC-01 and AZGR-DC-02) with the VNet and Azure, just type their name and IP Address in the boxes. I will also add the on premise DNS server (GR-DC-01) as third failback DNS server. When added click Save

image

6) When asked click YES, this will start updating the VNet

image

image

7) When finished successfully, click OK

image

image

8) When the DNS list is updated, we must restart all IaaS VMs (AZGR-DC-01 and AZGR-DC-02) connected to the VNet, so they can pick up the new DNS settings

Before the reboot:

image

After the reboot:

image

9) To check if DNS is working like it should after the changes, ping the on premise DC (GR-DC-01). If all is OK, you should get replies like shown it the below screenshot

image

By making use of the network configuration file

1) Logon to the Azure Classic Portal as a Service administrator or Co-administrator

2) In the navigation pane, click Networks, click the name of your VNet (AZU-VNET-1) to select it and at the bottom of the screen click EXPORT

image

3) Select your SUBSCRIPTION and click het check mark button

image

4) The NetworkConfig.xml file will be downloaded. When finished click View downloads

image

5) Click Open folder

image

 

6) Right click the NetworkConfig.xml file and select Edit

image

 

7) You can see in the original file there is just one DNS servers used (GR-DC-01 – 192.168.2.4)

image

8) Change the DNS servers like in the screenshot below and save the file

image

9) Go back to the Azure portal, click NEW at the bottom, click NETWORK SERVICES, click VIRTUAL NETWORK and then click IMPORT CONFIGURATION

image

10) Browse the changed NetworkConfig.xml file and click the arrow

image

 

11) Verify the changes and press the check mark button at the bottom if all is fine

image

12) The import will start

image

13) When the import is successfully finish press the OK button

image

14) Like you can see, the DNS servers (AZGR-DC-01 and AZGR-DC-02) are added

image

15) Reboot all IaaS VMs connected to the VNet to adjust their DNS settings

That ends this part of the series. I hope it’s useful, till next time!

Wim Matthyssen (@wmatthyssen)

Replica DCs on Azure – Transferring FSMO roles to the IaaS DCs

7:27 am in Azure, Cloud, DC, FSMO, hybrid cloud, IaaS, PowerShell, Replica DC, W2K12R2 by Wim Matthyssen

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

After we successfully installed both IaaS virtual machines (VMs) as DCs and verified everything was running smoothly (time synchronization included) there is still one AD related action we can perform, namely transferring the Flexible Single Master Operation (FSMO) roles between the on premise DC and the ones running on Azure.

Like you probably all know, some of these FSMO roles (5 in total) are rarely used, such as the Schema and Domain naming Master roles, while others are highly used, such as the PDC emulator and Relative ID (RID) Master role. One thing to keep in mind is that each FSMO role only exists once in the domain and forest. When the entire domain is running on Microsoft Azure it’s completely logical that all FSMO roles are ran on a single Azure IaaS DC or split over different Azure IaaS DCs. However, in most production environments a hybrid (combination of on premise and Microsoft Azure resources) cloud scenario is used. In this case you should see Azure as any other secondary site and the placement of the FSMO roles should be treated in that way. Therefore, always assess all pros and cons before moving certain or all FSMO roles to a DC running as an Azure IaaS VM. In either case, I will show you how you can transfer all or some of the FSMO roles to one of the DCs running on Azure. In my examples all these transfers are done by use of the GUI, but you can also use the command-line tool Ntdsutil.

To transfer the FSMO role(s), a user must be a member of the following group(s):

image

Transfer the Schema Master role (GUI)

1) Logon to one of the Azure IaaS DCs (AZGR-DC-01), open the Schmmgmt.dll library by opening Run and typing:

image

2) Press OK if the installation is succeeded

image

3) Also from the Run command open an MMC Console by typing mmc

image

4) On the Console menu, press Add/Remove Snap-in, select Active Directory Schema, click Add> and press OK

image

5) Right-click the Active Directory Schema icon and press Operation Master…

image

6) Click Change

image

7) Click Yes

image

8) Click OK

image

image

Transfer the Domain Naming Master role (GUI)

1) Logon to one of the Azure IaaS DCs (AZGR-DC-02), open Administrative Tools and click on Active Directory Domains and Trusts

image

2) Right-click the Active Directory Domains and Trusts icon and press Operation Masters…

image

3) Press the Change button

image

4) Press Yes to confirm the change

image

5) Press OK

image

image

Transfer the RID Master, PDC Emulator and Infrastructure Master role (GUI)

  • The RID master role and the PDC emulator role should be owned by the same DC as a best practice

1) Logon to one of the DCs running on Azure (AZGR-DC-01 or AZGR-DC-02) trough RDP, open Run and type dsa.msc and press OK

image

2) When the Active Directory Users and Computers window is opened right click the domain and click Operations Masters…

image

3) In the Operations Masters window, each tab will show you who the current Operations master is for a specific FSMO (RID, PDC and Infrastructure). For example, the RID Operations master is shown in the screenshot below

image

4) To transfer the role just press Change…

image

5) Select Yes

image

6) Press OK

image

7) Like you can see the role is transferred to AZGR-DC-02

image

8) If you want to transfer another role for example to AZGR-DC-01, select Active Directory Users and Computers and select Change Domain Controller…

image

9) Select AZGR-DC-01 out of the list and press OK. This will switch the DC

image

image

10) Now repeat steps 2 till 6 to switch the Infrastructure role to AZGR-DC-01

image

Check the location of all FSMO roles (PowerShell)

1) Logon to one of the DCs running on Azure (AZGR-DC-01 or AZGR-DC-02) trough RDP and open PowerShell as an Administrator

2) Run following command (save as .ps1 or run directly)

image

That ends the this 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 – Manage the Time Configuration settings on the DCs

1:46 pm in Azure, Cloud, DC, hybrid cloud, IaaS, PowerShell, Replica DC, Time Service, W2K12R2 by Wim Matthyssen

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

Because time management is one of the most critical things to take care of in an AD domain, I will discuss this topic in this part of the series. Like you probably all know, all DCs should be in time synchronization with the DC holding the PDC Emulator role. This DC is responsible for the time in the AD environment. Therefore it’s a best practice to manually set this server to synchronize his time with an external time source on the Internet (time.windows.com, be.pool.ntp.org, us.pool.ntp.org, …). In their place all other DCs sync their time with the this PDC Emulator.

Other than the DCs, all member servers and workstations will sync time with their authenticated DC. Be aware that when the local time of a server or workstation is out of sync (more than 5 minutes – default setting) Kerberos authentication will fail and users won’t be able to login. Besides all that, time stamps are also used in AD replication process. Below I will list some commands you can run in PowerShell, which will manage the time configuration settings on the DCs. Some oh these commands can also be used on a member server or even on a workstation. I hope you have some time to go through it.

 

 

* Picture source: https://technet.microsoft.com/en-us/library/cc773013.aspx

Check and set the Time Zone on a DC (PowerShell):

1) Logon to one of the DCs, open PowerShell and check the Time Zone via following cmdlet:

clip_image003

2) To set the time zone, run following command:

clip_image005

Set the DC which holds the PDC Emulator role to synchronize time with an external time server (PowerShell):

1) To find the server who holds the PDC Emulator FSMO role run following PowerShell command:

clip_image007

2) Logon to the DC holding the PDC Emulator role (GR-DC-01), open PowerShell As an Administrator and run the below command to check the current time against an external time server (time.windows.com):

clip_image009

3) The following command needs to be run on the PDC Emulator (GR-DC-01). Logon to an Azure DC, open PowerShell as an Administrator and run the below command to set the current time in synchronization with an external time server (time.windows.com):

clip_image011

4) The following command needs to be run on the Azure IaaS DCs (or all other DCs not holding the PDC Emulator role). Logon to an Azure DC (AZGR-DC-01), open PowerShell as an Administrator and run the below command to set the current time in synchronization with the PDC Emulator (GR-DC-01):

clip_image013

5) To check if all if the time settings are applied correctly, open up PowerShell (as admin) again and run following command. If you run this on the PDC Emulator and on another DC, you should see different settings under [TimeProviders] if all is configured well:

clip_image015

clip_image017

This concludes this part of the series, but if you’re interested in reading more about the Windows Time Service you can do so via following Microsoft TechNet article: Windows Time Service Technical Reference

Till next time!

Wim Matthyssen (@wmatthyssen)

Replica DCs on Azure – Domain Controller Health Check

9:56 am in Azure, Cloud, Command-line, hybrid cloud, IaaS, PowerShell, Replica DC, W2K12R2 by Wim Matthyssen

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

After we successfully installed and promoted both IaaS virtual machines (VMs) as DCs it’s time to do an overall health check of your hybrid active directory (AD) environment. Below I will show you some tools you can use to perform these checks. Probably it’s not a complete list but it gets you started.

Check Windows Update for the latest updates (GUI)

It’s always advisable when you install new roles on a server to check for new Windows updates after the completion of the installation. To check and install new updates, follow the steps below:

1) To open the Windows Update page, logon to one of the DCs, open Run and type:

image

2) Click Check for updates and if updates are available, install all preferred updates

Check the Event Viewer (GUI)

Another important tool to advise when you completed the promotion is to check the system, security, application, and other logs in the Event Viewer. To check these Event Viewer logs, follow the steps below:

1) To open Event Viewer, logon to one of the DCs, open Run and type:

image

2) Check the logs for possible warnings or errors

image

Run Dcdiag (command-line)

With the Domain Controller Diagnosis (DCDIAG) utility we can analyze the state of all DCs and domain services in the forest and we can create a report to troubleshoot possible problems. To run Dcdiag, follow the steps below:

1) Logon to one of the DCs as a user with Domain Admin privileges, open PowerShell as an Administrator and run following commands:

image

2) Open the file C:\Dcdiagresult.txt to view the result and to find possible issues

image

Run Repadmin (command-line)

With Repadmin you can diagnose (and in some cases repair) your AD replication status and health. To run Repadmin, follow the steps below:

1) Logon to one of the DCs as a user with Domain Admin privileges, open PowerShell as an Administrator and run following commands:

image

2) Open the file C:\Repadminresult.txt to view the result and to find possible replication issues

image

Run the Best Practice Analyzer (BPA) tools (GUI)

With the BPA tools we can conduct a scan against the DCs to ensure they are configured based on Microsoft and industry best practices. With BPA we can find incorrect configuration settings and security violations, but also investigate poor performance. To run BPA, follow the steps below:

1) Logon to one of the DCs and open Server Manager from the taskbar

2) Select a server role on the left and scroll down to the BPA section. Click TASKS and select Start BPA Scan

image

3) Select all servers you want to scan and click Start Scan

image

4) When the scan is completed, you can review all the results and fix possible issues if preferred

image

I hope this short DC health checklist helps you in the future and if you have any questions just let me know. Till next time!

Wim Matthyssen (@wmatthyssen)

Replica DCs on Azure – Promote the Azure IaaS VMs to a domain controller

12:59 pm in Azure, Cloud, DC, hybrid cloud, 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/

We will start were we left of in the previous blog post http://scug.be/wim/2016/06/06/replica-dcs-on-azure-add-the-active-directory-domain-services-role/ . We have just installed the Active Directory Domain Services (AD DS), so now it’s time to promote both servers to a domain controller (DC). We will use both the GUI (AZGR-DC-01) and PowerShell (AZGR-DC-02). So let’s kickoff.

Promote this server to a domain controller (GUI)

1) Logon to the server (AZGR-DC-01) as a domain administrator and open Server Manager. If you start were I left off in the previous blog post, you should see a question mark near the flag. Click on it and click on Promote this server to a domain controller

image

image

2) Select Add a domain controller to an existing domain. Normally the correct Domain is filled in automatically, if this is not the case select the proper domain or enter the domain name in the field provided. Select a user (Enterprise Administrator) who has to rights to add a domain controller to the domain and apply the proper credentials

image

3) Select both Domain Name System (DNS) server and Global Catalog (GC). Select the Site (AZU-VNET-1) to which the DC belongs. Fill in the Directory Services Restore Mode (DSRM) password and click Next. As a quick comment I just want to remind you that for best practice reasons this password should be documented, as it can help you to gain access to the AD environment in the event that all domain administrator accounts lose access

image

4) Since we are not using a parent zone, you will receive below warning message A delegation for this DNS server cannot be created because the authoritative zone cannot be found… We may ignore the warning message, as this will not affect whether the DNS feature gets installed. Click Next

image

5) In the Replicate from field select the on premise DC (GR-DC-01) to replicate from and click Next

image

6) Select as location for the AD DS database, log files and SYSVOL data the added Azure data disk with drive letter E: and click Next

image

7) The following window summaries all selected options. If all is right click Next

image

8) If the prerequisites check passes successfully, click Install

image

9) Installation will start and once it’s completed, by clicking on the Close button, the server will reboot. If the server is restarted the DC setup is completed

image

image

image

 

Promote this server to a domain controller (PowerShell)

1) Logon to the server (AZGR-DC-02) as a domain administrator and open PowerShell as Administrator

2) Run following PowerShell automation script (store with .ps1 extension or copy and run directly) to promote this server to a DC:

image

3) When asked enter a username and password (this user should have Enterprise Administrator rights)

image

4) Fill in the Directory Services Restore Mode (DSRM) password and confirm it a second time

image

5) Installation will go on and when succeeded the server will reboot. After the restart the DC installation is completed

image

image

This ends the seventh part of the series. Still a few steps to go, so please continue through the rest of the series to complete the setup. Till next time!

Wim Matthyssen (@wmatthyssen)