Windows Dc Renaming Error

Hi everyone

Today I wanted to talk an issue I seen, it’s not common, but it’s an error that can happen. It’s if you rename a DC like if it’s a normal computer, not the correct way. The problem after is it break your Active Directory Database.

After the reboot you will see that error on the login screen of the DC;

Security database on the server does not have a computer account for this workstation trust relation on domain controller.

To recover you need to use netdom the old way.

Please know it’s an issue with only one DC in a single forest. Don’t do those step if you have other working DC or a bigger forest.

1. First we do a backup in case something bad happen.
2. netdom computername <CurrentName> /enumerate
3. netdom computername <CurrentName> /add:<NewGoodName>
4. netdom computername <CurrentName> /makeprimary:<NewGoodName>
5. Restart
6. Check all service if OK, after we remove the old name
7. netdom computername <NewGoodName> /Remove<CurrentName>
8. Restart again.

That should do the trick to revert back to the good name, after that if you want to rename a DC, remember it’s not a good idea, but at that point it’s easier to promote another’s one to do the trick. If you need to keep the old server up, you can make sure you have another DC, and after you demote and re-promote with the good name the DC you wanted to change the name.

Reference for the post

Advertisement

Windows AutoPilot and QEMI / kvm-virtualization UUID issue

Hi everyone

Today I wanted to share a small bug you can encounter on QEMU / KVM if you are testing Windows 10’s machines. It’s something new I seen, so I wanted to discuss it.

The bug is simple to see, it’s in the Windows 10 setup at the start if you see a business login / portal that is not for your business then you must think the system UUID is probably taking one already registered online.

It’s something I never seen before, but it was reported there (or there), so it’s why I talk it.

In that case the user was seeing a login page from another business, as seen here when he used a normal ISO.

The QEMU command used to deploy the machine;

qemu-system-x86_64 -drive file=Windows.img,format=qcow2,if=virtio \
 -drive file="en-us_windows_10_enterprise_ltsc_2021_x64_dvd_d289cf96.iso",media=cdrom -drive file=virtio-win.iso,media=cdrom \
 -boot order=d -enable-kvm -machine type=q35 -cpu host,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time \
 -m 32G -smp sockets=1,cores=6,threads=1 \
 -device virtio-vga-gl -display sdl,gl=on \
 -netdev user,id=network0 -device e1000,netdev=network0,mac=52:54:00:12:34:56

In such case to bypass that problem make sure to change the UUID, that way to make QEMU use the system UUID;

 -enable-kvm -uuid $(dmidecode -s system-uuid)

In the OOBE make sure it’s offline too.

I will quote the answer from Aarad Prasad for that part;

Make sure the process is offline, by disabling your network adapter while in the OOBE process. Get an elevated prompt by pressing Shift+F10 and executing the following in powershell:

Disable-NetAdapter -Name "Adapter Name" -Confirm:$false

You may get the adapter name by

Get-NetAdapter