증상
2019, 2016 또는 2013에 대한 2021년 11월 보안 업데이트(KB500740 Microsoft Exchange Server 9)를 설치한 후 하이브리드 웹용 Outlook(OWA) 리디렉션이 손상됩니다.
온-프레미스 배포의 경우 사이트 간 OWA 리디렉션은 FBA(양식 기반 인증) 프로토콜을 사용하지 않는 환경에 대한 작업을 중지할 수도 있습니다.
예상 동작
하이브리드 환경의 경우
사서함이 있는 Exchange Online OWA온-프레미스에 로그인하면 해당 사서함을 지정하는 리디렉션 URL을 https://outlook.office.com.
프레미스 환경의 경우
여러 Exchange URL을 사용하여 OWA(예: site 1 = https://site1.contoso.com/owa 및 site 2 =https://site2.contoso.com/owa)에 걸쳐 있는 여러 AD(Active Directory) 사이트에 걸쳐 있는 배포에서는 site1에 사서함이 있으며 "site2" URL을 사용하여 OWA에 로그인하는 사용자가 자동으로 "site1" URL로 리디렉션됩니다.
실제 동작
예상된 두 시나리오 모두에서 사용자는 로그인할 수 없습니다. 2019 또는 2016에서 Exchange Server 오류 메시지를 수신합니다.
문제가 있습니다.
사용자는 2013년 Exchange Server 오류 메시지를 수신합니다.
외부 구성 요소가 예외를 throw했습니다.
해결 방법
이 문제는 에 대한 2022년 1월 보안 업데이트에서 Microsoft Exchange Server. "증상" 섹션에 언급된 OWA 리디렉션 문제를 해결하려면 1월 보안 업데이트를 설치합니다.
1월 보안 업데이트를 설치할 수 없는 경우 다음 섹션의 메서드 중 하나를 사용하여 OWA 리디렉션 문제를 해결합니다.
해결 방법
해결 방법 1
FBA를 사용하도록 영향을 받는 모든 프런트 엔드 서버에서 OWA 및 ECP 가상 디렉터리를 구성합니다.
해결 방법 2
각 사이트의 사용자에게 적절한 사이트별 OWA URL을 사용하여 로그인하도록 요청합니다.
예:
사이트 2에 사서함이 있는 사용자는 을 사용하여 https://site2.contoso.com/owa.
해결 방법 1
사용자는 의 브라우저에서 Exchange Online OWA에 대한 직접 URL을 https://outlook.office.com/owa.
해결 방법 2
참고 다음 해결 사항은 2019 및 Exchange Server 2016에 Exchange Server 적용됩니다.
Exchange Server 관리자는 리디렉션 규칙을 사용하여 사용자에게 오류가 나타나지 않을 수 있도록 리디렉션 URL을 수정할 수 있습니다. 이 해결 방법을 위한 단계는 OWA 트래픽을 처리하는 모든 서버에서 구성해야 합니다.
URL 다시 를 적용하는 단계
-
IIS 관리자를 를 연결 창에서<ServerName> 확장한 다음 기본 웹 사이트 를 선택합니다.
참고 사항 이 단계에서는 <ServerName> 서버 이름으로 바 대체합니다. -
기능(가운데) 창에 IIS 영역에 URL 다시 덮기 기능이 표시됩니다. 이 기능이 표시되지 않는 경우 기능이 설치되지 않을 수 있습니다. 이 경우 URL 다시 덮기: 공식 Microsoft IIS 사이트 에서 설치 패키지를 다운로드할 수 있습니다. 이 설치에는 다시 시작이 필요하지 않습니다. 그러나 IIS 앱 풀을 다시 시작합니다.
참고 사항 X64 버전을 설치해야 합니다.URL 다시 써기 모듈이 서버에 이미 설치되어 있으며, 경로 지정을 사용하여 서버가 유사하게 구성된 경우 변경한 후 첫 번째 서버의 wwwroot Web.config 폴더에서 다른 서버로 복사할 수 있습니다. 변경 내용이 첫 번째 서버에 적용될 때까지 잠시 기다려야 할 수 있습니다.
-
URL 다시 를 두 번 클릭합니다.
-
작업 창에서 규칙 추가 를 선택합니다.
-
규칙 추가 창의 인바운드 규칙아래에서 빈 규칙을 선택한 다음 확인 을 선택합니다.
-
인바운드 규칙 편집 화면의 이름 상자에 Nov21 OWA 리디렉션 수정 을 입력합니다.
-
요청된 URL을 패턴과 일치하게 떠날 수 있습니다.
-
와일드카드에 사용의값을 변경합니다.
-
패턴의경우 *owa/Auth/errorFE.aspx*를 입력합니다.
-
무시 대소문자 선택을 떠날 수 있습니다.
-
조건 목록을 선택하여 확장한 다음 추가를 선택합니다.
-
조건 편집 대화 상자의 조건 입력 상자에{REQUEST_URI}를 입력합니다.
-
입력 문자열이 패턴과 일치하는지 확인을 떠날 수 있습니다.
-
패턴의경우 *\u0026*\u0026*\u0026*을 입력합니다.
-
확인을 선택합니다.
-
작업 대화 상자에서 작업 유형 목록에서 다시 를 선택합니다.
-
작업 속성의에서 다시 작성 URL 텍스트
상자에 {C:1}&{C:2}&{C:3}&{C:4}을 입력합니다. -
쿼리 문자열 추가 확인란을 선택 취소합니다.
-
로그 다시 를 입력한 URL 확인란을 선택합니다.
-
작업 창에서 적용을 선택합니다.
-
적용 을선택한 다음 규칙으로 돌아가기 를 선택합니다.
-
URL 다시 작성 창에서 방금 만든 규칙을 선택한 다음 인바운드 규칙 아래에 있는 작업 창에서 규칙이 활성화되어 있는지 확인합니다.
이 새 규칙은 IIS 재설정을 요구하지 말아야 합니다. 이 규칙은 사용하도록 설정하는 즉시 적용됩니다. 이제 OWA(문제를 재현한 계정 사용)를 사용하여 예상되는 URL 리디렉션을 확인할 수 있습니다.
로깅을 사용하여 규칙 작업을 확인할 수 있습니다.
예상 리디렉션 동작을 확인하기 위해 실패한 요청 추적을 사용할 수 있습니다. 이렇게 하려면 다음과 같이 하십시오.
-
IIS 관리자를 를 연결 창에서 기본 웹 사이트 를 선택합니다.
-
구성 아래 작업 창에서 실패한요청 추적을 선택합니다.
-
웹 사이트 편집 실패 요청 추적 설정 대화 상자에서 사용 을 선택합니다.
-
디렉터리 및 최대 추적 파일의 수에 대한 값을 변경하지 않습니다.
-
확인을 선택합니다.
-
가운데 창에서 실패한 요청 추적 을 두 번 클릭합니다.
-
작업 창에서 추가를 선택합니다.
-
사용자 지정을 선택하고 errorFE.aspx 를 입력합니다.
-
상태 코드의 경우100-900을입력한 다음 완료를 선택합니다.
-
ASP, ASPNET및 ISAPI 확장 확인란을 선택 취소합니다.
-
WWW Server를 선택합니다. 영역에서마지막 옵션(다시 를 다시 를 사용)을 모두 선택을 선택하지 않습니다.
-
완료를 선택합니다.
-
다시 시도하여 Exchange Online OWA의 사서함에 로그인합니다.
-
영향을 Windows 탐색기에서 C:\inetpub\logs\FailedReqLogFiles로 이동합니다.
-
최신 파일 .xml 클릭합니다. 앞에서 추적을 완료하지 않은 경우 이 파일이 Fr000001.xml.
-
요청에 대한 모든 이벤트를 표시해야 하는 마지막 줄을 선택합니다.
-
URL_REWRITE_START 및 URL_REWRITE_END. 이러한 이벤트 사이에 있는 콘텐츠를 검사합니다. 다음 항목이 표시 됩니다.
ULE_EVALUATION_START
PATTERN_MATCH
CONDITION_EVALUATION
REWRITE_ACTION RULE EVALUATION_END -
값을 REWRITE_ACTION 합니다. 다시 는 이제 모든 \0026 패턴이 앰퍼 랜드(&)로 변경됩니다.
여러 서버에 배포
한 서버에서 이러한 절차를 완료한 후 이전에 언급한 URL 다시 작성 모듈이 모든 클라이언트 액세스 서버에 이미 설치되어 있는 한 여러 서버에 쉽게 Exchange 수 있습니다.
모든 서버에서 현재 Web.config 백업하는 것이 좋습니다. 그러나 규칙을 만든 서버에서 변경한 후 해당 Web.config C:\inetpub\wwwroot 폴더에서 다른 서버의 동일한 위치로 복사할 수 있습니다. 구성 변경이 적용될 때까지 잠시 기다려야 할 수 있습니다. 프로세스를 빠르게 진행하기 위해 명령 명령을 iisreset 있습니다.
