Monthly archives "Juni 2010"

OWA über ISA/TMG – von verschiedenen Browsern aus betrachtet

Im Rahmen eines Projektes wurde ich auf eine Fehlermeldung im Outlook Web Access aufmerksam gemacht. Es gibt im OWA den Menüpunkt „Optionen“, über den man verschiedene Einstellungen steuern kann (z.B. die in OWA verwendete Mailsignatur).

Ruft nun ein Benutzer dieses Punkt auf, erhält er die Fehlermeldung:

404 – Webseite kann nicht gefunden werden.

Ich habe es dann prompt über meinen Rechner getestet und dort tritt der Fehler nicht auf. Ich habe es dann von einem zweiten Rechner aus getestet und bekam dort die angegebene Fehlermeldung.

Was ist nun der Unterschied zwischen den beiden PCs? Auf einem läuft Windows Vista, auf dem anderen PC OpenSuse 11.2 (Linux).

Bei genauerer Betrachtung der verwendeten URL fiel mir dann etwas auf. Unter Windows wurde auf die URL https://owa.firma.de/ecp/?rfr=owa zugegriffen. Für Linux lautete die URL https://owa.firma.de/?ae=Options&t=Messaging.

Jetzt lag die Lösung auf der Hand: das Verzeichnis /ecp/ wurde über den ISA/TMG-Server nicht veröffentlicht.

Sollte allerdings ein „schlauer“ Admin auf die Idee kommen, den Zugriff auf „Optionen“ nur dadurch zu verhindern dass er das Unterverzeichnis nicht veröffentlicht, dann ist jetzt klar, wie man die „Sperre“ einfach umgehen kann.

]]>

Warum man manche Active Directory Attribute besser in Ruhe lässt

Heute habe ich den ganzen Tag mit einem besonders seltsamen Problem zu kämpfen gehabt. Ausgangssituation ist eine Mailmigration, bei der für eine Übergangszeit das alte Mailsystem (Lotus Notes) und das neue Mailsystem (Exchange 2010) parallel betrieben werden. Die Umgebung lief jetzt schon eine gewisse Zeit lang ohne Probleme.

Das Besondere an solchen Umgebungen ist die Tatsache, dass ein SMTP-Adressraum sich über zwei unabhängige Systeme erstreckt. Die Systeme müssen also wissen, dass sie Mails für Benutzer, deren Maildomäne ihnen zugeordnet ist, weiterleiten müssen, falls der Benutzer in dem System keine Mailbox hat. Exchange 2010 teile ich über „Akzeptierte Domänen“ mit, für welche Maildomänen es zuständig ist. Setze ich dabei die Option „internes Relay“, weiss Exchange dass es noch weitere Server ausserhalb der Exchange-Organisation gibt, die ebenfalls Mailempfänger aus dieser Domäne haben. Was dann noch fehlt ist ein SMTP-Konnektor, über den die Mails an das andere Mailsystem gehen.

Diese Konfiguration hat jetzt über einen längeren Zeitraum sehr gut funktioniert. Seit zwei Tagen aber konnten keine Mails mehr von Exchange aus an den Notes Server versendet werden. Die Mails landeten alle in der „Unzustellbar“-Warteschlange. Schaute man sich nun eine einzelne Mail dort an, wurde als fehlermeldung angegeben, dass der Empfänger kein Postfach haben würde. Exchange schien also zu glauben, dass der Empfänger zu der Exchange-Organisation gehören würde. Ich habe diese Konfiguration über Jahre (und Exchange-Versionen) hinweg bei Migrationen immer wieder gehabt; aber dieser Fehler war mir neu.

Zuerst habe ich das Übliche versucht: Diagnoseprotokollierung eingeschaltet, Event-Log überprüft. Kein Ergebnis. Der Neustart von Diensten brachte auch keinen Erfolg. Danach habe ich mich durch diverse Artikel in Foren und bei Microsoft gewühlt. Hierbei bin ich auf einen PowerShell-Befehl zum erneuten Versenden von Mails in einer Warteschlange gestossen: Retry-Queue. Hierbei ist zu beachten, dass dieser Befehl den Parameter Resubmit kennt. Wird der Parameter nicht angegeben, versucht das System eine sofortige Zustellung. Setzt man den Parameter aber auf „wahr“ ($true), dann wird die Mail erneut an den Categorizer übergeben. Da ich im Laufe des Tages einige kleinere Änderungen am Konnektor durchgeführt hatte, wollte ich sichergehen dass eventuelle Auswirkungen auf das Routing auch bemerkt würden und habe den Parameter mit angegeben.

Interessanterweise gab es zwei Maildomänen, die auf beiden Systemen existierten. Der Fehler trat nur bei einer Domäne auf; die andere funktionierte tadellos. Ich habe dann eine Mail an einen fiktiven Empfänger aus der nicht funktionierenden Domäne gesendet. Und siehe da: diese Mail ging durch. Nun konnte der Fehler eigentlich nur durch die einzige Änderung am System verursacht worden sein. Über ein Skript war bei allen AD-Benutzern das Attribut „mail“ auf die E-Mailadresse gesetzt worden (die nicht funktionierende). Nun war mir aber nicht klar, warum sich Exchange um dieses Attribut scheren sollte.

Ein Telefongespräch brachte dann die Lösung. Da das Mailrouting demnächst hauptsächlich über Exchange laufen sollte, benötigte der dort installierte SPAM-Filter eine Möglichkeit, aus dem Active Directory sämtliche E-Mail-Adressen für einen Benutzer auszulesen. So sollte sichergestellt werden, dass nur Mails für existierende Empfänger angenommen werden würden. Leider verfiel man, da in das Attribut „mail“ ja nur ein Eintrag passt, auf die Idee hierfür das Attribut proxyAddresses zu nehmen. Bei Benutzern mit Exchange-Postfach bzw. bei Kontakten stehen hier die Mailadressen des Benutzers. Da die Einträge aber über einen unüblichen Weg gemacht wurden, schien Exchange es jetzt so zu interpretieren dass der Benutzer ein Exchange-Empfänger wäre (also die Mail lokal zugestelltw erden könnte). Da die Abfrage nach dem Mailboxserver für den Benutzer (homeMDB-Attribut) aber mangels Postfach fehlschlug, landete die Mail mit der aus Sicht von Exchange korrekten Fehlermeldung in der Unzustellbarkeits-Queue.

Wir haben dann in einem weiteren Telefonat beschlossen die Proxy-Adressen wieder zu entfernen. Exchange bietet mittlerweile bei der Anlage von Kontakten zwei Möglichkeiten: E-Mail Kontakt und E-Mail Benutzer. Der E-Mail Kontakt ist der altbekannte Eintrag im globalen Adressbuch, der nur dazu dient dass man externe Empfänger zentral aus dem Adressbuch auswählen kann. Der E-Mail Benutzer ist nun aber ein Active Directory Objekt mit einer externen Mailadresse (also ohne Postfach). Man kann auch vorhandene Active Directory Benutzer nachträglich zu E-Mail Benutzern machen, so dass ihnen dann über einen korrekten Weg die externen Mailadressen zugewiesen werden kann.

Was lernen wir daraus? Es gibt bei Exchange noch Vieles zu entdecken.

PS:Was ich aber nicht verstehe: warum testet man eigentlich nicht, nachdem man so eine Änderung durchgeführt hat?

]]>

Mal wieder Buchempfehlungen

Es ist mal wieder Zeit für ein paar Buchempfehlungen.

Das erste Buch ist eine Empfehlung eines Blog-Lesers. Es handelt sich um einen Roman:„Der Täuscher“ von Jeffery Deaver. Die Handlung umreisse ich nur sehr grob, um nicht zu viel zu verraten. Der Hauptakteuer auf Seiten der Polizei dürfte dem Einen oder Anderen bekannt vorkommen; es ist der Forensikspezialist Lincoln Rhyme, der im Film „Der Knochenjäger“ von Denzel Washington gespielt wurde. Rhyme erfährt, dass sein Bruder des Mordes angeklagt wird. Die Beweislast scheint erdrückend zu sein. Aber sind die Beweise echt oder fälscht sie jemand äussert geschickt. Und falls sie jemand fälscht: woher weiss er so viel über die Personen? Man wird nach der Lektüre dieses Buches Firmen, die Daten sammeln, nicht unbedingt freundlicher gegenüber stehen.

Der nächste Vorschlag ist mal wieder was mit Bildung;-) Es handelt sich um das Buch „Scheinbildung – Was an unserem Wissen alles falsch ist“ von John Lloyd und John Mitchinson. Wie der Titel schon sagt, wird dem Leser gezeigt, welche Dinge zwar gerne als wahr angenommen werden, aber es nicht sind. Ein Beispiel ist die Antwort auf die Frage, wonach Amerika benannt wurde. Ich habe früher immer gesagt, daß der Name sich von dem Entdecker Amerigo Vespucci ableitet. Richtig wäre aber: Richard Ameryk (ein walisischer Händler). Andere Fragen drehen sich darum, ob Hitler Vegetarier war (nein) und wie viele Nasenlöcher Menschen haben (vier). Beid er Frage, welches Stockwerk sich am Besten zum Hinabwerfen einer Katze eignet, hoffe ich nur, dass das keiner ausprobiert. Für 9,95€ ein sehr unterhaltsames und lehrreiches Buch.

Das letzte Buch ist eine Zusammenfassung von Artikeln der Mathematikkolumne von SPIEGEL ONLINE. Holger Dambeck stellt in „Numerator – Mathematik für jeden“ zum Beispiel vor, wie Google den Page Rank einer Seite berechnet (zumindest grob), wie man U-Bahn Fahrpläne optimiert und wie man den Energieaufwand beim Bergsteigen minimiert. Die einzelnen Abschnitte sind locker geschrieben und kommen mit nur sehr wenigen Formeln aus. Empfehlenswert!

PS: Zum Hinabwerfen von Katzen eignet sich jedes Stockwerk vom siebten aufwärts (Please, dont try this at home). Und ja, es sind wirklich vier Nasenlöcher.

]]>

Auf ein Exchange-Postfach mit verschiedenen Outlook-Versionen zugreifen

Vor einigen Tagen hat mich ein Kunde mit einem interessanten Problem angerufen. Der Kunde setzt Exchange 2007 und Outlook 2003 ein, wobei Outlook über Citrix bereitgestellt wird. Einige Mitarbeiter hatten eine Outlook 2010 Schulung und haben testweise mal einige Tage die neue Version genutzt. Als sie nun wieder auf die „alte“ Version umgestiegen sind, ließ sich Outlook nicht mehr öffnen; angeblich sei das Profil nicht konfiguriert gewesen. Über die Systemsteuerung liess sich das Profil auch nicht konfigurieren; hier war alles ausgegraut.

Ich habe den Kunden gebeten, einen neuen Benutzer zu erzeugen. Der Kunde hat dann zuerst mit Outlook 2003 auf das Postfach zugegriffen; die Einträge in der Registry (unter „Windows Messaging Subsystem“) hat er dann exportiert. Danach hat er mit Outlook 2010 auf das Postfach zugegriffen und auch dann die Einstellungen exportiert. Die so erhaltenen Textdateien habe ich unter Windows mit ViM (vimdiff) verglichen.

Der mit 16f43 beginnende Schlüssel in der Registry war unter Outlook 2003 gefüllt (u.a. stand dort der Name des Users); unter Outlook 2010 war der Schlüssel leer. Er hat den Teilschlüssel aus der Reg-Datei für Outlook 2003 ausgeschnitten und im nicht funktionierenden Profil importiert. Outlook 2003 ließ sich nun wieder starten.

Vielleicht hilft die Info ja jemand weiter.

]]>

Neuer Exchangeserver und Citrix

Da mich das folgende Problem fast in den Wahnsinn getrieben hat und ich vielleicht nicht der einzige Consultant mit dieser Fragestellung bin, poste ich mal dieses kleine Problem.

Bei einem Kunden habe ich den Exchange 2003 Server durch einen Exchange 2007 Server ersetzt. Soweit verlief auch alles glatt; nur ein Problem liess uns keine Ruhe. Wurde ein neuer Benutzer angelegt und startet dieser dann sein Outlook (unter Citrix), stand dort im Profil immer noch der alte Server.

Wir haben auf dem Citrix-Server die Registry rauf und runter abgesucht, aber ohne Erfolg. Vor ein paar Tagen habe ich noch mal ein bisschen gegoogelt und stieß dabei auf die Lösung. Damit Outlook nicht konfiguriert werden muss, hat derjenige, der Citrix installiert hat, Outlook über eine PRF-Datei konfiguriert. Leider war das nirgendwo dokumentiert. Wie sich herausstellte, stand dort noch der alte Servername drin. Nachdem wir den geändert hatten, wurde für einen Testuser Outlook endlich korrekt konfiguriert.

Note to self: in solchen Umgebungen muss ich als Consultant auch mal über den Tellerrand (des eigenen Produktes) hinausblicken.

]]>

Geister-Server

Ich nutze seit Jahren VMWARE Workstation; man kann prima damit Testumgebungen aufbauen. Damit ich die Maschinen auch updaten kann, trage ich in den DNS-Servern immer meinen Router (Fritz!Box) als DNS-Server für die Auflösung von externen Adressen ein. Die Server bekommen eine feste IP, wobei ich eigentlich für unterschiedliche Testumgebungen dieselben IPs benutze.

Bisher hat das noch nie Probleme gegeben; aber es gibt ja immer ein erstes Mal.

In meiner aktuellen Testumgebung ging es um die Installation eines SQUID Proxy mit Authentifizierung gegen ein Active Directory. Gemäß einer Anleitung im Internet muß dazu der Linuxrechner, auf dem Squid läuft, in das Active Directory aufgenommen werden (SingleSignOn war gewünscht). Meine Versuche, den Server in die Domäne aufzunehmen, waren erfolglos. Es sah so aus als würde der Linuxrechner den DC nicht finden. Als ich nun einen PING von Linux aus in Richtung DC absetzte, war ich über die Antwort erstaunt. TCPDUMP zeigte mir als Namen nämlich eine Maschine an, mit der ich vor einigen Tagen einige Tests zum Thema „Windows PKI“ durchgeführt hatte. Rechnername und Domäne stimmten natürlich nicht mit der aktuellen Maschine überein; so war es kein Wunder, dass Linux den DC nicht finden konnte. Weder ein Neustart des Linuxrechners noch ein Neustart des DCs brachten eine Verbesserung. Ich hatte eigentlich erwartet, dass irgendwelche Caches danach gelöscht wären…

Bei der Gelegenheit ist mir dann aufgefallen, dass es (scheinbar) keinen Befehl zum Anzeigen des Caches auf einem Windows DNS-Server gibt. Falls ich da falsch liege, wäre ich über eine Nachricht sehr dankbar.

Eine weitere Kuriosität war, dass bei ausgeschalteten VM-Maschinen ich für den Namen trotzdem auf einen PING eine Antwort bekam! Die zurückgelieferte Adresse kam aus dem Adresspool meines Providers. Diese obskure Praxis hat die ct ja vor Kurzem thematisiert.

Zum Schluss blieb nur noch eine Möglichkeit übrig: es musste mein Router sein. Und richtig: nach einem Neustart verschwand der „Geister-Server“ und ich konnte die Maschine erfolgreich der Domäne hinzufügen. Es stellt sich jetzt die Frage: warum speichert ein unmodifizierter AVM-DSL-Router diese Einträge so lange und vor allem: wo?

]]>