Microsoft Patch KB4088875/KB4088878 has issues with VMXNET3 adapter

March rollup disconnects Windows Server 2008R2 VMs

Microsoft’s monthly March 2018 rollup KB4088875 contains a patch KB4088878 which seems to have issues with Windows Server 2008 R2 VMs and VMXNET3 adapter. Applying the patch disconnects Windows Server 2008R2 VMs.

Sounds familiar?

Yes, indeed! There used to be an old problem with Server 2008R2 VMs which had a VMXNET3 NIC. After restoring these VMs from backup, they’ve lost their static IP and instead switched to DHCP.  The problem is known by VMware and there’s a corresponding KB1020078.

Microsoft released in a hotfix 433809 (KB2550978) to prevent the issue. But you had to switch to DHCP first before installing the hotfix and then revert to your static IP. I’ve published the procedure in 2013. This blogpost is in German but the procedure is simple:

  • change NIC from static IP to DHCP
  • apply hotfix
  • reboot
  • revert to static IP

It seems that Microsoft now has included that old hotfix into a montly rollup. At least the similarity is striking.

Fun fact

Those who had already applied the Hotfix in the past to their 2008R2 VMs, seem to be immune to the problem.

Links

 

Veeam ReFS Repository on iSCSI Targets

Troubleshooting Repository Deadlocks

With Resilient Filesystem (ReFS) integration into Veeam Availability Suite 9.5 a whole bunch of features was integrated. One of the biggest advantages is ‘Fast Cloning Technology’ which enables synthetic full backups by merely creating pointers to already existing datablocks on the repository.

In a small scale environment I had a hardware repository server (Win 2016) with an iSCSI Volume as repository (ReFS, 64k) as primary backup target. This constellation worked like a Swiss watch. Daily backups ran for months without any trouble. Fast cloning technology enabled weekly synthetic full backups with minimal consumption of extra space.

Recently I’ve added another iSCSI Volume (ReFS, 64k) to be used as repository for backup copies. That’s when the fun began… Continue reading “Veeam ReFS Repository on iSCSI Targets”

Query NTFS Blocksize

Using 64k blocksize for better performance

Partitions with Veeam-Backups, SQL-Database files or SQL-Logs should be formatted with a 64k blocksize for better performance. You can check blocksizes with a simple command.

Open a CMD Shell with Administrator rights.

fsutil fsinfo ntfsinfo <Drive>

Example for the system partition.

fsutil fsinfo ntfsinfo C:
NTFS-Volumeseriennummer : 0xa892e42c92e400a4
Version : 3.1
Anzahl der Sektoren : 0x000000001dc807ff
Gesamtzahl Cluster : 0x0000000003b900ff
Freie Cluster : 0x0000000000b42c71
Insgesamt reserviert : 0x0000000000000ff0
Bytes pro Sektor : 512
Bytes pro physischen Sektor : 512
Bytes pro Cluster : 4096
Bytes pro Dateidatensatzsegment : 1024
Cluster pro Dateidatensatzsegment : 0
MFT-gültige Datenlänge : 0x0000000017180000
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x0000000000eb7240
MFT-Zonenende : 0x0000000000eb9340
RM-Bezeichner: FFFF0956-A102-11E7-87BD-005056C00008

You can see Bytes per Cluster: 4096 which equals 4KB.

Script

To check all local partitions for the corresponding blocksize you can use a PS script, which was originally posted by Stuart Moore.

$wql = "SELECT Label, Blocksize, Name FROM Win32_Volume WHERE FileSystem='NTFS'"
Get-WmiObject -Query $wql -ComputerName '.' | Select-Object Label, Blocksize, Name

Links

Stuart Moore – Get Cluster size for all disks and volumes on a Windows machine using powershell and wmi

Veeam Backup & Replication Best Practices