Registry-Favoriten können hilfreich sein

Einige Applikationen unter Windows verewigen sich in der Registry. Dort kann es dann auch zu Fehlern kommen oder man möchte Werte schnell überprüfen. Ähnlich wie in Browsern kann man in der Registry auch Favoriten erstellen, um schneller an das gewünschte Ziel zu kommen. 

Die Favoriten werden benutzerabhängig in der Registry gespeichert unter dem folgenden Pfad:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Applets\Regedit\Favorites

Diese können somit dort exportiert und auch auf weiteren Systemen importiert und genutzt werden.

Eine weitere Verwendungsmöglichkeit wären sogenannte applikationsabhänige Registrykeys für den Support, die per Verteilung zum Beispiel per GPO oder Softwaremanagementsystemen zur Verfügung gestellt werden könnten, um Probleme schneller zu beheben oder auf wichtige Registrywerte schneller zugreifen zu können.  

So könnte man eine GPO mit einer Active Directory-Gruppe verknüpfen und sogar per WMI-Filter angepasst auf Computersysteme verteilen, so dass der Supporter, wenn die entsprechende Applikation, welche im WMI-Filter definiert ist, auf dem System installiert ist, zentral bereits die entsprechenden Favoriten zur Verfügung gestellt bekommt. Somit ist das “Durchwandern” der Registry einfacher und effektiver gestaltet.

PowerShell-Skripte per Registry freischalten

Um PowerShell-Skripte als Benutzer auszuführen möchte muss dieses erst einmal freigeben, da diese Funktion bei der Standard-Installation deaktiviert ist.

Dazu kann der folgende Befehl genutzt werden, der als Administrator ausgeführt werden muss:

Set-ExecutionPolicy Unrestricted

Um dieses zum Beispiel bei automatisierten Installation anpassen zu können, ist auch eine Bearbeitung der Registry möglich, um diese Option anzupassen:

Pfad: HKEY_LOCAL_MACHINE\Software\Microsoft\Powershell\1\ShellIds\Microsoft.Powershell

Name: ExecutionPolicy

Typ: REG_SZ

Wert: Unrestricted

Es gibt allerdings noch weitere Policy-Einstellungen, die ich hier gern hier einmal zusammenfasse:

  • Restricted: Keine Ausführung von Skripten
  • AllSigned: Nur von einem vertrauenswürdigen Herausgeber signiert wurden können ausgeführt werden.
  • RemoteSigned: Heruntergeladene Skripte müssen von einem vertrauenswürdigen Herausgeber signiert werden, bevor sie ausgeführt werden können.
  • Unrestriced: Alle Skripte können ausgeführt werden.

0×80040201 bei DLL-Registrierung für AD-Schema-SnapIn

Am gestrigen Tage erhielt ich eine Anfrage aufgrund meines Artikels zum Active Directory-Schema und der Installation des entsprechenden SnapIns per DLL-Registrierung. Der Anfragende bekam immer die Fehlermeldung “The Module schmmgmt.dll Loaded but the Call to DllRegisterServer Failed with Error Code 0×80040201″.

Er hatte auch seinem Benutzer die höchstmöglichen Active-Directory-Rechte eingeräumt, was allerdings den Fehler nicht beseitigte. Das Hinderniss um den Befehl erfolgreich auszuführen war die UAC, die bei Windows Server 2008 R2 genauso aktiviert ist wie bei den Clientbetriebssystemen.

Nachdem der Fragende den Befehl “regsvr32 schmmgmt.dll” in einem Konsolenfenster mit administrativer Berechtigung ausgeführt hatte bekam er von dem System eine Erfolgreiche Rückmeldung und konnte auch das SnapIn nutzen.

“Administrative Tools” aus Programme und Startmenü entfernen

Nach der Installation der “Remote Server Administration Tools”, die zum Beispiel für die Verwaltung einer Active Directory oder zum Erstellen von Gruppenrichtlinien verwandt wird, erscheinen diese als Programmgruppe unter dem Punkt “Alle Programme” sowie als Unterpunkt im “Startmenü”.

Dieses kann per Registry-Key getrennt voneinander ausgeblendet werden.

Eintrag “Administrative Tools” im Startmenü verbergen:

Pfad: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Objekt: StartMenuAdminTools
Objekttyp: DWORD
Value: 0

Programmgruppe unter “Alle Programme” verbergen:

Pfad: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Objekt: Start_AdminToolsRoot
Objekttyp: DWORD
Value: 0

Der generellte Zugriff auf die eingebundenen Management-Konsolen ist weiterhin möglich und wird durch diese Registrywerte nicht beeinträchtigt.

ADPREP in unterschiedlichen Bit-Versionen

Aufgrund einer Domänenumstellung bei einem Kunden war es erforderlich den Befehl ADPREP von einer Windows Server 2008 R2-CD auszuführen.

Dabei musste auf einem Domänencontroller mit Windows Server 2003 R2 (32-Bit) eine Schemavorbereitung für eine Windows Server 2008 R2 Domäne durchgeführt werden.

Dieses stellt im eigentlichen kein Problem dar, wenn man an eine Kleinigkeit denkt:

  • Befehl “adprep” für 64-Bit-Systeme verfügbar
  • Befehl “adprep32″ für 32-Bit-Systeme verfügbar

Ich hatte leider noch eine ältere Zusammenstellung in meinen Unterlagen gefunden, wo der diese Unterscheidung leider nicht noch dokumentiert war.

Somit konnte ich mit dem entsprechenden Befehlen die Domäne auf ihre Umstellung auf einem Windows Server 2008 R2-Domänencontroller vorbereitet werden:

adprep32 /forestprep

adprep32 /domainprep /gpprep

Nach dem Hinzufügen des ersten Domänencontrollers sollte noch der folgende Befehl ausgeführt werden.

adprep32 /rodcprep

Somit hat man  Befehl komplett für die Umstellung genutzt.

LanguagePack-Installation beim Windows Server 2008 R2

Für den vereinfachten Support durch Mitarbeiter anderer Nationen sollte auf einem Server eine zusätzliche Sprache zur englischen Standard-Installation. Mit folgendem Vorgehen kann ein weitere Sprache auf dem Server installiert werden:

  • Herunterladen des erforderlichen LanguagePack-ISO
  • Brennen des Mediums
  • Aufrufen einer Konando-Konsole mit administrativen Rechten
  • Befehl “lpksetup.exe” eingeben und mit der ENTER-Taste bestätigen
  • “Install display language” auswählen
  • Über “Browse” das entsprechende LanguagePack auf dem Medium auswählen
  • Sprache wird entspreechend angezeigt und kann über “Next” installiert werden
  • Bestätigung der Lizenzbedingungen durchführen
  • Die Installation dauert nun eine ganze Weile
  • Mit “Next” zur Sprachauswahl weitergehen

Nun kann die neue Standard-Sprache ausgewählt werden oder über “Close” die Installation beendet.

Wenn eine neue Standard-Sprache für die Systembenutzer und das Begrüßungsfenster ausgewählt wird, muss der Server durchgestartet werden. Wenn im Nachgang ein Anwender seine persönliche Spracheinstellung anpasst, wird eine Abmeldung des Benutzers erforderlich.

Remote Desktop Web Access per DynDns

Nachdem ich nun den Terminalserver im lokalen Netzwerk nutzen konnte, interessierte mich halt auch in wieweit man den Server direkt über das Internet erreichen konnte.

Es war logisch, dass Ports in der Firewall freigeschaufelt werden mussten. Neben dem Port für das HTTPS-Protokoll 443 musste auch der Port 3389 für den Remote Desktop (jeweils TCP) zum Server durchgeleitet werden. Mit diesen Einstellungen Gels mir. Dreist eine Benutzerauthentifizierung am Webinterface.

Leider war es mir über den bereits im Router eingerichteten DynDns-Account nicht möglich direkt auf die Applikationen zugreifen, da mir die Fehlermeldung mitteilte, dass er den Server nicht erreichen könne, wobei ich diesen per Remote Desktop direkt aufrufen konnte.

Mein Fehler lag in der Konfiguration des Remote Desktop Services. Dort hatte ich den lokalen Servernamen des Systems eingetragen. Nach dem ich nun den die Verbindungseinstellungen auf den DynDns-Eintrag angepasst hatte und einen Reboot durchführte war es mir nun möglich aus dem Internet auf den Dienst zuzugreifen.

Des Weiteren muss man sich darüber im klaren sein, dass aufgrund der nun aktivieren Einstellung auch für den internen Zugriff auf das System standardmässig die Verbindung über das Internet gewählt wird, so dass es zu einem entsprechenden Leistungsengpass auf der Netzwerkanbindung kommen kann.

Sollte man ein entsprechendes System länger im Internet betreiben sollen, sollten man sich auf jeden Fall weitere Gedanken über den Punkt Security machen. Zum Beispiel ist es ebenfalls in der Konfigurationsmaske des Host Servers möglich den Port des abhörenden RDP-Kanals auf einen anderen Port anzupassen, so das ein Direktzugriff per DNS-Auflösung und Standard-Port nicht entsprechend einfach möglich ist.