FBI01

> VPN-Verbindung: Haken raus bei "Routing im Dings da > verwenden", habs gerade nicht parat. Du meinst die VPN Verbindung auf dem Client und dort: Eigenschaften -> Netzwerk -> Internetprotokoll (TCP/IP) -> Eigenschaften -> Erweitert -> ( ) Standardgateway für das Remotenetzwerk benutzen ... ansonsten bitte nochmal die Sache mit dem "Dings da" genauer beschreiben.

Hier die Lösung: Wenn via VPN der DNS nicht vollständig erreichbar ist liegt's am Routing. Der Server muss 1. eigerichtet sein als Router + RAS 2. IP-Routing aktivieren 3. -> IP-Routing -> Eigenschaften -> Namensauflösung -> IP-Adressen auflösen für Clients die DNS verwenden 4. IP-basierte RAS- und Verbinden bei Wählen bei Bedarf zulassen ... was hat sich das Entwicklerteam ( Übersetzungsengine ) bei diesen Kästechen und Häkchen blos gedacht ??? JETZT kann http://companyweb aufgelöst werden. ENDE

Irgendwas mit der Namensauflösung schlägt hier fehl ... Ich bin auf einem Notebook mit Anbindung an das lokale Netz. Eine Anmeldung in der Domain ist möglich, ich bin aber gerade nur lokal angemeldet. Gebe ich ein: http://mainserver erscheint sofort die"Willkommen" Seite. http://comanyweb ist wie üblich nicht erreichbar ... Jetzt der Test mit nslookup: > mainserver Server: mainserver.mainwork.local Adress: 10.10.1.20 *** mainserver wurde von mainserver.mainwork.local nicht gefunden: Server failed > ping mainserver geht ! ... verstehe ich nicht, über welches Protokoll wurde der Name denn über den Browser aufgelöst ? Auf der Netzwerkverbindung ist nur der SBS als DNS eingetragen. Jetzt habe ich auf der Netzwerkverbindung "NetBIOS über TCP/IP deaktivieren" angewählt und es ist "natürlich" kein Host mehr erreichbar, auch mainserver ( wie oben beschrieben ) geht nicht mehr: Folgerung: Der SBS DSN wurde noch gar nicht befragt ; ) oder "Server failed" deutet doch auf ein Rechteproblem hin ... ### Muss der anfragende PC als Clientcomputer eingetragen sein und in der Gruppe Domaincomputer ?? ### FBI01

> Der Alias ist eine reine DNS Sache. Alias Einträge werden > verwendet, wenn ein Host unter mehreren Namen erreicht > werden soll. Das steht ausser Frage. Interessant ist, dass der ALIAS Eintrag im Intranet funktioniert und für alle Clients im VPN nicht - OBWOHL der Server im VPN korrekt aufgelöst wird. ( Also sowas hab ich bei BIND noch nie gehabt. ) > z.b. Host(A) server.sbs.local IP > dann verweist der Alias companyweb auf server.sbs.local > > Wenn du nslookup companyweb aufrufst, dann solltest du > folgendes erhalten: > > server: server.sbs.local > Adress: IP Adresse des server.sbs.local > > Name: server.sbs.local > Adress: IP Adresse des server.sbs.local > Aliases: companyweb.sbs.local So sieht auf dem Server und allen Clients im LAN aus, aber NICHT bei denen im VPN. ( ??? ) Und nochmal, die Subdomain "companyweb.sbs.local" muss doch vom Web-Server zu einem bestimmten Content-Bereich "gebracht werden" ... beim Apache sind das die sog. Virtuellen Hosts. Auswertung über der Request-Header ... Habe einen neuen ALIAS im DNS angelegt: companyweb2 -> mainserver.mainwork.local ... landet logischerweise auf der Hautstartseite. Funktioniert aber nur auf dem Server, nicht auf den VPN-Clienets : ( Abgesehen davon, dass im VPN die Auflösung nicht funktioniert ( geht es vielleicht um Rechte oder Vererbungen* ? ) so muss die Subdomain doch irgendwo auf den Port 80 und 444 "umgesetzt" werden, also der angeforderte Kontent im Header wird übergeben und dann soll das "companyweb" erscheinen. Wo wird das konfiguriert ? FBI01 * PS: Hat sich eigentlich schon mal jemand Gedanken darüber gemacht was passiert wenn Microsoft nicht vererbt wird ?

> Du hast companyweb in der Forward-Lookupzone als Alias > (CNAME) eingetragen ? Ja ! ( hatte ich eben noch oben ergänzt ) > Teste mal deinen DNS mit nslookup dein_server_name und > nslookup deine_server_ip. > Funktioniert das ? Ja ! Deswegen geht mein Verdacht eher in Richtung Web-Server. Der sollte doch die Subdomain interpretieren, oder ? FBI01

> Auch über die VPN Verbindung erreichbar ? Ja, mit dem Port war das companyweb erreichbar ! Das ist doch ein DNS Problem ... > "ping companyweb" bleibt ohne Antwort : ? > "ping <server>" wird sofort beantwortet ... Jetzt habe ich den ALIAS Eintrag im DNS einmal gelöscht und wieder eingefügt - nun ist auch im Netz companyweb nicht mehr erreichbar. > nslookup companyweb ... auf dem Server ist jedoch ok -> Name: companyweb.MAINWORK.local ... hm Da muss doch der Server auch konfiguriert werden für diese Subdomain - nur wo ? FBI01

( ... ) Assisten "Verbindung mit dem Internet herstellen". Vielen Dank für den Tipp ! Ja, unter https://<IP>:444 ist das "companyweb" erreichbar. Nachdem ich "Verbindung mit dem Internet herstellen" durchgeführt habe, hat sich aber nichts geändert. Aus dem Internet sollen keine Zugriffe stattfinden sondern nur über den lokalen VPN ( RAS ) ... ist die Lösung evtl. dass keine Zugriffe gestattet werden ? Im lokalen Netzt funktionierts ja, nur eben über RAS nicht - könnte das auch an irgendwelchen DNS-Rechten liegen ? Für mich sieht es eher so aus, als ob der DNS den ALIAS "companyweb" nicht ordentlich auflöst ... Wo genau wird denn der ALIAS "companyweb" vom Webserver auf Port 80 und 444 interpretiert ? Ist das sowas wie ein Virtual-Host bei Apache ? Wo konfigiriert man das ? Grüße FBI01

Kennt keiner diesen Zustand ? Auch nach einer kompletten Neuinstallation können keine Clients aus dem VPN den ALIAS "companyweb" auflösen ... Der Server, hier "hautpserver" ... also -> http://hauptserver wird auf den VPN-Clients aufgelöst und ist pingbar. Kann es sein, dass die Clients aus dem VPN keine ALIASes auf dem MS DNS erreichen oder auflösen können und wenn ja, warum ? FBI01

... es ist nach intensiver Bearbeitung des DNS wohl doch eine Neuinstallastion notwendig : ( Nebenbei bemerkt: Ich lass in anderen Themen, dass sogar Domainen mit Umlauten eingetragen wurden ... ich hatte hier eine Domain wie "abc-df.local". Ist der Bindestrich ein Problem für den MS DNS ? Der Alias zu companyweb war zum Ziel "abc.df.local" eingestellt ... da ist doch irgendwas schief gelaufen bei der Installation. Eine nachträgliche Änderung führte leider nicht zum Erfolg : ( FBI01

( ... ) gegen eine Eicon Diva getauscht. Damit waren die Probleme behoben. Vielen Dank für den Tipp ! Meinst Du eine: - Eicon Diva ISDN PCI LowProfile - BRI(S/T) Anschluß/ 128 kBit/s/ Plug Play/ 14,4 kBit/s /FAX /14,4 kBit/s Modem/ MLPPP/ RVS-COM Lite Software/ Voice Unterstützung/ V.120/ Windows 2000/ NT/Me/9x/XP/ Linux Preislage ~ 78,00 € oder ein anderes Modell ? FBI01

> Das passiert dann, wenn auf dem Client noch kein FAX-Client > unter XP-SP1 installiert war. > Abhilfe siehe - http://support.microsoft.com/?kbid=885123 Vielen Dank ! > Zum Thema FAX-Empfang und Abbruch. Es gibt einige FAX- > Gegenstellen, die mit ISDN Karten Probleme haben. Bei meinen > Kunden hat fast immer ein Austausch auf andere FAX-KArte > (aktiv) oder analoges Modem eine wesentliche Besserung > gebracht. Was für eine Karte von AVM ist zu empfehlen ? Ich habe hier noch diverse ELSA MicroLink 56k rumliegen - muss man da viel AT's reinticken damit's klappt ? Mein Test war u.a AVM Fritz! PCMCIA -> AVM Fritz! PCI im eigenen ISDN Bus ... da muss der Fehler doch beim SBS2003 liegen ... Grüße FBI01

Das Fax ist über "Faxdienst konfigurieren" für 3 MSNs konfiguriert - an der ISDN-TK-Anlage kann im IDSN Protokoll alles beobachtet werden - grundsätzlich ist alles richtig konfigiriert. Hier nun die aktuellen Probleme: - werden mehr als 1 Seite empfangen bricht der Empfang einfach ab und der offene Job ( im Empfangsfach ) bleibt etwa 50 Sekunden länger stehen, als die ISDN Verbindung überhaupt noch aufgebaut ist - der Versandt aus Windows XP Pro SP2 ist nicht möglich; der MS Fehlerassisten ist unser bester Freund ( es gab hier auch schon Beiträge dazu, ggf. müssen wir einen anderen Faxdienst vom Server auf die Clients bringen ... ) Zu o.g. Problem - Kann es an der AVM Fritz! PCI V2 Karte liegen ? Gibt es bestimmte default Prüfungen bei eigehenden Faxen ? Ist der Betrieb via CAPI/TAPI via AVM CAPI Konfig problemlos möglich ? Wir haben für jede MSN ein neues Empfangsostfach eingestellt; die Ziele sind existent und bei 1 Seite läuft's auch. - Wir haben natürlich auch mehrere Faxgeräte genutzt um die Störungen weiter "einzukreisen" ... Gibt's da eine Lösung ? FBI01

-companyweb- nicht für VPN Teilnehmer erreichbar ... Zunächst ein grundsätzliche Verständnisfrage: http://companyweb'>http://companyweb wird als "Alias" im Windows DNS auf http://<server>.<domain>'>http://<SERVER>.<DOMAIN> weitergeleitet und dort als - eigenständige Domain interpretiert Ist das soetwas wie ein Virtual-Host ? Hier tritt folgendes Problem auf: Die Adresse http://companyweb ist von allen Rechnern im LAN ( und dem Server ) erreichbar. Auch von denen, die nicht in der Domain sind. Es gibt ein LAN mit 10.10.1./24 in dem der Server und alle LAN-Clients stehen. Diese LAN ist hinter einer Firewall. Durch die Firewall können sich User ( die auf dem SBS2003 eingerichtet sind ) per VPN anmelden und haben bereits auf freigegeben Verzeichnisse Zugriff. Alles läuft ok im VPN - alle User sind Teil des LAN. Nun das Problem: Die VPN Nutzer können zwar auf http://<server>.<domain> zugreifen, nur wenn man dort den Link zum "companyweb" anklickt ( oder direkt eingibt ) kann die Adresse nicht aufgelöst werden. - kein Auflösung ( NUR für companyweb ) - keine Fehlermeldung zu Rechten - als Primary DNS ist auf den VPN-Clients der <server> eingetragen als IP ! - als Standart-Gateway ist der <server> eingetragen als IP ! Wo kann der Fehler liegen ? Ist das "Workaround" mit dem "Datum" die einzige Lösung ? Grüße FBI01

( ... ) im Router muss der Port 444 zum Server zeigen! Wie ist es denn mit einem VPN ? Ich würde den SBS2003 -NICHT- hinter einem Router einfach so ins Internet stellen. Für alle User lässt sich doch ganz leicht der RAS aktivieren und dann kann der User über die VPN Verbindung etwas "eleganter" UND SICHERER auf die "companyweb"-Seiten zugreifen. FBI01

( ... ) Kann jemand helfen ? Der Fehler sieht bei mir leider ähnlich aus ... Im Board wurde dieser Lösungsweg beschrieben: - alle Clients abmelden - Serverdatum auf < 24.11.2003 stellen - Software -> Windows Small Business Server -> Wartung -> Intranet deinstallieren - Software -> MS SQL Server-Desktop Engine Sharepoint deinstallieren - Intranet wieder installieren - Server neu starten - Datum wieder aktuelisieren Hiernach soll's wieder laufen. Kann das jemand bestätigen ? FBI01