민우아빠[사가]의 잼있는세상

해당 오류는 Online Deflag 작업시 사용자가 접근 혹은 작업중일때 발생 할수 있다고 합니다.
또한 특별히 크리티컬한 문제는 아니며, 그래도 해당 오류를 꼭 제거 하고 싶다면
저장소를 dismount 하고 offline deflagment 를 돌리면 문제는 해결된다는 군요.

아래 내용 참조하시길 바랍니다..
------------------------------------------------------------------------------
해외 익스체인지 포럼의 한유저는 아래 hotfix의 업데이트 이후 문제가 해결되었다고
합니다.
해당내용 ==> http://forums.msexchange.org/1173/m_200016000/tm.htm

http://support.microsoft.com/kb/926666
------------------------------------------------------------------------------
Error 0x6bb deleting unused grouped view from folder 1-13AADE7 on database "First Storage Group\Mailbox Store". Microsoft Exchange Information Store will try to delete the view again at the next maintenance interval.
--------------------------------------------------------------------------------
http://support.microsoft.com/kb/913126
--------------------------------------------------------------------------------
Adrian Grigorof (Last update 11/28/2008):
In theory, this event can be recorded with several types of error codes but in practice only Error code 0x6bb is encountered. Error code 0x6bb (in hex) corresponds to Error code 1723 (decimal) also known as "The RPC server is too busy to complete this operation.". See the link to Error code 1723 for some information about this particular error message.

Mihai Andrei (Last update 2/23/2008):
This problem occurs because a counter is incremented every time that a recurring meeting is modified. This counter eventually reaches a limit. This limit blocks additional modifications. See M943721 for a hotfix applicable to Microsoft Exchange Server 2003.

See M913126 for additional information about this event (it states that you can ignore any errors referencing code 0x6bb).

Ionut Marin (Last update 9/29/2005):
As per Microsoft: "An error resulted during an attempt to delete an unused restricted view. By default, unused views are deleted if not used for a specified amount of time. The folder may be in use by another process, or permissions are prohibiting this action. The view may have already been deleted". See MSEX2K3DB for more details.

From a newsgroup post: "Regarding the event 1173 from source MSExchangeIS, based on my knowledge, it happens when online maintenance is performed. It is not related to an IMAP logon issue.
Basically, we can simply ignore these events. When an Online maintenance is performed, users can still access the Exchange Stores, thus some data in the Store may be locked by these users and cannot be maintained. This is a normal behavior. If no user accesses this data in the next maintenance interval, it will then be maintained at that time. As to the "View", it refers to the detailed database structure of the Mailbox Store. We can also ignore it.
We also recommend you schedule a time to perform an offline defragmentation to maintain your Exchange environment. No user will be able to access the Exchange Server thus this is more effective:

1). In Exchange System Manager, right click the Store, click Properties. Then, copy the "Exchange database" path in the Database tab. For your information, my path is: E:\Program Files\Exchsrvr\mdbdata\priv1.edb.
2). Dismount the Store.
3). Click Start -> Run, type "cmd", and press Enter.
4). Use the "cd" command to enter the following directory "E:\Program Files\Exchsrvr\bin".
5). Enter the following command and press Enter:
esetuil /d "E:\Program Files\Exchsrvr\mdbdata\priv1.edb".
For your information, a successful output is similar to the following information:
   Initiating DEFRAGMENTATION mode...
   Database: E:\Program Files\Exchsrvr\mdbdata\priv1.edb
   Streaming File: E:\Program Files\Exchsrvr\mdbdata\priv1.STM
   Temp. Database: TEMPDFRG2880.EDB
   Temp. Streaming File: TEMPDFRG2880.STM
   Defragmentation Status (% complete).
6). Mount the Store again".  

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Exchange서버의 Database는 단순하게 .edb와 .stm 파일만을 의미하지 않습니다.
Log도 Exchange Database의 일부입니다. ^^;;;

하지만 불가피하게 Log를 삭제하게 됐다면 그리고 백업본이 없다면
다행히 .edb파일과 .stm 파일만은 무사(?)하다면

(eseutil /mh 옵션을 통해서 DB 상태가 dirty shutdown이 아니라 clean shutdown 상태일때...)

기본적으로 exchsrvr\mdbdata 아래에 있는 파일등 중

.edb와 .stm 파일만 남겨 두고 나머지 파일들은 다른 곳으로 이동하시고

DB 마운트를 시도하시고 DB를 마운트하기 전에 ESM에서 해당 store 등록정보-database 탭에서

"this database can be overwritten by a restore" 옵션을 선택하고

DB를 마운트하면  DB가 마운트 됩니다.

만약 위의 옵션을 선택하지 않을 경우 에러가 발생합니다. http://support.microsoft.com/?id=251403

위와 같은 복원을 offline restore라고 말합니다.

늘...항상 DB는 백업 받아 두시구요...

Log도 DB의 일부임을 잊지 마세요.

혹시 만약에 DB가 full나는 문제가 발생했다면 아래 KB를 참조해서 commit되 log만을 지워야 합니다.

http://support.microsoft.com/?id=240145

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

익스체이지 서버를 운영하다가 보면 한번씩을 격게되는 문제 입니다. 트랜잭션 로그가 일정 규칙으로 생성이 되는데 해당 넘버링이 일정 횟수 이상 올라가 게되면 더이상 파일을 생성하지 못하게 됩니다. 이로인해 서버의 장애가 생길수 있구요. 해결방법은 간단합니다. Exchange Storage 를 dismount 한상태에서 eseutil을 이용해 storage 에 반영된 log 정보를 확인하고 해당 로그폴더에 있는 .chk 파일을 다른곳으로 백업후 다시 mount 를 해주면 된다는 군요.. 어찌보면 간단하지만, 이걸 확인안하고 넘어가게 되면, 장애가 생길수 있으니 조심하셔야 겠죠~~~ 아래 내용과 마이크로 소프트의 Exchange 의 해당 기능 및 DB에 관련된 유용한 글도 같이 있으니 참고하세요~~~ -1018, -1019 및 -1022 Exchange 데이터베이스 오류 이해 및 분석 Store databases are dismounted without warning or users cannot log on to their mailboxes in Exchange Server 2003 or in Exchange 2000 Server How to Reset the Transaction Log Numbering Sequence How to Reset the Transaction Log Numbering Sequence The Exchange Transaction Numbering sequence is limited to one million.  When a server begins to approach this limit the following event is logged in the application event log.  If you have monitoring in place, it is an excellent idea to set up an administrative alert for this event. Event Type: Warning Event Source: ESE Event Category: Logging/Recovery Event ID: 514 Date: 08/28/2007 Time: 02:52:08 PM User: N/A Computer: ServerName Description: Information Store (7372) SG1: Log sequence numbers for this instance have almost been completely consumed. The current log generation is 919000 (0x000E05D8) which is approaching the maximum log generation of 1048559 (0x000FFFEF), there are 129559 (0x0001FA17) log generations left to be used. To begin renumbering from generation 1, the instance must be shutdown cleanly and all log files must be deleted. Backups will be invalidated. For more information, click http://www.microsoft.com/contentredirect.asp. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.   How long it takes to reach this limit is determined by how busy the Exchange server is.  If the limit is reached, the Information Store Service will stop.  The following procedure may be executed to reset the numbering sequence. Use this procedure with caution. 1. Dismount all Databases in the SG 2. Verify that the databases were in a Clean Shutdown state. To do this, follow these steps: a. In Exchange System Manager, right-click the first store in the storage group that has run out of transaction log files, and then click Properties. b. Click the Database tab, and then note the paths and the file names of the database files in the Exchange database box and in the Exchange streaming database box. Each Exchange database is composed of a paired set of files that have the .edb file name extension and the .stm file name extension. Repeat this step for each store in the storage group. c. At a command prompt, move to the Exchange Server bin folder. For example, move to the C:\Program Files\Exchsrvr\bin. d. Type Eseutil /mh Database_File_Name, and then press ENTER. Repeat this step for each database in the storage group. This command displays the database file header. The header contains one of the following lines: • State: Clean Shutdown • State: Dirty Shutdown 3. Move logs and checkpoint files to another location in case a recovery is required from an old database. The log files have the .log file name extension. The checkpoint files have the .chk file name extension. 4. Mount all the databases in the storage group.     5. The storage group must be backed up when delivery settles down on this computer because you cannot recover log files past the new log file generation point.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

마이크로 소프트에서 제시하는 Exchange 2003 Server 를 운영하면서 일간/주간/월간으로
점검해야 하는 점검항목에 대한 문서 입니다.

Exchange Server 의 경우 사용자의 메일 Data 를 운영 관리하는 시스템이기 때문에
다른일반 관계형 DATABASE와 비슷한 면도 있지만, 많은부분에서 차이점도 존재 합니다.

이전에 마이크로 소프트에서 "Exchange 2003  이후 버젼에 대해선 RDBMS를 사용하게 될것이
다." 라고 발표한적이 있었지만, 역시 Exchange Server 의 고유 기능과 구조를 바꾸기는 쉽지
않았나 봅니다.. 결국 차기버젼인 Exchange 2007의 경우 아직 RDBMS가 아닌 기존의
EDB, STM형태를 유지하는 것으로 보여 앞으로도 계속 그렇게 되지 않을까.. 합니다.

해당문서는 정말 상세하게 Exchange 에 관련된 주요 점검 내역을 정리해 주고 있습니다.
하지만 실제 운영계에선 이중 중요한 몇가지만을 모니터링 하고 사용하고 있습니다.

아래 내용 참조하셔서 Exchange Server 관리에 참조하시길 바랍니다.

일간점검 :
 - Windows Server Event Log 점검
 - Exchange 서버의 STM/EDB 저장 폴더의 디스크 사용량 점검
 - Exchange 서버의 Tranjection Log 저장폴더의 디스크 사용량 점검
 - Exhcnage 서버상의 메일큐 점검
 - Exchange 서버의 DB백업 여부 점검
 - ONLINE Deflag 점검

주간점검:
 - 전제 문제 보고서 점검
 - 바이러스 백신 작업 점검

월간점검:
 - 전체 용량 점검 및 계획 수립
 - 각종 핫픽스 , 서비스 팩 및 보안업데이트 적용여부 점검 및 적용

비정기:
 - 정기적으로 디스크의 사용량을 점검하여 특정 메일함의 메일 삭제 (EXMERGE.EXE)
 - OFFLINE DEFLAG

 

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Exchange 2003 서버의 특정 유저가 갑자기 메일을 수신할수 없다고 한다.. 메일을 수신을 못하는 경우는

상당히 여러가지의 Case 가 생길수 있는 문제다.

모든메일이 수신이 안되는지, 외부에서만 수신이 안되는지, 아니면 내부에서만 수신이 안되는지 등등.

정확한 원인을 확인해보기 전까지 어느곳에서의 문제라고 꼭 집어서 말하기 힘들다..

- 외부메일만 안들어 올경우 : 대부분 스팸 메일에서 걸러진 경우 또는 메일박스가 Full 인경우

- 내부메일도 안들어 오는 경우 :

이런경우 메일을 배달하지 못해서 생기는 문제로 사용자 메일 박스가 Full 이 나서 생기는 문제로 메일박스    사이즈와 해당사용자가 들어가있는 저장소 그룹의 메일박스 제약 사항을 검토 해봐야 한다.

  대부분 메일 수신 및 송신의 문제는 문제가 발생하면, 시스템에서 NDR이라는 리턴 메세지를 전달해주기
마련이다. 만일 이런 NDR이 없는 경우는 메일 수신지 즉 그룹웨어 상에서의 메일 자동삭제, 혹은 수신거부  
등 기타 프로그램상의 설정 으로 인한 오류가 대부분이다.

헌데 오늘 정말 드문케이스가 발생했다. 저장소에 속해 있는 다른유저는 아무런 문제 없이 메일수신되지만
특정 유저만 메일 배달이 안되는 경우 였다. 특이사항이라면 해당유저가 비상식적(???)으로 메일박스 사이즈
가 컸던점, 그리고 Exchange server 상에 1023 이라는 메세지를 주기적으로 남긴 것.. 등등..

메일이 많은 상태에서 지속적으로 서버상에 Imap 연결을 시도하고 메일을 다운로드 받는등..

해결방법은 해당 유저가 속해있는 저장소를 분리/탑재 작업을 거친후에 모든문제가 해결되긴 했다.

또한 메일박스에 대한 정리도 별도로 요청했고.. 음.. 어렵다. 어려워,....

마소.. 언제 exchange 2003을 RDBMS로 내줄꺼냐고~~~ 

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.