DocData

Anhänge grundsätzlich verbieten. Datenaustausch über sichere, dafür speziell entwickelte Portallösungen. HTML/ RTF Mails am Perimeter in TXT umwandeln.

Ja, korrekt. Im SBS 2008 ist Exchange 2007 enthalten. Du musst also auf 2013 und dann auf 2016 gehen.

Äh. Nein. Nein. Es ist die Config. Das VPN der Fritz!Boxen arbeitet AFAIK nur mit einem Pre-Shared Key.

Bahnhof? Wie kommst du nun auf CA.crt?!

Wende dich an die Hilfsorganisationen, Diakonie, Caritas etc. Die freuen sich über brauchbare (!) Sachen. Müll kannst du sicherlich auch woanders entsorgen.

Die Fritz!Boxen können für die VPN Verbindung genutzt werden. AVM hat dazu sogar Anleitungen.

Was nicht an mir liegt... Soweit okay. Die TK Anlage braucht ein Interface in dem VLAN für das sie Relay spielen soll. Ob der Port tagged oder untagged sein muss, kann dir der Hersteller verraten. Wenn die TK Anlage die Frames nicht bearbeitet, also kein VLAN Tagging beherrscht, dann muss der Port untagged im Voice VLAN sein. Und da du das Ding ja auch administrieren willst, sollte sie wohl auch noch ein Interface in deinem Client-VLAN haben. Also auch dort untagged. Wenn deine TK Anlage nur EINEN Anschluss hat, hast du ein Problem. Du machst kein QoS über die VLANs... du lässt die Telefone DSCPs setzen und sagst den Switches was sie damit machen sollen (eben DSCP auf CoS mappen und das entsprechend berücksichtigen). Wenn die TK Anlage DHCP für beide Welten, also TK und Clients spielen soll, dann brauchst sie in beiden VLANs ein Interface. Und dann brauchst du eigentlich auch kein DHCP Relay. DHCP Relay brauchst du immer dann, wenn du DHCP Requests aus einem Subnetz an einen DHCP weiterleiten willst. Wenn dein DHCP aber multi-homed ist (das wäre deine TK Anlage ja, wenn sie DHCP spielt und in jedem VLAN ein Interface hat), dann brauchst du kein DHCP Relay.

Wo wir wieder beim Kontext wären. Wenn du kein VLAN und kein anderen DHCP Subnetz zur Verfügung stellen kannst, dann löst ein DHCP Relay dein Problem nicht. Eingangs hast du gesagt, dass du mit dem, was dir die IT gibt, leben musst. Also was denn nun?!

Rolle ein dediziertes Voice-VLAN aus. Konfiguriere dieses als tagged, das Client VLAN als untagged. Hänge den PC an das Telefon, das Telefon an den Switch. Konfiguriere ein DHCP Relay in deinem Netz. Teile deiner IT mit, dass du für VoIP ein anderes Subnetz brauchst und das die ihren DHCP entsprechend konfigurieren sollen.

Wie ich bereits mehrfach sagte: Du hast ein konzeptionelles Problem. Die ProVision kennen kein Hybrid und ein Port kann nur tagged ODER untagged sein. Aber nicht beides. In dem Dann dann doppelte Portanzahl. Ein Port für TK und einen für den PC.

Nein, reicht nicht aus. Der Port vom Telefon muss tagged sein. Quelle?

Ja, korrekt.

Mapping passt doch: 101110 46 7 ef

Das ist etwas für einen lauen Vormittag. Ein wenig PoSh und es ist getan. Du suchst New-MailboxExportRequest. Dann man sehr einfach skripten.

Kannst du mal qos type-of-service diff-services aktivieren und dann die Ausgabe von show qos dscp-map posten?

Wollt ihr nicht jemanden dazuholen der sich damit auskennt?

Ich wollte erst einen lmgtfy Link posten, aber so ist's einfacher: http://blogs.technet.com/b/uktechnet/archive/2013/05/14/what-s-the-difference-between-oem-retail-and-volume-licenses.aspx

Genau. Nein. Die Telefone sollen ihre Frames selber mit einem DSCP versehen. An den Switches musst du üblicherweise nichts mehr machen. Die ProCurven haben standardmäßig ein Mapping von DSCP zu COS. In dem ist hinterlegt das z.B. DSCP 101110 auf COS 7 gemappt wird. Siehe DSCP zu COS Mapping. Dann kauf jemanden ein der sich damit auskennt.

Geht nicht mit OneDrive. Bau dir VMs in Azure und löse dein Problem damit.

Brauchst du nicht. Lass die Telefone das machen. VLAN 1 als Voice VLAN markieren und den Telefonen sagen, dass sie das DS Feld selber mit einem DSCP füllen sollen. Dem Switch musst du nur noch sagen, dass er sich daran halten soll.

Was für Dateien hostet ihr auf dem DFS?

In deinem Fall bringt das nichts. DHCP und Priorisierung von VoIP Traffic haben NICHTS miteinander zu tun.

Hallo, SQL DB kannst du in der Tat per Azure einfach buchen. Virtuelle Maschinen kannst du in einem Virtual Network bereitstellen und dieses per IPsec an deine on-premises Umgebung anbinden (also vergiss nicht die Firewall und eine stabile Internetverbindung). Da kannst du dann z.B. einen DC bereitstellen. Oder aber auch Applikationsserver samt DB. Oder Fileservices anbinden. Geht alles. Aber vielleicht solltest du die Anforderungen weiter konkretisieren.

IP Helper ist was anderes als DHCP Relay. Und davon ab: Ich habe keinen 2530 hier, aber ich wage diese Aussage zu bezweifeln. Ein Forum ist keine offizielle Quelle. Dafür gibt es die QuickSpecs.

Der 2530 kann kein ip helper-address. Das ist ein reiner Layer 2 Switch. Siehe dazu auch die QuickSpecs zu dem Modell. Daher sind diese Befehle dort nicht verfügbar. Unabhängig davon löst es dein konzeptionelles Problem nicht. Du hast nicht mehrere VLANs und keinen Switch, der mittels DHCP Relay die DHCP Anfrage an den DHCP Server schicken kann. Der DHCP Server könnte aufgrund des Inhaltes im GIADDR Feld den geeigneten Scope identifizieren. Du hast nur eine Chance: DHCP Richtlinien. Sprich mit der IT deines Konzerns. Wozu? Lass die Telefone das doch machen und sag den Switches einfach, dass sie sich daran halten sollen. Dann musst du maximal am DSCP-to-CoS Mapping fummeln. Wobei bei dem 2530 ein qos type-of-service diff-services reichen sollte. Du solltest dein VLAN 1 als Voice VLAN markieren und auf Uplinks taggen. Sonst gehen dir die QoS Informationen verloren.