Confuse

Moin,

 

wenn Du 6 NICs je Server hast, reicht es doch:

2x iSCSI per MPIO

2x Host OS, Cluster und Live Migration als Team

2x VM als Team

 

Wenn Du iSCSI MPIO mit zwei Subnetzen verwendest, solltest Du auch 2 VLANs dafür auf den Switches einrichten. iSCSI wird serverseitig grundsätzlich ohne Link Aggregation betrieben - dafür gibt es Multipathing.

Es gibt zwar auch Setups, die LACP-Teaming und Subinterfaces oder vNICs für iSCSI ermöglichen. Für Deine Umgebung dürfte das jedoch nicht relevant sein.

 

Moin Dunkelmann,

 

Du hattest anfangs diese Kombination empfohlen. Ich denke dass diese Kombi aus Redundanzgründen sinnvoller ist, da ich ungerne von Anfang an SPoFs einbauen möchte.

 

Eigentlich ist es auch sehr einleuchtend, dass ich mit einer NIC im Server unmöglich Redundanz für 2 Switches schaffen kann.

 

Wie würde man dabei die VLAN Konfiguration vornehmen? Ein VLAN pro NIC-Team (Außer bei ISCSI hier soll es ja pro Subnetz ein VLAN sein, und es ist ja auch kein Teaming)?

 

Würde das auch bedeuten dass man Host OS, Cluster und Live Migration im gleichen IP Adressbereich hat?

 

Gruß Confuse..

Vielen Dank für die Info.

 

Ich werde mit das Konzept noch einmal überlegen, so gefällt mir das nicht.

 

 
 

Hallo zusammen,

 

Ich wollte heute anfangen meine VLANs zu konfigurieren und habe dabei festgestellt dass mir wieder viele Dinge nicht ganz klar werden.

 

Ich habe jetzt noch einen dritten Server der als Cluster Node eingesetzt werden soll.

 

Die NICs in den Servern sind alle konfiguriert, umbenannt und die Protokollbindungen konfiguriert:

NIC1 Management
NIC2 VM
NIC3 ISCSI1
NIC4 ISCSI2

NIC5 Cluster/CSV
NIC6 LiveMigration

 

Die beiden Netgear Switches sind jetzt als Stack konfiguriert.

Ich wollte jetzt die folgende Konfiguration vornehmen.

 

VLAN1 (ISCSI1) 4 Ports (QNAP NIC1 und jeweils ISCSI1 von den Nodes)

VLAN2 (ISCSI2) 4 Ports (QNAP NIC2 und jeweils ISCSI2 von den Nodes)
VLAN3 (Cluster/CSV) 3 Ports (1 für jeden Cluster Node)
VLAN4 (LiveMigration) 3 Ports (1 für jeden Cluster Node)
VLAN5 (Management) 5 Ports (1 für den DC auf dem auch der Failovercluster Manager laufen soll, 3 für die Nodes und 1 für Routing)

PVLAN (VM) Alle Restlichen Ports (Für die Anbindung von Clients an die virtuellen Maschinen)

 

Jetzt habe ich erst einmal folgende Frage: Ist es Notwendig den DC (Also den Failoverclustermanager) mit an die LiveMiagration und Cluster/CSV VLANs anzubinden, oder läuft die Kommunikation dieser Netze nur zwischen den Nodes und nur die Konfiguration erfolgt über das Management Netz?

 

Die zweite Frage: Bei ungleicher Anzahl an Nodes und 2 Switches, kann ich die VLANs zwar über die 2 Switches verteilen, habe dann aber immer einen Switch auf dem nur ein Node gesteckt ist. Was ist wenn der Switch ausfällt, an dem 2 der Nodes hängen?

ISCSI ist per MPIO angebunden, heißt ich hätte immer noch von allen Nodes Kontakt zum SAN, aber was ist mit der Kommunikation der Cluster Nodes untereinander? Bei Ausfall des Switches auf dem 2 NICs der Cluster Nodes stecken, wäre die Kommunikation zwischen den Clustern ja komplett getrennt? Kann man das irgendwie intelligenter lösen?

 

Was würde das Resultat davon sein? Ein Failover der Maschinen kann ja so nicht mehr stattfinden, würden also nur die Maschinen noch erreichbar sein die auf dem Knoten hängen der am noch funktionierenden Switch hängt?

 

ich hoffe ich habe das einigermaßen verständlich beschrieben.

 

Gruß Confuse..

Moin, Moin,

 

OK! Dann werde ich wohl mehrere LUNs erstellen. Was ich aber immer noch nicht recht verstanden habe, ist wie bei MPIO 2 Targets verwendet werden. Binde ich in jeden Knoten beide Targets ein? Normalerweise habe ich ja pro Target eine beliebige Anzahl von LUNs, oder ist es auch möglich dass die selben LUNs von mehreren Targets bereitgestellt werden?

 

Was würde passieren wenn ein Switch ausfällt? Dann ist die Verbindung zu einem Target ja definitiv getrennt, d.h. von der Logik könnte ich doch die LUNs unterhalb des Targets nicht mehr erreichen. Hoffe die Frage ist nicht zu doof, aber ich kann mir das nicht recht vorstellen...

Ok! Vielen Dank für die Infos:

 

Inzwischen sind beide Nodes mit Hyper-V 2012R2 installiert, beide Quadport-Nics verbaut, alle Treiber installiert und alle Updates installiert.

 

Die Netzwerkkarten sind umbenannt, wie im Hyper-V und Systemcenter Buch beschrieben und alle Protokolle für die Netzwerkadapter wurden konfiguriert. Ich habe jetzt die Protokolle "Microsoft Client" und "Datei- und Druckerfreigabe" für die NICs LiveMigration, CSV und Cluster aktiviert, damit später eine Redundanz für die LiveMigration möglich ist. Das NIC-Teaming lasse ich vorerst weg, da ich denke dass es mit QoS Geschichten am Anfang zu komplex für mich wird.

 

Meine weitere Vorgehensweise ist jetzt:
1. Konfiguration der VLANs auf den Switches (Für jedes Netzwerk ein eigenes VLAN)
2. MPIO Feature auf den Hyper-V Hosts aktivieren
3. NICs auf dem QNAP konfigurieren (Jeder NIC eine Adresse aus einem eigenen IP Adressbereich)
4. RAID konfigurieren (6 Platten S-ATA und 2 SSD)
5. ISCSI Target und LUNs konfigurieren
6. ISCSI Targets mit den Initiatoren verbinden und MPIO konfigurieren

 

Jetzt habe ich wieder Fragezeichen im Kopf :confused:

Zu 1. Die VLAN Konfiguration sollte nicht das Problem sein.

 

Beim Einrichten von MPIO komme ich allerdings ins Schleudern. Im diesem Artikel http://www.hyper-v-server.de/management/aufbau-und-einrichtung-eines-failovercluster-unter-windows-server-2012/ sind ja 2 ISCSI Targets auf dem SAN eingerichtet, ist dies für MPIO zwingend notwendig? Wenn ja, müssen die Targets dann identische LUNs enthalten?

 

Wozu ich auch keine wirklich eindeutige Aussage im Netz finde ist wie viele LUNs im Target angelegt werden sollten. Eine für das Quorum ist klar, aber wie viele LUNs sind für CSV empfohlen? Je nach Anforderung? Also zum Beispiel: CSV\Volume1 (LUN1) für System Partition und Daten die hohe I/O Anforderungen  haben, und CSV\Volume2 (LUN2 bzw. 3 rechnet man das Quorum mit) für Daten die keine hohen I/O Anforderungen haben?

 

Quelle: http://www.mcseboard.de/topic/190933-was-geh%C3%B6rt-ins-cluster-shared-volume-wo-liegen-die-nutzdaten/

 

Was für ein Dschungel...

 

Gruß Confuse...

 

Kleiner Nachtrag:

 

Number an Size of LUNs and Volumes

 

When you plan the storage configuration for a failover cluster that uses CSV, consider the following recommendations:

• To decide how many LUNs to configure, consult your storage vendor. For example, your storage vendor may recommend that you configure each LUN with one partition and place one CSV volume on it.
   
• There are no limitations for the number of virtual machines that can be supported on a single CSV volume. However, you should consider the number of virtual machines that you plan to have in the cluster and the workload (I/O operations per second) for each virtual machine. Consider the following examples:
  • One organization is deploying virtual machines that will support a virtual desktop infrastructure (VDI), which is a relatively light workload. The cluster uses high-performance storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively large number of virtual machines per CSV volume.
     
  • Another organization is deploying a large number of virtual machines that will support a heavily used database application, which is a heavier workload. The cluster uses lower-performing storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively small number of virtual machines per CSV volume.
     
• When you plan the storage configuration for a particular virtual machine, consider the disk requirements of the service, application, or role that the virtual machine will support. Understanding these requirements helps you avoid disk contention that can result in poor performance. The storage configuration for the virtual machine should closely resemble the storage configuration that you would use for a physical server that is running the same service, application, or role. For more information, see Arrangement of LUNs, volumes, and VHD files earlier in this topic.
  
  You can also mitigate disk contention by having storage with a large number of independent physical hard disks. Choose your storage hardware accordingly, and consult with your vendor to optimize the performance of your storage.
   
• Depending on your cluster workloads and their need for I/O operations, you can consider configuring only a percentage of the virtual machines to access each LUN, while other virtual machines do not have connectivity and are instead dedicated to compute operations.

Dem entnehme ich dass Microsoft auf die Empfehlung des jeweiligen Storage Herstellers verweist, aber ein CSV (Also ein LUN) theoretisch keine Größenbeschränkung hat??

 

 

Hallo zusammen,

 

Ich bin gerade dabei meine Netzwerkkonfiguration zu dokumentieren und treffe dabei auf ein paar Ungereimtheiten:

 

1. Welche Protokolle ich an die NICs binde wird im Hyper-V und Systemcenter Buch gut beschrieben, bei einem Punkt bin ich mir allerdings nicht sicher: Für die Netzwerke CSV, Heartbeat und Live Migration wird angegeben dass diese eigentlich keine Protokolle außer die beiden IP Versionen benötigen. Allerdings steht dort dass die Netze in der Praxis meist eine gegenseiteige Redundanz bilden und dann die Protokolle "Micrsosoft Client" und "Datei- und Druckerfreigabe" auf allen Adaptern aktiviert sein sollte.

Im Beitrag von Carsten Rachfahl http://www.hyper-v-server.de/management/hyper-v-cluster-und-netzwerkkarten-bindungen/ habe ich allerdings eine Tabelle gefunden in der diese Protokolle nur bei Live Migration aktiviert sind. Wenn ich das Ganze richtig verstanden habe geht bei der Rudundanz um die Funktion der Live Migration.

 

2. Außerdem habe diesen Artikel http://www.hyper-v-server.de/management/netzwerkkonfiguration-im-hyper-v-cluster/ gelesen und verstehe nicht warum im Failoverclustermanager unter "Netzwerke" das VM Netzwerk nicht vorhanden ist. Kann mich da evtl. jemand aufklären?

 

Gruß Confuse

@ Dukel: Es ist zwar im ersten Schritt eine Testumgebung, diese dient aber dazu, Erfahrungen zu sammeln um später auch produktive VMs darauf zu betreiben.

 

Meinst du mit der Redundanz der anderen Netzwerke, alle anderen NICs  als Team zu konfigurieren?

 

Wie gesagt habe ich noch keinerlei Erfahrungen mit dem Aufbau und orientiere mich am Hyper-V und System Center Buch, dort steht beschrieben dass man möglichst pro Netzwerk eine eigene NIC bzw. für das VM Netzwerk ein Team einsetzen sollte. Gerade die NIC für das Management OS wird angepriesen.

 

Habe ich keine Nachteile wenn ich zum Beispiel alle Cluster relevanten Netze (CSV, Heartbeat und Live Migration bzw. sogar noch das Management Netz) auf einen Adapter bzw. ein Adapter-Team konfiguriere?

 

Wie verhält sich das mit den virtuellen Switches bei dieser Konfiguration?

 

Gruß Confuse..

Guten Abend zusammen,

 

Ich habe jetzt für mein Projekt noch 2 Switches (Netgear GS724TS) zur Verfügung, was sich wohl positiv auf die VLAN Konfiguration auswirken dürfte, da diese im Gegensatz zu den Vorgängern stackable sind.

 

Zur Netzwerkkonfiguration habe ich mir jetzt folgendes überlegt:

 

2 NICs pro Node für ISCSI (Unterschiedliche IP Adressbereiche) für die Multipfad Anbindung an das QNAP über 2 VLANs

 

1 NIC für das Management OS

 

1 NIC für das VM Netzwerk

1 NIC für CSV und Heartbeat 

1 NIC für Live Migration

 

Ich hätte jetzt noch ein paar Fragen zu den virtuellen Switches auf den Servern. Nach meinem Verständnis benötige ich doch nur einen virtuellen Switch der an die NIC des VM Netzwerks gekoppelt wird (Gemeinsames Verwenden mit dem Hostsystem ist nicht gesetzt, mein Hostsystem soll ja keine Verbindung zu den VMs haben sondern eine IP Adresse aus dem Bereich der Domäne die die Cluster verwaltet), um den Uplink über die physikalische Netzwerkkarte in LAN herzustellen, oder muss ich noch weitere virtuelle Switches für die NICs erstellen?

 

Gruß Confuse

 

Vielen Dank für die Infos!

 

Ich poste morgen mal was ich Netzwerkkonfigurationstechnisch vorhabe. Vielleicht könnt Ihr dann ja kurz eure Meinung dazu äußern.

 

Ich wollte mich so nah wie möglich an den Microsoft Best Practize Empfehlungen orientieren bzw. am Buch Hyper-V und System Center, da ich halt noch nicht sehr viel Erfahrung in dem Bereich habe. Deswegen wundert mich die Empfehlung das Management OS Cluster/CSV und Live Migration an ein Team zu koppeln, aber wie gesagt bin ich noch nicht sehr erfahren mit der Cluster Geschichte und freue mich immer wenn ich etwas dazulernen kann.

 

Morgen mehr...

 

Schönen Abend noch! 

Hallo Necron,

 

Vielen Dank! Das ist die Information die ich gebraucht habe. Jetzt kann ich meine Planung anpassen, eigentlich hätte ich gerne 2 NICs für mein VM Netzwerk gehabt und diese Adapter dann im Team betrieben, aber da es sich zuerst um eine Testumgebung handelt, und ich leider von der Hardware auf 6 NICs pro Server angewiesen bin, muss vorerst eine NIC für das VM Netzwerk reichen. Ich meine gelesen zu haben dass eine 1:5 Regel gilt, das heißt ich kann ja 5 vNics per vSwitch an einen physikalischen Adapter koppeln, mehr VMs sollten es auch nicht werden.

 

Eine kleine Frage hätte ich aber noch :) : Wie sieht es mit der VLAN Konfiguration bei MPIO aus? Müssen die Switches Port Aggregation können um die beiden Karten als gemeinsame Verbindung (LAG) zu erkennen, oder muss für beide ISCSI Subnetze ein VLAN erstellt werden?

 

Gruß Confuse

Kurze Rückmeldung:

 

Ich lese immer wieder das Link Aggregation (LACP, 802.3ad bzw. LACP 802.1ax-2008), als dynamisches Teaming, also eigentlich nur im Zusammenhang mit NIC-Teaming eingesetzt wird. Außerdem wird im Hyper-V und Systemcenter Buch beschrieben, dass für die ISCSI Anbindung kein Teaming unterstützt wird bzw. diese mit MPIO stattfinden soll.

 

Richtet man für MPIO also grundsätzlich keine LAGs ein? Leider ist die Konfiguration von VLANs auf physischen Switchen nur sehr rudimentär beschrieben. Wahrscheinlich bin ich einfach noch zu grün hinter den Ohren um das zu verstehen :confused:

Hallo Necron,

 

vielen Dank für die schnelle Rückmeldung. Leider kenne ich den Artikel bereits und werde trotzdem nicht ganz schlau daraus.

Bei 2 Netzwerkkarten pro Clusterknoten arbeitet man ja laut dem Artikel mit 2 Subnetzen für ISCSI 1 und ISCSI 2 (192.168.212.0 und 192.168.213.0), was ja zur Folge hätte das ich dem QNAP auf seinen NICs auch ebenfalls eine Adresse aus jedem IP Adressbereich geben müsste. Allerdings ist auf dem QNAP "Port Trunking" aktiv bzw. steht es so in der Anleitung des Herstellers für die Nutzung von MPIO und in diesem Fall stellen ja beide NICs zusammen eine IP Adresse dar.

 

Eigentlich kann ich die Frage auch vereinfachen: Ist es möglich MPIO zu nutzen wenn ich pro Server nur eine Karte zur Verbindungsherstellung des SANs habe? Also quasi die Multipfad Verbindung auf 2 Server aufteile?

 

Gruß Confuse 

Guten Tag zusammen,

 

Ich lese gerade das Buch Hyper-V und System Center um mich in die Thematik des Clusteraufbaus unter Server 2012 zu fuchsen. Hintergrund ist, dass ich eine Testumgebung aufbauen möchte, für die ich die folgende Hardware zur Verfügung habe:
 

1 Domain Controller für die Clusternodes mit Server 2012R2
2 Cluster Nodes beide mit Server 2012R2
2 Netgear Switches GS724TP (Nicht stackable)
1 QNAP TS-879U-RP das als ISCSI Ziel genutzt werden soll
 

Die Clusternodes haben jeweils 6 NICs bzw. Ports (2 onboard und jeweils eine Intel Quadport I340-T4) und das QNAP hat 2 NICs.

 

Die Clusterknoten sollen jeweils einen NIC Port für ISCSI bekommen, und dann auf beide Switches verteilt werden.

 

Nun zu meiner Frage: Da im Buch öfter die Rede von der redundanten Anbindung der Knoten an das ISCSI Ziel ist, und dies halt nicht per Teaming sondern per MPIO vorgenommen werden soll, frage ich mich ob dies in meinem Szenario überhaupt greift. Ich habe ja pro Knoten nur einen NIC Port für ISCSI, ist MPIO in diesem Fall notwendig? Wenn ja muss das Feature auf meinen Clusterknoten und im ISCSI Ziel aktiv sein?

 

Gruß Confuse

 

http://files.qnap.com/news/pressresource/product/How_to_connect_to_iSCSI_targets_on_QNAP_NAS_using_MPIO_on_Windows_2008.pdf

 

Diese Anleitung von QNAP beschreibt das Szenario mit einem Server der 2 NICs hat, aber wie läuft es mit der Cluster Konfiguration? Lege ich die 2 benötigten IP Adressen einfach auf die NICs der beiden Knoten, oder wäre das eine Fehlkonfiguration?

Hallo zusammen,

 

ich konnte mein Problem lösen, in dem ich den SVR03 neu installiert und die RRAS Rolle erneut eingerichtet habe. Die Übung mit dem Relay Agent hat perfekt funktioniert. Zudem habe ich noch NAT auf dem Router über die Schnittstelle WLAN Extern konfiguriert damit die Server auch ins Internet kommen. Die IP Vergabe über den Relay Agent funktioniert auch mit aktiviertem NAT noch.

 

Endlich... jetzt geht's mit ISATAP Konfiguration weiter.

 

Schönen Abend noch!

Hallo zusammen,

 

Ich bin gerade an der MSCA Prüfung 20410B, und wollte ursprünglich versuchen einen DHCP Relay Agent zu konfigurieren, wie im Trainingsvideo gezeigt. Dazu wollte ich in meiner Hyper-V Testumgebung auf einem Server2012 Standard die Rolle Routing und RAS (Remotezugriff) installieren und diesen als Router zwischen 2 Subnetzen einrichten.

 

Nun zu meinem Problem, im Trainingsvideo sieht man nicht was für ein Routing Protokoll eingerichtet ist, da die Konfiguration der VM als Router nicht weiter beschrieben wird. Nach meinem Verständnis von Routing müsste ich eigentlich nur LAN Routing aktivieren, damit müsste ich erreichen dass meine VMs und der Host sich untereinander verständigen können, da durch den RRAS Dienst ja alle Routen auf dem Host gesetzt werden. Leider klappt das nicht so richtig, ich kann zwar von meinen VMs die Gateways pingen (NIC IP Adresse die auf der VM auf der der RRAS Dienst läuft eingetragen ist), aber keine anderen Hosts innerhalb der Subnetzte. Die Routing Tabelle sieht für mein Verständnis richtig aus. Ich habe schon einige Tests gemacht, unter anderem NAT aktiviert, dann hat die Kommunikation zwischen den Subnetzten funktioniert aber der DHCP Relay Agent hat keine Adressen in die anderen Subnetze verteilt.

 

Zu meiner Konfiguration:

 

Fritz.Box Fon 7320

 

IP:   172.16.1.1
SM: 255.255.255.0
DHCP ist deaktiviert (IPv4)

 

Hyper-V Host: Windows 8 Client mit installiertem Hyper-V Feature

 

IP Konfiguration des vEthernet Adapters (Extern WLAN)

IP:     172.16.1.254

SM:   255.255.255.0 (/24)
DG:   172.16.1.1
DNS: 172.16.1.1

3 Virtuelle Netzwerke/Switches

1. Externes Netzwerk (Extern WLAN) gekoppelt an meinen WLAN Adapter Intel Centrino Advanced N6205. Der Haken für gemeinsame Verwendung ist gesetzt.

2. Internes Netzwerk (Intern 192.168.1.0/24) Ohne VLAN ID

3. Internes Netzwerk (Intern 10.10.10.0/24)   Ohne VLAN ID

 

3 VMs (2 sind komplett ohne Rollen und alle VMs sind mit festen IPs konfiguriert)

 

1. SVR01 (Server 2012 Standard)

Virtueller Switch: Intern 192.168.1.0/24

IP:     192.168.1.20
SM:   255.255.255.0 (/24)
GW:  192.168.1.254 (IP Adresse des Interface auf SVR03)
DNS: Noch keiner

 

2. SVR02 (Server 2012 Standard)

Virtueller Switch: Intern 10.10.10.0/24

IP:     10.10.10.20
SM:   255.255.255.0 (/24)
GW:  10.10.10.254 (IP Adresse des Interface auf SVR03)
DNS: Noch keiner

 

3. SVR03 (Server 2012 Standard mit der Rolle Remotezugriff)

Virtuelle Switches:
1. Extern WLAN

IP:     172.16.1.253
SM:   255.255.255.0 (/24)
GW:  Keins
DNS: Keiner

 

2. Virtueller Switch: Intern 192.168.1.0/24

IP:     192.168.1.254
SM:   255.255.255.0 (/24)
GW:  Keins
DNS: Keiner

 

3. Virtueller Switch: Intern 10.10.10.0/24

IP:     10.10.10.20
SM:   255.255.255.0 (/24)
GW:  10.10.10.254 (IP Adresse des Interface auf SVR03)
DNS: Noch keiner

 

Wie gesagt ist auf SVR03 die RRAS (Remotezugriff) Rolle installiert, und die Konfiguration "Nur LAN Routing" aktiv. Die Routing Tabelle sieht nach meinem Verständnis richtig aus (Siehe Anhang 1), und route print liefert das selbe Ergebnis (Siehe Anhang 2). In einigen Tutorials habe ich gelesen dass ein Server der Routing macht vom Design her keine GWs haben sollte, da die Netze ja "Direkt verbunden" sind, es sei denn der Router benötigt Internet Konnektivität (In diesem Fall würde ich dem V-Switch Extern halt ein Gateway angeben). 

 

Ich hoffe mir kann jemand eine kleine Hilfestellung geben wie ich ein solches Szenario nachstellen kann. Im Grunde möchte ich nur das Routing zwischen 2 Subnetzen simulieren um die DHCP Relay Agent Funktion zu testen, hänge jetzt aber schon fast 2 Tage an der Netzwerkkonfiguration meiner Hyper-V Umgebung :confused:  .

 

BTW: Die Firewall Regeln für ICMP Requests (Datei- Und Druckerfreigabe (Echoanforderung - ICMPv4 eingehend)) sind auf allen Servern aktiv, sollten also alle Server auf Ping reagieren.

 

Falls weitere Informationen benötigt werden, reiche ich diese gerne nach.

 

Gruß vom Confuse

 

 

 

 

 

 

 

 

 

 

Moin, ehrlich gesagt, sieht die Fehlermeldung eher nach einem Liux-System, als nach Exchange aus. Kann es sein, das die Mail an ein anderes System geht? Ansonsten ist nicht wirklich so ganz klar, wer hier an welche Adresse schicken will.

 

Da hast Du Rech es ist eine Linux Spam Wall mit Spam Assasin, Amavis und Postfix Diensten vorgeschaltet von der IP-Adresse dieses Systems kommt offensichlich auch die Meldung. Dann wird wohl im Postfix ein anderer Alias für diese Mailadresse hinterlegt sein...

 

Leider habe ich von Linux sehr wenig Ahnung, so dass ich mich am Montag wohl vertrauensvoll an unseren Linux Admin wenden muss!

 

Trotzdem vielen Dank für die Rückmeldung!  

Guten Abend liebe Community,

 

Ich habe das Problem dass eine Mailboxweiterleitung nicht funktioniert, und ich in der Unzustellbarkeitsbenachrichtigung die Mailadresse einer Verteilergruppe die ähnlich heißt wie das Benutzerpostfach an das ich weiterleiten möchte genannt wird (receipient Adress rejected: user unknown in local recepient adress table).

 

Allerdings ist die Adresse an die ich weiterleite nicht als Alias in der Verteilergruppe eingetragen.

 

Kann mir jemand sagen wie ich in Exchange die Liste der Empfanger aktualisiere? Ich habe bereits das Globale Adressbuch mit dem Befehl: Update-GlobalAddressList -Identity "Default Global Address List" aktualisiert, leider ohne Erfolg.

 

Hilfe!

System ist Server2008R2 mit Exchange 2010, das Ganze ist von 2003 migriert worden.