Langlitz - IT Consulting

Tja, auch ich habe mich an die neue Windowsversion herangewagt.

Ich muss sagen, nachdem ich nun einige Wochen damit arbeitem, bin ich auch tatsächlich begeistert. Als ich allerdings nach der Installation das erste Mal eine Telnet Verbindung aufmachen wollte, habe ich doch dumm geschaut, als Windows den Befehl nicht kannte.

Der Telnet Client ist nicht automatisch mit der Windows 7 Installation aktiv sondern muss als Windows Feature extra  installiert werden.

Dazu über die Systemsteuerung die Funktion nachziehen:

“Windows-Feature aktivieren oder deaktivieren” wählen und dann den Telnet Client aktivieren:

Ich fürchte, ich kann Ihnen keinen vernünftigen Grund nenne, warum Microsoft das so gemacht hat. Einerseits streiten Sie seit Jahren darum, ob nun der IE oder der Mediaplayer im Betriebssytem enthalten sein darf oder nicht. Andererseits werden solche grundlegenden Funktionen nicht im Standard mit installiert.

Das verstehe wer will.

Wenn Sie mir einen vernünftigen Grund dafür nennen können, nehme ich diesen gerne hier mit auf.

Es ist keine Frage, die Autodiscover Funktion ist (erfolgreich eingerichtet) eine nützliche Geschichte für Outlook 2007 Clients. Aber wer schon mal für eine gehostete Exchange Lösung autodiscover eingerichtet hat, hat darüber sicher auch ein paar graue Haare mehr bekommen. Man beachte, ob es nun die Free and Busy Informationen, der Abwesenheitsassist, das Offline Address Book und noch einige andere Funktionen sind, Outlook 2007 will im Standard ohne Autodiscover nicht so wirklich funktionieren. Bei meinem “ersten Mal” bin ich beim verzweifelten Suchen nach dem richtigen Vorgehen auf den “Autodiscover Song” gestossen. Ich kann Ihnen diesen nur ans Herz legen

http://msexchangeteam.com/files/12/attachments/entry449511.aspx

Geht es auch ohne?

In der Tat. Natürlich können Sie weiter Outlook 203 nutzen Das ist aber nicht, was Sie möchten? Dann gibt es noch die Möglichkeit für den Client das Autodiscover abzuschalten. Dazu sind je nach Funktion ein paar Registry Bastelarbeiten erforderlich:

HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: DisableAutoStartup
Set to 1

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: ZeroConfigExchange
Set to 1

2. Free Busy:
Outlook 2007 zwingen den Public Folder Free/Busy zu nutzen:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Calendar
DWORD: UseLegacyFB
Wert:
0 (oder nicht vorhanden) = default Einstellung - Autodiscover nutzen
1 = public folder free/busy nutzen

Da ist sie nun, die neue Generation von Exchange. Es wird sich einiges ändern. Nährere Informationen finden Sie hier

http://www.microsoft.com/germany/presseservice/detail.mspx?id=532691

Eine Auflistung der neuen Funktionen und zusätzliche interessante Links finden Sie hier

http://www.msexchangefaq.de/e2010/index.htm

Natürlich bleibt abzuwarten, in welchen Punkten die Final Version noch der Beta gleicht, aber es ist schon abzusehen, dass Microsoft einen großen Schritt gewagt hat.

Themen wie Archivierung, Federation, Datensicherheit, ECP, verbesserte Migration, … sind alles Punkte, die entweder weiter verbessert oder neu impolementiert wurden.

Ich bin schon gespannt, ob Microsoft es noch in diesem Jahr schafft, die Final Version zu veröffentlichen

Über den Nutzen der Public Folder möchte ich hier nicht referieren, darüber kann sich sicher jeder selbst seine Meinung bilden. Welchen Stellenwert die Public Folder im Hause Microsoft genießen wird deutlich, wenn man sich bewusst macht, dass Microsoft diese seit der Version Exchange 2000 nicht mehr weiterentwickelt hat. Ursprünglich sollten die Public Folder in Exchange 2007 schon gestorben sein. Auf vielfache Beschwerden seitens der Kunden hat Microsoft aber entschieden, diese weiter in Exchange zu betreiben.

Wenn Sie nun einem Public Folder beibringen wollen auch eMails zu empfangen sind folgende Schritte erforderlich:

Mailenablen über Management Console

• Starten der Public Folder Management Console
• Wählen Sie den entsprechenden Public Folder
• Rechte Maustaste auf den Folder und wählen Sie „Mail Enable“

Das war’s. Den Unterschied zwischen Mailenabled Public Foldern und denen die dazu nicht in der Lage sind erkennen Sie an dem Symbol für den Folder:

  - Mail enabled
  - not Mail enabled

Mailenablen über Management Shell

Über die Management Shell führe Sie folgenden Befehl aus:

Enable-MailPublicFolder -Identity “\My Public Folder” -Server “Server01″

Jetzt braucht der Folder natürlich noch eine Mailadresse. Sie können diese auch über die Public Folder Management Console in den Eigenschaften des Folders vergeben, oder über die Management Shell mit dem Befehl:

Set-MailPublicFolder -Identity “\My Public Folder” -PrimarySmtpAddress folder@domain.com

Tja, damit könnte man meinen, das war’s dann. Für „interne“ eMails war es das tatsächlich, aber was, wenn der Folder auch eMails von „aussen“ empfangen soll. Dazu ist es noch erforderlich, dass der „anonymous“ User das Recht „create items“ für diesen Folder bekommt. Und wenn Sie sich bisher erfolgreich davor gedrückt haben, die Management Shell zu nutzen, kommen Sie jetzt nicht mehr darum herum. Berechtigungen für Public Folder können nur über die Management Shell gesetzt werden:

Add-PublicFolderClientPermission -Identity “\My Public Folder” -AccessRights createitems -User Harry

Jetzt können Sie sagen: “Das war’s”

Wie groß sollte vernünftigerweise eine Mailbox wirklich werden dürfen?
Um diese Frage beantworten zu bekommen kommt es auf den Blickwinkel an. Der Vertriebsmitarbeiter wird natürlich die Meinung vertreten, dass seine Mailbox überhaupt keinen Größenbeschränkungen unterliegen darf, weil er sonst Business verliert. Der Produktmanager sieht das sicher ähnlich, weil er natürlich alle Produktpräsentationen von zig MB in seinem Postfach aufbewahren muss. Der Tekkie wird eher eine sparsame Mailbox bevorzugen.

Ich persönlich komme auch die nächsten Jahre sicher noch mit einer Mailboxgröße von unter 500 MB aus. Ich behalte aber auch nicht jede Präsentation, jeden Joke oder jede Frage eines Kollegen, wann wir in der Mittagspause essen gehen wollen in meinem Postfach.

Hosted vs. Coporate?

Es spielt aber sicher auch eine Rolle in welchem Umfeld der Mailserver betrieben wird. Sprechen wir von einem Corporate Mailsystem, kann sich sicher auf eine Policy geeinigt werden, die für alle Mitarbeiter greift. Sprechen wir aber von einem gehosteten System muss natürlich auf die Wünsche der Kunden (soweit sich das noch vertreten lässt) eingegangen werden. Denn schließlich zahlt der Kunde ja für seine Mailbox.

Aus technischer Sicht im Bezug auf Exchange kann ich aber zum Einen auf Erfahrungswerte zurückgreifen und zum Anderen mich an die Empfehlungen von Microsoft halten.
Leider gibt Microsoft nicht wirklich an, was die optimale Größe ist. Allerdings gibt es die Aussage vom Microsoft Support, dass Mailboxen größer 2GB zwar unterstützt werden, wenn sich aber ein Kunde beschwert, dass bei seiner Mailbox, die vielleicht 5GB groß ist ein Suchvorgang ewig dauert bekommt er von Microsoft nur die Rückmeldung „selbst Schuld, Mach Deine Mailbox halt kleiner“, naja… Zumal der Suchvorgang in einer Mailbox im Wesentlichen von der Anzahl der Objekte und nicht von der Gesamtgröße abhängig ist.

Nichts desto trotz sehe ich nicht wirklich einen Grund weshalb ein Emailpostfach (egal auf welchem System) eine Größe von 1 GB übersteigen sollte. Denn die Erfahrung sagt mir, dass für die mir so lieb gewordene Spezies ein Postfach nie groß genug sein kann. Und wer kennt als Exchange Verantwortlicher nicht die Sonderregelung für die „wichtigen“ Mitarbeiter eines Unternehmens, für die immer wieder das Limit hoch geschraubt wird.
Und wir wissen auch alle wer dann am lautesten schreit, wenn das Verschieben oder ein Restore einer 5GB Mailbox einen halben Tag dauert…

Wer Mailserver betreibt, kennt auch die Beschwerden seiner Benutzer zu den unerwünschten, aber leider immer häufiger werdenden Spamfluten. Es gibt im Internet unzählige Statistiken zu diesem Thema. Die Steigerungungsrate von Spamaufkommen der letzten Jahre liegt demnach bei 1000den %. Genaue Aussagen dazu sind sicher schwer zu machen, aber für eine Standard eMail domäne liegt das Aufkommen bei ca. 95-98 %. Das heißt tatsächlich, von 100 Mails will der Empfänger wirklich eine Handvoll tatsächlich empfangen!
Es gibt viele Arten von Spam, vereinfacht gesagt sind das aber eMails, die der Empfänger gar nicht haben will. Da gibt es Anbieter von Potenzmitteln, zwielichtige Broker, die einem die neuesten Aktien einer Orangenplantage in sonst wo verkaufen wollen, einen Spendenaufruf für was auch immer und und und…
Wie kann man sich nun davor schützen? Zu allererst ist natürlich die Disziplin im Umgang mit einer Mailadresse oberstes Gebot. Ich muss nicht auf jeder Website meine Mailadresse hinterlassen. Wer weiß was damit dort geschieht. Der Handel mit reellen Adressen ist ein äußerst lukratives Geschäft.

Ein erschreckendes Beispiel:

Ich habe ein Catchall Postfach, das alles annimmt, was an eine Domain gesendet wird. Ich bin auf der Website eines namhaften deutschen Autobauers und soll dort eine Mailadresse hinterlassen. Also hinterlasse ich autobauer@meinedomain.de Alles schön und gut. 2 Wochen später bekomme ich an diese Adresse Angebote zum Thema Viagra gesendet. Ich habe dann eine Regel definiert, nach der alles was an diese Adresse ging automatisch weitergeleitet wird an info@autobauer.de. Einige Tage später droht mir der Autobauer und ich antworte: „wenn Ihr mir sagt, wie meine Adresse raus kam, stelle ich die Weiterleitung ab“ – Ich habe nie wieder etwas von denen gehört…

Schutzmassnahmen

Spamschutz Produkte für Mailserver Betreiber gibt es mittlerweile viele. Ich persönlich halte eine Lösung, die auf dem Mailserver installiert werden muss aber für keine gute Idee. Besser wäre doch alle eingehenden Mails über ein „Spamschutzgateway“ zu leiten und die Filterung dort vornehmen zu lassen. Damit halte ich mir den sowieso unerwünschten Traffic aus meinem Rechenzentrum gleich von vorneherein fern.
Bei der Auswahl des „richtigen“ Anbieters ist natürlich die Erkennungsrate ein Kriterium. Aber wenn ein Anbieter damit wirbt „Wir erkennen alles“, kann das zwar sein, aber wie viele „erwünschte“ eMails werden dann mit gefiltert (sog. false positives“). Genauso wichtig, wie die Erkennungsrate ist die Anzahl dieser false positives die im Durchschnitt gefiltert werden. Hier muss jeder seine eigenen Erfahrungen sammeln. „Das“ ultimative Produkt in diesem Bereich gibt es meiner Meinung nach nicht.
Ich habe bei einem Kunden eine Lösung im Einsatz, die mir persönlich sehr zuspricht. Dabei werden Mails nicht auf deren Inhalte geprüft, sondern auf Indizien, die diese zu einer Massenmail werden lassen. Un solche eindeutigen Massenmails werden dann nicht in einen Quarantäne Ordner verschoben, sondern an den Absender zurück geschickt, mit dem Fehlertext, dass die Originalmail nicht beim Empfänger ankam, weil sie als Spam deklariert wurde.
Damit hat der Absender (wenn es ein false positive wäre) die Möglichkeit darauf zu reagieren. Und der Empfänger muss nicht seine Zeit mit der Durchsicht eines Quarantäne Ordners verbringen. Denn wo ist der Unterschied im zeitlichen Aufwand, meinen Posteingang von Spams zu säubern, oder einen Quarantäne Ordner nach regulären Mails zu durchsuchen?

Eine sehr informative Seite zum Thema kann ich noch empfehlen www.antispam.de

Jetzt ist natürlich die Frage offen, wer um alles in der Welt sollte so etwas tun? Nur wer sich wirklich nackig machen will vor der ganzen Welt wird wirklich ein offenes Relay einrichten. Aber jeder der sich mit SMTP beschäftigt, weiß auch, dass es immer Anwendungen und Funktionen gibt die der ganzen Welt gerne mitteilen möchten, was sie gerade tun

Da ist die Eierlegendewollmilchsau, die natürlich eingescannte Dokumente per SMTP sonstwohin versenden kann oder das CRM System das auch dem Vertriebsmitarbeiter in der Mongolei mitteilen möchte das der Kunde XY nun eine neue Produktpräsentation bekommen hat oder…

Jedes diese Systeme ist nun in der Lage per SMTP Mails zu versenden, brauch aber auch dafür eine Relay Gegenstelle. Natürlich kann Exchange das, es ist aber nicht so trivial, wie sich das viele vorstellen. Es ist ein Einfaches dem Standard Recieve Connector zu sagen, dass er jetzt Mails von jedem an jeden annehmen darf. Aber dann hätten wir wirklich ein offenes Relay gebaut.

Also richten wir zunächst mal einen neuen Receive Connector ein, dem wir am besten auch einen eindeutigen namen (wie z.B. Relay) geben.

Folgende Einstellungen sind dafür erforderlich:

Das sieht erst mal logisch aus und jeder denkt, dass alle die unter Network eingetragen sind nun relayen dürfen.

Pustekuchen!

Der Connector wird bei jedem Relay Versuch mit „unable to relay“ antworten. Warum nur? Jetzt kommt die Management Shell ins Spiel, über die erst noch die erforderlichen Berechtigungen für den Connector gesetzt werden müssen. Das geschieht über folgenden Befehl:

Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Wenn dies erfolgreich abgearbeitet wurde, kann das Relay verwendet werden.

Komisch, warum stelle ich dann „anonymous Acces“ unter der Reiterkarte Permissions ein…

Ein sehr wichtiges Thema sind die Out Of Office Reply Meldungen, die per default nicht ins böse weite Netz gesendet werden sondern „nur“ intern zur Verfügung stehen. Jeder, der für solche System, wie Exchange verantwortlich ist, kennt die Problematik, dass ein ach so wichtiger Vertriebsmitarbeiter keine solchen Meldungen an seine Kunden versenden kann wenn er im Urlaub ist und alle Business dadurch verlieren und sowieso das Wohl und Wehe des ganzen Unternehmens davon abhängig ist…
Eines vorweg, das ist für diese Spezies tatsächlich ein Problem und wir Tekkies sollten ein klein wenig Verständnis für die Kollegen haben.
Nichts desto trotz ist es meiner Meinung nach absolut verwerflich solche Standard Meldungen automatisch zu versenden. Man überlege: Irgendwo in einem dunklen Kellerraum sitzt ein 16 jähriger Spammer, der sich mit obskuren Scripts Mailadressen zusammen bastelt und dann Spams an diese verschickt. Bei jedem, von dem er eine Antwort erhält, und sei es nur: „ ich bin derzeit nicht im Büro, blabla…“ kann er sich sicher sein, dass er eine „reale“(!) Mailadresse kreiert hat. Damit lässt sich leider, wie wir alle wissen sollten, viel Geld verdienen.
Also, bevor das aktiviert wird, sollten wir uns im Klaren sein, was passieren kann…

Völlig falscher Ansatz, meiner Meinung nach. Auch wenn die Namensgebung der aus Redmond “irgendwie” ähnelt. - Vielleicht nicht ganz zufällig?

Bei Open Xchange handelt es sich um eine Groupware Lösung, die das Verwalten gemeinsamer Ressourcen ermöglicht. Nebenbei kann man darüber auch eMails versenden und empfangen.

Das ist zwar in erster Linie auch das, was Microsoft Exchange bietet. Entgegen vieler Marketing/Vertrieb Vorstellungen aber ist OX keine Exchange für Arme. Viele der geschätzten Marketing/Vertrieb Angehörigen argumentieren aber häufig so. OX basieret auf Linux und Exchange auf Windows / Active Directory. Damit wird es wir immer Unterschiede in Funktionen zwische OX und Exchange geben.

Ein leidiges Thema. Richtig eingesetzt absolut sinnvoll und effektiv. Wird eine solche Lösung allerdings nicht seriös gepflegt, kann es schnell zu einem nervigen Störenfried mutieren.

Ich habe relativ gute Erfahrungen mit dem SCOM (System Center Operations Manager) von Microsoft gesammelt.

Die Frage ist allerdings, was sollte eigentlich überwacht werden. Wenn das Management Pack für Exchange im Standart eingerichtet wird, werden Sie nicht viel Freude daran haben. Sobald eine Handvoll User auf Ihrem Exchange Server zu finden sind wird der SCOM Sie gefühlte 348 Mal am Tag darüber informieren, das LDAP Abfragen auf Ihr AD zu lange dauern. Ich hatte bei einem Kunden den Fall, dass in der Pilotphase mit den ersten 100 Usern ständig diese Meldung kam. Nachdem wir den Schwellwert hochgesetzt haben und die Pilotphase weiter beobachtet haben, kamen keinerlei Beschwerden der User, dass z.B Adressbuchabfragen zu lange dauern würden. Mittlerweile sind dort auf zwei Mailstore Server 12.700 User am Arbeiten und alles läuft ziemlich flott.

Wenn der SCOM aber meldet, dass es Fehler im Mailflow gibt, ist das schon ein wichtiger Hinweis. Da kann z.B. der SMTP Dinest auf einem HUB Server im Nirvana stehen, was sonst niemand mitbekommen würde.

Also sollten sie überlegen, was Ihnen wichtig ist zu überwachen. Wenn z.B. eine LUN voll läuft, weil eine EDB zu schnell wächst möchten Sie doch sicher informiert werden, wenn noch ca. 20% freier Speicherplatz zur Verfügung steht, bevor die EDB ihren Dienst verweigert, wil kein Platz mehr verfügbar ist.

Nichts desto trotz macht es auch Sinn weiter Überwachungsmechanismen einzuführen. Denn was nutz eine Benachrichtígung, das Ihr Exchange Server gerade das Zeitliche gesegnet hat, wenn diese Nachricht per Mail an Ihr Postfach versendet wird. Hier sei der Hinweis erlaubt, dass viele Rechenzentrumsbetreiber eine rudimentäre Dienstüberwachung auf Portebene (häufig auch mit SMS Benachrichtigung) anbieten. Das wäre dann noch das Sahnehäubchen der Überwachung.

Deshalb abschließen die Bemerkung: Überlegen Sie, was Sie überwachen müssen. Der SCOM benachrichtigt Sie auch, wenn ein LKW an Ihrem RZ vorbeifährt, und er das als Erdbebenwarnung deklariert. Die Frage ist allerding: Wollen Sie das wirklich wissen? Oder beschränken Sie sich lieber auf das Wesentliche um nicht wichtige Meldungen auf Grund der Vielzahl zu übersehen.