s.k.

Hallo Nils, Hallo Jan, besten Dank für Eure schnellen und kompetenten Antworten! Das hat mir sehr geholfen, einen schnellen EInstieg zu finden. Seit ca. 2006 bin ich eigentlich nur noch in der Netzwerkschiene unterwegs gewesen und hatte seither kaum noch Updates in Sachen MS - weder technisch noch lizenzrechtlich. Bei beidem hat sich die Welt aber offenkundig erheblich weitergedreht. EIn guter Anlass, mich mal wieder auch in diesem Bereich etwas näher an den aktuellen Stand zu bringen. Habe zwischenzeitlich auch Zugriff auf unser VLSC und werde unsere Vorhaben und Anforderungen mit dem zuständigen LAR/LSP besprechen. Da wird dann alles ordnungsgemäß lizensiert. Nach heutiger Abstimmung mit zwei Carriern sieht es übrigens ohnehin so aus, als ob wir auf den TS verzichten und Fatclients einsetzen könnten, weil wir voraussichtlich für vergleichsweise schmales Geld (sogar wegeredundante) Dark-Fiber bekommen können. Das löst dann auch ein paar andere Probleme gleich mit. :-D Danke und Gruß Steffen

Hallo allerseits, [Vorwort/Einleitung] im Moment rollt bei uns ein Projekt, in welches ich (Mitarbeiter der internen IT-Abteilung einer Kommunalverwaltung) erst seit kurzem involviert bin (wie so oft, sind wir erst nachträglich/zu spät einbezogen worden). Das Vorgehen im Rahmen dieses Projektes muss ich einerseits inhaltlich und finanziell bewerten und kann ich andererseits in gewissen Grenzen noch in die eine oder andere Richtung steuern. Die Schwierigkeit besteht darin, (sehr) kurzfristige Funktionsanforderungen im Wege einer noch auszugestaltenden Interimslösung mit einer Migrationsplanung für das Jahr 2019 in Einklang bringen zu müssen. Inhaltlich und organisatorisch gibt es je nach gewählter Interimslösung halt Vor- und Nachteile - das ist aber nicht Teil dieses Threads. Mir geht es hier darum, eventuelle Fallstericke des Lizenzrechts zu erkennen und diese in die Entscheidungsfindung einfließen lassen zu können. Oder mit anderen Worten: Ich möchte einerseits sicherstellen, dass es zu keiner Unter- oder Fehllizensierung kommt und andererseits natürlich auch Doppel- oder Überlizensierung vermeiden. Da ich mich mit dem Lizenzrecht nicht in der Tiefe auskenne, bitte ich Euch um entsprechende Hilfestellung. [Fallgestaltung/Sachverhalt] Es gib einen separaten Betriebsteil der Behörde, der aufgrund seiner Anforderungen hinsichtlich der zeitlichen Verfügbarkeit des IT-Personals nicht von der internen IT-Abteilung, sondern von einem externen Dienstleister betreut wird. Hier läuft derzeit ein einzelner physischer Host mit VmWare ESXi und darauf mehrere virtuelle Windows-Server - unter anderem ein Fileserver und ein DB-Server (derzeit noch Oracle). Diese virtuellen Windows-Server sind derzeit per Einzellizenz über den Select-Vertrag der Behörde lizensiert. In 2019 wird dieser physische Host ersetzt. Dann wird eine HA-Lösung mit 2 physischen Nodes und VwWare ESX mit Virtual Center implementiert. Als DB soll dann wohl auch auf MS-SQL umgestellt werden, da Oracle in diesem Umfeld sonst wohl lizenztechnisch zu teuer würde. Bereits in 2018 soll jedoch einer anderen Behörde Zugriff auf das eingesetzte Fachverfahren und die Datenbank gegeben werden. Hierzu wird ein Site-to-Site-VPN aufgebaut und ein MS-Terminalserver bereitgestellt werden, welcher von der anderen Behörde quasi als abgesetzter Client ferngesteuert wird. Der Terminalserver soll (nach jetziger Planung) nicht Teil der internen Domäne des Standortes sein, sondern in einer DMZ (VLAN) isoliert bzw. reglementiert als Einzelserver betrieben werden. Es handelt sich vorerst um bis zu 3 parallele TS-Sessions/Nutzerzugriffe. Der externe Dienstleister hat hierfür folgendes angeboten/vorgeschlagen: - Aufrüstung des vorhandenen Hosts mit Arbeitsspeicher - Erweb einer OEM-Lizenz für MS Terminalserver mit 5 Usern - Installation des TS als VM auf dem vorhandenen ESXi (mit derzeit einem Node) Die Kosten für die Aufrüstung des vorhandenen Hardwareservers sind nicht ganz unerheblich und es wiederstrebt mir, diese für ein System zu investieren, welches nur noch ca. 12 Monaten in Betrieb sein wird. Auch würden wir gerne unnötige Downtime vermeiden. Deshalb ist die Überlegung, den Terminalserver übergangsweise auf dem VM-Ware-Cluster der Kommune zu hosten, bis dieser 2019 auf das neue System des betreffenden Betriebsteiles umziehen kann. Technisch wäre dies problemlos machbar. Der VmWare-Cluster der Kommune besteht aus 8 Hardwarenodes und ist hinsichtlich der MS-Server per Selectvertrag über entsprechende Datacenter-Lizenzen ablizensiert. [Zusammenfassung der Handlungsalternativen] Variante 1) - Aufrüstung des Speichers des 1-Node-ESXi in 2018 - hierauf Installation eines MS-TS; lizensiert als OEM-Version für 5 User - 2019 Umzug der TS-VM auf ein neuen 2-Node-ESX Variante 2) - Installation des MS-TS auf dem vorhandenen 8-Node-ESX der Kommune - Lizensierung des TS entsprechend den Erfordernissen - 2019 Umzug der TS-VM auf ein neuen 2-Node-ESX [Fragen] Für mich ergeben sich folgende lizenzrechtliche Fragen, deren Beantwortung ich mir hier erhoffe... 1) Beeinhaltet die OEM-Lizenz des TS auch den "Basis-Server" oder muss der zusätzlich lizensiert sein/werden? Gleiches gilt für die Cals. 2) Ist die OEM-Lizenz des TS ausreichend in der 1-Node-Umgebung? 3) Ist die OEM-Lizenz des TS ausreichend in einer Mehrfach-Node-Umgebung? Stichwort: Lizenzmobilität zwischen den Nodes? 4) Ergibt sich beim Umzug der vorhandenen virtuellen Windows-Server von der jetzigen Single-Host-Plattform hin zur 2-Node-HA-Plattform im Jahr 2019 in dieser Hinsicht ein veränderten Lizenzbedarf? 5) Wie ist 2019 der MS-SQL-Server zu lizensieren? Dann doch noch zwei technische Fragen: 6) Ist es möglich, den TS als Einzelserver (ohne Domäne) zu betreiben? 7) Kann der Lizenzserver in diesem Fall direkt auf TS direkt sein? Wenn nein: könnte er auf einem anderen Server sein, der Mitglied einer Domäne ist, die der TS selbst nicht angehört? Sollte ich weitere sich daraus ergebende Fragestellungen bisher nicht identifiziert haben, bitte ich ebenfalls um entsprechenden Hinweis. Danke und Gruß sk

http://www.administrator.de/frage/vlan-konfiguration-netgear-switch-153673.html#comment-607552

Hallo, ja der Switch hat offenkundig einen Speicherfehler und sollte daher produktiv nicht mehr eingesetzt werden, da zumindest mit Instabilitäten zu rechnen ist. Dass Deine VLANs nicht funktionieren dürfte aber eher daran liegen, dass Du das Funktions- und Konfigurationsprizip dieses Switches noch nicht durchschaut hast. Wenn ich Deine Ausführungen richtig verstanden habe, möchtest Du mehrere Securityzonen ("DMZten") auf dem selben Switch abbilden - den großen Switch also virtuell in mehrere kleinere Switche teilen. In den DMZten stehen jeweils einzelne oder mehrere Server, die sich innerhalb der gleichen Sicherheitszone/DMZ durchaus untereinander erreichen können sollen. Zonenübergreifend erfolgt die Kommunikation jedoch über eine Firewall und wird dort entsprechend beregelt. Offenkundig hat diese Firewall auch genügend physische Interfaces, um jeder Sicherheitszone ein dediziertes Interface zuweisen zu können. Soweit richtig? Dann hier ein Beispiel: Angenommen Du hast die Sicherheitszonen DMZ10 und DMZ20, welche Du auf die VLANs 10 und 20 abbilden möchtest. VLAN10 umfasst die Switchports 10-19 und VLAN20 die Switchports 20-29. An dem ersten Port hängt jeweils die Firewall mit einem dedizierten Interface und an den restlichen Ports jeweils bis zu 9 Server. In diesem Szenario sind alle Ports untagged im jeweiligen VLAN. Auch die Firewallports. Tagging findet ausschließlich switchintern - nicht jedoch zu den angeschlossenen Devices hin statt. Dies konfiguriert man folgendermaßen: Unter "VLAN" > "IEEE 802.1Q VLAN" werden die jeweiligen VLANs angelegt sowie die Portmitgliedschaft und das Taggingverhalten für den _ausgehenden_ Traffic festgelegt. Hier konkret: VAN 10 = Port 10-19 untagged, alle anderen Ports "not Member" VAN 20 = Port 20-29 untagged, alle anderen Ports "not Member" Bis hierhin hast Du dies vermutlich auch korrekt eingerichtet gehabt. Wahrscheinlich war Dir aber nicht bewusst, dass dies nur die "halbe Miete" ist, denn neben der Zuordnung der VLANs zu den Ports hast Du dem Switch hiermit lediglich mitgeteilt, dass er die Frames auf diesen Ports ohne VLAN-Tag ausgeben soll. Was Du ihm an dieser Stelle noch nicht gesagt hast ist, in welches VLAN der Switch solchen Traffic stecken soll, der auf diesen Ports ohne explizite Kennzeichnung (also ohne VLAN-Tag / "untagged") _eingeht_! Dieser Konfigurationsschritt erfolgt unter dem Punkt "Port Configuration" in der Spalte PVID. Hier konkret: Port 10-19 = PVID 10 Port 20-29 = PVID 20 Standardmäßig steht hier jeweils das Default-VLAN 1 drin. Weshalb der Switch _eingehenden_ Traffic ohne explizites Tag auch dann noch in das VLAN1 schiebt, wenn die Ports _egress_ in einem anderen VLAN auf untagged gesetzt sind! Anders als bei einigen anderen Herstellern, die dem Admin das Denken abnehmen, lässt es Zyxel (und auch viele andere Hersteller) durchaus zu, dass ein Port _ausgehend_ in mehreren VLAN untagged Member sein kann. Nur _eingehend_ ist es der Natur der Sache nach eine 1-zu-1-Beziehung. Dieses Verhalten entspricht durchaus dem normierten Standard und erlaubt es unter anderem, sog. "asymmetrische VLANs" zu konfigurieren. Dann noch ein Wort zu Deinem Autonegotiation-Problem: Dass der Switch auf 100MBit/s runterschaltet, wenn Du nur die andere Seite fest einstellst, ist kein Fehlverhalten des Switches sondern standardkonform. Ein Gerät, welches auf Autonegotiation eingestellt ist und bei der Aushandlung auf eine Gegenstelle trifft, die nicht verhandelt, schaltet dem Standard entsprechend auf 100 MBit/s Halfduplex herunter. Nicht standardkonform verhält sich bestenfalls die NIC des Servers, denn bei Gigabit Ethernet ist das Anbieten von Autonegotiation eigentlich Pflicht. Selbst wenn man im Treiber fest Gigabit einstellen kann, sollte dies eigentlich so implementiert sein, dass die Karte dennoch Autonegotiation macht, sich aber nur auf Gigabit einigt. Leider hält sich da aber nicht jeder Hersteller dran. Gruß sk

Hi, wie es zu konfigurieren ist, hängt von den eingesetzten Routern ab und nicht selten gibt es auch verschiedene Wege mit unterschiedlichen Vor- und Nachteilen. Hier ein Konfigurationsbeispiel für eine ZyWALL USG: http://www.studerus.ch/de/support/knowledgebase/detail/3168 Auf jeden Fall empfiehlt es sich, auf beiden Seiten die Systeme des selben Herstellers einzusetzen. Gruß sk

Mach Dir da nicht so viele Gedanken drum. Sofern nicht bereits auf Layer2 Mechanismen zur Flusskontrolle greifen, sorgt spätestens TCP dafür, dass keine Pakete verloren gehen und der Sender nicht schneller sendet, als der Empfänger es verarbeiten kann. Gruß sk

Noch eine Rückmeldung von mir: Der aufgezeigte Weg funktioniert leider NICHT. Auch ein Austausch des Schlüssels mit slmgr.vbs geht nicht. Möglich ist ein Upgrade durch Drüberinstallieren. Dabei wird ein neues Windows-Verzeichnis erstellt und das alte umbenannt. Die Treiber werden dabei übernommen. Das alte Verzeichnis lässt sich leider nicht komplett löschen - belegt also weiterhin reichlich Platz. Das ganze System lief danach auch deutlich weniger performant. Der Einsatz der Enterprise-Version scheint also mehr oder minder zwingend eine komplette Neuinstallation vorauszusetzen. Gruß sk

http://de.wikipedia.org/wiki/Provider_Independent_Address_Space

Super. Vielen Dank! Gruß sk

Hallo, wir haben für eine Schule einen Infocus Bigtouch 55 Zoll mit vorinstalliertem Win8 pro erworben. Das System soll in die Domäne aufgenommen werden und es soll u.a. Applocker genutzt werden. Für letzteres benötigen wir nach meinem Kenntnisstand Windows 8 Enterprise. Der Lizenzerwerb ist kein Problem - wir haben eine Software Assurance nachgekauft. Ich würde jedoch gern auf eine Neuinstallation des Systems verzichten - zum einen der Arbeit wegen und zum anderen, weil weder Installationsmedien/Treiber-CDs mitgeliefert wurden, noch diese auf der Homepage heruntergeladen werden können. Deshalb die Frage: Kann man die bereits aktivierte Win8pro-Installation durch einfaches Neueingeben des Enterprise-MAK-Schlüssels ohne Neuinstallation auf die Enterprise-Version anheben? Falls relevant: Der Win8pro-Key scheint nicht ins BIOS des Bigtouch integriert zu sein. Er befindet sich auf einem klassischen COA-Aufkleber auf der Rückseite des Gerätes und musste vor Aktivierung von Hand eingegeben werden. Danke und Gruß sk

Es gibt keine SFPs mit ST-Anschluß. Das ist rein von den physischen Abmessungen her nicht möglich. Es gibt natürlich (ältere) Modultypen, die größer sind (Z.B. X2 oder GBIC) und damit genügend Raum für ST bieten würden. Die haben aber in der Regel SC. ST habe ich da noch nie gesehen. Wäre aufgrund des Bajonettverschlusses auch sehr unpraktisch. Möglicherweise gab es mal Switche mit fest verbauten ST-Anschlüssen - das will ich nicht ausschließen, aber auch das wäre für die Steckerart bzw. den Buchsentyp am Patchfeld letztlich völlig unrelevant, denn man kann sich Patchkabel mit allen erhältlichen Steckerkombinationen anfertigen lassen. Relevant wäre der Anschlußtyp am Modul/Switch nur dann, wenn man direkt mit dem Stecker der LWL-Strecke auf das Modul/den Switch konnektieren würde, statt die passive Strecke zunächst auf einem Patchfeld mit Durchführungskupplungen abzuschließen. Aber das machen nur Amateure. Gruß sk

Das hängt von der Länge des Kabels, der Faserqualität, dem Zustand der Fasern und der Steckeroberflächen sowie von den verwendeten Transceivern ab. Mit 10GBASE-LRM-Modulen kannst Du da sogar 10 Gigabit/s über Entfernungen bis zu 220m fahren! Wenn keine Dokumentation mehr vorhanden ist, lässt sich die Kabellänge anhand der lfd.Meter-Aufdrucke auf dem Kabelmantel ermitteln. Am besten wäre es, die Kabel neu durchmessen zu lassen. Die können wahrscheinlich bleiben - zumindest wenn Dir 1GB/s pro Link genügt. Genaueres weiss man, wenn die Steckeroberflächen per Videomikroskop inspiziert und eine Messung durchgeführt wurde. Auf jeden Fall sollten die Steckeneroberflächen gereinigt werden. Außerdem solltest Du darauf achten, 62,5µm-Patchkabel und geeignete Transceiver zu verwenden. Wenn Du allerdings auf 10GBit/s gehen möchtest, solltest Du neue Pigtails mit HRL-Steckern anspleissen lassen. Gruß sk

Hallo, Über wieviele Accesspoints sprechen wir? Welche Fläche bzw. örtliche Gegebenheit soll abgedeckt werden? Wieviele Clients sind parallel eingeloggt? Sind das "managed Clients" oder BYOD? Was ist damit gemeint? Einfach der selbe PSK auf allen Accesspoints oder geht es um Single SingOn (Anmeldung am WLAN mit den Anmeldeinformationen der Domäne? Du benötigst (falls überhaupt) keinen Radius-Server eines Drittanbieters. Beim Server 2008 ist der sog. NPS-Dienst dabei. Gruß Steffen

falsch

Mikrotik! http://wiki.mikrotik.com/wiki/Port_Knocking http://mum.mikrotik.com/presentations/US10/discher.pdf Gruß sk