peterg

Ja, da in dem alten Exchange Zertifikat der CN nicht auch als SAN eingetragen war. Ich habe dann ein neues Zertifikat bekommen, wo dann alle Einträge richtig waren. Ich habe gerade mal im Zertifikatsspeicher nachgeschaut und den Fingerabduck der Zertifikate mit dem Hash-Wert des [::]:443 Zertifikats verglichen. Dieses Zertifikat gibt es im Zertifikatsspeicher nicht. Ich werde es jetzt mittles netsh http delete xxx löschen. Oder? Wie lautet dann eigentlich das Kommando? netsh http delete sslcert ipport=[::]:443 Passt das so mit den [::]? So wird es bei den Bindungen mit netsh http show sslcert angegeben. Normalerweise schaut es ja so aus: netsh http delete sslcert ipport=0.0.0.0:443

Hallo, ich weiß nicht ob ich auf dem richtigen Weg bin. Ich habe mir mal die Hash-Werte und die Anwendungs-IDs der SSL-Zertifikatsbindungen angeschaut (netsh http show sslcert). Zudem hatte ich die Möglichkeit über einen Bekannten bei einem anderen Exchange 2016 die SSL-Zertifikatsbindungen anzuschauen (siehe Anlage). Fazit: 0.0.0.0:443 und 127.0.0.1:443 haben den gleichen Hash und die gleiche Anwendungs-ID --> ist bei beiden Exchange-Servern so 0.0.0.0:444 hat einen anderen Hash, aber die gleiche Anwendungs-ID wie 0.0.0.0:443 und 127.0.0.1:443 --> ist bei beiden Exchange-Servern so Das Problemkind [::]:443 stimmt weder mit Hash, noch mit Anwendungs-ID mit irgendeinen anderen Zertifikat zusammen Zudem gibt es dieses Zertifikat nur bei dem Exchange mit der Fehlermeldeung. Das Zertifikat wurde auf diesem Server gelöscht (andere Geschichte) und ein neues Zertifikat installiert. Evtl. ist das irgendein Überbleibsel und wird evtl. gar nicht benötigt und kann gelöscht werden. Das hat mit dem CU4 Update wohl gar nichts zu tun und die Fehlermeldung ist mir erst jetzt aufgefallen. Der Zertifikatswechsel wurde auch erst vor kurzem gemacht. --> Kann dazu jemand was sagen? Gruß, Peter SSL-Zertifikatbindungen mit Fehlermeldung.txt SSL-Zertifikatbindungen Vergleichsserver.txt

Hi, habe ich mich noch nicht getraut. Was heißt mit "Key" exportieren? Ich habe das Zertiifkat über die EAC exportiert inkl. Passworteingabe oder muss ich das Zertifikat über die MMC exportieren? Hier habe ich keine Ahnung. Geht das so: https://www.digicert.com/ssl-support/pfx-import-export-iis-7.htm oder https://technet.microsoft.com/de-de/library/aa996305(v=exchg.160).aspx Kann ich dann einfach die 4 Schritte wie im Artikel beschrieben ausführen? Das habe ich noch nie gemacht, daher frage ich lieber ganz genau nach. Muss ich nicht bei "delete" die IP und den Port eingeben? -> delete sslcert ipport=127.0.0.1:443 -> delete sslcert ipport=[::]:443

Hi, ich habe mal bei "Default Web Site" die https-Bindungen auf "Microsoft Exchange" umgestellt, einen iis-Reset gemacht und dann wieder das Exterene Zertifikat eingetragen (und iis-reset). Brachte nichts :-( Die Fehlermeldung komme alle 10 Sek. Gibt's doch nicht....

Ja, da steht bei https Port 444 beim SSL-Zertifikat "Microsoft Exchange" und nicht das "externe Zertifikat" drin. Bei meinem Test-Exchange (gleich mit CU4 aufgesetzt) ist das aber auch so! Gehört hier das "externe Zertifikat" rein? Gruß, Pit

Hallo, ich habe auch nicht im iis gemacht. Da traue ich mich nicht ran. :-) Wenn man "googelt" wird beschrieben, dass oft das Zertifikat fehlt und im iis eingetragen werden muss. Bei mir war aber alles eingetragen. Das wollte ich nur prüfen. Bei get-exchangecetrificate kommt folgendes (siehe Bild) Kann/soll ich das Zertifikat gemäß der Technet-Seite reinstallieren? Welchen Kommentar meinst Du? Es geht ja auch teils um die Bindung beim "Exchange Back End", 444. Bei "netsh http show sslcert" steht nur bei einem Zertifikat "0.0.0.0:8172" die Anwendungs-ID mit 00000 drin. Bei den Zertifikaten mit Port 443 steht überall etwas bei der Anwendungs-ID. Gruß, Pit

Hi, Autodiscover.domainA.de und autodiscover.domainB.de sind "zufällig" im Zertifikat, da das "alte" Zertifikat kulanterweise umgetauscht wurde und ich quase noch zwei Einträge frei hatte. Das habe ich nur nicht erwähnt, da ich der Meinung war, dass die zwei Einträge nicht notwendig sind. Danke für den Hinweis. Gruß, Pit

Hallo, ich habe gerade das Exchange 2016 CU4 Update (von CU2) gemacht (auf einem Server2012R2), welches reibungsllos funktioniert hat. Nun habe ich im Ereignisprotokoll den Fehler 15021: Bei der Verwendung der SSL-Konfiguration für den Endpunkt (::'):443 ist ein Fehler aufgetreten. Die Fehlermeldung kommt ständig!!! OWA funktioniert, Outlook kann sich am Exchange anmelden und auch die Anmeldung an der EAC funktioniert. Im IIS unter "Default Web Site" -> Bindungen -> ist bei beiden https-Einträgen das "externe" Exchange Zertifikat eingetragen (siehe Bilder), welches ich bei der Exchange-Installation eingebunden habe. Kann das Zertifikat irgendwie "defekt" sein? Hat evtl. jemand einen Tipp? Gruß, Pit

Hallo, Problem gelöst. Evtl. interessiert es ja jemanden. 1. Zertifikat Sichergestellt, dass auf dem Zertifikat CN: outlook.abc-service.de und autodiscover.abc-service.de ist (CN wird automatisch als SAN eingetragen). autodiscover.domainA.de und autodiscover.domainB.de wird nicht benötigt 2. Interner DNS-Server Neue Forward-Lookupzone „autodiscover.abc-service.de” mit A-Record auf den internen Exchange Neue Forward-Lookupzone „outlook.abc-service.de” mit A-Record auf den internen Exchange In der gemeinsamen Domäne „xxx.local“ einen SRV Eintrag erstellen: Dienst: _autodiscover (auch so eintragen) Protokoll: _tcp (auch so eintragen) Priorität: 0 Gewichtung: 0 Port: 443 Host, der den Dienst anbietet: autodiscover.abc-service.de 3. Externe DNS-Server Service-Domain: outlook.abc-service.de und autodiscover.abc-service.de mit HOST A-Record auf die feste Internet-IP-Adresse Hierauf kommt es an: Domain-A: SRV-Eintrag erstellen -> _autodiscover._tcp.domainA.de -> Ziel: autodiscover.abc-service.de Host: beim Host darf nichts eigegeben werden Typ: SRV Zielt: autodiscover.abc-service.de Priorität: 0 Port: 443 Gewichtung: 0 Protokoll: TCP Dienst: autodiscover Domain-B: SRV-Eintrag erstellen, analog Domain-A Dann läuft der MS Connectivity Analyzer sauber durch. Danke für Eure Hilfe. Gruß, Pit

Der Router soll dem Client eine IP-Adresse aus dem gleichen Netz wie in der Domäne zuweisen. Am Router läuft dann quasi ein DHCP-Server nur für die VPN-Clients. Diesen IP-Bereich nehme ich aber am DHCP-Server der Domäne aus, bzw. evtl. gibt es ja einen Bereich der gar nicht zur Adressvergabe konfiguriert ist, da es ja sonst zu Adress-Konlikten kommen kann. Muss der IP-Bereich für die VPN-Clients am Router aber gar nicht im gleichen Bereich wie am Server sein? So verstehe ich die nachstehende Aussage. Unser Netz hat den IP-Bereich 192.168.110.xx, der Router hat die IP 192.168.110.254. Für die VPN-Clients wird am Router ein IP-Bereich 192.168.169.xx (hoffentlich exotisch :)) reserviert. Der VPN-Client verbindet sich also dann mit dem Router, bekomm eine IP-Adresse (komplett anders als das Netz mit dem Server) und der Router routet dann den Client in das Netz. Richtig? Wenn ich dann am VPN-Client z.B. der Server anpinge müßte das funktionieren oder? Welche Ports wäre das? Die Dame soll nur auf Ihre Netzlaufwekre Zugriff haben. Also reiner Datentransfer. Gruß, Pit

Hallo, alleine der Thementitel ist schon grausam aber hoffentlich verständlich. Eine Kollegin arbeitet nun teils in einer anderen Einrichtung (ist ganz woanders). Dort sitzt Sie an einem Rechner, welcher nicht Mitglied unserer Domäne ist, keine direkte Verbindung zum Domäenennetzwerk hat und in einer ganz normalen Arbeitsgruppe ist. Nun wäre es schön, wenn Sie trotzdem mit Ihren Zugangsdaten der Domäne Zugriff auf die Netzlaufwerke des Servers hätte. Die Verbidnung mit Outook zum Exchange habe ich schon hinbekommen. Das war aber eine andere Baustelle :-) Dies würde ich gerne über eine IPsec-Verbindung mit unserem bintec-Router machen. Auf dem Rechner wird dann eine IPsec Clientsoftware installiert, welche sich mit dem Router verbindet. Die Verbindung soll definitiv NICHT über den Server aufgebaut werden. Der Router hat entsprechende IPsec Lizenzen mit dabei. Dies ist aber nicht meine Frage. Ich würde gerne wissen, welche Konfigurationen/Einstellungen ich am Server 2012R2 (als VM) machen muss, damit der Benutzer des Rechners (ohne Domänenanbindung) mit seinen Benutzerdaten der Domäne, Zugriff auf die Netzlaufwerke bekommt. Ich denke hier an die Windows Firewall, Routing & RAS aktivieren?, bekommt der Client automatisch vom DHCP des Servers eine IP-Adresse?, muss ich beim Benutzer irgendwlche "Einwahlrechte" aktivieren? Wann erfolgt die Authentifizierung am Server, da die IPsec-Verbidnung wohl nichts mit den Benutzerkonten der Domäne zu tun hat? Bzw. ist das überhaupt so möglich? Schöne Grüße Pit Nachtrag DHCP: Eigentlich muss ich doch nur über den Router einen DHCP-Bereich aus dem Netzwerk festlegen, denn die IPsec-Clients dann bekommen. Diesen Bereich schließe ich am eigentlichen DHCP-Server aus, damit es keine Überscheidungen gibt. Somit solle man über \\servername\freigabe das Netzlaufwerk vom Rechner aufrufen können bzw. kommt dann erst die Authentifizierung (Benutzername, Passwort). Denke ich hier zu einfach?

Hallo, ist die Lösung wirklich so einfach? Nur noch einen SAN-Eintrag im Zertifikat ergänzen (also ein neues Zertifikat ausstellen lassen). Wie kann ich das eigetlich im aktullen Zertiifkat prüfen? Müßte der "Aussteller" nicht dann automatisch den CN auch als SAN setzen? Ich habe beim Zertifikat neben dem CN halt einfach auch die SANs beim Beatragen angegeben. Ich habe hier auch einen interessanten Artikel gefunden "Autodiscover with multiple domains and single name certificate". Damit habe ich etwas rumgespielt, wobei ich die internen DNS-Einträge schon so gemacht hatte (Split-DNS). Laut dem Artikel benötigt man nur einen Namen im Zertifikat. Ist das dann egal ob trotzdem noch SANs drin sind? Beim internen DNS (unsere Domäne heißt: domäne.local) gibt es nun unter den Forward-Lookupzonen eine zusätzliche primäre Zone "outlook.abc-service.de" mit einem Host-A Eintrag auf den Exchange Server. Zudem ist unter domäne.local/_tcp der SRV-Eintrag _autodiscover._tcp.outlook.abc-service.de mit dem Port 443 vorhanden. Irgendwie fehlen mir auch die Einträge für die eigentlichen Domains "domainA.de" und "domainB.de" am intenen DNS. Werden am internen DNS keine Einträge dafür benötigt? Z.B. eine interne Zone "domainA.de" mit dem SRV Eintrag? Beim externen DNS (Mail-Domain "outlook.abc-service.de") habe ich dann den SRV Eintrag _autodiscover._tcp.outlook.abc-service.de auf die feste IP hinzugefügt und den A-Record Eintrag "autodiscover.abc-servce.de" gelöscht. Somit gibt es dort nun den SRV-Eintrag und einen A-Record for "outlook.abc-service.de" auf die feste IP. Jetzt frage ich mich auch, was für Einträge (A-Record, CNAME, SRV) müssen bei den externen DNS-Servern der eigentlichen Domains "domainA.de" und "domainB.de" vorhanden sein um hier irgendwie auf "outlook.abc-service.de" weiterzuleiten? --> Funktioniert aber immer noch nicht :-( Alles in allem kenne ich mich da einfach nicht aus und probiere nur rum. Ich bin schon froh, dass so alles läuft. Ich bin nun soweit, dass wir einen Profi das Thema lösen lassen. Ich bin sonst noch weiter gefrustet. Das kostet dann ein paar Euros, aber dann paßt auch alles. Ich kann hier noch Stunden damit verbringen und möchte auch nicht weiter eure Zeit verschwenden. Könnt Ihr mir jemanden empfehlen, der das remote machen kann? Gruß, Pit

Hallo, nein! Als SAN stenen nur die drei "autodiscover"-Adressen drin. SAN: autodiscover.abc-service.de autodiscover.domainA.de autodiscover.domainB.de CN: outlook.abc-service.de Gruß, Peter

Hallo, als CN habe ich damals die Service-Domain "outlook.abc-service.de" (ist der Antragsteller des Zertifikats) eingetragen (also nicht domainA.de oder domainB.de oder abc-service.de), da wir ja zwei unterschiedliche Mail-Domains auf den Exchange haben. Über die Service-Domain ist der Exchange erreichbar. Das mit der Service-Domain hat sich für mich schon plausibel angehört, wenn man zwei unterschiedliche Mail-Domains hat. Gruß, Pit

Hallo, ich habe nun den CNAME Eintrag gelöscht und autodiscover.domainA.de mit einem A-Record mit der festein IP-Adresse verbunden. Anbei der Analyzer-Test (Outlook Autodiscover-Test) als PDF. Da blicke ich nicht mehr durch. Scheinbar paßt was nicht mit den Zertifikat bei unserem Provider nicht. Ich bin langsam bereit einen Profi das Thema beheben zu lassen. Kannst Du jemanden empfehlen. Natürlich alles auf Rechnung. Es kann ja nicht alles so falsch sein, da ja viel funktioniert. Gruß, Pit Microsoft Connectivity Analyzer.pdf

Tja, fehlerfrei! Das ist wohl das Problem. Ich habe keine Ahnung was ich noch machen kann. Die Notlösung ist natürlich OWA. Das funktioniert ja einwandfrei. Aber mich wurmt es schon. Ich habe gerade mal die Methode mit dem XML-File ausprobiert (Method 2 - HowToOutlook). Damit funktioniert tatsächlich Outllok 2016, aber die öffentlichen Ordner/Kalender werden nicht gefunden (in OWA natürlich schon). E-Mail senden/empfangen, Kalendereinträge funktioniert (kann ich ja gleich mit OWA prüfen). Also auch nicht der Hit, aber interessant. :-( Mal sehen ob noch jemand einen heißen Tipp hat. Gruß, Peter

Hallo, Outlook 2016 verbindet sich nur über autodiscover. Aber auch wenn ich die Daten manuell eingebe kommt eine Fehlermeldung, dass der Server nicht gefunden wird. Ich habe es auch schon bei meinem Rechner mit Outlook 2013 vergeblich versucht. Gruß, Peter

Hallo Exchange-Experts, ich würde unseren Exchange 2016 gerne sauber konfigurieren, da scheinbar was mit dem Autodiscover nicht passt. Die Konfiguration ist bei uns auch evtl. etwas "ungewöhnlich". Wir sind zwei gemeinnützige Vereine mit unterschiedlichen E-Mail Domains, welche sich einen Server inkl. Exchange 2016 teilen. Vor der Exchange-Installation habe ich im Netz mal nach einer möglichen Umsetzung gesucht und mir wurde folgendes geraten, was ich auch so umgesetzt habe (siehe unten – bisherige Konfiguration). Was möchten wir: Wir haben jetzt noch eine Verwaltungskraft, welche teilweise bei einem Verein (mit einem Domänenrechner) und aber auch noch teilweise in einer "Außenstelle" arbeitet (mit einem Rechner ohne Domänenanbindung). Es wäre super, wenn die Verwaltungskraft in der Außenstelle Zugriff auf Ihre Mails hat. Ich möchte daher Outlook mit dem Exchange-Konto verbinden, wobei der Rechner nicht Mitglied der Domäne ist. Geht das überhaupt? Zudem haben wir Office 2016 bei der Außenstelle. Hier ist Autodiscover ja quasi Pflicht. Es kommt bei der Einrichtung von Outlook immer die Fehlermeldung, dass der Server nicht erkannt wird. Auch funktioniert der MS Remote Connectivity Analyzer hinsichtlich "Autodiscover" nicht. Vorab: Outlook Web Access funktioniert von jedem Rechner (auch auf Nicht-Domänenrechner) überall auf der Welt. Outlook am Rechner kann auch außerhalb des Netzwerks mit jeder Internetverbindung eingerichtet werden, wenn der Rechner vorher an die Domäne angebunden wurde. Bisherige Konfiguration: Ich habe eine sog. Service-Domain "abc-service.de" und als Sub-Domain "outlook.abc-service.de", sowie "autodiscover.abc-service.de" angelegt. Als interne und externe Adresse am Exchange habe ich "outlook.abc-service.de" eingetragen. Die Pfade funktionieren auch. Damit soll/ist der Server von "außen" erreichbar. Wir haben also "Verein1@domainA.de", "Verein2@domainB.de", "outlook.abc-service.de" "autodiscover.abc-service.de". Beim Nameserver von "abc-service.de" habe ich einen HOST A Eintrag für "autodiscover.abc-service.de" und outlook.abc-service.de auf die feste IP des Server eingetragen. Beim Nameserver von "Verein1@domainA.de" habe ich einen CNAME Eintrag von "autodiscover.domainA.de" zu "autodiscover.abc-service.de" angelegt. Beim Nameserver von "Verein2@domainB.de" habe ich einen CNAME Eintrag von "autodiscover.domainB.de" zu "autodiscover.abc-service.de" angelegt. Zudem ist am Exchange ein Multidomain-Zertifikat mit folgenden Einträgen installiert: outlook.abc-service.de autodiscover.abc-service.de autodiscover.domainA.de autodiscover.domainB.de Gebe ich im Browser https://outlook.abc-service.de/autodiscover/autodiscover.xml ein, so wird die Authentifizierung abgefragt. Nach Eingabe der Daten kommt die Fehlermeldung: <Autodiscover> <Response> <Error Time="12:26:05.7398351"Id="366275129"> <ErrorCode>600</ErrorCode> <Message>Ungültige Anforderung</Message> <DebugData/> </Error> </Response> </Autodiscover> Wo liegt der Fehler? Ich komme nicht drauf. Sind die "Weiterleitungen" an die Service Domain bei Autodiscover nicht möglich? Es wäre super, wenn mir hier jemand einen Tipp geben könnte. Gruß, Pit

Hallo, ich habe zwei VLANs (VLAN210 und VLAN220) mit einem bintec RS353J Router und einem HP 1920 PoE Switch eingerichtet. Auf dem Router läuft je VLAN ein DHCP-Server mit unterschiedlichen IP-Bereichen (VLAN 210: 192.168.210.xxx, VLAN220: 192.168.220.xxx). Beide VLANS haben ein eigenes Gateway über den Router für das Internet (VLAN 210: 192.168.210.254, VLAN 220: 192.168.22.254). Der Router selbst hat die IP 192.168.200.254 (VLAN 1, default). Am Switch gibt es den Port 1 als Management-Port im VLAN 1 (default). Alle andern Ports sind entsprechend der VLANs zugeordnet. Es besteht nur eine Verbindung zwischen Router (Schnittstelle en1-1) und Swicht (Port 24 - tagged in allen VLAns) Soweit funktioniert alles wunderbar. Nun hängen am VLAN 220 ein paar AccessPoints. Auf diese würde ich gerne aus Verwaltungsgründen (Updates, etc.) aus dem VLAN 210 zugreifen können. Von VLAN 220 soll aber weiterhin kein Zugriff in das VLAN 210 möglich sein. Hintergrund: Wir haben ein kleines Büronetz (VLAN 210) und ein Netz für unsere Bewohner (Betreutes Wohnen Jugendlicher, VLAN 220). Daher die VLANs, damit hier kein "Blödsinn" passiert. Den generellen Zugriff zwischen den Netzen habe ich aktuell über die Firewall des Routers konfiguriert. Das funktioniert auch. Ich gehe nun mal davon aus, dass ich das irgendwie über das Routing am bintec-Router konfigurieren kann. So was habe ich aber noch nie gemacht. Auf was muss ich hier achten bzw. wie müssen die Routing Einträge ausschauen? Anbei ein Screenshot der aktuellen Routing-Tabelle (wird automatisch erzeugt). Die Internetverbindung wurde noch nicht eingerichtet. Daher fehlt der Eintrag hier noch (wir aber auch automatisch erstellt). Schöne Grüße Pit

Hat keiner einen Tipp? Gruß, Pit

Hallo, wir haben auf einer virtuellen Maschine MS Server 2012R2 Std. laufen. Ich habe dort die Rolle "Direct Access und VPN" installiert und konfiguriert (nur VPN bereitstellen -> Benutzerdefinierte Konfig -> VPN-Zugriff -> Firewall PPTP freigeschaltet). Dann eine Benutzergruppe "VPN-User" angelegt und eine Netzwerkrichtlinie mit "Zugriff gewähren" für diese Gruppe angelegt. Sonst habe ich alles so gelassen wie vom System vorgeschlagen (z.B. MS-ChAP-v2 und MS-CHAP zur Authentifizierung). In einer VM habe ich bei mir zu Hause Win 7 Prof. und Win 10 Prof. (alle Clients sind in der Domäne). Mit Win7 funktioniert der VPN-Zugriff ohne Probleme mit Win 10 leider nicht. Es kommt die Meldung: Die Remoteverbindung wurde verweigert, weil die angegebene Kombination aus Benutzername und Kennwort nicht erkannt wird oder das ausgewählte Authentifizierungsprotokoll nicht für den RAS-Server zulässig ist. -> Benutzername und Passwort stimmen aber. Auch habe ich schon die Verbindung gelöscht und neu angelegt. Unter Win 7 läuft mit dem gleichen User alles einwandfrei Der VPN-Typ ist auf "Automatisch" gestellt (wie bei Win 7), habe aber auch schon "nur PPTP" probiert. Den Benutzernamen habe ich schon mit und ohne Domäne davor probiert (Domäne\Benutzername). Eingerichtet habe ich die VPN-Verbindung analog wie bei Win7. Netzwerk- u. Freigabecenter -> Verbindung mit dem Arbeitsplatz herstellen -> Die Internetverbindung VPN verwenden -> Internetadresse eingegeben. Ich habe auch schon die Firewall bei Win10 deaktiviert. Leider ohne Erfolgt. Ich bin ratlos. Auch bei einem anderen Win10 Client (nicht in einer VM) funktioniert die VPN-Verbindung nicht. Im Ereignisprotokoll kommen folgende Meldungen: ID 20221 – Verbindung wird gewählt ID 20222 – Es wird versucht eine Verbindung herzustellen ID 20223 – Der Benutzer hat eine Verbindung mit dem RAS-Server hergestellt (die IP passt) ID 20224 – Die Verbindung mit der RAS-Server wurde vom Benutzer hergestellt dann kommt wieder ID 20222, 20223, 20224 dann kommt der Fehler ID 20227 – Der Benutzer hat eine Verbindung VPN … gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Ursachencode 691. Was mache ich falsch? Laut Google soll der Code 961 was mit dem Benutzernamen und Passwort zu tun haben. Aber mit Win 7 geht es ja. Für ein paar Tipps wäre ich echt dankbar! Gruß, Pit

Hi, ja, ich meine den 2012R2 Standard. Danke für die Info. Gruß, Pit

Hallo, kann man den Server 2012 R2 problemlos als Arbeitsgruppe betreiben (ohne zwingende AD Installation und dann wieder herunterstufen)? Zum Essentials oder Foundation habe ich gelesen, dass diese zwingend eine AD Installation verlangen. Zum Server 2012 R2 habe ich diesbezüglich nichs gefunden. Ich möchte nur sicher gehen. Schöne Grüße Pit

Hallo, ist schon ein echter Server, wird aber gerade nur zum testen verwendet. Als "externe" Karte wollte ich erst mal nicht soviel Geld ausgeben. Alle freigegebene Serverkarten sind immer gleich 2-Port Karten und schweineteuer. Der Dektop-Adapter ist aber für das Gerät (Fujitsu TX2540 M1) auch freigegeben. Ich finde keine VMQ-Option unter den Eigenschaften (am Host) der NIC. Nur Large-Send-Offload V2 (IP4) und IP6. Beides ist aktiviert. Hab's jetzt mal deaktiviert (wird auch scheinbar generell empfohlen). Gruß, Pit

Hallo, ich bin gerade bei der Fehlerbereinigung von Windows Server 2012R2 in einer VM mit Exchange 2016 drauf. Der Host und der DC sind ebefalls Server 2012R2. Mich wurmt hier eine Warnmeldung mit der ID 4320, Quelle: Tcpip Aufgrund einer Netzwerkbedingung wurde festgelegt, dass das Überlastungsfenster für mehrere Verbindungen beschränkt wird. Dies kann auf ein Problem in der globalen oder zusätzlichen TCP-Konfiguration zurückzuführen sein und hat die Verschlechterung des Durchsatzes zur Folge. Negative Auswirkungen kann ich aktuell nicht feststellen. Aber wer weiß... Kann das mit der Netzwerkkarte zusammenhängen? Es ist eine "Intel Gigabit CT2 Desktop Adapter". Die Treiber werden vom System gestellt und es gibt auch keine aktuelleren für Server 2012R2. Gruß, Peter