This is going to depend on your environment. Snapshots, clones, and gold-copy images all cause issues simply because they're using identical entropy pools to generate RNG for the system. VMWare offers virtio drivers that allow entropy to refresh from the core kernel but I don't think this exists for Windows.
In this case, a reboot refreshes the entropy pool but also has the very small window of below entropy threshold potential issues your reference also discusses. This is easily prevented by NOT allowing RNG functions for OpenSSL or other Keygen needs until the system is fully booted.
3rd option and in my thoughts the proper alternative is to rely on an external hardware rng to refresh your entropy pool and then pull from that. That allows you:
- True Entropy sources to populate all of the PRNGS on each virtual
- The ability to monitor each clone's entropy pool and refresh when entropy thresholds are hit (filling back up to 4k)
- No worries that you're using duplicated entropy pools from all of the clone images
None if this is an issue unless you have a compliance requirement and/or have keygen needs that'll saturate each vm's entropy pool and really cause a potential for known number scenarios. In those instances, go hardware RNG.
TL;DR