I’m putting together a blog post for easy access to Windows Server Core tasks.
View Installed Programs (PowerShell):
Get-WMIObject Win32_SoftwareFeature|Select ProductName,Caption,Version|FT
Request New Certificate (PowerShell):
Get-Certificate -Template “_TEMPLATENAME” -SubjectName “CN = SERVERNAME.domain.suffix” -CertStoreLocation cert:\LocalMachine\My
In my previous blog (https://paularquette.com/windows-server-firewall-logging-via-gpo-log-file-not-created/) I mentioned that simply turning on Group Policy for the Windows Firewall doesn’t actually create the firewall logs.
In order to force create the windows firewall logs for servers that are already out there in the wild I have created a batch script that can be ran in Group Policy as a startup script.
The script is located on my github but I’ve listed here as well because it is a small script. For the latest updates though please visit github as it is unlikely I will individually update this blog post.
https://github.com/paularquette/Windows-Servers/blob/main/CreateFirewallLogs.bat
rem Batch Script to Create Firewall Log Files
rem Written By: Paul Arquette
rem Last Modified: Oct 24, 2022
rem Last Modified For: Github
if exist C:\Windows\System32\LogFiles\firewall\pfirewall.log (
echo file exists
) else (
netsh advfirewall set allprofiles logging filename %systemroot%\System32\LogFiles\firewall\pfirewall.log
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable
)Did you apply a Windows Firewall Policy that blocks the ability to talk to Active Directory and get Group Policies? We all make mistakes….
¯\_(ツ)_/¯
You can no longer login to this box with Active Directory Credentials…..
You try to login as a local administrator and see that everything is grayed out?
On top of that you also turned off the ability to apply local firewall rules?
Don’t fear! There is a way to fix this as long as you have Local Admin rights on the box. Open up the Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall
Right-Click the WindowsFirewall key and delete it and all sub-keys and reboot.
This should fix the issue and you will pull down the corrected Group Policy on reboot.
When you try to enable Windows Firewall Logging via Group Policy you will notice that the Log Files are not created / do not exist.
You configure the GPO to setup logging:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security (Right-Click -> Properties)
However, no matter how many “gpupdate /force” you run or reboots of the server you do, the “LogFiles” directory still does not contain a “firewall” folder, let alone the actual log files.
How do we fix this?
One thing you could do if are deploying from a template is configure the template so these files are created. However, this only fixes new server deployments going forward, doesn’t do much for the servers already out there running.
The good news is, the same commands that can be used to fix the template can also fix all the servers that are currently running out there in the wild.
The Fix
In order to make a blog that will work for Server GUI or Server Core I’m going to use netsh firewall commands, run these from an elevated “Administrator” command prompt or PowerShell window.
The first command will actually create the folder and files necessary, and group policy should be able to configure everything else.
These commands will create the folder/files, set the maximum file size for the log file to the maximum size allowed by windows, log dropped packets, and allowed packets.
netsh advfirewall set allprofiles logging filename %systemroot%\system32\LogFiles\firewall\pfirewall.log
netsh advfirewall set allprofiles logging maxfilesize 32767
netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable
If you are just performing a normal robocopy without any crazy commands the default behavior is to copy the “Date Modified” timestamp of a folder but not the “Date created” timestamp.
If you want the Date created timestamp to be copied over you have to add the following flag to your robocopy command:
/dcopy:datLeaving breadcrumbs to update this post. Found these two posts on reddit.
https://www.reddit.com/r/sysadmin/comments/plq1hw/heads_up_windows_server_2022_kms_host_keys_seem/
https://www.reddit.com/r/sysadmin/comments/suqn1l/update_fixed_windows_server_2022_kms_host_keys/
The error we were receiving on the client was:
The client has sent an activation request to the key management service machine.
Info:
0x80072AF9, 0x00000000, <redacted>:1688, <redacted>-<redacted>-<redacted>-<redacted>-<redacted>, 2022/07/14 19:42, 1, 1, 258969, <redacted>-<redacted>-<redacted>-<redacted>-<redacted>, 25Resolution:
Launch Volume Activation on Server 2022 KMS Server and run through the process to install a new key, and just put the same key back in after you apply the current patches. This was done before July 2022 patches were applied.
After performing these tasks verify that the failed requests will now be processed by the KMS server.
In this blog I’m revisiting Microsoft’s Robocopy with using the “/XD” flag for excluding certain directories.
We are in the process of migrating about 200TB of data from one file cluster to another due to the underlying storage also changing. So robocopy has been our best friend for quite some time when you have to move these large datasets and retain things like Microsoft ACLs.
This particular command will copy from <source> to <destination> with the following options:
robocopy \\uncsource Y:\LocalDest /TEE /MIR /copyall /zb /w:1 /r:2 /xo /MT:16 /XD "?????1" "?????3" "?????5" "?????7" "?????9"/TEE: Writes the status output to the console window
/MIR: Mirrors directory tree (adds and deletes based on source data)
/copyall: Copies all file information
/zb: Copies files in restartable mode
/w:1: Specifies wait time between retries in seconds (1 second in this example)
/r:2: Specifies the number of retries on failed copies (2 retries in this example)
/xo: Excludes older files
/MT:16: Creates multi-threaded copies with n threads, must be between 1 and 128, default is 8.
/XD: Exclude directories
Directories are listed after XD in quotes and wildcards can be specified. A question mark (?) can be used for any character and an asterisk (*) can be used to fill in anything else.
For example if you wanted to exclude any directories that started with “ADM”, you could use:
/XD "ADM*"For example if you wanted to exclude any directories that start with anything and have a 1, 3, 5, 7, or 9 in them:
/XD "*1" "*3" "*5" "*7" "*9"The original first example above (copied again below this paragraph) is saying there can be any character for the first five characters and then if the last character is a 1, 3, 5, 7, 9 than exclude it and do not copy it.
robocopy \\uncsource Y:\LocalDest /TEE /MIR /copyall /zb /w:1 /r:2 /xo /MT:16 /XD "?????1" "?????3" "?????5" "?????7" "?????9"**NOTE** If you don’t want directories in directories to get skipped with the same wildcards specify a full path prior to the wildcards.
/XD “C:\Temp\?????1”
I was working with a colleague of mine the other day on this issue. If you are using WIndows Server 2022 with IIS to setup a website that will use client certificate authentication and notice that you are not prompted for a certificate….. the issue is probably TLS 1.3.
Windows Server 2022 IIS by default uses TLS 1.3. If you check the box to disable TLS 1.3 which will fall back to TLS 1.2 everything works.
Still not sure at this moment who is to blame, Microsoft, or the web browsers.
EDIT: Update from the Microsoft Article
https://docs.microsoft.com/en-us/answers/questions/654803/err-connection-reset-if-asking-client-certificate.html
Yes, I got answer: Microsoft implemented TLS 1.3 in most secure way by RFC. IIS wants to perform post-handshake authentication. Unfortunately common browsers do not support it in default configuration. You can enable it only with Firefox (when I last checked, maybe samething changed in near past). So, de facto IIS default configuration for two-way SSL with common browsers do not work with IIS when TLS 1.3 only is enabled.
You can enable IIS and TLS 1.3 only configuration by enabling in-handshake method for IIS instead on post-handshake method.
If you haven’t already forced ADFS to run on TLS 1.2 you are behind the curve. Activating TLS 1.2 on ADFS and turning off all other vulnerable services is relatively easy.
Step 1: Disable SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, RC4 & Enable Strong Auth for .NET
The first step that always goes unsaid is to snapshot your Virtual Machines or get a solid backup state before making any changes to a running production environment. The next unsaid step is to perform these activities on a test/dev environment before taking down Production!
SSL 2.0 and SSL 3.0 should already be disabled, if they are not disable them immediately! The following link from Microsoft provides the registry keys and powershell needed to disable all of these services. Make sure these changes are being made on all Web Application Proxies (WAPs) and ADFS servers.
Step 2: Reboot all Virtual Machines / Servers
This step is pretty self explanatory.
Step 3: ADFS is Br0ken, Oh Noes!!
Disabling TLS 1.0 will break ADFS 3.0, more specifically it breaks the connection between the WAPs and the ADFS servers. This is easy to fix though.
Following this article on re-establishing the trust: https://blog.rmilne.ca/2021/11/16/ad-fs-web-application-proxy-re-establish-proxy-trust/
Quick Recap: Change this registry value on the primary Web Application Proxy:
HKLM\Software\Microsoft\ADFS\ProxyConfigurationStatus –> 1
This value normally has a value of 2 (which means configured), change it back to 1, and this change does not even require a reboot.
Open up Server Manager and launch “Remote Access Manager”, select “Web Application Proxy” and put in the required information to re-establish the trust.
You may need to reboot the WAPs one more time, I had to.
Step 4: Verify SSL Services are Correct
Once all services come back up, it would be a good time to verify that all the services you think you turned off are actually off. A SSL Server Test tool would be great for that, like the one by SSL Labs: https://www.ssllabs.com/ssltest/
Step 5: You may need to correct internal .NET Applications pointing to ADFS
Internal .NET Applications may start failing. If you start to receive error messages like “Authentication failed because the remote party has closed the transport stream”, it just means you are not specifying TLS 1.2.
There is a great article on Microsoft Docs here that explains the situation and the fix: https://docs.microsoft.com/en-us/answers/questions/400152/authentication-failed-because-the-remote-party-has.html
The developers will just need to specify the SecurityProtocol in their application.
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
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.