Archiv der Kategorie: Microsoft

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

Veröffentlicht am von — 8 Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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

Exchange 2010 bestehendes (nicht selbstsigniertes) Zertifikat verlängern

Veröffentlicht am von — 4 Kommentare ↓

Die Verlängerung eines bestehenden öffentlichen Zertifikates unter Exchange 2010 (SP2) ist ohne Änderung des Privaten Schlüssels interessanter als gedacht. Das Erstellen einer neuen Zertifikatsanforderung oder einer Verlängerungsanforderung ist in der EMC kein Problem (Serverkonfiguration -> oben Server auswählen -> unten rechte MT auf das ablaufende Zertifikate und ‚erneuern‘ auswählen), aber was tun wenn man schon ein Zertifikat besitzt, das die Zertifizierungsstelle direkt verlängert? Diese liefert das Zertifikat in der Regel als DER (respektive PEM) aus und man muss dieses „nur“ noch in den Exchange importieren.

Exchange den Request nach dem „Abschließen der Anforderung“ immer noch als solchen an und lässt es auch nicht zu, diesem Zertifikate zuzuordnen, weil der Private Schlüssel fehlt:

Was man in der MMC -> Snap-In hinzufügen -> Zertifikate -> Lokales Computerkonto auch sehen kann:

Die EMC scheint an dieser Stelle ihre eigenen Voraussetzungen für eine erfolgreiche Zertifikatsverlängerung eines bestehenden Zertifikates ohne Änderungen nicht zu erfüllen. Di zugehörigen Anleitungen und TechNet Artikel verweisen immer auf „New-ExchangeCertificate“, das aber einen neuen Request oder gleich ein selbstsigniertes Zertifikat erstellen möchte. Exchange 2010 bestehendes (nicht selbstsigniertes) Zertifikat verlängern weiterlesen→

Windows LiveMail – Updatefehler (Adminrechte für das Update/ Deinstallation)

Veröffentlicht am von — Keine Kommentare ↓

LiveMail erzeugt manchmla Fehler, das nicht ausreichend Rechte für das Update oder die Deinstallation vorhanden wären

Lösung:

Nach der Neuinstallation sollte der Postfachinhalt und alle Kontoeinstellungenwieder zur Verfügung stehen, denn das LiveMail-Profil und der Anwendungsdatenordner (%APPDATA%…..) wird normalerweise nicht entfernt.