Hope This Helps

Problem:
Ich hatte eine RDP-Session, die sich "verrannt" hat und ich konnte auch keinen weiteren Benutzer mehr anmelden.
Stattdessen lese ich folgende Meldung beim Anmeldebildschirm:

"Der angeforderte Vorgang konnte nicht ausgeführt werden, da die Remotedesktopdienste derzeit ausgelastet sind. Versuchen Sie es in einigen Minuten noch einmal. Andere Benutzer können sich normalerweise weiterhin anmelden."

Die Anmeldung mit einem anderen Benutzer ist ebenfalls nicht möglich.
Wie komme ich jetzt an den Server um die Session zurückzusetzen?

Lösung:
Man kann von einem anderen Server/Client aus die Session per Kommandozeile ermitteln und zurücksetzen.
WICHTIG: SIE BENÖTIGEN EINEN BENUTZER, DER ADMINISTRATOR-RECHTE AUF DEM BETROFFENEN SERVER HAT!

1.) Melden Sie sich mit dem administrativen Benutzer an einem anderen Server/Client an

2.) Führen Sie den Befehl "query session /server:" aus, wobei Sie für den Namen des betroffenen Servers eintragen.

3.) In der Ausgabe sollten sie die betroffene Session sehen - merken Sie sich die entsprechende SESSION-ID

5.) Nun setzen Sie die betroffene RDP-Sitzung mit folgendem Befehl zurück: "reset session >SESSION-ID> /server:"
Wobei die Session-ID und der Servername mit den jeweiligen richtigen Werten ersetzt werden müssen.

6.) FERTIG - Die Session wird nun zurückgesetzt - das kann einige Minuten dauern!

Sollte der Fehler häufiger auf Server 2008R2 auftreten, dann gibt es von Microsoft einen Hotfix.
Hier scheint es ein Problem zu geben zwischen dem Prozess csrss.exe und manchen Anwendungen.
Microsoft: KB2661332 - Sie können keine Remotedesktopdienste-Sitzung auf einem Windows Server 2008 R2-basierten Server wiederherstellen.

Quelle:
rodolfovaraujo: How to kill RDP sessions remotely

Problem :
Windows Server 2008 R2 / Windows 8.1 / Windows Server 2012R2 startet auf einer ESXi 4.1 nicht richtig. Es kommt immer zu einem Bluescreen mit der Information CRITICAL_STRUCTURE_CORRUPTION

Lösung :

Ein Update für ihre ESXi Maschine kann dieses Problem beheben.
Da es sich in meinem Fall um einen ESXi 4.1 handelte hier der andere Weg.
Ein Workarround ist eine eigene CPUID Mask für die betroffene Maschine zu erstellen.

1.) ausschalten der betroffenen virtuellen Maschine
2.) Einstellungen der vm bearbeiten
3.) Auf das Register Optionen wechseln
4.) auf CPUID Mask klicken
5.) auf Erweitert klicken und eine CPUMASKID eintragen

Für Intel CPU den Wert unter Level 80000001.edx auf ----:0---:----:----:----:----:----:---- ändern
Für AMD Cpu den Wert unter Level 80000001.edx auf ----0--------------------------- ändern




Quelle :
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2060019

Problem : Man möchte einen Windows 2012 R2 Server auf einer VMWare ESXi 4.1 Infrastruktur installieren. Dies scheitert leider mit einem Bluescreen von Windows 2012 R2 Server. ESXi 4.1 unterstützt diese Plattform nicht, mit einem kleinen Eingriff kann man es aber überreden.

Lösung :

1.) Erstellen einer virtuellen Maschinen mit dem Gasttemplate Windows 2008 R2 (64Bit) Server
2.) Nach dem erstellen diese Datei herunterladen und im Pfad der Maschine auf der ESXi Kiste abspeichern.
3.) Direkt nach dem erstellen der Maschine muss die vmx Datei angepasst werden.
Diesen Eintrag hinzufügen :

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

4.)Anschalten der virtuellen Maschine und installieren

Kleiner Tipp um das ROM auf den ESXi zu übertragen ist das Tool WinSCP gut geeigent



Solltet ihr danach einen den Fehler bekommen CRITICAL_STRUCTURE_CORRUPTION lest euch das hier durch :
http://hope-this-helps.de/serendipity/archives/459-VmWare-ESXi-4.1-Windows-2012-R2-Server-CRITICAL_STRUCTURE_CORRUPTION.html

Quelle :
https://jgiffard.wordpress.com/
http://communities.vmware.com/servlet/JiveServlet/download/2139717-98102/bios.440.rom

Problem:
Der Windows Remote Management Dienst starte nicht mehr. Versucht man Ihn manuell zu starten, wird er sofort wieder beendet.
Ein Blick ins Ereignisprotokoll zeigt den Fehler 1300 für WinRM:


Lösung:
Nach kurzer Suche im Netz habe ich auch gleich eine Lösung gefunden. Damit der Dienst starten kann benötigt der Dienst-Benutzer das Recht zum "Generieren von Sicherheitsüberwachungen". Ich wollte dies mittels "secpol.msc" anpassen auf dem Server, aber da war das Hinzufügen ausgegraut. Nach kurzer Suche, war mir klar warum...es handelt sich hierbei um einen Domänencontroller und somit war die Änderung dieser Einstellung nur über die "Default Domain Controller Domain Controllers Policy" möglich. Hier habe ich folgendes angepasst:

- Navigieren zu "Richtlinie" -> "Windows-Einstellungen" -> "Sicherheitsrichtlinien" -> "Zuweisen von Benutzerrechten" -> "Generieren von Sicherheitsüberwachungen"

- Hier den zusätzlichen Benutzer eintragen (bei mir der Netzwerkdienst)

- Policy schließen und "gpupdate" auf dem DC ausführen

- WinRM-Dienst starten -> Fertig!

HINWEIS: Bei Member-Servern (Nicht-DCs), kann die Änderung auch über "Secpol.msc" durchgeführt werden.

Quelle zur Lösungsfindung:
XenDesktop 5.6 – The WinRM service is unable to start.