ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Wie finde ich den Benutzer (oder das Objekt) zu dem eine Exchange E-Mailadresse gehört?
get-recipient -results unlimited | where {$_.emailaddresses -match "[email protected]"} | select name,emailaddresses,recipienttype
(dies ist nur eine Notiz weil ich ständig das -match(ing) vergesse) 🙂
Exchange 2010 (SP1) möchte seine Datenbanken schon mal nicht freiwillig verschieben, wenn man die interne URL der OWA/OAB Dienste auf http umgestellt hat (um Zertifikatsfehler|kosten|Umstand zu vermeiden). Die Fehlermeldungen dazu sind auch recht kreativ, vor allem in EMC und EMS unterscheidlich.
Der Status von Datenbank "Mailbox Database 0110421406" konnte nicht abgerufen werden. + CategoryInfo : InvalidOperation: (Mailbox Database 0110421406:DatabaseIdParameter) [Move-DatabasePath], InvalidOperationException + FullyQualifiedErrorId : 79FDD20B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath
In diesem Fall reicht es aus, den SSL-erzwingen Haken von der ECP-zugehörgien IIS-Site zu entfernen:
IIS-Manager -> Site -> SSL-Einstellungen -> SSL Erzwingen Haken entfernen -> Übernehmen.
Dann eine Rauchen gehen oder anders etwa 5 Minuten Zeit vertrödeln. EMC neu starten und schon geht wieder alles. Das das NATÜRLICH nicht die goldene Lösung ist dürfte dem Lokalen Administrator klar sein, aber wer will schon für seine internen Sitehostheader extra Zertifikate beantragen oder eine extra-PKI bauen?
Wäre das nicht schön, wenn der zentral gesteuerte Import der „Sicheren Absender“ (bzw. „Blockierte Absender“ in den Outlook-Lokalen Junkmailfilter funktionieren würde? Outlook 2007 und 2010 können via GPO die JunkSaveSenders zentral importiren. Theoretisch jedenfalls.
Dafür gibt es immerhin auch ein paar schicke offizielle Gruppenrichtlinienvorlagen (GPO ADM Template) von Microsoft
Leider funktioniert das auch nach der Anwendung nicht ganz so richtig, jedenfalls nicht in zwei Fällen: Erstens wenn ein Benutzer mehr als ein Postfach verbunden hat und zweitens wenn er die Liste zudem manuell pflegen möchte (oder das bereits getan hat). Dann bleiben die Listen in der Anzeige immer leer, bzw. der Schlüssel wird beim Outlook-start auf „0“ zurückgesetzt.
Die angezeigte SafeList ist immer nur in Outlook die Liste der sicheren Absender, sollte aber immer synchron zu den Einträgen des Postfaches auf dem Exchange Server sein – sozusagen sieht man nur die Offine-Listenversion des Clients. Diese Liste muss bevor sie auf anderen Maschinen oder im OWA „zieht“ einmal auf den Exchange refresht werden. Das lässt sich auf zwei Arten erzwingen:
Update-SafeList -id “Postfach”
Naja, jedenfalls erklärt das Exchange-Team die erzeungene aktualisierung so 🙂
Der zweite große Fall ist schon ein wenig anspruchsvoller: die Übernahme einer SafeList von einem Benutzerpostfach auf ein anderes. Das geht am besten (sofern das Refresh von oben geklappt hat) am einfachsten via Powershell mit diesem fünfzeiler. Das Script ist ein bisschen umständlich, aber so ist das anpassen der Liste zur Laufzeit ebenfalls möglich:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 Get-MailboxJunkEmailConfiguration -identity "BENUTZERNAME" | select -ExpandProperty BlockedSendersAndDomains > c:tempBlockedSenders.txt $Temp = Get-MailboxJunkEmailConfiguration [email protected] $Temp.BlockedSendersAndDomains = get-content C:tempBlockedSenders.txt Set-MailboxJunkEmailConfiguration -Identity [email protected] -BlockedSendersAndDomains $Temp.BlockedSendersAndDomains Remove-Item c:tempBlockedSenders.txt
Danke an den Dariusz G. für den Schnipsel und die aufwändige Recherche dazu. Wir hoffen das dieser Artikel vielleicht anderen Administratoren bei diesem fies zu suchenden Fehler weiterhilft.
Exchange 2010 bringt eine neues Feature mit, welches mit geringem Aufwand erlaubt eine Verteilerliste von Mails von außen abzuschotten. Dummerweise ist dies bei neuen Verteilerlisten standardmäßig aktiv. Legt man nun unwissender Weise eine neue Verteilerliste an und trägt wie in Exchange 2003/2007 gewohnt E-Mail-Adresse und Mitglieder/Empfänger ein, ist die Liste innerhalb der eigenen Organisation problemlos erreichbar. Versucht man jedoch eine Mail von außen an die angegebene E-Mail-Adresse zu senden erhält man folgende Meldung (hier die Ausgabe des Microsoft Remote Connectivity Analyzer).
550 – Mailbox unavailable. The server response was: 5.1.1 User unknown
Um die Verteilerliste von außen erreichbar zu machen, ruft man die Eigenschaften der Verteilerliste auf und wählt dort im Tab Nachrichtenübermittlungseinstellungen per Doppelklick den Punkt „Einschränkungen für die Nachrichtenzustellung“ und entfernt den Haken bei „Authentifizierung aller Absender anfordern“.
Die Änderung wirkt sofort und ein erneuter Test von außen geht erfolgreich aus.
Bei einer Migration von Exchange 2003 nach 2007/2010 kann es mal zu einem seltsamen Effekt kommen. Nach Abschluss der Postfachmigration wird ja in der Regel die „Default Policy“-Empfängerrichtlinie via
Set-EmailAddressPolicy „Default Policy“ -IncludedRecipients AllRecipients
umgestellt. Dies muss auch sein, da sich sonst die E-Mailadressrichtlinie (ab 2007 heisst das nicht mehr Empfängerrichtlinien, sondern Adressrichtlinie) nicht mit der EMC bearbeiten lässt. In der Regel klappt das auch. Manchmal gibt es aber den kreativ anmutenden Fehler:
Set-EmailAddressPolicy : Die Empfängerrichtlinie ‚Default Policy‘ mit Postfach-Manager-Einstellungen kann nicht über die aktuelle Version der Exchange-Verwaltungskonsole verwaltet werden
Liesst sich ein bisschen wirsch. Nach viel suchen kommt heraus: Der Postfach-Manager ist eine superselten genutzte Funktion von Exchange 2003. Inhalte aus Postfächern können damit automatisch bearbeitet werden, z.B. kann der fiese Admin alles was älter als 30 Tage ist damit löschen (oder ausdrucken oder so). Exchange 2007/2010 kennt das nicht mehr; Microsoft hat die Funktion an sich allerdings deutlich erweitert und der geneigte Admin kennt diese nun als „Richtlinien zum Verwalten von Nachrichtendatensätzen„. In meinem speziellen Fall stammen die Einstellungen von einer Exchange-nahen Faxlösung aus der frühen Steinzeit.
Lösung: Einfach alle alten Postfach-Managereinstellungen (beabsichtigt oder nicht) entfernen. Und das geht so:
Danach geht auch die Übernahme mir set-EmailAddressPolicy auch sofort.
