Ex-Employee tells about the Microsoft Windows internal testing process [Bookmarks, +TLDR, +FR]

"Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!"
-- by  Barnacules Nerdgasm
"https://www.youtube.com/watch?v=S9kn8_oztsA"

TL;DR (FR-version) :

1. 1/ Ils ont licensié un département entier de testeurs quand ils ont fusionné leurs multiples systèmes d'exploitation : Desktop , Phone, etc.
2. 2/ Ils ne testent plus du hardware réel; tout est virtualisé (i.e. les problèmes spécifiques au matériel ne sont pas révélés)
3. 3/ Ils se reposent beaucoup sur le _Windows Insider Program_ et la télémétrie pour avoir des remontée de bugs avant de déployer les mises-à-jour "au plus grand nombre" (mais ce mécanisme a des limitations : les utilisateur du _Windows Insider Program_ ne remontent pas toujours les problèmes, les _mini-dumps_ ne sont pas toujours suffisants pour identifier la source d'un problème, les problèmes sont résolus à tâtons, et dans les pire cas, complètement ratés et les correctifs causent davantage de régressions).

TL;DR (EN-version):

1. 1/ They did a massive lay-off and got rid of a whole testing departement when they merged their multiple Operating System teams : Desktop, Phone, etc.
2. 2/ They don't test real hardware anymore; tests are run in virtual machines (ie. hardware-related corner cases are not tested)
3. 3/ They rely a lot on the _Windows Insider Program_ and telemetry before rolling-out updates to "most people" (but this process has limitations : _Windows Insider Program_ users don't always report bugs, _mini-dumps_ aren't always enough for tracking down a bug, some problèmes are solved by groping and, in the worst cases, even missed entirely and attempts to fix a problème cause further regressions).

The (default) generated homestead VM does not have an IPv4 address and how to fix this

When I first went on installing a Homestead VM, it did not get an IPv4 address. And there was nothing that indicated a failure:

• neither when the VM is booting (no errors, all appears "OK")

• using the "ifconfig" command, we can see that our adapters do not have an IPv4 address (whereas we were expecting 192.168.10.10 to be used)

• the “lspci” command allows us to see what devices are used. We can see the Ethernet controllers there.

tl;dr

I have written a much longer article about the analysis of the problem and all the possibilities offered by Virtual Box in terms of virtual ethernet adapters, and how to configure the Vagrant NIC Types, and you can read it here:

https://p19z.blogspot.com/p/
homestead-vm-does-not-have-ipv4-address.html

But a long story short:

Finally

Configuring the adapter type through the Vagrant file did not work as it created a third adapter and was ineffective.


But changing manually the NIC adapters in the VirtualBox VM setting and using Paravirtualized network adapter (virtio-net) finally gave the best results

Cloning a Windows VM that is part of a domain using Sysprep.exe

Introduction note

In the writing below, the term "SID" most of the time refers to the "Computer's Domain SID" (the SID of the computer accounts in the Domain). Windows OS also uses local SID(s) but those are meant to be harmless. For more information please read this excellent article from Mark Russinovich (cofunder of Sysinternals and writer of the NewSID tool) : http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx.

1. Using sysprep to change the SID

Cloning a VM that is part of a domain in order to use it simultaneously along with the original one is hard: on top of changing 1/ the MAC address, 2/ the computer name and 3/ the IP, we always run into mysterious problems when faced with the domain controller.

And there is even worst: the same goes for (some) backups. For instance, I recently backed-up (ie. copied) a VM and upgraded it to Service Pack 3. After the system was upgraded, I switched the VM off and turned the backup on: the domain rejected the old version of the VM. I assume that the controller stored the upgraded system type and refused to grant access to the domain when running an older XP SP2 system. Needless to say, this backup is quite useless :(

So, cloning a VM creates conflicts difficult to solve. Even if it has been taken off the domain prior to duplication! My network administrator pointed out that this is caused by the SID of the machines, but we never really knew what the solution was in order to work around this problem (from a user point of view, not from the network admin point of view). Now, I just found a possible solution in the Xen documents. The tool mentionned below (sysprep) is not specific to Xen, but to Microsoft. (Source: http://xen.org/files/XenCloud/guest.pdf, Chapter "Preparing to clone a Windows VM".)

Computers running Windows operating systems are uniquely identified by a Security ID
(SID). When cloning a Windows VM, it is important to take steps to ensure the uniqueness
of the SID. Cloning an installation without taking the recommended system preparation
steps can lead to duplicate SIDs and other problems. Because the SID identifies the computer
or domain as well as the user, it is critical that it is unique. Refer to the Microsoft
KnowledgeBase article 162001, "Do not disk duplicate installed versions of Windows," for
more information.
sysprep modifies the local computer SID to make it unique to each computer. The sysprep
binaries are on the Windows product CDs in the \support\tools\deploy.cab file.

And, more specifically, the process being:

5. Copy the contents of \support\tools\deploy.cab from the Windows product CD
to a new \sysprep folder in the VM.
6. Run sysprep. This will shut down the VM when it completes.

7. Convert the VM into a template.
8. Clone the newly created template into new VMs as required.
9. When the cloned VM starts, it will get a new SID and name, run a mini-setup to prompt
for configuration values as necessary, and finally restart, before being available for use.

And this important remark:

The original, sysprepped VM (the "source" VM) should not be restarted again after the
sysprep stage, and should be converted to a template immediately afterwards to prevent
this. If the source VM is restarted, sysprep must be run on it again before it can be safely
used to make additional clones.
For more information on using sysprep, refer to the Microsoft TechNet page "Windows System Preparation Tool".

So, in short, two points to be remembered:

1/ running sysprep destroys the SID and shuts the VM down

2/ a new SID is created when the VM is turned back on and added to the domain.

2. Operating systems supported

2.a) XP and Server 2003

sysprep.exe has to be installed separately.

There is a great article that explains how to create a template machine that will also prompt for a new name on next start: http://capitalhead.com/articles/force-sysprep-to-prompt-for-a-computer-name-during-mini-setup-in-windows-xp.aspx

I strongly recommend duplicating the VM before deleting the SID (for backup purpose of course!).

2.b) Windows 7 Professional and Server 2008 R2

I can confirm that sysprep is already present in the C:\Windows\System32\sysprep directory. Note that you have to run Explorer with Administrator privileges in order to see those files (press Win+R and type "sysprep").

3. Template instantiation

Computer makers such as Dell or HP use sysprep.exe to configure the computers: this tool allows you to install and configure programs (or drivers) on a computer, to create local accounts, etc. and then delete the SID and therefore make the computer ready for first use. The template can be copied as many time as you want, but each copy will have to be activated separately, an IP will have to be set for each computer and the Name and Domain configured. And that is it. Every program installed before the SID deletion will remain on the computer. All the user accounts created will remain as well and so does the application data.

An other interesting thing with this process, is that if you had two accounts ( say MYCOMPUTER\Administrator and MYDOMAIN\UserLambda ), then those users will find their desktop just as it used to be before the machine became a template and was re-instantiated again.

But this may have drawbacks and here is an exemple of what NOT to do (yeah I did it, no big deal really, but it creates an overhead of work upon each instantiation): so for instance, 1/ installing LogMeIn Hamachi and creating an account and then 2/ deleting the SID and re-instantiating the VM multiple times is... well, stupid. Hamachi settings are not reset by sysprep.exe because this tool is not part of the system and it does not use the SID either. Therefore every new VM will attempt to use the same Hamachi account and this will cause conflicts. The only solution then is to uninstall and reinstall the Hamachi client on every new computer.

A good practice here would have been to install the Hamachi client before templatisation, but never switch it on (or at least not configure it). The user of each instantiated VM would then already have the program at hand and just would have to run it and create his account himself.

3. Conclusion

I've successfully used the sysprep tool on an server2008 r2 system and it worked great but I did not have such luck with my old XP SP2 system and I will leave it there.

At the end of the day, sysprepping your OS is not very straightforward, but this an irreplaceable process when you need to duplicate a virtual machine that is part of a domain.

Thank you for reading,