Windows 2000, XP, and even Vista all would install without any need for an active internet connection. Starting with Win7 – and running through 8, 8.1, and 10 – MS was prompting users to connect to the internet in order to a) create a Microsoft online account and b) patch the system before you really start using it. It was an optional step that was easily bypassed (although on 10 they started “hiding” the option). But with Windows 11… not so much.

I should also note that the Pro, Education, and Enterprise variants are not impacted by this problem.

During the installation/configuration steps when setting up your Out Of Box Experience (OOBE comes back in just a few moments), simply follow along once you get to the Network Selection screen options.

Shift + F10
OOBE\BYPASSNRO
<enter>

Shift + F10 will open a command prompt window. OOBE\BYPASSNRO command sets the Out of Box Experience (see, I told you it would come back) to bypass the need for networking and registration options.

The computer will automatically reboot at this point and you’ll be able to continue with the initial setup steps and get to you Win 11 desktop without registering or connecting to a network. Huge benefit when setting up a workstation while not near an active network drop – or when I had a rather lengthy layover at an airport and wanted to pass the time on my dev laptop.

I’ve used BGInfo plenty of times in my past – it’s been a pretty good tool at providing information to technicians in order to assist with end-users’ woes. But overall I’ve only really used it on servers – it’s been helpful to color coordinate based on PRODUCTION vs non-production systems (eg RED and BOLD lettering for the hostname).

I also had a login script that would automatically run BGInfo from our sysvol scripts folder on users’ workstations. However, due to remote users – especially in this Covid time – the login script would not run/update accordingly. I needed to find a new way.

At first I looked at registry edits and tried to run in HKLM\Software\Microsoft\Windows\CurrentVersion\Run, but with my syntax of:

"C:\scripts\BGInfo\workstation.bgi /timer:0 /silent /nolicprompt"

On the workstation BGInfo would open with a default settings rather than my workstation.bgi ones. I’m fairly certain I had the bgi associated properly, but I didn’t look further into it as I went in a different direction: Scripts.

• Navigate to the all-users Startup
  • C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
• Create a file called hidden.vbs and populate with
  • Set MyScript = CreateObject("WScript.Shell")
  • MyScript.Run "c:\windows\bginfo\bginfo.bat", 0, False
• Copy the BGinfo64.exe and associated configuration.bgi to
  • C:\Windows\bginfo\
• Create a file called bginfo.bat in this same directory above
  • @echo=off
  • reg add HKU\.DEFAULT\Software\Sysinternals\BGInfo /v EulaAccepted /t REG_DWORD /d 1 /f
  • pushd %~dp0
  • pushd c:\windows\bginfo
  • cls
  • Bginfo64.exe configuration_client.bgi /TIMER:00 /nolicprompt
  • popd
  • exit
• Log off/Log on to see the changes

The only issue with this avenue is that if we ever decide to update our .bgi configuration file, we’d have to push updates to all systems to have them reflect the changes. Good thing for RMM tools!

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.