www.microsoft.com

로컬 네트워크나 인터넷 등 다양한 위치에서 특정 서비스에 액세스하려면 Exchange 2013 내부 및 외부 URL이 필요합니다. 기본적으로 서버 설치 시 내부 URL만 지정하고 fqdn 서버로 연결하며, 외부 URL은 전혀 존재하지 않습니다. .

이 문서는 설치 후 즉시 Exchange 2013을 구성하는 데 필요한 작업을 다루는 시리즈 중 다섯 번째 문서입니다. 다른 작업에 관심이 있다면 구성에 대한 주요 기사 또는 해당 주제에 대한 주요 기사를 참조하는 것이 좋습니다.

이 기사의 주요 목표인 내부 및 외부 URL 변경으로 넘어가겠습니다.

설정

이렇게 하려면 디렉터리로 이동하세요. EAC - 서버\서버— 마우스로 원하는 서버를 선택하십시오(나의 경우 exch02입니다)\ 변화(연필 아이콘) - 모바일 전망.

현장에서 사용자를 조직에 연결하려면 외부 호스트 이름(예: contoso.com)을 제공하세요.. 필요한 외부 주소를 등록합니다. 저에게는 mail.bissquit.com이 될 것입니다. 내부 노드의 이름도 비슷한 이름으로 바꾸는 것도 좋을 것 같습니다. 외부 이름과 내부 이름이 같을지 다를지 결정하는 것은 사용자의 몫이지만, 동일하게 만드는 것은 논리적인 것 이상으로 보입니다.

인증 유형을 변경하지 않은 경우 다음과 같은 경고가 나타납니다.

이전 버전의 Exchange가 없으므로 경고를 무시합니다.

cmdlet을 사용하여 Powershell을 통해 이 작업을 수행할 수 있습니다. 설정-OutlookAnywhere:

파워셸

결과를 확인해 봅시다:

다음으로 가상 디렉터리에 외부 URL을 추가하고(기본적으로 누락됨) 내부 연결에 유사한 주소를 설정하여 가상 디렉터리의 설정을 변경해 보겠습니다. EAC 웹 인터페이스를 통해 카탈로그에서 해당 작업을 수행할 수 있습니다. 서버\가상 디렉터리- 마우스로 원하는 디렉토리를 선택하고, 변화(연필 아이콘) 필요한 내부 및 외부 URL을 설정합니다.

다음을 제외한 각 가상 디렉터리에 대해 단계를 반복합니다. 자동 검색(기본 웹 사이트).가상 디렉터리 속성 변경 예 ecp(기본 웹 사이트)‎:

각 유형의 가상 디렉터리에 대해 별도의 cmdlet 집합이 있으므로 PowerShell을 통해 설정을 변경하는 명령이 꽤 많이 있습니다.

제어판 가상 디렉터리를 변경하려면 - Set-EcpVirtualDirectory.
Exchange 웹 서비스 가상 디렉터리를 변경하려면 - Set-WebServicesVirtualDirectory.
Microsoft Exchange ActiveSync 서비스 가상 디렉터리를 변경하려면 - 설정-ActiveSyncVirtualDirectory.
OAB 가상 디렉터리를 변경하려면 - Set-OabVirtualDirectory.
가상 Outlook을 변경하려면 - 세트-OwaVirtualDirectory.
PowerShell 가상 디렉터리를 변경하려면 - 세트-PowerShellVirtualDirectory.

따라서 요점에 더 가깝습니다.

파워셸

Set-EcpVirtualDirectory "exch02\ecp(기본 웹 사이트)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS(기본 웹 사이트) ) )" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync(기본값) 웹 사이트)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB(기본 웹 사이트) " -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA(기본 웹 사이트)" -InternalUrl https://mail.bissquit. com /owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell(기본 웹 사이트)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail. bissquit.com/PowerShell

-EcpVirtualDirectory 설정 "exch02\ecp(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/ecp -ExternalUrl https://mail. 비스킷. com/ecp

-WebServicesVirtualDirectory 설정 "exch02\EWS(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/EWS/Exchange. asmx -ExternalUrl https: // 메일 . 비스킷. com/EWS/Exchange. asmx

-ActiveSyncVirtualDirectory 설정 "exch02\Microsoft-Server-ActiveSync(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/Microsoft-Server -ActiveSync -ExternalUrl https: //mail. 비스킷. com/Microsoft-Server-ActiveSync

-OabVirtualDirectory 설정 "exch02\OAB(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/OAB -ExternalUrl https: //mail. 비스킷. com/OAB

-OwaVirtualDirectory 설정 "exch02\OWA(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/owa -ExternalUrl https://mail. 비스킷. com/owa

-PowerShellVirtualDirectory 설정 "exch02\PowerShell(기본 웹 사이트)"- 내부 URL https://mail. 비스킷. com/PowerShell -ExternalUrl https://mail. 비스킷. com/PowerShell

다음 장으로 넘어가겠습니다.

로컬 DNS 서버 설정

Exchange 2013 서비스에 대해 동일한 내부 및 외부 URL을 지정했으므로 로컬 DNS 서버 레코드를 올바르게 구성하는 방법을 알아내야 합니다(앞으로는 이를 분할 DNS라고 하겠습니다).

메모:사실은 mail.bissquit.com 도메인이 게이트웨이의 외부 주소로 확인되어 외부로 전송되고 게이트웨이에 도달하면 다시 로컬 네트워크. 이에 대해 끔찍한 것은 없지만 로컬 네트워크에서 Exchange 2013으로 향하는 모든 트래픽을 가져오는 추가 경로임은 분명합니다.

도메인 컨트롤러에서 "DNS" 스냅인으로 이동하여 새 정방향 조회 영역을 만들어야 합니다.

모든 설정을 기본값으로 두고 필요한 이름만 표시하면 됩니다. 제 경우에는 bissquit.com입니다. 영역을 생성한 후 하나의 CNAME 레코드를 추가해야 합니다. Exchange 2013 서버의 내부 주소를 확인하려면 mail.bissquit.com이 필요합니다.

메모:이 도메인(또는 하위 도메인)이 일부 외부 리소스에 연결되어 있는 경우 서비스에 두 번째 수준 도메인을 추가하는 것은 매우 좋지 않은 생각일 수 있습니다. 이 경우 로컬 DNS 서버는 자신이 이 전체 영역을 담당한다고 간주하고 예를 들어 사이트 도메인이 존재하지 않는다는 응답을 반환합니다.

레코드가 생성되었습니다. 어떻게 작동하는지 확인해 보겠습니다.

mail.bissquit.com이라는 이름은 내부 주소로 확인되므로 필요한 대로 모든 것이 정상입니다. 그러나 새 영역에 항목을 만들지 않은 다른 하위 도메인을 "ping"하려고 하면 이름을 확인할 수 없습니다. 이는 DNS 서버가 전체 비스킷 도메인에 대해 책임이 있다고 간주하기 때문에 발생합니다. 위임을 사용하여 외부적으로 사이트 레코드에 대한 DNS 쿼리를 보낼 수 있습니다.

이름에 필수 도메인을 지정하십시오.

다음으로, 귀하가 관리하는 DNS 레코드가 있는 공급자의 NS 서버 중 하나(또는 여러 개)를 등록하십시오. NS 서버를 모르는 경우 명령줄에서 nslookup을 실행하고 레코드 유형(set type=ns)을 설정한 후 필수 항목을 입력하세요. 도메인 이름(내 사이트는 bissquit.com입니다):

다시 확인해 보겠습니다.

보시다시피 모든 것이 작동합니다. Alexey 블로그의 기사 덕분입니다. 이 방법의 작은 단점은 모든 외부 하위 도메인을 수동으로 등록해야 한다는 것입니다. 사실, 아직 많이는 아니고 하나만 가지고 있습니다.

이로써 DNS 설정이 완료되었습니다. 일반적으로 DNS 서버 관리는 내부 및 외부 URL 구성과 간접적으로만 관련되어 있지만, URL 구성을 수행할 때 Technet의 설명서는 어떤 DNS 레코드를 생성해야 하는지에 대한 일반적인 정보만 제공하지만 이를 어떻게 구성해야 하는지에 대한 일반적인 정보만 제공하므로 이는 고려해야 할 중요한 사항입니다. 이렇게 하면 어떤 뉘앙스가 설명되지 않는지 알 수 있습니다.

클라이언트 액세스 서버 가상 디렉터리에서 내부 URL을 구성한 후에는 Outlook Web App 및 기타 연결 옵션에 대한 개인 DNS 레코드를 구성해야 합니다. 구성에 따라 클라이언트 액세스 서버의 내부 또는 외부 IP 주소나 FQDN을 가리키도록 개인 DNS 레코드를 구성해야 합니다. 다음은 내부 클라이언트가 연결하기 위해 생성해야 하는 권장 DNS 레코드의 예입니다.

FQDN DNS 레코드 유형 의미
Mail.contoso.com CNAME Ex2013CAS.corp.contoso.com
www.contoso.com CNAME Ex2013CAS.corp.contoso.com

Exchange 2010을 기반으로 메일 서비스를 설정합니다.

외부 메일과 함께 작동하도록 Exchange 2010 서버를 설정하는 방법에 대한 자세한 지침이 인터넷에 충분하지 않다는 의견이 있습니다. 이 문서에서는 Edge 전송 서버를 통해 외부 전자 메일과 작동하도록 Exchange Server 2010을 구성하는 프로세스를 가능한 한 자세히 설명하고 접근성을 설명하려고 합니다.
정말 완벽한 단계별 가이드를 만들기 위해 처음부터 외부 메일을 설정하는 과정을 살펴보겠습니다. 일반적으로 이 프로세스는 세 가지 주요 단계로 구성됩니다.

비즈니스 도메인 이름 등록
도메인 이름을 제공하는 DNS 서버에 MX 레코드를 설정합니다.
외부 도메인과 작동하도록 Exchange 서버를 구성합니다.

우리는 첫 번째 요점에 대해서는 언급하지 않을 것입니다. 왜냐하면... 대다수의 회사는 이미 인터넷에 자체 도메인 이름을 갖고 있으며, 아직 도메인 이름이 없는 경우 모든 등록 기관(예: RU-CENTER www.nic.ru)에서 쉽게 구입할 수 있습니다. 도메인 이름을 등록한 후에는 이를 제공할 최소 2개의 DNS 서버를 도메인 설정에서 찾아서 등록해야 합니다. 이 작업은 등록 기관에서 수행하거나 무료 DNS 서버(예: http://freedns)를 사용할 수도 있습니다. .ws /ru/).
첫 번째 단계가 완료되었습니다. 이제 공급자로부터 조직의 고정 IP 주소를 받아야 하며 두 번째 단계로 넘어갈 수 있습니다. 즉, 외부 도메인을 제공하는 DNS 서버에 MX 레코드를 설정하는 것입니다. MX(메일 교환) 레코드는 도메인의 메일을 처리할 메일 서버를 정의합니다.

다음과 같이 DNS 서버의 영역을 편집합니다.

예를 들어 mail.firma.ru와 같은 A 레코드를 등록하고 Exchange 서버가 게시된 외부 IP 주소를 표시합니다.
MX 레코드를 등록하고 호스트 이름(mail.firma.ru)을 지정합니다.

참고: 도메인에 대한 영역을 방금 생성한 경우 ping Firma.ru가 원하는 IP를 즉시 가리킬 것이라고 생각하지 마십시오. 모든 인터넷 DNS 서버가 변경 사항을 "학습"하는 데 꽤 오랜 시간이 걸릴 수 있습니다. .

설정의 정확성을 확인하려면 다음 명령을 사용해야 합니다. nslookup다음과 같이:

도메인(예: mail.ru)의 MX 레코드를 확인합니다.

nslookup -type=mx mail.ru

그 결과 우리는 우체국이 mail.ru 호스트를 통과합니다 mxs.mail.ru .

호스트의 IP 주소 확인 mxs.mail.ru :

nslookup mxs.mail.ru 8.8.8.8

참고: 이 예에서는 호스트 mxs.mail.ru에 대해 "알고 있는" 것이 로컬 DNS 서버가 아니라 Google DNS 서버(8.8.8.8)인지 확인합니다.

그림 1: MX 레코드 확인

모든 것이 올바르게 구성되어 있고 도메인의 MX 레코드가 서버의 외부 IP 주소로 확인되면 Exchange 설정을 직접 진행할 수 있습니다.
Exchange 서버 게시.

인터넷에 Exchange 서버를 게시하는 데는 두 가지 옵션이 있습니다.

역할이 있는 서버 허브 운송기업 로컬 네트워크에 위치하며 기업 인터넷 게이트웨이를 통해 인터넷에 게시됩니다.
역할이 있는 서버가 게이트웨이에 게시됩니다. 엣지 트랜스포트에 위치한 DMZ 구역메일을 로컬로 전달합니다. 허브 운송.

이 기사에서는 Exchange 서버 게시를 위한 두 번째이자 가장 올바른(제 생각에는) 옵션에 대해 설명합니다. 이 방식의 단점은 Exchange Server 2010에 대한 추가 라이센스를 구입하고 Windows Server 2008을 추가로 설치해야 한다는 것입니다.
참고: Windows Server 라이선스를 절약하려면 하드웨어, 중소기업이 역할을 맡을 수 있습니다. 엣지 트랜스포트제어 중인 게이트웨이에 직접 연결 위협 관리 게이트웨이(TMG), 이 구성은 Microsoft에서 공식적으로 지원하므로 그렇게 하겠습니다(ISA 서버에는 Edge를 설치할 수 없습니다). TMG에 Exchange 2010 Edge Transport를 설치하는 방법에 대한 자세한 내용은 여기(http://www.alexxhost.ru/2010/04/exchange-server-2010-edge-server.html)에서 확인할 수 있습니다.

결과적으로 Exchange 조직의 다이어그램은 다음과 같습니다.

그림 2: Exchange 조직 다이어그램.

이 문서에서는 Exchange 2010 서버 및 역할의 설치 프로세스에 대해 논의하지 않습니다. 왜냐하면... 이에 대해 복잡한 것은 없으며 이 주제는 다른 소스에서 두 번 이상 설명되었습니다. 구성에 중점을 두겠습니다.
Edge Transport를 통한 메일 전환

설정을 시작하기 전에 에지 메일 서버(Edge)가 로컬 허브 서버(Hub)와 어떻게 상호 작용하는지 살펴보겠습니다. 서버 간에 메시지를 교환하기 위해 Exchange는 커넥터를 사용하며 적절한 메일 전환을 위해 구성되어야 하는 커넥터입니다. 그림 3은 Edge Transport 에지 서버를 통해 메시지를 받고 보내는 프로세스를 보여줍니다.

그림 3: Edge Transport를 통한 메시지 전환.

결과적으로 6개의 커넥터가 사용됩니다.

Edge 서버에서 외부 메일을 수신합니다.
Edge 서버에서 Hub 서버로 메일 보내기
Hud 서버는 Edge 서버로부터 메일을 받습니다.
Edge 서버를 통해 인터넷으로 로컬 메일 보내기
Hub 서버로부터 메일을 Edge 서버가 수신합니다.
Edge 서버를 통해 인터넷으로 메일을 보냅니다.

언뜻보기에 구성표는 간단하지 않지만 Exchange 서버 개발자가 관리자를 관리하고 Edge 전송 서버에 가입하는 절차를 만들었습니다. 엣지 구독) 결과적으로 다른 모든 설정 외에도 필요한 송신 커넥터를 자동으로 생성할 수 있습니다.
Edge 전송 서버의 네트워크 매개변수 구성

구독에 등록하기 전에 Edge 전송 역할이 있는 서버에서 네트워크 설정을 올바르게 구성해야 합니다. 이 시나리오에서는 기업의 도메인 구조에 포함되지 않고 DMZ 영역에 위치하며 TMG와 동일한 서버에 위치한다는 점을 상기시켜 드립니다(송수신을 위해 TMG에서 규칙을 올바르게 구성하는 것을 잊지 마십시오) 우편). 이 시나리오에 따라 다음 설정을 지정하는 것이 좋습니다.

공급자로부터 구입하여 설치 외부 인터페이스에서공급자의 서버 IP 주소(이전에 구성된 MX 레코드가 가리키는), 마스크, 게이트웨이 및 DNS 서버 주소
DMZ 영역에 자체 DNS 서버가 없으면 파일에 작성해야 합니다. 호스트\%Systemroot%\System32\Drivers\Etc 폴더에서 허브 전송 서버의 이름을 해당 IP 주소에 매핑합니다. 파일 끝에 이와 같은 줄을 추가하십시오 192.168.0.10 허브.도메인.로컬;
인터페이스를 보면 로컬 네트워크에기업은 IP 주소와 마스크를 설정합니다. 게이트웨이를 입력할 필요가 없습니다.
그림 4와 같이 컴퓨터 이름과 DNS 접미사를 구성합니다. (이 설정은 나중에 변경할 수 없습니다.)

그림 4: 서버 DNS 접미사 설정.

로컬 DNS 서버에서 Edge 서버의 IP 주소를 가리키는 A 레코드를 만듭니다.

결과적으로 Edge 서버는 허브 전송 역할이 있는 서버의 주소와 인터넷 주소를 확인할 수 있어야 하며, 허브 전송 서버는 FQDN 이름으로 Edge 서버를 찾는 방법을 알아야 합니다. 명령을 사용하여 확인 핑그리고 nslookup).
Edge 구독 등록

위에서 언급한 것처럼 Edge 전송 서버 역할이 설치된 컴퓨터는 Active Directory에 대한 액세스 권한이 없습니다.. 모든 구성 및 수신자 정보는 Lightweight Directory Services 인스턴스( 광고 LDS) 액티브 디렉토리. 이 서비스는 그림 5와 같이 미리 설치되어 있어야 합니다.

그림 5: AD LDS(Lightweight Directory Services) 설치.

받는 사람 검색 작업을 수행하려면 Edge 전송 서버에 Active Directory에 있는 데이터가 필요합니다. 이 데이터는 EdgeSync를 사용하여 Edge 전송 서버와 동기화됩니다. 엣지싱크 Active Directory에서 Edge 전송 서버의 AD LDS로 받는 사람 및 구성 정보의 단방향 복제를 수행하기 위해 허브 전송 역할을 실행하는 컴퓨터에서 실행되는 프로세스 모음입니다.
AD LDS를 설치한 후 올바른 설정네트워크 매개변수를 사용하여 Edge 및 Hub 전송 서버의 공동 작업 구성을 시작할 수 있습니다. 이를 위해 다음과 같이 Edge 구독을 발행합니다.

Edge 전송 역할이 있는 서버에서 다음 명령을 실행합니다.

New-EdgeSubscription – 파일 이름 c:\edge_subscr.xml

그림 6: Edge 구독 생성.

받은 파일 edge_subscr.xml 로컬 허브 전송 서버에 복사합니다.
가자 Exchange 관리 콘솔-> 섹션 조직 구성-> 행동 새로운 Edge 구독…

그림 7: 허브 전송 서버에서 Edge 구독 만들기.

필요한 AD 사이트를 선택하고 XML 파일구독. 송신 커넥터를 자동으로 생성하려면 확인란을 활성화된 상태로 두는 것을 잊지 마십시오.
마법사가 완료되면 송신 커넥터가 생성되고 잠시 후 Edge 전송 서버와의 동기화가 수행됩니다. 동기화 세션을 기다리지 않으려면 다음 명령을 사용하여 수동으로 수행할 수 있습니다.

시작-Edge동기화

설정 추가 매개변수교환 2010

Edge 구독 프로세스는 관리자의 업무를 훨씬 쉽게 해주지만 모든 작업을 수행하지는 않습니다. 일부 설정은 수동으로 완료해야 합니다.
커넥터 만들기

위에서 언급한 것처럼 Edge 서버를 통해 메일을 성공적으로 전환하려면 커넥터가 6개 이상 있어야 합니다. 기본적으로 어떤 것이 있는지 확인해 보겠습니다.

그림 8: Edge 전송 서버의 수신 커넥터

기본적으로 위치에 따라 모든 네트워크 인터페이스와 외부 및 내부 IP 주소의 메일을 수락하는 커넥터가 Edge 전송 서버에 생성되었습니다. 1 그리고 5 그림 3의 다이어그램에서 우리는 이미 그것을 가지고 있습니다.
이제 송신 커넥터를 살펴보겠습니다.

그림 9: 송신 커넥터

Edge 구독을 생성하는 동안 송신 커넥터를 생성하는 옵션은 활성화된 상태로 유지되었습니다(그림 7 참조). 이제 조직 수준의 허브 전송 속성에서 자동으로 생성된 두 커넥터를 볼 수 있습니다. 이러한 커넥터는 조직 수준에 있으므로 도메인의 다른 모든 Exchange 서버에도 해당 커넥터가 있습니다. 이 경우 Edge Transport도 예외는 아니며 Edge에서는 읽기 전용이라는 점만 다릅니다. 그 결과 커넥터는 인터넷에 대한 기본 사이트 이름임무를 수행할 것이다 4번째그리고 6번째우리 회로의 커넥터 Default-First-Site-Name으로의 인바운드 – 2위.
따라서 6개 중 5개의 커넥터가 있습니다. 허브 전송 서버의 수신 커넥터가 없거나(다이어그램의 3번) 거기에 있습니다. 기본 허브 이름, 하지만 IMHO, 별도로 만드는 것이 더 정확할 것입니다. 수신 커넥터를 생성하려면 해당 레벨로 이동하세요. 서버 구성, 역할을 선택하세요 허브 운송작업 메뉴에서 버튼을 누릅니다. 새로운 수신 커넥터.

그림 10: 허브 전송 서버에서 수신 커넥터 만들기.

커넥터의 이름을 입력하고 커넥터가 될 것임을 나타냅니다. 내부, 즉. 우리 조직의 Exchange 서버와 함께 작동합니다. 마법사의 다음 단계에서는 서버의 IP 주소에서 메일을 받아야 함을 나타냅니다. 엣지 트랜스포트. 버튼을 눌러 생성을 완료하자 새로운.
이제 커넥터 작업을 마쳤으므로 메일 수락을 위한 정책을 만드는 단계로 넘어갑니다.
허용 도메인 및 이메일 주소 정책 생성

허용 도메인 Microsoft Exchange 조직이 이메일을 보내고 받는 데 사용되는 SMTP 네임스페이스입니다. 외부 도메인 이름이 로컬 이름(firma.ru 및 domain.local)과 다르기 때문에 조직 수준에서 허용 도메인을 추가해야 합니다. Firma.ru, Exchange 서버가 작동할 수 있도록 합니다.
그러기 위해서는 레벨로 갑시다 조직 구성 -> 허브 운송 -> 허용 도메인.

그림 11: 새 허용 도메인 만들기.

마법사에서 허용 도메인의 표시 이름을 입력하고 도메인 자체를 입력한 후 해당 도메인이 권위 있는, 왜냐하면 수신자의 사서함은 이 SMTP 도메인에 위치합니다.
사용자가 허용 도메인을 통해 메일을 받고 보내려면 추가 이메일 주소를 만들어야 하며 이는 이메일 주소 정책을 사용하여 수행됩니다.
이메일 주소 정책작업을 선택하여 허브 전송 역할 속성의 조직 수준에서 생성됩니다. 새로운 이메일 주소 정책…

그림 12: 이메일 주소 정책 추가.

정책은 필터 없이 원하는 FQDN 이름(그림 12 참조)에 바인딩되고 즉시 실행(즉시) 일정에 지정되어 모든 유형의 수신자에게 적용되어야 합니다. 결과적으로 전자 메일 주소 정책은 허용 도메인에 바인딩될 때 적용되는 모든 수신자에 대해 해당 전자 메일 주소를 자동으로 생성합니다.
참고: 수신자에 대한 추가 주소 생성은 즉시 수행되지 않으므로 기다리지 않으려면 사서함 속성에서 직접 전자 메일 주소를 추가하거나 cmdlet을 실행할 수 있습니다. 업데이트-EmailAddressPolicy.

두 개의 정책을 생성해야 합니다. 하나는 도메인용입니다. Firma.ru, 또 다른 도메인.로컬. 결과적으로 조직의 각 수신자는 2개의 전자 메일 주소를 갖게 되며, 반송 주소로, 우선 순위가 낮은 정책에 속하는 정책이 사용됩니다.
이제 허브 전송 서버 작업이 완료되었으며 Edge 전송으로 이동할 수 있습니다.
주소 재작성

외부 도메인 이름과 AD 도메인 이름이 다르기 때문에 들어오고 나가는 메시지의 주소를 다시 써야 합니다( *.ru<->*.현지의). Microsoft Exchange Server 2010에는 이러한 목적을 위한 기능이 있습니다. 주소 재작성을 사용하면 들어오고 나가는 메시지의 보낸 사람과 받는 사람의 주소를 변경할 수 있습니다. 자세히 알아보기 이 기능여기(http://technet.microsoft.com/ru-ru/library/aa996806.aspx)에서 읽을 수 있습니다.
주소 재할당 정책을 추가하려면 cmdlet을 사용하세요. New-AddressRewriteEntry서버에서 엣지 트랜스프로트:
New-AddressRewriteEntry – 이름 "Lan - 인터넷" – 내부 주소 "domain.local" – 외부 주소 "firma.ru"

그림 13: 주소 다시 쓰기 정책 추가.

참고: 이 정책은 즉시 적용되지 않습니다. 즉시 활성화하려면 Microsoft Exchange Transport Service를 수동으로 다시 시작하면 됩니다.

가능한 문제

이로써 기업 DMZ 영역에 있는 Edge 전송 서버를 통해 외부 메일을 작업하기 위한 Exchange Server 2010의 기본 구성이 완료되었습니다. 다음 단계는 이 메일이 전송되고 수신되었는지 확인하는 것입니다. 어떤 이유로든 메일이 전송되거나 수신되지 않는 경우 먼저 다음 단계를 따르시기 바랍니다.

마법사를 사용하세요 원격 연결 분석기메뉴에 위치 도구 상자. 이 마법사는 다양한 Exchange 서비스를 테스트할 수 있는 http://testexchangeconnectivity.com/ 페이지로 이동합니다.
메시지 대기열 보기 도구 상자 -> 큐 뷰어편지가 어느 단계에서 멈춰 있는지 확인하기 위해. 이 유틸리티는 메시지 대기열뿐만 아니라 특정 대기열에서 발생한 최신 오류 텍스트와 여기에 포함된 메시지 헤더도 표시할 수 있습니다.
팀 텔넷 YourServer 25서버가 메일을 수신할 수 있는지 확인하는 데 도움이 됩니다.
큐 뷰어에서 DNS와 관련된 문제를 발견하면 인터페이스의 네트워크 매개 변수를 올바르게 구성하지 않았거나 잘못 편집했을 가능성이 높습니다. 호스트 파일.
또한 Edge 전송 서버의 경우 네트워크 인터페이스에 설치된 것과 다른 DNS 서버 주소를 지정할 수 있습니다. 이 작업은 메뉴에서 수행됩니다. 속성선택한 서버 – 탭 내부 DNS 조회그리고 외부 DNS 조회.
커넥터의 탭을 확인해야 합니다. 회로망, 입증그리고 권한 그룹.
허브 전송을 변경한 후에는 동기화하는 것을 잊지 마세요( 시작-EdgeSynchronization).
위의 어느 것도 도움이 되지 않으면 시스템 로그를 분석하고 커넥터 속성의 일반 탭에서 프로토콜 로깅을 활성화할 수 있습니다. 전송 로그 분석에 대한 자세한 내용은 http://technet.microsoft.com/ru-ru/library/aa998617.aspx에서 확인할 수 있습니다.

Forefront Threat Management Gateway(TMG) 2010에는 Exchange 2010용 Microsoft Exchange OWA(Outlook Web App) 게시와 Exchange 2007, 2003 및 2000용 Outlook Web Access 게시에 대한 지원이 포함되어 있습니다. 두 부분으로 구성된 이 시리즈의 1부에서는 게시용 CAS 서버를 프로비저닝하는 방법을 살펴보았습니다. 2부에서는 TMG를 사용하여 Exchange OWA 2010을 게시하는 데 필요한 단계에 대해 설명합니다. 이 문서 시리즈의 첫 번째 부분을 읽으려면 Microsoft Forefront Threat Management Gateway(TMG) 2010에 Exchange Outlook Web App(OWA) 게시: 1부 - CAS(클라이언트 액세스 서버) 준비로 이동하세요.

소개

인증서 가져오기

OWA를 게시하려면 먼저 사이트의 SSL 인증서를 TMG 방화벽으로 가져와야 합니다. 이 작업을 완료하려면 메뉴로 이동하세요. 시작/실행그리고 입력 mmc.exe. 드롭다운 목록에서 선택 파일/스냅인 추가 또는 제거. 선택하다 인증서을 누른 다음 추가하다.

옵션을 선택하세요 컴퓨터 계정.

로컬 컴퓨터를 관리하는 옵션을 선택하세요 (로컬 컴퓨터).

콘솔 트리에서 노드를 확장합니다. 인증서. 폴더 확장 개인의, 폴더를 마우스 오른쪽 버튼으로 클릭하세요. 인증서그리고 선택 수입

이전에 내보낸 인증서 파일의 위치를 나타냅니다.

비밀번호를 입력하고 (선택사항) 확인하세요. 개인 키수출 가능한 것으로.

기본 옵션을 수락합니다 모든 인증서를 다음 저장소에 배치하십시오..

OWA 게시 규칙 만들기

TMG 관리 콘솔에서 방화벽 정책 노드를 마우스 오른쪽 버튼으로 클릭합니다. (방화벽 정책)콘솔 트리에서 선택하고 새로운그런 다음 Exchange 웹 클라이언트 액세스 게시 규칙

게시 규칙에 의미 있는 이름을 지정합니다.

선택하다 익스체인지 서버 2010드롭다운 목록에서 게시 옵션을 선택하세요. 아웃룩 웹 액세스.

데모 목적으로 하나의 CAS 서버를 게시하므로 옵션을 선택합니다. 단일 웹 사이트 또는 로드 밸런서 게시.

SSL을 사용하여 게시된 웹 서버 또는 서버 팜에 연결 옵션을 선택합니다.

이름을 입력하세요 내부웹 사이트.

특정 도메인에 대한 요청을 수락하는 옵션을 선택한 후 다음을 입력하세요. 공개 이름웹 사이트.

옵션을 선택하세요 인증서 선택이전에 가져온 인증서를 나타냅니다.

옵션을 선택하세요 HTML 양식 인증 사용그리고 Windows(액티브 디렉토리)자격 증명을 확인합니다.

필요한 경우 SSO를 활성화합니다.

TMG 방화벽에서 사용되는 인증 방법 일치해야 함웹사이트에 구성된 인증 방법을 사용합니다. 웹사이트에서 기본 인증을 활성화했으므로 옵션을 선택하겠습니다. 기본 인증여기.

OWA 액세스를 특정 사용자 및/또는 그룹으로 제한하려면 여기에 추가하세요. 그렇지 않으면 그룹을 수락합니다. 인증된 모든 사용자기본.

작동을 확인하려면 버튼을 누르세요. 테스트 규칙.

TMG에서는 규칙을 테스트하고 작동 여부를 보고합니다.

결론

이 시리즈의 1부에서 Exchange CAS(클라이언트 액세스 서버)를 준비한 후 2부에서는 Exchange Outlook Web App 2010을 안전하게 게시하도록 Forefront TMG(위협 관리 게이트웨이)를 구성했습니다. SSL 인증서를 가져오고 Exchange 만들기 단계를 진행했습니다. 웹 클라이언트 액세스 게시 규칙 마법사 게시 규칙 및 TMG의 진단 기능을 사용하여 게시 규칙이 올바르게 구성되었는지 확인했습니다.

http://spravka.zhavoronki.biz에서 복사

24.12.2012

이 문서에서는 OWA 인터페이스를 통해 사용자가 사용할 수 있는 구성 요소를 제한하고 OWA 로그인 및 로그아웃 화면을 사용자 지정하는 데 사용되는 OWA 분할에 대해 설명합니다.

윌리엄 레프코비츠 ([이메일 보호됨]) - Mojave Media Group의 CTO이자 메시징 및 협업 기술에 대한 기사의 저자입니다. MCSE 인증 및 Microsoft Exchange MVP 타이틀 보유

Exchange Server 2010의 OWA(Outlook Web App)는 Exchange Server 5.0이 출시된 지 약 15년 동안 사용된 Outlook Web Access의 새 이름입니다. Exchange Server의 첫 번째 버전이 OWA와의 세션을 종료한 이후로 관리자는 지원되는 사용자 지정 기능 외에도 OWA에 고유한 기능을 추가하기를 지속적으로 원했습니다. OWA 설정은 색상 조정부터 기업 상징의 완전한 변경 및 인터페이스의 급격한 변경까지 다양합니다. OWA 설정의 용이성은 Exchange Server 버전, 사용 가능한 구성 도구, 관리자의 기술 수준에 따라 달라집니다.

최신 버전의 OWA는 Exchange 5.0 및 5.5의 단순한 ASP(Active Server Pages) 응용 프로그램과 크게 다릅니다. Exchange Server 2007에 도입된 Microsoft Exchange 웹 서비스를 사용하면 다양한 웹 서비스 API 호환 소스에서 Exchange 데이터를 사용할 수 있습니다. Exchange 웹 서비스가 포함된 Exchange Server 2010을 사용하면 Exchange Server 데이터에 액세스하기 위한 사용자 지정 웹 응용 프로그램을 더 쉽게 디자인할 수 있습니다. Exchange 2007에서는 사용자가 선택할 수 있는 네 가지 테마를 OWA에 추가합니다. Exchange Server 2010 RTM은 OWA 구성 옵션을 구현하지 않습니다. 이전 Exchange 2007 테마는 설치에 여전히 존재하지만 작동하지 않습니다. OWA 설정은 Exchange Server 2010 SP1(서비스 팩 1)에서만 반환됩니다. 현재 Exchange Server 2010 SP2에는 이 문서에서 설명한 것 이상의 OWA 설정이 포함되어 있지 않습니다.

OWA 설정에 대한 Microsoft의 접근 방식

논의 중인 OWA 변경 사항 중 상당수는 기존 파일을 업데이트된 파일로 교체해야 합니다. 테마, 간단한 CSS(Cascading Style Sheet), 로그인 및 종료 화면 작업 시 파일 수준에서 변경 사항이 발생합니다. Microsoft가 버그, 패치 롤업 또는 서비스 팩을 수정하기 위해 Exchange Server를 업데이트할 때 회사는 변경 사항이 유지된다는 것을 보장하지 않습니다. 또한 코드 업데이트가 사용자가 수행한 사용자 정의에 영향을 미치지 않는다는 보장도 없습니다. 따라서 설정을 보관하고 업데이트를 적용한 후 OWA 설정이 작동하는지 확인해야 합니다. Exchange 5.5까지의 모든 버전에 대해 OWA를 구성하는 Microsoft의 접근 방식은 "Exchange용 Outlook Web Access 사용자 지정에 대한 Microsoft 지원 정책"(http://support.microsoft.com/kb/327178) 문서에 설명되어 있습니다. 전체 사용자 지정 OWA 응용 프로그램이든 브랜드 화면에 대한 파일 수준 로그인 화면 변경이든 작업을 프로덕션으로 이동하기 전에 랩에서 사용자 지정 항목을 개발하고 테스트하는 것도 좋은 생각입니다.

분할

세분화는 완벽하게 지원되는 OWA 구성 방법입니다. 세분화를 통해 관리자는 최종 사용자에게 표시되는 OWA 구성 요소를 정의하기만 하면 됩니다. 많은 회사에서는 사용자가 OWA 클라이언트를 통해 전체 기능 세트에 액세스할 수 있기를 원합니다. 그러나 일부 사용자는 일상 활동에 제한된 기능 세트만 필요할 수 있습니다. 예를 들어, 저는 얼마 전 직원들이 전자 메일과 연락처에 액세스해야 했지만 일정, 과제 또는 공용 폴더에는 액세스할 수 없는 공장에서 일했습니다. OWA에 대한 제한된 액세스로 인해 사용자는 기밀이거나 자신의 권한을 벗어난 정보를 공개하거나 보는 것을 방지할 수도 있습니다. 사용량에 따라 또는 정책을 통해 선택적 구성 요소에 대한 액세스를 제한하는 것도 위험 노출을 줄이는 좋은 보안 기술입니다. 또한 분할을 통해 OWA 세션 중에 소비되는 통신 대역폭을 줄일 수 있습니다.

기본적으로 OWA는 클라이언트 액세스 서버 역할이 설치된 Exchange 2010 서버에서 사용할 수 있습니다. 세분화에는 추가 구성이 필요하지 않습니다. Exchange 2007에서는 EMC(Exchange 관리 콘솔)를 통해 조각화를 쉽게 관리할 수 있습니다. 분할은 EMC의 클라이언트 액세스 서버를 통해 구성됩니다.

EMC 콘솔에서 OWA를 호스팅하는 클라이언트 액세스 서버로 이동하여 오른쪽 클릭 OWA 웹 사이트 위에 마우스를 놓고 속성을 선택합니다. 조각화 탭(그림 1)에는 클라이언트 액세스 서버 사용자가 비활성화하거나 활성화할 수 있는 OWA 기능이 나열되어 있습니다(사용 가능한 기능 목록은 표 1 참조). 개별 기능을 한 번에 하나씩 선택하고 활성화하세요.

Exchange Server 2010에는 OWA 사서함 정책이 도입되었습니다. 이러한 정책을 사용하면 관리자는 특정 클라이언트 액세스 서버에서 OWA에 연결된 모든 사람이 아닌 개별 사용자 또는 사용자 그룹에 분할을 적용할 수 있습니다. 기능 이름에 "사서함"이 포함되어 있지만 이러한 정책은 기술적으로 사서함이 아니라 사서함의 데이터에 액세스하는 데 사용되는 웹 응용 프로그램에 적용됩니다. 클라이언트 액세스 서버 역할이 설치되면 표준 OWA 사서함 정책이 적용됩니다. 기본적으로 나열된 모든 세그먼트 기능이 활성화됩니다.

OWA 사서함 정책은 그림 2와 같이 EMC에서 회사 수준으로 구성됩니다. EMC의 조직 구성 센터에서 클라이언트 액세스를 선택합니다. OWA 사서함 정책은 가운데 창에 표시됩니다. 새 정책을 추가하려면 가운데 창의 빈 영역을 마우스 오른쪽 버튼으로 클릭하고 다음에서 새로 만들기를 선택합니다. 상황에 맞는 메뉴, 또는 EMC Actions 패널에서 직접 선택합니다. 그림 2에서 볼 수 있듯이 OWA 사서함 정책의 주요 목적은 사용자 인터페이스에서 구성할 항목이 없기 때문에 사용자 또는 그룹에 대한 특정 분할 옵션을 구성하는 것입니다. 정책이 적용되는 지역이나 비즈니스 단위 등 설명이 포함된 이름을 정책에 지정하거나 저널 없음과 같이 이름에 특정 분할 대상을 포함하는 것이 유용합니다. 그림 3은 기존 OWA 사서함 정책을 적용할 수 있는 Outlook Web App 속성 창을 보여줍니다. 사서함또는 상자. OWA 사서함 정책은 EMS(Exchange 관리 셸) 또는 New-OWAMailboxPolicy 및 Set-OWAMailboxPolicy 명령을 사용하여 만들고 편집할 수 있습니다.

이러한 명령을 사용하여 새 OWA 사서함 정책을 만들거나 기존 정책을 수정하는 경우 특성 목록을 설정하거나 해제할 수 있습니다. 이러한 특성은 표 1에 나열된 기능에 직접 적용됩니다. 기본적으로 기능은 활성화되어 있으므로 일반적으로 EMS에서 OWA 사서함 정책을 구성할 때 토글 특성을 선택하고 false로 설정하여 비활성화해야 합니다. 각 명령의 속성 목록은 Microsoft 문서 "Set-OwaMailboxPolicy"(http://technet.microsoft.com/en-us/library/dd297989.aspx) 및 "New-OWAMailboxPolicy"(http://technet)를 참조하십시오. .microsoft.com/en-us/library/dd351067) 및 명령 도움말에도 있습니다.

세분화는 서버 또는 사용자 수준에서 EMS를 사용하여 구성할 수도 있습니다. Set-CASMailbox 명령은 특정 OWA 사서함 정책에 정의된 대로 조각화를 적용합니다. 예를 들어 다음 코드는 사서함 액세스 권한이 있는 사용자 Steve에게 North America Staff라는 OWA 사서함 정책을 적용합니다.

Set-CASMailbox -Identity Steve -OwaMailboxPolicy: "북미 직원"

OWA 사서함 정책 이름에 공백이 있으면 EMS에서는 따옴표를 사용해야 합니다. 동일한 이름을 가진 AD(Active Directory) OU(조직 단위)에 속한 모든 사용자에게 Executives라는 OWA 사서함 정책을 적용하려면 다음 코드를 사용합니다.

Get-CASMailbox -OrganizationalUnit 임원 | 세트-CASMailbox -OWAMailboxPolicy:Executives

EMS를 사용하면 일반적인 기존 특성(예: 제목, 위치)을 기반으로 OWA 사서함 정책을 적용하려는 사서함 액세스 권한이 있는 사용자 목록을 얻을 수 있습니다. 이렇게 하려면 Get-User를 사용하고 출력을 Set-CASMailbox 명령으로 파이프합니다. Get-Content 명령을 사용하여 EMS를 통해 텍스트 파일에서 데이터를 추출할 수도 있습니다.

콘텐츠 가져오기 "c:\files\OWAPolicyList.txt" | Set-CasMailbox -OwaMailboxPolicy "북미 직원"

OWAPolicyList.txt는 사서함의 이메일 주소 목록을 한 줄에 하나씩 포함하는 간단한 텍스트 파일입니다.

[이메일 보호됨]

물론 관리자들은 마이크로소프트 오피스 365는 회사에서 세분화를 설정하려면 EMS를 사용해야 합니다. Office 365용 ECP(Exchange 제어판)는 OWA 정책 관리에 대한 액세스를 제공하지 않습니다.

Exchange 2010 SP2는 이전에 제거된 웹 메일 버전인 OWA Mini(이전에는 OMA(Outlook Mobile Access)로 알려져 있으며 Exchange Server 2003에 있음)를 다시 가져옵니다. OWA Mini의 업데이트된 버전은 OWA 내의 양식 집합을 제공합니다. OWA의 일부인 OWA Mini( 모바일 브라우저) 및 OWA Basic(테스트되지 않은 브라우저의 경우)도 분할 플래그를 인식합니다. 달력과 같은 기본 폴더에 대한 액세스가 거부된 사용자는 OWA Mini(그림 4) 또는 OWA Basic을 통해 해당 폴더에 액세스할 수 없습니다.

화면 4. OWA 미니

세분화를 통해 사용자는 OWA 웹 경험을 더욱 단순하고 일관되게 만들 수 있습니다. 기본적으로 OWA는 브라우저 창의 왼쪽 하단에 기본 메일, 일정, 연락처 및 작업 폴더를 표시합니다. 처럼 간단한 예처음에 OWA 사서함 정책을 적용하지 않아 모든 기능을 활성화한 Steve Bauer라는 사용자를 생각해 보십시오. 일정, 작업 및 주제 선택을 비활성화하는 OWA 사서함 정책을 적용해 보겠습니다. 화면 5와 6에서는 정책 적용 전과 후의 인터페이스 차이를 보여줍니다.

Set-VirtualDirectory 명령을 사용하여 서버 수준에서 분할을 적용할 수도 있습니다. Set-OWAMailboxPolicy 명령과 마찬가지로 개별 기능을 활성화하거나 비활성화할 수 있습니다. 이렇게 하면 owa(기본 웹 사이트)와 같은 특정 서버 및 가상 디렉터리에 연결하는 모든 사람이 동일한 OWA 기능을 볼 수 있습니다. 여러 클라이언트 액세스 서버에서 OWA 액세스에 대해 일종의 부하 분산 방법을 사용하는 경우 조각화 설정 변경 사항을 풀의 모든 클라이언트 액세스 서버에 적용해야 합니다. 그렇지 않으면 부하 분산 메커니즘을 통해 연결하는 클라이언트 액세스 서버에 따라 사용자에게 다른 OWA 구성이 표시됩니다.

마지막으로, 새 OWA 사서함 정책을 만들거나 서버 수준 분할을 변경하고 해당 정책이나 변경 사항을 사용자에게 즉시 적용하려는 경우 OWA 사이트를 다시 시작해야 할 수도 있습니다. Microsoft IIS가 다시 시작되면 OWA의 변경 사항도 즉시 적용됩니다. 이것부터 하는 것이 가장 좋습니다. 명령줄다음 명령을 사용하여 서버에서:

Iisreset -noforce 로그온 및 로그오프 화면 사용자 정의

사용자가 OWA용 URL에 접속하면 첫 화면은 등록 화면이 됩니다(인증 오류가 없는 한). 일부 회사에서는 브랜딩을 강조하거나 사용자에게 올바른 위치에 있음을 확신시키기 위해 가입 및 로그아웃 화면을 사용자 정의하려고 합니다. 친숙한 회사 로고와 색상이 포함된 등록 화면은 사용자에게 올바른 사이트에 있다는 확신을 줍니다. 등록 화면에 특정 정보나 면책조항을 포함할 수도 있습니다. 로그인 또는 로그아웃 화면 설정은 기본 OWA 기능에 영향을 주지 않습니다.

OWA 로그인 또는 로그아웃 화면은 여러 그래픽 파일을 사용하는 독립형 웹 양식입니다. 글꼴 및 서식을 위한 gif 및 CSS 테이블. OWA에 처음 로그인하는 사용자의 경우 CSS 파일 및 이미지가 로그인 화면과 동일하므로 사용자 정의할 수 있는 추가 화면이 있습니다. 초기 로그인 화면은 logon.css에 따라 구성 및 배치된 9개의 gif 파일로 구성됩니다. 등록 화면의 다른 측면도 gif 이미지 파일 외부에서 사용되는 글꼴 유형 및 색상을 포함하여 CSS 파일의 정보에 따라 결정됩니다. 첫 번째 로그인 설정 화면과 로그아웃 화면에는 동일한 파일이 사용됩니다. 이러한 파일을 변경하려면 한 번만 수행하면 됩니다. 업데이트는 세 페이지 모두에 반영됩니다. 로그인, 최초 로그인 및 로그아웃 화면의 표준 버전은 화면 7, 8, 9에 표시됩니다.

화면 7: 표준 로그인 화면

화면 8: 표준 최초 등록 화면

화면 9: 표준 로그아웃 화면

로그인 및 로그아웃 화면에 사용되는 파일은 \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\\Themes\Resources 디렉터리에서 클라이언트 액세스 서버 역할을 실행하는 Exchange 서버에 있습니다. 변수는 Exchange Server 수준에 있습니다. Exchange 2010 SP2에는 14.2.247.5라는 폴더가 표시됩니다. Exchange 2010 SP2 롤업 1에는 14.2.283.3 폴더가 추가됩니다. OWA는 최신 소스를 사용합니다.

위에서 언급한 것처럼 가능하다면 맞춤 제작을 실험실에서 테스트해야 합니다. 그렇지 않으면 백업을 만들어 보십시오. 소스 파일 OWA 파일을 변경하기 전에. 운 좋게도 Microsoft는 GIF에 설명적인 이름을 부여했습니다. 그림 10은 등록 화면의 gif 분포를 보여줍니다. 표 2에는 이미지 파일 이름과 크기(픽셀 단위)가 나열되어 있습니다.

로그인 화면을 사용자 정의하는 가장 쉬운 방법은 2단계 프로세스입니다. 즉, gif를 보다 적절한 회사 로고로 바꾸고 그에 따라 logon.css 및 owafont.css를 변경하는 것입니다. 당연히 이러한 표면적인 변화만이 유일한 것은 아니지만 이런 방식으로 최소한의 노력으로 최대의 효과를 얻을 수 있습니다. 그림 7, 8, 9에 표시된 Outlook Web App 텍스트의 GIF는 lgntopl.gif라고 합니다(파일 이름은 로그온, 위쪽, 왼쪽을 나타냄). 표준 OWA 색 구성표를 변경하지 않고 로고만 추가하려는 경우 작업하기가 가장 쉽습니다. 이 기사를 준비하면서 나는 그림 11과 같이 gif 파일을 가져와 네바다주 라스베이거스 스트립의 유명한 라스베이거스 간판을 빌려 가상의 라스베이거스 웹메일 로고를 추가했습니다. gif 파일의 크기는 동일하게 유지되었습니다(456 x 115픽셀), 따라서 클라이언트 액세스 서버의 파일을 바꾸면 해당 클라이언트 액세스 서버에서 OWA에 로그인하는 사용자에게 새 로고가 표시됩니다. 다른 파일 크기를 사용하고 CSS 파일을 변경하지 않은 경우 그래픽 서식일관성이 없을 것입니다. 페이지의 각 이미지 위치는 CSS 파일의 데이터와 픽셀 위치에 따라 결정됩니다. 따라서 gif 파일의 크기를 변경하는 경우 CSS 파일에서 이러한 변경 사항을 수용해야 합니다. 분명히 기존 이미지의 모양을 변경하는 것 이상으로 등록 화면을 심층적으로 사용자 정의하려면 CSS에 대한 지식이 필요합니다.

그림 11: 사용자 정의된 OWA 로그인 화면

로그인 화면의 텍스트 스타일도 logon.css 파일의 지침에 따라 결정됩니다. CSS 파일은 텍스트 편집기나 여러 CSS 편집기 중 하나에서 수정할 수 있는 간단한 텍스트 파일입니다. 그러나 오늘날 모든 웹 개발 프로그램은 CSS를 수정할 수도 있습니다. Microsoft Expression Web은 CSS 파일 작업을 위한 훌륭한 도구입니다. Microsoft Visual Studio도 사용할 수 있습니다. 강력한 편집자 CSS를 이 목적으로만 사용하는 것은 분명히 비합리적입니다. CSS의 색상은 16진수 색상 코드(기호(#) 뒤에 6자리 코드)로 정의됩니다. 대부분의 CSS 편집기는 16진수로 구성된 색상 팔레트를 제공합니다. 인터넷에는 VisiBone과 같은 빠른 액세스 리소스도 있습니다. 마케팅 전문가, 예술가 및 웹 프로그래머는 일반적으로 기업 로고의 색상 구성표를 나타내는 인쇄 및 웹 제품의 정확한 색상 코드를 정의합니다.

표 3에는 로그인 화면의 logon.css 파일에 정의된 일부 색상이 나열되어 있습니다. 이 예에서는 logon.css 파일의 글꼴 색상을 주황색에서 보라색으로 변경하고, 사용자 이름 및 비밀번호 입력 필드의 배경을 연한 주황색에서 연한 회색으로 변경했습니다. 또한 희박한 회색을 진한 파란색으로 변경하고, 색상 코드를 변경하고, 테두리의 픽셀 빈도를 높여 입력 필드 주변의 테두리를 강조했습니다. 이러한 변경을 위해 logon.css 파일에서 fff3c0의 값을 cccccc로, ff6c00을 800080으로, a4a4a4의 값을 000080으로 변경했습니다. CSS 파일의 어떤 요소가 페이지에 적용되는지 정확하게 확인하려면 여러 버전을 테스트해야 했습니다. 소중하게 지켜온 백업 복사본 logon.css를 사용하여 클라이언트 액세스 서버의 \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.2.283.3\Themes\Resources 디렉터리에 새 파일을 배치했습니다. 또한 새 lgntopl.gif 이미지를 동일한 디렉터리에 복사했습니다. 그림 12는 OWA 등록 화면의 간단한 변경 사항을 보여줍니다. 물론 귀하의 옵션은 이러한 간단한 설정에만 국한되지 않습니다. CSS와 그래픽을 잘 이해하면 표준 OWA 옵션에서 인식할 수 없는 사용자 정의 로그인 및 로그아웃 화면을 만들 수 있습니다.

사용자가 변경 사항을 즉시 보려면 로컬 브라우저 캐시를 지워야 할 수도 있습니다. 내 연구실에서는 고객에게 변경 사항을 전달하기 위해 웹사이트를 다시 시작해야 했습니다. 네트워크 경계에서 특정 프록시 애플리케이션이나 장치를 사용하는 경우 사용자가 업데이트를 받기까지 지연이 발생할 수 있습니다.

설정 적용 중

OWA 변경 사항은 클라이언트 액세스 서버 간에 복제되지 않습니다. 클라이언트 액세스 서버 역할이 설치된 여러 Exchange 서버가 OWA를 제공하는 경우 각 서버에 모든 설정을 적용해야 합니다. 이 경우에만 모든 사용자에게 동일한 화면이 표시됩니다. 사용자는 브라우저가 연결되는 클라이언트 액세스 서버로부터 OWA 화면을 받게 됩니다. 이는 장점이자 단점이 될 수 있습니다. 때로는 기업 환경에서 다양한 사용자 그룹이 OWA와 다르게 상호 작용하도록 하는 것이 유용할 수 있습니다.

Exchange Server의 파일 수준에서 작업하고 싶지 않지만 로그인 및 종료 화면을 변경해야 하는 경우 일부 엔터프라이즈 브랜딩 회사는 OWA 2010을 포함한 다양한 사용자 정의 소프트웨어 솔루션에 대한 서비스를 제공합니다. 많은 회사가 OWA를 대폭 변경합니다. 등록 화면에서 애플리케이션을 인식할 수 없게 됩니다. 이러한 공급자의 예(클라이언트 솔루션에 대한 여러 스크린샷 포함)는 Techstur.com입니다. 해당 회사의 서비스를 사용하는 경우 OWA용 새 서비스 팩 출시 이후 발생할 수 있는 문제에 대처할 준비를 하십시오.

Exchange Server 2010에서 OWA 구성

Rosalab Wiki의 자료

목적

이 설명서에는 다양한 연결 방법이 설명되어 있습니다. 메일 클라이언트 Microsoft Exchange 서버에. 목표는 기능 면에서 Microsoft Outlook과 일치하는 시스템을 얻는 것입니다.

입력 데이터

예제에서는 Microsoft Exchange 2010 서버(v14.03.0361.001) 서비스 팩 3 업데이트 롤업 18을 사용합니다. 테스트는 회사 네트워크 내에서 수행됩니다. DNS 서버에는 메일 서버의 외부 메일 주소가 포함되어 있습니다. 다음은 Exchange 서버에서 작동해야 합니다.

OWA(Outlook Web Access) - 공동 작업 서버에 액세스하기 위한 웹 클라이언트 마이크로소프트의 일교환
OAB(오프라인 주소록) - 오프라인 주소록
EWS(Exchange Web Services)는 Exchange Online(Office 365의 일부) 및 온프레미스 버전의 Exchange(Exchange Server 2007부터)에 저장된 사서함 데이터에 대한 액세스를 제공하는 서비스입니다.

Exchange 서버 설정

Microsoft 이외의 클라이언트가 Exchange 2010에서 성공적으로 실행되는 데 중요한 문제는 인증입니다. CAS(클라이언트 액세스 서버) 역할이 있는 Exchange 서버에서 해당 매개변수를 볼 수 있습니다. IIS 관리자 스냅인을 실행하고 사이트/기본 웹 사이트 탭을 엽니다. 인증에는 세 가지 구성 요소가 있습니다.

OWA - 상태 " 활성화됨" 을 위한 " 기본인증" 그리고 " 윈도우 인증»:

OAB - 상태 " 활성화됨" 을 위한 " 기본인증" 그리고 " 윈도우 인증»:

EWS - 상태 " 활성화됨" 을 위한 " 익명 인증», « 기본인증" 그리고 " 윈도우 인증»:

레이어(중개자) 및 보조 유틸리티

DavMail

일부 이메일 클라이언트는 Microsoft Exchange에 직접 연결할 수 없으며 중개자를 사용해야 합니다. 이 예에서는 프록시 서버가 중개자로 사용됩니다. DavMail.

설치하다 DavMail, su 또는 sudo를 사용하여 관리자 권한을 얻었습니다.

sudo urrpmi davmail

달리다 DavMail:

'메인' 탭의 ' OWA(교환) URL"서버 주소를 "https:// 형식으로 입력하세요. /EWS/Exchange.asmx" 또는 OWA 링크

"https:// 형식으로 /오와."

포트 번호를 기억하세요 " 로컬 IMAP 포트" 그리고 " 로컬 SMTP 포트" 이 예에서는 각각 1143과 1025입니다.

매번 수동으로 서버를 시작하지 않도록 DavMail, 시작에 해당 호출을 추가해야 합니다.

메뉴로 이동 " 시스템 설정 → 시작 및 종료 → 자동 실행", [ 애플리케이션 추가] 검색창에 “davmail”을 입력한 후 [ 좋아요]:

이제 로컬 프록시 서버 DavMail시스템이 시작되면 자동으로 시작됩니다. "작업 표시줄"에 있는 아이콘이 거슬린다면 숨길 수 있는 옵션이 있습니다. 이렇게 하려면 .davmail.properties 파일에서 davmail.server=false 줄을 편집하여 false를 true로 변경합니다.

Sudo mcedit /home/<имя_пользователя>/.davmail.properties