All posts by bsdman

Currently working as an IT Manager. Worked for an OIT company as a Network Engineer in 2011. Worked for a Medical IT company as the Network Administrator 2009-2011. Worked as the Senior Systems Administrator at a computer reseller from 2005-2009. Worked as a Computer Consultant for several small companies from 2007-2009. Worked as a Computer Technician at a computer reseller from 2002-2004.

U6 Pro Unifi Not Updating

I’ve had many access points from Unifi over the years. Updating from the controller is generally a painless operation, and only rarely have I ever needed to utilize the CLI to make any changes (mostly set-inform related).

However, when attempting to update the firmware of my Unifi systems (U6-Pro, US-24-250W, US-8-60W, UAP-nanoHD, and U6-Pro), I got stuck on the U6-Pro. I would click on upgrade the firmware and then the access point would get stuck on the blue/white blinking LED for hours. I even let it sit there overnight just to see. For the record, I was attempting to upgrade from 6.0.14 to 6.0.15 at the time, and it was not happy. Unplugging from power and then plugging back in would get me back to the 6.0.14 version, so no harm no foul.

I figured it would get fixed with a new release of the controller as well as a firmware release to 6.0.18. Wrong. Same issue. I even attempted to CLI it by logging in via SSH and running the “upgrade” command. No dice. Hard reboot and it’s back on 6.0.14.

Swannman had the same issue posted on the unifi forms, and UI-Glenn gave an updated command for me to try:

curl -o /tmp/fwupdate.bin && fwupdate.real -m &

Magically this worked and the controller reads it just fine. Posting for future sake of my sanity.

OPNSense Booting.. Stuck

Trying to install OPNSense on an older Alibaba system I had laying around, and I noticed that I couldn’t install due to the system freezing at the “Booting…” prompt (post kernel loading).

When booting, press “3” to Escape to loader prompt.

  • Type set kern.vty=sc
  • Press enter
  • Type boot
  • Press enter

Assuming the system boots and you can install, you’ll have to edit a file in the /boot directory to get the system to boot with future restarts.

  • cd /boot; press enter
  • vi loader.conf.local; press enter
  • i
  • kern.vty=sc
  • Press esc
  • :wq!; press enter

I should note that this fix was permanent between reboots and updates until just recently; patched a remote system of similar specs and it required the creation of the loader.conf.local file again.

BGInfo Auto Start All Users

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!

Windows Certificate AUthority SAN

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.

HAProxy and Kace SMA

Running Kace SMA (K1000) version 11.0.273. Wanted to run it behind a reverse proxy so it wasn’t directly exposed to the internet. Generally speaking, you really don’t want things like webservers directly exposed to the internet for obvious reasons, but KACE has been really adamant about security and running it in a DMZ and it hasn’t had any known intrusions to date.

In any case, I decided to move it out of the DMZ and run HAProxy in its place. I have my outside-of-this-documents-scope reasons. However, KACE SMA 10.x didn’t play nicely with reverse proxies even with legit SSL’s installed (you can read about konea certificates vs web ones on the kace support pages).

Upgraded to version 11 and from there it splits into two – konea certificates are unpublished but necessary, and then our web certificates for all other traffic. And yes, all traffic does terminate to port 443, but the konea side changes to a new port.

        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        lua-load        /etc/haproxy/acme-http01-webroot.lua

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # See:
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

        log     global
        mode    tcp
        option  tcplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend http-in
        bind *:80
        acl url_acme_http01 path_beg /.well-known/acme-challenge/
        http-request use-service lua.acme-http01 if METH_GET url_acme_http01

frontend sma
#       bind *:443 ssl crt /etc/letsencrypt/live/pem/
        bind *:443
        tcp-request inspect-delay 5s
#       tcp-request content capture req.ssl_sni len 25
        tcp-request content accept if { req_ssl_hello_type 1 }

        use_backend sma_agent if { req_ssl_sni konea }
        use_backend sma_webui if { req_ssl_sni mykacesite.domain.tld }
        default_backend sma_webui

backend sma_webui
        server sma_apache

backend sma_agent
        server sma_koneas

I should point out that I also am utilizing letsencrypt for the web portion, however, by switching to tcp mode instead of http it bypasses that requirement. TCP mode is REQUIRED for the konea portion to actually function.

Windows Server time ntp

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 instead of the local server.

Open an Administrator command Prompt

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

Disable Windows Defender AV on Server 2016+

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.