These are the steps taken from my notes to reset/change an administrator password on a Windows Server 2003 R2 Standard install. I used Ubuntu and chntpw and the Windows partition was not encrypted.

1. Boot from Ubuntu live disk
2. Switch to root

   sudo -i

3. Add the repository that has chntpw

   apt-add-repository universe

4. Install chntpw

   apt-get install chntpw

5. Make a folder to mount the Windows partition drive

   mkdir /winmount

6. Mount the partition (search available partitions using Gparted)

   mount /dev/xxx /winmount

7. List all users

   chntpw -l /winmount/WINDOWS/system32/config/SAM

8. Modify the desired user
   chntpw -u username /winmount/WINDOWS/system32/config/SAM
9. Clear (blank) the password of the user, option 1.  Then unlock if necessary, option 2.
10. Quit and write the changes
11. Unmount and reboot

    unmount /winmount

This affects the minimum and maximum speeds allowed for throttling of reshaping and checking activities of mdadm.

To monitor the current speed
sudo cat /proc/mdstat

To temporarily adjust the speed use the commands below. They will reset to defaults on the next reboot. The speed, x, is a number in kbytes/seconds.
echo x > /proc/sys/dev/raid/speed_limit_min
echo x > /proc/sys/dev/raid/speed_limit_max

To make the change permanent and persist after a reboot modify this file:
/etc/sysctl.d/99-openmediavault-mdadm.conf
Add these lines where the speed, x, is a number in kbytes/seconds.
dev.raid.speed_limit_min = x
dev.raid.speed_limit_max = x

Note: the default setting for a fresh install of OMV version 6.0 is only a minimum speed with a value of 10000 (contrary to the comment in the config file with a value of 1000).

First error We’re sorry, we can’t continue because we weren’t able to download a required file. Please make sure you’re connected to the internet or connect to a different network, then try again. Error Code: 30182-1011

Removing

I was getting a repeating error in the log file when trying to download using the ODT (setup.exe /download rather than /configure):

Nexus Transport xxxxx Monitorable MsoGetRemoteHostNetworkStatusWithUrlType failed {“RemoteHost”: “https://nexus.officeapps.live.com”}

Ultimately it would fail with the message: We’re sorry, we  had a problem installing your Office program(s). Error Code: 30015-1007

Folder size of Office/Data would increase to about 300-400MB.

Root cause was an old version of the tool’s setup.exe (I was running 16.0.7614.3602). I downloaded the latest ODT and then the O365 download would complete without error. At the time of this post the latest version was 16.0.12624.20290.

When trying to perform apt-get update on OMV 4.1.27-1 (Arrakis), I received the following error

Hit:10 https://packages.openmediavault.org/public arrakis InRelease
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fd4ea277598>
Traceback (most recent call last):
File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fd4ea277598>
Traceback (most recent call last):
File "/usr/lib/python3.5/weakref.py", line 117, in remove
TypeError: 'NoneType' object is not callable
Reading package lists... Done

The fix is to edit and replace 2 lines in weakref.py

nano /usr/lib/python3.5/weakref.py

Old line 109:
def remove(wr, selfref=ref(self)):
New line 109:

def remove(wr, selfref=ref(self), _atomic_removal=_remove_dead_weakref):

Old line 117:
_remove_dead_weakref(d, wr.key)
New line 117:

_atomic_removal(d, wr.key)

You must be careful to replace only the specific text and not modify whitespace, otherwise you may receive the following error during the next update:
TabError: inconsistent use of tabs and spaces in indentation

The source for the above fix: https://forum.openmediavault.org/index.php?thread/19658-upgrade-debian-9-and-4-x/&postID=155621#post155621

An alternative way to fix weakref.py is to replace the entire file:

wget -O /usr/lib/python3.5/weakref.py https://raw.githubusercontent.com/python/cpython/9cd7e17640a49635d1c1f8c2989578a8fc2c1de6/Lib/weakref.py

The source is from this post: https://forum.openmediavault.org/index.php?thread/19658-upgrade-debian-9-and-4-x/&postID=196631#post196631

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.