As far as I'm aware, you should have changed the Directory Server settings in the SEPM to point to a new DC before decommissioning the DC, since the SEPM infra was dependant on it.

Ideal scenario says that had the Directory Server binding been changed in the SEPM Server configuration, this issue would not have occurred.

Really hate to say this, but unfortunately there is no one in Support that would be able to help out since it's a dependency failure. Even I'm not aware of any KNOWN methdos to resolve this. Might be somene may or may not have come up with resolution steps.

Anyone from Support or any PM's want to chip in?

Can you give me your case number? I can try and put the case back in the queue and get another tech to work with you.

Thomas

How do you feel about working after hours after everyone has gone home and getting to the ugly. 

Worst case scenario, because the LDAP is being querried by IP, you can... 
1.  Restart the old decommisionned server and make the modifications necessary.  -> I am assuming you already considered and it's not possible, but felt it necessary to toss out there nonetheless.

2.  <down to the ugly>  Once business is over for the weekend.  Change the IP address on the server to be from .24 to .23.  Note this might muck up other parts of the network.  Hence, once everyone is gone for the weekend.  Once this is done, and SEPM can once again communicate for LDAP authorization, make the necessary changes pointing back to .24 and logout of the SEPM console.  Try to log back in with the server now pointing to the right LDAP address.

NOTE.
I am going to assume that you .24 is an ADC and that you have a backup on the network somewhere?  Is this server, your main DNS and ADC authentication server for the network?  If so, you may want to reboot, so that roles are transferred to the backup ADC and thus, not as many querries will hit this machine, lessening the impact on the network during your downtime... 

@ Jason - Thumbs up for you mate.

Good one.

Hi guys

Thanks for your reponses. Yes, we should have gone into SEPM and changed the LDAP settings prior to decomissioning the domain controller DOH!
But, the reason I did not was because we do not use LDAP to login. When I first setup SEPM I set it to use an SA login. I then decided to have a crack at
logging in using LDAP. I did not like it so change the setting back to SA logon. Symantec still saved the LDAP setting in the database and Im now buggered
because of it. Anyway, that's not going to solve my poblem. The old domain controller is no longer, it has been rebuilt with a new IP address. I may however
have ago at changing the IP on the new server to see if we can logon to make the setting change. Other than that I have been told by Symantec to uninstall
SEPM and reinstall it. My question is "Will this break my clients and will I have to uninstall & reinstall all the clients too?"

Thanks

You can use sylink replacer tool to able for the new sepm server to see the clients. no need to uninstall reinstall the clients.

Did you have a Go at changing the IP of the "new server" that is running LDAP to see if you could now get it to work?

Any updates on this?

Maybe someting to prevent this in the future.
In the case of having redundant domain controllers you can use only the domain name to connect to a available domain controller in your domain. If the AD domain name is avaliable in DNS as alias e.g. xyz.com then using the alias as name for the directory server should be sufficient.

Anyway that is how we solved domain controller dependencies.