Tach Allerseits,

Anfang März wurde in der deutschen ISA-Newsgroup die Frage gestellt, ob sich ein Konfigurationsspeicherserver (CSS) einer ISA-Server-Enterprise-Umgebung “verschieben” läßt. Die Idee hierbei: ein Sekundärer CSS soll zum primären CSS ernannt und der frühere primäre CSS gelöscht werden. Marc und ich philosophierten via EMail über das Thema und debatierten ob ein Transfer der FSMO Rollen für das Szenario nötig sei.

Wie es der Zufall so will wurde gestern auf dem offiziellen ISA-Blog ein passendes Workaround zu besagtem Thema veröffentlicht: http://blogs.technet.com/isablog/archive/2009/03/31/transferring-configuration-storage-server-fsmo-roles.aspx.

Mit der in dem Artikel dargestellten Verfahrensweise sollte sich die Anforderung umsetzen lassen.

Karsten Hentrup aka Jens Mander…

|<-|

…Tach Allerseits,

bei meiner ISA-Implemantation in Oberhausen “spuckte” uns ein Router ein wenig in die Suppe. Das Netz meines Kunden war bis heute durch einen Router mit integriertem IP-Paketfilter vom Internet getrennt. Dies wurde von uns durch eine Back-to-Back-Lösung mit einem ISA2006SE-Server ergänzt. Ich traf heute morgen die Hardware in bestem Zustand an, OS inkl. aktuellem Patchlevel zu allen Schandtaten bereit. Flux das LAN-Kabel des Routers gezogen und mit der externen Seite des ISAs verbunden (erst direkt aufgepatcht, später testweise mit zwischengeschaltetem Switch). Die Back-to-Back-Lösung sollte somit auch eine physikalische Trennung erfahren, folgende Topologie wurde von uns angestrebt:

Internet – Router (mit 2 ISP-Anbindungen) – ISA – Intranet

An den Router des ISPs sind zwei externe ADSL-Modems der Telekom angeschlossen. Als wir das LAN-Kabel des Routers zogen und neu patchten, stellte sich folgender (für mich zumindest) äußerst merkwürdiger Effekt ein: die Modems verloren die Synchronisation mit der Gegenüberstelle. Flux das LAN-Kabel auf den Core-Switch des Kunden zurückgepatcht – beide Modems syncen einwanfrei. Dieses Verhalten ist reproduzierbar. Es wurde kein Crossover-Kabel zwischen Router und ISA verwendet. Ein eigenständiger Switch zwischen Router und ISA schaffte keine Abhilfe. Ich hätte in dem Fall gedacht, das die Modems “aus Sicht” des Routers extern sind und nichts mit der internen Verkabelung zu tun haben. Aber sobald ich den Router vom Core-Switch runternehme ist Ende im Gelände angesagt, der Sync mit der DSL-Gegenstelle geht ins Nirvana (jau, wir haben wirklich lange gewartet).

Als Notlösung (uns wäre die physikalische Trennung lieber gewesen) haben wir folgendes gemacht: Der Router bleibt mit seiner LAN-Seite auf den Core-Switch gepatcht, der ISA mit seiner externen NIC ebenfalls. Die verwendeten IPs der internen NIC des Routers, sowie der externen NIC des ISAs sind aus einem komplett anderen IP-Segment. Wo wir schon keine physikalische Trennung hinbekommen können, haben wir sie wenigstens “virtuell” vollzogen.

Verrückte Geschichte das. Falls hierzu jemand ein paar Infos hat, bin für jede “Erleuchtung” dankbar (hentrup@aixperts.de).

Karsten Hentrup aka Jens Mander…

|<-|

Tach Allerseits… 

Vor zwei Wochen bin ich nochmal in die Verlegenheit gekommen eine ISA-2006-Inplace-Migration durchzuführen. Der Kunde sitzt bei mir vor Ort in Aachen und das wirklich besondere an ihm ist, das ich ihn innerhalb von 10 Minuten zu Fuß erreichen kann!

Vor Ort installiert war eine ISA-2004-SE. Ein Upgrade auf ISA-2006-SE war vom Kunden gewünscht. Zielsetzung war insbesondere die Password-Change-Option auf dem mit FBA versehenen Weblistener. Weitere Konfigurationswünsche: Regelwerkoptimierung, Patchlevel aktualisieren, SSL-Bridge statt Serververpublish für OWA und HTTPS/RPC alias Outlook Anywhere.

Als erstes haben wir die aktuelle ISA-2004 Konfiguration, sowie die vorhandenen Logfiles gesichert (auf einem hausinternen Fileserver). Danach wurde das OS-Patchlevel geradegezogen. Nach einem leckeren Mittagessen vor Ort warfen wir die ISA-2006-SE-CD ins Laufwerk und starteten das Inplace-Upgrade. Mir persönlich wäre eine Neuinstallation der Kiste lieber gewesen um manche Altlasten in Sachen Softwareinstallation nicht mitzunehmen (z.B. ist – warum auch immer – auf der Maschine NLB auf sämtlichen NICs aktiviert gewesen), dies ist aber manchmal leider nicht möglich. Nach der Installation noch flott das ISA-2006-SP1 draufgesetzt. Finger weg vom Post-SP1-UDP-DNS-Patch, der Kunde macht VPN mit dem ISA! Kiste durchgestartet – Eventlog gecheckt – alles wunderbar!

Bis hierhin lief alles wunderprächtig, auch die Regelwerkoptimierung für die ausgehenden Zugriffe verliefen reibungslos. Als letztes hatten wir noch den eingehenden Verkehr zu regeln, sprich OWA und HTTPS/RPC. Für die Password-Change-Option die wir anvisierten installierten wir eine domänenintegrierte CA auf einem internen Webserver. Auf dem Exchange- und dem ISA-Server rollten wir die benötigten Zertifikate aus und richteten die SSL-Bridge ein. Zugriff von extern aufs OWA gegengetestet – klappt.

Als letzten Konfigurationsschritt richteten wir die Password-Change-Option auf dem mit FBA versehenen Listener ein und bauten die noch fehlende Regel für‘s HTTPS/RPC. Daraufhin fingen unsere Probleme an:

Die Password-Change-Option wurde auf der FBA einwandfrei angezeigt und das Ändern des Passwortes für einen Testbenutzer funktionierte genau einmal. Bei allen weiteren Versuchen bekamen wir die üblich nichtssagende „man solle doch an jemanden anrufen, der etwas davon verstehe“-Fehlermeldung. J

Die Passwort-Änderung, die stellvertretend durch den ISA durchgeführt wird (Proxy halt) wird vom ISA zu den internen DCs mit LDAPS durchgeführt. Dieser Umstand wird in einem Microsoft-Whitepaper zu diesem Thema in einem Nebensatz erwähnt. Das bedeutet, das eine domänenintegrierte CA zwingend benötigt wird und alle DCs jene auch kennen. Damit dies gegeben ist hatten wir sämtliche DCs neu gestartet anstatt aufs Auto-Enrollment des Zertifizierungsinstanzzertifikates (eines meiner Lieblingswörter) zu warten. Positiver Nebeneffekt hierbei: das Patchlevel haben wir in einem Rutsch direkt gerade gezogen. Trotz der intensiven und korrekten Vorbereitung quittierte uns die Password-Change-Option die mir bekannte Fehlermeldung, die erscheint, wenn man keine hausinterne CA besitzt, bzw. einer der DCs diese noch nicht kennt. Auf mehrfaches Nachfragen meinerseits wurde mir vom Kunden versichert es gäbe nur zwei DCs. Nach einiger Zeit des Forschens, Rebootens und Testens öffnete ich die MMC für Active Directory-Standorte und -Dienste und siehe da: ein lustiger mir bisher nicht bekannter DC winkte mir fröhlich entgegen. Ein paar Fragen später stellte sich heraus, dass diese Maschine eigentlich kein DC, sondern nur ein hausinterner Backupserver sein durfte. Ein dcpromo bestätigte den nicht vorhandenen Service. Anscheinend ein nicht sauber aus dem AD ausgetragener Ex-DC. Nur referenziert das AD weiterhin auf ihn, den Computernamen gibt es auch noch, nur das halt kein DC auf der Maschine läuft. Bei der Passwort-Änderung scheint unser guter ISA-Server via LDAPS mit ihm kommuniziert zu haben und die Änderung ging ins Nirvana. Der Spuk hatte ein Ende, nachdem der verwaiste DC korrekt aus dem AD ausgetragen wurde. Notiz an mich selber: Immer erst im AD kontrollieren wieviele DCs tatsächlich im AD eingetragen sind.

Etwas länger schlugen wir uns allerdings mit dem HTTPS/RPC herum. Flux eingerichtet und von einem Notebook des Kunden gegengetestet (welches sich angeblich im Internet befindet). Die Zugriffe schlugen fehl. Ein Authentifizierungsfenster in Outlook ließ mich fälschlicherweise vermuten, ich kommuniziere bereits mit dem ISA. Ein Fehler wie ich später in einer VM bei mir im Home-Office bemerkte. Outlook zaubert beim HTTPS/RPC-Szenario anscheinend automatisch ein Popup-Fenster, auch wenn keinerlei Connect zu irgendeinem Zielsystem existiert. Recht verwundert war ich allerdings durch die Tatsache, das der HTTPS/RPC mit meinen Outlook von zuhause aus einwandfrei funktionierte. Tags darauf wieder beim Kunden vor Ort der gleiche Effekt wie am Vortag: keine Verbindung möglich. Ich möchte euch die verzweifelten Versuche meinerseits ersparen, die ich durchgetestet habe um das gute Teil zum fliegen zu bringen und direkt auf die Lösung hinweisen. Das Laptop des Kunden (mit dem wir die Verbindungen getestet haben) befand sich keineswegs im Internet, sondern in dem Transfernetz zwischen dem ISA Server und der Frontendfirewall. Da wir aber zum Testen immer den öffentlichen FQDN genommen haben wurde ein Connect durch die Frontendfirewall raus und wieder rein versucht, welcher hoffnungslos scheiterte. Wir modifizierten auf dem Rechner im Transfernetz die Host-Datei und drehten den öffentlichen FQDN gegen die externe IP des ISA Servers und schon war alles in Butter. Notiz an mich selber: Teste externe Verbindungsversuche immer mit dem eigenen Laptop via UMTS/HSPA.

Die Ursachen für die Probleme mögen recht trivial sein, in der Situation an sich kann man an solchen Nettigkeiten schon mal ein wenig verzweifeln.

Karsten Hentrup aka Jens Mander…

|<-|