Shut up, Windows 10! Here is a free must-have tool to protect your privacy.

If you install Windows 10 with the default "Express Settings" then it will collect a plethora of data from you and send it to Microsoft and "trusted partners": Not only whatever you ask Cortana (Microsoft's version of Apple's Siri or Google Now), but also what you type or write by hand, where you are, what networks you connect to, what you search for and more...

Sure, they are not alone with this: Google does it with Android, Apple with iOS devices, and - if you ask them - they all collect the data only to optimize the personalized services that they offer you for free. Really for free? No, you pay with your data ... However, more and more people are concerned about data privacy and want to have a choice about what data they disclose. Recently I stumbled over a great tool that helps those people when using Windows 10.

A fix for Intel i211 and i350 adapters not being detected by ESXi

Recently two readers of my blog asked me for help with a strange issue that they encountered when trying to install ESXi on their whitebox hardware. The one was a Shuttle DS57 barebone, and the other one was a Compulab Fitlet-X (an interesting tiny fanless industrial PC with 4 onboard NICs). Both have Intel i211 Gigabit Ethernet adapters that were not detected by ESXi, although they are officially supported by the ESXi 6.0 built-in igb driver (see VMware HCL entry).

Looking for a solution I found that this seems to be a common issue. Multiple reports found in the VMware Communities and other forums convinced me that resolving the issue would help a lot of people. Time for some late night troubleshooting ...

Troubleshooting VM network performance using vsish

Long time, no post ... I'm currently busy with several support requests that I opened with VMware. These keep me busy but they are also good opportunities to learn something new.

One of the cases involves troubleshooting the network performance of Lync 2013 servers running on top of vSphere. It turned out that the VMkernel system information shell (better known as vsish) is a great tool for this.

Heads up: The upcoming Leap Second adjustment may affect your IT infrastructure!

Okay, probably everyone is aware of the upcoming leap second time adjustment on June 30th, 0:00 UTC. I won't explain the story behind it although it's a very interesting topic, but others have done this already. A good starting point is the Wikipedia Leap Second article.

You might wonder: Okay, this is an anomaly that is confusing, but it's only one second, and modern IT systems should not really stumble over this, right? I was of the same opinion until recently, but the nearer the time comes the more IT vendors alert their customers of leap second related issues in their products, and you might be surprised to hear that very critical parts of your infrastructure can fail on June 30th if you do not patch them before!

Filtering logs in ESXi 6.0 - A practical example

Recently I rented a new server with an LSI MegaRAID SAS 9260-4i controller and - of course - installed VMware ESXi 6.0 on it. I will soon migrate my "production workloads" (the V-Front Online Depot, the ESXi Patch Tracker site and my Zimbra E-Mail server) onto this box to improve their availability. A disk failure is one of the most likely disaster scenarios, so a hardware RAID controller with two mirrored disks will certainly help.

After I had the host installed and configured I did a routine check of the log files and found a lot of SCSI errors like these in /var/log/vmkernel.log:
cpu1:34460)NMP: nmp_ThrottleLogForDevice:3178: Cmd 0x1a (0x439d80668b00, 0) to dev "naa.600605b0058b25f01c995a4f0b03da18" on path "vmhba1:C2:T0:L0" Failed: H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0. Act:NONE
cpu1:32779)ScsiDeviceIO: 2646: Cmd(0x439d80716d00) 0x4d, CmdSN 0x1 from world 34425 to dev "naa.600605b0058b25f01c995a4f0b03da18" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x20 0x0.
These errors were referring to the RAID 1 disk, and first I was worried about them - according to KB289902 the D:0x2 translates to "Device: Check condition" and the sense data codes 0x5 0x24 0x0 and 0x5 0x20 0x0 mean "Illegal request", "Invalid Field in CDB", resp. "Invalid command operation code". I double checked that the RAID controller is on the VMware HCL, I searched the Internet for these errors, found few peoples' posts describing this issue, but no solution. I even updated the firmware of the controller, all to no avail ... and then, finally, I stumbled over KB1031221 which - basically - describes that these errors are "normal" and "can be safely ignored".

Well, that calmed me down... But I'm a log purist: I wanted to get rid of these false error messages in vmkernel.log!