Glad to see setup completed. However, you still need to perform a root cause analysis. The dates on your parallel MSDN post go back to 7/3. The date on the above setup is 8/13. You need to find the cause of the first setup failure, so you can avoid the same thing happening again.

Running msiexec /X is outside the control and knowledge of SQL Server setup. When that command is run, you put the system in an inconsistent state. The next install of a CU may fail with the same original setup failure, or the next install of a CU may fail with a different error. I have seen a few boxes that needed to be flattened after running msiexec /X. With 45 instances, I would think the cost of a msiexec /X-induced setup failure is very high. Dealing with just the error that is currently in front of you is risky.

Let me offer you an analogy: You are in a car driving in a city with many streets. You take a left turn onto a on-way street, going the wrong way. You make a right run onto a street that is marked "Residents only". You take a left turn onto a street with a road block & sign that says "Bridge under construction". You drive around the road block and your car goers off the bridge and into the water. You ask for help, but all you tell those that you ask is "My car is in the water". Someone says "Use my pump." You pump out the water, try the engine and it starts. You believe you are good to go. Is the care really fixed? What if other parts are still corroding? What if you still go the wrong way down a one -way street, you still go on a street that is marked "residents only", you still drive around a "bridge under construction" sign, or you still pump out the water from your car whenever it gets flooded?

If a setup states that a reboot is required, are you going to wait until tomorrow (and try to run SQL Server upon an incomplete setup), or are you going to immediately reboot (because you do not know how an incompletely setup SQL Server will behave)? What if setup's need to reboot the system is rooted in a module that is common to all 45 instances? The need to reboot the OS (as opposed to a need to restart just one instance of SQL Server, which SQL Server setup does easily perform) implies that all 45 instances of SQL Server will be running in an unsupported state (being exposed to the risk of random failures), until that reboot is done...

It very well could be that a reboot was required for the last successful setup, a setup that had completed before the first setup failure... If that is the cause, it is important to not postpone reboots (especially when 45 instances are setup).

A decision to setup 45 instances has consequences, and it appears those consequences were not clearly understood by the person or persons who made that decision.