Windows 7: Anmeldeinformationen speichern für RDS-Server zulassen

Unter Windows Vista und Windows 7 ist es aus magischen Sicherheitsgründen nicht möglich, Anmeldedaten für einen RDS-Server eine Domäne zu speichern, deren Mitglied der betroffene Computer nicht ist. Möchte man aber nun Anmeldedaten für einen RDS (Remotedesktopverbindung) speichern, funktioniert das nicht. Man hat diese vielleicht auch bereits gespeichert, aber die Anmeldung kommt trotzdem immer wieder

Dieses Verhalten lässt sich via GPO anpassen:

Computerkonfiguration > Administrative Vorlagen > System >
  Delegierung von Anmeldeinformationen >
  Delegierung von gespeicherten Anmeldeinformationen mit reiner NTLM-Serverauthentifizierung zulassen

Die Richtlinie muss „Aktiviert“ werden und entweder der betroffene Terminalserver („TERMSRV/<HOSTNAME>“) oder eine das Wildcard-Label („TERMSRV/*“) konfiguriert werden.

Windows Server 2016 (oder Windows 10) Windows Update 0x8024001e

Tritt bei einem Windows  10 und Windows Server 2016 bei der Aktualisierung der Update Fehler 0x8024001E auf, hilft in der Regel diese Vorgehensweise:

  1. Server neu starten. Wichtig.
  2. Die Dienste „Windows Update“ und „Intelligenter Hintergrundübertragungsdienst“ beenden
  3. Das Verzeichnis „%windir%\Software Distribition“ vollständig (!) löschen
  4. Die Dienste „Windows Update“ und „Intelligenter Hintergrundübertragungsdienst“ wieder starten
  5. Den Update-Vorgang erneu starten

Nun sollte es nicht mehr zu dem Updatefehler 0x8024001e kommen. Ursache war bisher praktisch immer ein defektes Update-Paket; ob das die Vollversion oder das Delta-Paket war, ist unerheblich. Schuld können Virescanner, Firewalls, Paketfilter, UTMs, Deepsecurity-Kram, unterbrochene Netzwerkverbindungen, kaputte Platten oder ähnliches sein. Auf jeden Fall ist der Download defekt.

Besonders fiese Geschichte: Ein (physikalischer) Server hatte einen defekten 10G Netzwerkkartentreiber und ein „heiler“ Download war darüber nicht möglich. Wir haben stundenlang gesucht …

Windows 10 1709 ADMX Ressourcendatei (ADML) nicht gefunden

Problem

Der Gruppenrichtlinieneditor zeit iele GPOs nicht mehr an, sondern stattdessen diesen Fehler:

Für Datei "\\<DC-NAME>\SysVol\<DOMAENE>\Policies\PolicyDefinitions\CcmUsrCse.admx" konnte keine geeignete Ressourcendatei gefunden werden (Fehler = 3): Das System kann den angegebenen Pfad nicht finden. 
Das Richtlinienpräsentationselement "CSE_NOBACKGROUND" auf das in Präsentation "CSE_Drives" verwiesen wird, ist nicht vorhanden. Datei \\<DC-NAME>\SysVol\<DOMAENE>\Policies\PolicyDefinitions\GroupPolicyPreferences.admx, Zeile 334, Spalte 70

Der Fehler tritt auf, nachdem man in einem Group Policy Central Store die Gruppenrichtlinienvorlagen (ADM/ADMX) von Windows 10 auf die aktuelle Version 1709 aktualisiert hat, oder nur das aktuelle Paket installiert.

Lösung

Es fehlt in dem ADMX-Paket eine (deutsche) Übersetzung einer Ressourcendatei. Microsoft hat in dem deutschen 1709er ADMX-Installer-Sprachpaket (de-DE) die „CcmUsrCse.adml“ Übersetzungsdatei vergessen. In 1703 ist diese noch vorhanden (und unverändert). Es hilft sofort, diese Datei aus dem englischen Ordner (en-US) von 1703 dazuzukopieren.

  1. Das „Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709) – Deutsch“ herunterladen und „Installieren“ (sofern noch nicht geschehen)
  2. Das „Administrative Templates (.admx) for Windows 10 Creators Update (1703) – Deutsch“ herunterladen und „Installieren“ (sofern noch nicht geschehen)
  3. Aus dem Ordner <1703ADMX>\PolicyDefinitions\en-US die Datei CcmUsrCse.adml nach <1709ADMX>\PolicyDefinitions\de-DE kopieren
  4. Den <1709ADMX>\PolicyDefinitions Ordner verwenden, zum Beispiel für die aktualisierung des Cenral Store.

Wenn man schon einen Central Store verwendet:

  • Die CcmUsrCse.adml aus dem 1703er \PolicyDefinitions\en-US Ordner nach de-DE kopieren.

Windows 10 Jumplist (Sprungliste oder „Zuletzt verwendet“) Anzahl der Einträge anpassen

Zum Beispiel für RDP-Verbindungen hilfreich

Die Jumplists oder „Sprunglisten-Elemente“ in der Taskleiste von Windows bietet bei einem Rechtsklick die Ansicht der zuletzt verwendeten Dokumente/Dateien/Aktionen. Eine einfache und schnell Hilfe – finden wir auch gut. Standardmäßig werden hier leider nur zehn Einträge angezeigt und man kann die Einstellung leider nicht mehr ändern. Wie macht man die Sprungliste größer?

Unter Windows 10 (1607, 1703, 1709) höher wurde die „Anzahl Sprunglistenobjekte“ entfernt, aber dieser Trick klappt noch.

In der Registry unter HCUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced ist der DWORD-Wert (Dezimal!) des Eintrages „JumpListItems_Maximum“ dafür verantwortlich.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]
"JumpListItems_Maximum"=dword:00000016

Und schon gibt es wieder 20 Einträge. Oder mehr.

Der ursprüngliche (generierte) Name eines Windows-PCs

Es ist leider nicht möglich, den ursprünglichen Namen einer Windows-Maschine herauszufinden, zum Beispiel den pseudeozufällig genrierten Namen von der Installation. Es gibt in Windows auch keine „Historie“ aller Hostnmane oder ähnliches.

Aber der jeweils letzte Hostname der Windows-Installation kann in diesem Registry-Schlüssel nachgeschlagen werden:

HKLM\Software\Microsoft\SchedulingAgent\OldName

Windows 10: „Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden“

Problem

Nach einem Update/Upgrade können sich neue Benutzer nich mehr an diesem PC anmelden. Es erscheint die Fehlermeldung „Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden.„. Danach wird der Benutzer sofort wieder abgemeldet. Administratoren können sich anmelden, jedoch bekommen diese entweder kein Startmenü oder nur einen schwarzen Bildschirm.

Lösung

Ein Update auf Windows 16xx macht das manchmal; es git dann einen lokalen Link-Loop in den Profil der die Kopie für frische Benutzer erfolgreich verhindert. Der UserprofileServer versucht das dreimal und bricht dann ab.

Das „Default“ Userprofile ist defekt und es muss durch eine saubere Kopie von einem funktionierenden Windows 10 System ersetzt werden.

  1. Alle Benutzer von dem Zielsystem abmelden (damit der Profildienst nichts mehr blockt)
  2. Remote: Das Default-Profil umbenennen. Nicht löschen, das geht wegen des Loops nicht fehlerfrei.
    •  \\<ZIELPC>\Users\Default -> Default.doof
  3. Ein „sauberes“ Default-Profil von einem funktionierenden Windows 10 mit Windows in eine ZIP-Datei packen
  4. Die ZIP-Datei nach \Users entpacken

Fertig. Danach funktionert die Anmeldung neue Benutzer sofort wieder.

Symantec Endpoint Protection Manager RESETPASS.BAT (Kennwort zurücksetzen) Script herunterladen

Der „Symantec Endpoint Protection Manager“ (SEPM) in der Version 12.x hat so ein prakisches kleines Script, das dem Administrator erlaubt, sein Kennwort „hart“ auf einem lokalen Server zurück zu setzen. Das ist unter anderem hilfreich, wenn der Admin wechselt, ein Kennwort verloren geht oder der Endpoint-Client von einem Virus mißbraucht wurde.

Das Script ist nur leider nicht mehr im Lieferumfang enthalten und man müsste erst umständlich einen Support-Case öffnen um das Script zu bekommen. Wenn es nicht ugg.li gäbe!

  • Download SEP 12.x RESETPASS.BAT (RESETPASS.CMD)
  • Im .\tools-Verzeichnis der SEPM-Installation ausführen
  • Benutzername und Kennwort laten dann „admin“ (in Zeile 7 am Ende änderbar – keine Sonderzeichen!)
  • NICHT unter 14.x ausführen! Das zerschießt die Datenbank

Der Inhalt des Scripts ist relativ übersichtlich:

@echo off
REM /* RESETPASS.CMD für Symantec Endpoint Protectoin Manager 12.x */

set CATALINA_HOME=%CD%\..\tomcat
set JRE_HOME=%CD%\..\jre

"%JRE_HOME%\bin\java.exe" -Xms64m -Xmx256m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=40 -classpath "%CD%\..\bin\inst.jar;%CD%\..\bin\inst-res.jar" -Dcatalina.home="%CATALINA_HOME%" -Djava.library.path="%CATALINA_HOME%\bin;%CATALINA_HOME%\..\ASA\win32" com.sygate.scm.tools.DatabaseFrame setpassword admin admin
endlocal

Danke Symantec …

Veraltete Computerkonten im Active Directory finden

Problem

Eine wiederkehrende und frustrierende Verwaltungsaufgabe für das Active Directory ist, alte Computerkonten (Server, Desktop-PCs, Laptops … ) sauber zu entfernen. Viele Admins fügen eigentlich immer nur hinzu, alte Konten werden nicht aufgeräumt. Einen eingebauten Automatismus dafür gibt es nicht.

Ein Blick auf die Registerkarte „Objekt“ eines Computerkontos zeigt zwar, wann die Update-Sequenznummer (USN) aktualisiert wurde, aber nicht wann sich der Computer das letzte mal bei der Domäne angemeldet hat.

Lösung

Es gibt verschiedene Möglichkeiten, um festzustellen, ob ein Computerkonto in Active Directory veraltet ist. Der empfohlene („Best Practice“) Ansatz besteht darin, eine Richtlinie für Ihre Active Directory-Domäne einzurichten, in der die Regeln erläutert werden. Das Problem dabei sind aber remote-Systeme, wie zum Beispiel ein Laptop, wo der entsprechende Benutzer in der Lage ist, alles zu tun, was er über eine Webanwendung benötigt.

Inaktive Computer im AD mit dsquery suchen

C:\> dsquery computer -inactive <WOCHEN>

Der Befehl wird so für die gesamte Domäne (des ausführenden Computers) ausgeführt. Einschränkungen sind aber möglich:

C:\> dsquery computer OU=Hiersuchen,DC=domain,DC=local -inactive <WOCHEN>

Leider kann dsmove nicht mit dieser Liste direkt gepiped werden, da ist die Powershell etwas komfortabler. Um also ältere Computer in eine eigene OU zu verschieben, ist an der CMD-Shell ein Dreizeiler erforderlich:

dsquery computer -inactive <WOCHEN> > liste.txt
FOR /f %%i in (liste.txt) do dsmove %%i -newparent OU=<INACTIVE-OU>,DC=domain,DC=local
del liste.txt

 

 

Inaktive Computer im AD mit der PowerShell suchen

Das geht sogar in Tagen, nicht nur in Wochen. Dafür muss die Variable entsprechend geändert werden (-60).

PS C:\> $then = (Get-Date).AddDays(-60)
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then}

Die ausgegebenen Objekte lassen sich so direkt weiterpipen.

Mehr Beispiele an der Powershell

# Ausgabe veralteter Computerkonten als halbwegs sinnvolle Liste
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Sort-Object -Property "lastLogonDate" | FT Name,lastLogonDate
# Veraltete Computerkonten im AD deaktivieren
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Set-ADComputer -Enabled $false
# Veraltete Computerkonten im AD löschen
PS C:\> Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Remove-ADComputer