Outlook 2007/2010 JunkMail sichere Absender Liste importieren (so gehts wirklich)

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.

Das offizielle Vorgehen dafür funktioniert so

  • Im Schlüssel HKCU:SoftwarePoliciesMicrosoftoffice14.0outlookoptionsmail die folgenden Werte aktualisieren:
    1. JunkMailImportAppend (DWORD) auf 1
    2. JunkMailSafeSendersFile (String) auf „c:pfadfile.txt“
    3. JunkMailImportLists (DWORD) auf 1

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:

  • Im Outlook WebApp (einfach einen Eintrag in der Liste bearbeiten)
  • Via Powershell
    • 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.

Windows Live ist tot. Endlich.

Microsoft macht endlich kurzen Prozess. Der Konzern wird mit seiner eher weniger erfolgreichen Dachmarke für Webdienste, „Windows Live“, aufräumen und sie zum Start von Windows 8 in der zweiten Jahreshälfte nicht mehr verwenden. Anders gesagt: Live ist tot.

Natürlich bekommt jetzt alles neue Namen, aber ein Wunder ist geschehen: Laut aktuellem Planungsstand sind das sinnvolle Namen! Kaum zu glauben. Aber Chris Jones (der Kopf der windows-Live-Gruppe bei der Microsoft) bloggt doch tatsächlich die Änderungen und die neuen Namen.

Und wird die Namenswelt aussehen:

Dienst Windows 8 Windows Phone Web Alter Name
Zugang Microsoft account Microsoft account Account.live.com Windows Live ID, Passport
Storage und Dokumente SkyDrive app, SkyDrive Desktop SkyDrive app, Office app SkyDrive.com FolderShare, Live Mesh, Windows Live Mesh
Mail Mail app Mail app Hotmail.com Windows Live Mail, Outlook Express
Kalender Calendar app Calendar app Calendar.live.com Windows Live Mail, Windows Calendar
Kontakte People app People app People.live.com Windows Contacts
Messaging Messaging app Messaging app Integrated in Hotmail and SkyDrive MSN Messenger
Medien Photos app, Photo Gallery, Movie Maker Photos app, Camera Roll Photos.live.com Windows Live Photo Gallery, Windows Live Movie Maker

Windows 7 msg.exe – Fehler xxx beim Abrufen der Sitzungsnamen

Der schöne (und schreckliche zugleich) net-send Nachrichtendienst wurde mit dem Erscheinen von Vista leider glücklicherweise entsorgt. Natürlich nicht ersatzlos, denn das wäre ja langweilig 🙂

Der neue Ersatz dafür heisst „msg“ und tut im Prinzip dasselbe wie Net Send damals. Leider verschweigt das Tool in der Kommandozeilen-Auskunft, dass die Nachrichten nicht mehr via Nachrichtendienst versendet werden, sondern via RPC-Call an die Windows-Terminaldienste. Im Sinne einer korrekten Zuordnung der Nachrichten an verschiedene gleichzeitig arbeitende Nutzer auf einem Server macht das zwar durchaus Sinn, setzt aber technisch gesehen voraus, das der Windows 7 Terminaldienst auch weiss das er Remote-Aufrufe annehmen soll (was er via Remote-Registry tut). Zudem funktionieren diese Zustellungen nur zuverlässig in einer ActiveDirectory Domäne. Daher hier auch nur die Anleitung zu einer Gruppenrichtlinie (GPO) die das erledigt.

Und so macht man das schöne msg-Kommando wieder unter Vista und Windows 7 einsatzfähig:

  1. Neue GPO erstellen, verknüpfen und bearbeiten
  2. Computerkonfiguration > Einstellungen >Windows Einstellungen > Registrierung
  3. Ein neues Registrierungselement erstellen:

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminalServer

    AllowRemoteRPC (REG_DWORD) auf „1“ setzen

Und schon kann mit msg <benutzername> /SERVER:<computername> „<nachrichtentext>“ wieder fröhlich gesendet werden.

 

 

Windows Server 2008R2 (Event 2886) – Sicherheit des Verzeichnisservers erhöhen

Nach der Promovierung eines 2008R2 Servers zum DC erscheint in den Eventlogs gerne mal die Warnung mit der Ereignis-ID 2886:

Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Ereignis-ID: 2886
Aufgabenkategorie: LDAP-Schnittstelle
Beschreibung:Sie können die Sicherheit dieses Verzeichnisservers deutlich verbessern, indem Sie den Server so konfigurieren, dass SASL-Bindungen (Verhandlung, Kerberos, NTLM oder Digest), LDAP-Bindungen ohne Anforderung einer Signatur (Integritätsüberprüfung) und einfache LDAP-Bindungen über eine Klartextverbindung (ohne SSL-/TLS-Verschlüsselung) zurückgewiesen werden. Selbst wenn keine Clients derartige Bindungen nutzen, erhöht sich die Sicherheit des Servers durch diese Konfiguration beträchtlich. Einige Clients benötigen möglicherweise unsignierte SASL-Bindungen oder einfache LDAP-Bindungen über eine Verbindung ohne SSL-/TLS-Verschlüsselung […]

Diese Sicherheit zu erhöhen ist kein Problem. wichtig zu wissen ist, das es gewisse Inkompatibilitäten mit Windows XPSP2 und darunter (bzw. Server2003SP1) geben kann.

So führt man die Signaturpflicht für LDAP-Bindungen ein:

  1. Gruppenrichtlinienverwaltung öffnen
  2. „Default domain Policy“ bearbeiten
  3. Gehe zu: Computerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen
  4. „Domänencontroller: Signaturanforderungen Eigenschaften für LDAP-Server“ auf „Signatur erforderlich“ stellen.

Routing und Ras startet nicht mit Fehler „8007042a“ (meistens auf einem SBS)

Der Routing und Ras Dienst startet nicht (mehr), NPS geht. Der Fehler lautet „ein Dienstspezifischer Fehler ist aufgetreten“. Im Ereignisprotokoll erscheint nach dem start der RRAS-Dienste meistens der Hinweis:

C:WindowsSystem32iprtrmgr.dll kann nicht geladen werden. (Quelle: RemoteAccess, Event 20103)

Dank der umfassenden Integration der IPv6-Protokolls in den SBS passiert das gerne, wenn man die v6-Bindung entfernt. In der Registry dann einfach den Schlüssel HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRemoteAccessRoutermanagersIpv6 restlos entfernen.

Spannend: Bei einer Neuinstallation des RRAS-Rolle (und Dienste) geht diese von einer vorhandenen Verbindungskonfiguration aus, bringt also keine Abhilfe.