Jump to content

ehcm

Members
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ehcm

  • Rank
    Newbie
  1. Korrekt, der SRV-DC1 ist ein Domänencontroller. Mir ist die Sicherheitslücke gerade nicht bewusst, kann mich kurz jemand aufklären?
  2. Hallo zusammen, bei meiner Exchange 2013 DAG ist die falsche Zeugenressource angegeben. Fehlermeldung in der Ereignisanzeige: Die Dateifreigabe-Zeugenressource "File Share Witness (\\srv-dc1.domain.local\Exchange-DAG.domain.local)" konnte nicht für die Dateifreigabe "\\SRV-DC1.domain.local\Exchange-DAG.domain.local" vermitteln. Stellen Sie sicher, dass die Dateifreigabe "\\SRV-DC1.domain.local\Exchange-DAG.domain.local" vorhanden ist und dass der Cluster darauf zugreifen kann. - Ereignis-ID 1564 In der ECP ist sie korrekt angegeben: Allerdings nicht, wenn ich sie per get-clusterresource abfrage: Name : File Share Witness (\\srv-dc1.domain.local\Exchange-DAG.domain.local) State : Failed OwnerGroup : Clustergruppe ResourceType : File Share Witness Wenn ich versuche den Pfad anzupassen erhalte ich mit meinem Domänen-Admin ein Zugriff verweigert: Get-ClusterResource "File Share Witness*" -Cluster Exchange-DAG.domain.local | set-ClusterParameter -name sharepath -value \\srv-dc1.domain.local\Exchange-DAG set-ClusterParameter : Geänderte Eigenschaften für "File Share Witness (\\srv-dc1.domain.local\Exchange-DAG.domain.local)" können nicht gespeichert werden. Zugriff verweigert In Zeile:1 Zeichen:83 + Get-ClusterResource "File Share Witness*" -Cluster Exchange-DAG.domain.local ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (:) [Set-ClusterParameter], ClusterCmdletException + FullyQualifiedErrorId : AccessDenied,Microsoft.FailoverClusters.PowerShell.SetClusterParameterCommand Und in die Ereignisanzeige wird folgender Fehler geschrieben: PowerShell-Cmdlet "Set-ClusterParameter" für Failovercluster: Geänderte Eigenschaften für "File Share Witness (\\srv-dc1.domain.local\Exchange-DAG.domain.local)" können nicht gespeichert werden. - Ereignis-ID: 4657 Habt ihr eine Idee, wie ich die Zeugenressource bearbeiten kann? Welche Benutzerrechte sind hier erforderlich? Viele Grüße ehcm Ich konnte das Thema selbst lösen. Nach dem ich diesen Haken gesetzt habe, konnte ich den Befehl durchführen: Get-ClusterResource "File Share Witness*" -Cluster Exchange-DAG.domain.local | set-ClusterParameter -name sharepath -value \\srv-dc1.domain.local\Exchange-DAG WARNUNG: Die Eigenschaften wurden gespeichert, doch alle Änderungen werden erst wirksam, wenn File Share Witness (\\srv-dc1.domain.local\Exchange-DAG.domain.local) offline und anschließendwieder online geschaltet wird.
  3. Ich konnte das Problem in der Zwischenzeit weiter eingrenzen. Wenn ich die Dateien im Verzeichnis "C:\Users\%Username%\AppData\Roaming\Microsoft\Credentials" lösche tritt das Problem nicht mehr auf, bis ich mich unter dem Benutzer mit einem anderen Outlookkonto anmelde und das Kennwort speichere. Für mich wirkt es derzeit wie ein Bug. Derzeit habe ich die Möglichkeit entweder das Kennwort nicht zu speichern oder dem anderen Benutzer Vollzugriff auf das andere Postfach zu geben. Habt ihr hierfür eine Lösung?
  4. Meinst du diesen Screenshot? Dass war zu dem Zeitpunkt, wo ich durch einen angepassten Host-Eintrag den Loadbalancer umgangen habe und einen Exchange-Server direkt angesteuert habe.
  5. Nein, dass ist nur das Zertifikat, wenn ich auf den Server direkt zugreife und den Loadbalancer umgehe. Auf dem normalen Weg ist das Wildcard-Zertifikat hinterlegt.
  6. Um nochmal das Zertifikatsthema aufzugreifen... Auf unseren Exchange-Servern sind derzeit folgende Zertifikate installiert: (Das zweite Zerifikat ist gleich aufgebaut) Habe ich es richtig verstanden, dass es besser wäre von unserer internen Zeritfizierungsstelle jeweils ein Zertifikat ausstellen zu lassen und hinzu zufügen?
  7. Einmal die RAW beim Klick auf automatisch Antworten. POST https://exchange.domain.com/ews/exchange.asmx HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml; charset=utf-8 User-Agent: Microsoft Office/15.0 (Windows NT 10.0; Microsoft Outlook 15.0.5059; Pro) X-User-Identity: bxxx.axxx@domain.com Depth: 0 Content-Length: 471 Host: exchange.domain.com Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJwAAABsAWwBtAAAABIAEgBYAAAAJgAmAGoAAAAMAAwAkAABBBBAAEAAgAgAAFYKI4goA7kIAAAAPoy/v6U5NPsyXrAh5O5uhmE0AWQBUAEgARQBSAEUAUwBBAGEAZABtAGkAbgAuAGIAYQBiAGUAbAB0AHMAaABhAHUAcwBlAHIATQBXAFMAOAA4ADcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5yvaTuqk74TlpSd5JZA5awEBAAAAAAAAAeybj6Nq1AG8tOn5RuZ5mQAAAAACABIATQBZAFQASABFAFIARQBTAEEAAQAOAFMAUgBWAC0ARQBYADIABAAeAG0AeQB0AGgAZQByAGUAcwBhAC4AbABvAGMAYQBsAAMALgBTAFIAVgAtAEUAWAAyAC4AbQB5AHQAaABlAHIAZQBzAGEALgBsAG8AYwBhAGwABQAeAG0AeQB0AGgAZQByAGUAcwBhAC4AbABvAGMAYQBsAAcACAAB7JuPo2rUAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAANZ7mx29a+/B6/lgRBBKwr8P4jHh9Ec5V4g/jbggQxDgoAEAA43bsqMZt8RhMQvS3Iciu0CQA2AEgAVABUAFAALwBlAHgAYwBoAGEAbgBnAGUALgBtAHkAdABoAGUAcgBlAHMAYQAuAGMAbwBtAAAAAAAAAAAAAAAAAIdvtl7T/x4SXIN1uLdGuy8= Cookie: OutlookSession="{8F188690-0906-44B2-ACBD-A4D5200D2DE7}"; ClientId=LZTQLJSUWBBVDKHVXBKU <?xml version="1.0"?> <q:Envelope xmlns:q="http://schemas.xmlsoap.org/soap/envelope/"><q:Body><ex12m:GetUserOofSettingsRequest xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages"><ex12t:Mailbox xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types"><ex12t:Address>bxxx.axxx@domain.com</ex12t:Address><ex12t:RoutingType>SMTP</ex12t:RoutingType></ex12t:Mailbox></ex12m:GetUserOofSettingsRequest></q:Body></q:Envelope> Daraufhin konnte ich mit der ClientID im W3SVC2-Log noch etwas finden: 2018-10-23 07:39:41 192.168.72.236 POST /ews/exchange.asmx &CorrelationID=<empty>;&ClientId=LZTQLJSUWBBVDKHVXBKU&cafeReqId=6a8afd76-08cf-44af-83ea-010776fa84cb; 443 - 192.168.72.233 Microsoft+Office/15.0+(Windows+NT+10.0;+Microsoft+Outlook+15.0.5059;+Pro) - 401 1 2148074254 31 Und die RAW aus dem Autodiscover, wobei mir hier auffällt, dass es sich um eine andere Client-ID handelt. POST https://exchange.domain.com/autodiscover/autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml User-Agent: Microsoft Office/15.0 (Windows NT 10.0; Microsoft Outlook 15.0.5059; Pro) Client-Request-Id: {EFC3FA52-D057-4A15-A70B-32EF8C43DA84} X-MapiHttpCapability: 1 Depth: 0 X-AnchorMailbox: bxxx.axxx@domain.com X-User-Identity: bxxx.axxx@domain.com Content-Length: 368 Host: exchange.domain.com Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJwAAABsAWwBtAAAABIAEgBYAAAAJgAmAGoAAAAMAAwAkAAAABAAEAAgAgAAFYKI4goA7kIAAAAPBzssEaRTRPLH7rdl3r9bcU0AWQBUAEgARQBSAEUAUwBBAGEAZABtAGkAbgAuAGIAYQBiAGUAbAB0AHMAaABhAHUAcwBlAHIATQBXAFMAOAA4ADcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAm19gb1LmTtQOMFxyqu1DawEBAAAAAAAA9T/y0KRq1AHyh9ADLS6IFgAAAAACABIATQBZAFQASABFAFIARQBTAEEAAQAOAFMAUgBWAC0ARQBYADEABAAeAG0AeQB0AGgAZQByAGUAcwBhAC4AbABvAGMAYQBsAAMALgBTAFIAVgAtAEUAWAAxAC4AbQB5AHQAaABlAHIAZQBzAGEALgBsAG8AYwBhAGwABQAeAG0AeQB0AGgAZQByAGUAcwBhAC4AbABvAGMAYQBsAAcACAD1P/LQpGrUAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAANZ7mx29a+/B6/lgRBBKwr8P4jHh9Ec5V4g/jbggQxDgoAEAA43bsqMZt8RhMQvS3Iciu0CQA2AEgAVABUAFAALwBlAHgAYwBoAGEAbgBnAGUALgBtAHkAdABoAGUAcgBlAHMAYQAuAGMAbwBtAAAAAAAAAAAAAAAAAFluDQ4/gaP+qI4FqXipmLQ= Cookie: OutlookSession="{D290FFC0-AFF8-4AF0-8DD3-E3014A078132}"; ClientId=LFDOKQHJIEUXDBIQDYW <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>bxxxaxxx@domain.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>
  8. Meinst du mit dem IISlog folgendes ...\inetpub\LogFiles\W3SVC1 bzw. W3SVC2? Hier finde ich leider gar keine Einträge zu meinem Benutzer zu dem Zeitpunkt wo ich die automatische Antwort teste. Bei Fiddler erscheinen folgende Einträge, wenn ich versuche eine automatische Antwort zu erstellen: ...und beim Autodiscover: Der Loadbalancer arbeitet auf Layer 7 mit SSL reencrypt.
  9. Es handelt sich um 2 Exchange-Server in der DAG. Die URLs sind sowohl für intern, als auch für extern immer nach diesem Schema aufgebaut: https://exchange.domain.com/ecp exchange.domain.com und autodiscover.domain.com werden vom DNS aufgelöst und verweisen auf den Loadbalancer.
  10. Wäre es besser eigene Zertifikate für die einzelnen Server zu kaufen? Bzw. welche Vorteile bringt das?
  11. Das heißt, ich sollte am besten das *.domain.com Zertifikat vom Loadbalancer auch auf beiden Exchangeservern einspielen?
  12. Ich habe den Hosts-Eintrag testweise mal angepasst. Die Fehlermeldung bleibt die Gleiche, auch nach einem /flushdns und einem Rechnerneustart. Zusätzlich erhalte ich auch nach der Installation des Self-Signed Zertifikats einen Sicherheitshinweis: Den Kemp Support habe ich bis jetzt hierzu noch nicht ins Boot geholt.
  13. Exchange Dienste laufen alle: Auch bei Get-ServerComponentState schaut alles gut aus. Das Ganze hat schon funktioniert. Allerdings kann ich nicht sagen, seit wann genau es nicht mehr funktioniert.
  14. Hallo zusammen, bei uns tritt zurzeit bei einzelnen Postfächern folgende Fehlermeldung auf, beim Versuch in Outlook eine automatische Antwort zu erstellen: Das Problem tritt nur in Outlook auf. Ein erstellen der automatischen Antwort in OWA und über Powershell ist auch für die betroffenen Postfächer möglich. Bis jetzt kann ich leider noch kein Schema feststellen, welche Postfächer betroffen sind. Es ist egal... ...auf welcher Datenbank sie liegen ...über welchen der beiden Exchangeserver zugegriffen wird ...welcher Arbeitsplatz/Outlook verwendet wird Folgendes habe ich bereits getestet: - Neueinbindung des Postfachs - Zugriff auf https://exchange.domain.com/ews/exchange.asmx ohne Zertifikatsmeldung möglich. Hier erscheint direkt die Login-Abfrage. - Reduzierung der zugehörigen AD-Gruppen des betroffenen Benutzers - Erhöhung des Wertes HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters "MaxFieldLength" und "MaxRequestBytes" von "65534" auf "65536" inkl. Neustart der Server Zur Umgebung: - Kemp-Loadbalancer mit der Version 7.1.34.1.12802 - 2x Exchange 2013 (Build 1367.3) in der DAG - Outlook Standard 2013 Habt ihr Ideen, was ich noch testen kann, um dieses Problem zu lösen? Viele Grüße ehcm
  15. Hallo zusammen, ich stehe vor folgendem Problem: Derzeit ruft ein, auf einer Windows-VM installiertes, Outlook 2013 via POP3 Mails von einem Mailserver ab und speichert diese in einer PST-Datei. Allerdings funktioniert die Synchronisation nicht mehr richtig, wenn die PST-Datei die Größe von ca. 50 GB überschreitet. Was nach ca. einem Monat der Fall ist. Ein anheben der PST-Grenzwerte im Registrierungseditor bringt leider keine Verbesserung. Die Synchronisierung funktioniert erst nach dem Anlegen einer neuen PST-Datei wieder, bis diese die ca. 50GB erreicht. Bevor wir Outlook für diesen Job im Einsatz hatten, haben wir Mailstore Home verwendet. Welches mit dem Mailaufkommen deutlich besser zurechtkam und dieses auch besser komprimiert hat. Allerdings haben wir dieses nicht mehr verwenden können, da es dort nicht möglich ist, die Mails automatisch nach 90 Tagen zu löschen. Habt ihr eine Idee, wie ich diesen Fall am besten lösen kann? Nochmal die wichtigsten Daten: * 50GB Mails pro Monat * Abruf über POP3 * Automatisches löschen nach 90 Tagen * Falls möglich, Komprimierung der Mails Viele Grüße ehcm
×
×
  • Create New...