Aufgrund einer Anforderung in einem Kundenprojekt durfte ich mich in der letzten Woche mit dem Thema “Leerlauf” beschäftigen. Eigentlich sollte ein Programm mit gewissen Parametern ausgeführt werden, wenn das System sich im Leerlauf befindet. Dieses sollte über die Aufgabenplanung realisiert werden. Hörte sich nach einer lösbaren Aufgabe an, was sich allerdings schnell zu einer Herausforderung entwickelte.

Bei der Bezeichnung “Leerlauf” war ich davon ausgegangen, dass es sich der Rechner im Leerlauf befindet, wenn er nach einer kurzen Zeit merkt, dass derzeit nichts zu tun ist. Leider ist es laut Microsoft-Definition etwas komplexer.

Zur Ermittlung des Leerlaufs überprüft der Aufgabenplanungsdienst alle 15 Minuten, ob das System sich im Leerlauf-Modus befindet. Als erstes Kriterium wird ermittelt, ob der Bildschirmschoner gestartet ist. Sollte dieses nicht der Fall sein, kann ein Leerlaufzustand ermittelt werden, wenn innerhalb der letzten 15 Minuten in einem Zeitraum von 90 Prozent keine CPU-Last und keine Schreib- oder Lesezugriffe auf der Festplatte stattgefunden haben. Desweiteren dürften weder Tastatur noch Mauseingaben oder Mausbewegungen stattgefunden haben.

Somit ist es ohne Bildschirmschoner gar nicht so einfach einen Leerlauf zu erreichen. Ausserdem gibt es heute viele Programme, die im Hintergrund doch regelmäßig auf die Festplatte zugreifen wie zum Beispiel der Indizierungsdienst von Windows Desktop Search.

Für weitere Informationen zum Thema bitte hier klicken:
Link

Wer bei Gruppenrichtlinien mit WMI-Filtern arbeiten möchte muss die Werte von “Version” und “ProductType” des WMI-Objektes “Win32_OperationSystem kennen. Aus diesem Grund zum schnellen Überblick hier eine Auflistung

Version:

  • 5.1 – Windows XP
  • 5.2 – Windows Server 2003
  • 6.0 – Windows Vista und Windows Server 2008
  • 6.1 – Windows 7 und Windows Server 2008 R2
  • 6.2 – Windows 8 und Windows Server 2012

Da aber der Versionsnummerierung 6.0 die Client und Serverbetriebssysteme unter einer Versionsnummer geführt wurden, muss seit dem auch der “ProductType” ausgewertet werden.

  • 1 – Client
  • 2 – Domänencontroller
  • 3 – Server

Entsprechend gibt es die folgende Unterscheidung auf Client- bzw. Serverbetriebssystem anhand des Beispiels der Version 6.2.

Windows 8:

select * from Win32_OperatingSystem WHERE Version LIKE “6.2%” and ProductType = “1”

Windows Server 2012:

select * from Win32_OperatingSystem WHERE Version LIKE “6.2%” AND ( ProductType = “2” or ProductType = “3” )

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.

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.

Leider machen auch ansonsten gut funktionierende Systeme mal Fehler. In diesem Fall wollten sich 9 Updates, die über einen WSUS-Server verteilt werden, nicht installieren. Diese Meldungen hatte sich schon mehrere Tage bemerkbar gemacht, allerdings bin ich erst heute dazu gekommen mich damit zu beschäftigen.

Leider musste passieren, was in solchen Momenten immer passiert laut eines gewissen Herrn Murphey: Der Fehler konnte in dem Moment, wo ich einen entsprechenden Ansprechpartner an der Strippe hatte nicht nachgestellt werden. Also fühlte ich mich in der Beweispflicht, nach dem wir uns auf den kommenden Tag verabredete hatten, den Fehler jederzeit nachstellen zu können.

Dazu nutze ich nun folgendes Skript, welches ich in einer Batch-Datei nutze:

net stop wuauserv
REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f
REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v DetectionStartTime /f
Reg Delete "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v NextDetectionTime /f
net start wuauserv
wuauclt /detectnow

Nach einer gewissen Zeit werden mir nun, die immer noch fehlerhaften Updates zur Installation angeboten. Mit diesem Skript wird allerdings generell alle vom WSUS-Server zur Verfügung gestellten Pakete geprüft, so dass es auch bei Installationsroutinen genutzt werden kann.

Bei 32-Bit-Systemen habe ich die acctinfo.dll schon häufiger genutzt, um zum Beispiel das Passwort-Ablaufdatum oder auch die SID eines Benutzers zu ermitteln. Heute wurde ich allerdings angesprochen, wie das Tool unter einem Windows 7-System, welches auf der 64-Bit-Technologie basiert, eingesetzt werden kann.

Die Dll ist Bestandteil eines Tool-Packs “Account Lockout and Management Tools”, welches unter dem folgenden Link heruntergeladen werden kann.

Download

Nach dem Entpacken sollte die DLL sowie die Datei “lockoutstatus.exe” in den folgenden Pfad kopiert werden:

%SystemRoot%\SysWOW64\

Anschließend muss der folgende Befehl mit administrativen Rechten ausgeführt werden, um die DLL in das System zu importieren:

regsvr32.exe %SystemRoot%\SysWOW64\acctinfo.dll 

Wenn man nun die Konsole des SnapIns “Active Directory Benutzer und Computer” öffnet, erhält man bei den direktem Benutzerobjekt trotzdem nicht die zusätzliche Registerkarte.

Hierfür muss eine Konsole in einer 32-Bit-Umgebung gestartet werden. Dieses kann entweder durch das Öffnen der Manangment Konsole im 32-Bit-Kontext und dem Einbinden des SnapIns durch den folgendne Befehl:

mmc.exe -32

Ein weiterer Weg ist der Aufruf des direkten SnapIns; ebenfalls im 32-Bit-Kontext:

dsa.msc -32

Eine weitere und nicht unwerwähnte Möglichkeit ist die entsprechende Erweiterung für 64-Bit-Systeme zu nutzen, die unter dem Dateinamen “acctinfo2.dll” auch in einer 64-Bit-Version erhältlich ist. Diese ist allerdings nicht seitens Microsoft supportet.

Des Weiteren ist darauf hinzuweisen, dass der zusätzliche Reiter nur erscheint, wenn man direkt das Objekt aus dem Objektbaum öffnet und nicht über die auch im SnapIn implementierte Suche aufruft.  

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.