Installed a new certificate authority on Windows Server 2019 and was attempting to utilize the http://localhost/certsrv to issue a new certificate to my website (RDS, also on 2019). It wasn’t going well.

First I opened the certificate authority and noticed that Certificate Templates was not showing up as a subdir. That was fixed by removing the certificate authority and reinstalling as an Enterprise Standalone CA (you may be able to get to there by changing the DWORD value from HKLM\SYSTEM\CurrentControlSet\services\Certsvc\Configuration\YOURCAFQN\CAType to “0”.

Then I went to Certificate Templates and duplicated the Web Server one, right-click Certificate Templates and select Manage, then checkbox for “Allow private key to be exported” on the Copy of Web Server template.

I forgot to then right-click again on Certificate Templates and select New > Certificate Template To Issue, then select the Copy of Web Server I created earlier. So I fixed that too.

I probably changed the permissions of the template to include Authenticated Users to be able to enroll/read/write certs prior to all that published above.

Then I navigated to http://localhost/certsrv and clicked through:

• Request a certificate
• Advanced certificate request
• Create and submit a request to this CA
• “Yes” to the this website is attempting to perform a digital certificate operation
• Certificate template drop down to my Copy of Web Server
• Name of rds.domain.tld, keysize of 2048, Mark keys as exportable, attributes “san:dns=rds.domain.tld&nameofserver.domain.tld” without the quotes, friendly name of rds.domain.tld
• Submit
• Install
• Open MMC for Certificates (personal/user)
• Under the Personal > Certificates store, you’ll find your installed certificate
• Right-click and export this cert with key; I used a passphrase

From here I added it to the RDS system certificates (my RDS 2019 server has all roles of Gateway Broker and Session host in-one).

Unfortunately I noticed that my SAN (subject alternate name) wasn’t working on the certificate. There’s a command to address the attribute required to support SANs:

• Open command as an administrator (on the Certificate Authority)
• certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
• Restart the Active Directory Certificate Services service (or the entire server if you want)
• Re-run the aforementioned SAN cert commands and now export; profit.

I had a pair of domain controllers that refused to cooperate with regards to maintaining the correct time. Long story short, I ended up changing the time config to point to time.nist.gov instead of the local server.

Open an Administrator command Prompt

1. w32tm /config /manualpeerlist:time.nist.gov /update /syncfromflags:manual /reliable:yes
2. w32tm /query /status
3. w32tm /resync

Starting with Server 2016 (and continuing with 2019), Microsoft changed the way their Windows Defender works when installing a 3rd party AV solution. Namely they made it so that the installation of the 3rd party AV no longer disables the built-in Windows Defender.

I actually found this out when I was receiving CPU alerts for a domain controller. Recently added monitoring and alerting to an existing site and found that Sophos AV was competing with Windows Defender and both scanning at the same time. Yay.

Open a Powershell command as Administrator:

Uninstall-WindowsFeature -Name Windows-Defender

Then reboot the server.

It’s been a while since I was in a role that required me to worry about Windows activation’s, but yet here I am.

User entered a ticket saying they had < 30 days remaining on their Windows activation and to contact their sys admin team for support.

Running the following commands without the prepend “cscript” will show the active user interface a vbscript popup. Since I like to perform my actions behind the scenes, cscript allows me to have a remote command prompt with no user interaction required.

Check current settings

cscript slmgr.vbs -dli

Change KMS Server

cscript slmgr.vbs -skms dnsnameofyourserverhere.tld

Activate

cscript slmgr.vbs -ato

Trying to patch one of my administrative servers and was receiving that error message. Server is 2016 standard, domain-joined, and there is WSUS in the environment along with the associated GPO’s for WSUS use.

Looks like this error is/was received due to the fact that my WSUS server was experiencing some issues.

• Log into WSUS
• Open IIS Manager
• Navigate to Server Name > Application Pools
• Find WsusPool
• Start (or restart) this pool

In my case the pool had stopped due to an issue encountered when running a WSUS cleanup script. Starting it and then re-running the update check (retry button), yielded much better results.

Current employer has 3 forests, 3 domains, and 2 WSUS servers. During Covid (operationally speaking anyway), we’re in a 95% work-from-home status. One of our WSUS servers at some point in time decided to fill up its disks with updates. At another point in time, no one on the team thought it would be a good idea to setup monitoring or alerting for this system. Yay. Long story short, I have a love/hate relationship with WSUS.

For on-prem systems it works fairly well. GPOs put systems into specific groups (Workstations, Servers, Pilot Groups, etc), and an-eventually-implemented naming convention will allow IT Personnel to easily identify DEV, ADM, and PRD systems at a glance. Approving updates, pushing updates, and reporting updates all works.

What doesn’t work, however, is the automatic installation of updates. This post will turn into 2 posts: 1) Server-related, and 2) Workstation-related. The workstations, especially those that are remote, aren’t patching themselves on the regular. Probably because the users don’t VPN in often (or long enough) AND whomever set WSUS rules up didn’t specify an install-by required date for updates. Users are lazy and don’t like to reboot (myself included), so this just compounds the issue.

However, this post was more for the Server updates path. WSUS was setup to download patches, but the GPO for servers indicates that at no time will the patches be installed on servers. The previous regime had used batchpatch for that purpose. I’ve used PDQdeploy – SSDD. But since I said “previous regime”, and the last member of that batchpatch crowd left over a year ago, we’ve been woefully underpatched since pre-Covid.

Enter PowerShell. Note: I may clean this up a bit, but for now it’s the messy workthrough.

On EVERY managed system you need to have the following pre-requisites:

• An Administrator account
• WSMan configured to allow the host(s)
• WinRM configured
• PSWindowsUpdate PS Module

1. Open PowerShell as an Administrator
2. winrm /quickconfig
3. Set-Item WSMAN:\localhost\client\trustedhosts -Value *
4. Install-Module -Name PSWindowsUpdate

If the PSWindowsUpdate fails to install it’s generally due to the fact that you’re running PS 5.2 or below and it’s failing TLS requirements to run NuGet. Enable strongencryption on powershell, restart powershell, and re-run the PSWindowsUpdate to continue.

• Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
• Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Now we want to create the PS1 file. I located this in my C:\scripts directory on a domain controller because it’s easier that way.

I’ll eventually remove the credential ask (and hardcode one in) and also have it pull from a comma delaminated file listing all of the required servers. Perhaps I’ll have it ask “which domain” with selections 1 to 3, then “enter credentials for XYZ domain”.

From here we want to save that PS1 file and then run it from the domain controller. Right-click run with powershell. Follow along. I should note that I have the following auto-admin code at the top of the script:

Check for run as administrator
 param([switch]$Elevated)
 function Test-Admin {
     $currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
     $currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
 }
 if ((Test-Admin) -eq $false)  {
     if ($elevated) {
         # tried to elevate, did not work, aborting
     } else {
         Start-Process powershell.exe -Verb RunAs -ArgumentList ('-noprofile -noexit -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
     }
     exit
 }

Look for updates to this post for the workstations or servers. Or not. I get lazy sometimes.