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

I had a situation where the Delete button was grayed out  / disabled when attempting to delete a user account on a Windows 7 machine. This occurred when logged in with an account with full administrator privileges.  The solution was to first navigate to the c:\Users\folder, find the desired user’s folder and try to enter it.  Windows should then prompt you:
You don’t currently have permission to access this folder. Click Continue to permanently get access to this folder.
Once that is complete and you can access the folder, you should then be able to go back to Advanced System Settings and delete the user profile.

Edit: 29-Jan-2020
If you still have the issue, make sure your account has full administrative privileges (e.g., if you had to elevate your domain account) and then reboot the system.

I recently acquired some SAS hard drives but when installed in a Norco SATA/SAS backplane the activity light was always on when idle (for this backplane, the light was a constant green). This behavior was opposite of the SATA drives installed in the same backplane where the activity light was off when idle. When the SAS drives were active then the activity LED was consistent with the SATA drives and blinked as one would expect.

This behavior seems not uncommon with enterprise grade SAS drives but turns out it can be modified by using the program sdparm using most Linux distributions (this example was using Ubuntu). If you want to modify the behavior of the activity light, follow these steps.

If sdparm is not already installed :

sudo apt install sdparm

To turn off the activity light while idle, we need to modify the Ready Light Meaning (RLM) field in the HDD firmware. To read the current setting in the firmware:

sdparm --get=RLM /dev/ABC

where ABC is the SAS device name (e.g., /dev/sda).
Note: if in doubt about the device name, you can get a list of devices with the command: smartctl –scan

You should then get an output from sdparm similar to the below:

RLM 0 [cha: y, def: 0, sav: 0]

Note: If you specify the wrong device (e.g., a SATA drive instead of a SAS drive) you may get an output similar to the below:
RLM not found in Protocol specific port (SAS) mode page

To flip the behavior of the activity light, issue this command:

sdparm –set=RLM /dev/ABC

This immediately turned off the light for an Hitachi Ultrastar 7K3000 and you can verify it in the device’s firmware by issuing the same get=RLM command as before.

The output should then look similar to the below:

RLM 1 [cha: y, def: 0, sav: 0]

This change is not permanent so it would revert back on power cycle. To make the page field persistent, add the save flag the command we issued previously:

sdparm --set=RLM --save /dev/ABC

The activity light should now be permanently off while idle (or until you revert the change with sdparm). The output of the get=RLM command should now look similar to the below:

RLM 1 [cha: y, def: 0, sav: 1]

If you need to flip the activity light for other devices you can do it all in one step with the save flag.  If you want to revert the change for a device, issue this command:

sdparm --clear=RLM /dev/ABC

The change was again instant for this particular drive. To verify it in the firmware, the output of get=RLM should then be:

RLM 0 [cha: y, def: 0, sav: 1]

To commit the change, add the save flag again:

sdparm --clear=RLM --save /dev/ABC

The output of get=RLM should now be:

RLM 0 [cha: y, def: 0, sav: 0]

Now you can repeat the set/save or clear/save command as desired for each SAS device.