Manchmal besteht der Wunsch, auf einem Windows-System eine automatische Anmeldung nach dem (Neu)Start durchzuführen. Dies ist mit sehr einfachen Mitteln möglich und funktioniert sowohl bei Client- als auch Server-Betriebssystemen, auch bei älteren. Nötig ist dazu nur der Zugriff auf die Registry und ein passendes Benutzerkonto.
Als erstes wird der Registrierungseditor mittels “regedit.exe” geöffnet:
Dort muss zu dem Schlüssel unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon navigiert werden.
Abschließend sind folgende Schlüssel nötig (alle als Zeichenfolge, REG_SZ)
AutoAdminLogon = “1”
DefaultUserName = BENUTZER
DefaultPassword = PASSWORT
DefaultDomainName = DOMÄNE
So etwa wie im Screenshot…
Das war es schon gewesen. Beim nächsten Neustart ist die automatische Anmeldung aktiv…
Mit der Zeit sammeln sich auf einem WSUS (Windows Server Update Service) einige Updates an. Da können auch schnell mehrere hundert Gigabyte an Daten zusammenkommen. Nicht jedes Update, welches auf dem WSUS gespeichert ist, wird aber noch benötigt. Daher ist es aus Gründen der Speicherplatzeffizienz sinnvoll, von Zeit zu Zeit etwas aufzuräumen. Dafür gibt es schon seit längerem einen passenden Assistenten in der WSUS-Konsole:
Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.
Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:
Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.
Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.
Auch wenn die Tatsache selbst nicht neu ist möchte ich den folgenden Fakt etwas genauer beleuchten, da immer mehr Unternehmen Hyper-V für produktive Virtualisierungszwecke verwenden.
Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.
Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).
Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):
Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.
Glücklicherweise kündigt sich das bereits vorab an:
Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.
Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.
Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:
Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!
(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)
Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!
Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:
(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)
Der System Center Configuration Manager (SCCM) 2012 R2 bietet die Möglichkeit, Anwendungen für Benutzer als “verfügbar” bereitzustellen. In dieser Kombination (und nur dort) lässt sich auch eine Genehmigungsanforderung einschalten:
Der Benutzer hat nun die Möglichkeit, die Software über den Application Catalog (Anwendungskatalog) anzufordern:
Wurde die Anforderung vom Benutzer ausgelöst, so taucht sie dann in der SCCM-Konsole auf:
Leider ist es nicht vorgesehen, dass man das Eintreffen einer neuen Anforderung per E-Mail o.ä. meldet und in der Regel sitzt kein Admin den ganzen Tag vor der GUI und wartet auf neue Anforderungen. Also muss man eine andere Lösung schaffen, dies weitgehend zu automatisieren.
Eine Variante wäre, bei Eintreffen eben eine E-Mail zu versenden. Dazu muss man das Eintreffen einer Anforderung automatisiert feststellen können. Und dazu ist die PowerShell sehr gut geeignet:
Microsoft bietet einem Blog-Beitrag von Andrew Parson zufolge aktuell für Prüfungen über Prometric kostenlos an. Damit lassen sich 2 Zertifizierungen erreichen:
Für den Microsoft Certified Specialist in Azure muss mindestens eine dieser beiden Prüfungen abgelegt werden:
In der aktuell verfügbaren Technical Preview vom künftigen Windows Server (aktuell unter verschiedenen Namen bekannt, Windows Server 10, Windows Server 2015, Threshold, …) sind bereits einige Neuerungen in Hyper-V erkennbar. Einige davon möchte ich hier kurz ansprechen:
Production Checkpoints vs. Standard Checkpoints
Neben den bisherigen “regulären” Snapshots / Checkpoints (Im Windows Server 2015 als “Standard Checkpoints” bezeichnet) gibt es nun “Production Checkpoints” die explizit für Maschinen im Produktiv-Betrieb gedacht sind.
Hierbei wird mit Hilfe der Datensicherungstechniken des Gastbetriebssystems (bei Windows via VSS, bei Linux über den Systempuffer) ein Snapshot erzeugt, der auf Konsistenz ausgelegt ist. Sollte ein solcher Snapshot nicht möglich sein, wird auf einen regulären Snapshot ausgewichen (bei dem eben keine Konsistenz aller Daten gegeben ist). Wurde der Production Snapshot erfolgreich erzeugt, wird eine entsprechende Meldung ausgegeben:
Für den Production Snapshot muss die Windows Server Sicherung im Gast-System NICHT installiert sein:
Laufende Anwendungen werden bei dieser Snapshot-Technik nicht berücksichtigt. Nach einem Revert (Zurücksetzen au einen Snapshot) muss die VM neu gestartet werden, Anwendungen die zum Zeitpunkt des Snapshots liefen gehen dadurch verloren. Allerdings verhält sich das Gast-Betriebssystem so, wie nach einem regulären, sauberen Shutdown:
Hyper-V Manager Remote Management
Bereits frühere Versionen vom Hyper-V Manager haben es ermöglicht, von einem System aus mehrere Hosts unter einer GUI zu verwalten. Dabei fand das Login auf den Remote-Servern immer mit den Credentials des interaktiv angemeldeten Benutzers statt. Der neue Hyper-V-Manager macht es jetzt möglich, alternative Login-Daten anzugeben:
Damit wird es möglich, Maschinen in fremden Domänen, in Workgroups oder in der DMZ anzusprechen.
Der neue Windows Server (aktuell noch als “Technical Preview” bezeichnet) bringt auf den ersten Blick nicht so viele Neuerungen (zumindest optisch). Wenn man aber einfach mal via Servermanager neue Rollen und Features hinzufügt, fällt einem schnell auf, dass es hier doch viel Neues gibt:
Hier ist der “MultiPoint Server” als neue Rolle zu finden. Bisher war dies ein eigenständiges Produkt, welches separat heruntergeladen und installiert werden musste.
Bei den Features gefällt mir vor allem die Möglichkeit, Windows selber neu zu starten (“Soft Restart”), ohne die Hardware (incl. POST und allem was dazugehört) neu starten zu müssen. Dies bringt vor allem bei Updates deutlich kürzere Downtimes.
Die Funktionen werde ich demnächst im Detail testen und darüber berichten.
Wie Jim Alkove, Windows Enterprise Program Manager, in einem Blog-Artikel vor wenigen Tagen bekannt gegeben hat, wird es bei künftigen Betriebssystemen eine Änderung bezüglich Updates geben.
Enterprise-Kunden können dann aus einem von drei Pfaden wählen, der bestimmt, wie Updates verteilt werden. Ein Pfad sieht vor, alle Updates so schnell wie möglich zu bekommen und zu verteilen, um immer up-to-date zu sein. Ein weiterer Pfad sieht vor, nur die kritischen und Sicherheits-Updates zu bekommen. Der dritte Pfad wird ein Mittelweg zwischen den beiden Extremen sein.
Dabei soll auch die Möglichkeit bestehen, die eigenen Benutzer aufzuteilen und gruppenabhängig die Zuweisung zu einem dieser Pfade vorzunehmen.
Was Bestand haben wird ist, das Sicherheitsupdates und andere kritische Updates monatlich veröffentlicht werden. Vermutlich wie bekannt zum “Patch-Tuesday”.
Nun bleibt also abzuwarten, wie sich das alles entwickelt und wie Microsoft diese Ankündigungen umsetzt.
Seit dem 01. Oktober stehen nun neben der Technical Preview von Windows 10 auch die Previews für den kommenden Windows Server sowie für System Center bereit:
In 5 großen Bereichen soll es Änderungen beim Windows Server geben:
Infrastructure Upgrades
Networking
Storage
Remote Desktop
Identity and Access Management
Dies ist einem Blog-Artikel vom “Microsoft Server and Cloud Plattform Team” zu entnehmen.
Ein finaler Name für den neuen Windows Server steht noch nicht fest, aber ich vermute, dass er “Windows Server 2015” heißen wird. Über Details werde ich zeitnah berichten.
Den Download der Preview erhält man über die MSDN oder das Evaluation Center.
Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:
Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.
Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.
Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:
Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:
Was bleibt nun also? Eine Abfrage mittels WMI!
Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:
Will man statt den “internen” (teil kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:
Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName
Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:
