3 Aug 2016

Name Resolution in 'the cloud' using Active Directory

When running DNS to support an Active Directory domain within Amazon's EC2 and MS Azure I've observed some subtle differences with the set-up of the forwarders for resolution of external name spaces.

To add context to the above, I'm running AD domains within the Azure and AWS domains and therefore domain joined servers are configured to use the DNS server on the Active Directory Domain Controller for DNS in order to support normal domain membership capabilities. Should the member server or client require name resolution for external namespaces then additional configuration is required in some cases, as the client only makes DNS queries to Domain Controller and therefore can't leverage the inbuilt functionality provided by the platform.

In Azure, standalone machines using the out of the box configuration, will rely on the Azure DNS option on the VNET which will resolve any external name queries by via the Azure infrastructure as defined by the option illustrated below for when viewing the VNET >> DNS Servers.

The same is true for VPCs in AWS, their default DHCP option set will be configured with 'AmazonProvidedDNS' which will provide a reserved IP address at the base of the VPC address space (the last octet incrememted by 2) and will be enabled to service name resolution for external DNS names.

When considering the scenario of configuring forwarding for name queries from a Domain Controller or other hosted DNS server and also assuming that it is undesirable for the servers to have direct access to the Internet via the VNET default routing or public IP address assignment. Therefore I have configured the forwarders on the DNS Server with the Azure/AWS supplied recursive resolvers and remove the Root Hints ensuring that there is a single defined path for name resolution. This approach ensures that any name resolution queries are answered by the Domain Controllers for the name space for which it is authoritative and any external name space queries are forwarded within the VPC/VNET and answered by the platform and sent back to the DC. This ensures that no DNS traffic directly originating or destined for an internal server is exposed to the outside world.

The recursive resolvers that can be used in as forwarders are listed below;

  • Azure DNS -

  • AWS DNS -

14 Jul 2016

Reset a Computers Secure Channel with the Domain

To reset the secure channel betweeen a computer and the domain, the following PowerShell command can be used;


It can also be performed on a remote computer using the following;

Invoke-Command -ComputerName "Server01" -ScriptBlock {Reset-ComputerMachinePassword}

Full details can be found here

23 Jun 2016

Managing Azure PowerShell behind a Proxy

I've struggled recently when attempting to manage our MS Azure environment from my corporate machine as it's behind a proxy server. I found that issuing the following line of PowerShell would allow me to authenticate the PowerShell with the proxy and connect to Azure successfully.

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

22 Jul 2015

List FSMO Roles via Command Line

To list FSMO via the command line, use the following command

netdom query fsmo 

It's much easier than using the MMC GUI

7 Jun 2015

Security Accounts Manager Failed

This morning we received errors from a remote site 2003 based Domain Controller which was sharing the hardware with a File Server, with the following message being logged in the Directory Services Log.
NTDS (460) NTDSA: Corruption was detected during soft recovery in logfile C:\WINDOWS\NTDS\edb.log. The failing checksum record is located at position END. Data not matching the log-file fill pattern first appeared in sector 14418 (0x00003852). This logfile has been damaged and is unusable.
 When restarting the server, the following message was appearing and when clicking 'OK', the DC would then reboot.


By entering Directory Services Restore Mode, several checks were preformed using NTDSUTIL from the Command Prompt.

NTDSUTIL > FILES > INFO showed that all files were present and the correct size.

NTDSUTIL > FILES > INTEGRITY showed that the Database was corrupt.

NTDSUTIL > FILES > RECOVER would not recover the database.

Finally I tried,

esentutl /p “C:\Windows\NTDS\ntds.dit” /!10240 /8 /o

Deleted all log files present in the NTDS folder, in this case C:\Windows\NTDS

Then a DB analysis which completed successfully.

NTDSUTIL > Semantic Database Analysis > Go

Upon rebooting the server, no more error messages and I was now in a point where I could gracefully Demote the server and replace it with a dedicated Domain Controller.

30 Mar 2015

Troubleshooting AD Replication & Lingering Objects

Some handy links for better understanding the troubleshooting of AD replication, Lingering objects and their removal, with a guide coming soon.

Removing Lingering Objects

Information about Lingering Objects in an AD Forest

Removing Lingering Objects

Fixing Lingering Object Problems

Strict Replication Consistency 

Contrary to popular belief, Strict Replication Consistency isn't enabled by default on DCs that reside in forests upgraded from 2000 functional levels

Troubleshooting Replication

AD Replication Status Tool
A very useful tool for troubleshooting replication, think of repladmin but in a GUI and more.


24 Mar 2015

Scheduling PowerShell Scripts

I have a requirement to run a PowerShell .ps1 file each evening to perform a backup in an AWS environment. Having written the .ps1 script and placed it on the server. I've now created the Task with the following parameters using the Task Scheduler GUI.

Program/script C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

Add arguments -File ".\EC2_Backup.ps1"

Start in D:\Scripts

To invoke the AWS connection details for the region and access keys, I also added the following to the top of the script