We had Project Professional (specifically 2016 version 1908) running on Windows Server 2012 R2.  Initially Project was installed with SharedComputerLicensing enabled. Later we reinstalled it via Office Deployment Tool and shared computer activation disabled in order to utilize volume licensing (rather than subscription).

The problem was a user was getting a license error loop that would repeat every time Project was launched. Project was still usable in this state, but the error was causing confusion. Uninstalling Project and installing fresh did not resolve the issue.

We noticed you just updated your license. Please reboot Microsoft Project for the changes to take effect.

The root cause was this particular user had run Project in the past when it had been installed with SharedComputerLicensing enabled.   Deleting the user profile from the system resolved the error loop.

Brand new install of Ubuntu 20.04 LTS (Focal Fossa) running as a virtual machine on ESXi was generating a lot of errors in syslog like the below

multipathd[711]: sda: failed to get udev uid: Invalid argument
multipathd[711]: sda: failed to get sysfs uid: Invalid argument
multipathd[711]: sda: failed to get sgio uid: No such file or directory
multipathd[711]: sda: add missing path

The solution is to edit the configuration of the virtual machine using the steps shownb elow for ESXi 6.7. Source https://ubuntuforums.org/showthread.php?t=2441797

1. Shut down the VM
2. Edit the VM -> Edit settings -> VM Options
3. Under Advanced ->Configuration Parameters -> click Edit Configuration button
4. Add a new parameter with following properties:
   Key: disk.EnableUUID
   Value: TRUE
5. Click OK -> Save
6. Power on the VM and confirm the errors have stopped in /var/log/syslog

This issue affects both Ubuntu and Debian.
For example Mopidy 3.0.2 on Ubuntu 20.04 (Focal Fossa) using the apt.mopidy.com method.
Also mopidy 3.3  on Debian 11 (bullseye).

All attempts to connect to a known working Icecast2 server would not work and the Icecast server would not log any errors. However the Mopidy log would record the following error:
[MainThread] mopidy.audio.gst GStreamer error: Could not connect to server
The root cause is a bug in the version of the libshout3 library that is included in the repository has a bug.

For example on Ubuntu 20.04 (source: https://bugs.launchpad.net/mixxx/+bug/1833225).

A workaround is to downgrade libshout3 library to a working version. In this example we will use the library in Ubuntu 19.10 (Eoan): 2.4.3 (2.4.3-1) –> 2.4.1 (2.4.1-2build1)
https://packages.ubuntu.com/eoan/libshout3

Steps for Ubuntu (see Notes for Debian)

1. cd /tmp

2. wget http://mirrors.kernel.org/ubuntu/pool/main/libs/libshout/libshout3_2.4.1-2build1_amd64.deb

3. sudo dpkg -i libshout3_2.4.1-2build1_amd64.deb

4. Restart Mopidy

To prevent the library from being replaced with every apt-get upgrade  you can hold it:

sudo apt-mark hold libshout3

Once the libshout3 package is fixed in 20.04 we will be able to undo it:

sudo apt-mark unhold libshout3

Then upgrade libshout3 using apt-get.

Notes:
Modify steps 2 and 3 for Debian to use the version in the buster repository. This will downgrade libshout3 from version 2.4.5
https://packages.debian.org/buster/amd64/libshout3/download
http://ftp.us.debian.org/debian/pool/main/libs/libshout/libshout3_2.4.1-2_amd64.deb

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.