Jump to content

GFischer

Members
  • Gesamte Inhalte

    7
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von GFischer

Apprentice

Apprentice (3/14)

  • Erste Antwort
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei
  • 1 Jahre dabei

Neueste Abzeichen

10

Reputation in der Community

  1. Es gibt keinen Kunden!! Das ist ein Evaluierungssystem dessen Lizenzschlüssel ich vom Lizenzrecht gedeckt aus dem Technet-Abo habe. Was wird getestet? Eine Branchensoftware, die jemand entwickelt. Wer testet? Ich, Admin (MCSE 2003 + MCITP 2008 Enterprise Administrator). Ich entwickle selbst nicht. Ehrlich gesagt finde ich es frustrierend, dass hier nur beleuchtet wird, ob das TechNet Plus Abo ausreicht. Auf die Ungereimtheiten, die sich beim simplen Aufsetzen des Systems schon ergeben haben, will anscheinend, außer Lizenzdoc keiner eingehen.
  2. Natürlich verwenden wir zur Entwicklung voll lizenzierte Rechner in voll lizenzierten Entwicklungsumgebungen. Als Admin führe ich lediglich einen Installer mit einer fix- und fertigen Software aus, und schau ob sie unter diesem (vielleicht neuem) Betriebssystem und unter sell- und jenem Aufbau noch funktioniert. Auf den Systemen wird nichts entwickelt, und sie sind auch nicht produktiv. Das ist alles abgeklärt, das passt schon, mach euch keine Sorgen. @lizenzdoc: war jaksa jetzt der Doc, den du erst mal fragen musst? Da wir die "Lücke" (welche Lücke, das mit dem löschen von MSLicening oder das mit dem "pro Benutzer" und dem stets funktionierenden Lizenzservers?) schon selbst gefunden haben: Mir würde ein beruhigendes, passt scho, lass ma so (...wie?) laufen, genügen. Details wären mir für das Verständnis jedoch lieber. Hier will auch keiner bewusst eine Lücke suchen und ausnutzen, sondern es sind beim Aufsetzen und der Installation einfach Unstimmigkeiten aufgefallen. Dies sind schlicht und einfach die daraus resultierenden Fragen.
  3. Hallo zusammen, um es kurz vorweg zu schicken: Es geht mir nicht darum Microsoft zu betrügen. Wir sind TechNet-Abonnent und verwenden die dort erhältlichen Lizenzen nur zur Evaluierung, sprich für Testsysteme. Unsere Testaufbauten dienen zur Erprobung einer von uns entwickelten Software. Diese Scenarien müssen allerdings mit unter recht lange testfähig bleiben. Wir fahren gerade einen Testaufbau mit einem 2008 R1 Terminalserver ohne AD-Integration. Den Terminal-Lizenzserver habe ich gleich mit installiert. Dieser ist nicht aktiviert und stellt nur temporäre Lizenzen aus. 1. Wie lange tut er das inaktiviert? Habe mal die Systemzeit auf 2015 vorgestellt, konnte mich immer noch per RD verbinden. Der Server hat nur sein selbstsigniertes Zertifikat für Serverauthentifizierung erneuert, das wars. 2. Den Terminalserver selbst schien das Datum 2015 auch nicht zu stören. Die 120 Tage scheinen wirklich nur für den Betrieb völlig ohne Lizenzserver zu gelten. Richtig? Oder fängt der Terminalserver sich doch irgendwann an daran zu stören, dass der Lizenzserver nicht aktiviert ist? Ist dieses Ereignis bloß in den 20 Minuten in denen ich die Systemzeit vorgestellt hatte nicht eingetreten? Ich hatte in dieser Zeit den Server auch mal neu gestartet... Trotzdem alles OK. 3. Wir hatten die Test begonnen mit Lizenzierung "pro Gerät". Da hat man die temporären CALs auch schön im Manager gesehen. Würde nun eine Lizenz ablaufen, so löscht man am CLient den Schlüssel "MSLicening", startet die mstsc einmal als Administrator, und bekommt ein neue temporäre Lizenz ausgestellt. Ausprobiert, geht, soweit so gut. Alles gut überblickbar und verständlich. Nun haben wir testweise auf "pro Benutzer" (ohne AD) umgestellt. Es erscheinen keine temporäre Lizenzen mehr im Manager, man kann sich aber trotzdem verbinden? Das Vorstellen der Systemzeit (s.o.) habe ich auch in diesem Modus vorgenommen. Wie kann das sein? Wo sind meine temporären "pro Benutzer"-Lizenzen? Warum liefen die nicht bei vorgestellter Systemzeit ab? Wie gesagt, hier will keiner Microsoft betrügen. Ich will nur wissen was passiert, und dafür sorgen können, dass unser Testsystem in 91, 121, 181 oder 366 Tagen immer noch testfähig ist. Grüße!!
  4. @necron Ich muss mich mal präzisieren, da hast Du recht: Es dauert immer ziemlich gleich lange um Namen aufzulösen, egal ob: 1. ich per Browser auf einen Webserver im Remotenetzwerk zugreife (definitiv keine Netbios-Auflösung) 2. ich per UNC-Pfad über den Explorer auf ein Share zugreife (eventuell Netbios) 3. ich einen ping auf einen Kurznamen absetze, der mit einem FQDN beantwortet wird (ziemlich sicher DNS-aufgelöst) Ich könnte mir folgendes vorstellen: Es wird erst für das lokale Netz das Ballett host-dnschache-dnsserver-(wins)-broadcast-lmhosts aufgeführt, was dauert, und dann das ganze Ballett nochmal für die VPN-Verbindung angefangen, was dann mit einer Antwort vom DNS im Remotenetzwerk endet? Möglich? Wäre zumindest eine Erklärung für die Langsamkeit, und dass es ÜBERHAUPT funktioniert. Und wie könnte man, außer mit einer sekundären Zone im lokalen Netz für die Remotezone, die Auflösung noch beschleunigen?
  5. Sorry, ich bin auf der Arbeit, der Post war auch so lang genug... Ächz, immer dieser Zeitdruck... du weißt schon... :) was wiederum eine broadcast namensauflösung wäre, so denn kein WINS server vorhanden, oder? und der broadcast geht auf die broadcastadresse des lokalen Netzes, und nicht auf die des Remotnetzwerkes. Oder? Ausserdem, nicht ganz richtig. In einem vollständig durch DNS aufgelösten Netzwerk ist meines Wissensstandes Netbios nicht notwendig... solange Outlook keinen Exchangeserver sucht :). Was Windows dennoch versucht, steht auf einem anderen Blatt... Der lookup greif natürlich auf den lokalen Router zu... non-existent domain. Spricht wiederum für Netbiosnamensauflösung. Kann aber nicht sein. UND der Ping auf clientXY liefert vorallem eine Antwort von clientXY.domainXY.local. Was auch gegen Netbios spricht. Da käme die Antwort von ClientXY, kein FQDN. Oder? Da hats Du allerdings recht, da hab ich quatsch geschrieben.
  6. Ja logisch geht es damit schneller. In die host schaut der Client ja zuerst rein. Das ist aber keine Lösung. Es sollen beliebe Shares im Remotenetzwerk erreichbar sein. U.u. auch unter wechselnden IP Adressen. Andere Vorschläge? Vor allem Erklärungen warum es überhaupt geht? :D
  7. Wie konfiguriere ich einen Windows-VPN-Client richtig, so dass er Rechnernamen über das VPN im Remotenetzwerk auflösen kann? Schon ein Artikel diesbezüglich vorhanden? Habe folgendes konfiguriert, funktioniert meistens, DNS-Auflösung dauert aber lange (selten geht es auch garnicht): Server: Win2008, DHCP, DNS mit Zone domainXY.local, Routing und RAS über PPTP. Der DHCP-Bereich ist natürlich mit der Option DNS konfiguriert. Client: XP/Vista/Win7, hinter NAT-Firewall/Router (z.B. FritzBox), PPTP-Verbindung ist mit verbindungsspezifischem Domänensuffix domainXY.local konfiguriert, bekommt vom DHCP korrekt seine IP, registriert sich auch korrekt in der Zone domainXY.local bzw. der DHCP macht das für ihn. Rein IP+SMB+etc. mäßig funktioniert alles, nur dauert die Auflösung von Clients im Remotenetzwerk meistens sehr lange, und manchmal gehts gar nicht. Fragen: 1. Muß der Benutzer am Client beim Zugriff über Explorer/SMB auf z.B. ein Share nun zwingend den FQDN angeben, oder kann man sich auch darauf verlassen, dass Windows bei den Auflösungsversuchen brav automatisch das verbindungsspezifische Suffix domainXY.local anhängt und ausprobiert? 2. Da es im lokalen Netz des Clients keinen DNS mit der Zone domainXY.local gibt, sondern nur einen Router mit einem DNS-Proxy möchte man ja verhindern, dass letzterer überhaupt gefragt wird. Ist es mit dem konfigurieren des verbindungsspezifischen Suffix auf der PPTP-Verbindung getan? Läuft die Auflösung bei Angabe des FQDN nun über den DNS im Remotenetzwerk? Oder gibt es noch etwas anderes, was man tun kann? 3. Oder gibt es für eine saubere DNS-Auflösung der Rechner im Remotenetzwerk nur die Lösung mit einem lokalen DNS, z.B. mit einer Sekundären Zone für domainXY.local? Anmerkung: Mir ist schon klar, das das Problem die Reihenfolge der DNS-Server ist. Der lokale Router wird gefragt, und nicht der DNS im Remotenetzwerk. Was mich aber Wurmt: eigentlich sollte es ja gar nicht funktionieren. Vor allem nicht, weil momentan in der PPTP-Verbindung des Clients nicht mal das Häkchen "Gateway für das Remotenetzwerk verwenden" gesetzt ist. Das würde das komplette Routing ja über das VPN jagen, so dass der lokale Router gar nicht erreicht und gefragt wird. Bleibt zu guter letzt nicht mal die Möglichkeit, dass der Name über broadcast aufgelöst wird... dieser geht ja immer auf die broadcastadresse des eigenen Netzes, nicht auf die des Remotnetzwerkes... oder auch zusätzlich auf die broadcastadresse des Remotenetzwerkes?
×
×
  • Neu erstellen...