Ondrej Žilinec – IT Blog

We had Active Directory domain called DOMAIN.LOCAL. There was Exchange 2010 installed. It was fully functional. After some time I added new sub-domain/child domain SUB.DOMAIN.LOCAL and migrated users with mailboxes from DOMAIN.LOCAL to SUB.DOMAIN.LOCAL.

Problem

When users from SUB.DOMAIN.LOCAL logged into OWA they received following view:

Error stated: Exception message: Could not find any available Domain Controller in domain DC … so problem is probably in the way Exchange locates domain controllers. When users clicked F5 or refreshed website, he could see his e-mails normally.

There was also event 2130 logged on Exchange server saying Exchange Active Directory Provider could not find an available domain controller in the domain.

Solution

When you want to install Exchange into Active Directory domain, you need to prepare forest and also domain before you install it. You use setup.com (from installation DVD of Exchange) with some switches (for example /PrepareSchema, /PrepareAD,…). So new added domain SUB.DOMAIN.LOCAL to existing AD Forest was not prepared for Exchange implementation. I ran following command setup.com /PrepareDomain:SUB.DOMAIN.LOCAL:

If you have more then one domain to prepare for Exchange, you can use command setup.com /PrepareAllDomains.

The best way to run /PrepareDomain or /PrepareAllDomains is:

• to be logged domain controller with role Schema Admin
• to be member of Enterprise Admins group
• to be member of Schema Admins group

I hope you will not make same mistake as I did 🙂

Couple months ago we have created Active Directory domain for one of our customer. His AD was subdomain of existing AD domain hosted in Germany. Let’s call them following:

• DOMAIN.LOCAL <– Main AD in Germany
• SK.DOMAIN.LOCAL <– New created domain in Slovakia

To make administrators life easier in future, we have created DFS Shares in domain SK.DOMAIN.LOCAL. One of those DFS shares is called “Common”. So people in Slovakia were accessing DFS share \\\\SK.DOMAIN.LOCAL\\Common and share data. Under this DFS Namespace following share was hidden \\\\FSSERVER\\Common.

Everything worked just fine.

Problem

Problem appeared when users from Germany (from domain DOMAIN.LOCAL) wanted to access this share. There were following symptomps:

• Users from DOMAIN.LOCAL couldn’t access \\\\SK.DOMAIN.LOCAL\\Common
• Users from SK.DOMAIN.LOCAL could access \\\\SK.DOMAIN.LOCAL\\Common
• Users from DOMAIN.LOCAL could access \\\\SK.DOMAIN.LOCAL\SYSVOL and \\\\SK.DOMAIN.LOCAL\NETLOGON

There were no firewalls between two domains. All ports were accessible.

Solution

After couple tries (and using dfsutil) I figured out that client machine from DOMAIN.LOCAL get as DFS Refferal NetBIOS server name FSSERVER and it cannot translate FSSERVER to IP (FSSERVER is from SK.DOMAIN.LOCAL). Client machine from DOMAIN.LOCAL although can translate FQDN of FSSERVER.SK.DOMAIN.LOCAL. I tried to put FSSERVER IP record into client machine’s hosts file and everything started to work perfectly. So we have more solutions to solve issue:

• Synchronize NetBIOS names between two domain (weird)
• Add DNS Search suffixes to clients in domain (not nice solution and can slowdown DNS queries)
• Force DFS to propagate FQDN as refferals (winner)

I decided to force DFS to propagate FQDN as refferals. It’s made by change in registry keys for DFS service. More about it is at http://support.microsoft.com/kb/244380/en-us. One more important thing is that you need to remove and re-add refferal servers from DFS Namespaces. I used DFS console because I didn’t use DFS Replication. If you do use DFS Replication it’s recommended to do it using cmd line (dfscmd.exe).

That’s all folks,