Bei Spam Filtering in Exchange 2007 ist das Festlegen bestimmter Server als “interne” Server wichtig für die richtige Funktionsweise des Connection Filtering Agents.

Wenn man nur eine reine Exchange Organisation hat, braucht man sich nicht weiter darum kümmern, da die Anti Spam Konfiguration alle Edge Server betrifft und damit alle eingehenden Nachrichten abdeckt. Hat man aber Nicht-Exchange Server, in meinem Fall einen Sendmail Server auf Windows und einen Postfix Server auf Linux welche Mail (ungefiltert) an die Exchange Organisation weiterleiten – sei es auch nur für einen einzelnen User, muss man diese Server – egal ob sie physisch im eigenen Netz sind, oder bei einem Provider oder Partner oder in einer Filiale stehen, als „Internal SMTP Servers“ definieren, da sie sonst von einem Filter, den wir später näher betrachten werden, nämlich dem Sender Reputation Filter auf die Blocklist gesetzt werden, weil sie ja in großen Mengen Spam in‘s Unternehmen bringen.

Sie auf die Whitelist zu setzen wäre auch der falsche Ansatz, da dann alle Nachrichten völlig ungefiltert angenommen werden.

Der einzig richtige Weg ist daher in der Powershell den Befehl:
Set-TransportConfig -InternalSMTPServers {IP}
auszuführen.

Wichtig ist, zu verstehen, dass der Connection Filter, der der erste in der Reihenfolge der Exchange Spam Filter ist, immer den letzten Nicht-Internen Server überprüft. Würden wir also unsere „Weiterleitungs-Server“ nicht mittels Set-TransportConfig als interne Server definieren, würden sie als externe Server vom Connection Filter behandelt werden.

Durch diese Konfiguration ergibt sich aber noch etwas weiteres, das man beachten muss: Dadurch dass der „Weiterleitungs-Server“ jetzt ein interner Server ist, kann es sein, dass der Server davor im Mail Header „RECEIVED FROM:“ als erster „fremder Server“ behandelt wird. Wenn dieser aber das Mail Programm des Absenders ist, liegt er möglicherweise auf einer dynamischen IP – daher ist es wichtig, keine DNSBL Listen zu verwenden, die alle dynamischen IP‘s sperren – das ist ohnedies etwas, was eigentlich gegen alle Regeln des SMTP Protokoll verstößt. Denn wenngleich Spam oft von dynamischen Adressen kommt, bedeutet das noch lange nicht, dass das sicher Spam ist, außerdem darf man sehr wohl auch auf dynamischen Adressen Server betreiben. – Gerade in Amerika ist das auch von den Providern fast immer erlaubt.

Q: Gibt es die Möglichkeit, nur die gleichzeitigen Zugriffe auf das auf einem Terminal Server installierte Office zu lizenzieren?

A: Nein – Siehe Seite 7 Microsoft Product Use Rights – „Der Zugriff auf Kopien der auf einem Netzwerkgerät installierten Software ist Ihnen nur von einem Gerät aus erlaubt, das für die Software lizenziert wurde.“ und „Das Gerät, das Sie für den Remotezugriff auf Software benutzen, muss für die gleiche oder höhere Version, darf jedoch nicht für eine niedrigere Version lizenziert sein.“ – Es gilt also zu beachten, dass Geräte, die eine niedrigere Version von Office 2010 oder eine ältere Version haben (etwa Home&Business 2010 als OEM Lizenz) nicht auf den Terminal Server zugreifen dürfen.

Q: Welche Editionen von Office 2010 sind geeignet für den Betrieb auf einem Terminal Server?

A: Alle Volumenslizenzversionen, also Office Standard 2010 und Office Professional Plus 2010 – Siehe „System Requirements for Office 2010“

Q: Welcher Nutzer/welches Gerät muss bei Microsoft Exchange Server 2010 nicht lizenziert werden?

A: siehe Seite 68 – Product Use Rights: „Sie benötigen keine CALs für einen Nutzer oder ein Gerät, der bzw. das auf Ihre Instanzen der Serversoftware zugreift, ohne direkt oder indirekt von Active Directory authentifiziert zu werden.“

· Product Use Rights:       http://www.microsoftvolumelicensing.com/Downloader.aspx?DocumentId=3010

· Product List:                      http://www.microsoftvolumelicensing.com/Downloader.aspx?DocumentId=3067

· Plan to deploy Office 2010 in a Remote Desktop Services (Terminal Services) environment

· System Requirements for Office 2010 – Microsoft Office Standard 2010

Windows 7 und Office 2010 SKUs

Alle Angaben ohne Gewähr!

In Outlook 2010 werden die Einträge für die Funktion für das Autovervollständigen von E-Mail Adressen nicht mehr lokal (im Profil des Users) in einer *.nk2 Datei gespeichert, sondern zentral am Exchange Server (und zwar in einer versteckten Nachricht) und somit kann von jedem Outlook Client auf den gleichen Cache zugegriffen werden.

Doch heute fragte mich ein Kunde, wie man denn bei einer Migration (z.B. von Outlook 2003 auf Outlook 2010) diesen Cache von der alten *.nk2 Datei in Outlook 2010 (und damit auf den Exchange Server) migriert.

Die kurze Antwort:
outlook.exe /importnk2

Hier der entsprechende Knowledgebase Artikel von Microsoft
http://support.microsoft.com/kb/980542

Weitere Informationen und Anleitungen zu diesem Thema:

Roaming AutoComplete list
Recipient AutoComplete lists are now stored on the Exchange Server. A user’s recipient AutoComplete list is now available to any computer on which Outlook 2010 runs that is connected to the same Exchange account. Names can be easily removed from the list by using the new inline Delete function.
http://technet.microsoft.com/en-us/library/cc179110.aspx

How to migrate NK2 Auto complete cache “suggested contacts” from Microsoft Outlook 2003 or 2007 to Microsoft Outlook 2010 - Link

Und hier noch eine Anleitung wie man einzelne Autocomplete Einträge oder die ganze Liste in verschiedenen Outlook Versionen löscht:
http://support.microsoft.com/kb/287623/en-us

$a = (Get-TransportConfig).InternalSMTPServers ; $a += "192.168.10.5" ; Set-TransportConfig -InternalSMTPServers $a