RDP: Wie setzt man eine RDP-Sitzung remote zurück (cmd - Session Reset)

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

Server 2012R2/2016: Event Error DCOM 10016 - APPID 9CA88EE3-ACB7-47C8-AFC4-AB702511C276 / F72671A9-012C-4725-9D2F-2A4D32D65169

Problem:
Nach der Installation meiner Windows 2012R2 und 2016 Server habe ich im Eventlog immer wieder folgende Meldungen gelesen:
Quelle: Microsoft-Windows-DistributedCOM
Ereignis-ID: 10016
Beschreibung:
Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} und der APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276} im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.


Lösung:
Das Problem ist, dass der genannte Benutzer (hier: SYSTEM) keine Berechtigung zur Lokalen Aktivierung der DCOM-Komponente besitzt. Um dem Benutzer diese Berechtigung zu geben, müss man wie folgt vorgehen:

1.) regedit starten und zum Schlüssel "HKEY_CLASSES_ROOT\AppID\{9CA88EE3-ACB7-47c8-AFC4-AB702511C276}" navigieren
2.) Hier in den Berechtigungen den Besitzer auf "Administratoren" ändern (Default ist TrustedInstaller)
3.) Den Administratoren dann die Berechtigung "Vollzugriff" auf das Objekt gewähren
4.) Jetzt öffnet man die Komponentendienste mittels "dcompcfg"
5.) In der DCOM-Konfiguration zur entsprechenden APPID navigieren (Hierbei handelt es sich um den "RuntimeBroker")
6.) Den Reiter "Sicherheit" öffnen
7.) Im Abschnitt "Start- und Aktivierungsberechtigungen" auf den Button "Bearbeiten" klicken
8.) Dem Benutzer in der Event-Meldung (hier: System) hinzufügen und die Berechtigungen "Lokale Aktivierung" und "Lokaler Start" geben
9.) FERTIG - der Fehler sollte jetzt nicht mehr auftauchen

Ich hatte die Meldung auch nochmals mit der APPID "F72671A9-012C-4725-9D2F-2A4D32D65169" - hier genauso damit verfahren!

Quelle:
Wiki Butzhammer.de: DistributedCOM-Fehler 10016, APPID 9CA88EE3-ACB7-47C8-AFC4-AB702511C276

Microsoft BitLocker: Ständige Frage nach Recovery-Key nach BIOS-Update

Problem:
Ich habe ein BIOS-Update bei einem Bitlocker-geschütztem System durchgeführt (sehr leichtsinnig!) und nun verlangt Windows immer den sehr, sehr langen Recovery-Key.

Lösung:
Manchmal ist man ja etwas leichtsinnig und ich habe beim BIOS-Update überhaupt nicht an Bitlocker gedacht...hmmm!

Korrekte Vorgehensweise um ein BIOS-Update bei Bitlocker durchzuführen wäre:
1.) Systemsteuerung > System und Sicherheit > Bitlocker-Laufwerksverschlüsselung
2.) Hier wählt man "Schutz anhalten" (NICHT DEAKTIVIEREN)
3.) Nun kann man das BIOS-Update durchführen
4.) Nach dem Update aktiviert man den Schutz wieder
5.) Fertig

Was macht man, wenn man das vergessen hat?
1.) Man startet den Rechner und gibt den Recovery-Schlüssel (Vorher hoffentlich gesichert?!)
2.) Nun hält man den Schutz ebenfalls an, wie oben beschrieben
3.) Nun aktiviert man den Schutz wieder und damit ist alles gut!
4.) Fertig - nach einem Neustart ist alles beim Alten!

Quelle der Recherche:
Winboard: BitLocker: BIOS-Update - "suspend" vergessen

Server 2016: Aufgabenplanung führt Aufgaben nicht aus, wenn erste Startzeit in der Vergangenheit liegt!!

Problem:
Ich habe mich an den ersten Server 2016 Systemen versucht und bin gleich auf einen Bug in der "Aufgabenplanung" gestolpert.
Das Problem ist, dass ich versucht habe mehrere Aufgaben zu bestimmten Zeiten laufen zu lassen (Robocopy etc.)
Ein manuelles Starten des Tasks lief problemlos. Aber die Jobs wurden, beim erreichen der geplanten Zeit, nicht ausgeführt!
Nach langer Suche bin ich tatsächlich auf mehrere englische Foreneinträge gestoßen, die hier das gleiche Problem beschreiben.

Wenn Uhrzeit und Datum der ERSTEN Ausführung in der Vergangenheit liegen, dann läuft der Task nicht, wird aber immer wieder neu eingeplant - nur nicht ausgeführt! Man sieht auch, dass sich das Datum der letzten Ausführung nicht ändert!

Lösung:
Gegenwärtig (03.04.2017) habe ich hierfür keine Lösung gefunden!
Es gibt einen Workaround, dass man das Datum manuell in die Zukunft legt und dann läuft der Task auch - bis zum nächsten Neustart des Server - dann tritt das Problem wieder aus. Also wieder alle Tasks in die Zukunft verlegen und dann läuft das !
Ich werde mich erst Mal mit einem Server 2012 R2 begnügen, da das Problem hier nicht auftritt!

Quelle der Recherche:
serverfault: Task Scheduler in Server 2016 Datacenter Edition Doesn't Run Automatically
serverfault: Windows Server 2016 scheduled task schedule must be in future

ActiveDirectory: Sicheres Schema-Update (ADPREP) mittels Replikations-Pause

Vorgehenweise um ein sicheres ActiveDirectroy-Schema-Update durchzuführen

Viele haben bestimmt schon ein ActiveDirectory-Schema-Update durchgeführt, ohne sich der Risiken bewusst zu sein, oder diese zu ignorieren. Ich hatte vor kurzem das erste Mal einen Stromausfall bei einem Schema-Update - glücklicherweise in einer Demo-Umgebung. Das Schema war danach zerstört und hatte sich aber beim Neustart der Server bereits repliziert - ActiveDirectory komplett zerstört, nur noch Fehlermeldungen beim Zugriff auf Objekte!
Um das zu verhindern, habe ich mir eine Anleitung zusammengebaut, in der ich wie folgt vorgehe:

1.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
2.) ADPREP durchführen
3.) Testen des Zugriffs auf die AD (ActiveDirectory-Benutzer und -Computer)
4.) Verzeichnis-Replikation wieder aktivieren
5.) Test der ActiveDirectory

Dazu gehe ich wie folgt vor:

1.) Schemamaster finden
Dazu verwende ich den Befehl "netdom query fsmo" und schau, welcher DC der Schemamaster ist

2.) Aktuelle Schema-Version ermitteln
Hierzu verwende ich auf dem Schemamaster den Befehl DSQUERY.
Hier ein Beispiel für die Domäne DEMO.LOCAL
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion

Kleiner Tipp, falls es sich um ein Exchange-Schema-Update handelt - mit diesem Befehl kann ich die Exchange-Version des Schemas auslesen:
dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=DEMO,dc=INTERN -scope base -attr rangeUpper


3.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
Hierzu verwendet ich die den Befehl "repadmin" um die eingehende und ausgehende Replikation zu deaktivieren:
(SCHEMAMASTER-NAME muss angepasst werden)

repadmin /options SCHEMAMASTER-NAME +DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME +DISABLE_INBOUND_REPL

Danach findet man im Ereignisprotokoll die Ereignisse 1113 und 1115, die darauf hinweisen, dass eingehende und ausgehende Replikation vom Benutzer deaktiviert wurde (Ereignisprotokoll VERZEICHNISDIENST)


4.) Schema-Update durchführen
Jetzt führt man das Schema-Update durch mittels diesen drei Befehlen:
adprep /forestprep
adprep /domainprep
adprep /rodcprep


Im Ereignis-Protokoll werden die Aktualisierungen auch mit protokolliert:


5.) Prüfen der neuen Schema-Version
Nun kann man mittels DSQUERY-Befehl prüfen, ob die neue Schema-Version vorliegt
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion
Als Test dann man sich mal auf einen anderen DC einloggen und den Befehl ebenfalls durchführen.
Hier wird man sehen, dass die Schema-Version noch die alte Version ist, da die Replikation nicht aktiv ist!

6.) Testzugriff auf die AD auf dem Schemamaster
Öffnen Sie einige AD-Konsolen auf dem gerade aktualisieren Schemamaster und klicken Sie sich durch, ob es zu Fehlermeldungen kommt. Wenn alles in Ordnung ist, dann können Sie die Replikation wieder aktivieren.

7.) Replikation wieder aktivieren und das Schema global aktualisieren

Starten Sie auf dem Schemamaster mittels der nachfolgenden Befehle wieder die ein- und ausgehende Replikation:

repadmin /options SCHEMAMASTER-NAME -DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME -DISABLE_INBOUND_REPL


Das Aktivieren der Replikation wird ebenfalls wieder im Ereignisprotokoll angezeigt:



8.) Prüfen der neuen Schema-Version
Starten Sie die Replikation der DCs manuell oder warten Sie den Zyklus ab. Danach prüfen Sie auf allen bestehenden DCs, ob das Schema übernommen wurde mittels des vorherigen DSQUERY-Befehl.

9.) FERTIG!

Damit haben Sie eine risikoarme Schema-Erweiterung durchgeführt und minimieren das Risiko, dass die ActiveDirectory beschädigt wird.

Quellen für die Hilfestellung:
Directory Services: Upgrading AD DS Schema to Windows Server 2016
ANTARY: Active Directory Schema Version herausfinden




“Die Organisationen stecken Millionen von Dollars in Firewalls und Sicherheitssysteme und verschwenden ihr Geld, da keine dieser Maßnahmen das schwächste Glied der Sicherheitskette berücksichtigt: Die Anwender und Systemadministratoren.”
Kevin Mitnick