자동 검색 outlook 2016 구현

요약

자동 검색은 연결 된 서버에 대 한 구성 정보를 가져오려면 Outlook을 사용 하는 기능입니다. Exchange 서버와 Outlook 2016, 자동 검색은 단일 지점의 구성 정보에 대 한 진실 간주 됩니다 구성 되어야 하 고 완전 하 게 작동 하는 outlook 제대로 작동 하 고 있습니다. 여기에서는 간편 실행 버전 Outlook 2016의 현재 채널에서 자동 검색의 구현에 설명합니다. Office 365 클라이언트 채널 버전에 대 한 자세한 내용은 다음 Microsoft 웹 사이트를 참조 하십시오.

Office 365 클라이언트에 대 한 업데이트 채널 릴리스 버전 및 빌드 번호

Office 365 클라이언트 업데이트 채널 릴리스

추가 정보

자동 검색 시간

다음 시간에 자동 검색을 실행합니다.

  1. 동안 계정 만들기.

  2. Exchange 웹 서비스를 제공 하는 Url로 변경 사항을 수집 간격 (OOF, 가용성 서비스 등)를 제공 합니다. 이 프로세스가 끝나면 다른 try 한 시간 후 이루어집니다. 시도가 성공 하지 않으면 5 분 후 다음 try가 이루어집니다. 모든 Microsoft Office 응용 프로그램에서 사용 하는 백그라운드 작업 인프라 때문에 각 시도 25% 만큼 지연 가능성이 있습니다.

  3. 특정 연결 실패에 대 한 응답입니다. 다양 한 시나리오에서 연결 시도가 실패 하면 Outlook에서 연결 문제를 해결 하려고 새로운 설정을 검색 하는 자동 검색 작업을 시작 합니다.

  4. 때 다른 응용 프로그램이 MAPI를 사용 하 여 호출 합니다. MAPI에 대 한 자세한 내용은 다음 MSDN 문서를 참조 하십시오: Outlook MAPI를 참조합니다.

자동 검색 효율성

사용자 계정 이름 (UPN)를 사용 하 여 자동 검색 과정을 지원 하기.

도메인에 가입 된 컴퓨터에서 Outlook 자동 검색 프로세스를 시작 하기 위해 사용자의 UPN을 알고 있어야 합니다. Windows에 로그온 하는 경우에 UPN 사용 Outlook에서 직접 액세스를 UPN 로그온 자격 증명에서. 하지만 Outlook 사용자에 대해 같은 자격 증명에 밖에 있으면 로그인 창에 사용자 사용 하 여 도메인 \ 사용자. UPN을 가져오려면 Outlook 먼저 찾아야 사용자 디렉터리에 있습니다. Outlook이이 조회 조회를 추적 합니다 요청 합니다. 복잡 한 환경에서 다양 한 결과 발견 하기 전에 연락을 Dc 발생할 수 있습니다. Outlook에서 사용자의 UPN을 발견 한 후 프로필에는 값이 캐시 하 고이 사용자에 대 한 조회를 다시 발생 하지 않습니다.

이러한 문제를 방지 하려면 사용자 도메인 \ 사용자 이름 대신 UPN을 사용 하 여 로그온 할 수 있습니다.

ITAR 고려 사항

Microsoft Office 365는 ITAR의무를 사용 하 여 고객을 지원할 수 있는 기능을 제공 합니다. Outlook의 자동 검색 기능을 사용 하면 환경에서이 기능 집합 정책 설정 및 자동 검색에 사용 되는 서비스 끝점 군주 클라우드 요구 사항 준수를 보장 하는 동작을 포함 합니다. 특히 Office 365 특정 단계에서 (단계 4와 단계 11) 자동 검색 프로세스에서 나열 된 정책 제어를 자동 검색 과정에서 적절 한 서비스 끝점을 사용 하는 확인 하십시오 수 있습니다.

자동 검색 프로세스

Outlook에 자동 검색 정보가 필요 할 때마다 구성 설정을 포함 하는 XML 페이로드를 검색 하기 위해 일련의 단계를 순서 대로 사용 합니다. 그룹 정책 개체 (GPO)를 사용 하 여 여러이 단계를 제어할 수 있습니다 및 GPO 값 단계 설명에 포함 됩니다.

1 단계: 다시 시작 시나리오에 대 한 확인

Outlook이 실행 되는 동안 두 번째 계정을 추가 하는 경우와 같은 일부 경우에 페이로드가 자동 검색 Outlook 클라이언트를 다시 시작 하는 동안 사용할 로컬 파일에 캐시 됩니다. 시나리오 단계 도중 이들 중 하나는 Outlook을 알려 주는 몇 가지 특별 한 "부팅" 정보에 대 한 레지스트리를 확인 하는 첫 번째 자동 검색을 다시 시작 및 자동 검색 페이로드 특수 로컬 파일에서 읽을 수 있습니다. 이것은 드문 경우 이며 일반 자동 검색 문제의 원인이 되지 일반적 으로입니다. 이 단계에 대 한 Outlook 결정이 특별 한 부팅 시나리오에서 하 고 시도가 실패 하면 전체 자동 검색 자동 검색 XML 데이터를 검색 하려면 시도가 실패 합니다. 추가 단계 없이 시도 됩니다.

이 단계에 대 한 특정 정책 컨트롤이 있습니다.

2 단계: 로컬 데이터 기본 설정 확인

Outlook 구성에 사용 되는 특정 자동 검색 XML 파일을 배포 하는 관리자에 게 GPO를 제공 합니다. 관리자가이 레지스트리 값을 배포 하 고 있는 autodiscover.xml 파일의 시드 Outlook 자동 검색 페이로드를이 파일에서 읽습니다. 다시는 드문 경우 이며 일반적으로 제네릭의 원인이 아닌 자동 검색 문제. 이 단계는 페이로드를 검색 하지 않습니다, 경우 3 단계로 이동 합니다. 자동 검색 XML에 대 한 자세한 내용은 다음 TechNet 문서를 참조: Outlook 2010에서 사용자 계정을 자동으로 구성 하려면참고Outlook 2010에 대 한이 문서를 만들었습니다. 그러나 이후 버전의 Outlook에 여전히 관련 됩니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: PreferLocalXML.

3 단계: 마지막으로 알려진 좋은 (LKG) 데이터 확인

자동 검색을 성공적으로 모든 단계를 통해 XML 페이로드를 검색, 페이로드 "마지막으로 성공한" 구성으로 로컬로 캐시 될 수 있습니다. 첫 번째 성공적으로 일반적으로 자동 검색 페이로드를 가져올 방법은이 마지막으로 알려진된 양호한 파일에서. 마지막으로 알려진된 좋은 XML 파일의 경로 Outlook 프로필에서 발생합니다. LKG 단계 구성을 기본 사서함 검색에 사용 됩니다. 기본이 아닌 사서함에 대 한 자동 검색 조회 인지 (공용 폴더를 대체 하 고, 대리자 사서함, 그룹 및 등), LKG 단계는 자동으로 생략 합니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 4 단계로 이동 합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeLastKnownGoodURL.

4 단계: O365 우선 순위 확인

제공 되는 사용자 계정 Office 365에서 가져온 것인지 여부를 결정 하는 휴리스틱 집합을 사용 됩니다. Outlook O365 사용자는 자신 있게 결정 알려진된 O365 끝점 (일반적으로 https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 또는 https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml)에서 자동 검색 페이로드를 검색 하려면 시도가 이루어집니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 5 단계로 이동 합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다.

ExcludeExplicitO365Endpoint.

ITAR 고려 사항

기본적으로 Outlook 자동 검색 페이로드를 검색 하려면 알려진된 끝점을 쿼리 합니다. 기존 정책을이 단계를 건너뜁니다 유효 하도록 하 고 끝점을 시도 하지 않고 5 단계로 이동 하 여 사용할 수 있습니다. 또한 새 정책을 적절 한 Url을 검색할 자동 검색 페이로드를 검색 하기 위해 중앙 Office 365 구성 서비스를 쿼리하여 Outlook을 지시 하는. 개념적으로 과정은 다음과 같습니다.

  1. 새 정책으로 설정 합니다.

  2. 자동 검색 프로세스의 4 단계 동안 Outlook Office 365 구성 서비스를 쿼리합니다.

  3. 서비스 결정 (있는 경우)는 특수 ITAR 필요로 지정된 된 사용자에 적용 됩니다 및 upn 도메인 정보를 사용 하 여 해당 사용자에 대 한 적절 한 Url을 반환 합니다.

  4. Outlook에서 페이로드 자동 검색 서비스에서 제공 된 Url에서 검색 하려고 합니다.

Office 365 구성 서비스를 사용 하는 새로운 기능에 대 한 정책 제어 값은 EnableOffice365ConfigService입니다.

참고

현재 빌드 16.0.9327.1000, EnableOffice365ConfigService 정책은 더 이상 사용 됩니다.

5 단계: SCP 데이터 확인

컴퓨터를 도메인에 가입한 Outlook 자동 검색 XML의 경로 반환 하는 서비스 연결 지점 데이터를 검색 하는 LDAP 쿼리를 수행 합니다. 그런 다음 자동 검색 페이로드를 검색 하려고 하는 SCP 조회에서 반환 되는 각 URL에 시도가 이루어집니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 6 단계로 이동 합니다. SCP에 대 한 자세한 내용은 다음 MSDN 문서를 참조 하십시오: 연결 지점 서비스를 사용 하 여 게시합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeScpLookup.

6 단계: 루트 도메인 확인

이 단계에서는 Outlook https://<domain>/autodiscover/autodiscover.xml 형식의 초기 주소의 도메인 이름 URL을 빌드하고 결과 URL에서 페이로드를 검색 합니다. 루트 도메인 자동 검색을 사용 하도록 구성 되지 않은 때문에 Outlook은 의도적으로 시도 검색 하는 동안 발생 하는 모든 인증서 오류가 지정. 이 단계 페이로드를 검색 하지 않으면 7 단계로 이동 합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeHttpsRootDomain.

7 단계: 검사 자동 검색 도메인

이 단계에서는 Outlook https://autodiscover.<domain>/autodiscover/autodiscover.xml 형식의 초기 주소의 도메인 이름 URL을 빌드하고 결과 URL에서 페이로드를 검색 합니다. 일반적으로 자동 검색 데이터에 대 한 기본 URL 이기 때문에 Outlook에 시도 검색 하는 동안 발생 하는 모든 인증서 오류가 무음 하지 않습니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 8 단계로 이동 합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeHttpsAutoDiscoverDomain.

로컬 데이터를 8 단계: 확인

2 단계에서 Outlook 기본 설정으로 자동 검색 페이로드를 구체적으로 확인 하는 정책을 관리자 배포 여부를 확인 했습니다. 정책이 없는 곳에는 이전 단계에서 페이로드를 검색 하지 않은 경우, Outlook 이제 장소에 PreferLocalXML 설정 하지 않고도 로컬 파일에서 페이로드를 검색할 시도 합니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 9 단계로 이동 합니다.  이 단계에 대 한 정책 제어에 없는 경우

9 단계: HTTP 리디렉션에 대 한 확인

이 단계에 대 한 Outlook 자동 검색 도메인 URL로 요청을 보냅니다 (http://autodiscover. < 도메인 > / autodiscover/autodiscover.xml) 및 리디렉션 응답을 테스트 합니다. 실제 자동 검색 XML 페이로드를 반환 하 고 이동이 아닌 Outlook 보안 (http) 없이 검색 되므로 실제 자동 검색 XML 응답을 무시 합니다. 응답이 올바른 리디렉션 URL을 경우 Outlook 해당 리디렉션을 따르고 새 URL에서 XML 페이로드를 검색 하려고 시도 합니다. 또한 outlook는 인증서 검사를이 단계에서 문제가 될 수 있는 Url로 리디렉션을 수행 합니다. 이 단계는 페이로드를 검색 하지 않습니다, 경우 10 단계로 이동 합니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeHttpRedirect.

10 단계: SRV 데이터 확인

이 단계에 대 한 Outlook "< 도메인 이름 > _autodiscover._tcp."에 대 한 DNS 쿼리를 만들고 https를 프로토콜로 사용 하는 첫 번째 레코드에 대 한 검색 결과 반복 합니다. 그런 다음 outlook 해당 URL에서 페이로드를 검색 하려고 합니다. 이 단계 페이로드를 검색 하지 않으면 11 단계로 이동 합니다.이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeSrvRecord.

11 단계: O365로 안전 확인

위의 단계를 모두 페이로드를 반환 하지 않은 경우 Outlook O365 끝점에 마지막 시도 도움이 될 지 여부를 결정 하는 덜 제한적인 휴리스틱 집합을 사용 합니다. Outlook 시도 가치가 결정은 한 O365 계정 경우 알려진된 O365 자동 검색 끝점을 시도 합니다. 이 시도 4 단계 처럼 동일한 대상 Url을 사용 하는 자동 검색 프로세스는 이후와 최후의 수단으로 시도 되는 사실에만 다릅니다. 이 단계에 대 한 정책 제어 값은 다음과 같습니다: ExcludeExplicitO365Endpoint.

ITAR 고려 사항

Outlook이 단계로 가져옵니다 페이로드에서 자동 검색을 성공적으로 검색 되지 않은 경우, 잘 알려진 끝점을 Office 365를 시도해 야 하는지 여부를 확인 합니다. 두 개의 테스트가 수행 됩니다. 먼저 사서함 소비자 계정 (예: outlook.com) 이면 잘 알려진 끝점 시도 됩니다. 둘째, 사서함 ITAR 요구 사항을 갖고 있지 않은 도메인에 속하는 것으로 결정 되는 잘 알려진 끝점 시도 됩니다. 상업 및 ITAR 요구 사항이 도메인에 속한 사서함 확인 잘 알려진 Office 365 끝점 시도 되지 않았습니다. 나중에 시리즈에서 11 단계로 이동할 수 있습니다 동일한 논리에 Office 365 구성 서비스를 호출 하 고 4 단계. 이 변경 될 때이 문서 새 프로세스 단계를 반영 하도록 업데이트 됩니다.

리디렉션 처리

자동 검색 프로세스 섹션에서 9 단계는 안전 하지 않은 리디렉션 데이터를 처리 하는 명시적 단계입니다. 다른 보안 단계를 자동 검색 XML 페이로드를 검색 하려는 시도 대 한 끝점에서 가능한 응답은 리디렉션 응답. 이 응답에 페이로드를 검색 하기 위해 새, 다른 URL로 리디렉션하는 Outlook 알려 줍니다. 또한 리디렉션 데이터 자동 검색 시도 대 한 대상 주소로 사용 하 여 새, 다른 이메일 주소를 포함할 수 있습니다. Outlook에서는 세 가지 별도 응답이 "리디렉션 응답".

  • 새 URL 사용 하 여 HTTP 상태 코드 (301, 302)

  • HTTP 상태 코드 200, 하지만 다른 URL로 이동 하도록 지정 하는 XML 페이로드를 사용 하 여

  • HTTP 상태 코드 200, 하지만 다른 smtp 주소를 대상 주소로 사용 하도록 지정 하는 XML 페이로드를 사용 하 여.

1과 2의 경우에서 Outlook 프로토콜은 https 새 URL에서 XML 자동 검색에 검색을 시도 합니다. 않음 (http) Url 시도 되지 않습니다. 또한 새 URL에 https 인 경우에 확인 인증서 정보를 측정 하는 추가적인 보안을 제공 합니다. 3 사례에 대 한 Outlook 처음부터 전체 자동 검색 프로세스를 시작합니다.  만약 모든 단계 (1-11)를 새 전자 메일 주소를 사용 하 여 모든 성공 없이 시도 Outlook 원본 전자 메일 주소를 반환, 5 단계로 이동 그리고 원래 주소를 사용 하 여 XML 페이로드를 검색 하려고 계속.

예외

자동 검색 프로세스 섹션의 단계는 Outlook 자동 검색 페이로드를 얻으려고 시도 하는 방법에 대 한 일반 규칙. 다양 한 최적화 기능 및 프로세스를 약간 변경 될 수 있는 뛰어난 시도 됩니다. 예를 들어,는 새로운 계정 생성을 수행할 때 Outlook 내부적으로 서 생략 하는 (확인) 마지막으로 알려진 좋은 (LKG) 데이터에 대 한 3 단계 마지막 알려진된 좋은 항목을 아직 사용할 수 없습니다.  마찬가지로, 시도 현재의 구성 정보를 사용 하 여 오류가 트리거된, 다음 Outlook 의도적으로 하려는 경우 자동 검색을 다시 및 LKG 정보를 사용 하지 때문 아마도 마지막으로 알려진된 좋은 정보에는 오류가 발생 했습니다.

정책 제어

정책 값을 자동 검색 프로세스를 정의 된 정책 기반 레지스트리 값 또는 값 정책 기반-섹션 수 있습니다.  정책 키를 수동으로 구성 하거나 GPO를 통해 배포 될 경우 설정 하지 않은 정책 키 보다 우선 합니다. 정책 비 키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 정책 키: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover 각 값이 DWORD형식입니다. PreferLocalXML 1 로 설정 집합 에 프로세스의 단계를 설정 하는 Outlook으로 컨트롤 값에서 다릅니다.  나머지 값을 1 로 설정 하도록 지정 턴 오프 또는 관련된 단계를 무시 합니다. 예를 들어, Outlook 프로세스의 6 단계를 수행할 필요가 설정 ExcludeHttpsRootDomain 값을 1 로 설정 합니다.

추가 레지스트리 컨트롤

Outlook에서는 자동 검색 프로세스에 영향을 줄 수 있는 몇 가지 추가 레지스트리 기반 구성 옵션을 제공 합니다.

Office 365 구성 서비스를 사용 하 여

키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 값: EnableOffice365ConfigService 기본값: 0 데이터: 적절 한 자동 검색 Url을 검색할 Office 365 구성 서비스를 호출 하는 Outlook 강제로 1로 DWORD 데이터를 설정 합니다.

HTTP 시간 제한 설정

키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 값: 시간 초과 기본값: 25 초 최소: 10 초 최대: 120 초

정보: 지정한 제한 시간 WinHttpSetTimeouts 설정으로 사용 됩니다. 지정 된 데이터는 WinHttpSetTimeouts API의 모든 4 개의 매개 변수가 전달 됩니다. 연결 되지 않은 하기 위해 HTTP 요청을 제한 시간이 빠름, 전체적인 성능이 향상 됩니다 있습니다. 설정을은 기본값인 25 초 보다 큰 값으로 시간 제한 설정을 늘려 성공 25 초 보다 오래 걸리는 하는 HTTP 요청을 사용 하는 수 없습니다. Mapi/Http 프로토콜 제어

키: HKEY_CURRENT_USER\Software\Microsoft\Exchange 값: MapiHttpDisabled 기본값: 0 데이터: 1 = 프로토콜은 사용할 수 없습니다. 0 = 프로토콜이 활성화 되어

정보:이 값이 되지 않으면 자동 검색 키 아래에 있습니다. 이 설정은 Outlook Mapi/Http 프로토콜 스택을 사용 하 여 Exchange에 연결을 시도할 수 있는지 여부를 제어 하는 일반입니다. 이 프로토콜을 사용 하지 않도록 설정 하려면 2016 Outlook의에서 기본은 아닙니다. 이렇게 하면 특수 헤더를 추가 하는 자동 검색 프로세스를 사용 하 고 있습니다 (X-MapiHttpCapability:1)을 발견할 수 Mapi/Http 프로토콜 설정을 평가 하 고 처리할 수 있도록 처리 합니다. 레거시 인증 협상 제어

키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC 값: AllowNegoCapabilityHeader 기본값: 0 데이터: 1 = 헤더를 추가 합니다. 0 = 헤더에 추가 되지 않습니다

정보: 참고 자동 검색 키이 값이 아닙니다. 이 설정은 협상 인증 헤더를 http 요청에 추가 됩니다 여부를 제어 합니다. 헤더의 내용이 클라이언트 컴퓨터의 인증 기능에 따라 달라 집니다. 예제 머리글에는 있을 수 있습니다: "X-Nego-역량: 협상, NTLM, Kerberos, pku2u MSOIDSSP". 레지스트리 값이 및 헤더를 추가 하는 경우 거의 모든 최신 인증 스택의 사용 하 고 매우 tAodiscover 프로세스 음수 또는 양수 방식에 영향을 인증서 오류 처리

키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 값: ShowCertErrors 기본값: 0 데이터: 1 = 쇼 인증서 경고/오류; 0 = 인증서 경고 표시 안 함

정보:이 값이 오류 및 http 작업을 수행 하는 경우 수신 된 경고를 처리할 인증서 하는 방법을 제어 합니다. 일반적인 경우에이 설정을 사용 하는 경우 Outlook은 인증서 오류나 경고를 표시 하는 보안 대화 상자를 사용 하 여 묻고 확인 하는 데 사용할 수 있지만 outlook (자동 검색 프로세스 섹션의 6 단계), 어떤 경우에는이 설정을 재정의할 수 있습니다 또는 Http 요청을 취소 합니다. 세 특정 인증서 오류를 무시 하 고 http 요청을 다시 시도 하는 outlook 사용자를 결정할 수 있습니다.

  • 인증서 속성에 대 한 날짜를 사용 하 여 문제가 있으면-WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID

  • WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID-일반 이름의 인증서 속성에 문제가 있습니다.

  • WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA-인증 기관 인증서 속성에는 문제가 있습니다. 이러한 세 가지 인증서 오류 상태에 대 한 자세한 내용은 WINHTTP_STATUS_CALLBACK 콜백 함수 에서 찾을 수 있습니다.

프록시 인증 처리

키: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\ 값: AllowOutlookHttpProxyAuthentication 기본값: 0 데이터: 1; 프록시 서버에서 인증 요구를 처리할 수 있도록 Outlook = 0 = 자동 프록시 서버에서 인증 요구를 실패

정보 레지스트리 값이 완화의 보안 구성을 사용 하면 및 Microsoft 기술 자료의 다음 문서에서 자세히 설명 됩니다.: 3115474 MS16-099: Outlook 2010 용 보안 업데이트에 대 한: 2016 년 8 월 9 일

다른 프로토콜에 대 한 자동 검색

자동 검색 기능 으로 검색 하 고 구성할 Exchange ActiveSync (EAS) 계정을 Outlook에서 사용 됩니다. EAS 자동 검색 프로세스와 의사 결정은이 문서에서 설명 하는 단계는 다릅니다. 예를 들어, EAS 구현 O365 끝점 논리를 구현 하지 않는 및 SCP 위치를 확인 하는 단계는 없습니다. 이 문서는 Exchange에서 MAPI 기반 프로토콜을 자동 검색 시도 대해 Outlook에서 사용 하는 자세한 단계를 설명 하기 위해 범위가 지정 됩니다.

참조

자동 검색에 대 한 기존 정보를 Microsoft 기술 자료의 다음 문서에서 찾을 수 있습니다.

\Autodiscover 키 아래에 레지스트리 설정을 사용 하는 경우의 2212902 예기치 않은 자동 검색 동작

자동 검색에 대 한 자세한 내용은 다음 Microsoft 문서를 참조 하십시오.

Exchange 자동 검색

자동 검색 서비스

추가 도움이 필요하신가요?

기술 향상
교육 살펴보기
새로운 기능 우선 가져오기
Microsoft Insider 참가

이 정보가 유용한가요?

소중한 의견에 감사드립니다.

피드백을 주셔서 감사합니다. Office 지원 에이전트와 연락하는 것이 도움이 될 것 같습니다.

×