[FISI] Projektantrag - Exchange Server

[hexerhasi]

Hallöchen allerseits!

Ich denke ich habe das gröbste des Antrags fertig und möchte gerne ein paar Rückmeldungen und Kritik von erfahrenen Menschen hören. Dazu muss ich sagen, dass ich das Gefühl habe das dort noch einiges fehlt bzw. suboptimal formuliert ist. Aber vertraue in der Hinsicht auf eure Meinungen und Erfahrungen

Ich möchte mich jetzt schonmal für eure Bemühungen (selbst wenn ihr nur lest) bedanken!

Projektantrag – Exchange Edge Server

1. Projektbezeichnung

1.1. Kurzform der Aufgabenstellung

Installation, Konfiguration und Absicherung eines neuen Microsoft Exchange Edge Server 2007 in einer virtualisierten Testumgebung mit anschließender Übernahme in den Produktivbetrieb.

1.2. Ist-Analyse / Ausgangssituation

Die ***** ist ein Unternehmen, das speziell auf Kundenwünsche angepasste Software entwickelt. Der Firmensitz ist in *****, wo unter anderem auch ein eigener Mailserver bereitgestellt wird. Benutzt wird der Microsoft Exchange Server 2007 mit einem in einer DMZ stehenden Exchange Edge Server, über den alle Postfächer der Mitarbeiter sowie Verteilerlisten und Termine verwaltet werden. Die Kommunikation über das Mailsystem ist ein wichtiger Bestandteil der täglichen Arbeit, somit muss dessen korrekte Funktion zu jederzeit sichergestellt sein.

Der aktuelle Zustand des vorhandenen Exchange Edge Servers ist nicht zufriedenstellend, da es wegen einigen falschen Konfigurationen oftmals zu Problemen beim Emailversand kommt. Werden die Emails direkt von der eigenen Domäne aus versendet, schlägt die Absenderprüfung beim empfangenden Server fehl und die Email verschwindet im Spamverzeichnis, wird direkt gelöscht oder garnicht erst angenommen. Aus diesem Grund wurde der Versand über einen Smart Host eingerichtet, so kann die Absenderprüfung erfolgreich durchgeführt werden. Der verwendete Smart Host gerät allerdings in unregelmäßigen Abständen unter Verdacht Spamemails zu versenden und wird deswegen auf verschiedenen Realtime Blocklists (RBL) geführt. Daraus folgt, dass auch die von der ***** versandten Emails unter Spamverdacht stehen.

Die Wartezeit für die Entfernung des Smart Hosts aus so einer RBL kann unter Umständen sehr lange sein, erfahrungsgemäß mindestens 72 Stunden. Diese Wartezeit ist vor allem bei geschäftskritischen Emails wie Rechnungen und Terminplanungen nicht zu vertreten.

2. Zielsetzung entwicklen/Soll-Konzept

2.1. Was soll am Ende des Projektes erreicht sein?

Nach Beendigung des Projektes soll eine Lösung für die Probleme und Anforderungen des Emailversandes existieren, auf ihre Anwendbarkeit überprüft und im Unternehmen umgesetzt worden sein.

2.2. Welche Anforderungen müssen erfüllt sein?

Es sollen weiterhin alle Emails über einen Smart Host gesendet werden, allerdings muss bei einer Störung (z.B. Smart Host ist in RBL eingetragen) sichergestellt sein, dass der Emailversand zeitnah ohne Probleme fortgesetzt werden kann.

Bevor eine Lösung am produktiven System umgesetzt wird, muss das geplante Vorgehen dokumentiert und von den Verantwortlichen überprüft werden.

2.3. Welche Einschränkungen (Probleme) müssen berücksichtigt werden?

Damit die Maildomain der ***** nicht auf einer der Blacklisten eingetragen wird, muss sichergestellt sein das keine Emails ohne Benutzerauthentifizierung ins Internet versendet werden können. Im internen Netzwerk muss dies allerdings möglich sein, da einige Testgeräte nur unter dieser Voraussetzung korrekt arbeiten können.

Außerdem muss die produktive Übernahme zu einem Zeitpunkt erfolgen, an welchem nur ein geringes Emailaufkommen zu erwarten ist, damit es zu keinen kritischen Einschränkungen kommen kann.

3. Projektphasen inklusive Zeitplanung

• 8h – Planung

o Präzisierung der Probleme

o Klärung der Anforderungen

o Informationsbeschaffung über mögliche Lösungswege

o Hardwarebeschaffung

• 4h – Installation

o Vorbereitung der virtuellen Umgebung

• 4h – Konfiguration

o Implementierung der Lösung in die Testumgebung

• 5h – Test

o Überwachung der ausgehenden Emails

o Kontrolle der Emailheader

o Simulation (z.B. Smart Host auf RBL)

• 6h – Reale Umsetzung

o Planung des Ablaufs

o Vorbereiten des Servers

o Installationen

o Überwachung

o Simulation (z.B. Smart Host auf RBL)

• 8h – Dokumentation

o Aufarbeitung der Projektdokumentation

o Erstellung einer Installations-/Konfigurationsdokumentation

Zeitaufwendung insgesamt: 35 Stunden

//Die Formatierung musste leider etwas leiden ;(

[Chief Wiggum]

Verstehe ich das richtig, ihr habt einen Exchange als exposed host in der DMZ, der nicht sauber läuft, nutzt stattdessen eine Smarthost, der regelmässig auf einer RBL landet und sucht, statt die Ursache an der Wurzel anzupacken, einen anderen Smarthost? Warum nicht eine feste IP mit einem sauberen MX Eintrag ins Haus holen? Warum nicht den äusseren Exchange flicken?

Ich halte die Grundidee schon für *hust* suboptimal. Solltest du einen Exchangekenner im PA haben, empfehle ich auch im Sommer zur mündlichen Prüfung eine dicke Winterjacke anzuziehen.

[hexerhasi]

Naja der Smart Host, den wir aktuell benutzen ist in einem Jahr "nur" zweimal auf einer RBL gelandet und das letzte Mal ist schon ziemlich lang her. Das ist zb ein Punkt der im Antrag fehlt: Der Smart Host soll nicht dauerhaft benutzt werden, sondern nur solange bis wir uns sicher sind, dass kein Müll aus unserem Netz versendet werden kann.

Unser Exchangesystem besteht aus zwei Servern, dem Mailbox Server und einem sozusagen SMTP Relay (nennt sich dort Exchange Edge Role) in einer DMZ. Das Problem wird im Zuge des Projektes an der Wurzel angegangen, allerdings wollte ich die Möglichkeit als Entscheidung während des Projektes einbringen, begründen und umsetzen.

Feste IP und MX ist vorhanden nur konnten wir zum Zeitpunkt als die Probleme auftraten, mangels Erfahrung und Wissen über den Exchange (wurde von einer ext. Fa. eingerichtet, ziemlich schlecht um ehrlich zu sein) die Sache nicht selbst angehen. So empfanden wir die Smart Host Lösung am sinnvollsten.

Ich denke die Übergangsgeschichte, den MX und die Ip sollte ich im Antrag erwähnen oder?

Und vielen Dank für die Antwort!

Bis bald

[Chief Wiggum]

Autsch... Ein Exchange Livesystem ist kein Bastelsystem.

Und wenn du dich nicht tief im Exchange auskennst, lass die Finger von.

[hexerhasi]

Ich habe mich seit unser Exchange eingerichtet wurde, intensiv in einer Testumgebung mit ihm beschäftigt. Also ich behaupte mal, dass mein Wissen an der Stelle mittlerweile nicht mehr das Problem ist. Davon mal abgesehen, habe ich im Antrag doch erwähnt, das alles in einer Testumgebung durchgespielt wird und ohne Planung mit den Verantwortlichen produktiv garnichts geändert wird?!

[hexerhasi]

Wie wäre es denn, wenn ich die Änderungen am Livesystem komplett aus dem Projekt streiche. Dann würde ich das so handhaben, dass das Projekt sich auf eine Lösungsfindung mit Test in einer Testumgebung bezieht. Die Lösung die mit dem Projekt entsteht (ich weiß was am Ende passieren und funktionieren muss) muss dann sorgfälltig dokumentiert werden und von mir wird ein Ablaufplan für die Umsetzung am Livesystem erstellt.

Und ich möchte auch nochmal erwähnen, dass ich nicht unwissend bin was den Exchange angeht.

Die Testumgebung muss auch nicht installiert werden, diese exisitert bereits und alles was ich dort machen werden, entspricht dem was am Livesystem gemacht werden würde.

Für beide Exchange Systeme (Live und Test) existieren zudem feste IP Adressen mit entsprechend eingerichteten MX Einträgen.

Auch nochmal erwähnen möchte ich, dass es sich nur um einen kleinen Teil des Exchange Systems handelt, nämlich den Versand.

[hexerhasi]

Ich hab mir den Antrag nochmal komplett vorgenommen, da der erste ja sehr missverständlich formuliert wurde. Kritik, vor allem zum Antrag, aber auch zum Projekt selbst ist ausdrücklich erwünscht.

Vorweg noch eine Sache, ich weiß das der Exchange ein sehr komplexes Thema ist. Es dreht sich in dem Projekt nur um den Versand der Emails.

Projektantrag – Exchange Emailversand

1. Projektbezeichnung

1.1. Kurzform der Aufgabenstellung

Konfiguration und Anpassung des Emailversandes.

1.2. Ist-Analyse

Die abc GmbH ist ein mittelständisches Unternehmen mit Firmensitz in Musterstadt. Sie entwickelt überwiegend Software, welche auf individuelle Kundenwünsche angepasst ist. Jeder Mitarbeiter der abc GmbH hat ein eigenes Postfach auf dem, von einem externen Dienstleister eingerichteteten, Microsoft Exchange Server 2007 (Mailbox Server) mit Exchange Edge Server (sozusagen SMTP Relay). Der eigentliche Versand der Emails ins Internet wird über diesen Edge Server abgewickelt. Ein großer Teil des Kundenkontaktes und des internen Informationsaustausches wird per Email abgewickelt. Beim Versenden von Emails gibt es allerdings Einschränkungen, aufgrund von suboptimalen Konfigurationen des damaligen Dienstleisters. Aktuell werden die Emails der abc GmbH über einen Smart Host ins Internet gesendet, da diese bei direktem Versand, wegen falscher Konfiguration des Servers, als Spam erkannt werden und so gelöscht oder nicht angenommen werden. Mit dem eingerichteten Smart Host ist allerdings ein weiteres Problem aufgetreten, selbiger wurde bereits zweimal auf mindestens einer Realtime Blocklist (RBL) geführt, was bedeutet das die gesendeten Emails der abc GmbH unter Spamverdacht stehen. Die Wartezeit für die Entfernung des Smart Hosts aus so einer RBL kann unter Umständen sehr lange sein, erfahrungsgemäß mindestens 72 Stunden. Diese Wartezeit ist vor allem bei geschäftskritischen Emails wie Rechnungen und Terminplanungen nicht zu vertreten. Damit diese Probleme in Zukunft nicht mehr die tägliche Arbeit behindern, soll eine Lösung gefunden werden.

Da bevorstehende Änderungen am produktiven Exchange System erst getestet werden müssen und nur umgesetzt werden, wenn sichergestellt werden kann das der Emailversand ohne Einschränkungen funktioniert, existiert bereits eine identisch konfigurierte Testumgebung. Diese Testumgebung beinhaltet eine eigenständige Active Directory Domäne, einen Microsoft Exchange Server 2007 und einen in einer DMZ stehenden Microsoft Exchange Edge Server. Eine Lösung soll zuerst in dieser Testumgebung umgesetzt werden. Diese Testumgebung besitzt außerdem, genau wie das Firmennetzwerk, eine feste Internet IP-Adresse und einen MX-Eintrag über die der Emailversand in naher Zukunft auf jeden Fall erfolgen soll.

2. Zielsetzung entwicklen/Soll-Konzept

2.1. Was soll am Ende des Projektes erreicht sein?

Am Ende des Projektes soll eine Lösung existieren, mit der die bestehenden Probleme gelöst werden. Zusätzlich soll ein Ablaufplan entstehen, der beschreibt wie bei einer Realisierung am produktiven System vorzugehen ist. Eine Dokumentation der eventuell anfallenden Installationen bzw. Konfigurationen ist dem Systemadministrator auszuhändigen, damit dieser nachvollziehen kann, was genau eingerichtet wurde. Außerdem muss ein ausführliches Testprotokoll vorgelegt werden.

2.2. Welche Anforderungen müssen erfüllt sein?

In Zukunft soll der Emailversand ohne einen Smart Host funktionieren, die dafür benötigte feste Internet IP-Adresse und der entsprechende MX-Eintrag sind bereits vom Systemadministrator beantragt worden. Hier muss sichergestellt werden, dass keine Spammails aus dem eigenen Netzwerk versendet werden können, ansonsten droht ein Eintrag in einer RBL.

2.3. Welche Einschränkungen müssen berücksichtigt werden?

Damit die Maildomain der abc GmbH nicht auf einer der Blacklisten eingetragen wird, muss sichergestellt sein das keine Emails ohne Benutzerauthentifizierung ins Internet versendet werden können. Im internen Netzwerk muss dies allerdings möglich sein, da einige Testgeräte nur unter dieser Voraussetzung korrekt arbeiten können.

3. Projektstrukturplan entwickeln

3.1. Was ist zur Erfüllung der Zielsetzung erforderlich

Fehlt noch

3.2. Haupt-/Teilaufgaben auflisten

1. Planung

a. Kundengespräch (Administrator/Geschäftsführung)

b. Präzisierte Ist-Analyse

2. Vorbereitung

a. Präzisierte Soll-Analyse

b. Lösung definieren

c. Ablaufplan für Umsetzung in Testumgebung erstellen

3. Installation/Konfiguration

a. Umsetzung der Lösung in Testumgebung

4. Test

a. Kontrolle von ausgehenden Emails

b. Kontrolle von eingehenden Emails

c. Testprotokoll anfertigen

5. Abschluss

a. Testprotokoll aufarbeiten

b. Ablaufplan für produktive Umgebung erstellen

c. Kundengespräch

6. Dokumentation

a. Projektdokumentation erstellen

b. Administratordokumentation erstellen

4. Projektphasen mit Zeitplanung in Stunden

1. 4h - Planung

2. 8h - Vorbereitung

3. 5h - Installation/Konfiguration

4. 6h - Test

5. 4h - Abschluss

6. 8h – Dokumentation

Gesamte geplante Zeitaufwendung: 35 Stunden