MS에서 Exchange Server 2010을 2009년 4월 15일(현지시간) 발표했습니다.

웹 친화형 익스체인지 제품이고, 최종버전은 올해말에 공개될 예정이지만, 오피스 2010버전은 2010년 초가 되어야
선보일 것 같아서 안정적으로 상용화가 되려면 시간이 조금 걸릴 듯 합니다.

2010년 상반기부터 업그레이드를 고려할 수 있다고 봐야 될 것 같습니다.

Microsoft에서는 메시징 및 커뮤니케이션을 통합메시징(Unified Communication)으로 무게를 두고 있어서, 기존의 흩어져 있던 Communication제품들을 하나로 묶어서 Microsoft UC 제품군으로 만들게 되었습니다. 그리고 Exchange, SharePoint, Communication 서버들이 기존의 Enterprise Servers제품군에서 Office 제품군으로 이동하게 됩니다. Exchange Server 를 제외하고는 앞에 모두 Office SharePoint Server, Office Communication Server와 같은 이름이 붙게 되었습니다.

내년초에 Windows 7과 함께 출시될 가능성이 높아지고 있습니다.

재미있는 점은 Beta버전이 한글버전도 같이 공개되었다는 점인데
아래 링크를 통하여 다운로드 받으실 수 있습니다.

http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=1898ed2c-2f88-48ac-824e-d3d20fad77d7


시스템 요구 사항

  • 지원하는 운영 체제: Windows Server 2008; Windows Vista 64-bit Editions Service Pack 1
  • 관리 도구를 설치하는 데 필요한 운영 체제: 64비트 버전의 Windows Vista® SP1 이상 또는 Windows Server® 2008
사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

 

안녕하세요 빛향기고운데입니다~*

Exchange Server에서나 Windows Server에서나 Anti-Virus제품군을 사용하시고 계시는데

비검사영역을 설정 하지 않은 관리자 분들이 많이 있는것 같습니다.

특정 Anti-Virus제품군중에서는 파일의 HEX값을 조정하여 DB에 영향을 미치는 솔루션들이

있기 때문에 Exchange에서 중요한  Directory들은 비검사영역으로 설정해 두는 것이 중요합니다.




Exchange 데이터베이스 및 로그 파일

Exchange .mta 파일(기본 위치: \Exchsrvr\Mtadata)

Exchange 메시지 추적 로그 파일(기본 위치: \Exchsrvr\Server_Name.log).

가상 서버 폴더(기본 위치: \Exchsrvr\Mailroot)

SRS(사이트 복제 서비스) 파일(기본 위치: \Exchsrvr\Srsdata)

IIS(인터넷 정보 서비스) 시스템 파일(기본 위치: \%SystemRoot%\System32\Inetsrv)

인터넷 메일 커넥터 파일(기본 위치: \Exchsrvr\IMCData)

메시지 변환에 사용된 스트리밍 임시 파일을 저장하는 데 사용되는 작업 폴더. 기본적으로 이 작업 폴더는 \Exchsrvr\MDBData에 있습니다.

Eseutil.exe 같은 오프라인 유지 관리 유틸리티에 함께 사용되는 임시 폴더. 기본적으로 이 폴더는 .exe 파일이 실행되는 위치이지만 유틸리티를 실행할 때 이 위치를 구성할 수 있습니다.

 

 


 KB문서


 

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다~*

NDR Size값을 이용하여 공격하는 패턴을 막을 수 있는 방법입니다.

레지스트리 수정시에 주의하시기 바랍니다.

 

Unable to resend the message. The nondelivery report does not contain sufficient information about the original message. To resend the message, open it in your Sent Items folder, click the Actions menu, and click "Resend this message".

Option to strip attachments for messages that generate an NDR


KB문서

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기



OWA(Outlook Web Access) 관리 도구에서는 관리자가 조정할 수 있는 모든 OWA 설정에 대해 웹 기반 UI를 제공하고 도메인의 모든 서버 목록을 제공하며 이 관리 도구를 사용할 경우 모든 프런트 엔드 및 백 엔드 서버에서 OWA 설정을 관리할 수 있습니다. 이 도구는 서버 레지스트리에 설정을 올바르게 기록하도록 해 주며 구성할 수 있는 모든 기능에 대한 인라인 설명서를 제공합니다.

Regedit를 수정할 필요 없이 OWA Admin이 웹 기반 폼으로 손쉽게 적용이 가능합니다.
테마 및 정크 메일, 자동 서명, 주소록, 보안, 등 OWA기능을 손쉽게 변경할 수 있습니다.


Main 화면


서버기능 수정


테마적용


사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다~*

In order to assist customers in designing their storage layout for Exchange 2007, we have put together a calculator that focuses on driving the storage requirements (I/O performance and capacity) and what the optimal LUN layout should be based on a set of input factors.

Exchange 2007 사용자 DB(Storage) Size 계산을 하는 Excel Sheet입니다.





 


출처 : Microsoft Exchange Team Blog

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다~*

Exchange2007에서 사용자 그룹정책에 대한 내용입니다.
참고하셔서 보시면 좋을 것 같습니다.


Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects. A policy is a collection of configuration settings that can be applied to one or more Exchange objects of the same class. This blog post gives an overview of Exchange 2007 policies: E-mail Address Policy (EAP), Exchange ActiveSync mailbox policy, Unified Messaging (UM) mailbox policy, and managed folder mailbox policy. Policies available in Exchange 2003 that are removed or changed in Exchange 2007 are also covered.



 

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다.

돌아다니다 좋은 걸 발견했네요.
TechNet에서 만든 Exchange2007 아키텍쳐 포스터 입니다.

PDF파일로 올려드리니 다운 받아서 보시기 바랍니다.



사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기


안녕하세요 빛향기고운데입니다.
Exchange에서 Pickup Folder를 테스트 하는 방법입니다.



* Telnet 을 이용하여 SMTP 접근후 TEST

telnet mailservername 25

ehlo

mail from: email@test.com

rcpt to: email@destinationExchangeMailboxToTest.com

data

test message text

.    #must do single period then enter to end

  * message.eml 파일을 Notepad로 생성

Exchange의 Default Pickup 폴더로 이동후 생성한 eml File을 Convert To TMP


* 메세지가 정상적으로 도착했는지 확인

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기
 

The previous sections listed the counters for the most common use of Exchange Servers—as mail-flow and mailbox servers. However, some organizations heavily use Exchange server roles, such as front-end servers and public folder servers. For those organizations, there are other performance issues that need to be monitored.

Looking at Front-End Servers

Front-end servers, such as those that serve Outlook Web Access, authentication, IP address checking, Secure Sockets Layer (SSL) protocol, and encryption schemes, have security features that require significant processing. For these servers, you are likely to see increased processor activity, both in privileged and user mode, and an increase in the rate of context switches and interrupts. If the processors in the server cannot handle this increased load, queues are likely to develop.

If your front-end servers are using SSL, the Local Security Authentication Server (Lsass.exe) process may consume a large amount of CPU. This is because SSL processing occurs here at the server. This means that administrators used to monitoring CPU usage may see less processor consumed by the Inetinfo.exe process and more consumed by the Lsass.exe process.

Improving Front-End Server Performance

The following item describes how you can improve the front-end server performance:

·      Use hardware cryptographic accelerators

When there is extremely high SSL use, you can improve performance by using hardware cryptographic accelerators to offload the calculations and remove SSL from being a bottleneck.

Looking at Public Folder Servers

For public folder servers, it is important to understand that the replication traffic between public folders (if there is more than one public folder in the topology) can affect all the servers involved. Arrange the replication schedule of the servers so that a replication queue does not mount any public folder. Processing replication changes causes resource competition with the operations already occurring on the server.

Replication Mail Flow

Replication messages are received by SMTP, categorized and handed to the local SMTP queue. The messages are then submitted to the Public Folder store. Once they have been submitted to the Public Folder store the messages are put in the Replication Receive Queue. The messages in the Replication Receive Queue then get processed and the changes are performed on the appropriate Public Folder

Use the counter listed in the following table to determine whether there is any public folder performance degradation.

Performance Counter for Public Folder Server Receive Queue

Counter

Expected values

MSExchangeIS Public\Replication Receive Queue Size

Indicates the number of replication messages waiting to be processed.

·      This value should not go above 100.

·      This value should return to a minimum value between replication intervals

 

Improving Public Folder Server Performance

The following item describes how you can improve the public folder server performance:

·      Tune replication schedule to avoid queues

You can increase or decrease the frequency that a public folder replicates its content changes to other public folders. For some deployments, having replication contents replicate more frequently actually results in performance gains. These performance gains are possible because the increased replication frequency avoids big replication queues and involves less public folder content being replicated at a time.

However, if replication is never completing then you will see an unbounded growth of the Replication Receive Queue size. When changing the frequency of replication monitor this counter to ensure that replication is completing before the beginning of the next interval.

·      Minimize the number of replicas

Minimizing the number of replicas will also result in performance gains. In some cases multiple replicas of folders may have been added in order to distribute the load over multiple servers. A more effective way to balance the load would be to divide the folders across multiple servers.

For example, if you were to divide the folders between two servers such that each server had replicas of half the hierarchy that scenario would result in less load per server than if the two servers that had replicas of all the folders. Dividing the folders results in better performance because there will not be the added performance cost of replicating all the content changes between the servers.

·      Throttling Offline Address Book downloads to reduce network hit

Exchange 2003 and Outlook 2003 Cached Mode increase the number of downloads of the Offline Address Book (OAB). These downloads may result in very high network utilization and may overload the network. By default, every client request for a full OAB is served immediately. Throttling the OAB downloads will help limit the effect on the network. See the following Microsoft Knowledge Base articles for more information.

·      Throttling full offline Address Book downloads to limit the effect on a LAN in Exchange Server 2003

·      High network usage occurs while Outlook clients download the offline Address Book from Exchange 2003 at the same time

·      Structuring the Public Folder hierarchy

Reducing the number of direct subfolders will also help improve performance. A deeper and narrow hierarchy will have lower performance cost than a shallow and wide hierarchy. Limiting the number of direct subfolders for any given folder to 250 will reduce the cost of both replication and user actions.

·      Limiting the number of messages per folder

Limiting the number of messages for a public folder will reduce search and sort times on that folder. This will improve the client experience as well as reduce load on the server.

It is not uncommon for servers to experience multiple bottlenecks. It is important, however, to understand whether there are any causal relations occurring—that is, where one subsystem's performance issues spills over to another subsystem. For example, a CPU-bound server can build up queues, which causes unusually high use of the SMTP disks.

Because of the possibility of causal relations occurring between subsystems, analyze the performance logs with regard to: 

·      The role assigned to the server.

·      The cause or causes that trigger the performance degradation of one or more subsystems.

Generally, it is worth mitigating each bottleneck, and then seeing the effects of removing that malfunctioning piece of the puzzle. Otherwise, enforcing policies may be enough to mitigate issues caused by multiple bottlenecks. For instance, enforcing message sizes for POP3 retrievals can reduce the load on the database disk. However, enforcement may not be enough. There are many cases that will require upgrades or a redesign of the hardware.

Example of a Multiple Bottleneck

In this example, the Exchange server is a mailbox server that hosts 6,000 users. It is connected to three direct attach storage arrays: 

·      One array has the database.

·      Another array has the transaction logs.

·      The third array has the SMTP disks.

This Exchange server has two storage groups with two private databases, each database with 1,500 users. The SLA for backing up and restoring limits the number of storage groups to two.

The problem is that, during the daytime, users experience slow response as they use Microsoft® Office Outlook® in online mode.

Looking at the Symptoms

By collecting a performance log during the eight hours of day-time use for which this server is experiencing degraded performance, it becomes clear that the MSExchangeIS\RPC Requests counter is constantly around 60, and that some clients experience slow responses to the operations requested. Furthermore, the MSExchangeIS\RPC Averaged Latency counter is constantly hitting or going above 100 ms. These are clear symptoms of performance issues that need to be isolated.

Eight hours of day-time performance information

 

Analysis of the performance logs uncovered problems with the performance of the database drive, the log drive, and the CPU. The following sections indicate which performance counters were used to determine each problem.

Problem 1—Database drive with bad performance

The Exchange Server is connected to a Storage Area Network that cannot handle the I/O load. As shown in Figure 10, the write latencies on the database drive (as indicated by the PhysicalDisk\Average Disk sec/Write counter) average 62 ms, with frequent spikes above 80 ms and some above 100 ms.

Performance log of the database drive

 

Problem 1 Solution

By adding another array and controller, and then splitting the storage groups into separate arrays, the performance of the database drive improved.

Problem 2—Log drive with bad performance

As shown in the following figure, a slow transaction log drive is causing the Database\Log Record Stalls/sec counter to average 114 stalls/second, with constant spikes above 150 stalls/second. In addition, there are frequent log threads waiting as indicated by the Database\Log Record Stalls/sec counter, with spikes above 20.

Performance log of the transaction log drive

 

Problem 2 Solution

The controller responsible for the transaction logs was experiencing problems. The controller has the write-back cache disabled. The stalls subsided after replacing the old controller with a new controller that had a properly functioning write-back cache.

Problem 3—CPU-bound

As shown in the following figure, this server is experiencing high CPU usage (with the Processor\% Processor Time counter averaging 97%) and large processor queues (as indicated by the System\Processor Queue Length counter).

Performance log of CPU usage

 

Problem 3 Solution

The slowness on the database and transaction logs aggravated the CPU utilization, causing more context switches than necessary (an average of 50,000 on this performance log) and consequently over utilizing the CPU. By resolving the database issues in Problem 1 and the transaction logs issues in Problem 2, the CPU utilization problem shown in the figure in this problem is resolved as well.

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기




Exchange depends on the performance of the global catalog domain controllers. You can investigate CPU usage, as well as disk and memory bottlenecks, on your Active Directory servers.

Note:

Most investigative techniques described in this article apply to global catalogs.

For each of the Exchange servers in the topology, use the counters listed in the following table to determine whether there is a slowdown in communicating with global catalogs.

Performance Counters on the Exchange Server that Indicate Global Catalog Problems

Counter

Expected values

SMTP Server\Categorizer Queue Length

Indicates how well SMTP is processing LDAP lookups against global catalog servers.

This should be at or around zero unless the server is expanding distribution lists. When expanding distribution lists, this counter can occasionally go up higher. This is an excellent counter to tell you how healthy your global catalogs are. If you have slow global catalogs, you will see this counter go up.

·      The maximum value should be below 10.

MSExchangeDSAccess Process\LDAP Read Time (for all processes)

Shows the time (in ms) that an LDAP read request takes to be fulfilled.

·      The average value should be below 50 ms.

·      Spikes (maximum values) should not be higher than 100 ms.

MSExchangeDSAccess Process\LDAP Search Time (for all processes)

Shows the time (in ms) that an LDAP search request takes to be fulfilled.

·      The average value should be below 50 ms.

·      Spikes (maximum values) should not be higher than 100 ms.

 

For each of the global catalogs in the topology, use the counters listed in the following table to determine whether the global catalogs are experiencing performance degradations.

Performance Counters on the Global Catalog Servers that Indicate Problems

Counter

Expected values

Processor\% Processor Time (_Total)

Indicates the percentage of time the processor is running non-idle threads.

You can use this counter to monitor the overall utilization of the processors or per-processor.

·      The average CPU utilization should be below 90% at all times.

System\Processor Queue Length

Indicates the number of threads in the processor queue.

There is a single queue for processor time, even on computers with multiple processors. This counter shows ready threads only, not threads that are currently running.

·      This counter should be less than 2.

Network Interface\Bytes Total/sec

Indicates the rate at which the network adapter is processing data bytes.

This counter includes all application and file data, in addition to protocol information such as packet headers.

·      For a 100-Mbps NIC, this counter should be below 6 MB/sec.

·      For a 1000-Mbps NIC, this counter should be below 60 MB/sec.

Network Interface\Packets Outbound Errors

Indicates the number of outbound network packets that could not be transmitted because of errors.

·      This counter should be zero (0) at all times.

PhysicalDisk(NTDS Database Disk)\Average Disk sec/Read

Indicates the average time (in seconds) that it takes to read data from the disk.

·      The average value should be below 20 ms.

·      Spikes (maximum values) should not be higher than 50 ms.

PhysicalDisk(NTDS Database Disk)\Average Disk sec/Write

Indicates the average time (in seconds) that it takes to write data to the disk.

·      The average value should be below 20 ms.

·      Spikes (maximum values) should not be higher than 50 ms.

PhysicalDisk(NTDS Log Disk)\Average Disk sec/Read

Indicates the average time (in seconds) that it takes to read data from the disk.

·      This value should be below 10 ms at all times.

PhysicalDisk(NTDS Log Disk)\Average Disk sec/Write

Indicates the average time (in seconds) that it takes to write data to the disk.

·      This value should be below 10 ms at all times.

PhysicalDisk(NTDS Database or Log Disks)\Average Disk Queue Length

Indicates the average number of both read and write requests that were queued for the selected disk during the sample interval.

·      The average value to be less than the number of spindles of the disk.

If a SAN is being used, ignore this counter and concentrate on the latency counters:

PhysicalDisk\Average Disk sec/Read and PhysicalDisk\Average Disk sec/Write.

Memory\Available Mbytes (MB)

Indicates the amount of physical memory (in MB) immediately available for allocation to a process or for system use.

The value of this counter is equal to the sum of memory assigned to the standby (cached), free, and zero page lists.

·      During the test, there must be 50 MB of memory available at all times.

Memory\Pages/sec

Indicates the rate at which pages are read from or written to disk when resolving hard page faults.

This counter is a primary indicator of the types of faults that cause system-wide delays. It includes pages retrieved to satisfy page faults in the file system cache. These pages are usually requested by applications.

·      This counter should be below 1,000 at all times.

 

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다.
레지스트리 통하여 Exchange Server IMF v2  수정하는 방법입니다.


By default, the Intelligent Message Filter feature is installed with Microsoft Exchange Server 2003 Service Pack 2 (SP2). You must manually enable Intelligent Message Filter to obtain the benefits of this new message filtering technology. The Microsoft Exchange Server Intelligent Message Filter v2 Operations Guide describes the update process that keeps Intelligent Message Filter up-to-date. This guide includes information about the following topics:

How Intelligent Message Filter works

How to plan your Exchange Server Intelligent Message Filter

How to secure your gateway SMTP virtual servers

How to deploy in a multiple forest scenario

How to configure and to enable Exchange Server Intelligent Message Filter

How to update the Exchange Server Intelligent Message Filter

Supported scenarios

Schedule and availability of updates

How to enable updates

How to uninstall updates

Service packs

Unsupported scenarios: clustered environment

Automatic updates

How to monitor and to troubleshoot Exchange Server Intelligent Message Filter

How to use system monitor and performance logs and alerts

How to customize Exchange Server Intelligent Message Filter

How to change the archive location

How to store the SCL rating with archived messages

How to filter messages sent through authenticated connections

How to set the size of spam rules








해당 Regedit 값에 DWORD 추가하시고 값을 1 주시면 됩니다.

restart the Simple Mail Transfer Protocol (SMTP) service





KB문서 참조
http://support.microsoft.com/KB/907747
사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기


안녕하세요 빛향기고운데입니다.

Exchange Server에서 보안을 위하여 필요한 설정입니다.
Tarpit기능을 이용하여 트래픽조절을 통하여 고의적인 공격을 예방하는 기술입니다.
필터링중 받는 사람 필터링을 설정한 경우 큰 이점이 되는 기능입니다.



SMTP 타르핏 기능?

타르핏 기능은 스팸이나 기타 원하지 않는 트래픽과 관련된 특정 SMTP 통신을 고의적으로 지연하는 방법입니다. 이러한 종류의 통신을 적용하려면 일반적으로 많은 양의 트래픽을 사용하게 됩니다. SMTP 통신 속도를 저하시켜 자동 스팸을 보내거나 사전 공격(dictionary attack) 수행할 있는 속도를 크게 줄일 있습니다. 타르핏 기능을 사용하면 합법적인 트래픽 또한 느려질 있습니다.


받는 사람필터링 기능?

받는
사람 필터링 기능은 Exchange 2003 새로운 기능입니다. 기능을 사용하면 특별히 정의된 받는 사람과 조직의 Active Directory 디렉터리 서비스에 나열되어 있지 않은 받는 사람이 보내는 메일을 필터링하거나 거부할 있습니다.

받는 사람 필터링을 설정하고 구성하는 방법에 대한 자세한 내용은 Microsoft Exchange Server 2003 온라인 도움말을 참조하십시오.

받는 사람 필터링 기능을 설정하면 보낸 사람은 잘못된 받는 사람이나 필터링된 받는 사람을 향하는 메일은 보낼 없습니다. 이러한 메일은 메일 본문이 전송되기 전에 SMTP 통신에서 사전에 거부됩니다.

동작은 일반적으로 Exchange Server에서 잘못된 메일을 처리해야 필요를 줄여 줍니다. 메일을 받거나 저장할 필요도 없으며 메일을 받지 않았으므로 잘못된 메일에 대해 NDR(배달 못함 보고서) 보내지 않아도 됩니다.

받는 사람 필터링 기능을 사용하지 않을 경우에는 Exchange 조직의 잘못된 전자 메일 주소로 보내진 메일을 Exchange Server에서 받아 처리하게 됩니다. 이러한 메일을 처리한 Exchange Server에서는 모든 잘못된 메일에 대해 NDR 생성하고 보내야 합니다.



타르핏 기능과 받는 사람 필터링 기능을 함께 사용하는 방법

받는 사람 필터링 기능의 단점은 전자 메일 주소 수집 공격의 효율성을 증가시킨다는 점입니다. 일반적인 수집 공격에서 사용자 도메인에 보내기 위해 다량의 전자 메일 메시지를 자동으로 생성하는 "사전" 또는 가능한 전자 메일 이름 목록이 사용됩니다. 목표는 전자 메일 주소의 유효성을 확인하는 것입니다. 그런 다음 공격자는 검색된 전자 메일 주소 목록을 사용하여 스팸이나 다른 비합법적인 용도의 메일을 보냅니다.

받는 사람 필터링 기능을 설정하면 서버는 SMTP 통신 동안 전자 메일 이름이 유효한지 여부를 표시합니다. 받는 사람 필터링 기능을 해제하면 공격자는 추측한 이름에 대해 NDR 반환될 때까지 기다립니다.

받는 사람 필터링 기능과 타르핏 기능을 모두 설정하면 잘못된 전자 메일 이름에 대한 응답을 크게 지연할 있습니다. 이러한 동작은 공격을 방해합니다.

참고 대다수의 공격자가 스푸핑된(spoofed) 도메인으로 로그온하기 때문에 스팸 메일을 보내는 사람이나 기타 공격자가 사용자 서버에서 생성된 NDR 실제로 받을 가능성은 희박합니다. NDR 공격자를 찾을 있다면 여러분도 공격자를 찾을 있습니다. 따라서 NDR 통한 사전 공격 위험은 SMTP 통신 동안 정보가 누출될 위험만큼 크지 않습니다.



공격자에게
도움이 될 수 있는 응답을 Exchange에서 보내지 않도록 막지 않는 이유

응답을 보내지 않도록 Exchange 구성할 수도 있습니다. 이렇게 하려면 받는 사람 필터링 기능을 해제하고 NDR 표시하지 않도록 해야 합니다.

앞에서 설명한 것처럼 NDR 표시하지 않는 것은 RFC 준수하는 방법이 아닙니다. 따라서 NDR 표시하지 않는 것은 일반적으로 좋지 않습니다. 또한 NDR 표시하지 않으면 전자 메일 메시지를 보낼 받는 사람 주소를 잘못 입력하는 일반 사용자에게 불편을 주기도 합니다. 전자 메일을 보내는 사람은 일반적으로 NDR 반환되지 않으면 전자 메일 메시지가 목적지에 도달한 것으로 생각합니다.

받는 사람 필터링 기능을 설정하면 수집 공격을 받을 위험이 커질 있습니다. 그러나 NDR 대량 공격을 위한 벡터로 사용될 가능성도 줄어듭니다. NDR 대량 공격은 보낸 사람이 유효한 도메인의 반환 주소를 의도적으로 스푸핑한 다음 잘못된 전자 메일 메시지를 해당 도메인에서 보낸 것처럼 사용자에게 보내는 것입니다. 그러면 사용자의 서버는 도메인에 의무적으로 다량의 NDR 보고서를 보냅니다.

전자 메일 수집 공격, NDR 대량 공격 스팸 자체의 문제는 합법적인 전자 메일 전송에 유용하거나 필요한 SMTP 프로토콜 기능을 사용합니다. 합법적인 트래픽을 계속 허용하면서 이러한 위협으로부터 방어할 고려해야 하는 장단점이 있습니다.

타르핏 기능은 합법적인 사용자가 받는 영향을 최소화하면서 SMTP 오용을 방지하는 하나의 다른 옵션입니다.


 

타르핏 기능을 설정하는 방법

경고 레지스트리 편집기나 다른 방법을 사용하여 레지스트리를 잘못 수정하는 경우 심각한 문제가 발생할 있습니다. 문제를 해결하려면 운영 체제를 다시 설치해야 수도 있습니다. Microsoft 문제에 대해 해결을 보증하지 않습니다. 레지스트리의 수정에 따른 모든 책임은 사용자에게 있습니다.

타르핏 기능은 레지스트리 키를 통해 설정하고 구성할 있습니다. 다음과 같이 하십시오.

참고 TarpitTime 레지스트리 항목이 없으면 Exchange 레지스트리 항목의 값이 0으로 설정된 것처럼 동작합니다. 레지스트리 항목의 값이 0이면 SMTP 주소 확인 응답을 보낼 지연되지 않습니다.

1.

시작, 실행 차례로 누르고 열기 상자에 regedit 입력한 다음 확인 누릅니다.

2.

다음 레지스트리 하위 키를 찾아서 누릅니다.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters

3.

편집 메뉴에서 새로 만들기 가리킨 다음 DWORD 누릅니다.

4.

레지스트리 항목 이름으로 TarpitTime 입력한 다음 Enter 키를 누릅니다.

5.

편집 메뉴에서 수정 누릅니다.

6.

10진수 누릅니다.

7.

데이터 상자에 존재하지 않는 주소에 대해 SMTP 주소 확인 응답을 지연할 시간() 입력합니다. 그런 다음 확인 누릅니다. 예를 들어 5 입력한 다음 확인 누릅니다. 이렇게 하면 5 동안 SMTP 주소 확인 응답이 지연됩니다.

8.

레지스트리 편집기를 종료합니다.

9.

SMTP(Simple Mail Transport Protocol) 서비스를 다시 시작합니다.




  10진수 사용

 

 

감사합니다.

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기


안녕하세요 빛향기고운데 입니다.

오늘은 Exchange Server에서 Memory때문에 Kernel issues가 생기는 문제에 대하여 다뤄보도록 하겠습니다.


64-bit & 32-bit

* Addressable Memory
  * 32-bit = 2 의 32승 = 4GB maximum memory
  * 64-bit = 2 의 64승 = 18 Exabyte maximum memory
     * Current hardware restricts memory to between 16 and 64GB

* More memory = larger cache
   * Larger cache = less IOPS/user
     * Less IOPS/user (75% less )
     * Less IOPS = 4x users per disk or 1/4 disks required)

* More memory = no more kernel errors
* More memory = no more VM fragmentation
* More memory = meet growing demands


  No switches



  /3GB



  /3GB and /USERVA




PAE & AWE

* PAE(Physical Address Extension)
  * A function of the Windows 2000/2003 memory managers that provides more physical memory to a
    program that requests memory
  * The progrma is not aware that any of the memory that it uses resides in the range 4GB +

* AWE(Address Windowing Extensions)
  * An API set that enables programs to reserve large chunks of memory
  * The reserved memory is non-pageable and is only accessible to that program


Boot.ini Ortions for Exchange 2003 on Windows 2003
 Exchange 2003 Server Role Physical Memory Config  Additions Made to Boot.ini 
 Mailbox  1GB   /3GB /USERVA=3030 
 Public Folder  1GB   /3GB /USERVA=3030 
 Front End(FE)  1GB   None
 SMTP
Gateway/Bridgehead
 1GB   None
 SMTP
Gateway/Bridgehead
(Envelope Journaling)
 1GB   /3GB /USERVA=3030 
 MTA/X.400/3rd Party
Connector Bridgehead
 1GB   /3GB /USERVA=3030 


* /PAE

The Physical Address Extension (PAE) allows 32-bit Windows systems to use more than 4 GB of physical memory. PAE also enables several advanced system and processor features so it can also be used on computers that have less than 4 GB of memory. Features enabled by PAE include hardware-enabled Data Execution Prevention (DEP), non-uniform memory access (NUMA), and the ability to add memory to a system while it is running (hot-add memory).

On most computers, PAE is disabled by default. (PAE is enabled by default only if DEP is enabled on a computer that supports hardware-enabled DEP, or if the computer is configured for hot-add memory devices in memory ranges beyond 4 GB.) PAE must be explicitly enabled for Windows to run in NUMA mode on a NUMA-capable computer.

To enable PAE, use the BCDEdit /set command to set the pae boot entry option.

Windows Server 2003 and Windows XP/2000:  To enable PAE, use the /PAE switch in the Boot.ini file. To disable PAE, use the /NOPAE switch.

With PAE enabled, the operating system moves from two-level linear address translation to three-level address translation. The extra layer of translation provides access to physical memory beyond 4 GB. Instead of a linear address being split into three separate fields for indexing into memory tables, it is split into four separate fields: a 2-bit field, two 9-bit fields, and a 12-bit field that corresponds to the page size implemented by Intel Architecture (4 KB).

PAE, 4-gigabyte tuning (4GT), and Address Windowing Extensions (AWE) serve different purposes and can be used independently of each other:

  • PAE allows the operating system to access and use more than 4 GB of physical memory.
  • 4GT extends the 32-bit user virtual address space from 2 GB to up to 3 GB.
  • AWE is a set of APIs that allows a process to allocate nonpaged physical memory and then dynamically map portions of this memory into the virtual address space of the process.

When neither 4GT nor AWE are being used, the amount of physical memory that a single 32-bit process can use is limited by the size of its address space (2 GB). In this case, a PAE-enabled system can still make use of more than 4 GB of RAM to run multiple processes at the same time or to cache file data in memory.

4GT can be used with or without PAE. However, some versions of Windows limit the maximum amount of physical memory that can be supported when 4GT is used. On such systems, booting with 4GT enabled causes the operating system to ignore any memory in excess of the limit. For details, see Memory Limits for Windows Releases.

AWE does not require PAE or 4GT but is often used together with PAE to allocate more than 4 GB of physical memory from a single 32-bit process.



Windows Server 2003에서는 서버가 핫 추가 메모리 장치를 사용하는 경우에만 PAE가 자동으로 설정됩니다. 이 경우 핫 추가 메모리 장치를 사용하도록 구성된 시스템에서는 /PAE 스위치를 사용할 필요가 없습니다. 다른 모든 경우에 4GB 이상의 메모리를 이용하려면 Boot.ini 파일에서 /PAE 스위치를 사용해야 합니다.

일반적으로 Windows 2000이나 Windows Server 2003에서 실행되는 프로세스는 /3GB 스위치를 사용하지 않는다고 가정할 때 최대 2GB의 메모리 주소 공간에 액세스할 수 있으며 이 메모리 중 일부는 실제 메모리이고 일부는 가상 메모리입니다. 프로그램과 프로세스를 더 많이 실행하면 최대 2GB의 주소 공간까지 메모리를 더 많이 커밋하게 됩니다.

이런 상황이 발생하면 페이징 프로세스가 크게 증가하여 성능에 나쁜 영향을 미칠 수 있습니다. Windows 2000 및 Windows Server 2003 메모리 관리자는 PAE를 사용하여 프로그램에 더 많은 실제 메모리를 제공합니다. 이렇게 하면 페이지 파일의 메모리를 스왑할 필요성이 줄어들어 성능이 향상됩니다. 프로그램 자체는 실제 메모리 크기를 인식하지 못합니다. 모든 메모리 관리와 PAE 메모리의 할당은 실행되는 프로그램에 관계없이 메모리 관리자에 의해 처리됩니다.

앞의 정보는 /3GB 스위치를 사용하여 실행하는 프로그램에 해당됩니다. 3GB 메모리를 요청하는 프로그램은 페이징 아웃하는 대신 실제 메모리에 더 많은 메모리가 남아 있도록 할 수 있습니다. 이렇게 하면 /3GB 스위치를 사용할 수 있는 프로그램의 성능이 좋아집니다. 예외는 /3GB 스위치를 /PAE 스위치와 함께 사용할 때 발생합니다. 이 경우 운영 체제는 16GB를 초과하는 메모리를 사용하지 못합니다. 이 문제는 커널 가상 메모리 공간의 고려 사항으로 인해 발생합니다. 이렇게 Boot.ini 파일에서 /3GB 항목을 사용하여 시스템을 다시 시작하고 시스템의 실제 메모리가 16GB보다 큰 경우 운영 체제는 추가 실제 RAM을 사용하지 않습니다. /3GB 스위치를 사용하지 않고 컴퓨터를 다시 시작하면 실제 메모리를 모두 사용할 수 있습니다.

AWE는 메모리 관리자 기능에 대한 API(응용 프로그래밍 인터페이스) 집합으로 프로그램이 표준 32비트 주소 지정을 통해 4GB보다 큰 사용 가능한 메모리를 주소 지정할 수 있게 해 줍니다. AWE를 사용하면 프로그램은 실제 메모리를 비페이징 메모리로 예약한 다음 비페이징 메모리 일부를 프로그램의 메모리 작업 집합에 동적으로 매핑할 수 있습니다. 이 프로세스를 사용하면 대형 데이터베이스 시스템처럼 메모리를 많이 사용하는 프로그램이 페이지 파일을 사용하기 위해 페이징 인/아웃할 필요 없이 많은 실제 메모리를 데이터용으로 예약할 수 있습니다. 대신 데이터는 작업 집합에서 스와핑되며 예약된 메모리는 4GB 범위를 초과합니다. 또한 4GB를 초과하는 메모리 범위는 PAE에 의해 AWE 기능 및 메모리 관리자에 노출됩니다. PAE 없이는 AWE가 4GB를 초과한 메모리를 예약할 수 없습니다.

다음은 PAE 스위치가 추가된 Boot.ini 파일의 예입니다.
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /PAE




/3GB Switch


-> 기본적으로 Windows는 총 4GB의 가상 주소 공간을 주소 지정할 수 있습니다. 기본적으로 이 중 2GB는
     커널(운영 체제)용으로 예약되고 나머지 2GB는 Exchange 같은 사용자 모드 프로그램용으로 예약됩니다.

    운영 체제의 Boot.ini 파일에 /3GB 스위치를 추가하면 사용자 모드 프로그램에 3GB의 공간을 제공하고
    커널을 1GB로 제한하도록 가상 주소 공간 분배가 다시 할당됩니다. /3GB 스위치는 사서함 저장소나
    공용 폴더 저장소가 있는 컴퓨터에서만 필요합니다. 사서함 저장소나 공용 폴더 저장소가 없는 컴퓨터에서는
    이 스위치를 사용하지 않는 것이 좋습니다.


*  /3GB 사용가능 운영체제

Microsoft Windows Server 2003 Datacenter Edition
Microsoft Windows Server 2003 Enterprise Edition
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows NT 4.0 Enterprise Server

* /3GB 사용 불가능 운영체제
Microsoft Windows 2000 Server
Microsoft Windows NT 4.0 Server
-> /3GB스위치 사용하면 커널용으로 1GB와 사용자 모드 프로그램용으로 2GB가 할당되어 1GB의 주소공간이
    손실 됩니다.




메모리 부족이 발생하면 가상 메모리 조각화가 발생하여 문제를 information store 서비스가 비정상 동작하게 된다.

관련 성능 카운터
(1) MSExchangeIS - VMLargest Block Size
가상 메모리의 가장 큰 free block 크기를 byte 크기로 알려 줍니다.
이 값이 32MB 이하가 되면 9582 이벤트가 경고로 발생하고
16MB 이하가 되면 에러로 이벤트가 남게 됩니다.
이 값은 32MB 이하로 내려가서는 안 됩니다.
(2) MSExchangeIS – VM Total 16mb Free Blocks
16MB 이상의 가상 메모리 블록의 개수를 나타내고 1 밑으로 값이 떨어져서는 안 됩니다.
(3) MSExchangeIS – VM Total Free Blocks
크기와 상관없이 가용한 가상 메모리 블록크리의 총 개수를 나타냅니다.
역시 1 밑으로 값이 떨어져서는 안 됩니다.
(4) MSExchangeIS – VM Total Largest Free Block Bytes
16MB 이상이ㅡ 크기를 가지는 가상 메모리들만의 총 바이트 입니다.
50MB 밑으로 떨어져서는 안 됩니다.

관련 성능 카운터의 임계치를 넘어서면
이벤트 9582를 발생시킨다. 해당 이벤트를 만나면 서비스를 재시작하여 큰 문제를 막아야 한다.





Troubleshooting Kernel Memory

1.Ensure Exchange server configuration is correct. Run ExBPA
2.Isolate which Kernel Memory space is being exhausted (PP, NPP or PTE’s)
a.Analyze Events
b.Analyze Perfmon
3.Determine what is causing the specific Kernel Memory space exhaustion
4.Take corrective action






 


291988 (http://support.microsoft.com/kb/291988/) 4GB RAM 조정 기능 및 PAE(실제 주소 확장) 스위치에
          대한 설명
300573 (http://support.microsoft.com/kb/300573/) XGEN: Windows 2000 Datacenter Server에서의
          Exchange 2000 Enterprise Server 지원
266096 (http://support.microsoft.com/kb/266096/) XGEN: 1GB 이상의 실제(Physical) RAM을 가진
          Exchange 2000 서버에서 /3GB 스위치가 필요하다
298064 (http://support.microsoft.com/kb/298064/) Exchange 2000 Server에 대한 확장성 계획
266650 (http://support.microsoft.com/kb/266650/) Windows 2000 Datacenter Server 기반 컴퓨터에서의
          BackOffice 프로그램 지원 정보
317411 (http://support.microsoft.com/kb/317411/) XADM: Exchange 가상 메모리 문제를 해결하기 위해
          데이터를 수집하는 방법
266768 (http://support.microsoft.com/kb/266768/) Exchange 2000 Server에서 저장소 데이터베이스 최대 캐시
          크기를 수정하는 방법
823440 (http://support.microsoft.com/kb/823440/) Windows Server 2003 기반 시스템에 Exchange Server 2003
          을 설치한 경우 /3GB 스위치를 사용해야 한다
사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기
안녕하세요 빛향기고운데입니다.

Tool 하나를 드립니다. 많은 Exchange 관리자 분들이 이런 굉장한 Tool이 있는지 모르고 지나치는 경우가
많아 너무 안타까운 마음에 소개해 드립니다.

ExBPA - Best Practice Analyzer
 말그대로 Best Practice 를 분석해 주는 Tool입니다.
자동으로 Exchange를 분석하고 관리자에게 보기 쉽게 리포터를 보여주는 기능을 가지고 있습니다.

Exchange benchmark를 해주기도 하고, Default 값이 변경된 값을 찾아주며,
보안상 취약한 부분을 찾아 주기도 합니다.

MS에서도 Premium Support를 해줄때도 해당 Tool을 사용합니다.
Exchange분석 및 튜닝을 쉽게 할 수 있답니다.
그만큼 Open되어있는 강력한 Program Tool입니다.

저는 정기적으로 Report를 저장해서 보관하고 있습니다.
서버일지를 쓰는 것도 도움이 되지만, 해당 Report가 더 정확하니까요.
Exchange를 관리하시는 분이라면 꼭 사용해보시길 강력 추천드립니다.

감사합니다.


Ps, EXBPA에 대하여 강좌를 쓸까 했지만 구병국님이 너무 정리를 잘 해두셔서 링크를 걸어둡니다.

TechNet Library에 있습니다.
http://technet.microsoft.com/ko-kr/library/cc700733.aspx



다운로드 사이트
Microsoft Exchange Server Best Practices Analyzer Tool
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=dbab201f-4bee-4943-ac22-e2ddbd258df3



사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

1. 익스체인지 서버

클라이언트/서버통신 TCP: 135
익스체인지 관리자 TCP: 135
익스체인지 라우팅 TCP: 691
IMAP TCP: 143
IMAP (SSL) TCP: 993
MTA-X.4000 over TCP/IP TCP: 102
POP3 TCP: 110
POP3 (SSL) TCP: 995
RPC TCP: 135
SMTP TCP: 25
NNTP TCP: 119
NNTP (SSL) TCP: 563

 

2. Windows 기본 서비스

액티브 디렉토리 (LDAP) TCP: 389
액티브 디렉토리 (LDAP-SSL) TCP: 636
브라우징 UDP: 137,138
DHCP 임대 UDP: 67,68
DHCP 관리자 TCP: 135
디렉토리 복제 TCP: 135
UDP: 138
직접 호스트 (SMB,CIFS) TCP: 445
DNS 관리 TCP: 135
DNS 이름분해 TCP: 53
UDP: 53
이벤트 뷰어 TCP: 139
파일공유 TCP: 139
글로벌 카탈로그 (LDAP) TCP: 3268
글로벌 카탈로그 (LDAP-SSL) TCP: 3269
IPSec UDP: 500(IKE)
IP Protocol: 50(ESP), 51(AH)
인터넷 프린팅 프로토콜 (IPP) TCP: 631
커버로스 TCP: 88
UDP: 88
2계층 터널링 프로토콜 (L2TP) UDP: 1701
로그온 시퀀스 TCP: 139
UDP: 137,138
Net Logon UDP: 138
Pass Through Validation TCP: 139
UDP: 137,138
성능모니터 TCP: 139
지점간 터널링 프로토콜 (PPTP) TCP: 1723
IP Protocol: 47(GRE)
인쇄 TCP: 139
UDP: 137,138
레지스트리 편집기 TCP: 139
서버 관리자 TCP: 139
트러스트 TCP: 139
UDP: 137,138
사용자 관리자 TCP: 139
WinNT 진단 TCP: 139
WinNT 보안채널 TCP: 139
UDP: 137,138
WINS 복제 TCP: 42
WINS 관리자 TCP: 135
WINS 등록 TCP: 137

3. Convoy 클러스터링 (WLBS)

Convoy UDP: 1717
Windows NT 로드밸런싱 서비스 (WLBS) UDP: 2504


4. SQL 서버

SQL연결 (Winsock) TCP: 1433
UDP: 1434

5. 프록시 서버

Winsock 프록시 클라이언트 UDP: 1745

6. 터미널 서버

RDP 클라이언트(마이크로소프트) TCP: 3389
ICA 클라이언트(씨트릭스) TCP: 1494
 


사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

Exchange 2000 16GB 데이터베이스 크기 제한을 일시적으로 늘리는 방법

기술 자료 ID : 813051
마지막 검토 : 2008년 9월 11일 목요일
수정 : 5.3

현상

Microsoft Exchange 2000 Server Standard Edition 정보 저장소는 허용되는 최대 크기 제한에 도달하면 자동으로 종료되고 다시 시작되지 않습니다. 또한 응용 프로그램 이벤트 로그에 다음과 같은 이벤트 ID가 기록될 수도 있습니다.

이벤트 유형: Error
이벤트 원본: MSExchangeIS
이벤트 범주: 일반 사항
터미널 서비스를 1112
설명: "사서함 저장소(서버 이름)" 데이터베이스가 최대 허용 크기에 도달했습니다. 데이터베이스를 연결 해제하고 있습니다.

이벤트 유형: Warning
이벤트 원본: ESE
이벤트 범주: 공간 관리
터미널 서비스를 445
설명: 정보 저장소(3160) - D:\Program Files\Exchsrvr\MDBDATA\priv1.edb 데이터베이스가 최대 크기인 16383MB에 도달했습니다. 데이터베이스를 다시 시작할 수 없는 경우 오프라인 조각 모음을 실행하여 데이터베이스 크기를 줄일 수 있습니다.

참고 이벤트 ID 445의 설명에는 Priv1.edb 파일이 16,383MB에 도달한 것으로 되어 있지만 실제로는 아닐 수도 있습니다. 이벤트 ID 445는 Priv1.edb 파일과 Priv1.stm 파일을 합한 크기가 16,383MB에 도달하는 경우에 발생합니다. Priv1.edb 파일의 크기는 16,383MB보다 작을 수 있습니다.

 

원인

이것은 Exchange Server 2000 Standard Edition 정보 저장소 데이터베이스가 데이터베이스 파일에 보유할 수 있는 것보다 더 많은 데이터를 삽입하지 못하도록 의도적으로 설계된 동작입니다.

Microsoft Exchange 2000 Server Standard Edition을 실행할 때 이 문제가 종종 발생합니다. Exchange 2000 Server Standard Edition은 데이터베이스 크기를 16GB로 제한합니다.

참고 Exchange 개인 사서함 저장소 데이터베이스의 16GB 크기 제한과 Exchange 공용 사서함 저장소 데이터베이스의 16GB 크기 제한은 Priv.edb 파일과 Priv.stm 파일의 크기를 합한 값입니다. Exchange System Manager에서 사서함에 사용되는 공간을 검토하면 Priv.edb 파일에 사용되는 공간만 포함되어 있고 Priv.stm 파일에 사용되는 공간은 포함되어 있지 않습니다.

사서함에 제한을 적용할 경우 Priv.edb 파일의 저장소만 제한하고 Priv.stm 파일의 저장소는 제한하지 않습니다. 예를 들어 Exchange System Manager에서 사서함이 250MB의 공간만 사용하는 것으로 나타날 수 있습니다. 그러나 사서함이 사용하는 전체 공간은 450MB일 수 있습니다. Priv.stm 파일에 사용되는 200MB의 공간이 Exchange System Manager에 나타나지 않기 때문에 이러한 차이가 발생합니다.

 

해결 방법

Exchange 2000 Server Standard Edition에 대한 새 업데이트가 개발되었습니다. 이 업데이트를 사용하면 데이터베이스 크기 제한이 일시적으로 1GB까지 늘어납니다.

이 문제를 해결하기 위해 관리자는 다음 단계를 수행해야 합니다.
데이터베이스 크기 제한을 임시로 1GB 늘립니다.
필요 없는 데이터베이스 콘텐츠를 선택적으로 제거합니다.
데이터베이스 조각 모음을 수행하여 정의된 데이터베이스 크기 제한 이하의 수준으로 데이터베이스 크기를 줄입니다.
Exchange Server 2003에서는 임시로 데이터베이스 크기 제한을 1GB씩 늘리는 기능이 제품에 내장되었습니다. 그러나 이 기능을 활성화하려면 관리자가 다음 기술 자료 문서에 설명되어 있는 새로운 레지스트리 값을 만들어야 합니다.
828070 (http://support.microsoft.com/kb/828070/) 사서함 저장소 데이터베이스가 16GB 제한에 도달하면 Exchange Server 2003 사서함 저장소가 탑재되지 않는다


Exchange 2000에서는 2003년 9월 Exchange 2000 Server 서비스 팩 3 이후 롤업을 적용하여 이 문제를 해결할 수 있습니다. 그런 다음 관리자가 새로운 레지스트리 값을 만들어서 이 기능을 활성화해야 합니다. 롤업을 다운로드하고 설치하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하십시오.
824282 (http://support.microsoft.com/kb/824282/) 2003년 9월 Exchange 2000 Server 서비스 팩 3 이후 롤업

2003년 9월 Exchange 2000 Server 서비스 팩 3 이후 롤업을 나중에 설치할 계획이지만 이 문제를 위한 수정이 지금 필요하다면 아래 "업데이트 정보" 절을 확인하십시오.

 

업데이트 정보

현재 제품의 기본 동작을 수정하는 지원 기능은 Microsoft에서 구할 수 있지만 이 문서에서 설명하는 동작을 수정하기 위한 기능일 뿐입니다. 이 기능이 특별히 필요한 시스템에만 적용하십시오.

기능을 다운로드할 수 있는 경우 기술 자료 문서의 맨 위에 "핫픽스 다운로드 가능"이 표시됩니다. 이 부분이 표시되지 않는 경우 해당 기능을 구하려면 Microsoft 온라인 기술 지원으로 문의하십시오.

참고 문제가 추가로 발생하거나 문제 해결이 필요한 경우 별도의 서비스 요청을 해야 할 수도 있습니다. 이 특정 기능으로 해결할 수 없는 추가적인 질문과 문제에 대해서는 지원 비용이 청구됩니다. Microsoft 온라인 기술 지원 전화 번호의 전체 목록을 얻거나 별도의 서비스 요청을 하려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://support.microsoft.com/contactus/?ws=support (http://support.microsoft.com/contactus/?ws=support)
참고 "핫픽스 다운로드 사용 가능" 형식에는 기능에 사용할 수 있는 언어가 표시됩니다. 사용자 언어가 표시되지 않으면 해당 언어로 기능을 사용할 수 없기 때문입니다.

전제 조건

파일 종속성으로 인해 이 업데이트에는 Microsoft Exchange 2000 Server 서비스 팩 3(SP3)이 필요합니다. 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하십시오.
301378 (http://support.microsoft.com/kb/301378/) 최신 Exchange 2000 Server 서비스 팩을 구하는 방법

파일 정보

이 업데이트의 영어 버전에는 다음과 같은 파일 특성 또는 최신 파일 특성이 포함되어 있습니다. 이 파일의 날짜와 시간은 UTC(협정 세계시)로 나열되며 파일 정보를 볼 때 현지 시간으로 변환됩니다. UTC와 현지 시간의 차이를 보려면 제어판날짜 및 시간 항목에서 표준 시간대 탭을 사용하십시오.
날짜         시간   버전  크기    파일 이름
--------------------------------------------------------------
<Tr><Td>2003-01-17</Td>  <Td>01:17</Td>  <Td>6.0.6401.0</Td>  <Td>3,915,776</Td>  <Td>Cdoex.dll</Td></Tr>
<Tr><Td>2003-01-17</Td>  <Td>01:17</Td>  <Td>6.0.6401.0</Td>  <Td>3,567,616</Td>  <Td>Excdo.dll</Td></Tr>
<Tr><Td>2003-01-17</Td>  <Td>00:32</Td>  <Td>6.0.6401.0</Td>  <Td>258,048</Td>  <Td>Exmime.dll</Td></Tr>
<Tr><Td>2003-01-17</Td>  <Td>01:09</Td>  <Td>6.0.6401.0</Td>  <Td>1,691,648</Td>  <Td>Exoledb.dll</Td></Tr>
<Tr><Td>2003-01-16</Td>  <Td>22:37</Td>  <Td>6.0.6401.0</Td>  <Td>2,265,088</Td>  <Td>Mdbmsg.dll</Td></Tr>
<Tr><Td>2003-01-16</Td>  <Td>22:08</Td>  <Td>6.0.6401.0</Td>  <Td>32,768</Td>  <Td>Mdbrole.dll</Td></Tr>
<Tr><Td>2003-01-17</Td>  <Td>00:31</Td>  <Td>6.0.6401.0</Td>  <Td>4,591,616</Td>  <Td>Store.exe</Td></Tr></Table>

새 레지스트리 값 만들기

업데이트에서 이 기능을 사용하려면 새 레지스트리 값을 만들어야 합니다.

중요 이 절, 방법 또는 작업에는 레지스트리를 수정하는 방법에 대한 단계가 포함되어 있습니다. 그러나 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수도 있으므로 다음 단계를 주의하여 수행해야 합니다. 추가 보호 조치로 레지스트리를 수정하기 전에 해당 레지스트리를 백업하는 것이 좋습니다. 이렇게 하면 문제가 발생하는 경우 레지스트리를 복원할 수 있습니다. 레지스트리 백업 및 복원 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하십시오.
322756 (http://support.microsoft.com/kb/322756/) Windows XP 및 Windows Server 2003에서 레지스트리를 백업, 편집 및 복원하는 방법


Exchange 2000 컴퓨터에 레지스트리 항목을 추가하려면 다음 단계를 수행하십시오.
1. 시작, 실행을 차례로 클릭한 다음 regedt32.exe를 입력합니다.
2. 다음 레지스트리 키를 찾습니다. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Exchange Server Name>\Private-<long hexadecimal string>
3. 편집 메뉴에서 값 추가를 클릭한 다음 값 이름 상자에 Temporary DB Size Limit Extension
4. 데이터 형식으로 REG_DWORD를 선택한 다음 확인을 클릭합니다.
5. 1을 입력한 다음 확인을 클릭합니다.
6. 레지스트리 편집기를 종료합니다.
특정 데이터베이스에 대해 Temporary DB Size Limit Extension 레지스트리 값이 있고 값이 0 이외의 값으로 설정된 경우 데이터베이스 크기 제한은 1GB씩 증가됩니다. 그러나, 이 레지스트리 값은 동적으로 읽는 것이 아니고 데이터베이스가 시작될 때만 읽습니다. Exchange 정보 저장소가 시작되면 임시 데이터베이스 크기 제한을 사용한다는 것을 알려주는 이벤트 9657이 경고로 기록됩니다.

참고 복구 프로세스 동안 임시 17GB 제한을 초과하는 사서함 저장소에 새 전자 메일 콘텐츠가 추가되지 않도록 하려면 사서함 저장소를 탑재하기 전에 SMTP(Simple Mail Transfer Protocol) 및 Microsoft Exchange MTA Stacks 서비스를 중지하는 것이 좋습니다. 이 메타데이터를 제거하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하십시오.
828070 (http://support.microsoft.com/kb/828070/) 사서함 저장소 데이터베이스가 16GB 제한에 도달하면 Exchange Server 2003 사서함 저장소가 탑재되지 않는다

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

Database Size Limit Configuration and Management  / 2008-08-05

Prior to Microsoft Exchange Server 2003 Service Pack 2 (SP2), there was no method to configure database size limits for Exchange Server 2003. Exchange Server 2003 SP2 introduces the following new features:

  • For the Standard Edition, the default configured database size limit will now be 18 GB, a 2 GB addition to the previous limit, with a new maximum size of 75 GB.
  • For the Enterprise Edition, there is no default configured database size limit, and no software set maximum size.
  • Both versions of Exchange Server 2003 with SP2 have the ability to configure a limit, a warning threshold, and a warning interval set through registry keys.
  • Size check done against the database now uses logical database size. Empty or white space in the database does not count against the configured database size limit; therefore, no offline defragmenting is required for recovery exceeding the configured or licensed database limits.
  • Limit checks, done at regular intervals, are now controlled by the store process instead of JET. The default time interval is 24 hours and this interval is configurable through the registry.


 

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

사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

메일서버등록제(SPF: Sender Policy Framework)
메일서버 정보를 사전에 DNS에 공개 등록함으로써 수신자로 하여금 이메일에 표시된 발송자
정보가 실제 메일서버의 정보와 일치하는지를 확인할 수 있도록 하는 인증기술

* 대다수 스팸발송자가 자신의 신원을 감추기 위하여 발송자 주소나 전송경로를 허위로 표기하거나
변경하는 경우가 많다는데 착안
 
SPF를 이용한 이메일 인증절차:
발신자 : 자신의 메일서버 정보와 정책을 나타내는 SPF 레코드를 해당 DNS에 등록
수신자 : 이메일 수신시 발송자의 DNS에 등록된 SPF 레코드를 확인하여 해당 이메일에
                표시된 발송IP와 대조하고 그 결과값에 따라 수신여부를 결정
                (메일서버나 스팸차단솔루션에 SPF 확인기능이 설치되어 있어야 함)
 
SPF 개발 및 도입현황:
1998년 Paul Vixie의 ‘Repudiating Mail From'에서 처음으로 아이디어가 제안된 이후
    Pobox.com의 Meng Weng Wong에 의해 SPF가 개발됨
2004년 2월 IETF(Internet Engineering Task Force)에 공식 RFC(Request For Comments)로
    제안되었으며, 2004년 12월 SPF의 모든 기술적 내용들이 최종 완성됨
SPF는 타 인증기술에 비해 적용이 용이하고 호환성이 좋으며 오픈소스를 기반으로 하므로
    전 세계적으로 폭넓은 지지기반을 확보하고 있음
한국을 비롯한 미국, 캐나다, 일본 등 여러 국가들이 정부차원에서 사업자들을 대상으로
    SPF 레코드 출판 및 확인기능 도입을 통한 스팸차단 활용을 적극 권고하고 있음
통합 White Domain 등록제란?
정상적으로 발송하는 대량 이메일이 RBL이력으로 간주되어 차단되는 것을 방지하기
     위하여, 사전에 등록된 개인이나 사업자에 한하여 국내 주요 포탈사이트로의 이메일
     전송을 보장해주는 제도입니다. ( 무료 )

* 단, White Domain으로 등록되었다 하더라도 이후 모니터링을 통해 RBL이력발송 사실이
   확인되면, 즉각 차단 조치되며 White 리스트에서도 삭제될 수 있습니다.


기존에 개별 포탈에서 'IP 등록제', 'IP 실명제'등의 이름으로 운영해오던 것을
      2006년 9월 1일부로 KISARBL이 등록접수/관리/운영을 통합한 것이므로,
      KISARBL에 White Domain으로 등록하게 되면 , 여러번 별도로 등록할 필요없이 참여하고 
      있는 포탈사이트에 동시에 등록됩니다 .

*단 , 개인의 경우에는 일부 포탈사이트에서 자사의 정책상 등록을 허용하지 않습니다.

SPF 작성 도우미 (SPF Record 출판)
     -> KISA RBL 참조
         https://www.kisarbl.or.kr/spf/spfWizard_step1.jsp
사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

안녕하세요 빛향기고운데입니다~*

메세징을 경험하시다 보면 흔히 만나게 되는 NDR 오류 코드입니다.


사업자 정보 표시
(주)코레이즈 | 김창현 | 경기도 성남시 분당구 장미로42 5층 | 사업자 등록번호 : 144-81-08126 | TEL : 02-1833-5805 | Mail : sales@coraise.co.kr | 통신판매신고번호 : 호 | 사이버몰의 이용약관 바로가기

+ Recent posts