Outlook không thể kết nối với cụm Exchange 2013 cân bằng tải thông qua Direct Access 2012 R2

Chúng tôi có cụm Exchange 2013 SP1 cân bằng tải, chạy MAPI qua HTTP.

Kết nối máy khách trong mạng riêng của chúng tôi hoạt động tốt, trong khi máy khách được kết nối qua Truy cập trực tiếp không kết nối. Nhật ký Outlook trên máy khách hoàn toàn không có lỗi.

Máy chủ Direct Access đang chạy 2012 R2, các máy khách đều là Windows 8.1. Mọi thứ đều được vá.

Tôi đã tìm kiếm như điên trong vài tuần qua và những lần truy cập thú vị duy nhất tôi nhận được là về việc TMG 2010 (UAG) lọc ra các yêu cầu do thay đổi IP nguồn (bộ cân bằng tải trao đổi). Có một Điều cơ sở kiến thức (982604) mô tả điều này và một bài đăng trên blog khá nặng nề về vấn đề từ hỗ trợ hàng đầu, nhưng thật đáng buồn là tập lệnh không hoạt động trên máy chủ của chúng tôi vì nó không phải là TMG và đó là Windows Server 2012 R2 ..

Tôi đang thua lỗ ở đây. Tôi sẽ đưa ra câu hỏi này một tuần, sau đó tôi sẽ nêu ra một trường hợp hỗ trợ hàng đầu với Microsoft.

— tạm dừng
nguồn

Ý bạn là MAPI qua HTTP? Phiên bản nào của Outlook? Bạn có thể đăng chi tiết hoặc ảnh chụp màn hình từ DA client Outlook, hiển thị Trạng thái kết nối và Tự động cấu hình email thử nghiệm không? Bạn đang sử dụng gì để cân bằng tải?

— mfinni

@mfinni Xin lỗi, tất nhiên MAPI :-) Outlook 2013 SP1 với các bản vá mới nhất. Cân bằng tải của chúng tôi là KEMP VLM-1000. Tôi sẽ cố gắng đăng ảnh chụp màn hình, nhưng cài đặt văn phòng là tiếng Na Uy .. có lẽ sẽ không có nhiều ý nghĩa với bạn?

— pauseka

Chà, điều chúng tôi đang tìm kiếm là nếu khách hàng đang cố gắng kết nối với URL Tự động phát hiện nội bộ (như thường lệ, sử dụng DA) hoặc bên ngoài, điều này có thể thất bại và có thể gây ra sự cố của bạn. Rất nhiều trong số đó có thể đi xuống cấu hình DNS của bạn. Nếu tự động phát hiện hoạt động chính xác, nhưng một số phần của kết nối không thành công.

— mfinni

@mrfinni Tôi đã kiểm tra điều này, vì chúng tôi không sử dụng đường hầm bắt buộc. Chúng tôi có một DNS tách não với không gian tên duy nhất, vì vậy tất cả các miền bên trong và bên ngoài đều được tạo đường hầm rõ ràng. Trong thực tế, điều này có nghĩa là khách hàng không thể giải quyết bất kỳ mục DNS bên ngoài nào của chúng tôi. Tôi sẽ cài đặt phiên bản tiếng Anh của Outlook khi tôi có thời gian ..

— pauseka

EvanAnderson: Tôi sẽ cung cấp ảnh chụp màn hình và nhật ký vào cuối ngày hôm nay. Aceth: Xin lỗi, đó là SP1 (được làm rõ trong Q). longneck: Nó không tạo ra sự khác biệt. Tôi biết rằng LB viết lại IP nguồn (nat) và tôi nghĩ rằng đây là nơi nó bị hỏng ..

— pauseka

Câu trả lời:

Tôi đã gặp phải loại vấn đề này trước đây (trên giải pháp dựa trên HAproxy), trong trường hợp của tôi, đó là Exchange 2010 và Máy chủ ISA 2006 có bật bộ lọc RPC. Chúng tôi đã vô hiệu hóa bộ lọc RPC và ngày hạnh phúc trở lại ...

Tôi đã làm một chút tìm kiếm xung quanh mình và tôi tìm thấy điều này:

http://geek.martinwahlberg.com/probols-USE-forced-tunneling-mode-in-directaccess

Điều này gợi ý các vấn đề với Outlook, DirectAccess và chế độ đường hầm không bao giờ được giải quyết (ngoài khả năng hack khách hàng có thể xảy ra ..) vì vậy tôi đã tự hỏi liệu đó có phải là điều tương tự không. anh ấy đã nhận được ID trường hợp của mình trong các bình luận vì vậy nếu bạn đi đến MS, bạn có thể tăng thêm một chút trọng lượng cho trường hợp của mình.

— Aaron Tây
nguồn

Tôi cũng tìm thấy rất nhiều bài viết về bộ lọc RPC và ISA, nhưng thật đáng buồn là chúng tôi không sử dụng. Môi trường của chúng tôi hiện chạy HTTP MAPI thuần túy, do đó không nên có bất kỳ RPC nào liên quan. Bây giờ tôi đã từ bỏ toàn bộ vấn đề, ngoại trừ lưu lượng Outlook từ đường hầm DA.

— pauseka

Bản dựng nào của Exchange 2013 là các máy chủ CAS đang chạy? Tôi không quen thuộc với "KEMP VLM-1000" nhưng tôi đã tải trao đổi cân bằng 2013 bằng NGINX và gặp phải vấn đề tương tự với Exchange 2013 SP1 trước khi RPC không hoạt động cân bằng tải qua HTTPS.

Trong phiên bản Exchange 2013 SP1 gần đây, họ đã triển khai MAPI trên HTTPS nhằm giải quyết vấn đề này - Tôi chưa kiểm tra nó nhưng liên kết kỹ thuật ở bên dưới

Trao đổi 2013 SP1 - MAPI qua HTTPS

Hãy cho tôi biết làm thế nào bạn tiếp tục khi tôi chưa hoàn thành việc này khi tôi chỉ sử dụng haproxy để cân bằng tải TCP giữa các máy chủ CAS.

— Rhys Evans
nguồn

Chào. Chúng tôi đang sử dụng MAPI trên HTTPS trên SP1 (và RPC trên HTTPS cho khách hàng trước năm 2013). Điều này đã được bao phủ trong câu hỏi.

— pauseka

Chỉ bởi vì bạn vừa chỉnh sửa nó! haha Bạn đã thực hiện các bước được mô tả trong liên kết? Bạn đã thử kiểm tra và tìm kiếm trong các tệp nhật ký mapi trao đổi ..% ExchangeInstallPath% Logging \ MAPI Client Access \% ExchangeInstallPath% Logging \ HttpProxy \ Mapi \

— Rhys Evans

Nếu có thể, hãy thử hoán đổi bộ cân bằng tải của bạn cho NGINX ( Turnkeylinux.org/nginx-php-fastcgi - đã được cài đặt và cấu hình độc đáo) thêm một cấu hình mới để trao đổi. Công cụ tôi dự định triển khai cho MAPI qua HTTP dựa trên .. gist.github.com/taddev/7275873

— Rhys Evans

hoặc nếu bạn không cần một bộ cân bằng tải dựa trên HTTP, hãy thử sử dụng HAProxy, đó là những gì tôi đã làm và hoạt động tốt.

— Rhys Evans

Thay thế bộ cân bằng tải của chúng tôi chỉ vì kết nối Outlook bị phá vỡ DirectAccess không phải là một lựa chọn .. Chúng tôi đã trả rất nhiều tiền cho nó và nó cân bằng mọi thứ khác mà chúng tôi chạy (trang trại RDS, máy chủ cổng, proxy, v.v.) một cách hoàn hảo. Chỉ dưới DA mà Outlook phá vỡ. Tôi đã không kiểm tra các nhật ký đó, vì vậy tôi sẽ làm điều đó sau hôm nay khi tôi chạy thử nghiệm mới ở nhà.

— pauseka