Archiv der Kategorie: Microsoft

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.

Exchange 2007/2010 „INSUFF_ACCESS_RIGHTS“

Veröffentlicht am von — 7 Kommentare ↓

Beim Verschieben eines Postfaches unter Exchange 2007/2010 oder beim Delegieren eines „Senden-als“ Rechtes in der Management Console (EMC) kann es vorkommen das eine Fehlermeldung wie diese auftaucht:

Fehler:
Fehler bei Active Directory-Vorgang mit dc.foo.ba. Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus.
Active Directory-Antwort: 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
. Der Benutzer verfügt nicht über die erforderlichen Zugriffsrechte.

Wie der Fehler sagt, gibt es nicht die passenden Rechte. Andrs als man im ersten Moment vermuten mag, liegen die Send-As Rechte und deren Kollegen immer noch im ACE (Access Control Entry) im ActiveDirectory. In der Regel hat ein Domänen-Admin diese Rechte auch; manches mal hat das Objekt diese aber nicht (mehr) geerbt.

Lösung: Erben der Rechte im Objekt wieder einschalten.

Active Directory und Benutzer (mit erweiterten Eigenschaften) -> Benutzer suchen -> Rechtsklick auf Eigenschaften -> Tab „Sicherheit“ -> „Erweitert“ -> „Vererbbare Berechtigungen des übergeordneten Objektes einschließen“ einschalten. Fertig.

Ab jetzt klappts auch wieder mit delegierten Rechten und dergleichen.

Office365 Exchange Synchronisationsfehler bei einer Shared-Mailbox

Veröffentlicht am von — Keine Kommentare ↓

Folgendes Problem taucht in sehr vielen Office365-Accountsauf; interessanterweise nicht nur da, sondern auch in Exchange2010 on-premise Clustern.

  • Office365 Exchange Online (oder Exchange 2010)
  • Ein Benutzerpostfach als „Öffentliche Ordner“ ersatz erstellt (http://help.outlook.com/en-us/140/ee441202.aspx)
  • Outlook 2010 mit eingeschaltetem Cachemode
  • E-Mail und Exchange funktionieren soweit fehlerfrei
  • Dann tritt dieser Synchronisationsfehler mit enervierender Regelmäßigkeit auf:
17:46:42 Synchronisiererversion 14.0.6117
17:46:42 Postfach "Chuck Norris" wird synchronisiert
17:46:42 Änderungen im Ordner 'öffentlicher Ordner - Posteingang' auf dem Server werden synchronisiert
17:46:42 Download von Server "GNGNAMSTYLE0411.mailbox.outlook.com"
17:46:42 Fehler bei der Synchronisierung des Ordners.
17:46:42                  [80070005-508-80070005-560]
17:46:42                  Sie besitzen nicht die erforderlichen Berechtigungen, um diesen Vorgang auszuführen. Wenden Sie sich an die Kontaktperson dieses Ordners oder an Ihren Administrator.
17:46:42                  Microsoft Exchange-Informationsspeicher
17:46:42                  Weitere Informationen zu diesem Fehler erhalten Sie unter der folgenden URL:
...
17:46:42 Vorgang abgeschlossen

 

Manchmal hilft es den Cachemode abzuschalten. aber da Outlook 2010 ja oft grade wegen diesem Features genutzt wird, ist das natürlich keine Alternative.

Lösung

(Veröffentlicht von Marcus Strehlow [MSFT Support] am 12. September 2012)

es ist so dass wenn [man] Änderungen an einer Shared Mailbox vornimmt, im Sinne von Mails verschieben, oder auch dorthin senden, wird ein solcher Fehler generiert. Dieser Fehler verschwindet normalerweise wenn die Änderungen im Exchange Cluster propagiert wurden. Wenn jedoch die Mailbox laufend modifiziert wird, ist es momentan leider unumgänglich diese Meldungen zu bekommen.

Sprich: Ignorieren. Microsoft has confirmed this to be a problem but this Behavior is By Design. Fragt sich nur warum das immer alles so geheim ist.