Category Archives: Windows Server

Windows Server 2022 Core – Failed to release DHCP lease

There appears to be a bug in Server Core 2022 in regards to changing the network settings through “sconfig”.

I’m deploying a new server from template in vCenter and by default it drops onto a private network with DHCP. The first thing I will do is go edit the settings of the VM and drop it on the proper network. After the VM is properly configured I will then go through “sconfig” to reset the IP to a static IP.

In “sconfig” you punch in number “8” for “Network Settings” and select “1” for the only NIC in the machine and you will be at the following prompt:

Here you will select “1” for 1) set network adapter address.

Then select “S” for (S)tatic IP Address.

Follow the on-screen prompts to enter IP, Subnet Mask, and Default Gateway. It is here you may be prompted with the error.

Setting NIC to static IP…

Failed to release DHCP lease.

Result code: 83

Method name: ReleaseDHCPLease

If you run into this issue you can enter “15” on sconfig and drop to Powershell. You can then run the following commands:

Get-NetAdapter

This will provide the NICs and more importantly the “Name” field which will be needed below

Remove-NetIPAddress -InterfaceAlias Ethernet0 -confirm:$False

Even after getting this far you may still not be able to assign the IP through “sconfig” in which case you can do it with Powershell.

New-NetIPAddress -InterfaceAlias Ethernet0 -IPAddress 172.16.1.2 -PrefixLength 24 -DefaultGateway 172.16.1.1

You can now launch “sconfig” go back to “8” Network Settings and configure your DNS servers.

Monitoring Domain Controller Windows Firewall Logs (Part of Active Directory Hardening Series)

The first step before you can monitor the local DC firewall logs is to make sure you have properly setup your domain controllers to log firewall activity. If you have not already turned on firewall logging and increased the log size to the maximum you can configure that by looking at my prior post: https://paularquette.com/lock-down-your-active-directory-domain-controllers-internet-access-part-of-my-active-directory-hardening-series/

I have shared a new script on GitHub to do some basic monitoring of dropped traffic on your Domain Controllers. https://github.com/paularquette/Active-Directory/blob/main/AD_Monitor_DC_Firewall_Logs.ps1

I currently run this script every hour and I get plenty of overlap for logs. The logs roll relatively quick but not that quick. I’m also logging all allows and I may change that in the future to only log drops.

In order to see dropped traffic outbound you would have to have outgoing firewall rules in place. By default traffic is not blocked going out. You can reference my previous post linked above.

In the example below you can see I’m limiting all TCP/UDP outbound traffic on Non HTTP ports to a certain subset of IP ranges:

If this Domain Controller tries to send any NON-HTTP(s) traffic outside of the organization it will show up in the DC firewall logs.

Example of HTML Report:

If your IT Security group has the hardware firewalls super locked down you may not see much if any traffic being dropped on the local DCs, but it still isn’t a bad idea to have another layer of security around such a high profile service!

PrintNightmare – [0Day] Windows Critical Vulnerability

I had been watching Twitter all day yesterday and amongst all the #infosecbikini photos filling up InfoSec Twitter there was mention of this critical Windows vulnerability. At first it sounded like the June patches would protect you, then Twitter seemed to lose faith that was the case.

The US Cybersecurity & Infrastructure Security Agency (CISA) released the following notice the evening of June 30, 2021. (https://us-cert.cisa.gov/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability)

It has been recommended to disable the Windows Print spooler service on Domain Controllers and any systems that do not print.

EDIT: As of writing this entry the best workaround I have been able to find if you need to keep print services running is here: https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

EDIT 2: Microsoft has finally responded: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527

EDIT 3: CISA put out emergency directive: https://cyber.dhs.gov/ed/21-04/

For your meme viewing pleasure:

Extending Volumes in Windows Server Core

If you add space to a Windows Server Core hard disk in a virtual platform like VMware and need to extend the disk in the Operating System you will have to complete it all via command line.

Step 1

Add the space to the hard drive in your virtualization platform

Step 2

Login to the server and launch diskpart. You can then issue the command “list disk” to see which disks are on the system and which ones have free space.

Step 3

Type in “Select Disk <number>” in order to choose the disk you want to modify. You can then issue the command “List Volume” to provide the volumes on that disk in order to find the volume you want to expand.

Step 4

As you can see from the image in “Step 2”, we have 100GB that is listed as “Free”. We want to add that free space to the currently large volume, which you can see from “Step 3” is listed as “Volume 2”.

Type in “select volume <number>” and then type in “extend” in order to extend the volume for the full length that we can.

Running another “list volume” should show that the volume size is now increased to 199GB.

Server 2012R2 in place upgrade to Server 2019 on VMware

I’m personally not a fan of in place Microsoft Server upgrades but I suppose they have their time and place.

Since many of our 2012R2 servers are from the 5.1 and 5.5 days of VMware many of them are still running Virtual Hardware v9. This hardware version needs to be upgraded to perform the OS upgrade.

I was able to successfully re-create the issue with an upgrade of a clean 2012R2 install on v9 hardware. After the first reboot you will get stuck at the black screen with blue window, with no circle running underneath. I let this run for two full days (48 hours) before cancelling it.

After cancelling it and resetting the VM, you will be given the following error message:

We couldn’t install Windows Server 2019

We’ve set your PC back to the way it was right before you started installing Windows Server 2019.

0xC1900101 – 0x20017

The installation failed in the SAFE_OS phase with an error during BOOT operation

VMware generally states that you shouldn’t upgrade the VM hardware version unless there is a need. In this case there is a need.

My recommendations would be to do the following:

  1. Shut down the VM you want to perform an in place upgrade on
  2. Take a snapshot with the VM off
  3. Upgrade the Virtual Machine hardware version (We went to v15)
  4. Power on the VM, mount the ISO, run the upgrade

This process seems to be working for us, and although this may be a no-brainer, I’m putting it out there for the search engines to index in case it does help someone.