Link to home
Start Free TrialLog in
Avatar of Dwight Crane
Dwight CraneFlag for United States of America

asked on

Can not create Mailbox (GAL issue)

I have looked up this error code and everything points to issues with the GAL.  In the ESM, there is a mailbox that doesn't have a network user anymore. When I go to right click on the name, after 2 mins I get this same error. error 0xc007054b Domain not valid.

I am not able to create any new Mailbox either. When try to create  a new user in AD it tells me it can't verify uniqueness of name because the GAL can't be reached.

Global Catalog IS checked on the DC for NTDS properties. However this is an alias name of 21CE9160-7378-4A3C-B3D1-B0713FDD3391._msdcs.(domain name).   This name is NOT pingable.

Avatar of TheCleaner
TheCleaner
Flag of United States of America image

Avatar of Dwight Crane

ASKER

I can't use Sembee's solution. The problem with that is, in ESM>Recipient Update Services>, there are 2 entries. RUS(Enterprise Configuration) and RUS (CompanyName). both have proper entries pointing to "Grant" server (our only DC). However, lets say they weren't, when you open the properties and try to <Browse> to find the DC, there is no visible network list to choose from. So I cant' point it to anything even if I want to.

Here's a kicker... I can ping Grant, Exchange is working (people still send/recieve), Remote Logon to exchange box no longer works via Name or IP.  
I ran DCDIAG from exchange and this is what i got.  Where is it pulling that absurd host name from?

Testing server: Default-First-Site-Name\GRANT
   Starting test: Connectivity
      The host 21ce9160-7378-4a3c-b3d1-b0713fdd3391._msdcs.CompanyName.WoodlandPark could not be resolved to an
      IP address.  Check the DNS server, DHCP, server name, etc
      Although the Guid DNS name (21ce9160-7378-4a3c-b3d1-b0713fdd3391._msdcs.CompanyName.WoodlandPark) couldn't be
      resolved, the server name (grant.Sturman.WoodlandPark) resolved to the IP address (10.10.1.125) and was pingable.
      Check that the IP address is registered correctly with the DNS server.
      ......................... GRANT failed test Connectivity
That's the unique GUID and should be listed as an Alias(CNAME) under DNS under the _msdcs.domain.com zone in DNS.

If it isn't there then you can create one there as a CNAME, using the GUID and then browse to Grant at the bottom and choose that one.
I tried that. Under Forward LUZ there is MyDomain. Under the domain is the _msdcs folder. Inside that is an Alias record with the quid. This didnt' seem to change a thing though.

on the Exchange server, I listed the DNS Cache and saw 4 records that didn't resolve they were _ldap._tcp.grant.DOMAIN
_ldap._tcp.gc._msdcs.DOMAIN
_ldap._tcp.default-first-site-name._sites.grant.DOMAIN
_ldap._tcp.default-first-site-name._sites.gc._msdcs.DOMAIN

becasue I didnt' even see these entries in the DNS server, as a test I put them in the HOST file and now resolve. I know this isn't proper and if they are needed, I have NO IDEA how they suddenly dissapeared. This was all working fine till this past weekend.
I found that all the SRV records are gone from DNS server. I put in the ones for LDAP (tcp/udp) and I can now create users on teh network again. I still can't create Mailbox's. I think because there are no .GC. entries in teh DNS server the global catalog can't be referenced. I dont' know how these records got removed, but I can't find a reference on how manually add the Global Catalog refernces in DNS. I tried turning GC off then on again in hopes it would regenerate the records, but no go. Anyone know how and exactly what the GC entries should be?
Don't worry about manually recreating them.  Instead, on the DC, do:

netdiag /fix

then

ipconfig /registerdns

and that should create the necessary records.

Let me know.
I do not see any new records created on DNS. Here is the log file from NetDiag
netdiag.log
On the exchange I did a display of DNS and see this. Odd there are two same entries and one works and one doesn't. This was after I flushed the dns cache to get  a fresh read.

_ldap._tcp.gc._msdcs.sturman.woodlandpark
----------------------------------------
Record Name . . . . . : _ldap._tcp.gc._msdcs.sturman.woodlandpark
Record Type . . . . . : 1
Time To Live  . . . . : 556216
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 10.10.1.125


_ldap._tcp.gc._msdcs.sturman.woodlandpark
----------------------------------------
Name does not exist.
ASKER CERTIFIED SOLUTION
Avatar of TheCleaner
TheCleaner
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Ok, here is some more data plus a screenshot. It should be able to explain what I see and you most likely will readily see what is missing.
netlogon.dns.log
DCdiag.log
DNS.JPG
Ok, I checked the register box on DNS tab. There are 3 DNS server entries. 2 are the DNS servers from ISP and 1 is itself 10.10.1.125.  The only thing in DNS eventvwr logs are entries when DNS service starts and the Scavage cyle.  The netdiag fix test displays a dozen failures, however they are all failed to register on the 1 DNS entry for the NIC which is the ISP DNS server.
Ok, I moved the 10.10.1.125 to the top of the list on the nic, ran the netdiag fix. It generated a bunch of entries on the DNS server (good thing).  Will this order affect grabbing DNS from the ISP?
Everything Seems to be working now. :)  I am concerned though about the order of the DNS servers.  Let me know what you think. THANK you for all your help in trouble shooting this.
You shouldn't have the DNS entries for the ISP at all under the NIC.  Those should be in DNS as Forwarders.  The idea is that you check locally for DNS resolution, if it can't be found locally it is sent on to the ISP (for internet browsing, etc.)

The only thing under the local DNS in TCP/IP properties should be local DNS servers.
BTW, your ISP probably was wondering what just happened when you tried to register all your SRV records with them (prior to you moving 10.10.1.125 to the top).
There forwarders were/are pointing to the ISP already. So i guess it was a bit redundant. Thanks so much!
Welcome...glad it was resolved.