how do I fix error LDAP bind failed with error 1323?

Just to update this... I don't know if this helps but I ran dcgpofix and got this message in red letters within the console: Could not open the Active Directory Object LDAP://rootDSE

Are you saying that you replaced a domain controller with a new machine, and gave it the same name and IP Address of the old domain controller?

I gave it the same IP... haven't been able to give it the same name although I'd like too

OK... but is it a domain controller?

Yes, it is also a domain controller

Hello,
Can you tell me more about the replacement Server? I.E. Server Version, what Roles are installed?
You may find that from the newly installed server you cannot PING your domain. If this is the case you will need to potentally run the below command from a comand prompt on your Domain Controller.
ipconfig /registerdns
Let me know how you get on :)
Cheers
MC

Ahhh, bit late sorry, run "ipconfig /registerdns" on your Primary DC.
Cheers
MC

Thanks guys... I've ran the command.  I'll let you know how things go in the next few minutes

@dhoffman_98... ok, so I should just change the IP address then?

1. Check your connection settings.  A poorly defined network will result in a poor AD infrastructure

2. Can your servers access each others Sysvol folder ? That should be necessary for replication.

3. Check your Eventvwr.  Is there a service that should be running and that actually isn't running ?

Restart the netlogon service on the domain controller to register the SRV records with the new IP.  dcdiag /fix also does it but I just usually restart netlogon.
Thanks
Mike

1. There is no "Primary" DC ever since Windows NT.
2. Running "ipconfig /registerDNS" on another machine, would have no effect on the bad machine. But if the bad machine is not showing properly when attempting to resolve via DNS from another machine, will cause an extra entry with the same IP Address to be created.

However, since this is a domain controller, the DNS entry should have been created when the DC was promoted. And since another server wth a static DNS entry already exists under the same IP address (the bad server) you won't be able to overwrite the record. This is a security function that prevents rogue servers from taking over as malicious DNS or domain controllers.

Here's one of the errors I'm also getting: (note we use standexadp.standex.net, not the stxengraving domain this machine is trying to use... so...)  it's looking for another division (where this used to be used)

This is the replication status for the following directory partition on the local domain controller.
 
Directory partition:
DC=stxengraving,DC=standex,DC=net
 
The local domain controller has not recently received replication information from a number of domain controllers.   The count of domain controllers is shown, divided into the following intervals.
 
More than 24 hours:
2
More than a week:
2
More than one month:
1
More than two months:
1
More than a tombstone lifetime:
1
Tombstone lifetime (days):
180
 Domain controllers that do not replicate in a timely manner may encounter errors. It may miss password changes and be unable to authenticate. A DC that has not replicated in a tombstone lifetime may have missed the deletion of some objects, and may be automatically blocked from future replication until it is reconciled.
 
To identify the domain controllers by name, install the support tools included on the installation  CD and run dcdiag.exe.
You can also use the support tool repadmin.exe to display the replication latencies of the domain controllers in the forest.   The command is "repadmin /showvector /latency <partition-dn>".

For more information, see Help and Support Center at

Normally you would want to avoid changing the IP Address after the DC is already promoted. My thoughts are that by using the same IP Address, DNS refused to allow it to become a new entry in order to protect AD from a rogue server.

My suggestion would be to change it to a new address, then promote it, and allow it to join the site as a new domain controller with a new address... and a new name.

Those errors would be normal until all replication has completed and until you can remove the bad server with NTDSUTIL.

ok, give me a few minutes...

You need to run a metadata cleanup on those old domain controllers, definitely on the one that is past the tombstone lifetime
http://www.petri.co.il/delete_failed_dcs_from_ad.htm
You run that from your good DC.
So when you say this DC was used in another division what do you mean; it was a DC for another domain?

Ok, assigned new ip address.  Now what? :)

restart netlogon to register the SRV records with the new address...you also still need to remove the "dead" boxes.
Thanks
Mike

remove the dead boxes?  can you elaborate a bit on that?

For now, don't be as concerned about removing the dead boxes. You can clean that up later. More important is to get the new machine to replicate properly. The Intersite Topology Generator  (ISTG) and the Knowledge Consistency Checker (KCC) will determine that you can't communicate with the other DC at that site, and will set your topology so that the new server can replicate with ones from other sites.

Now, that you changed the IP Address, you'll need to register the new IP Address with "ipconfig /registerDNS" and then DCPromo so that it becomes a full DC on the new address. Then replication should start. DCPromo will restart Netlogin for you.

@dhoffman_98... thanks mate... give me a few minutes.  I'm on it :)

ipconfig /registerdns doeesn't register SRV records if I recall correctly.
 

Once you have it all completed, Go check the link that mkline provided. That's a good site for information and I have personally used that article several times. It will walk you through how to clean out the metadata so the remnants of the old machine are gone.

But your priority for now is to get the new machine replicating.

That's correct mkline, it doesn't. But DCPROMO will take care of that.

when I ran DCPROMO... it is removing Active Directory from this server so I'm assuming after that is complete I'll want to use the link mkline sent to remove the old machine and then do DCPROMO again to get it back up with AD?

You are currently removing AD from the new machine.
IF that process gives you errors that state that it could not be removed correctly for some reason, then you might need to run that cleanup from one of your other domain controllers... and in that case, while you are there, you might as well do both this machine, and the crashed one.

If it does run correctly, just let it reboot, log in again as a local administrator (it should have asked you for the new local admin password while demoting) and then run DCPROMO again to promote it again.

If you don't get any errors demoting and then promoting, then you can go back and do the cleanup on the crashed server later.

@dhoffman_98... It let me do it without errors... I was starting to go thru the steps of that site but, after seeing your post to reboot I just did that (waiting now).  As soon as it comes back up I'll go thru dcpromo again.  back in a few

when I did dcpromo to remove AD, I didn't rename the server after it was done.... tell me I shouldn't have renamed it then and just worked to get AD back up so this machine is replicating....

I just got an "issue" during dcpromtion... it recognized the old name and asked if I wanted to continue.  I said yes and it said all info for the machine would be replaced which I assume is good?

Tell me if you had another server that survived the lightning blast. If so, you need to seize the FSMO roles on that server, because it carries the old Global Catalog objects, Then you need to remove metadata of that failed server, (FRS, DNS, and AD metadata). Once done, you should be able to join this new DC to the domain.

If you didn't have a server that holds the old AD objects in the GC, then you have a new domain, UNLESS you have an image of that old server... If you have a new domain, you will have to rejoin all computers and copy/paste profiles over in each users...

You CAN'T, rename a DC and provide the IP of an old server to call it the same server, the network bindings are different. To keep your domain, you have to have some of the old domain records, whether that comes from the old domain's replication partner, or from a backup..

Ok, dcpromo tasks have completed... the users in Georgia still can't access my documents although I've created the share on the machine.  What should I do next?

Well, the name thing is a little bit of a concern because of DNS.

Have a user in Georgia try to ping the machine by it's name. If they can ping it, then have them go to "\\servername\sysvol" in explorer and try to open that.

You may still also be waiting for the ISTG and KCC to finish replication of the topology as well.

You mean I should have renamed it (the server) when I did the first dcpromo?  There isn't anything in the sysvol folder yet... Maybe it's just not replicated yet?  Anyway to speed the replication along maybe?

Well, if you go into AD Sites and Services, you may be able to force the replication from the machine's replication partner.

What I meant about renaming is that your DNS settings are already going to have the name of the old server in there with the old server's IP Address. It's usually a best practice in this situation to build your new server with a new name and new IP Address to avoid any conflicts. The reason for that is that if someone decided to just put a new server online and use the IP Address of the old server, it could cause security concerns.

Are the people in Georgia able to ping the new server by name and get a response back?

Also, try going to a command prompt on the new server and run DCDIAG. You'll probably see information in there about various shared volumes that are not replicated yet.

It's not replicating because you have a broken replication set. You still have FRS metadata of the failed server. When FRS gets to replicating with that Server, all stops right there. You have to remove this old server out of FRS and then try to force replicate.

Still if you are trying to replace a server, DON"T. Bring this up as a new server. If you have a replicating partner, you can replicate it out. By bringing this up as a new server, instead of trying to replace it as old, you are much easier to tell the difference when cleaning up AD objects of the old server. This is why everyone is telling you to rename the server not use the old name, and IP.

Was very calming influence and provided easy explanations as to what was happening and what needed to happen.  Prioritized the issue for me - very helpful