Mit dem SQL-Management Studio auf die WSUS SQL Instanz zugreifen

Der WSUS Server (respektive die „Windows Server Update Services Rolle“) bringt auf Wunsch ihre eigene SQL-Server Instanz (Microsoft SQL Server Windows Internal Database (64-bit)“ mit. Freiwillig lassen sich die Einstellungen dieses Servers nicht ändern, aber mit den SQL-Tools kann man auch diesen SQL-Server konfigurieren. So lässt sich zum Beispiel der Arbeitsspeicher der WSUS-Instanz beschränken oder die CPU-Nutzung reglementieren. Natürlcih sind so auch eigene Auswertungen der WSUS-Daten mit Excel oder Access möglich.

So gehts:

  1. Herunterladen des SQL Server Express Management Studios
  2. Verbinden mit der lokalen Instanz:
    1. \.pipemssql$microsoft##sseesqlquery („Servername“)
    2. Windows-Authentifizierung mit einem lokalen Administrator-Konto

Inaktive und alte Computerkonten im ActiveDirectory finden

Ein offenes Geheimnis unter Administratoren ist, das kaum jemand sein Active Directory vollumfänglich pflegt. Computer werden getauscht, neu installiert oder gewechselt ohne das jemand die verwaisten Konten entfernt. Doch wie findet man diese Einträge möglich schnell?

Computer ändern ihre Computerkennwort für die Domänenanmeldung selbstständig alle 30 Tage (unter NT4 waren das noch 7 Tage). Daher ist eine längere Kennwortänderung schon ein recht gutes Indiz für „tote“ Computerkonten.

So bekommt man (ab der Windows 2003 pur Funktionsebene) veraltete Computerkonten:

dsquery computer -stalepwd 50

„stalepwd“ gibt die Anzahl abgelaufenen Tage von „heute“ aus an. Die Ausgabe des Kommandos dann auch direkt in dsrm umgeleitet werden, um die toten Rechner direkt zu löschen:

dsquery computer -stalepwd 50 | dsrm -noprompt -c

Windows Server 2008R2/2012/2012R2 Autologon (in einer Domäne)

Server 2008R2 AutologonWindows Server seit 2008 lassen nach einem Domain-Join den Haken „Benutzer müssen beim start des Computers Name und Kennwort eingeben“ verschwinden, der vorher noch in „control userpasswords2“ sichtbar war.

Trotzdem kann ein Windows Server (auf Windows Server 2012 und 2012R2) natürlich immernoch automatisch eingeloggt werden. Dazu müssen diese Schlüssel gesetzt werden (oder noch einfach: gleich die ganze .reg-File importiert werden):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoAdminLogon"="1"
"DefaultUserName"="BENUTZER"
"DefaultPassword"="KENNWORT"
"DefaultDomainName"="DOMÄNE"

Über das Sicherheitsproblem, das ein Klartext-Kennwort in der Registry in einem für jeden Benutzer lesbaren Schlüssel impliziert, verlieren wir aber natürlich kein Wort 🙂

Der orginal-KB dazu stammt aus den Windows2000-Zeiten und findet sich unter http://support.microsoft.com/kb/324737/de

Limitierung der Weiterleitung von Nachrichten in Outlook-Regeln *Update

Manchmal möchte man mehrere Menschen von freudigen Ereignissen in Kenntnis setzen. In einigen Fällen sogar ganz automatisch – durch das weiterleiten einer E-Mail Nachricht. Am besten entlang einer Regel, wie zum Beispiel:

„Wenn eine E-Mail von <meiner Freundin> eintrifft und <das baby ist da> ODER <baby geboren> im Betreff enthält, diese an <Kollegen Bekannte ….> Weiterleiten“.

Das klappt in den meisten Fällen auch ganz gut. Manchmal klappt das einfach nicht und man findet den Fehler nicht. Auch Admins sind gerne Ratlos. Die Lösung liegt in diesem Artikel zu Exchange und office365. Weiterleitungen per Outlook-Regel sind generell limitiert. Natürlich wird dem Nutzer weder eine angemessene Fehlermeldung präsentiert, noch ein Eventlogeintrag erstellt oder ähnliches (hilfreiches) getan. Es passiert schlicht nichts. Danke für diesen Satz:

Die Anzahl der Adressen, an die Sie weiterleiten können, kann abhängig von den Einstellungen für Ihr Konto beschränkt sein. Wenn Sie mehr Adressen hinzufügen, als zulässig sind, funktioniert Ihre Weiterleitungsregel nicht. Wenn Sie eine Weiterleitungsregel mit mehr als einer Adresse erstellen, testen Sie die Funktionsfähigkeit der Regel.

Genau. Testen Sie die Regel lieber Anwender.

Die Antwort lautet: Dieses Limit ist generell 10, die Quelladresse mitgezählt. Warum das so ist weiss niemand und wie man das ändert auch nicht. Der passende Support-Call mit dem Office365-Support Team ist noch offen.

*Update (15. Oktober 2012)

Bezüglich Ihrer Serviceanfrage xxxxxxx möchte ich Ihnen mitteilen, dass Sie dieses Limit nicht ändern können, da dies serverseitig eingerichtet ist. Dies würde dann bedeuten, dass dies für alle Konten gilt und Auswirkungen auf die Auslastung des Servers hätte.

In Ordnung. Aber warum gibt es dann nicht wenigstens eine sinnvolle Fehlermeldung?

Office365 Kennwörter niemals ablaufen lassen

Die Vorgabe von Microsoft in Office365 ein maximales Kennwortalter von 90 Tagen als Standardwert für alle Benutzer (obligatorisch) zu verwenden ist zwar an sich recht sicher (wir erinnern uns an die secure computing plattform maxime „secure by default„), aber auch deutlich unkomfortabel. Vor allem in Netzwerken mit bisher eher laxen Sicherheitsvorkehrungen schürt man damit dem Cloud-Unmut. Selbstverständlich lässt Micosoft auch keine Änderung an diesen Vorgaben via GUI zu.

Kennwörter niemals ablaufen lassen

  1. Herunterladen und installieren der Office 365-Cmdlets (und der connect-Tools, falls notwendig)
  2. Powershell starten, Module importieren, verbinden und Kennwörter nicht ablaufen lassen:
import-module MSOnline
Connect-MsolService
Get-MsolUser | Set-MsolUser -PasswordNeverExpires $True

Herausfinden, ob ein Kennwort so eingerichtet ist, dass es nie abläuft

Get-MSOLUser -UserPrincipalName <user ID> | Select PasswordNeverExpires

Oder gleich für alle Benutzer anzeigen:

Get-MSOLUser | Select UserPrincipalName, PasswordNeverExpires

Ein Kennwort so einrichten, dass es abläuft

Set-MsolUser -UserPrincipalName -PasswordNeverExpires $false

Oder gleich für alle
Um die Kennwörter aller Benutzer in einem Unternehmen so festzulegen, dass sie ablaufen, führen Sie folgendes Cmdlet aus:

Get-MSOLUser | Set-MsolUser -PasswordNeverExpires $false