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