Es scheint doch ein etwas exotisches Problem zu sein, aber vielleicht stehen ja auch mal andere vor der Herausforderung mit einem Setup für ein cumulative update oder Service Pack klar zu kommen, dass so gar keine Anstalten macht irgendetwas zu tun.

Bei meinem Fall war es ein Server mit SQL Server 2008 R2 Shared Features und SQL Server 2012, der sich beharrlich weigerte die per WSUS angebotenen Patche einzuspielen. Der Versuche diese per Hand einzuspielen ließ nur ein kurzes Blinken des Bildschirms erahnen, aber keine GUI erschien.
Im Verzeichnis %ProgramFiles%\Microsoft SQL Server\nnn\Setup Bootstrap\Log\ wurde auch kein neues File geschrieben. Was jetzt?

Suche nach Informationen

Ich habe dann den Process Monitor angeworfen und das Setup mitverfolgt. Als Ergebnis bekam ich die Info, dass es im Pfad C:\Users\<mein User>\AppData\Local\Temp\4 ein Log zu der Installation geben solle. Den Aufwand hätte ich mir auch sparen können, wenn ich mich rechtzeitig an diesen Artikel zum Lesen und Anzeigen der Setupprotokolldateien von SQL Server erinnert hätte.

Dort steht zwar:
Wenn Setup in einem unbeaufsichtigten Modus ausgeführt wird, werden die Protokolle unter %temp%\sqlsetup*.log erstellt.
Doch galt dies wohl auch für meinen Fall des interaktiven Aufrufs für die allerersten Schritte des Setups.

Fehlerbehebung

Zugegeben, ich konnte selber mit der Fehlermeldung nicht viel anfangen:
Error: Cannot load .Net security policy file 0x80004005
aber bei meiner weiteren Suche kam ich schnell auf diesen blog Eintrag. Der war auch schon etwas älter, aber das von mir behandelte System war ja auch nicht mehr ganz taufrisch.

Die Lösung lautete also:

Ran in cmd : C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe -machine -reset
if you have 64 bit then use Framework64

Das habe ich also ausgeführt:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\caspol.exe -machine –reset

Damit startete dann auch das GUI für das Setup und die weiteren Log-Files wurden dann auch wie erwartet geschrieben.