Attempting to install an application on Windows Server acting as a RDS resulted in Windows Installer Coordinator hanging indefinitely with the message:
Please wait while the application is preparing for the first use
followed by the Windows Installer error message:
Install server not responding
This occurred on both Server 2012 R2 and Server 2019.

The workaround is the same for both versions and involves temporarily changing a local group policy setting:

1. Open Local Group Policy Editor (gpedit.msc)
2. Navigate to:
   Computer Configuration -> Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Application Compatibility
3. Locate the setting: Turn off Windows Installer RDS Compatibility
4. Change it to Enabled and click Apply

At this point you should be able to retry or restart the installation of the application. Once complete, revert the group policy setting back to the previous value (default is Not Configured).

Problem: Removing the floppy drive and saving the VM configuration, the floppy drive would automatically appear again.

Solution: Shutdown the VM and unregister it. Manually edit the vmx file, find one or more lines similar to the below and delete them:

floppy0.startConnected = “FALSE”
floppy0.clientDevice = “TRUE”
floppy0.fileName = “vmware-null-remote-floppy”

Then add a new line :
floppy0.present = “FALSE”

Save and overwrite the old vmx file in the datastore, then re-register the VM. Your floppy drive should now be gone.

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