How to Remove a Stale DHCP Server from Active Directory

When a Windows DHCP server is retired or removed improperly, its authorization can remain in Active Directory. This stale entry may continue to appear in the DHCP management console and should be cleaned up.

1. Check Authorized DHCP Servers

From an elevated PowerShell session on a domain controller or management system with the DHCP tools installed, run:

Get-DhcpServerInDC

You may see something similar to:

DnsName              IPAddress
-------              ---------
DHCP01.contoso.local 10.10.10.20
OLD-DHCP.contoso.local 10.10.10.15

Confirm that the server you intend to remove is actually retired and no longer providing DHCP services.

2. Remove the Stale Authorization

Remove the old DHCP server from Active Directory:

Remove-DhcpServerInDC -DnsName "OLD-DHCP.contoso.local" -IPAddress 10.10.10.15

Confirm the operation when prompted.

3. Verify the Removal

Run the following again:

Get-DhcpServerInDC

The retired server should no longer appear in the list of authorized DHCP servers.

Optional: Clean Up the DHCP Management Console

If the retired server still appears in the DHCP MMC console, right-click DHCP and select Manage Authorized Servers or remove the old server from the console.

Final Check

Removing a stale DHCP authorization does not delete DHCP scopes or modify another DHCP server. It removes the retired server's authorization record from Active Directory.

Before removing anything, verify the server name and IP address carefully—especially in environments where DHCP services have recently been migrated to a replacement server.

Migrating NPS Settings from Old Domain Controller to New Domain Controller

If you're using RADIUS on your Windows network, and you need to do Domain Controller upgrades, rebuilding RADIUS can be a pain if there are a lot of entries.  Using this process, you can easily back it up and then restore it on the new server.

NOTE:  This process assumes you are using the same name and IP address on the new OS for your new DC.

1.  Backup NPS on the old server.  Run this command:

netsh nps export filename="C:\NPS-Export.xml" exportPSK=YES

2.  For good measure, backup DHCP as well.

netsh dhcp server export C:\dhcp.txt all

3.  Copy these two files to a place where you can access them on your new DC.

4.  Once your new OS is promoted to a Domain Controller with the same name and IP address as the old DC, you can begin the import process.

5.  Install NPS on the new DC.

Install-WindowsFeature NPAS -IncludeManagementTools

6.  Import your NPS configuration file

netsh nps import filename="C:\NPS-Export.xml"

7.  Register NPS in AD

netsh ras add registeredserver

8.  Restart the NPS service

net stop ias

net start ias

PRO TIP:  Just in case, it's a good idea to grab a backup of the NPS registry key.  I personally haven't had to use it but it can't hurt to have it.

reg export HKLM\SYSTEM\CurrentControlSet\Services\IAS C:\NPS-Registry.reg

That's really all there is to it.  Good luck!

Exchange Anonymous Connector

 If you're like most, you need an internal relay on your Exchange server to allow devices and applications inside to send email without the need for credentials.  Since the connector can be scoped to the IP address of the source, this is a pretty good way to set it up.

I ran into a new issue on our new Exchange server today.  When you create the new Internal Relay receive connector to allow anonymous access, you must run a PowerShell command to make the connector accept messages.  This assumes you have the correct IP addresses in the relay.

Run this first:

Get-ADPermission "YourConnectorName" |

Where-Object { $_.User -like "NT AUTHORITY\ANONYMOUS LOGON" -and $_.ExtendedRights -like "*SMTP-Accept-Any-Recipient*" }

If this returns nothing, and it probably will, run this command to add the permissions:

Get-ReceiveConnector "YourConnectorName" |

Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" `

-ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Good luck!

Can't Remove Old Exchange UCC Certificate - Certificate Bound to Send Connector

I've been running into this a lot lately where an old certificate can't be removed from Exchange as it is bound to a send connector and most commonly it's on a hybrid-mode Exchange configuration.

Here's how to get rid of it easily on Exchange and then delete the old certificate.

First, run the command to get the certificates on the Exchange server.:

Get-ExchangeCertificate | fl

This will return a full list of all certificates on the server.  Make a note of the Thumbprint of the certificate you want to keep.  That's the only one needed.

Now, shut off the "Microsoft Exchange Transport" service using Exchange PowerShell:

net stop "Microsoft Exchange Transport" or Stop-Service -Name MSExchangeTransport whichever you prefer.

Next is to get the name of your Send Connector shown in the error when trying to remove the certificate.  You'll need that name in the next command to remove any certificates that are bound to the connector:

Set-SendConnector -Identity "Outbound to Office 365 - 5c10806d-35cb-6645-8b8f-fde431830769" -TlsCertificateName $Null

At this point you can now delete the old certificate(s) as they're no longer bound to the connector.

Now run these two commands to set the variables for the certificate you want to keep.  This is where having the Thumbprint for the new certificate is needed.

$cert = Get-ExchangeCertificate -Thumbprint 6B6CB53DF162724D4F3AD97E508C5BBF072DCE8

$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

Do not change the syntax on the 2nd command.  That's used to pickup that variable for the final command.

Use this command finally to assign the new certificate only to the Send Connector:

Set-SendConnector -Identity "Outbound to Office 365 - 5c10806d-35cb-6645-8b8f-fde431830769" -TlsCertificateName $tlscertificatename

Finally, restart the Microsoft Exchange Transport service and you're finished.

net start "Microsoft Exchange Transport" or Start-Service -Name MSExchangeTransport

This completes the removal of any old certificates bound to the Send Connector so you can delete them from the server.  As a precaution, always test your mail flow service to make sure everything is working properly.

Good luck!

 Tonight I was trying to fully clear our older MSA 2040 SAN that is getting a new storage lease on life.  To my surprise when trying to clear the volumes and vdisks off this SAN, I found one disk group that had been quarantined and the GUI would not let me remove this no matter what process I tried.  This MSA is not under warranty there was no way to contact HPE support to help me. HPE forums always finished with "contact support" and "I can't share the special commands in a forum".  Beyond frustrating.

Just a note, the MSA family is a rebrand of Dot Hill (now Seagate) AssuredSAN. Lenovo and Dell both have the same products. It's the same CLI in the Lenovo at least.

To force a disk deletion:

From CLI, create a new user with the role of "diagnostic"

# show users (to verify existing user accounts and roles)

# create user <new username> role diagnostic

The admin will be immediately prompted for a new password, use a complex password (one special character, one number, A-Z, a-z)

Verify the new user has been created by entering “show users” CLI command

After the new user account is created, log into the A controller CLI using the new diagnostic user account.

From CLI prompt, enter the "show disk-groups" command to verify disk-groups and to identify the foreign disk group you want to remove. Unfortunately, your existing disk group and the foreign disk group have the same name, capacity and RAID version so your approach to removing based upon SN is the best way to specify the appropriate disk-group for deletion.

From CLI, enter the following command:

# set advanced-settings virtual-pool-delete-override on

User will be prompted, enter “yes”

Enter “show advanced-settings” to confirm the configuration successfully entered:

User should observe “Virtual Pool Delete Override: Enabled” near the bottom of the list; it is only listed when properly enabled.

After entering the above command to enable virtual-pool-delete-override, you will only have 15 minutes to complete delete operations, otherwise, you will need to re-enable under diagnostic user and continue where you left off.

After virtual-pool-delete-override is turned on, continue to attempt to remove the disk group using the SN approach you previously attempted.

Get the vdisk or disk-group serial number if you don't have it.  When running the "show disk-group" command the serial shows as the very long hex number.

Execute removal:

# remove disk-groups diskgroupserialnumer or

# remove vdisks diskgroupserialnumer

Restart both controllers (MC and SC).

# restart mc both

#restart sc both

This was done on a HPE MSA 2040, with storage firmware GL220P008-01. This process worked perfectly for me and allowed me to fully clear and recover all disks in the SAN.  What was only 6TB before this process is now allowing me to use the full 11TB after configuring the new disk groups and volumes.

Credits: https://forums.lenovo.com/t5/Enterprise-Storage/S2200-3200-dequrantine-diskgroup/m-p/3682552

Hard to believe a Lenovo post helped me resolve this issue on a HPE 2040 SAN.