Archiv der Kategorie: Microsoft 365

Office365 Exchange – Weiterleiten von E-Mails nur ohne Quelladresse

Veröffentlicht am von — Keine Kommentare ↓

Der Office365 Exchange Server hat eine ärgerliche Funktionseinschränkung. Da ich jetzt schon ein paar mal über genau diese Frage gestolpert bin, sei die Sachlage nun hiermit für jeden dargelegt. Vielleicht ändert Microsft das in der nächsten Wave ja, das wäre fein.

Der Effekt ist schnell erklärt: Wenn man in Outlook eine E-Mail Weiterleitet, bleibt die Adresse des Senders erhalten:

Von: Foo Bar [mailto:[email protected]]

Wenn man genau das selbe in der Outlook WebApp tut, ist der Absender plötzlich verschwunden:

 Von: Foo Bar

Dieses Verhalten von Exchange Online ist so „korrekt“. Die offizielle Antwort (Zitat, die Fehler sind nicht von mir) des MSFT-Supports lautet (Marketing-Blasen sind durch „…“ ersetzt):

Outlook Web App […] etwas beschänkte Funktionalität im Vergleich zu Outlook […]. Deshalt […] von Dir gewünschte Funktion kann man nicht machen.

Damit ist die Exchange Online WebApp so schick die auch ist, für mich in vielen Fällen praktisch nutzlos. Ich ich leite viele E-Mails zur direkten Bearbeitung an den passenden Mitarbeiter weiter, aber wenn der neue Empfänger dem Absender nicht zurückschreiben kann, ist das natürlich sinnlos. Ich persönlich kann mit natürlich behelfen, aber ich muss gestehe von einem OutlookWebApp Client doch die Fähigkeit zur Weiterleitung einer E-Mail erwartet zu haben.

Interessanterweise ist das in Exchange 2010 an sich durchaus möglich; On-Premise Kunden haben an dieser Stelle funktional also die Nase vorn.

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

Office365 Exchange Online Powershell Zugang

Veröffentlicht am von — Keine Kommentare ↓

Für den schnellen Zugang zur Office365 Powershell:

$Cred = Get-Credential
 $shell = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
 Import-PSSession $shell

Sollte beim Import dieser Fehler auftreten:

Import-Module : Fehler beim Laden der Formatdatendatei: Microsoft.PowerShell, , C:Users~~AppDataLocal….format.ps1xml: Aufgrund der folgenden Validierungsausnahme wurde die Datei übersprungen: Die Datei C:Users~~AppDataLocalTemp... kann nicht geladen werden, da die Ausführung von Skripts auf diesem System deaktiviert ist. Weitere Informationen erhalten Sie mit "get-help about_signing"..
 Bei Zeile:3 Zeichen:30
 + Import-Module <<<< -Name $name -Alias * -Function * -Prefix $prefix -DisableNameChecking:$disableNam
 eChecking -PassThru -ArgumentList @($session)
 + CategoryInfo : InvalidOperation: (:) [Import-Module], RuntimeException
 + FullyQualifiedErrorId : FormatXmlUpateException,Microsoft.PowerShell.Commands.ImportModuleCommand

Hilft es sofort, die locale ExecutionPolicy anzupassen:

Set-ExecutionPolicy RemoteSigned

Für Administratoren die die Exchange-Tools auch (korrekterweise) auf Ihrer lokalen Maschine installiert haben, ist folgende Parameter sinnvoll:

Import-PSSession $shell -AllowClobber

Der Parameter „-AllowClobber“ überschreibt die lokale Registrierung der Kommandos mit der passenden Remote-Version. Danke an Dariusz und  The RDP Files für den hilreichen Tipp.

 

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.