When reviewing the share permissions on a printer added to Windows Server 2019, it had a principal present with the following name:

S-1-15-3-1024-4044835139-2658482041-3127973164-329287231-3865880861-1938685643-461067658-1087000422

This SID was present on two different servers and permissions allowed were set for Print and Manage documents. I could not find this specific SID listed but there are two articles available linked below that present more information about SIDs (this looks to be a capability SID). No action was taken so this is just for information.

https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
https://support.microsoft.com/en-us/help/4502539/some-sids-do-not-resolve-into-friendly-names

This was a Windows Server 2019 that would log the following error every hour:

The atc service failed to start due to the following error:
Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

Inspecting the registry, the following was found:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atc

which had an ImagePath with file C:\Windows\System32\drivers\atc.sys

Under the Properties-Details menu of atc.sys, its description indicated it to be associated with BitDefender Active Threat Control Filesystem Minifilter (AntiVirus), however this was not currently installed on the server.

The service was uninstalled using the command prompt:

sc delete atc

To find other Bitdefender leftovers, add Product Name to the Windows  file explorer columns then sort and look for Bitdefender. I found several others:

Trufos.sys (Bitdefender Antivirus Kernel Module)
bddci.sys (Bitdefender BDDCI filter driver)
gzflt.sys (Bitdefender Gonzales File System Driver)
ignis.sys (Bitdefender IGNIS Firewall)

sc delete trufos
sc delete bddci
sc delete gzflt
sc delete ignis

Then reboot to flush the deleted services.

When trying to perform a File Backup job using Veeam Backup and Replication (specifically version 10.0.0.4461) it would randomly fail with An unexpected network error occurred. This backup job was configured to backup a local NFS File Share to a local SMB (CIFS) backup repository. Repeating the job would result in another failure but differing amounts of data being transferred each time.  After the failure, the job report listed items such as NasMaster.ExecuteBackupProcessor and boost::filesystem::status:.

It continued to fail even after setting the Backup I/O control of the NFS File Share to the lowest impact value. To resolve it the backup repository was switched from SMB/CIFS to NFS.  After this change the Backup I/O control setting was also reset back to the default (middle) value.  This solution likely indicates a problem with the destination (backup repository), so if you need to keep it as SMB/CIFS then you can try adjusting the Load Control settings of the repository (right click Properties menu -> Repository). For example try reducing the maximum number of concurrent tasks. If it fails with just 1 task then you may also need to try limiting the data rate.

If you forgot the login credentials for the web account, here is how to perform the reset.

1. Access the VM appliance console
2. Stop the PowerChute service

   /etc/init.d/PowerChute stop

3. Edit the configuration file

   vi /opt/APC/PowerChute/group1/pcnsconfig.ini

4.  In the [NetworkManagementCard] section of the INI file, add the following lines with your desired values:
   username= new user name
   password= new password
5. Save and close
6. Restart the PowerChute service

   /etc/init.d/PowerChute start

A CyberPower CP1500AVRLCD unit originally came with two batteries, B.B. Battery HR1234W with dimensions 6.00 x 2.60 x 3.70 in. (LxWxH).  If you replaced them and forgot how to wire them back up, you can refer to the below diagram:

I had a CentOS 7 system running WordPress and received the warning: WordPress has detected that your site is running on an insecure version of PHP.  The system was running PHP 5.6 which is end of life, so here are the steps I used to upgrade to the latest version recommended by WordPress at the time of this posting (PHP 7.3).

1. If not already installed:

   sudo yum install epel-release

2. Add the IUS repository that maintains updated PHP packages.
   More information can be found at the following site including these commands:
   https://ius.ioFor CentOS 7

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

   For CentOS 6

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

   Note: if you get Error: Nothing to do when  using the above commends it means you may already  have the repository installed and is safe to ignore.

3. Since we are using IUS repository we will use the replace plugin
   More information about this plugin for reference:
   https://github.com/iuscommunity/yum-plugin-replace

   yum install yum-plugin-replace

4.  The next step depends on your specific configuration. If you are on a stock CentOS 7 install you can use

   yum replace --replace-with php73-common php

   Note: if you receive Error: Package ‘php’ is not installed then you are not on a stock install and you must replace php with the specific version you have installed. Inspect the output of the command:

   yum list installed | grep php

   Then perform the yum replace command using the package name you have installed. For example:

   yum replace --replace-with php73-common php56u

   Note: if you receive WARNING: Unable to resolve all providers it probably means identical replacements for all php extensions could not be found which is typical. Press y to continue.

5. This server was running Apache so it needs to be restarted for the new PHP to take effect:

   apachectl restart

6. At this point the WordPress installation was broken: There has been a critical error on your website.   Setting WordPress into debug mode revealed the following Fatal error: Uncaught Error: Call to undefined function json_encode() … /wp-includes/functions.php:3820 To resolve it, install the json extension:

   yum install php73-json

7. Then restart Apache again

   apachectl restart

8. Now WordPress should be functional again and no longer reporting an out of date version of PHP.

Attempting to backup a Windows Server 2012 R2 Server with the Veeam Agent freshly installed and Backup and Replication server version 9.5 (also 10). The administrator credentials for the source server had been added to the destination server (Backup and Replication) and a backup job with type Windows Agent Backup was created. When running the job it would fail with error: Processing ServerName Error: Failed to connect to x.x.x.x:11731

The reason is because the source Windows Server was not properly added to the infrastructure of the destination Backup and Replication server. Checking the Programs and Features installed on the source Windows Server, only Veeam Agent for Microsoft Windows was listed. The Veeam Installer service was missing, which is triggered to install by the destination Backup and Replication server.

To resolve it, from Backup and Replication server navigate to Physical Infrastructure, Manually Added. Then perform a Rescan. Once complete you should see a confirmation that the Backup agent is installed on the source Server. Checking Programs and Features of the source Windows Server 2012 R2, the Veeam Installer Service should now be listed as installed.  The backup job on the destination server can now be restarted and should complete without the  previous failed to connect error.

Update 09-May-2020: The original script didn’t really work so I have commented it out.
Update 11-May-2020: Added method to search by Volume Name.

There are several reasons you may want to have ESXi rescan iSCSI at boot. For this example a FreeNAS guest VM was running an iSCSI target and sharing it back to the ESXi host. ESXi was then using it as a datastore with other VMs on it that also needed to be autostart. The trick is to start the FreeNAS guest and give it enough time to boot before letting ESXi proceed to the autostart step.

This script should be added to the following file in ESXi (using vi) so that it is preserved by ESXi upon reboot.
/etc/rc.local.d/local.sh
Note: the last line of this file should be preserved (exit 0).

#Establish our timer
count=0

#Power on the guest VM with the specified Vmid
#use the command vim-cmd vmsvc/getallvms to find which Vmid to use
vim-cmd vmsvc/power.on 1

#Now continuously rescan for the iSCSI device until it is found
#or the maximum time of 10 minutes is reached.
#This command will search all Logical Devices for one that has "Vendor_Name" in the Display Name (e.g., FreeNAS)
while ! esxcfg-scsidevs -c | grep -q 'Vendor_Name'

#Alternatively if you have multiple iSCSI targets that share the same Display Name
#(iSCSI Vendor) then you may want to instead search by Volume Name.
#This method allows you to single out a specific server since Volume Name is user configurable.
#The command below will search for the volume name 'Your_custom_volume_name' and that Mounted status is true.
#while ! esxcli storage filesystem list | grep -q "Your_custom_volume_name.*true"
do
    #print some debugging info to the syslog
    logger "local.sh: Forcing rescan since iSCSI target is not yet available..."
    
    #Rescan SCSI HBAs to search for new Devices, remove DEAD paths and update path state. 
    #This operation will also run an claim operation equivalent to the claimrule run command and a filesystem rescan.
    esxcli storage core adapter rescan --all

    #Now wait (in seconds) before checking again
    sleep 30

    #Increase the timer
    count=`expr $count + 30`

    #Check if maximum time has been reached (in seconds)
    if [ $count -ge 600 ]
    then
       logger "local.sh: Aborting, maximum time reached while searching for iSCSI target."
       break
    fi
done

logger "local.sh: Search time for iSCSI target was" $count "seconds."

#-------------- Old script is below, do not use

#Adjust the delay in seconds as needed to allow time for NAS to boot up fully
#sleep 300

#Enable iSCSI Initiator and rescan for iSCSI specific LUNs.
#esxcfg-swiscsi -e
#esxcfg-swiscsi -s

#Search for new VMFS datastores. If a new datastore has been detected, it is mounted in /vmfs/volumes/
#vmkfstools -V

#another delay just to be sure
#sleep 10

#Run the ESXi autostart script again to start all VMs that are on the datastore
#sh /usr/sbin/vmware-autostart.sh start

BuddyPress @mentions were working perfectly within WordPress posts and comments however not in bbPress.

This is one solution to get @mention user lookups and an email notification when used in a topic or thread reply.  However a notification is not logged within BuddyPress.

First create or modify the following file in your WordPress install
/wp-content/plugins/bp-custom.php

Sources:

bp-custom.php

https://gist.github.com/imath/5a3c4ac645ec765863f2

<?php
function custom_bbpress_maybe_load_mentions_scripts(
$retval = false ) {
if ( function_exists( 'bbpress' ) && is_bbpress() ) {
$retval = true;
}
return $retval;
}
add_filter( 'bp_activity_maybe_load_mentions_scripts', 'custom_bbpress_maybe_load_mentions_scripts' );

Then you will need to install the bbPress Toolkit plugin for WordPress.

Once activated navigate to Tools -> bbP Toolkit in WordPress Dashboard. Then choose Extras at the top and confirm mentions are enabled.

A second option is to use the bbp Mentions Suggest plugin available at this website:

bbp Mentions Suggest

These are the minimum steps I needed to get WordPress running on Ubuntu Server 18.04. It is based on the below guide at the time of this writing:

How to install WordPress

1. During the install and setup of Ubuntu Server 18.04, the only option I chose beyond the defaults was to install Open SSH server but is not required depending on your needs.
2. sudo apt install apache2
3. Optional: if you want SSL support
   sudo a2enmod ssl
4. sudo apt install mysql-server
5. Set up a MySQL user and database for WordPress to use by using the debian-sys-maint user:

   sudo cat /etc/mysql/debian.cnf

   mysql -u debian-sys-maint -p(copy/paste the password from the previous cat output)

   CREATE USER 'username'@'localhost' IDENTIFIED BY 'password'; CREATE DATABASE your_dbname DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; GRANT ALL PRIVILEGES ON your_dbname.* TO 'username'@'localhost'; FLUSH PRIVILEGES; quit;

6. sudo apt install php libapache2-mod-php php-mysql php-gd php-xml php-mbstring
7. By default apache will look at /var/www/html location for your WordPress install, but you can modify it with these steps
   sudo nano /etc/apache2/sites-enabled/000-default.conf
   in this example we will change DocumentRoot line to be /var/www/wordpress
8. Optional: if you want SSL support add this entire block<VirtualHost *:443>
   ServerAdmin [email protected]
   DocumentRoot /var/www/wordpress
   SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
   SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
   </VirtualHost>
9. cd /var/www
10. sudo curl -O https://wordpress.org/latest.tar.gz
11. sudo tar xfvz latest.tar.gz
12. sudo cp wordpress/wp-config-sample.php wordpress/wp-config.php
13. sudo nano wordpress/wp-config.php
14. Modify database_name_here, username_here, password_here
15. sudo chown -R www-data:www-data /var/www/wordpress
16. Allow .htaccess permissions in Apache2 (otherwise changing the Permalinks settings in WordPress will result in 404 errors, as well as plugins that rely on subfolders to serve content).sudo nano /etc/apache2/apache2.conf
    Find the section where Directory parameters are specified and add the following block:
    <Directory /var/www/wordpress/>
    Options Indexes FollowSymLinks
    AllowOverride All
    Require all granted
    </Directory>sudo a2enmod rewrite
17. If you need to adjust maximum upload filesize and post size for PHP it is found in /etc/php/7.2/apache2/php.ini
    Then change upload_max_filesize and post_max_size
18. sudo systemctl restart apache2
19. Done