Symptomy
Po zainstalowaniu aktualizacji zabezpieczeń z listopada 2021 r. (KB5007409) dla programu Microsoft Exchange Server 2019, 2016 lub 2013 przekierowanie aplikacji Outlook w sieci Web (OWA) w środowisku hybrydowym jest uszkodzone.
W przypadku wdrożeń lokalnych międzysietowe przekierowywanie aplikacji OWA może przestać działać w środowiskach, które nie używa protokołu uwierzytelniania opartego na formularzach.
Oczekiwane zachowanie
W przypadku środowisk hybrydowych
Gdy użytkownik, który ma skrzynkę pocztową usługi Exchange Online loguje się do aplikacji OWA lokalnie, otrzymuje adres URL przekierowania, który wskazuje, że https://outlook.office.com.
W przypadku środowisk lokalnych
W przypadku wdrożenia programu Exchange obejmującego wiele witryn usługi Active Directory (AD), które używają różnych adresów URL do uzyskiwania dostępu do aplikacji OWA (na przykład witryna 1 = https://site1.contoso.com/owa, a witryna 2 = https://site2.contoso.com/owa), użytkownik, który ma skrzynkę pocztową w witrynie site1 i loguje się do aplikacji OWA przy użyciu adresu URL "witryna2", zostanie dyskretnie przekierowany do adresu URL "witryna1".
Rzeczywiste zachowanie
W obu oczekiwanych scenariuszach użytkownik nie może się zalogować i w programie Exchange Server 2019 lub 2016 otrzymuje następujący komunikat o błędzie:
Coś poszło nie tak.
W programie Exchange Server 2013 jest wyświetlany następujący komunikat o błędzie:
Składnik zewnętrzny wystąpił wyjątek.
Rozwiązanie
Ten problem został rozwiązany w aktualizacji zabezpieczeń ze stycznia 2022 r.dla systemu Microsoft Exchange Server. Zainstaluj aktualizację zabezpieczeń ze stycznia, aby rozwiązać problem z przekierowywaniem aplikacji OWA wymieniony w sekcji "Objawy".
Jeśli nie możesz zainstalować styczniowej aktualizacji zabezpieczeń, użyj jednej z metod z następnej sekcji, aby rozwiązać problem z przekierowywaniem aplikacji OWA.
Obejście
Obejście 1
Skonfiguruj katalog wirtualny OWA i ECP na wszystkich serwerach front end, których dotyczy problem, w celu używania funkcji FBA.
Obejście 2
Poproś użytkowników z każdej witryny o użycie odpowiedniego adresu URL aplikacji OWA do zalogowania się.
Przykład:
Użytkownicy, którzy mają skrzynkę pocztową w witrynie 2, powinni używać programu https://site2.contoso.com/owa.
Obejście 1
Użytkownicy mogą używać bezpośredniego adresu URL aplikacji Exchange Online OWA w przeglądarce na stronie https://outlook.office.com/owa.
Obejście 2
Uwaga 16. Poniższe obejście dotyczy tylko tych Exchange Server 2019 i Exchange Server 2016.
Exchange Server administratorzy mogą użyć reguły przekierowywania w celu zmodyfikowania adresu URL przekierowywania, aby błąd nie był wyświetlany użytkownikom. Czynności opisane w tym obejście należy skonfigurować na wszystkich serwerach, które obsługują ruch w aplikacji OWA.
Procedura stosowania ponownego adresu URL
-
Otwórz Menedżera usług IIS. W okienku Połączenia rozwiń pozycję <ServerName>, rozwiń pozycję Witryny ,a następnie wybierz pozycję Domyślna witryna sieci Web.
Uwaga W tym kroku zastąp <ServerName> na nazwę serwera. -
W okienku Funkcje (na środku) powinien być wyświetlony adres URL Funkcji Redagowanie w obszarze usług IIS. Jeśli jej nie widzisz, być może ta funkcja nie została zainstalowana. W takim przypadku możesz pobrać pakiet instalacyjny z adresu URL Przepisz: oficjalna witryna usług IIS firmy Microsoft. Ta instalacja nie wymaga ponownego uruchomienia. Spowoduje to jednak ponowne uruchomienie pul aplikacji usług IIS.
Uwaga Upewnij się, że instalujesz wersję X64.Jeśli moduł zmiany adresu URL jest już zainstalowany na serwerach, a serwery są skonfigurowane w podobny sposób przy użyciu ścieżki, możesz skopiować plik Web.config z folderu wwwroot na pierwszym serwerze do innych serwerów po wymuseniu tej zmiany. Zwróć uwagę, że może być konieczne zaczekenie chwilę na ich wprowadzone zmiany na pierwszym serwerze.
-
Kliknij dwukrotnie pozycję ADRES URL Przepisz.
-
W okienku Akcje wybierz pozycję Dodaj reguły.
-
W oknie Dodawanie reguł w obszarze Regułyprzychodzące wybierz pozycję Pusta reguła ,a następnie wybierz przycisk OK.
-
Na ekranie Edytowanie reguły przychodzącej w polu Nazwa wprowadź poprawkę przekierowywania aplikacji OWA 21 listopada.
-
Pozostaw żądany adres URLzgodnie ze wzorcem.
-
Zmień wartość używania na symbole wieloznaczne.
-
W przypadku wzorcawprowadź tekst *owa/Auth/errorFE.aspx*.
-
Pozostaw zaznaczoną opcję Ignoruj sprawę.
-
Wybierz listę Warunki, aby ją rozwinąć, a następnie wybierz pozycję Dodaj.
-
W oknie dialogowym Edytowanie warunku w polu Wprowadzania warunku wprowadź {REQUEST_URI}.
-
Pozostaw sprawdź, czy ciąg wejściowy jest zgodnie ze wzorcem.
-
W przypadku wzorcawprowadź *\u0026*\u0026*\u0026*.
-
Wybierz przycisk OK.
-
W oknie dialogowym Akcja wybierz pozycję Przepisz z listy Typ akcji.
-
W obszarze Właściwości akcji wpolu tekstowym Przepisz adres URL wprowadź następujący kod:
{C:1}&{C:2}&{C:3}&{C:4} -
Wyczyść pole wyboru Dołącz ciąg zapytania.
-
Zaznacz pole wyboru Rejestruj ponownie napisany adres URL.
-
W okienku Akcje wybierz pozycję Zastosuj.
-
Wybierz pozycję Zastosuj, a następnie wybierz pozycję Powrót do reguł.
-
W oknie Adres URL Przepisz zaznacz właśnie utworzoną regułę, a następnie zaewidencjonuj okienko Akcje w obszarze Reguły przychodzące, aby sprawdzić, czy reguła jest włączona.
Ta nowa reguła nie powinna wymagać resetowania usług IIS i powinna zostać w związku z tym w związku z tym wyzowana zaraz po jej włączeniu. Teraz możesz je przetestować przy użyciu aplikacji OWA (przy użyciu konta, które nasyło problem), aby sprawdzić, czy masz oczekiwane przekierowywanie adresu URL.
Włączanie rejestrowania w celu zweryfikowania akcji reguły
Aby sprawdzić oczekiwane zachowanie przekierowywania, możesz użyć śledzenia żądania nieudanego. W tym celu wykonaj następujące czynności:
-
Otwórz Menedżera usług IIS. W okienku Połączenia wybierz pozycję Domyślna witryna sieci Web.
-
W okienku Akcje w obszarze Konfigurowaniewybierz pozycję Śledzenie żądania nie powiodło się.
-
W oknie dialogowym Edytowanie witryny sieci Web z żądaniem śledzenia po awarii wybierz pozycję Włącz.
-
Pozostaw niezmienione wartości w folderze Katalogi Maksymalna liczba plików śledzenia.
-
Wybierz przycisk OK.
-
W środkowym okienku kliknij dwukrotnie pozycję Śledzenie żądania nieudane.
-
W okienku Akcje wybierz pozycję Dodaj.
-
Wybierz pozycję Niestandardowei wprowadź błądFE.aspx.
-
W przypadku kodówstanu wprowadź 100-900, a następnie wybierz pozycję Zakończ.
-
Wyczyść pola wyboru ASP,ASPNETi ISAPI Extension (Rozszerzenie ISAPI).
-
Wybierz pozycję WWW Server. W obszarzeObszary usuń zaznaczenie wszystkich opcji oprócz ostatniej (która powinna być opcja Redaguj).
-
Wybierz pozycję Zakończ.
-
Spróbuj ponownie zalogować się do skrzynki Exchange Online lokalnej aplikacji OWA.
-
W Windows plików na serwerze, którego dotyczy problem, przejdź do folderu C:\inetpub\logs\FailedReqLogFiles.
-
Kliknij dwukrotnie najnowszy .xml pliku. Jeśli śledzenie nie zostało jeszcze wykonane wcześniej, prawdopodobnie plik będzie Fr000001.xml.
-
Zaznaczanie ostatniego wiersza, który powinien być zobacz wszystkie zdarzenia dla żądania.
-
Poszukaj URL_REWRITE_START i URL_REWRITE_END. Sprawdź zawartość między tymi zdarzeniami. Powinny zostać wyświetlony następujące wpisy:
ULE_EVALUATION_START
PATTERN_MATCH
CONDITION_EVALUATION
REWRITE_ACTION REGUŁA EVALUATION_END -
Sprawdź REWRITE_ACTION wartości. We wzorcu \0026 zmiana ciągu "i" powinna być teraz zmieniona na wzorce \0026 (&).
Wdrażanie na wielu serwerach
Po zakończeniu tych procedur na jednym serwerze można łatwo wdrożyć je na wielu serwerach, o ile wcześniej wspomniany moduł ponownego adresu URL jest już zainstalowany na wszystkich Exchange dostępu klienta.
Zalecamy wykonać kopię zapasową bieżącego pliku Web.config na wszystkich serwerach. Jednak po wymuceniu zmian na serwerze, na którym została utworzona reguła, możesz skopiować plik Web.config z folderu C:\inetpub\wwwroot na tym serwerze do tej samej lokalizacji na każdym z pozostałych serwerów. Zwróć uwagę, że może być konieczne zaczekenie na efekt zmian konfiguracji. Aby przyspieszyć ten proces, możesz uruchomić iisreset wiersza.
