Tag Archives: Domain Controller

Exchange Server in Azure – Part II

January 26, 2023 jaapwesselius Leave a comment

In my previous blog I wrote about creating a virtual network in Microsoft Azure and a site-to-site VPN connection to connect your on-premises network to the virtual network in Azure. The next step is to create a Domain Controller and (optional) an Azure AD Connect server in Microsoft Azure.

On a Domain Controller on-premises, create a new site in Active Directory and a new subnet and assign it to the new site. In my environment, the new site is called ‘Azure’ and the new subnet is ‘172.16.1.0/24’ as shown in the following screenshot:

Adding a new VM to Azure is not too difficult, but you must be careful with change the network properties. Do not change the DNS setting on the NIC inside the VM, but change it on the properties of the networking interface object in Azure.

Open the properties of the Virtual Machine in Azure, scroll down to Networking (under Settings) and click on the Network Interface. Select DNS Servers (under Settings) and add the (AD Integrated) DNS server on-premises shown in the following screenshot:

It takes some time before the new settings are active. Once active, you should be able to resolve other machines on the on-premises network and more important, join the new VM to Active Directory. And once joined, install the ADDS components on the new VM and promote it to a new Domain Controller, running in Azure.

Another thing I have changed in Azure is the DNS setting of the virtual network. Open the virtual network properties and scroll down to DNS Servers (again under settings). Open the DNS servers properties, select the ‘custom’ radio button and add the IP address of the new Domain Controller (with Integrated DNS of course). All VM’s on this virtual network now use the new Domain Controller for name resolution.

For external recurring DNS queries, and the Azure forwarder with IP address 168.63.129.16 on the forwarders tab of the DNS server as shown in the following screenshot:

The next step is to create a VM that will host the Azure AD Connect server. It still is my test environment so VMs don’t have to be that big, so for the Azure AD Connect server I’m using the Standard DS1 v2 (1 vcpu, 3.5 GiB memory) as well. You can also install Azure AD Connect on the Domain Controller in Azure, but personally I’m not a big fan of installing other services on Domain Controllers.

Make sure the new VM is connected to the Virtual Network that was created earlier, it will automatically get an IP address in the correct range.

Once installed, logon to the new server, join it to the domain and reboot again, just you would do with a server on-premises.
Since we are working post migration to Exchange Online we do have an Azure AD Connect server running on-premises. Moving this server to Azure is just like upgrading an Azure AD Connect server. Export the configuration of the existing server to a JSON file, and import this JSON file using the Azure AD Connect setup application. I have blogged about this process in an earlier upgrade blog: https://jaapwesselius.com/2021/12/24/upgrade-azure-ad-connect-from-1-x-to-2-x/ but it’s similar to moving to Azure.

When using this method, the new server will automatically be in ‘staging mode’, so it will fill its database with information, but it won’t sync anything with Azure AD. When you are ready, set the old server in staging mode and get the new server out of staging mode. At this point you are synchronizing using Azure AD Connect in Azure instead of on-premises.

Windows

Transfer FSMO Role Win32 error returned is 0x20af

February 11, 2021 jaapwesselius 1 Comment

For a client I had to test some domain controller scenarios and issues. There are two domain controllers (DC01 and DC02) and a new one (NewDC) is added. FSMO roles are moved to NewDC and DC01 must be decommissioned. No big deal you would say….

Domain FSMO roles (RID Master, PDC and Infrastructure master) moved in an instant, but moving the forest FSMO roles (Schema master and Domain Naming master) failed with the following error, both in the GUI as well as NTDSUTIL:

Win32 error returned is 0x20af(The requested FSMO operation failed. The current FSMO holder could not be contacted.)
Depending on the error code this may indicate a connection, ldap, or role transfer error.

Using Netdom query FSMO I could see the roles.

This happened when logged on the AD01 as well as NewDC, connectivity was not an issue and I did not notice any strange issues with Exchange and Outlook or OWA clients.

Using Google I found several other similar issues, and the overall recommendation was to seize the FSMO roles. Seizing FSMO roles is an option when the old Domain Controller is no longer available, but in my scenario I had to keep the old Domain Controller for testing.

But instead of using Google I had to look in the eventlog in the first place. The first entry I found was a confirmation that the roles could not be transferred, but Additional Data Error value: 4 was not very helpful:

An attempt to transfer the operations master role represented by the following object failed.

Object:
CN=Partitions,CN=Configuration,DC=msexchangebook,DC=com
Current operations master role:
CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=msexchangebook,DC=com
Proposed operations master role:
CN=NTDS Settings,CN=NIEUWEDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=msexchangebook,DC=com

Additional Data
Error value:
4

Subsequent entries were more helpful, Event 2019, ActiveDirectory_DomainService indicated replication issues:

Or in tekst for Search Optimization:

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.

Operations which require contacting a FSMO operation master will fail until this condition is corrected.

FSMO Role: CN=Partitions,CN=Configuration,DC=msexchangebook,DC=com

User Action:

Initial synchronization is the first early replications done by a system as it is starting. A failure to initially synchronize may explain why a FSMO role cannot be validated. This process is explained in KB article 305476.
This server has one or more replication partners, and replication is failing for all of these partners. Use the command repadmin /showrepl to display the replication errors. Correct the error in question. For example there maybe problems with IP connectivity, DNS name resolution, or security authentication that are preventing successful replication.
In the rare event that all replication partners are expected to be offline (for example, because of maintenance or disaster recovery), you can force the role to be validated. This can be done by using NTDSUTIL.EXE to seize the role to the same server. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.

The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

In the end it turned out that DNS was not configured correctly, hence the replication issues. Fixed the DNS settings on the Domain Controllers and after a short while the Domain Controllers resumed replication and I was able to move the Forest FSMO roles to the new Domain Controller.

So in short, always check eventlog, replication and DNS when troubleshooting Domain Controller issues 😉

Exchange

Configure Domain Controller in Exchange 2010

November 16, 2010 jaapwesselius Leave a comment

10 years ago it was a best practice to use an ’empty root’ Active Directory model. Lately I see this model quite often in Exchange 2003 environment that need to be upgraded to Exchange 2010.

A customer has an empty root AD with 2 domain controllers in this empty root. Outlook’s autodiscover sometimes returns one of these domain controllers, but in this specific scenario these domain controllers are behind a firewall. Therefore they cannot be used for authentication purposes by (desktop) clients.

Exchange has a service (MSExchange ADAccess) that uses the topology discover to retrieve a list of available domain controllers. You can check the properties of the Exchange Server in the Exchange Management Console or you can check the eventlog for Event ID 2080.

Log Name: Application

Source: MSExchange ADAccess

Date: 15-11-2010 12:46:57

Event ID: 2080

Task Category: Topology

Level: Information

Keywords: Classic

User: N/A

Computer: cashub01.infra.root.local

Description:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1576). Exchange Active Directory Provider has discovered the following servers with the following characteristics:

In-site:

AD001.root.local CD- 1 6 6 0 0 1 1 6 1

AD005.infra.root.local CD- 1 6 6 0 0 1 1 6 1

AD013.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD014.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD002.root.local CDG 1 7 7 1 0 1 1 7 1

AD004.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD006.infra.root.local CDG 1 7 7 1 0 1 1 7 1

AD003.infra.root.local CD- 1 6 6 0 0 1 1 6 1

Out-of-site:

To exclude a particular domain controller the Set-ExchangeServer cmdlet can be used in the Exchange Management Shell. In this example the AD001 domain controller is excluded for Exchange Server CASHUB01:

Set-ExchangeServer Identity “CASHUB01” –StaticExcludedDomainControllers AD001.root.local

Is is also possible to create a list of domain controllers and global catalog servers that are allowed by the Exchange Server:

Set-ExchangeServer Identity “CASHUB01” –StaticDomainControllers AD005.infra.root.local,AD003.infra.root.local

Set-ExchangeServer Identity “CASHUB01” –StaticGlobalCatalogs AD013.infra.root.local,AD014.infra.root.local

After configuring the Exchange Server you’ll see the results in the event log: