These are the steps to crossflash a Dell 0WFN6R (SAS9341-8i) to an LSI 9300-8i. At the time of this guide the latest firmware available is P16.

All files needed for this guide can be downloaded here. The firmware and BIOS files were sourced directly from Broadcom’s website (Installer_P16_for_UEFI.zip and 9300_8i_Package_P16_IR_IT_FW_BIOS_for_MSDOS_Windows.zip specifically).

For UEFI method you will use sas3flash.efi.  You can perform this same procedure with BIOS method by instead using sas3flsh.exe. However if in BIOS mode you receive ERROR: Failed to initialize PAL. Exiting Program, then you must switch to the UEFI method.

1. Make a record of the Assembly number and SAS Address from the stickers on the back of the card
2. Create your bootable USB disk with Rufus, formatted as FreeDOS.  Extract the files from this guide to the root of the drive.
3. Place jumper on TP12 located on the front rear of the card near the two SAS ports. Otherwise you will receive the error: No Avago SAS Adapters found! Limited Command Set Available! when trying to use SAS3Flash.
4. Boot from the USB disk either UEFI or BIOS. For BIOS method substitute sas3flsh.exe for sas3flash.efi in all steps below.
5. Navigate to the SAS3Flash binary on the USB drive
6. Confirm the the 9341 card is detected:

   sas3flash.efi -list

7. Perform preliminary flash of the firmware:

   sas3flash.efi -noreset -f SAS9300_8i_IT.bin

8. Once you receive a confirmation that the flash was successful, power off the system and remove the jumper. Reinstall the card and boot off the USB drive.
9. Wipe the card :

   sas3flash.efi -o -e 6

10. Flash the firmware:

    sas3flash.efi -f SAS9300_8i_IT.bin

11. At this point you can stop if you don’t want any BIOS on the card.  It is needed if you want to boot from a drive attached to the card.
12. Flash the BIOS:

    sas3flash.efi -b mptsas3.rom

13. Flash the UEFI rom:

    sas3flash.efi -b mpt3x64.rom

14. Program the SAS address (don’t include hyphens as they will be added automatically): Note – you can perform this later at any time.

    sas3flsh.exe -o -sasadd XXXXXXX

15. Program the board assembly (you DO need to include hyphens with this):
    Note – you can perform this later at any time.

    sas3flsh.exe -o -assem XXXXXXX

16. Verify your results:

    sas3flash.efi -list

17. You should see your SAS address, firmware version 16.00.10.00,  BIOS version 08.37.00.00, UEFI BSD Version 18.00.00.00 and your board assembly.  Crossflashing is now complete.

Recent experience with an Aquantia AQtion AQC108 5G network card that was integrated in a motherboard (Supermicro X11SRA-F).    Plugging in an ethernet cable would not activate the port (status LEDs would not light up on either the NIC or the switch), so the NIC appeared dead.  However when booting into ESXi 6.7 the NIC would be detected as AQC108 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] but not be listed under Networking – Physical NICs indicating that no driver was found.  Turns out this NIC needs an OS that has a driver installed before the LEDs will activate. For example with the ESXi host machine the NIC was set up as Passthrough to a guest running Windows Server 2019 (which has the drivers built in).  The link LEDs then began working and the NIC functioned normally in the Windows guest.

Upgraded a Supermicro CSE-836 from 3 pin fans to 4 pin PWM fans. Here is the before and after matrix of part numbers:

Note: the above matrix was for replacements in kind. The latest CSE-836 has these fans:
Middle: FAN-0126L4 (Qty 3)
Rear: FAN-0125L4 (Qty 2)

Note: an alternative 4 pin hot swap cable is CBL-0216L

When trying to update/upgrade ESXi 6.7.0 Update 3 (via software profile update command) you may run into the following error below. This was a host running specifically Update 3 build 15018017 trying to update to build 15160138.

[InstallationError]
[Errno 28] No space left on device
vibs = VMware_locker_tools-light_11.0.1.14773994-15160134
Please refer to the log file for more details.

When attempting to update to build 16075168, the failure is related to: vibs = VMware_locker_tools-light_11.0.5.15389592-15999342, you can substitute this version into the commands below, keeping everything else the same.

First make sure you have Swap enabled on a datastore.  In vSphere Web Access, navigate to Host->Manage->Swap and choose a datastore.

Then manually install the VMware_locker_tools package by following these steps via SSH on the host:

cd /tmp

wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/tools-light/VMware_locker_tools-light_11.0.1.14773994-15160134.vib

esxcli software vib install -f -v /tmp/VMware_locker_tools-light_11.0.1.14773994-15160134.vib

Once you receive verification that the Operation finished successfully, try the profile update command again to patch ESXi.

When trying to update a CentOS 7 system after an extended amount of time, I ran into this error:

Downloading packages:
warning: /var/cache/yum/x86_64/7/ius/packages/yum-plugin-replace-0.2.7-1.ius.el7.noarch.rpm: Header V4 RSA/SHA256 Signature, key ID 4b274df2: NOKEY
Retrieving key from file:///etc/pki/rpm-gpg/IUS-COMMUNITY-GPG-KEY

The GPG keys listed for the “IUS Community Packages for Enterprise Linux 7 – x86_64” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.

Failing package is: yum-plugin-replace-0.2.7-1.ius.el7.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/IUS-COMMUNITY-GPG-KEY

In this example I was trying to install the package yum-plugin-replace, but a similar error can occur with other packages you may have installed as well.  The solution was to reinstall the IUS repository (https://ius.io/setup)

sudo yum install \
https://repo.ius.io/ius-release-el7.rpm \
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Once complete retry the update

sudo yum update

At which point you may run into the below message.  The fingerprint should match https://ius.io/keys, then type Y to finish.

Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-IUS-7
Importing GPG key 0x4B274DF2:
Userid : “IUS (7) <[email protected]>”
Fingerprint: c958 7a09 a11f d706 4f0c a0f4 e558 0725 4b27 4df2
Package : ius-release-2-1.el7.ius.noarch (installed)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-IUS-7
Is this ok [y/N]:

Edit: fixed a typo in the command in step 3

For Windows Server 2012 R2 it’s not possible to change the alias of an existing RemoteApp. However it is possible to set a custom alias when creating a new RemoteApp using PowerShell.  The steps:

1. Unpublish the existing RemoteApp
2. Start PowerShell
3. Issue the following command to publish the new app with your desired alias. Note that folder name is optional. The collection name you can find in Server Manager under Remote Desktop Services -> Collections.

   New-RDRemoteApp -CollectionName "YourCollectionName" -Alias "YourAlias" -DisplayName "YourDisplayName" -FolderName "YourFolderName" -FilePath "C:\path\to\executable.exe"

References:

https://learn.microsoft.com/en-us/powershell/module/remotedesktop/new-rdremoteapp?view=windowsserver2016-ps

When attempting to change the timezone in Windows Server 2019 you may run into the following problems:

• The change button in Windows Settings for Date & Time is greyed out
• Receive an error message when clicking Change Time Zone button in Control Panel Date and Time, even though you are an administrator:
  Unable to continue
  You do not have permission to perform this task. Please contact your computer administrator for help.

The solution is to force the Control Panel Date and Time applet to run separately with administrator privileges:

1. Click Start
2. Type timedate.cpl
3. Right click on the resulting Control panel item
4. Choose Run as administrator
5. Now you can adjust the time freely

On a Ubuntu 18.04 bionic system I suddenly started getting errors with certbot for one domain while certificates for other domains on the same system were renewing without errors.  Performing a –dry-run would result in various error messages, such as:

DNS problem: SERVFAIL looking up CAA for …

Remote PerformValidation RPC failed

Unfortunately, an error on the ACME server prevented you from completing authorization. Please try again later.

Running certbot renew with the additional flag –debug-challenges and inspecting the letsencrypt.log revealed the following:

Invalid Content-Type header on POST. Content-Type must be “application/jose+json”

The solution was to simply update certbot on the system

sudo apt-get update
sudo apt-get upgrade