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…

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:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]

[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]

[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]

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.

Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx 

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 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:

Der Aufruf dazu lautet:

Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1}

(CurrentState ist der Zustand der Anfroderung; “1” bedeutet, sie ist neu und unbearbeitet, “4” bedeutet z.B., sie ist bereits genehmigt)

Mittels Format-Table o.ä. könnte man die Ausgabe noch aufbereiten:

Nun lässt sich diese Ausgabe z.B. in eine E-Mail verpacken. Ein komplettes Skript könnte dann so aussehen:

$FromAdr = admin@abc.de
$ToAdr = receiver@abc.de
$SMTPSrv = send.abc.de
$MailSubject = "New SCCM Application Approval Request"

If((Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | Measure-Object).Count -gt 0)
{
    $Mailtext = Get-CMApprovalRequest | Where-Object {$_.CurrentState -eq 1} | ft Application,User,Comments -Auto
    Send-MailMessage -from $FromAdr -to $ToAdr -subject $MailSubject -body $Mailtext -smtpServer $SMTPSrv
}

Für den Microsoft Certified Specialist in Azure muss mindestens eine dieser beiden Prüfungen abgelegt werden:

• 70-532: Developing Microsoft Azure Solutions

• 70-533: Implementing Azure Infrastructure Solutions

Um den Microsoft Certified Solutions Associate in Office 365 zu erreichen müssen die beiden folgenden Prüfungen abgelegt werden:

• 70-346: Managing Office 365 Identities and Requirements

• 70-347: Enabling Office 365 Services

Die Voucher zum kostenlosen Ablegen der Prüfungen können von hier bezogen werden: http://borntolearn.mslearn.net/goodstuff/p/mcp.aspx

Das Angebot ist nur begrenzt gültig und maximal bis zum 31. Dezember 2014 verfügbar – schnell sein ist also die Devise!

PS: 70-532 ist ein Beta-Examen!

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.

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.

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.

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.

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: