프리지아 랩

Exchange & Outlook/System Administration +28

[적용 버전: Exchange Server 2010/2013]

 

Exchange Server의 데이터베이스를 유지 관리할 때 디스크 사용 현황 모니터링은 운영자의 중요한 업무 중 하나 입니다.

System Center 2012 R2의 Operations Manager를 구매해서 이용하면 더 좋겠지만, 비용이나 훈련의 문제로 곤란을 겪고 있다면, 다음에 소개하는 두 종류의 PowerShell 명령으로 현재 Exchange Server 디스크 사용 현황과 데이터베이스 사용현황도 추출 할 수 있습니다.

 

이렇게 추출한 자료를 엑셀을 사용해 잘 정리하면 전체 스토리지 사용 현황을 쉽게 확인 할 수 있고, 향후 사서함 재배치나, 디스크 증설을 고려할 때 참고 할 수 있습니다.

 

여기에 소개하는 PowerShell 구문은 Exchange Management Shell에서 실행합니다.

 

먼저, Exchange 서버의 디스크 사용 현황을 추출하는 명령 구문입니다. WMI 기능을 PowerShell 커맨드렛을 통해 사용합니다.

 

WMI에 관한 자세한 설명은 다음 링크를 참고하세요.

WMI 개요

 

Get-WMIObject Win32_LogicalDisk -computer PL-MBX-01,PL-MBX-02 | Select-Object SystemName,DeviceID,VolumeName,@{Name=”size(GB)”;Expression={'{0:N1}' -f($_.size/1gb)}},@{Name=”freespace(GB);Expression={'{0:N1}' -f($_.freespace/1gb)}} | Export-CSV D:\Exchange\Disk_150701.csv

 

이 명령 구문을 실행하면 현재 Exchange Server에서 사용하면 시스템 이름, 디바이스 ID, 볼륨 이름, 볼륨 크기, 여유 공간을 추출해서 CSV 파일로 저장합니다.

 

두 번째로, 각 사서함 서버 별로 DB 현황을 가져옵니다. 이 명령 구문은 서버 별로 실행합니다. 서버가 많다면, 서버의 리스트를 먼저 뽑고 파이프로 넘겨 빨간색으로 표시한 부분을 매개변수로 받으면 됩니다.

 

Get-MailboxStatistics -Server PL-MBX-01 | Select-Object itemcount, @{expression={$_.TotalDeletedItemSize.Value.ToMB()};label="TotalDeletedItemSize(MB)"}, @{expression={$_.TotalItemSize.Value.ToMB()};label="TotalItemSize(MB)"}, Database | Export-CSV e:\test\DB_150701_mbx01.csv

 

이 명령 구문을 실행하면 각 사서함에 든 메일 항목의 전체 개수, 삭제된 항목 전체 크기, 전체 메일 항목 크기, 데이터베이스 명을 추출해서 CSV 파일로 저장합니다.

 

이렇게 뽑은 두 가지 데이터를 이용해 엑셀에서 잘 정리하면 다음과 같은 여유 공간 추이를 한 눈에 파악해볼 수 있습니다.

 

 

 

 

 

Comment +0

시간이 제법 흘렀지만, 제 Exchange 강의에 들어오신 분이 방명록에 다음과 같은 시나리오에 대한 해결책을 물어보는 질문을 올린적이 있습니다.

 

"A란 회사에서 회사 전체 그룹메일을 allCompany@A.com을 쓴다고 가정할 때, 굳이 공지할 필요도 없는 메일인데 allCompany@A.com으로 막 메일을 보낼 수 있는 경우가 있을거구요, 이런 경우 관리자쪽에서 해당 (중요)메일로 보낸경우에 바로 들어가는 것이 아닌, 한번 Audit가 된다던가 특정 필터(문자열?)로 메일이 수신(allCompany@A.com)되지 않게 할 수 있는지 궁금합니다."

 

 

이 시나리오에서는 배포그룹 중재 기능과 허브전송 규칙 구성이라는 두 가지 해결책을 물어 본것입니다. 각각을 설정하는 방법의 예를 들어보겠습니다.

 

본 포스팅의 내용은 Exchange Server 2010 SP1 이상을 가정합니다.

 

[1] 배포그룹 중재 기능 활용
EMC(Exchange Management Console)의 왼쪽 트리에서 [Receipient Configuration]을 펼치고 Distribution Group을 선택합니다.

 

1. 회사 전체로 메일을 배달하는 그룹을 선택합니다. 아래 그림에서는 AllCompany 그룹이 바로 그런 그룹입니다.

 

2. 이 그룹을 더블 클릭하면 속성창이 열립니다. 여기서 Mail Flow Settings 탭을 선택하고 내용에서 Message Moderation을 선택해 속성창을 오픈합니다.

 

 

3.사용자를 추가할 수 있는 두 개의 영역이 있는데, 맨 위의 영역은 이 그룹으로 메시지가 보내졌을 때 감사를 하고 허용 여부를 결정할 사람을 넣습니다. 아래 영역은 이 그룹으로 메시지를 보낼때 별도로 허용받을 필요가 없는 사람을 넣습니다(예를 들면 임원 같은 경우겠죠).

 

4. 이제 사용자가 아웃룩 같은 메일 클라이언트에서 해당 그룹에 메일을 보내봅니다.

 

 

5 다음 그림처럼 관리자에게 승인을 요청하는 메일이 오게됩니다.

 

[2] 허브전송 정책 활용
이번에는 허브전송 정책을 통한 메시지 필터링을 구성해보겠습니다.
EMC(Exchange Management Console)의 왼쪽 트리에서 [Organization Configuration]을 펼치고 Hub Transport를 선택합니다.

 

1. 가운데 세부 정보 창에서 마우스 오른 클릭을 하거나, 오른쪽 Action에서 New Transport Rule을 선택합니다.

 

 

2. 적절한 규칙 이름과 주석을 넣고 맨 아래 Enable Rule 체크상자를 체크합니다.

 

 

3. 이제 조건 항목에서 필터링하고자 하는 조건을 선택합니다. 다음 그림처럼 텍스트 패턴을 넣거나 아니면  특정 단어들을 넣도록 선택합니다. 그러면 아래 스텝2에서 특정 단어나 패턴을 구체적으로 입력하게됩니다.

 

4. 다음 그림은 특정 단어를 넣는 장면인데, 텍스트 패턴 화면을 잘못 띄웠습니다. 어쨋든 이런 식으로 넣으면 된다는 것을 보이는 것이니....

 

5 이렇게 특정 단어를 넣고 나면 스텝2 모습이 다음 그림과 같이 됩니다.

 

6. 이제는 이런 조건에 걸리면 어떤 동작을 할 것인지를 정하는 겁니다. 여기서는 별도로 알림을 주지 않고 삭제 시켜버리는 것으로 선택했습니다. 함부로 전사 메일을 보내지 못하게 하는 거죠...

 

7. 모든 규칙에는 예외가 있죠? 내가 회사 사장이라면 자신은 예외로 빼주길 원할 수도 있겠죠. 다음 그림에서 예외를 선택하면 됩니다.

 

8. 이렇게 모든 설정을 마치고 나면 [New] 버튼을 누르고 정책을 만들면 됩니다.

 

9. 이제 사용자가 아웃룩 같은 메일 클라이언트에서 해당 그룹에 메일을 보낼때 지정한 단어들을 사용하면 방금 설정한 규칙에 걸려 메일이 삭제가 됩니다.

 

참고로, 위 그림에서 보듯이 To로 AllCompany를 지정하면 해당 그룹에 중재자가 설정된 경우 메일설명(Mail Tip)으로 미리 사용자에게 보여줍니다.

Comment +1

Exchange Server 2013은 CAS(Client Access Server)와 Mailbox 서버라는 두 개의 기본 빌딩 블록으로 이뤄져 있습니다.

 

CAS는 클라이언트 프로토콜과 SMTP라는 두 가지 컴포넌트로 구성됩니다. CAS 어레이는 프로토콜 세션 관점에서 일련의 씬 서버이자 무상태 서버입니다. 서버에서 상태를 갖지 않기 때문에, 세션 지속성(session affinity)이나 7계층 로드 밸런싱이 필요하지 않습니다. Exchange Server 2013은 프로토콜을 인식하지 않는 TCP 친화성이나 4 계층 로드 밸런싱으로 동작하도록 설계되었습니다.

 

이런 사실은 유연성을 제공하고 로드 밸런싱과 고 가용성에 관한 선택 때문에 중요한 부분입니다. 이러한 설계 변경으로 인해 SSL 처리와 세션 쿠키 처리 등을 하지 않아도 되어 LB의 기능과 활용성을 증가시켜 줍니다. 그리고 복잡성과 비용을 줄여주게 됩니다.

 

CAS는 모든 프로토콜 요청을 알맞은 백엔드나 사서함 서버, 심지어 이전 버전의 Exchange로의 경로를 확보하는 로직을 가집니다. 새로운 Exchange 서버는 모두 도메인에 조인되며, 이제는 Edge 서버나 게이트웨어 서버로 사용되지 않습니다.

 

기능성의 관점에서 CAS와 MBX 기능 간의 의존성을 되도록 피하는 것이 업그레이드에서 독립성을 보장하고 버전간 상호작용도 더 용이하게 하므로, 고객의 입장에서는 업그레이드와 공존이라는 시나리오를 단순하고 유연하게 해준다는 점이 중요합니다.

 

개발 유연성의 관점에서 이러한 변화는 CAS에서 Exchange의 MBX와 동일한 위치에 있어야 한다는 요구사항에서 자유로움을 의미합니다. 대다수의 고객은 동일한 사이트에 이들 서버를 두지만, 일부 대규모 조직에서는 CAS를 통합하거나 MBX를 통합하는 유연성을 원할 수도 있습니다.

 

또한 Exchange Server 2013의 사서함 서버는 RPC CA, OWA, RPC proxy, transport, UM 같은 데이터 처리와 렌더링, 저장하는 모든 컴포넌트를 제공합니다. 클라이언트는 직접 MBX 서버에 연결하지 않으며, 연결은 CAS를 통해 이뤄집니다.
 
새로운 MBX 서버는 Exchange 2010과 DAG에서 제공한 기능을 한 층 더 진화 시켰고, MBX 서버의 컬렉션은 HA 유닛을 형성합니다.

Comment +0

Exchange Server 2010에서 CAS 역할을 하는 서버에서 SSL 통신 채널을 구축하기 위해서는 CAS에 인증서를 할당해야 합니다. 인증서는 유료의 공용 인증서를 사용해도 되고, 아주 약간의 불편을 감수 한다면 사설 인증서를 사용해도 됩니다. 사설 인증서를 사용하는 경우, AD 인프라에서 인증기관이 설치되어 있어야 합니다. 

 

지금 부터 CAS에 인증서를 할당하는 단계를 설명하겠습니다.

 

1. CAS의 EMC에서 해당 서버를 선택한 후 오른편 [작업]창에서 [새 Exchange] 인증서를 선택한다.

 

 

2. 인증서 이름을 입력한다. 예, mail.dokyun.pe.kr

 

 

3. 하위 도메인을 추가하지 않는다면, 아래 그림은 넘어간다.

 

 

4. 인증서에 들어갈 이름을 입력한다.

필요한 CAS의 FQDN과 autodiscover 주소, 대표할 일반 이름을 설정한다. 여기서는 mail.dokyun.pe.kr을 일반 이름으로 설정했다.

 

 

5. 조직과 위치에 대한 정보를 입력하고, 인증서 요청 파일을 저장할 경로에 파일 확장자 .req를 포함한 파일 명을 입력한다.

 

 

6. 구성 요약 내용을 확인하고 모든 정보가 제대로 입력되었다면, [새로 만들기]를 클릭해 인증서 요청 파일 생성을 시작한다.

 

 

7.  인증서 요청 파일 생성이 완료되면, 요약 내용을 확인하고, 필요한 경우 사용된 파워셸 명령을 복사해 두자.

 

 

8. 이제 만들어진 인증서 요청 파일을 루트 CA 서버로 가져가서 인증서를 생성해야 한다. 인증 기관의 인증서 서비스에 접속하고 다음 그림처럼 [인증서 요청] 이라는 하이퍼링크를 클릭한다.

 

 

9. 인증서 요청 섹션에서 [고급 인증서 요청]이라는 하이퍼링크를 클릭한다.

 

 

10. 고급 인증서 요청 섹션에서 [Base 64 인코딩 CMC 또는 ~] 하이퍼링크를 클릭한다.

 

 

11. 앞서 만든 인증서 요청 파일을 노트패드로 열어서 내용을 복사한 뒤, 아래 그림의 [저장된 요청] 항목에 붙여 넣는다. 또한 인증서 템플릿 타입을 적절히 선택한다. 모든 구성을 완료했다면 [제출] 버튼을 클릭한다.

 

 

12. 이제 [인증서 다운로드] 하이퍼링크를 클릭해 만들어진 인증서를 다운로드하여 저장한다.

 

 

13. 다시 EMC로 돌아가서 앞서 수행했던 인증서 요청을 마무리할 차례다. [서버 구성]에서 [대기 중인 요청 완료]를 선택한다.

 

 

14. 다운로드한 인증서 파일의 위치를 입력한다.

 

 

15. [대기 중인 요청 완료] 대화 상자에서 요청을 완료한다.

 

 

16. 마지막으로 인증서를 사용할 서버가 여럿이라면 한 꺼번에 선택해서 [인증서 서비스 할당]을 클릭한 뒤 [인증서에 서비스 할당] 대화 상자에서 "인터넷 정보 서비스"를 선택한다.

 

 

 

Comment +0

이 내용은 Exchange 2010을 도입할 때 메일 사서함을 위한 저장소 디스크 용량을 산정하는 방식을 다룹니다.

 

1. 메일 사서함 저장소 디스크 도입을 위한 공통 기준 정의

 

☞ 사용할 사서함의 수 결정 (예, 32,000 개 사서함)

☞ 서버당 호스팅할 사서함의 수 결정 (예 8대의 서버인 경우, 4,000 사서함 / 서버)

이 때 도입할 서버의 스펙에 따른 호스팅 가능한 사서함의 수를 결정한다. Jet-Stress 테스트를 통해 서버의 성능을 평가해보는 방법으로 서버의 호스팅 가능 사서함 수를 산정한다.

☞ 사용자당 메일 사서함 제공 용량 결정 (예, 1GB = 1024 MB)

 

2. 사용자의 유형 분류.

 

보통 다음과 같은 표를 통해 사용자의 메일 사용 유형을 분류하는데, 이전에 해당 조직에서 메일의 사용 통계를 참고하면 쉽게 유형을 파악할 수 있다.

 

 

 

해당 기업의 메일 사용 경향을 통계분석한 결과 대략 평균 하루에 수신: 40개 / 발신: 60개 정도로 메일 중심의 업무가 진행된다고 칠 경우, 이 조직은 Extra Heavy 유형의 사용자료 분류할 수 있고 이를 근거로 사서함 서버의 메모리 용량을 산정할 수 있다.

 

3. 저장소 디스크 용량 계산식과 RAID 형식

 

☞ 실제 메일 DB와 로그가 저장되는 디스크의 형태로 RAID 1+0 구성

MDB + 로그 공간: RAID 1+0

 

☞ 복원을 위한 공간 RAID 5로 구성

 

☞ 디스크 저장 단위 (보통 4kb 단위인 경우 2Kb 데이터라도 4Kb 차지)를 고려한  20%의 여유 공간 확보

Database Growth Factor = 20%

 

☞ 각종 트랜잭션 로그를 위한 별도 공간 필요 (40 Sent / 160 Received)

Transaction Log Space Factor = 15%

 

☞ 순수 여유 공간, 일반적인 모니터링 기준 (80%)에 맞춰 20%의 여유 공간 산정, 여유 공간 부족시 관제에서 경고

Free Space Factor = 20%

 

☞ MDB 복구를 위해 작업용으로 필요한 영역, RAID 5로 구성

Restore Space Factor = one of Active (MDB)

 

4. 필요한 저장소 디스크 용량 계산 사례

 

앞서 설정한 공통 기준에서 예시한 값으로 스토리지 공간을 계산해보자.

 

☞ 사서함 서버 1대 장애 발생 시 7 대의 서버로 운용이 가능한 저장 공간 계산

1024 MB * 4000 MBX * 2 (Active, Passive) = 8.2 TB

 

☞ Database Growth Factor 20%

8.2 TB * 1.2 = 9.84 TB

 

☞ Transaction Log Space Factor 15%

9.84 TB * 1.15 = 11.316 TB

 

☞ Free Space Factor 20%

11.316 TB * 1.2 = 13.58 TB

 

☞ Restore Space Factor

572 (4000 MBX / 사서함 DB 파티션 Active 파티션 7개) * 1024 MB = 0.59 TB

 

☞ 서버당 전체 필요 Usable 크기 = 13.58 TB+ 0.59 TB =  Usable 14.17 TB / Server

 

▣ 총 디스크 소요량: 14.17 TB * 8 Server = 114 TB

 

 

Comment +0

이 글은 우리가 받는 메일 한 통은 보이는 내용이면에 그 메일 한 통을 보내기 위해 시스템간에 많은 상호작용이 있다. 그러한 상호작용이 고스란히 보존된곳이 메일의 헤더다.

이번에는 메일의 헤더를 열어서 그 구조를 잠깐 음미해보자.

 

이 부분은 한 통의 메일이 네트워크의 어떤 경로를 통해 전달되었는지를 보여준다.

 

"Received from"이라는 부분이 반복되어 나타나는데 이 반복 부분은 거꾸로 추적 하면된다.

 

즉, 이 메시지는 southpacific 서버를 출발해 redmond 서버를 거쳐갔음을 알 수 있다. 그리고 중간에 마이크로소프트의 Forefront 안티바이러스 월(파란색 상자)을 지나간것도 보인다.

 

이렇게 전달된 메일은 수신자의 메일 서버에 메일이 배달된것까지의 기록이다.

 

 

이 부분은 전자 메일을 보냈을 때 microsoft.com 시스템에 있는 표면사의 메일 주소를 나타낸다.

 

 

Message-ID는 메일 서버로 전달된 각 메일을 고유하게 구별하기 위해 붙이는 고유한 값이다. 이 값을 통해 메시지를 받은 후 수정/삭제 여부를 확인할 수 있다.

 

메일이 마임(MIME) 형식임을 나타낸다. 메시지에 여러 형식이 혼합되어 MIME을 이용해 두 부분으로 나눴다.

Forefront Online Protection for Exchange(FOPE)의 스팸여부 확인

메일 계정 설정시 답장 주소. 보낼때 주소와 답장 주소를 다르게 할 수 있다

비 공식적인 메일의 도착시간을 알려준다. 이 경우는 메시지가 최종microsoft.com을 떠난 시간이다.

 

메시지들은 여러 패킷으로 나뉘어 수 많은 서버를 통해 다양한 경로를 거쳐간다. 헤더에는 그 메시지가 통과하는 서버들만 기록하는 것이며 각각의 경로를 따라 라우터와 스위치 정보까지 기록하지는 않는다.

 

이번 글은 메일 헤더를 편의상 7개 부분으로 나누어 기본적인 헤더 구조를 살펴봤다. 다음 번 기회에 메일헤더를 실제 RFC와 비교해서 조금 더 자세히 다뤄 보겠다.

 

메일 헤더를 찾는 방법은 이전 글을 참고하면 된다.

 

Comment +0

우리가 받는 전자 메일에는 메일을 보낸 사람과 메일이 거쳐온 경로, 메일의 내용 등 여러가지 정보가 들어 있다. 흔희 우리가 사용하는 아웃룩에서 이런 메일 헤더 정보를 쉽게 볼 수 있다. 메일 헤더 정보를 보는 방법은 다음의 두 가지 단계를 따르면 된다. 이 글은 아웃룩 2010을 기준으로 설명한다.

 

1. 아웃룩을 실행하고 헤더를 보기 원하는 메일을 더블 클릭한다. 별도 창으로 팝업된 해당 메일의 상위 메뉴에서 [파일]을 선택한다.

 

 

2. 해당 메일의 [파일]-[정보]를 선택하면 오른편 창에 4가지 주요 기능을 제공한다. 여기서 [속성]이라는 사각형 아이콘을 클릭한다.

 

 

3.  [속성] 창의 아래부분에 있는 [인터넷 머리글]이라는 영역이 이 메일의 헤더 정보를 담고 있는 부분이다.

 

 

Comment +0

1. 기본 오프라인 주소 속성

 

 

 

 

2. OAB 속성

 

 

 

Comment +0

 

1. DAG 클러스터 가상 어댑터의 네트워크 바인딩 순서 조정

Windows Failover Cluster 를 이용한 DAG 구성시 생성되는 Cluster Virtual Adapter 의 네트워크 바인딩 순서를 낮추려면 다음의 작업을 수행한다.
 - MSDN Code Gallery : http://code.msdn.microsoft.com/nvspbind 에서 nvspbind 를 다운로드 받는다.
 - 압축 해제 후 nvspbind.exe 파일을 Mailbox Server (DAG Member) 에 복사한 후 다음 명령을 실행한다.

 - 현재 바인딩 순서를 확인한다 (대부분 Virtual adapter 의 아이피는 169.254 대역의APIPA Address 가 할당 된다.)

 Nvspbind.exe /o ms_tcpip

 

다음의 그림에서 보이는 Local Area Connection* 9 이 Virtual adapter 이며, 바인딩이 최우선으로 설정되어있다.

 

 

 

☞ Local Area Connection* 9 바인딩 순서 낮추려면 다음의 명령을 수행한다.
Nvspbind.exe /- “Local Area Connection* 9” ms_tcpip


제일 아래로 내리기 위해 동일 명령을 두번 실행하면 된다.

 

참고 :  Exchange Queue & A: Gone to the DAGs 

 

2. Link-Layer Topology Discovery 기능 활성화

Heartbeat 이라고 설정된 NIC 은 Replication Network 으로 사용되므로 Replication Network Adapter 의 권장 구성요소인Link-Layer Topology Discovery Mapper I/O Driver 및Link-Layer Topology Discovery Responder 기능을 활성화한다.

 

 

 

참고: Planning for High Availability and Site Resilience 에서 Replication Network Adapter Configuration 항목 참고

 

 

Comment +0


▩ Exchange Server에서 발송하는 기본 메시지

1. 경고 메시지
사서함에서 불필요한 항목을 모두 삭제하고[지운 편지함]폴더를 비워 사서함 크기를 줄이십시오.

2. 메일 발송 제한 메시지
이제 사서함에서 메시지를 보낼 수 없습니다. 사서함에서 불필요한 항목을 모두 삭제하고[지운 편지함]폴더를 비워 사서함 크기를 줄이십시오.

3. 메일 수 발신 제한 메시지
이제 사서함에서 메시지를 보내거나 받을 수 없습니다. 사서함에서 불필요한 항목을 모두 삭제하고 [지운 편지함]폴더를 비워 사서함 크기를 줄이십시오.

[그림 1] 사서함 용량 관련 메시지

▒ Exchange Server의 경고 메시지 처리 방식

1. Exchange Server에 Text 형태로 Identity 와 함께 저장되어 있음, Text 내용을 변경할 수 있다.

2. 필요 시점에 Identity 를 호출하여 해당 메시지를 본문에 추가 후 발송 처리한다.

Identity : ko\WarningMailbox
Text     : 사서함에서 불필요한 항목을 모두 삭제하고 [지운 편지함] 폴더를 비워 사서함 크기를 줄이십시오.

Identity : ko\ProhibitSendMailbox
Text     : 이제 사서함에서 메시지를 보낼 수 없습니다. 사서함에서 불필요한 항목을 모두 삭제하고 [지운 편지함] 폴더를 비워 사서함 크기를 줄이십시오.

Identity : ko\ProhibitSendReceiveMailBox
Text     : 이제 사서함에서 메시지를 보내거나 받을 수 없습니다.사서함에서 불필요한 항목을 모두 삭제하고 [지운 편지함] 폴더를 비워 사서함 크기를 줄이십시오.

▨ 커스트마이징 고려사항

1. 시스템 설정 값을 변경할 수 있다.
2. 경고 메시지 발송에 대한 설정 항목이 하나뿐임으로 두 개의 경고를 발송할 수 없다.
3. 사서함 용량에 따라 경고메시지를 구분하여 처리하는 것은 불가능 하며, 문구에 용량을 표시하지 않고 사용해야 범용적으로 사용이 가능하다.
4. URL을  추가할 수 있지만, Text 형태로 본문에 삽입된다.

[그림 2] URL 추가 모습

5. 경고 메시지에서 그래프로 보여지는 사서함 용량 표시는 보내기 금지 용량이 표시된다. (그림 1, 그림 3 참조)


[그림 3] 저장소 제한 설정

Comment +0


스마트폰에는 회사 Exchange의 메일을 볼 수 있도록 설정할 수 있으며, 폰을 분실한다면 회사메일이 외부에 노출되어 보안상 문제가 발생할 수 있다. 스마트폰과 회사 Exchange의 연동은 해당 스마트폰에서 지원하는 Active Sync를 이용한다.
이때 관리자에게 연락하거나 Exchange의 웹 메일 즉 OWA에서 회사메일을 스마트폰에서 볼 수 없도록 설정하여 보안상 위험을 줄일 수 있다.
 
다음은 OWA를 이용해 분실된 스마트폰의 데이터를 지우는 방법이다. 이것은 Remote Wipe라고 하는 기능이며, 이 기능을 실행할 경우 해당 스마트폰의 모든 데이터를 지울 뿐만 아니라 기기 자체를 완전 초기화 한다.

1. 먼저 웹 아웃룩으로 접속해 우측 상단에 있는 [옵션] 메뉴를 클릭한다.

2. [전화] - [휴대폰] - [장치 데이터 지움]을 클릭한다. 이 때 분실된 핸드폰이 네트워크에 연결되면  내 폰에 저장된 메일데이터를 강제적으로 삭제하게 된다.



Comment +0


Exchange Server 2007의 경우 SP2를 설치할 경우 스키마 확장이 반드시 필요하다. 이 부분이 안되어 있을 경우 셋업 과정에서 스키마 확장을 한다. 하지만 이런 경우의 권고사항은 항상 작업은 분리해서 하는 것이 좋다는 점이다.

서비스 팩 2를 적용할 때 윈도우 보안 업데이트 이후에 CAS-->MBX 순으로 실시한다.

세부적인 절차는 아래 기사를 참고해 다음과 같이 순서를 잡는다.

Exchange 2007 Service Pack 2 Prerequisites

  1. Extend the Schema
  2. Prepare Active Directory
  3. Install Windows Installer 4.5
  4. Uninstall Interim Updates

SP2 적용을 위해 참고할만한 두 가지 인터넷 리소스는 다음과 같다.

1. Exchange 2007용 최신 서비스 팩 또는 업데이트 롤업을 설치하는 방법
2. Exchange 2007 SP2 - Upgrade + Fallout

Prerequisite Environment Changes
As usual, before a major Service Pack - there are a list of prereq's for the install. For Exchange 2007 SP2, the details and pre-req's are outlined well on the EHLO blog.


다음


라이선스 동의 후 다음


이제 다시 시작.

 


Now, let's extend the AD Schema. What? Yup, Exchange 2007 SP2 includes a Schema extension to support Exchange 2010. You can read more about that on the EHLO blog. Excerpt below:

For those of you that haven't been keeping abreast of the work we are doing in Exchange 2010, Exchange 2007 SP2 is required for coexistence with Exchange 2010. This enables support for coexistence like ensuring Exchange 2010 mailbox Autodiscover requests that are received by CAS2007 are redirected to the appropriate CAS2010 and enabling ActiveSync proxy support between CAS2010 and CAS2007.

Therefore, to minimize the number of times you have to perform a schema extension, we decided to include the Exchange 2010 RTM schema. For those of you that are planning to upgrade your Exchange 2007 environments to Exchange 2010, this will reduce the number of schema extensions you have to perform. Once you extend the schema with Exchange 2007 SP2, you will not have to extend the schema with Exchange 2010 RTM.

However there are direct benefits with deploying the Exchange 2010 schema with Exchange 2007 SP2. One of the new features in Exchange 2007 SP2 is the ability for administrators to control certain settings at the organization level that originally were configured via configuration files; the schema changes have enabled us to move some of these settings now into AD. Expect to hear more about this in a future blog post.

Anyway, let's start. Drop to an administrative command prompt.



"setup /PrepareSchema"를 실행하고 대기



끝나는데 대략 20-25분 걸린다.
이제 액티브 디렉터리를 준비하자. 다시 관리 명령 프롬프트로 돌아간다.

"setup /PrepareAD"를 실행하고 대기


몇 분 정도 걸린 후 작업 완료.


이제 Exchange 2007 SP2 Setup 프로그램을 시작한다.


[설치]를 선택한다.


내용 확인 후 [다음]


라이선스 동의


SP2 인스톨러에서 몇 가지 준비사항 체크. 안티바이러스 프로그램 이나 백업 에이전트 종료. [업그레이드] 클릭후 앉아서 커피한잔 하면서 지켜본다.


대략 30여분 걸려 끝나고 나서 다시 서버를 부팅한 다음 클라이언트를 연결하고 메일 흐름을 체크 한다.


OWA Redirect
I have a simple index.asp redirect set so if you go to http://mail.domain.com - it will automatically redirect to the HTTPS OWA https://mail.domain.com/owa landing page.

<% Response.Redirect "https://mail.domain.com/owa" %>

For some reason, Exchange 2007 SP2 broke my redirect. It didn't change the file itself, but, it did adjust the security settings of my "Default Web Page" inside IIS. I re-adjusted those and my OWA redirect worked again.


Comment +0


1. 모바일 연동 암호화
아래 테크넷 사이트에서 모바일 암호화 옵션 관련한 내용을 확인할 수 있다.

http://technet.microsoft.com:80/en-us/library/bb123484.aspx

 Device encryption enabled  This setting enables encryption on the mobile phone. Not all mobile phones can enforce encryption. For more information, see the phone and mobile operating system documentation.

이 부분은 아래 화면의 "암호 필요" 옵션에 대한 설명으로, 휴대폰에 암호화가 필요한 경우 이 옵션을 선택한다. 이렇게 하면 휴대폰의 저장소 카드에 있는 모든 정보를 암호화 하여 보안이 강화된다.


2. 스마트폰 연동에서 첨부 다운로드 제한 정책이 걸린상태에서 폰에서 메일을 전달할 경우 첨부가 같이 전달될까?

다운로드 제한 정책을 걸고, 다운로드를 하지 않은 상태에서 fwd할 경우, 첨부물로 같이 메일로 보내진다. 다운로드 금지 정책은 모바일 기기에 다운로드를 금지하는 것이고, 메일은 서버에서 보내지는 것이므로 첨부물도 같이 전달이 된다.

Comment +0

많은 조직에서 Exchange 2010 도입을 고려하면서 어떤 장점이 있을지를 고민합니다.
이전 버전을 사용하는 조직에서 Exchange 2010을 도입해야 하는 이유는 다음의 장표 한 장으로 요약해서 보여 줄 수 있습니다.


조금 더 자세한 비교 자료를 원하면 메일 주소를 남겨주세요.

Comment +1

Exchange 2010에서 메일박스 아카이브를 구성할 수 있다. 이러한 구성을 하게되면 사용자 모르게 별도의 스토리지에 메일을 보관할 수 있고 사용자가 임의로 삭제한 메일도 보관되게 된다.

Exchange 2010에서 지원하는 아키이브와 보관 기능은 크게 두 가지 종류가 있다.

1. Personal Archive
  • 사용자에게 대용량을 보관할 수 있는 온라인 사서함을 하나 더 부여하는 방식
  • OWA와 아웃룩에서 모두 접근 가능하다 (이전 버전에서는 로컬 컴퓨터에 아카이브하는 방식이어서 OWA에서 접근이 불가)
  • 별도의 추가 라이선스가 필요 없으며 메일박스 저장소의 물리적 용량만 증설한다.
  • 물리적으로 분리된 스토리지에는 온라인 아카이브 사서함을 구성할 수 없다.


2. 저널링 (Journaling)
  • 허브 전송을 통해 들어오는 모든 메일에 대해 별도의 메일 사서함으로 사본을 보내어 보관한다.
  • Exchange 엔터프라이즈 CAL (Exchange Server 라이선스와는 다름)이 필요하다.
  • 저널링 전용 사서함 운영을 위해 별도의 물리적 서버를 추가 구성해야 할 수 있다.





Comment +0


마이크로소프트의 Forefront TMG를 사용해 특정 스마트폰의 익스체인지 액티브 싱크 연결을 차단할 수 있다. 이를 위해서는 우선, 익스체인지 CAS 서버의 IIS 로그에서 단말기 정보를 발췌한다. 다음 [그림1]은 애플의 ios를 사용하는 단말기의 로그만 추려 본 것이다.


[그림 1] ios를 사용하는 단말기의 로그

이제 TMG 서버에서 특정 URL 항목을 확인하는 차단하는 방법은 다음의 절차를 따른다.

1. [Publish Rule(Active Sync)]에서 오른쪽 클릭해 [Configure HTTP]를 선택 한다.
2. [Signatures] 탭을 선택한다.
3. [Add] 클릭
4. 아래 [그림2]의 [HTTP header]에 정확한 필드 이름 (CS(user-Agent)인지 IIS로그에서 정확하게 확인)과 [Signature]에  필요한 값들을 추가한다.


[그림 2] Signature 추가

Comment +2

  • 김승진 2012.01.14 19:23 신고

    근데 TMG에서 모바일 안드로이드만 막을 수 있는 방법은 없을까요????
    안드로이는 Linux로 찍혀서 제어하기가 싶지 않네요~~
    그리고 TMG도 VPN처럼 권한 제어가 됐음 좋겠어요~

  • 안드로이드도 제어할 수 있을것 같네요.
    비록 Linux로 나오더라도 세부 버전 정보 등을 비교하면 가능하지 않을까 싶은데, 일단 IIS 로그에 찍힌 내용을 먼저 분석해봐야 할 것 같네요.

    TMG도 목적에 따라 여러종류가 있어요. 지금 소개한 버전은 익스체인지용이라고 보면 더 정확합니다.


회의실 리소스가 이미 예약이 되어 있는 시간대에 다른 사용자가 리소스 사용을 요청하게 되면 [승인 보류중입니다.] 라는 리턴 메일을 받게된다. 이런 경우 이것이 승인 보류가 아닌 그 시간대에 예약을 하려 하면 reject가 되어버리도록 설정할 수 있다. 또한 보통 수락 혹은 보류 메일이 오면 [그림 1]과 같이 표시가 되는데, 이 때의 메시지도 바꿀 수 있다.


[그림 1] 수락 혹은 보류에 대한 표준 메시지

Exchange 2010의 관리 콘솔의 해당 회의실 메일박스 설정에서 [그림 2]와 같이 모임 요청 충돌 허용 옵션을 해제 한다.


[그림 2] 회의실 메일박스 설정

이후에 해당 회의실에 이미 일정이 있는 경우 사용 요청을 하게 되면 [그림 2]와 같은 거절 메시지가 오게 된다.


[그림 3] 일정 충돌로 인한 거절 메시지

이 때 거절 메시지에 별도의 추가 글귀를 입력하고 싶은 경우는 [그림 3]에서 보인 [자원 정보(Resource Information)] 탭의 [텍스트 추가(Add Additional text)] 체크 상자를 체크 하고 [추가 텍스트(Additional text)]란에 글귀를 입력한다.


[그림 4] 메시지 추가

추가 메시지를 넣고 나면 거절 메시지는 다음 [그림 5]와 같이 시스템 메시지가 변경되어 사용자에게 보내진다.


[그림 5] 사용자 정의 메시지 수신

Comment +0


Outlook에서 회의실의 일정을 볼 수 있도록 하기 위해 [그림 1]의 파워쉘 화면에서 해당 사용자에게 Reviewer 권한을 명시적으로 주면, Outlook에서 해당 회의실의 일정이 열린다.


[그림 1] 회의실 보기 권한 부여


[그림 2] 회의실이 표시된 아웃룩 화면

사용자가 아니라 그룹으로 권한을 줄 경우도 Add-MailboxFolderPermission으로 추가할 수 있다. 그룹도 다음 명령 처럼  -User명령어로 추가하면 된다. 단, Mail Enabled Group이어야 하며 Distribution List는 권한으로 추가할 수 없다.

Add-MailboxFolderPermission –Identity “User:\일정” –User NewGroup –AccessRights reviewer

위 명령어는 다음 UI에서 처럼 [사용권한]에 추가할 수있는 항목들을 의미한다.

[그림 3] 일정 속성에 권한 추가 화면

Comment +0


Exchange 2010에서는 고가용성 확보를 위한 클러스터링 구조를 데이터베이스 레벨에서 수행 가능하도록 디자인 아키텍처가 변경되었다. (DB 이중화를 위하여 최소 1개의 데이터 복제본 필요하. Disk RAID 구성하지 않는 경우, 안정성을 위하여 DB 복제본은 2 이상으로 구성하는 것을 권고) .
아키텍처 변경으로 인한 Data Storage 비용 절감을 위해 이전 버전 대비 디스크 구성 방식의 유연성을 추가로 제공한다.

이전 버전에서는 Mailbox Server Active-Passive 클러스터 구조를 이용해 고가용성을 지원하였기 때문에 휴면 상태의 Mailbox Server 존재(전체 서버의 가용성 측면에서는 단점으로 작용)하였으나, Exchange 2010 에서는 모든 Mailbox Server 상시 운영 상태로 존재한다.



Exchange 2010에서는 DR 센터 구축 , 별도의 서드파티 소프트웨어의 도움 없이자체 기능을 이용해 구성 가능하다.
DR
센터 구성에 사용되는 Exchange 2010 노드 스토리지 확보를 위한 비용만 추가된다. (다음 그림에서 San Jose 실제 운영 센터이고 Dallas DR 센터다.)


Exchange 2010에서는 시스템 장애 , 데이터 복구를 보다 신속하게 수행할 있도록 지원한다.
별도의 복제본(Data Redundancy) 통해서 가능하다.


 

Comment +0


1. Outlook의 오프라인 주소록(OAB) 관련 서버의 업데이트 주기, 사용자 client에서 다운로드 주기 메커니즘(outlook, owa 2가지 구분)

a. 서버의 OAB 업데이트 주기: 기본 오프라인 주소는 사용자 지정 일정에 따라 메일박스 서버에서 업데이트가 되고, 폴링 간격(6시간 마다)에 따라, CAS 서버로 배포됨.
b. Outlook 캐시드 모드: 기본 오프라인 주소는 최초 다운로드 완료 후, 24시간마다 업데이트 됨
c. Outlook 온라인 모드, OWA: 서버에 온라인으로 접속하므로 GAL을 조회.

2. 주소 캐쉬의 처리 메커니즘

a. Outlook 캐시 모드, 온라인 모드: 한번 조회된 사용자의 X500 주소는 이름 자동 완성을 위해, 클라이언트 머신에 nk2 파일로 저장 됨.
b. OWA에서는 사용자 사서함에 별도로 캐시가 저장됨.

3. 사용자가 수신자에 "홍길동"을 입력하는 순간 (cached mode로 oab가 존재하는 걸로 가정) outlook/owa가 주소를 가져오는 메커니즘

a. Outlook에서는 이름을 타이핑하는 순간, 이름 자동 완성을 위한 캐시 주소를 먼저 조회하고 없으면, 이름 확인 시, 캐시 모드 일 경우는 오프라인 주소록을, 온라인 모드일 경우에는 GC 서버에 접속하여 GAL을 조회한다.
b. OWA에서는 이름을 타이핑하는 순간, 이름 자동 완성을 위한 사서함에 저장된 캐시 주소를 조회하고 없으면, 이름 확인 시,  GC 서버에 접속하여 GAL을 조회한다.


▦ 주소록 다운로드 시나리오

[전체 OAB 다운로드]
1. 아웃룩 계정 처음 연결 시, 아웃룩이 구동 된 후 5분 후에 OAB Full Download를 시도
2. 기본적으로 아웃룩 상에서는 OAB가 다운로드가 되면 그 후, 정확히 24시간 후에 다시 한번 Download를 시도한다.
3. 만약, 아웃룩 저속 연결 시나 디스크 공간 부족 등의 제 3의 원인 발생 시 다운로드가 실패하면 성공할 때 까지 1시간 마다 한번 씩 업데이트 시도 한다.
4. OAB 버전을 확인 (ANSI/Unicode)해 서버가 지원하는 포맷으로 전체 다운로드
5. Long Gap (10일 이상 아웃룩 연결 없다가 연결 시 Download 시도)
6. 도구 – 보내기/받기 – 주소록 다운로드에서 “incremental” 부분이 체크 해제 되어 있을 때, 주소록 다운로드에서 확인을 누르면 OAB 전체 다운로드를 강제적으로 수행하게 됨.
7. F9를 눌러 보내기 /받기를 시도했을 경우 (OAB 다운로드 옵션이 선택된 경우)

[증분 OAB 다운로드]
1. 캐시 모드 사용을 가정해, OAB의 증분 다운로드는 전체 다운로드 후 무조건 24시간 후에 수행 한다.
2. 만약, 아웃룩 저속 연결 시나 디스크 공간 부족 등의 제 3의 원인 발생 시 다운로드가 실패하면 성공할 때 까지 1시간 마다 한번 씩 업데이트 시도 한다.
3. 도구 – 보내기/받기 – 주소록 다운로드에서 “incremental” 부분이 체크되어 있을 때, 주소록 다운로드에서 확인을 누르면 OAB 증분 다운로드를 강제적으로 수행하게 됨.
4. F9를 눌러 보내기 /받기를 시도했을 경우 (OAB 다운로드 옵션이 선택된 경우)

[OAB 파일 생성 주기 증가 시키기]

더보기


[주요 질문]

더보기

Comment +0


전체 사서함에 대해 송/수신 메일 전체를 저널링한다면 (저널링 보관 기관이 따로 없다면), 전체 시스템에 2배 가까운 부하가 걸린다고 보아야 한다. 저널링 기능이란 한 번의 메시지 트래픽에 추가적인 한 번의 트래픽을 더 발생시키기 때문에 2배의 메시지 트래픽으로 계산한다.

예를 들면  평균 메시지 사이즈가 50KB이고 사서함 당 Heavy 프로파일(20 Sent/80 received)이고 30일 동안 메시지를 보관하여야 한다면, 단순 계산만으로도 저널링만을 위한 사서함 공간으로 32000 * 50KB * 100 * 30 = 4.8 TB 이상의 사서함 용 디스크 공간과 추가적인 로그 공간 등이 필요하고, 네트워크 트래픽, 서버 부하 등이 고려되어야 한다.

Exchange 2010에는 법적, 감사 차원에서 Discover 기능/Legal Hold 등의 기능이 이미 들어가 있다. Exchange 자체에서는 추가 저널링은 Ent-CAL(엔터프라이즈 CAL)을 필요로 하므로 이를 사용하지 않고, 이미 내장된 이러한 기능을 활용하고, 추가적인 저널링 부분은 전용의 3rd-party 솔루션을 이용하는게 나을 수 있다.

Discovery 기능에 대한 추가 설명 자료
1. Exchange 2010 E-Discovery (Multi-Mailbox Search)
2. 여러 사서함 검색 이해

▣ RPC와 HTTPs 네트워크 트래픽 비교
1. Exchage Server 2007 내용이나 Exchange Server 2010과 근본적인 차이는 없음, (http://msexchangeteam.com/archive/2008/04/10/448668.aspx)

2. Exchange Server 2003의 경우 클라이언트 트래픽 비교
(http://technet.microsoft.com/en-us/library/cc164325(EXCHG.65).aspx)

 

Comment +0


다음과 같은 Exchange 2010의 MMC 허브 전송의 [전역 설정]을 통해 수신되는 메시지와 발송하는 메시지의 최대 크기를 설정할 수 있다.

 


위 설정을 보면 해당 메일 서버를 사용하는 사용자 입장에서 최대 수신은 30 MB, 발송할 때는 13MB까지 인것으로 생각하기 쉬우나, 사실 위 전송 설정의 전송 제한 기능의 원래 취지는 다르다.

메시지 수신시 외부,내부와 상관없이 Sender 보낸 메시지는 Exchange서버를 거쳐 Recipient에게 도달한다.

다음과 같은 흐름이 되는 것이다.
Sender -> Exchange Organization -> Recipient

메시지 수신시에 MaxSenderSize 제한값은 모든 Sender(외부,내부) 대해서 적용된다그런 다음 MaxReceiveSize 설정값이 각각의 Recipients 적용된다.

MaxReceiveSize값이 MaxSenderSize값을 덮어쓰는 것이 아니라 각각 순서대로 실행되는 것이다.

예를 들어 위의 그림과 같은 설정에서 20MB 파일을 전달한다고 가정 해보자.

MaxSendSize : 13MB

MaxReceiveSize : 30MB

Send/Receive Connector : 100MB

 

메시지의 처리 과정은 다음과 같다.

1. 수신 커텍터에서는 최대100MB 허용하므로 수신조건에 맞기 때문에 메시지는 통과하여 조직으로 Inbound 된.

2. Sender 보낸 메시지의 크기를 체크합니다. MaxSendSize 13MB이지만 실제 메시지는 20MB이기 때문에 수신조건에 맞지 않는다.

3. MaxReceiveSize 30MB이고 수신자에게 따로 개별 수신메시지 제한이 없으므로 2 조건은 만족한다.

     4. 해당 메시지는 MaxSendSize제한에 걸려 Sender에게 반송됩니다.

 

결론 적으로 MaxSendSize제한값은 메시지를 보낼 적용되는 부분이 아니라 메시지를 보내고 받을 Sender 대하여 항상 체크되는 항목이다마찬가지로 MaxReceiveSize 제한값도 메시지 송수신시 모두 적용되는 항목이다.

 

이외에 다른 변수로는 외부에서 전송된 Native메시지는 Exchange서버에서 인코딩되고 디코딩되는 과정에서 최대 33%까지 메시지가 원본보다 커질수 있다. 그 때문에 30MB제한설정 환경에서 23MB이상 크기의 메시지는 정상적으로 수신되지 않을 있다.
 

[아웃룩을 이용해 메일 발송 전에 보낼 수 있는 메시지의 크기를 체크할 수 있다?]
클라이언트의 종류 또는 외부/내부등 환경에 따라서 메시지가 송수신되면서 메시지 크기를 체크하는 방법은 다를 수 있다. 외부에서 보내는 메일일 경우 수신자 서버의 메시지 크기제한값을 알 수 없기 때문에 메시지가 수신되면서 Transport 단에서 메시지 제한값을 Check하여 메시지를 수신할지 말지를 결정한다.

내부에서 Outlook으로 전달하는 경우 당연히 서버의 메시지 크기 제한값을 읽어와 Outlook에서 발송전에 메시지를 보낼 수 있는지 없는지 확인할 수 있다. 하지만 모든 Outlook버전이 그렇진 않다. Outlook 2003 서비스팩2 이하의 버전에서는 Outlook에서 첨부시에 첨부파일이 서버제한값에 걸리는지 체크되지 않고 외부에서 발송하는것처럼 메시지가 서버에 인입된 다음에 메시지 크기제한을 체크하게 된다.  때문에 Outlook 2003 SP2이하버전에서 1GB가량의 큰 메시지를 서버로 전달하면서 서버에서 메시지를 처리하는동안 서버의 리소스 사용량이 늘어나 버전 버킷으로 인한 메시지 송수신 장애등의 문제를 겪을 수가 있다. 그래서 서버에서 버전필터를 통해서 이러한 Outlook 버전의 연결을 금지시키기도 한다.

결론적으로 메시지 송수신시 서버의 Transport 제한값을 모두 Check 해야 한다. Outlook과 같은 Smart Client의 경우 서버의 제한값을 전송전에 체크해 메시지 인입을 사전에 막을 수 있다. 하지만 Outlook 2003 SP2이전의 MAPI 또는 Non MAPI 클라이언트의 경우 이러한 부분을 메시지 발송전에 체크할 수 없으므로 서버에서 인입되는 메시지에 대한 Size Limit 체크기능이 필요하다.

Comment +2

  • 유환기 2011.12.16 16:19 신고

    허브전송에서의 메시지 수발신 크기정책에 대한 글을 잘보았습니다. 제가 잘못알고 있었던 부분을 설명을 잘 해주셨네요...헌데 회사내 exchange서버에서 설정을 하는데 잘 안되서 이렇게 문의 좀 드립니다.
    회사내부사용자의 발신메일을 5M로 제한하고, 수신메일은 40M로 제한하려고 합니다.그리고 특정사용자는 해당 계정의 속성의 메시지크기제한만 설정하면 되는건지요?
    이렇게도 해보고 저렇게도 해보고 하는데 수신이나발신쪽 어느 한쪽이 정책이 안 먹더라구요... 실례를 무릅쓰고 이렇게 문의 드립니다.

  • 이씰뉴오 2011.12.20 15:02 신고

    Exchange Server에서 발신 및 수신 사이즈를 2개다 체크를 합니다
    그래서 2개의 설정 중에 하나의 조건에 걸리게 되면 그 설정 때문에 발송이 되지 않습니다.

    답변이 되었으면 합니다.


▦ 아웃룩 로깅 설정

아웃룩의 문제해결 로깅을 사용하려면, 아웃룩을 다음과 같이 설정한다.

1. 아웃룩 2007
[도구] | [옵션] |[기타] |[고급 옵션] | [문제 해결 로깅 사용(아웃룩을 다시 시작해야 함)]을 체크하고 [확인]을 클릭해 창을 닫은 후 아웃룩을 재시작한다.

2. 아웃룩 2010
[파일] |[옵션] | [고급] | [문제 해결 로깅 사용(아웃룩을 다시 시작해야 함)]을 체크하고 [확인]을 클릭해 창을 닫은 후 아웃룩을 재시작한다.

[그림 1] Outlook 2010의 옵션

로깅을 설정한 후 MAPI(Exchange)와 POP3, SMTP 전송에 대해 충분한 시간동안 로그를 수집하도록 한다. 수집된 로그는 아웃룩을 종료하고 가져오도록 한다. 로그파일의 이름은 OPMLog.log이다.

 로그 파일의 위치는 운영체제에 따라 위치가 조금씩 다른곳에 위치 한다.

1. Windows 7과 Windows Vista

c:\사용자\사용자 이름\AppData\Local\Temp\Outlook Logging

2. Windows XP

c:\Documents and Settings\사용자 이름\Local Settings\Temp\Outlook Logging

▩ RPCTrace 수집

아웃룩과 익스체인지의 RPC 접속에 대한 트레이스를 수집하기 위한 절차는 다음과 같다.

1. 아웃룩을 종료한다.

2. 탐색기를 실행하고 "C:\Program Files\Microsoft Office\Office12" 로 이동한다.

3. 원본 olmapi32.dll / emsmdb32.dll 파일을 다른 이름으로 변경한다. (삭제하거나 덮어 씌우지 않도록 주의. Trace file 만든 이후 다시 원복해야 한다.)

4. 아래 압축 폴더의 레지스트리 파일 적용.

5. 아웃룩 실행 후 문제 재현

6. 아웃룩 종료 후  "C:\tmp" 폴더의 RPC Trace 파일 수집

7. 아웃룩 파일 복구 및 디버그 파일 제거, 레지스트리 삭제
레지스트리는 아래의 키를 삭제 하도록 한다.
 

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC]

"RpcTraceEnabled"=dword:00000001

"RpcdumptoFile"=dword:00000001

"RPCOutputDir"="c:\\tmp"


▒  Netmon 수집 (클라이언트, 서버 동시 작업)

아웃룩 클라이언트와 익스체인지 서버간의 네트워크 통신으로 주고 받는 패킷을 캡처한다.

1. L4 장비로 인해 어떤 서버로 로드 밸런싱될 지 알 수 없으므로, 클라이언트 PC의 Host 파일에 특정 CAS서버 ip를 설정한 후 재현 한다.

2. 클라이언트와 서버에서 동시에 Netmon을 실행해 패킷을 수집한다.

3. 클라이언트와 서버의 IP를 기록해 놓는다.

Comment +0


[1] 개별 사용자 캐시 삭제 방법

OWA 내에서 자동완성 정보가 보이는 사용자를 Shift + Delete 키를 이용해 영구삭제 한다.

[2] 전체 사용자 캐시 삭제 방법

1. MFCMAPI 를 이용하여 해당 정보를 모두 삭제할 수 있다.

2. OWA 라이트 버전으로 로그온 해 [옵션] | [전자 메일 이름 확인] 부분에서 [최근 받는 사람 목록 지우기]를 선택해 삭제할 수 있다.

[그림 1] OWA 라이트 버전 로그온

[그림 2] 최근 받는 사람 목록 지우기

[3] Nickname Cache 기능을 EWS API를 이용해 구현하는 방법

1. Nickname Cache 기능을 사용하기 위한 EWS API 가 지원되지 않음
2. MS는 Nickname Cache 를 프로그램적으로 Access 하는 것을 지원하지 않음.

※ 추가 정보

Q) OWA 로그온 및 메시지 작성창을 띄운 상태에서 네트워크 케이블을 제거하더라도 Nickname Cache 가 사용가능하다. 그 이유는? 아래는 한국 MS로 부터 받은 답변임.

A) "IE 및 모든 관련 캐싱 정보를 모두 삭제하여도 동작하는 것으로 미루어 위 경우는 메시지 작성창을 띄우는 상태에서 Nickname Cache 정보를 메모리에 로딩하는 것으로 추정. Nickname Cache 는 메시지 작성창에서만 동작함으로 네트워크 케이블이 제거된 상태에서는 새로운 메시지 작성창을 띄울 수 없으므로 해당 정보를 사용하여 Nickname Cache에 활용할 수 없는 것으로 보임."

Comment +0

Nickname Cache 라는 기능은 최신 100 개의 사용자 정보를 각 사용자 사서함 기록해 OWA EAS (ActiveSync 서비스) 상에서 메시지 작성 시 자동완성 기능에 사용한다.

Nickname Cache는 각 사서함의 AutoCompleteCache 에 저장되며, 사용자가 UI 상으로 확인할 수 있는 방법은 없으나, MFCMAPI라는 도구를 사용해서 정보를 확인할 수는 있다. 이 도구를 사용해서 정보를 확인 하는 절차는 다음과 같다.

1.     MFCMAPI 를 수행하기 전에 Outlook Profile을 Cached Mode 가 아닌 온라인 모드로 정의해야 한다.

2. MFCMAPI 를 수행하여 [Session] | [Logon and Display Store Table]을 선택한다. (그림 1 참조)

[그림 1]

3. 프로필을 선택한다. (그림 2 참조)

[그림 2]

4. 해당 사용자 사서함을 더블클릭 한다. (그림 3 참조)

[그림 3]

5. [루트-사서함] 에서 마우스 오른쪽 버튼을 눌러 [Open Associated Contents Table] 을 선택한다. (그림 4 참조)

[그림 4]

6. [Message Class] 열로 이동해 "IPM.Configuration.OWA.AutocompleteCache"를 선택하고, "0X7C80102" 를 더블클릭 한다. (그림 5 참조)

[그림 5]

7. 아래 그림에서와 같이 Binary 정보 내에서 캐싱된 사용자들의 정보를 확인할 수 있다. (그림 6 참조)

[그림 6]

Comment +0


▣ 아웃룩에서 회의실 일정보기 권한 부여

사용자가 Outlook에서 해당 회의실의 일정을 볼 수 있도록 하기 위해, Reviewer 권한을 명시적으로 주면, Outlook에서 해당 회의실의 일정이 열수 있다. 그룹의 경우도 -User 명령어로 추가할 수 있다. 단, Mail Enabled Group이어야 하며 Distribution List는 권한으로 추가할 수있다.

[그림 1] 회의실 일정보기 권한 부여 Power Shell

▣ 회의실 리소스 예약 충돌실 거절로 처리하기

회의실 리소스가 이미 예약이 되어 있는 시간대에 다른 사용자가 리소스 사용을 요청하게 되면 [승인 보류중입니다.] 라는 리턴 메일을 받는다. 동일 시간대에 요청 시 승인 보류가 아닌 거절 메일이 가도록 설정하는 방법은 다음의 절차를 따르자.

1. 회의실 사서함 설정에서  충돌 모임 요청허용 옵션 Disable.

[그림 2] 리소스 정책 탭 설정

2. 리소스 사서함에서 요청 및 취소를 자동으로 처리하도록 설정

[그림 3] 리소스 일반 탭 설정

▣ 회의실 리소스 예약 메시지 변경하기

회의실 리소스 요청후 요청이 수락되었을 때 날라오는 메시지를 변경하는 방법은 다음의 절차를 따르자.

1. [리소스 정보] 탭의 [텍스트 추가] 항목을 체크하고 아래 텍스트 상자에 원하는 메시지를 입력한다.

[그림 4] 리소스 정보 탭 설정

Comment +0

Exchange 스팸 지수(SCL: Spam Confidence Leve)로 정크 메일로 분류한다.

SCL (Spam Confidence Level ) 구분 관련링크: http://technet.microsoft.com/ko-kr/library/bb124490.aspx
-1 인증된 내부사용자가 발송한 메일
0   정상메일
1 에 가까울수록 정상메일에 가까운 메일
9 에 가까울수록 스팸메일에 가까운 메일

경험치(게이트웨이-6 정크메일-5로 설정)
7이상은 거의 대부분 스팸메일
4이하는 대부분 정상메일
6일 때 정상적 메일이 스팸으로 걸려지는 경우 있음
5일 때 간혹 스팸메일이 정상 메일로 들어옴

Exchange 2003의 IMF 기능을 대체하는 Exchange 2010 HT의 "스팸 방지 에이전트" 기능이 활성화 되어 있을 경우 특정 보낸 메일 주소나 메일 도메인을 bypass할 수 있다.

현재 콘텐츠 필터 구성을 보려면 다음의 파워셸 명령을 이용한다.

Get-ContentFilterConfig

특정 메일 주소를 Bypass 하려면 다음과 같이 설정한다.

Set-ContentFilterConfig -BypassedSenders aaa@abc.com
http://technet.microsoft.com/ko-kr/library/aa996791.aspx

최대 100개까지 등록 가능하며, 여러개를 등록할 때는 쉼표로 분리한다.

Comment +0

ㅇFRAME: 디스크를 추가하는 박스
ㅇDISK PACK: 디스크 Array Group (ex. 146 GB * 4 : 4 개씩 한 그룹을 묶음)
ㅇCache: 디스크가 늘어나면 데이터가 많이 늘어나기 때문에 병목을 줄이기 위해 캐시 증설
ㅇFC(Fiber Channel) port: SAN 스위치와 스토리지를 연결하기 위한 광채널
ㅇLicense: 펌웨어에서 스토리지 용량이 늘어나는 만큼 구성가능하도록 해주는 라이센스로 TB당 하나씩 필요함.
ㅇ7D+1P: 7개의 디스크에 데이터를 넣고 1개의 디스크를 패리티로 사용하는 구성, 장애시 복구를 위함이며, RAID 5 방식중 하나. (ex. 3D+1P, 5D+ 1P ..)

Comment +0