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
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:
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.
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
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)
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.
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.
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.
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
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.