Monitoring alerted me to a couple of servers which had lost the ability to replicate SYSVOL using FRS. Microsft KB290762 (https://support.microsoft.com/en-us/help/290762/using-the-burflags-registry-key-to-reinitialize-file-replication-service) provided instructions on how to recover.

In summary, on all members of the replication set (in this instance all DCs) stop the ntfrs service using:

net stop ntfrs

The choose one server which will be the authoritative copy and set BurFlags to 0xd4:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 0xd4 /f

On the other servers, set BurFlags to 0xd2:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 0xd2 /f

On the authoritative server, start the ntfrs service and watch for event 13516 in the “File Replication Service” event log. Once that event is logged, start the ntfrs service on the next server and again wait for the 13516 event log. Repeat this on the remaining servers.

EDIT: I have since discovered FRS was being used due to upgrades from Windows 2003. Followed https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process/ to migrate from FRS to DFSR. In future, if replication breaks it can be reinitialised by following this doc: https://support.microsoft.com/en-ie/help/2218556/how-to-force-an-authoritative-and-non-authoritative-synchronization-for-dfsr-replicated-sysvol-like-d4-d2-for-frs

 

There are various posts relating to issues with VMware Workstation and the use of SATA physical drives (i.e. passing a physical SATA drive through to the guest VM).

The first challenge is getting past the “Internal Error” error message. To do so, create a VM with a SATA virtual disk. Once you’ve done this, you can try and add a SATA physical drive to the guest. This needs to be as a SATA device, since adding the pass-through drive as a SCSI device works. You will receive the “Internal Error” error message. Note that the .vmdk file is created for the drive in the VM’s directory.

The next step is to edit the .vmx and replace the original SATA device (sata0:0.fileName= line) with the newly created .vmdk file. This will get the SATA pass-through device into the VM. However, I was not able to power on the VM at this stage and got another error message.

Looking in the VM’s log file it was apparent that VMware Workstation was unable to open the raw device,
\\?\Volume{someGUID}

The fix to this is to run VMware Workstation as administrator. So instead of double clicking as you normally would, you need to right click and select “Run as administrator”. This was the step that I did not see mentioned anywhere else.

By doing this, I was able to start the VM and it then worked as expected!

Well I am trying to upgrade MailScanner on one of my servers. Alas, these upgrades are never straight forward. The MailScanner upgrade went reasonably smoothly but when it came to starting MailScanner the problem showed itself. Starting MailScanner resulted in the following error:

root@host:/opt/MailScanner/bin# ./MailScanner
 is only avaliable with the XS version at /usr/local/share/perl/5.8.7/Compress/Zlib.pm line 9
BEGIN failed--compilation aborted at /usr/local/share/perl/5.8.7/Compress/Zlib.pm line 9.
Compilation failed in require at /opt/MailScanner/lib/MailScanner/SA.pm line 42.
BEGIN failed--compilation aborted at /opt/MailScanner/lib/MailScanner/SA.pm line 42.
Compilation failed in require at ./MailScanner.orig line 110.
BEGIN failed--compilation aborted at ./MailScanner.orig line 110.
root@host:/opt/MailScanner/bin#

The root of the error is the message about “is only avaliable with the XS version” within Compress/Zlib.pm line 9. There are a few posts relating to this but no real resolutions. One of the common suggestions, which works for a few people it seems, is to force reinstall the Scalar::Util Perl module. Use “force install Scalar::Util” from within the CPAN shell. This didn’t work for me.

I tried a short test script to try reproduce the problem:

use Scalar::Util qw(dualvar);
use Compress::Zlib;
print "$Scalar::Util::VERSIONn";
my $foo = dualvar 10, "Hello";
print "$foon";

This worked which indicates that the XS functionality is working properly.

I figured it might be related to the load order of the libraries. For MailScanner 4.79.11-1 I managed to work around this problem by inserting

use Scalar::Util qw(dualvar);

in at line 38 (just after “require 5.005;”). This appears to load the Scalar::Util XS functions before MailScanner alters the library search paths.

Hopefully this helps someone else with this problem.