Jump to content

Born4IT

Members
  • Gesamte Inhalte

    10
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von Born4IT

Explorer

Explorer (4/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Guten Morgen Doso, danke für deine Antwort. Dein Vorschlag klingt soweit nicht verkehrt. Leider stellt es für mich nur einen Workaround dar, und löst nicht die Frage weshalb und wo die alten Kennungen gecached werden. Zusätzlich haben wir an einem Account testweise die Prä-Windows 2000 Kennung geändert, was dazu führte das das Profil nicht mehr geladen wurde und der entsprechende Mitarbeiter nur ein temporäres Profil bekam. Gruß, Marco
  2. Hallo zusammen, Wir sind derzeit in der Umstellung von Windows XP auf Windows 7 (etwas spät, ich weiß ;) ). In diesem Zuge passen wir auch die Prä-Windows 2000 Kennungen an und ändern sie von der historisch bedingten Großrechnernummerierung in das Konzept V.Nachname. Nun zu meiner Herausforderung: Unsere elektronische Zeiterfassung "Zeus" bietet jedem Mitarbeiter die Möglichkeit, seine Arbeitszeiten über ein Webportal abzurufen. Die Authentifizierung findet per SSO mit dem IIS 7 (7.5.7600.16385) statt, welcher auf einem Windows Server 2008 R2 Std läuft. Jedoch stellt es sich nun so dar, dass trotz der Änderung der Prä-Windows 2000 Kennung noch immer irgendwo her die alte Prä-Windows 2000-Kennung, also die Großrechnernummer zur Authentifizierung herangezogen wird, mit welcher jedoch eine Authentifizierung nicht möglich ist. Bisherige Vermutungen sind, das es im IIS noch einen Bereich gibt, in dem die SID's und die Prä-Windows2000-kennungen gecached werden. Bei meinen Recherchen bin ich auf die Einstellung des LSA-Lookup-Caches gestoßen, der ein Zwischenspeichern der Authentifizierungen verhindern soll. (DWORD-Wert: LsaLookupCacheMaxSize = 0 in "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa") Dies hat nur zu einer sporadischen, leider nicht zuverlässigen Verbesserung der Situation geführt, und dann auch nur mit einer Wartezeit von ca. 24 Std. nach Änderung der Prä-Windows 2000 Kennung. Um das Problem zu beheben, hat bisher nur ein kompletter Neustart des Windows Servers geholfen, was jedoch bei der Migration von >250 Arbeitsplätzen keine Alternative ist. Ein Durchstarten des Webs oder des IIS genügt nicht. Ich bin mit meinem Latein am Ende und hoffe auf hilfreiche Ratschläge von euch. Gruß, Marco
  3. Hallo Günther, Werde den Hinweis zukünftig gerne beachten und in den jeweiligen Fachforen die genauen Wege zur Lösungsfindung dokumentieren. Danke für diesen Hinweis. Marco
  4. Hallo Norbert, Ok da ist definitiv weniger Interpretationsspielraum. Ergo nutze ich dann auch einen Teil der 2008er Terminal Services und benötige auch dementsprechende Lizenzen. Da wird sich die Buchhaltung freuen :D Gruß, Marco
  5. Hallo Dr.Melzer, danke für deine schnelle Antwort und entschuldige das ich nochmal (vielleicht ****e) nachhaken muss. Der TS-Gateway ist zwar Teil der Remotedesktopdienste, stellt jedoch keine grafische Oberfläche bereit. Diese kommt weiterhin vom TS 2003. Ich möchte jetzt nicht spitzfindig sein, nur richtig lizenziert und ohne unnötig kosten zu verursachen. Ich finde die Microsoft-Verklausulierungen teils etwas sehr interpretationsfähig. Vielen Dank im Voraus. Marco
  6. So liebe Kollegen, ich habe leider keine wirkliche Lösung für das Problem, jedoch mit Hilfe der Kollegen unseres Systemhauses einen Workaround gefunden. Die Vermutung, dass der Exchange sich für "@online.de" verantwortlich hält, hat weiterhin bestand, da er ja jede Mail an @online.de sauber an den Postmaster liefert. Ergo hat er keine Ahnung wohin er intern damit soll. Wir haben nun aber eine OU mit dem Namen 1&1 erstellt und dort Kontakte angelegt. Diese Kontakte haben keine interne sondern die betreffende @online.de Mailadresse eingetragen. Nun scheint der Exchange sich verantwortlich zu fühlen und die Mail über die entsprechende Routinggruppe an den Smarthost zu übergeben. Und schau an: Die Mail kommt tatsächlich bei 1&1 an. Irgendwie scheint also die Kombination "-online.de" in unserem Domainnamen wie eine Art Wildcard interpretiert zu werden. Da es sich zum Glück nur um eine Handvoll Adressen und Kunden im Monat handelt, ist dieser Workaround noch handhabbar. Wenn jemand noch eine Idee hat, diesen Weg noch zu optimieren, immer her damit. Bitte dann als PN, da ich den Threat erst mal als gelöst markieren werden. Allen Helfern ein herzliches Danke. Gruß, Marco
  7. Hallo an alle Admins und IT-Fans, Ich plane eine Umstrukturierung unseres Netzwerkes für den Terminalserverzugriff und würde gern wissen ob ich mich noch auf einem lizenzrechtlich sauberen Pfad befinde. Derzeit steht der Terminalserver ganz entspannt in einer eigenen Domäne in der DMZ. Die DMZ wird durch einen ISA-Server 2006 realisiert. Auf den Servern laufen Betriebssysteme der 2003er Serie (sowohl R1, wie auch R2) Nun würde ich gerne den Terminalserver in die Domäne im internen Netz anbinden und den Zugriff über einen auf Windows Server 2008 R2 basierenden Terminalserver Gateway nach folgendem Konzept absichern. Um auf den eigentlichen Kernpunkt meiner Frage zu gelangen: Der Terminalserver soll weiterhin auf Windows 2003 laufen, um die bestehendwen Lizenzen nutzen zu können. Darf ich das so ohne weiteres oder benötige ich aufgrund des 2008er TS Gateways jetzt auch 2008er Terminalserver Cals, da der Gatewaydienst ein Teil der 2008er Terminaldienste ist?? Danke euch im Voraus. Marco PS: Falls jemand ein noch besseres Konzept zur Umstrukturierung und TS-Veröffentlichung hat, ich bin für jeden Vorschlag offen.
  8. Moin Robert, hier nochmal in Klartext die Bedeutung der Ereignis IDs. Ereignis-ID 1027 - SMTP-Informationsspeichertreiber: Nachricht von Informationsspeicher übermittelt Ereignis-ID 1019 - SMTP: Nachricht an erweiterten Warteschlangenmechanismus übermittelt Ereignis-ID 1025 - SMTP: Nachrichtenübermittlung an erweiterten Warteschlangenmechanismus begonnen Ereignis-ID 1024 - SMTP: Nachricht wurde an Kategorisierungsmodul übermittelt Ereignis-ID 1033 - SMTP: Die Nachricht wurde Kategorisiert und zur Weiterleitung in die Warteschlange gestellt Ereignis-ID 1036 - SMTP: Die Nachricht wurde zur lokalen Übermittlung in die Warteschlange gestellt Ereignis-ID 1023 - SMTP: Nachricht lokal an postmaster@ich-bin-online.de übermittelt Ereignis-ID 1028 - SMTP-Informationsspeicher: Nachricht lokal an Informationsspeicher an postmaster@ich-bin-online.de übermittelt Wollte das Problem erst mal hier posten ob es vvl. jemanden gibt der sagt "Hey das Problem hatte ich auch, ich hab es so und so gelöst." Werde das System dann hier von anderer Seite durchleuchten lassen. Trotzdem besten Dank schon mal. Sobald ich eine Begründung für das Verhalten des Exchange habe, werde ich es hier noch posten und den Threat danach als gelöst schließen. Gruß, Marco
  9. Moin Robert, schonmal danke für deine Antwort. Ich kann im SMTP-Log keinerlei kommunikation nach außen erkennen. Aber wie erwähnt nur im Bezug auf die online.de Domäne. Laut Nachrichtenverfolgung wird die Mail sauber an das Postmaster-Postfach übermittelt. Keinerlei Hinweis auf einen Fehler oder Ähnliches. Die Abläufe der Ereignisse: 1027 -> 1019 -> 1025 -> 1024 -> 1033 -> 1036 -> 1023 -> 1028 Ist da für dich irgendwas erkennbares dabei oder hast du noch eine Vermutung oder ein Bauchgefühl was da des Pudels Kern sein könnte? Hälst du es für möglich, dass es an der Namensgebung liegen könnte? Interne Domäne --------------------- ich-bin-online.local Name der Exchangeorganisation ------ ich bin Name der e-Mail Domäne ------------- ich-bin-online.de Problem bei der Zustellung an -------------- online.de Gruß, Marco
  10. Zuerst ein freundliches hallo an alle! Wir haben hier mit unserem Exchange ein wie ich finde kurioses Problem und ich hoffe ihr könnt mir helfen, dem Fehlerteufel auf die pur zu kommen. Kurz zu den Gegebenheiten: Server: Windows Server 2003 R2 Exchangeserver: 2003 Standard Dienste auf dem Server: AD, Mail, DNS, TS Die Domäne befindet sich in einer von einem ISA 2006 bereitgestellten DMZ Alle Systeme werden auf einem aktuellen Patch-Stand gehalten. Die Domäne in der DMZ nennen wir mal ich-bin-online.local Die Anbindung findet über eine CompanyConnect 2mbit Standleitung statt. Uns steht eine IP-Range von xxx.yyy.zzz.32 - 39 mit einer 255.255.255.248er Subnetzmaske zur Verfügung. Die Domäne (nennen wir sie mal ich-bin-online.de) wird von Strato gehostet. Bei Strato wurde der MX-Record auf xxx.yyy.zzz.37 eingerichtet. Ebenso ist smtp.strato.de als Smarthost eingerichtet. Der Mailverkehr funktioniert im Allgemeinen ohne Probleme, außer an die 1&1 Domäne @online.de. Eine Testmail an @onlinehome.de (ebenfalls eine 1&1 Domäne) funktioniert hingegen tadellos. Nochmal kurz eine Auflistung zum Verständnis: interne Domäne --------------------- ich-bin-online.local Name der Exchangeorganisation ------ ich bin Name der e-Mail Domäne ------------ ich-bin-online.de Problem bei der Zusellung an ----------------- online.de Beim Versand an eine @online.de Adresse wird kein Fehler Produziert. Sie wird nur direkt durch das Kategorisierungsmodul des Exchange an das Postmaster-Postfach weitergeleitet und wird gar nicht erst an den Smarthost übergeben, verlässt das eigene Netz also nicht. Den einzigen, mir aber nicht wirklich logischen Grund für dieses Verhlten wäre die Kombination auf Exchangeorganisationsmen und der online.de Domäne. Ein allgemeines Routingproblem zu online.de besteht nicht. Ebenso sind auch keine Mailadressen mit *online.de angelegt. Es existiert auch nur eine DEfult Routinggruppe im Exchange die den gesamten Mailverkehr (außer dem, den der Exchange direkt über die im AD eingetragenen Mailadressen zuordnen kann) an den Smarthost übergibt. Ich hoffe ich konnte Das Problem ausreichend detailliert schildern. Ansonsten bitte ich um Nachfrage wenn ihr noch Informationen braucht um mich bei dem Problem zu unterstützen. Besten Dank im Voraus Marco
×
×
  • Neu erstellen...