Windows Server 2012 und Server 2008/R2 können dem gestandenen Admin ab und an auch mal neue Schrecken einjagen. Praktisch direkt nach der Installation, dem ersten Schwung Updates und vielleicht ein bisschen Rollen-Gewühle bleibt nach einem Reboot der fast-frische Serverbildschirm nach dem Login plötzlich schwarz. Sowohl via RDP als auch bei der loaklen Anmeldung – alles schwarz. STRG+ALT+ENTF zaubert zwar den Taskmanager-Auswahlbildschirm wieder in die sichtbare Realität, mehr aber auch nicht. Ich habe dieses Phänomen jetzt unter VMWare gesehen, unter Hyper-V und auf echter Hardware (selten, aber sowas gibt’s noch). Hardware ist nicht schuld.
Im Eventlog, das via RPC erreichbar ist, offenbart sich der Effekt durch die Warnung:
The Windows logon process has failed to spawn a user application. Application name: . Command line parameters: C:Windowssystem32userinit.exe.
Lösung
Der Fehler liegt irgendwo zwischen der Erzeugung des Twintoken bei der Anmeldung und der UAC-Steuerung. Beides benötigt zur Anzeige rechte für die Interaktive Anmeldung; irgendetwas zerstört offenbar diese (lokal). Daher: Die lokale Gruppe „Benutzer“ verfüg über diese – und bekommt die beiden neuen Mitglieder „Authentifizierte Benutzer“ und „Interaktive Anmeldung“. Das ist remote möglich – reboot und der Bildschirm ist wieder da. Auf einem DC gibt es bekanntlich keine Lokalen Gruppen, daher müssen für solche Server die Domänen-Prinzipale in builtin herhalten. Einfach dort beide Prinzipale einfügen, fertig.
Nach langem Suchen bin ich nun doch fündig geworden. Die Offlinesynchronisation die sich im Windows-Dateiserver so wunderbar einfach pro Freigabe deaktivieren lässt, ist auch unter Linux durchaus konfigurabel.
Redundante DHCP-Server sind eine feine Sache. Microsoft geht sowas gerne mit der 70/30 Methode an, andere Hersteller haben andere Zahlen – nutzen aber die selbe Technik. Die Proportionen sind natürlich jeweils anpassbar, die Taktik aber gleich: Man baut einfach identische DHCP-Server, schliesst aber jeweils die Hälfte der Adressen (oder 70% und 30%) von der Verteilung pro Server aus. Funktioniert gut, ist aber nicht die performateste Möglichkeit – und löst das Problem der Reservierungen nicht. Reservierungen müssen jeweils auf beiden (oder mehr) Servern angelegt werden, sonst endet ein Client gerne mal mit einer falschen (oder vermeintlich reservieren) Adresse.
