프리지아 랩


▩ 문제 내용

Exchange 2010
서버와 OCS 2007 R2 통합을 위해서 필요한 작업들을 진행하였으나 OWA상에서 OCS Presence 정보등이 제대로 표시되지 않음.

▩ 해결 방안

1. Exchange 2010 CAS에 아래 순서로 설치되어있는지 확인한다.
 (1)  vcredist_x64.exe
(2) UcmaRedist.msi
(3) UcmaRedist.msp
(4)CWAOWASSP.msi

Microsoft Office Communications Server 2007 R2 Web Service Provider
윈도우2008R2를 위한 fix : Unified Communications Managed API 2.0 Redist (64 Bit) Hotfix KB 2282949

2. 다음의 파워셸 명령어로 OWA에서 OCS를 위한 구성을 확인한다.

Get-OWAVirtualDirectory -Identity "owa (default web site)" | *instant*

 

InstantMessagingCertificateThumbprint : 27C7F9EECE7A2BA672DA3FB6F5F05726377CEDAE

InstantMessagingServerName : ocspool.ktcorp.ktlab.lab

InstantMessagingEnabled : True

InstantMesasagingType  : OCS

3. Windows 방화벽에서 OCS 2007 R2 CAS간에 필요한 통신을 위해 IIS Worker Process(“C:\Windows\System32\inetsrv\w3wp.exe”)가 허용으로 추가되어있는지 확인한다.

4. OCS 2007R2 프론트엔드서버 속성에서 Authorized Host CAS서버의 FQDN 으로 정상설정되어있는지 확인한다.

5. 서버를 다시 시작한다.

6. 문제된 기능을 확인한다.


Comment +0


1. 먼저 [시작] 메뉴에서 다음 그림 처럼 "extra"를 입력한 후 실행한다.


2. [Select Task]를 클릭한다.


3. [Trace Control]을 클릭한다.


4. [Set Manual Trace Tags]를 클릭한다. (데이터를 생성할 경로를 지정해준다.)


5. 다음과 같이 체크하고 [Start Tracing]을 클릭한다.


6. EMC의 다음 위치에 있는 OAB를 업데이트 한다.


7. 약 1 분후에 데이터 수집 창에서 [Stop Tracing]을 클릭하고 해당 경로에 수집된 .etl 파일을 확인한다.

Comment +0


1. 문제 기술

문제 발생 환경: Windows Server 2008 R2 / Exchange Server 2010 SP1 / 8 Node DAG + FSW 쿼럼구성
내용: 이벤트 뷰어에 매 15분 간격으로 이벤트 오류 1069, 1558 (FSW 쿼럼 실패) 메시지 나타남.



2. 문제 원인

클러스터가 Witness 의 클러스터 디렉터리 핸들링을 할 수 없을때 발생함.

3. 문제 해결

☞ 쿼럼 방식을 Node Majority (노드 과반수) 로 변경.
☞ FSW 파일을 제거 한 후Node and File Share Witness (노드 및 파일 공유 과반수) 로 변경하여 FSW 파일을 재 생성.

 

해당 작업은 Exchange Server DAG 를 통해 작업되는것이 아니라 Windows Failover Clustering 에서만 반영된다.

Quorum 방식을 바꾸더라도, DAG FSW 를 인식하고 있다. 임시로 Node Majority 로 변경 후 반드시Node and File Share Witness 로 변경 한다.



▩ 위 문제와 관련해 검토했던 추가 액션 플랜.

1)   핫픽스 적용 (http://support.microsoft.com/kb/2612966)
해당 핫픽스는 공유파일 액세스시 Paged pool memory leak 현상에 대한 핫픽스 이다.
이 핫픽스 적용 후 동일한 이슈가 해결된 사례가 있다. 리부팅이 필요.

2) Cluster Virtual Adapter 네트워크 바인딩 순서 조절
Nvspbind 명령이 한글을 지원하지 않아 해당 작업을 레지스트리 수정을 통해 바인딩 순서를 조절 할 수 있다. Powershell 에서 다음 명령을 실행하여, Network Adapter GUID 값을 확인 한다.

gwmi Win32_NetworkAdapterConfiguration | where-object {$_.IPEnabled -eq "True"} | ft Description, SettingID -auto

출력 결과 중 Description Microsoft Failover Cluster Virtual Adapter GUID 값을 확인 한다. 레지스트리 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Linkage 하위의 Bind 값을 열어 해당 GUID 를 제일 아래로 내린다.


Comment +0


1. 문제 기술
Exchange 2010서버와 OCS 2007 R2 통합을 위해 필요한 Action들을 진행하였으나 OWA상에서 OCS Presence 정보등을 볼수 없는 경우가 있다.

2. 문제 해결 단계

1)  Exchange 2010 CAS에 아래 순서로 설치되어있는지 확인한다.
vcredist_x64.exe
UcmaRedist.msi
UcmaRedist.msp
CWAOWASSP.msi

Microsoft Office Communications Server 2007 R2 Web Service Provider
윈도우2008R2를 위한 fix : Unified Communications Managed API 2.0 Redist (64 Bit) Hotfix KB 2282949

2) OWA에서 OCS를 위한 구성 확인을 위한 파워셸 구문

Get-OWAVirtualDirectory -Identity "owa (default web site)" | *instant*

 

InstantMessagingCertificateThumbprint : 27C7F9EECE7A2BA672DA3FB6F5F05726377CEDAE

InstantMessagingServerName : ocspool.ktcorp.ktlab.lab

InstantMessagingEnabled : True

InstantMesasagingType  : OCS

3) Windows 방화벽에서 OCS 2007 R2 CAS간에 필요한 통신을 위해 IIS Worker Process(“C:\Windows\System32\inetsrv\w3wp.exe”)가 허용으로 추가되어있는지 확인 한다.

4) OCS 2007R2 프론트엔드서버 속성에서 Authorized Host CAS서버의 FQDN 으로 정상설정되어있는지 확인 한다.

5) 서버 다시 시작.

Comment +0


▩ 증상

MS Exchange Server 2010 SP1 업그레이드 후 아웃룩 웹 액세스 서비스의 비정상 동작이 보고되어, 확인 결과 CPU 과점유 이슈가 발견되었음.

<-- SP1 업그레이드 후 버전 변화



 

▩ 원인 및 분석결과

1. CPU 점유율이 가장 높은 프로세스: MsFTEFD.exe
2. CPU점유율이 높은 시점에는 해당 프로세스의 동작중  초당 2000 ~ 4000 회 정도 아래의 레지스트리 Open을 시도하는 경우가 자주 발생함.
  ☞HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\Language\Korean_Default

3. 레지스트리 접근시 커널단의 AhnRghNt.sys드라이버에 의해 Check 됨으로써 CPU 점유율 증가함.
  ☞AhnRghNt.sys드라이버 load 기능: 스파이웨어검사, V3자체보호
4. MBX 서버에서 위의 기능 OFF한 결과
  ☞바이러스검사On, 스파이웨어 및 V3자체보호 OFF 한 결과 CPU 과점유 현상 발생안됨
  ☞스파이웨어검사 또는 V3자체보호 2개 중에 1개 기능만 On 하여도 CPU 과점유 현상 발생

5. 결론
  ☞ MsFTEFD.exe 프로세스에서 초당 2000~4000회 정도 레지스트리 Open시 커널단에 AhnRghNT.sys 드라이버에 의해 Check 됨으로써 커널단의 CPU가 과점유 됨.

▩ 조치 방안

MBX 서버에 바이러스검사 On, 스파이웨어검사 OFF, V3자체보호 OFF 적용

스파이웨어검사 OFF시 영향도: 일반적으로 스파이웨어의 경우 인터넷을 통해 감염 되기 때문에, 서버상에서 인터넷을 사용하지만 않으시면 안전함.
V3자체보호OFF시 영향도: Anti Virus 동작을 방해하는 바이러스에 감염될 경우 자체 보호(V3관련 레지스트리,파일,프로세스 접근제어)가 불가능

Comment +0


아웃룩과 익스체인지간의 MAPI 연결 실패가 일어나는 경우에 대한 마이크로소프트의 기술자료 입니다.
 

[MAPI Failure conditions. (Failover to RPC over HTTP/S)]

When an RPC fails or a connection is dropped, Outlook will attempt to reconnect the session.  If the server responds with Im not available or theres a network timeout, we will switch bindingsfrom RPC/TCP to RPC/HTTP.  These failures can happen for a variety of transient reasons, in addition to a small handful of known reasons.  Unfortunately, the transient reasons far outweigh the known ones, so its not easy to answer why or when this happens.  The simple fact is that networking layers in the OS may return errors when wireless is flaky, building routers are overloaded, the system is waking up from hibernation and network stacks are coming online in unpredictable orders, notifications fire to reconnect and encounter timing issues with other apps using the networking layers such as proxy server resolution, etc.  So, if the RPC/TCP and RPC/HTTP connections will both work from behind the firewall, you can expect to see a small percentage of your connections to the Exchange servers when you're behind the firewall, to be RPC/HTTP connected.  The only way to prevent this is to block RPC/HTTP from inside your firewall.  Then RPC/HTTP will always work outside (because RPC/TCP will always fail), and RPC/TCP will always work inside (because RPC/HTTP will always fail).

위 내용에 대해 번역이 필요하신 경우 댓글을 달아주세요.

Comment +0


▩ 현상 


*** Problem Description ***

RPC returned fault.. Status: 0x1C00001A nca_s_fault_context_mismatch

 

RPC is closing down this session and it can be for several different reasons

 

▦ 해결 방안


*** Resolution *** Jul 30 2008 6:04PM waynem

 

In this case there is a Proventia integrated security appliance in between the

remote client and the server and at the time of the failures there is a log on the

device. Proventia integrated security appliances unify multiple security

technologies on a single, engine to provide advanced intrusion prevention,

firewall, VPN, vulnerability assessment, antivirus, antispam and Web filtering

protection. This isn't specific to Preventia, any device that drops or blocks RPC

packets could cause the issue.

 

A second case was caused by a CISCO router upgrade and only broke communication

between one site while others worked fine.

 

 

Check for a filtering device or an issue crossing a router/switch either between

the server and the client or the server and the DC.

Comment +0


▩ 현상

OWA에서는 html 첨부 일부 태그와 스크립트가 제거됨. 예를 들면 금융기관에서 보내는 보안 명세서 등의 첨부를 열지 못하거나, 본문 이미지에 링크를 삽입해 보내는 경우 링크가 동작하지 않는다.

▣ 원인

 Exchange Safe HTML 기능으로 인해 위험성이 있는 태그와 스크립트가 제거됨.

▒ 해결 방법

 Exchange 2010 SP1에서 Safe HTML Filtering은 아래와 같이 파워셸에서 제어가 가능하도록 변경된다.
 

Safe HTML Filtering

Safe HTML filtering feature in previous Exchange versions can strip off certain email attachments upon download in OWA. We can avoid this by editing the web.config to include BypassOwaHTMLAttachmentFiltering and BypassOwaXmlAttachmentFiltering. Service Pack 1 has moved the settings to the OWA virtual directory, as well as OWA Mailbox Policy. The default value is False. As long as the attachment type is in the Force Save list, there will be no Safe HTML filtering applied on download.

[PS] C:\>Get-OwaVirtualDirectory | fl ForceSaveAttachmentFilteringEnabled

ForceSaveAttachmentFilteringEnabled: False

 

[PS] C:\>Get-OwaMailboxPolicy | fl ForceSaveAttachmentFilteringEnabled

ForceSaveAttachmentFilteringEnabled: False

더보기

Comment +0


▩ 현상

Exchange 2010에서 허용된 크기를 초과하는 파일을 첨부하는 경우 아래 [그림1]과 같은 오류 메시지를 표시한다. 그러나 이전 Exchange 2007에서는 [그림2] 처럼 첨부 파일의 크기를 초과하는 경우 첨부 파일 크기 초과에대한 안내 메시지를 잘 표현하고 있다.

[그림 1] Exchange Server 2010

[그림 2] Exchange Server 2007

▩ 해결 방안


근본적인 해결 방법은 마이크로소프트에서 핫픽스나 서비스팩에서 해당 문제를 수정해야 하나,  IIS 의 특정 설정값을 추가 혹은 수정해줌으로써 해당 에러 메세지를 피해갈 수 있는 방법이 있다.

기본적으로 IIS 7.0 레벨에서 허용하는 최대 업로드는 30MB이며, 이를 web.config 내에서 OWA에 dedicated된 MaxRequestLength가 아닌 별도의 속성 값을 추가해줌으로써 IIS에서 리턴하는 404에러를 없앨 수 있다.

Web.config 내에 다음의 속성값을 추가 혹은 원하는 용량으로 설정한다.

<security>
            <requestFiltering>
                <requestLimits maxAllowedContentLength="700000000" />
            </requestFiltering>
</security>

실제 위의 설정은 IIS레벨에서  700메가까지 허용하겠다는 의미며, 이 경우 MaxRequestLength에 설정된 값을 초과 하더라도  최대 업로드 제한 용량을 초과한다는 메세지를 OWA에서 정상적으로 뿌려주게 된다.

자세한 내용은 아래 링크 참조.

IIS7 File Upload Size Limits

OWA

Comment +0


▒ 현상

익스체인지의 관리 콘솔에서 Exchange Activesync의 설정 중에 첨부 다운로드의 허용/비허용을 설정하는 부분이 있다(그림 1 참조). 첨부 다운로드를 비허용으로 설정할 경우 윈도우 모바일폰이나 안드로이드폰에서는 작동을 하지만 아이폰에서만 정책이 적용이 안됨.
 
[그림1] Exchange 2010 첨부 다운로드 허용/비허용 설정

▨ 원인

현재 애플의 아이폰 OS인 ios에서는 익스체인지의 정책을 따르지 않는것으로 확인.
액티브싱크 모바일 단말별로 현재 익스체인지의 기능을 어느 정도까지 사용가능한지에 대해서는 아래 링크를 참조하자.

 

▦ 해결 방안

마이크로소프트에서 현재 모바일 단말별로 이런 정책 이슈가 제기되고 각 단말에서 익스체인지 액티브싱크를 구현하면서 모든 기능을 맞춰 제공하는데는 한계가 있는 것으로 판단한것으로 보인다. 따라서 첨부 정책 같은 경우는  Exchange 2010 SP1에서 Server-side 정책으로 변경되었고, 해당하는 AttachmentsEnabled 정책이, Exchange 2010 SP1에서 Server-Side로 작동한다.

Comment +0


▒ 현상

OWA 에서 Office 첨부 문서를 열 때 [그림1]과 같은 오류메시지를 보이며, 문서가 열리지 않는다.
 
[그림1] 오류 메시지


▨ 원인

아래 기술문서에 언급된 바와 같이, Office 파일 명으로 일정 길이 이상 지정 시, 파일 열기를 하면 위와 같은 에러 메시지가 나타날 수 있다. 이는 Office 버전과 상관없다.

더보기

아래 두 파일 명을 가진 Office 파일을 첨부하여 문제 현상이 발생하는지 테스트 수행.

  • KT_IPTV TVRO_견적서_0528.xls‎
  • 6~7월 쇼폰케어 프로모션안(공지)_10052~1.xlsx

첫 번째 파일의 경우, 파일 경로를 포함한 길이가 218 character 이하이기 때문에 문제 없이 문서가 잘 열린다.  두 번째 파일의 경우, IE7 에서는 위 그림과 같은 에러 메시지를 보이며 문서가 열리지 않았고, IE8 에서는 문서가 잘 열리는 것을 확인 했다.

원인을 확인하기 위해 process monitor를 분석한 결과, IE 7의 경우, OWA 에서 문서가 IE temporary folder 로 임시 저장될 때 다음과 같이 UTF-8 형식으로 바로 저장되기 때문에, 파일 길이가 234 character, 즉 218 character 이상이 되어 문제가 발생하는 것을 확인 했다.

10:37:51.2813127 AM       iexplore.exe          952         4280       CreateFile              C:\Documents and Settings\user\Local Settings\Temporary Internet Files\Content..IE5\CHIT9G5Z\6~7%ec%9b%94%20%ec%87%bc%ed%8f%b0%ec%bc%80%ec%96%b4%20%ed%94%84%eb%a1%9c%eb%aa%a8%ec%85%98%ec%95%88%28%ea%b3%b5%ec%a7%80%29_100528.xls[1].xlsx                SUCCESS                Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: NCI, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created

반면, IE 8 의 경우, OWA 에서 문서가 IE temporary folder 로 임시 저장될 때 다음과 같이 UTF-8 형식을 ANSI로 디코딩해 저장하기 때문에, 파일길이가 139 character, 즉 218 character 이하가 되기 때문에 문제가 발생하지 않는다.

12:04:20.5150881 PM        iexplore.exe          6128       3808       CreateFile                C:\Users\certiware\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\TT4M3O1W\6~7월%20쇼폰케어%20프로모션안(공지)_100528.xls[1].xlsx         SUCCESS                Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: NCI, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Created

이 문제는 파일명에 ‘~’ 가 들어가든지 여부와 상관없이 위 기술문서에 언급된 길이 제한을 초과할 경우 발생한다.

▦ 해결 방안

 IE7 에서 다음 핫픽스를 설치한 다음, 레지스트리 값 변경 필요. 반드시, 아래 순서를 지켜서 작업해야 한다.

1. 아래 경로에서 IE7 latest cumulative update 를 다운받는다.
Cumulative Security Update for Internet Explorer 7 for Windows XP (KB982381)
http://www.microsoft.com/downloads/details.aspx?FamilyID=fc02fc7e-ee85-4377-b54c-012fa60a8c9c&displaylang=en
2. 명령 프롬프트에서 위 파일을 설치한 경로로 이동한다.
3. 아래 명령어를 사용하여 설치한다. 설치 후 재부팅 해야한다.
<package name>.exe /b:sp3qfe
(예) IE7-WindowsXP-KB982381-x86-ENU.exe /b:sp3qfe
4. 레지스트리 편집기에서 아래 키를 생성한 다음, 값을 아래와 같이 추가한다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ALLOW_LONG_INTERNATIONAL_FILENAMES

이름: iexplore.exe
형식: DWORD
값: 00000001

[그림 2] 레지스트리 편집기


Comment +0


▒ 현상

특정 사용자에게서 고급 검색 미표시. 아래 두개의 그림을 비교 해보면 [그림2]의 검색 상자 옆에 [<<] 표시가 없음.
 
[그림1] 고급검색 미표시

[그림2] 고급 검색 표시


▨ 원인

고급 검색이 표시되지 않는 사용자를 다른 데이터베이스로 이동하여 확인 결과 제대로 표시됨.
고급 검색이 표시되지 않는 사용자가 위치한 데이터베이스의 Catalog 파일이 손상된것을 확인함.


▦ 해결 방안

해당 문제가 발생하는 데이터베이스를 정상 복사본에서 재 복제 시행.

Comment +0


▒ 현상

1. DAG의 다른 노드로 이동 시 다음 이벤트가 발생하면서 Fail-Over 가 실패함

더보기


2. DB 상태에서 다음 내용 확인 가능함

더보기



▨ 원인

기본적으로 DAG를 구성하면 Public Network를 통해 Replication이 발생하며 서비스와 복제를 모두 제공하기에 네트워크의 대역폭이 충분치 않음. DAG로 구성된 Database에서 CopyQueueLength가 늘어나 Fail-Over 실패 발생


▦ 해결 방안


1. 다음 명령으로 Index Catalog 업데이트 후 정상적으로 Fail Over가 진행됨.

Update-MailboxDatabaseCopy -Identity DB0807\MAIL-MBX-08 CatalogOnly

2. DAG 복제 전용 네트워크 추가

더보기


3. Index 가 손상된 DBIndex Rebuilding

▩ 추가 정보

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

Comment +1


▒ 현상

EWS를 이용한 메일 첨부 기능을 개발 하였으며, 10MB 이상 첨부 메일을 보낼 때 아래의 오류 발생
 

오류 로그 Microsoft.Exchange.WebServices.Data.ServiceRequestException: Request failed. 원격 서버에서 (507) Insufficient Storage 오류를 반환했습니다. ---> System.Net.WebException: 원격 서버에서 (507) Insufficient Storage 오류를 반환했습니다.

   위치: System.Net.HttpWebRequest.GetResponse()

   위치: Microsoft.Exchange.WebServices.Data.ServiceRequestBase.Emit()

   위치: Microsoft.Exchange.WebServices.Data.ServiceRequestBase.InternalExecute()

   --- 내부 예외 스택 추적의 끝 ---

   위치: Microsoft.Exchange.WebServices.Data.ServiceRequestBase.InternalExecute()

   위치: Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()

   위치: Microsoft.Exchange.WebServices.Data.ExchangeService.CreateAttachments(String parentItemId, IEnumerable`1 attachments)

   위치: Microsoft.Exchange.WebServices.Data.AttachmentCollection.InternalCreateAttachments(String parentItemId, IEnumerable`1 attachments)

   위치: Microsoft.Exchange.WebServices.Data.AttachmentCollection.Save()

   위치: Microsoft.Exchange.WebServices.Data.Item.InternalCreate(FolderId parentFolderId, Nullable`1 messageDisposition, Nullable`1 sendInvitationsMode)

   위치: Microsoft.Exchange.WebServices.Data.EmailMessage.InternalSend(FolderId parentFolderId, MessageDisposition messageDisposition)

   위치: KTUC.WebApp.Mail.ezEmail.Remote.mail_intersend.sendmail(ExchangeService esb, XmlDocument xmldom) 파일 \\10.215.33.101\c$\NetModule\ezEmail\Remote\mail_intersend.aspx.cs: 


▨ 원인

Web.config 설정의 수정 필요.


▦ 해결 방안


1. %exchange install path%\V14\ClientAccess\exchweb\ews\web.config에서 다음의 두 가지 부분 수정

더보기

 

더보기


2. IIS Reset 실행

▩ 추가 정보

Comment +0


▒ 현상

메일 확인 후 읽음 메일이 발신인에게 회신 될 때 수신자가 메일을 읽은 시간이 실제 시간과 9시간 차이가 발생해 사용자가 혼란을 일으킴
 


▨ 원인

Exchange 2010 의 Time Zone 이 GMT +9 이고 클라이언트 또한 GMT +8 환경인 상황에서 실제 읽음 확인이 발생한 시간이 오후 10시 52분 경이나 수신 메시지 본문은 GMT 0 기준의 UTC 형태의 메시지로 시간이 표시됨.

  • Exchange 2007 에서도 RU5 에서 읽음 확인 시간에 대한 이슈 존재.
  • Exchange 2003 과 같이 클라이언트 Time Zone 반영이 어려워 서버의 Time Zone 을 반영하면서 반영한 Time Zone 정보를 읽은 확인 메시지의 시간 정보에 반영한 것으로 확인. http://support.microsoft.com/kb/940259/en-us  


▦ 해결 방안


Exchange 2010 에서도 UTC 로 반영되는 부분에 서버의 Time Zone 정보가 반영될 수 있도록 디자인 변경 요청이 완료되어 서비스팩 1에 반영될 예정.

▩ 추가 정보

1. Exchange 2007 환경
Exchange 2007 에서는 HUB 서버의 Time Zone +9 가 반영되어 아래와 같이 GMT+9 가 반영되어 시간이 표시됨


2. Exchange 2003 환경
클라이언트 PC 혹은 OWA 로 로그온한 사용자의 지역 설정에 따라 클라이언트의 Time Zone 이 자동계산되어 ‘읽음 확인’ 메시지의 시간이 반영됨.

Comment +1