SimonFB

Ich persönlich würde erstmal versuchen das "kleine Problem" zu lösen, bevor ich mit Kanonen auf Spatzen schieße. Oder uns an dem Problem teilhaben zu lassen...

So, Problem gelöst. Nachdem ich den Umstieg auf eine Single-Domain-Lösung gemacht habe* konnte ich ein öffentliches Zertifikat einbinden und weitere Fehlersuche via RemoteConnectivityAnalyser betreiben. Dies führte mich zu dem Fehler: Sämtliche Hinweise zu Firewall und Problemen mit den verwendeten Ports (6001, 6002, 6004 TCP) waren nicht hilfreich, Test per Telnet war jeweils erfolgreich. Ich fand aber bei der Recherche mehrere Einträge** zum Thema IPv6 und HOST-Datei. Ich war sicher damit in eine Sackgasse zu rennen - schließlich ist das ein Problem, was MS spätestens im SP1 hätte beheben müssen!! Tatsächlich war die Lösung aber erfolgreich. Fazit: 4 Wochen Ärger und Fehlersuche durch zwei Bugs (1x Outlook, 1x Exchange). Freue mich, dass nun alles geht, aber ein fader Beigeschmack bleibt. * http://www.mcseboard.de/topic/204150-exchange-als-single-domain-autodiscover-zertifikatsfehler/?do=findComment&comment=1275970 ** zB http://systemadminthings.com/2013/03/outlook-anywhere-rpc-over-http-failing-html/

So, Problem gelöst! Ich war der Meinung, dass möglicherweise etwas mit dem SCP nicht in Ordnung wäre. Auf der Suche bin ich auf einen Blogeintrag* gestoßen, der den SCP nochmal genauer erklärt - mit meinem SCP war aber alles in Ordnung! In einem der Kommentare zum Blog entdeckte ich dann dies: Stimmt so nicht ganz, die Reparatur war nicht erfolgreich. Aber Löschen und Neuanlage vom MAPI-Profil waren tatsächlich zielführend. Bin zwar noch nicht begeistert, dass ca. 100 Profile neu angelegt werden müssen, aber zumindest habe ich jetzt eine lauffähige Single-Domain-Lösung. Damit war es mir nun auch möglich ein vertrauenswürdiges/öffentliches Zertifikat zu installieren um mein anderes Problem** anzugehen. * https://acbrownit.wordpress.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/ ** http://www.mcseboard.de/topic/203870-outlook-anywhere-autodiscover-mehere-domains/?p=1273898

So, war im Kurzurlaub: Get-ClientAccessServer | fl *uri* AutoDiscoverServiceInternalUri : https://mail.kunde.com/autodiscover/autodiscover.xml Get-WebServicesVirtualDirectory | fl *url* InternalNLBBypassUrl : https://mail.kunde.com/ews/exchange.asmx InternalUrl : https://mail.kunde.com/ews/exchange.asmx ExternalUrl : https://mail.kunde.com/ews/exchange.asmx Get-OabVirtualDirectory | fl *url* InternalUrl : https://mail.kunde.com/OAB ExternalUrl : https://mail.kunde.com/OAB Get-AutodiscoverVirtualDirectory | fl *url* InternalUrl : ExternalUrl : https://mail-kunde.com/autodiscover/autodiscover.xml Get-OWAVirtualDirectory | fl *url* Url : InternalUrl : ExternalUrl : Url : InternalUrl : ExternalUrl : Url : InternalUrl : ExternalUrl : Url : InternalUrl : ExternalUrl : Url : {} InternalUrl : https://mail.kunde.com/owa ExternalUrl : https://mail.kunde.com/owa Get-ActiveSyncVirtualDirectory | fl *url* MobileClientCertificateAuthorityURL : InternalUrl : https://mail.kunde.com/Microsoft-Server-ActiveSync ExternalUrl : https://mail.kunde.com/Microsoft-Server-ActiveSync Das ist direkt der Output, dank Copy-and-Paste zwecks Anonymisierung fallen zwei Sachen auf: 1) Interne URL zum AutoDiscover-VirtualDirectory nicht gesetzt. 2) Tippfehler in der externen AutoDiscover-VirtualDirectory-URL. Habe ich vorher zwar in der Konsole gefühlte 12x überprüft, aber immer überlesen. Laut folgendem Artikel haben diese Einstellungen keine besondere Relevanz, ich werde aber am Montag den Praxisgehalt testen: http://blogs.technet.com/b/rmilne/archive/2013/04/02/busting-the-set-autodiscovervirtualdirectory-myth.aspx

Kann ich mir zum Glück noch überlegen, bin ja noch in der Vorbereitungsphase. mail.kunde.com löst auf die interne IP auf. Sonst würde ja gar nichts mehr funktionieren. Den SRV-Record für Autodiscover habe ich aber (noch?) nicht gesetzt, weil die Domänenclients (trifft auf alle internen zu) ja über den SCP bedient werden. Wenn ich in Outlook (intern, Domänenclient) die Autokonfiguration teste, sieht der dekodierte Traffic so aus: POST /autodiscover/autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{620CAE7E-AAF1-4E11-95DD-F277CF9189F8}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7153; Pro) X-MapiHttpCapability: 1 X-User-Identity: test@kunde.com X-AnchorMailbox: test@kunde.com Depth: 0 Content-Length: 359 Host: mail.kunde.com <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>test@kunde.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>HTTP/1.1 401 Unauthorized Content-Type: text/html Server: Microsoft-IIS/7.0 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM X-Powered-By: ASP.NET Date: Fri, 24 Jul 2015 14:15:18 GMT Content-Length: 74 Sie sind nicht berechtigt, dieses Verzeichnis oder diese Seite anzuzeigen.POST /autodiscover/autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{620CAE7E-AAF1-4E11-95DD-F277CF9189F8}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7153; Pro) X-MapiHttpCapability: 1 X-User-Identity: test@kunde.com X-AnchorMailbox: test@kunde.com Depth: 0 Content-Length: 0 Host: mail.kunde.com Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw== HTTP/1.1 401 Unauthorized Content-Type: text/html Server: Microsoft-IIS/7.0 WWW-Authenticate: Negotiate TlRMTVNTUAACAAAABgAGADgAAAAVgoniNODUw0QPaBsAAAAAAAAAAG4AbgA+AAAABgByFwAAAA9TAEsAUAACAAYAUwBLAFAAAQAMAE0AQQBJAEwAMAAxAAQADgBzAGsAcAAuAGEAZABzAAMAHABNAEEASQBMADAAMQAuAHMAawBwAC4AYQBkAHMABQAOAHMAawBwAC4AYQBkAHMABwAIAF5zLysbxtABAAAAAA== WWW-Authenticate: NTLM X-Powered-By: ASP.NET Date: Fri, 24 Jul 2015 14:15:18 GMT Content-Length: 74 Sie sind nicht berechtigt, dieses Verzeichnis oder diese Seite anzuzeigen.POST /autodiscover/autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{620CAE7E-AAF1-4E11-95DD-F277CF9189F8}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7153; Pro) X-MapiHttpCapability: 1 X-User-Identity: test@kunde.com X-AnchorMailbox: test@kunde.com Depth: 0 Content-Length: 359 Host: mail.kunde.com Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIAAAAA2ATYBmAAAAAYABgBYAAAADgAOAF4AAAAUABQAbAAAABAAEADOAQAAFYKI4gYBsR0AAAAP4wua365ZZBGL39lbsHUAJlMASwBQAGoAZQBkAHoAaQBuAHkASQAtAEkATgBWADAAMAAyADEANwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+w4JbRJrSoh8fO0i8vlViAQEAAAAAAABecy8rG8bQAfErx3mrpHpNAAAAAAIABgBTAEsAUAABAAwATQBBAEkATAAwADEABAAOAHMAawBwAC4AYQBkAHMAAwAcAE0AQQBJAEwAMAAxAC4AcwBrAHAALgBhAGQAcwAFAA4AcwBrAHAALgBhAGQAcwAHAAgAXnMvKxvG0AEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAMAAA9/y0n8C0fG9oy2UE+Tuyzx9PanQ+YlBBC8MZjVlRKY4KABAAjmKeYJf4UYy1CzsZg0UtRwkAQABIAFQAVABQAC8AbQBhAGkAbAAtAHMAawBwAC4AcwBrAHAALQBpAG4AZwBlAG4AaQBlAHUAcgBlAC4AYwBvAG0AAAAAAAAAAAAAAAAADJRQnS/Xj8+1jUV0TNB65w== <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>test@kunde.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Length: 2848 Content-Type: text/html; charset=utf-8 Expires: -1 Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 X-Powered-By: ASP.NET Date: Fri, 24 Jul 2015 14:15:18 GMT <?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <User> <DisplayName>Jedziny, Cornelia</DisplayName> <LegacyDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=berft</LegacyDN> <DeploymentId>01f4dee5-eeb8-4360-931d-d0edaca63f06</DeploymentId> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>MAIL01.intern.local</Server> <ServerDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL01</ServerDN> <ServerVersion>72038053</ServerVersion> <MdbDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL01/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer>MAIL01.intern.local</PublicFolderServer> <AD>dc01.intern.local</AD> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> <EwsUrl>https://mail.kunde.com/ews/exchange.asmx</EwsUrl> <OOFUrl>https://mail.kunde.com/ews/exchange.asmx</OOFUrl> <UMUrl>https://mail.kunde.com/UnifiedMessaging/Service.asmx</UMUrl> <OABUrl>https://mail.kunde.com/OAB/75788870-fc6f-4476-95a2-4802083af078/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>mail.kunde.com</Server> <SSL>On</SSL> <AuthPackage>Basic</AuthPackage> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> <EwsUrl>https://mail.kunde.com/ews/exchange.asmx</EwsUrl> <OOFUrl>https://mail.kunde.com/ews/exchange.asmx</OOFUrl> <OABUrl>https://mail.kunde.com/OAB/75788870-fc6f-4476-95a2-4802083af078/</OABUrl> <CertPrincipalName>msstd:mail.kunde.com</CertPrincipalName> </Protocol> <Protocol> <Type>WEB</Type> <External> <OWAUrl AuthenticationMethod="Fba">https://mail.kunde.com/owa</OWAUrl> <Protocol> <Type>EXPR</Type> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> </Protocol> </External> <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://mail.kunde.com/owa</OWAUrl> <Protocol> <Type>EXCH</Type> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> </Protocol> </Internal> </Protocol> </Account> </Response> </Autodiscover> Starte ich aber Outlook ohne weitere Eingabe, wird nach etwa 20 Sekunden im Hintergunde eine Autodiscover-Abfrage ausgeführt, die sich offenbar mehrmals am Tag wiederholt und von der obigen abweicht: POST /Autodiscover/Autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{8BC89FAC-AB19-4A40-9601-4E22EFE11673}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7153; Pro) X-MapiHttpCapability: 1 X-User-Identity: test@kunde.com X-AnchorMailbox: test@kunde.com Depth: 0 Content-Length: 359 Host: mail01.intern.local <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>test@kunde.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>HTTP/1.1 401 Unauthorized Content-Type: text/html Server: Microsoft-IIS/7.0 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM X-Powered-By: ASP.NET Date: Fri, 24 Jul 2015 14:13:05 GMT Content-Length: 74 Sie sind nicht berechtigt, dieses Verzeichnis oder diese Seite anzuzeigen.POST /Autodiscover/Autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{8BC89FAC-AB19-4A40-9601-4E22EFE11673}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7153; Pro) X-MapiHttpCapability: 1 X-User-Identity: test@kunde.com X-AnchorMailbox: test@kunde.com Depth: 0 Content-Length: 359 Host: mail01.intern.local Authorization: Negotiate YIIG+wYGKwYBBQUCoIIG7zCCBuugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBrUEggaxYIIGrQYJKoZIhvcSAQICAQBuggacMIIGmKADAgEFoQMCAQ6iBwMFACAAAACjggUmYYIFIjCCBR6gAwIBBaEJGwdTS1AuQURToiEwH6ADAgECoRgwFhsESFRUUBsOTUFJTDAxLnNrcC5hZHOjggTnMIIE46ADAgEXoQMCAUiiggTVBIIE0UwW8FLMjOSkYA1mJOyymWP35V6I0jlXg3QpTYjCGDfAvNoDHcOlIqDdprffQyNbk+HbYSXLhgb5hqqW2Nj5poRVFd1izJ+fcjSz9o2+jP19VEqXQXVTTQ0JgMw+D2UzKE0ly07g/M/x287bLQqOXDK7Lxp3Ea6Id1E/edcxFeRs6dbz7Bgq4/UdNpEeIsJTIVwgui4Q9aTW9yE6M3DXRJPcFUodvBW2dIhavfeCstQYqjBcceuNqcYu2KVKk3bX2J5rrsuND+1VYGY8E8v5mwOAKSRuaMbM+DnzvraRRYhYUknAES4rtKMVTrYT/S+rNDM/TuT5Ib1Pmqyl0/3yhDbZixOv4ygR61myfNj6NBgKnNGVqm7f/nZoU/35QYlAEutW5j/hdA6H+KkDz32tGYdWIV5d0KdaUFHXFdXa/dN2c38IZJVfkQ8LtzlLFKJhGJ9U159BwT2VouLWNgGgEp5AKlBcSu0eqKNzSomzxcbaI8T7+0Pv3/sRr6mFZuLnYb2PGhl5juh6umeMQBSC7PY8RPjKhIWFgoslEZTjcPBQ7Klk0JemKajmns3eZhI2ofJlzYbDY7UWBkkUpKSo+TZ9atbIUbMZnmtgcXPl2ASeUj+HfVfrQISv0kjsnv7KbvJDIu0o8xALPppvhqeYXu7e2xHx/K+tZ06ODJkc1UgyrbXhy1ot8Iz0Kvyax9cJ2B6mbYMvIpZhXsY7JzLNMvyuvLSRgV6aWRTSnDED/dSiN0VqP7Ao6Mugvva3CQPw2GlSgPclVUWMvQ0aSSJWbgxWxbQ8qeAldiMTaSx06MWtTJjE1EHmewc7meCpVbidMITA83GPnYbCqDDqQHXWyyv7b6nG3edlYnKfsAliN7FskBfT5vWyabGrPAbylscM+UUndtJpoZ9BclIiYOJ6bo6xL7u0dMo8a+GbjcCV9A2qbaEbVb+MNEu0RGJLfVzGwcwQqT23aO6JfPJeFH2SNYWfU94lXbio79OzXk3sKvovJlCWjzMfYI2ZR16jT3w4+4sv/OQdTcT8gr0/EBXST+NMuPdU7GmcqIH5kadh24g5YG1XYvxV/d/nCSjQLtPmx5CgyDggnZS/He1e9bvDJcZa0w2EfpZm6ldVZErDpix5ItIAZ64OhVDAd4tN61EDSUTlJMbEl7fyio/mRrE/XvHD3Yz0MCk7pmhcOxgKGdTxkjazH5F0B4cULLUGNKiWMTYOwslklUri1sA0wGKla8HG4KW7RCtJcOUBNE0Qay6OTFlXEzng+CH5G42cYOGS/tJelnVJ53CBFMgHrdrL6OZXMgLpaoXo3Ha2KknDPnbH/a9myN5xhnWYwy6oDcBd+aVjYdtWUdFdr3f8++6DnG8enkYc9n4z4Os2+CpqRWAYQ6ZrDn4iWeT4bQrBhGWezmDyOe8RbQRLhtgCl/0p9VEWBVdxLV56Vbk6neACYGjlmFbcjRuLaVYtQ02DanyioYo+7ZUHV80IEA2sncj5f18HqmcSpROyoIMEhBE5p8iI9YWbeAS4QkywLhfsad2eSxDAg7Mn8TqClm4Jev1pAb4L2CH7ZlfrHsepn0S+0PS/vu8cWaC0AGrrLcGshaueGffsnBktDDibjZxNXci5z+9yJIqztWFG1dtxRztV6wJyRqSCAVcwggFToAMCAReiggFKBIIBRgVJr+/XmiiBkVm9kK7uEC3daApiy6K95S0yzcDBjxWN7uc/cA1tdegtvoywgP4KWqg6DW3Iu4HexvAhDRhEwQOzVsVsjavmnVs3rwgnGMFv6xRYwwcq6DOcvKjk6CVLLUWHEJaGV5EwKJubQU3NH/2MnOW9DRA5v/W/hcdA2F3E+rBe2ne97312cj490ojjYYv08uvgwdw3pwCpZKpopeJgjN5Ons8zll9DQjUx5pzMYuRgWqULTZCVAp37janj/Ok7t6M9BDAB9SC49QEpJXqCJ+LEkcc1QXe+skNsq1zrCAWultd6bDZAuCJooY4PV/Lkc8MNu9enTzd4FUybidmh+64k22mEU84DgMOqnuHqIIOIjAQGeSJ9QggrRjxiHyLNArV8lGOhv5OogZbOUrkPSjeUaGU5whlIjRUtDzHOfEmxGVpR <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>test@kunde.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>HTTP/1.1 200 OK Cache-Control: no-cache Pragma: no-cache Content-Length: 2848 Content-Type: text/html; charset=utf-8 Expires: -1 Server: Microsoft-IIS/7.0 X-AspNet-Version: 2.0.50727 WWW-Authenticate: Negotiate oYGyMIGvoAMKAQChCwYJKoZIgvcSAQICooGaBIGXYIGUBgkqhkiG9xIBAgICAG+BhDCBgaADAgEFoQMCAQ+idTBzoAMCAReibARqTYO1hPN70go69FuPeu5nnW7uDWW9mwvychl7gnO+54ltAqCLwFSD8puJakxNM70YgKKpSnkg5BoouclwbxRLbiJxPUn6WT63SIhuXHBbyy1fMKovJkQWZ2e+kHTqFvQvTaa+rZdyVd89yg== X-Powered-By: ASP.NET Date: Fri, 24 Jul 2015 14:13:05 GMT <?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <User> <DisplayName>Jedziny, Cornelia</DisplayName> <LegacyDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=berft</LegacyDN> <DeploymentId>01f4dee5-eeb8-4360-931d-d0edaca63f06</DeploymentId> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>mail01.intern.local</Server> <ServerDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL01</ServerDN> <ServerVersion>72038053</ServerVersion> <MdbDN>/o=intern/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL01/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer>mail01.intern.local</PublicFolderServer> <AD>DC03.intern.local</AD> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> <EwsUrl>https://mail.kunde.com/ews/exchange.asmx</EwsUrl> <OOFUrl>https://mail.kunde.com/ews/exchange.asmx</OOFUrl> <UMUrl>https://mail.kunde.com/UnifiedMessaging/Service.asmx</UMUrl> <OABUrl>https://mail.kunde.com/OAB/75788870-fc6f-4476-95a2-4802083af078/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>mail.kunde.com</Server> <SSL>On</SSL> <AuthPackage>Basic</AuthPackage> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> <EwsUrl>https://mail.kunde.com/ews/exchange.asmx</EwsUrl> <OOFUrl>https://mail.kunde.com/ews/exchange.asmx</OOFUrl> <OABUrl>https://mail.kunde.com/OAB/75788870-fc6f-4476-95a2-4802083af078/</OABUrl> <CertPrincipalName>msstd:mail.kunde.com</CertPrincipalName> </Protocol> <Protocol> <Type>WEB</Type> <External> <OWAUrl AuthenticationMethod="Fba">https://mail.kunde.com/owa</OWAUrl> <Protocol> <Type>EXPR</Type> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> </Protocol> </External> <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://mail.kunde.com/owa</OWAUrl> <Protocol> <Type>EXCH</Type> <ASUrl>https://mail.kunde.com/ews/exchange.asmx</ASUrl> </Protocol> </Internal> </Protocol> </Account> </Response> </Autodiscover> Grüße, Simon

Guten Abend! Nicht zuletzt wegen der Hinweise aus diesem Forum bin ich gerade dabei für einen Kunden endlich ein "ernsthaftes" SSL-Zertifikat für seinen Exchange zu kaufen. Da ab November keinen internen Namens auf Zertifikaten mehr gelten, will ich ein Single-Domain-Zertifikat für mail.kunde.com kaufen. Ich bin also gerade dabei dem Exchange 2007 beizubringen, dass er intern und extern auf den gleichen FQDN hört. Dafür gibt es ja auch genügend Anleitungen. Zum Testen habe ich ein selbt-zertifiziertes Zertifikat ausgestellt, dass ausschließlich den externen FQDN beinhaltet. Problem ist nun: Die internen Nutzer (via RPC, Outlook 2010 und 2013) erhalten in unregelmäßigen Abständen Zertifikatswarnungen. Mir ist es nun gelungen den Netzwerktraffic, der die Zertifikatswarnung auslöst, mitzuschneiden und zu entschlüsseln. Dabei zeigt sich, dass Outlook im laufenden Betrieb -ohne Benutzerinteraktion- Autodiscover-Abfragen absetzt. Verwundert mich nicht besonders, aber...: -Bei der Neueinrichtung von Kontos werden diese Abfragen gegen den (neuen) externen FQDN gerichtet. -Bei manuellem Start "Outlook => Autokonfiguration testen" gehen die Abfragen gegen den (neuen) externen FQDN. -Die periodischen Abfragen im laufenden Betrieb gehen gegen den alten, internen FQDN. Es sieht für mich ein bißchen so aus, als würden Variante 1) und 2) über den SCP laufen, Variante 3) aber nicht. Konnte schon jemand ähnliche Erfahrungen sammeln oder hat eine Idee wo diese unterschiedlichen Verhalten von Autodiscover herrrühren? Soll ich doch noch (intern) einen SRV-Record anlegen? Grüße, Simon

Bekomme mit Outlook immer noch keine Verbindung. OWA und alle Smartphones laufen nach wie vor ohne Probleme. Habe jetzt mal eine fehlschlagende Verbindung mitgeschnitten und entschlüsselt. Hat noch jemand eine Idee? tcp.stream eq 0 => kein Fehler RPC_IN_DATA /rpc/rpcproxy.dll?mail01.***.ads:6002 HTTP/1.1 Accept: application/rpc Cookie: OutlookSession="{5F3A46E1-6426-429B-91A8-1D0E7F038157} Outlook=14.0.7151.5000 OS=6.0.6002" User-Agent: MSRPC Host: mail.****ingenieure.com Content-Length: 1073741824 Connection: Keep-Alive Cache-Control: no-cache Pragma: no-cache Authorization: Basic c2twXG53dXNlcjowbTluOGI3dg== ........h.........................fG..$..6i.I........G.t.:.i9.i..h.J.......@............{......G......3"..........(.......................D.<a......O........]..........+.H`..........D.<a......O.......,..l..@E............ .......NTLMSSP...........................r......................... .......NTLMSSP.........z...............X.......^.......j.......p...5.....r.....d....+'... ....P*.*.*.n.w.u.s.e.r.W.T.S.B.L.N.0.2.........................q...F....U.M)...........o.,.......I9.X?.........*.*.*.....M.A.I.L.0.1.....*.*.*...a.d.s.....M.A.I.L.0.1...*.*.*...a.d.s.....*.*.*...a.d.s.....o.,...............0.0............0..Z.#....W...ch...r.M..6.S~.....................(..v.d.......Q................\........M.kb...A.._ ....,...d.(a....J..s.......)...Xa..N...@?..U.w7....<..D.:.i..K..c//.Q..3.!.+..3..{. ............|8...X..... tcp.stream eq 1 => RPC Fehlermeldung ist by Design und markiert Ende der Kommunikation?! RPC_OUT_DATA /rpc/rpcproxy.dll?mail01.***.ads:6002 HTTP/1.1 Accept: application/rpc Cookie: OutlookSession="{5F3A46E1-6426-429B-91A8-1D0E7F038157} Outlook=14.0.7151.5000 OS=6.0.6002" Pragma: SessionId=c9b38c7b-01e9-47a4-9d14-b7c71bda3322 User-Agent: MSRPC Host: mail.****ingenieure.com Content-Length: 76 Connection: Keep-Alive Cache-Control: no-cache Authorization: Basic c2twXG53dXNlcjowbTluOGI3dg== ........L.........................fG..$..6i.I.......X.....F8..jC.}..........HTTP/1.1 200 Success Content-Type:application/rpc Content-Length:1073741824 ....................................,.............................................................6002...........]..........+.H`............................ .......NTLMSSP.........8...5........D.j........n.n.>.....r.....*.*.*.....*.*.*.....M.A.I.L.0.1.....*.*.*...a.d.s.....M.A.I.L.0.1...*.*.*...a.d.s.....*.*.*...a.d.s.....o.,.................`.......,.........ZVJ..(e`.{.V..c.3.p7. 5.....z.g`..FYtf;W.r.@=. ............<.0........HTTP/1.0 503 RPC Error: c0021012 tcp.stream eq 2 => Fehler! RPC_IN_DATA /rpc/rpcproxy.dll?MAIL01.***.ads:6004 HTTP/1.1 Accept: application/rpc Cookie: OutlookSession="{5F3A46E1-6426-429B-91A8-1D0E7F038157} Outlook=14.0.7151.5000 OS=6.0.6002" User-Agent: MSRPC Host: mail.****ingenieure.com Content-Length: 1073741824 Connection: Keep-Alive Cache-Control: no-cache Pragma: no-cache Authorization: Basic c2twXG53dXNlcjowbTluOGI3dg== ........h..........................>Clw4>...s:uP....E...}.^9l...W.-b.......@...............3..3A.......HHTTP/1.0 503 RPC Error: 6c0 Der 6c0 (1728) taucht aber nicht im Eventlog auf...

Leider (derzeit noch) nicht. Ich bin ein bißchen weiter gekommen. Im Exchange war der CertPrincipalName des Outlook-Providers EXPR auf "*.internedomäne.ads" gesetzt. Dies habe ich jetzt testweise auf "none" (nicht: $null) festgelegt. Seitdem ist der Fehler 10 weg. Eine Verbindung bekomme ich trotzdem nicht zustande: Mehrfache Passwort-Abfrage, "Muss im Onlinemodus und verbunden sein...". Remote Connectivity Analyzer läuft mit SSL ingnorieren sauber durch, inklusive Postfach-Syncronisation.

Hallo Norbert, vielen Dank für diese gut platzierte Frage. Tatsächlich stoße ich hier auf einen Zertifikatsfehler, weil All-Inkl sich mit einem Zertifikat für *.kasserver.com meldet. Wenn ich nun die Reihenfolge der Abfragen beachte, scheitert der zweite Schritt, bevor der Dritte zielführend wäre. 1. SCP im AD => kann extern nicht klappen. 2. https://****projekt.com/autodiscover/autodiscover.xml => muss auch scheitern, da der Webspace nichts mit dem Exchange zu tun hat. Führt aber zu o.g. Zertifikatsfehler. 3. https://autodiscover.****projekt.com/autodiscover/autodiscover.xml=> Sollte sauber auflösen, wenn Zertifizierungsstelle vertrauenswürdig. Und das sagt der Remote Connectivity Analyzer dazu: Und an Euch beide meinen herzlichen Dank für Eure Geduld und Unterstützung bis hierher!

Sowohl über https://mail.***ingenieure.com/owa,als auch über https://autodiscover.****projekt.com/owa bekomme ich das erwartete Zertifikat. Was mir aber gerade beim Testen aufgefallen ist: Unverschlüsselt über Tcp-Port 80 stellen wir einen anderen Dienst zur Verfügung. Aber aufgrund der Zertifikatswarnung würde ich das als Fehlerursache ausschließen.

Stimmt, die Wildcard ist drin. Ich habe heute morgen den SRV-Record rausgeworfen und durch einen A-Record für Autodiscover ersetzt. Inzwischen sind die Änderungen im DNS angekommen, ein NsLookup auf den Autodiscover liefert die richtige 62.***.***.*** IP. Autodiscover funktioniert auch. Die Zertifikatswarnung bleibt aber leider.

Steht mit drin, neben etwa 40 anderen Einträgen. :rolleyes: Hatte nur nicht alle zitiert. Da muss ich mit einer Wissenslücke glänzen. Wäre der "richtige" Weg dann eine Subdomain "autodiscover.****projekt.com" mit A-Record auf 62.***.***.***? Bei All-Inkl sehe ich für die "****projekt.com" nichts. Oder meinst du eine andere Stelle? Ja, auf jeden Fall! Das wird aber noch ein bißchen dauern,er Kunde expandiert und kommt alle 4 Wochen mit neuen Domains um die Ecke. Grüße aus Berlin, Simon

Ich schließe mich hier einmal an - die Problematik ist bei mir sehr ähnlich. Ausgangssituation: -Exchange 2007. -Eine GbR, mehrere Firmen, noch mehr Domains. -Ein Mailserver, von Aussen erreichbar über 62.***.***.*** bzw. "mail.****ingenieure.com" Bisher saßen quasi alle (>100) Mitarbeiter im Haus, die CA für das selbstsignierte Zertifikat wird über die AD vertrauenswürdig. Alles schick. Nun gibt es 6 neue Mitarbeiter die von unterwegs RPC-over-Http(s) nutzen sollen. Habe also das Zertifikat auf den Notebooks installiert, den Proxy eintragen und: lief. Exakt bis zum ersten Neustart von Outlook (2013). Dann hat Outlook bei jedem Start über das (unkonfigurierte) Autodiscover den Proxy-Eintrag verworfen. Also habe ich bei All-Inkl für die Unterdomäne ****projekt.com einen SRV Eintrag im DNS vorgenommen: Name: _autodiscover._tcp Typ: SRV Prio: 0 Data: 0 443 mail.****ingenieure.com Seitdem funktioniert das Autodiscover problemlos. Nun bekomme ich aber beim Start die Fehlermeldung: Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor. Der Name des Sicherheitszertifikates ist ungültig oder entspreicht nicht dem Namen der Zielwebsite 'mail.****ingenieure.com'. Mein Problem ist aber: Im Zertifikat sind meiner Meinung nach alle möglichen beteiligten Domains als 'Alternative Antragstellernamen' eingetragen: DNS-Name=mail01 DNS-Name=mail01.internedomaene.ads DNS-Name=mail.***ingenieure.com DNS-Name=****projekt.com DNS-Name=autodiscover.****projekt.com Hat jemand einen Tipp für mich wie meine Fehlersuche weitergeht? Viele Grüße, Simon

Dieses Problem habe ich schon öfter gesehen - bisher hat es geholfen, nicht direkt im Sicherungstask das Ziel über "Netzlaufwerk:\" oder über den UNC-Pfad zu definieren, sondern ein persönliches Depot mit dem hinterlegten UNC-Pfad zu erstellen. Bei der Einrichtung des Depots werden die Anmeldedaten hinterlegt, allerdings konnte ich schon öfter beobachten, dass diese noch einmal "verloren" gehen. Dies ist gut zu beobachten, wenn in der Übersicht über die Persönlichen Depots die Speicherkapazitäten nicht mehr angezeigt werden. In diesem Fall hat es bisher immer ausgereicht, die Anmeldedaten noch einmal einzugeben, danach sind sie gespeichert worden. Dieses Problem hatte ich bestimmt schon 10 mal...

Zahni, ich verneige mich und frage mich gleichzeitig, warum ich nicht selber auf die Idee mit der IASC gekommen bin. Die Critical-Events sind gut gefüllt und korrespondieren zum großen Teil auch mit den Bluescreens. Da die Fehler Round-Robin-artig über alle Module laufen, geht das Log nun einfach zum Serverhersteller - dann können die überlegen, was ausgetauscht werden soll. BTW: Das WinDbg habe ich über besagten SDK-Installer über den Punkt Common Utilitys => Debugging Tools installiert. Version war trotzdem die 12.6. Merkwürdig. Nochmal danke!

Vorweg schonmal vielen Dank für die Antworten! Der installierte KVR1333D3S8R9S/1GI ist in der Kompatibilitätsliste enthalten. Auch dein Link führte mich wieder zu der Version 12.6, welche (mit Online-Symbol Pfaden) nicht so ganz mit dem WHEA klarzukommen scheint. Nun war ich aber offenbar bisher mit Blindheit geschlagen und habe in der Ereignisanzeige noch einen Eintrag vom WHEA-Logger (Event-ID 18) gefunden, welcher folgendes besagt: Schwerwiegender Hardwarefehler. Fehlerquelle: Computerüberprüfung Fehlertyp: Speichercontrollerfehler Prozessor-ID gültig: Ja Prozessor-ID: 0x4 Steckplatznummer: 8 Von daher werde ich als nächstes den Memtest machen und mich ggf. um die hoffnungslos veraltete BIOS-Version kümmern (R38 *hust*). Nein, die Zeiten variieren. Antwort meinerseits wird ein bisschen Zeit in Anspruch nehmen, "Produktivsystem" und "Ramtest" sind schwer unter einen Hut zu bringen...

Ist wegen der Länge als Datei angefügt. Über das Intel-Download-Center finde ich keine neueren, dito über die Online-Suche von Microsoft. Schwer einzuschätzen, ich denke aber nicht. Der letzte Bluescreen trat nach einer Uptime von 5,5 Tagen auf. crashdump.txt

Hallo zusammen, ich habe bei einem Kunden einen recht regelmäßig auftretenden Bluescreen (etwa wöchentlich), und weiß keine Abhilfe. Alle Lösungen die ich im Internet gefunden habe beziehen sich lediglich auf virtuelle Umgebungen. Es handelt sich um einen Windows 2008 SP2 mit aktuellen Updates. Der Bluescreen wird ausgelöst durch die intelppm.sys, welche wohl zum Prozessortreiber gehört. Weder bei Microsoft, noch bei Intel kann ich eine neuere Version des Treibers finden. Es handelt sich um einen Xeon Quadcore E5504 auf einem Intel S5500HCV Mainboard. Anbei die Analyse des Minidumps: Windows Longhorn Kernel Version 6002 (Service Pack 2) MP (4 procs) Free x64 Product: Server, suite: TerminalServer SingleUserTS Built by: 6002.18267.amd64fre.vistasp2_gdr.100608-0458 Kernel base = 0xfffff800`01a1d000 PsLoadedModuleList = 0xfffff800`01be1dd0 Debug session time: Tue Dec 7 12:15:37.655 2010 (GMT+1) System Uptime: 7 days 19:19:35.887 Loading Kernel Symbols ................................................................................................................................... Loading unloaded module list ..... Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 124, {0, fffffa800b41a030, be000000, 1009f} Unable to load image \SystemRoot\system32\DRIVERS\intelppm.sys, Win32 error 2 *** WARNING: Unable to verify timestamp for intelppm.sys *** ERROR: Module load completed but symbols could not be loaded for intelppm.sys Probably caused by : intelppm.sys ( intelppm+29ed ) Followup: MachineOwner --------- Sachdienliche Hinweise sind herzlich willkommen ;) Grüße, Simon

Nach nunmehr einer Woche Betrieb ist das Problem wieder da. Scheibar lag es nicht an dem Level1-Block - es wurden aber keine Änderungen am System vorgenommen. Ich hab keine Idee mehr.

Auch bei mir hat sich das Problem mittlerweile gelöst: Outlook sperrt ja potentiell unsichere Dateien - unter anderem auch Verknüpfungen. Das definieren einer Ausnahme für die *.lnk hat war tatsächlich die Lösung! Wie das jetzt aber mit dem eigentlichen Problem zusammenhängt, weiß wohl nur Microsoft...

So, tgl. Neustart ist nun deaktiviert. Nach 3 Tagen und 7 Stunden ist o.g. Phänomen wieder aufgetreten. Der Neustart der einzelnen Dienste hat gezeigt, dass der Fehler offenbar durch den Transportdienst verursacht wird. Irgendwelche Vorschläge zur weiteren Fehlersuche? Grüße, Simon

Wirklich niemand eine Idee? Problem besteht immer noch, eine Idee habe ich nicht mehr wirklich. Identische Software-Kombination (Office 2003 SP3 auf Server 2008 Std SP2 mit RDS) funktioniert bei drei anderen Kunden. -Komplette Neuinstallation von Outlook ist ergebnisslos verlaufen. -Löschen und Vergrößern des Icon-Caches bringt keine Besserung. -Das Verhalten tritt nicht nur im Datei-Speichern Dialog auf, sondern in allen Dialog-Fenstern von OL. Gehe ich zB über Datendatei öffnen und setzte den Filter auf "alle Dateien" friert OL auch ein, sobald ein Icon nicht angezeigt wird. Grüße, Simon

Zwischenstand: Ich konnte den Fehler eingrenzen. Das Einfrieren scheint definitiv mit den Icons zu tun zu haben. Erstaunlich, aber wahr. Wenn ich auf den User-Desktop als Speicherort gehe, sehe ich drei der 10 Icons als undefiniert und Outlook bleibt nach kurzer Zeit (max 1 Sec.) hängen. Entferne ich diese drei Icons vom Desktop, ist der Fehler weg. Dieses Verhalten ist reproduzierbar. In anderen Ordnern verhält es sich mit anderen Dateitypen genauso. Nochmal zur Info: Über den Explorer betrachtet sind alle Icons "normal". Vorschläge? :)

weitere Infos: -Reperaturinstallation von Office führt auch nicht zum Ziel -Über Procman habe ich gesehen, dass die Outlook.exe im Hintergrund durchaus weiter aktiv ist - besonders oft wird HKLM\System\CurrentControlSet\Services\Tcpip\Parameters abgefragt. Ich hatte daher auf ein Problem getippt; "netsh int ip reset" bringt aber keine Veränderung. -Im "Anlagen Speichern"-Dialog werden die entsprechenden Icons der zugeordneten Programme für Dateien nicht oder nur teilweise mit angezeigt, alle Icons sind "weiß". Im Explorer tritt dieses Verhalten nicht auf. Hat noch wer Vorschläge? Gruß, Simon

Ich wärme dieses Thema nochmal auf, da ich vor dem gleichen Problem stehe und keine Lösung finde: Navigiert man über die (oben markierten) Buttons am linken Rand, hängt sich das "Anlagen Speichern"-Fenster komplett auf (Keine Rückmeldung) - benutzt man die obere "Speichern in"-Leiste funktioniert die Navigation zunächst. Klickt man dann ein bisschen durch die Ordnerstruktur kann o.g. Fehler immer noch auftreten. Folgende Beobachtungen oder Lösungsversuche von mir: -Benutzerkonto unabhängig, Fehler auch mit adm. Rechten -Unabhängig vom vorhandsein von Netzlaufwerken -DEP-Ausnahme für OL2003 ist vorhanden -Virenschutz (Spohos) und Win-Defender abschalten bringt keine Veränderungen -Keine Auffälligkeiten im Task-Manager -Zugriff auf gleiche Pfade über z.B. Word "Speichern unter" oder Adobe Reader "Kopie speichern" problemlos möglich. -Windows-Firewall hat keinen Einfluss -Keine Auffälligkeiten in den Prozessen im Benutzerkontext über Procmon sichtbar (Überwacht wurden Registry und FS-Zugriffe aller Prozesse im Besitz von Administrator) -Keine korrespondierenden Einträge in der Ereignisanzeige -OL-Safemode bringt keine Besserung Ansonsten analog zu oben: Windows 2008 Std SP2 mit Office 2003 SP3 und akt. Updates. Hat noch jemand eine Idee?