MarkusM1971

Hallo zusammen, ich komme der Sache näher, muss es nur noch reproduzierbar absichern... Folgendes: Da selbst Test-OutlookConnectivity ein "erfolgreich" meldet, war ich mir dann zu 99% sicher, das die die eigentliche Exchange/Outlook Umgebung in Ordnung sein muss. Netzwerkprobleme? Na ja, ich habe kein Internet -> aber das scheint es wirklich zu sein! Wie komme ich darauf? 1. Habe das Test-Laptop aus der Testumgebungsdomäne rausgenommen und in eine Arbeitsgruppe gepackt 2. Laptop in produktive Umgebung in Domäne aufgenommen (DHCP mit vorhandenem Gateway) 3. User angemeldet -> Outlook läuft sofort ohne Probleme 4. Laptop zurück in Testumgebungsdomäne (DHCP) 5. Outlook läuft nicht -> Netzwerksymbol im Tray zeigt "Kein Internetzugriff" 6. Feste IP Konfiguration eingerichtet 7. dabei wieder mal den ersten DC der Testumgebung versuchsweise als Standardgateway eingerichtet 8. Überraschenderweise zeigt das Symbol dieses Mal im Tray danach "Internetzugriff" (obwohl im Labor kein Internetzugang existiert) 9. Outlook startet sofort und ohne Probleme 10. Neustart des Laptop -> immer noch "Internetzugriff" und Outlook läuft weiterhin 11. Das Warum des angeblich vorhandenen "Internetzugriff" ist mir noch nicht ganz klar Aber: Dazu Hinweis in Richtung NLA (Network Location Awareness) gefunden. https://blog.superuser.com/2011/05/16/windows-7-network-awareness/ Ist zwar schon älter, aber erklärt das Ganze recht gut. Ist eine Technik, womit ein MS System prüft, ob eine Internetverbindung existiert oder nicht, entsprechend wird das dann beim Netzwerksymbol im Tray angezeigt. Zur Zeit habe ich unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ den EnableActiveProbing auf 0 Mit diesem Registry Eintrag und dem gefakten "Standardgateway" (DC als Gateway) startet Outlook ohne Probleme. Ich bleibe dran und werde dies mit einem zweiten Client im Labor absichern. Gruß, Markus

@ Dukel Habe es mal auf NUR "Windows Auth." umgestellt und IIS neu gestartet -> keine Änderung im Verhalten - > wieder zurückgestellt

Hallo Dukel, wurde alles von einem Systemhaus eingerichtet, bin somit für jeden Hinweis zur zukünftigen Verbesserung dankbar... Gruß, Markus

Moin cj_berlin, folgende Antworten zu deine Fragen. 1. Get-ServerComponentState sagt 35 "active" components 2. Outlook ohne Kontoeinrichtung starten, Rechtsklick mit STRG auf Outlook Symbol -> E-Mail Konfiguration testen 3. IIS -> Frontend -> mapi -> Authentifizierung -> Standard und Windows aktiviert -> Negotiate/Negotiate:Kerberos/NTLM Siehe hochgeladene Screenshots. Hoffentlich sind die Screenshots passend, bin leider kein Exchange-Experte... Danke und Gruß, Markus

Hallo zusammen, ich nutze eine isolierte Testumgebung zum Testen von Veeam-Sicherungen (kein Internet Zugriff, da komplett separiert). Alles OK soweit (DCs, ERP, DMS, CAD), aber ich hänge bei Exchange/Outlook fest. Details hierzu: 2 x Server 2012 R2 als DCs (DHCP,DNS) 1 x Server 2012 R2 mit Exchange 2016 1 x Win 10 Client mit Outlook 2016 Folgendes Problem: Alle Server sind mittels Veeam gesichert und in der Testumgebung mit gleichem Datum restored. DCs (AD, DHCP, DNS) sind funktional. Exchange ist insofern funktional, das ich mit OWA komplett arbeiten kann: - keine Zertifikatmeldungen beim Starten von OWA - Mails können zwischen zwei Postfächern via OWA hin-und her gesendet werden - Kalender sind einsehbar etc. - Autodiscover scheint OK - DNS Tests mit NSLookup sind für Autodiscover OK - Autodiscover kann erfolgreich ein Profil in Outlook anlegen - Direkt nach der Erzeugung des Profiles stoppt es bei der Verbindung zum Exchange: ---- "Microsoft Outlook kann nicht gestartet werden. Das Outlook Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Fehler bei der Anmeldung bei MS Exchange." (ohne Cache Mode) ---- Bei Nutzung des CacheMode kommt eben noch "Die Datei ist kein Outlook Datendatei (OST)." dazu... Wie gesagt ist das Profil ab diesem Zeitpunkt vorhanden und kann auch bearbeitet werden, aber es kommt zu keiner Verbindung. Die üblichen Maßnahmen haben zu keinem Erfolg geführt: - Outlook Reparatur - Outlook Neu - Dummy Default Gateway eingetragen (versuchsweise den Mail-Server selbst, da das Gateway der produktiven Umgebung ja nicht erreichbar ist wegen der Laborumgebung) - diverse Reg Einträge (Deaktivierung Autodiscover O365, Mapi Over HTTP disable/enable etc. ...) Mir scheint, das es bei der MAPI/HTTP Anmeldung hängt. Da aber die DCs und der Exchange genau in dieser Kombination in der produktiven Umgebung ohne Probleme funktionieren, hänge ich gerade richtig fest... Was fehlt im Testlabor evtl.? Internetzugang? Ach so, die Testumgebung dient auch dazu, letztendlich die Server 2012 R2 durch Server 2016/19 zu ersetzen... Vielleicht habt ihr ja eine Idee hierzu, wie gesagt, ich sehe den "Wald vor lauter Bäumen nicht mehr" ... Danke und Gruß, Markus

Hallo zusammen, OK... aus Euren Kommentaren entnehme ich, dass eine SA bei den Server CALS nicht notwendig scheint. Auch ein Admin-Kollege aus einem anderen Unternehmen sagte mir, das die SA nicht zwingend ist bei Hochverfügbarkeit. Dies alles bestätigt letztendlich meine eigenen Recherchen hierzu. Hier die Hintergrundgeschichte dazu: Habe mir von 2 Systemhäusern ein Konzept aufgrund von mir festgelegten Eckdaten erstellen lassen. Das eine Systemhaus sagt, das in jedem Fall bei Hochverfügbarkeit die CALS mit SA gekauft werden müssen, Der andere Anbieter sagt dazu "Quatsch - ihr benötigt nur dann die SA, wenn ihr von dem implizierten Upgrade Recht Gebrauch machen wollt". Was wir aber in diesem Konzept nicht benötigen werden. Mal schauen, was der eine Anbieter dazu sagt ... Gruß, Markus

Hallo zusammen, habe zwar schon etwas recherchiert, finde aber nur unpräzise und auch widersprüchliche Aussagen zu folgender Situation: Geplant ist: - HP VSA SAN mit Hochverfügbarkeit (active-active Konzept über 2 Serverräume in 2 Brandabschnitten) - pro Serverraum 1 ESX Server (entsprechend performant ausgelegt) - 12 virt. Server (nur Windows) mit HA und vMotion - Server 2016 Datacenter pro Serverraum In welchen Fällen benötigt man für die Server CALS definitv eine SA? Benötigt man alleine wegen der Hochverfügbarkeit eine SA bei den Server CALS? P.S. Mir ist klar das ich für einen Exchange 2016 oder SQL 2014 zwingend eine SA benötige. Aber wie sieht es hier bei den CALS aus? Gruß, Markus