4. Active DirectoryActive Directory 在企业中在企业中
域和域和 OUsOUs 组成层组成层
次化管理结构次化管理结构
多个域可以组成多个域可以组成
树树 -Trees-Trees
森林森林 -Forests-Forests
Forest
Objects
DomainDomainDomainDomain
DomainDomain
Tree
DomainDomain
DomainDomain
Tree
DomainDomain
OUOU OUOU
OUOU
5. Active Directory SchemaActive Directory Schema
ObjectObject
Class ExamplesClass Examples
ObjectObject
Class ExamplesClass Examples
PrintersPrinters
ComputersComputers
UsersUsers
Attributes of UsersAttributes of Users
Might Contain:Might Contain:
Attributes of UsersAttributes of Users
Might Contain:Might Contain:
accountExpires
department
distinguishedName
middleName
accountExpires
department
distinguishedName
middleName
List of AttributesList of AttributesList of AttributesList of Attributes
accountExpires
department
distinguishedName
directReports
dNSHostName
operatingSystem
repsFrom
repsTo
middleName
…
accountExpires
department
distinguishedName
directReports
dNSHostName
operatingSystem
repsFrom
repsTo
middleName
…
AttributeAttribute
ExamplesExamples
AttributeAttribute
ExamplesExamples
Active Directory Schema Is:
动态可用的
动态可更新的
由 DACLs 保护
7. Global CatalogGlobal Catalog
Global Catalog Server
Global CatalogGlobal CatalogGlobal CatalogGlobal Catalog
Subset of the
Attributes of All
Objects
Subset of the
Attributes of All
Objects
DomainDomain
Domain
DomainDomain
Domain
查询查询查询查询
Group membershipGroup membership
when user logs onwhen user logs on
Group membershipGroup membership
when user logs onwhen user logs on
27. 网络连接网络连接
AD Site link –AD Site link – 站点连接站点连接
BJ ----- SHBJ ----- SH
BJ ----- GZBJ ----- GZ
SH ----- GZSH ----- GZ
BJ ----- CDBJ ----- CD
Exchange 2000Exchange 2000 路由组路由组
与与 AD Site LinkAD Site Link 匹配匹配
管理组管理组
与路由组匹配与路由组匹配
InternetInternet 出口出口 ------ 北京，成都北京，成都
30. 安装安装 Exchange 2000Exchange 2000
First server
in the forest
Forest
Setup /forestprepSetup /forestprep
Windows 2000
ConfigConfigConfigConfig
SchemaSchemaSchemaSchema
ModifyModifyModifyModify
ModifyModifyModifyModify
InstallInstallInstallInstall
准备森林设置准备森林设置 /forestprep/forestprep
40. 计划路由组计划路由组
服务器必须属于同一个 Active Directory directory service
forest
服务器彼此之间必须永久连接
路由组内的所有服务器必须能够连接到 routing group
master
在一个路由组的在一个路由组的 Exchange 2000Exchange 2000 必须满足下列条件必须满足下列条件在一个路由组的在一个路由组的 Exchange 2000Exchange 2000 必须满足下列条件必须满足下列条件
Cost = 10
Cost = 30
AAAA CCCC
BBBBCost = 10
User
C
User
C
User
C
User
C
43. 文件放置文件放置
系统分区和启动分区系统分区和启动分区
Mirror Set
C:
Storage Group 1
Transaction Logs
Storage Group 1
Transaction Logs
Mirror Set
E:
Storage Group 2
Transaction Logs
Storage Group 2
Transaction Logs
Mirror Set
F:
Page FilePage File
D:
All Database Files For
Both Storage Groups
All Database Files For
Both Storage Groups
Stripe Set with Parity
G:
51. Secure SMTP ServerSecure SMTP Server
Secure relaySecure relay
settingssettings
Best Practice:Best Practice:
Default settings!Default settings!
52. ISA ServerISA Server 配置配置
HTTPS (SSL)HTTPS (SSL)
映射的协议映射的协议 : “HTTPS server”: “HTTPS server”
ISA Server listens on 443/tcpISA Server listens on 443/tcp
接受入站通信接受入站通信
重新产生新的包转发给重新产生新的包转发给 OWA serverOWA server
保留原地址和端口保留原地址和端口
53. ISA ServerISA Server 配置配置
HTTPS (SSL) — SecurityHTTPS (SSL) — Security
如果要求监测如果要求监测 ??
使用使用 WebWeb 发布发布
ISA ServerISA Server 需要更高的能力需要更高的能力 -- 考虑使用硬件加密卡考虑使用硬件加密卡
SSLSSL 终止点终止点
SSL stops at ISA ServerSSL stops at ISA Server
Certificate per ISA Server IP addressCertificate per ISA Server IP address
SSLSSL 桥桥
SSL from Client to ISA Server; new SSL from ISASSL from Client to ISA Server; new SSL from ISA
Server to OWA serverServer to OWA server
需要证书从需要证书从 ISAISA 到到 OWA serversOWA servers
54. ISA ServerISA Server 配置配置
SMTPSMTP
映射的协议映射的协议 : “SMTP Server”: “SMTP Server”
典型典型 ISA ServerISA Server 反向代理方式反向代理方式
SMTP filterSMTP filter 提供保护提供保护
附件部署附件部署
拒绝的发送者和域拒绝的发送者和域
SMTPSMTP 命令确认和限制命令确认和限制
关键词过滤关键词过滤
55. 保证保证 Exchange ServerExchange Server 安安
全全
Exchange
Server
ProtocolProtocol SourceSource DestinatioDestinatio
nn
PortPort
AnyAny InternalInternal
NetworkNetwork
Mail ServerMail Server AnyAny
ProtocolProtocol SourceSource DestinationDestination PortPort
SMTPSMTP AnyAny Mail ServerMail Server TCP 25TCP 25
POP3POP3 AnyAny Mail ServerMail Server TCP 110TCP 110
IMAPIMAP AnyAny Mail ServerMail Server TCP 143TCP 143
InternetInternet
56. Front end/Back EndFront end/Back End
FirewallFirewall
Open Ports:Open Ports:
443, 993, 995443, 993, 995
Exchange 2000Exchange 2000
Front-EndFront-End
ServerServer
Exchange 2000Exchange 2000
ServerServer
Active DirectoryActive Directory
Global Catalog ServerGlobal Catalog Server
Exchange 2000Exchange 2000
ServerServer
Exchange 2000Exchange 2000
ServerServerInternet
HTTP, IMAPHTTP, IMAP
or POP3 Clientor POP3 Client
63. 桌面防毒桌面防毒
Windows andWindows and 浏览器浏览器
下载最新的补丁下载最新的补丁
定制浏览器的安全区域选项定制浏览器的安全区域选项
OutlookOutlook 安全安全
Outlook 98 / 2000 SP1Outlook 98 / 2000 SP1
Upgrade available now from http://www.officeupdate.comUpgrade available now from http://www.officeupdate.com
Outlook 2002Outlook 2002
Built into base productBuilt into base product
安装最新防病毒工具安装最新防病毒工具
Editor's Notes
Good afternoon.
This is TechNet Session 1:
Next slide
Active Directory stores data for Exchange 2000 in partitions, which are also referred to as naming contexts. Active Directory uses naming contexts to define the boundaries for information that is stored within the database. The information that is stored in Active Directory on every domain controller in the forest is partitioned into three categories: domain, configuration, and schema. All Active Directory partitions are stored on domain controllers. You will be able to design your Exchange 2000 organization more effectively if you understand where Active Directory stores each type of information.
Domain Partition
The Active Directory domain partition contains all of the objects (such as users, groups, contacts, and computers) in the directory for the domain. Exchange recipients are Active Directory objects that have been included in the Exchange 2000 organization. Active Directory users, groups, and contacts can all be Exchange 2000 recipients.
Windows 2000 replicates domain configuration data in each domain to every domain controller in that domain, but not beyond that domain.
Configuration Partition
The Active Directory configuration partition contains the Exchange 2000 organization configuration. The configuration partition defines the topology, connectors, protocols, and service settings of the Exchange 2000 organization. Because Active Directory replicates the configuration partition across all domains in the forest, the configuration of the Exchange 2000 organization is replicated throughout the forest.
Schema Partition
The Active Directory schema partition contains all object types that can be created in Active Directory, as well as all attributes of such objects. This data is common to all domains in the forest, and is replicated by Active Directory to all domain controllers throughout the forest.
Key PointsThe Active Directory schema is extended with new attributes for Exchange 2000—attributes that have names that start with ms-Exch.Delivery TipUse ADSI Edit to show the students the various Active Directory partitions.During the installation in the Active Directory forest of the first computer running Exchange 2000, the Active Directory schema is extended with new attributes for Exchange 2000—attributes that have names that start with ms‑Exch. The schema is extended by using LDAP Directory Interchange Format (LDIF) files. You can examine which attributes have been added to Active Directory by viewing the LDIP files on the Exchange 2000 compact disc.
NoteInstalling the first computer running Exchange 2000 only extends the Active Directory schema if you have not already run /forestprep. You can view the Active Directory partitions by using Active Directory Service Interface (ADSI) Edit, which is included in the Windows 2000 support t
If you add 50,000 non-mail-enabled users to this new Active Directory database, the database will grow to approximately 345 MB, or 6K per user.
If you mail-enable those 50,000 users, the Active Directory database will grow to approximately 425 MB, or 7K per user.
When designing an Exchange 2000 organization, you can design user principle names (UPNs) to alleviate any confusion that might be generated by differences between the domain namespace and the e-mail namespace. Typically, administrators use a single user principle name suffix for each forest.
Designing a Single User Principle Name Suffix
Consider creating and assigning a single user principle name suffix as the default for all users. For example, as shown in the illustration on this page, you can create and assign a user principle name suffix of @nwtraders.msft as the default for all users. Making the user principle name the same as the SMTP address provides users with a single namespace that they can use for logging on to the network and for gaining access to e-mail.
Separating User Principle Names From the Mail Namespace
An organization might want to separate user principle names from the namespace that is used for e-mail. Separating user principle names from Internet e-mail addresses increases security by not affiliating user names with publicly known e-mail addresses.
NoteUPNs must be unique across the entire forest.
DSAccess uses one common set of commands to access the Active Directory. Exchange 2000 queries Active Directory for both user and configuration information. The most important part of DSAccess is the shared cache, which caches search results between different services in Exchange 2000.
Global Catalog Access
For access to the global catalog, DSAccess first queries the Windows 2000 site to which the server running Exchange 2000 belongs. If all global catalog servers in that site are unavailable, DSAccess queries other sites.
Domain Controller Access
For access to a domain controller, DSAccess first queries domain controllers within the same site and domain as the server running Exchange 2000. If no such domain controller is available, DSAccess queries domain controllers outside the site but still within the same domain. If more than one domain controller is available, DSAccess selects one by using the round-robin method. If the desired information is not stored on one of the domain controllers, DSAccess makes a Domain Name System (DNS) query for the nearest global catalog server and then requests the information again.
During initialization, DSAccess dynamically detects available directory service servers within the domain, unless you manually configure static entries. There are two kinds of detection algorithms, one for domain controllers and one for global catalog servers.
Detecting Domain Controllers
DSAccess uses DNS to provide a list of all of the domain controllers in the local domain and the local Active Directory site. DSAccess saves up to ten domain controller names in its cache; it load balances the usage of these domain controllers in a round robin fashion.
Detecting Global Catalog Servers
Global catalog server detection is different from traditional service detection. To detect global catalog servers, DSAccess uses the Lightweight Directory Access Protocol (LDAP) connection to the domain controller that DSAccess is currently bound to. On the domain controller, DSAccess reads the Options attribute of the Microsoft Windows NT® Directory Service Settings object for each directory service server, if any, in the site that contains the server running Exchange 2000. DSAccess detects which of the listed domain controllers are also global catalog servers. The global catalog servers are added to the DSAccess profile, and load balancing takes place.
If DSAccess does not find any global catalog servers in the local domain and site, a remote global catalog server is selected. Using a global catalog server in a remote site is not an optimal solution, however, because the global catalog servers in other Active Directory sites may be located across slow links and may not be load balanced.
DSAccess performs a full network redetection whenever either the Kerberos version 5 authentication protocol ticket times out (there is a default period of 10 hours) or a configuration change is made, such as the addition of a new domain controller or global catalog server.
Defining Domain Controllers and Servers
The DSAccess process communicates with Active Directory servers to look up information in the address book and to read configuration data. You can configure DSAccess to send directory queries to specific Active Directory domain controllers and servers.
DSAccess contacts an Active Directory server by making a DNS query. You can require a server running Exchange 2000 to always use the same Active Directory server by changing the registry settings.
If you manually configure global catalog servers, but do not specify domain controllers in the registry, DSAccess dynamically detects and uses any available domain controller. Similarly, if you manually configure domain controllers but do not specify any global catalog servers in the registry, DSAccess dynamically detects and uses any available global catalog servers.
The following registry keys are required to statically configure domain controller and global catalog servers for use by DSAccess. Multiple domain controllers and global catalog servers can be specified for load balancing, but only one Configuration-Context Domain Controller can be configured.
User-Context Domain Controller
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\UserDC1 (UserDC2, and so on) IsGC = REG_DWORD 0x0HostName = REG_SZ DC_ComputerName.DomainName.comPortNumber = REG_DWORD (0x185 by default or 0x27C for SSL)
User-Context Global Catalog Server
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default\UserGC1 (UserGC2 and so on)IsGC = REG_DWORD 0x1HostName = REG_SZ GC_ComputerName.DomainName.comPortNumber = REG_DWORD (0xCC4 by default or 0xCC5 for SSL)
Configuration-Context Domain Controller
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Instance0ConfigDCHostName = REG_SZ configDC_ComputerName.DomainName.comConfigDCPortNumber = REG_DWORD (0x185 by default or 0x27C for SSL)
ImportantIf these registry entries are configured so that a server running Exchange 2000 only queries specific domain controllers and global catalog servers, that server running Exchange 2000 will no longer dynamically detect domain controllers and global catalogs. This means that if none of the servers in a specific list are working, Exchange 2000 will be unable to perform any directory lookups.
In order to plan DNS server deployment to support your Active Directory domains, you must identify the DNS servers that will be authoritative for your domain names, and ensure they meet the requirements of the domain controller locator system.
Authority and Delegation in DNS
The Domain Name Service is a hierarchical, distributed database. The database itself consists of resource records, which primarily consist of a DNS name, a record type, and data values that are associated with that record type. For example, the most common records in the DNS database are Address (A) records, where the name of an Address record is the name of a computer, and the data in the record is the TCP/IP address of that computer.
Like Active Directory, the DNS database is divided into partitions that enable the database to scale efficiently even on very large networks. A partition of the DNS database is called a zone. A zone contains the records for a contiguous set of DNS names. A DNS server that loads a zone is said to be authoritative for the names in that zone.
A zone begins at a specified name and ends at a delegation point. A delegation point indicates where one zone ends and another zone begins. For example, there is a registration authority on the Internet that is responsible for the zone called “com.” Inside this zone are thousands of delegation points to other zones, for example, reskit.com. The data in a delegation point indicates which servers are authoritative for the delegated zone. Figure 9.10 shows the relationship among DNS servers, zones, and delegations.
The Domain Controller Locator System
Domain controllers register a set of records in DNS. These records are collectively called the locator records. When a client requires a particular service from a domain, it sends a query for a specific name and type of record to the nearest DNS server. The answer is a list of domain controllers that can satisfy the request.
The names of the locator records for each domain end in <DNS-domain-name> and <DNS-forest-name>. The DNS servers that are authoritative for each <DNS-domain-name> are authoritative for the locator records.
Note
Windows 2000 does not require reverse lookup zones to be configured. Reverse lookup zones maybe be necessary for other applications, or for administrative convenience.
DNS Server Requirements
If you do not already have DNS servers running on your network, it is recommended that you deploy the DNS service that is provided with Windows 2000 Server. If you have existing DNS servers, then the servers that are authoritative for the locator records must meet the following requirements to support Active Directory:
Must support the Service Location Record.
The DNS servers that are authoritative for the locator records must support the Service Location (SRV) resource record type. For more information about the SRV record, see “Windows 2000 DNS” in the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.
Should support the Dynamic Update Protocol.
The DNS servers that are authoritative for the locator records and are the primary master servers for those zones should support the Dynamic Update Protocol as defined in RFC 2136.
The DNS service provided with Windows 2000 Server meets both these requirements and also offers two important additional features:
Active Directory Integration
Using this feature, the Windows 2000 DNS service stores zone data in the directory. This makes DNS replication multi-master, and it allows any DNS server to accept updates for a directory service-integrated zone. Using Active Directory integration also reduces the need to maintain a separate DNS zone transfer replication topology.
Secure Dynamic Update
Secure dynamic update is integrated with Windows security. It allows an administrator to precisely control which computers can update which names, and it prevents unauthorized computers from stealing existing names out of DNS.
The remaining DNS servers on your network that are not authoritative for the locator records do not need to meet these requirements. Servers that are not authoritative are generally able to answer SRV record queries even if they do not explicitly support that record type.
Placement strategy
The availability of DNS directly affects the availability of Active Directory. Client computers rely on DNS to be able to find a domain controller, and domain controllers rely on DNS in order to find other domain controllers. Even if you already have DNS servers deployed on your network today, you might need to adjust the number and placement of servers to meet the needs of your Active Directory clients and domain controllers.
As a general rule, place at least one DNS server in every site. The DNS servers in the site should be authoritative for the locator records of the domains in the site, so that clients do not need to query DNS servers off-site to locate domain controllers that are in a site. Domain controllers will also periodically verify that the entries on the primary master server for each locator record are correct.
A simple configuration that satisfies all requirements is to use Active Directory-integrated DNS, store the locator records for a domain within the domain itself, and run the Windows 2000 DNS service on one or more domain controllers for each site where those domain controllers appear.
Distributing the Forest Wide Locator Records
Each domain controller in the forest registers two sets of locator records: a set of domain-specific records that end in <DNS-domain-name>, and a set of forest-wide records that end in _msdcs.<DNS-forest-name>. The forest-wide records are interesting to clients and domain controllers from all parts of the forest. For example, the global catalog locator records, and the records used by the replication system to locate replication partners, are included in the forest-wide records.
In order for any two domain controllers to replicate between each other, including two domain controllers from the same domain, they must be able to look up forest-wide locator records. In order for a newly created domain controller to participate in replication, it must be able to register its forest-wide records in DNS, and other domain controllers must be able to look up these records. For this reason, it is important to make the forest-wide locator records available to every DNS server in every site.
To do this, create a separate zone called _msdcs.<DNS-forest-name>, and replicate that zone to every DNS server. If you are using the simple Active Directory-integrated configuration, you can place the primary copy of this zone in the forest root domain along with the <DNS-forest-name> zone. You can then replicate the zone to DNS servers outside the domain using standard DNS replication.
Generally, it is not sufficient to replicate the zone to only one DNS server per site. If a DNS server does not have a local copy of the _msdcs.<DNS-forest-name> zone, it must use DNS recursion to look up a name in that zone. In order for a DNS server to perform recursion, it contacts a DNS server that is authoritative for the root of the namespace (a DNS root server) and walks down the delegations in DNS until it finds the record in question. If there is no DNS root server in a site, and the links between that site and other sites are down, a DNS server will not be able to perform recursion. Thus, it will not be able to find any DNS servers that are authoritative for _msdcs.<DNS-forest-name>, even if those DNS servers are in the same site.
DNS Client Configuration
Client computers and domain controllers should be configured with at least two DNS server IP addresses: a preferred local server, and an alternate server. The alternate server can be in the local site, or it can be remote if you trust your network to handle the failover.
The location of servers on your site topology has a direct effect on the availability of Active Directory. During the physical partitioning exercise of the domain plan, you created a basic plan for domain controller placement. By placing servers onto the site topology, you will complete the details of this plan.
Placing Additional Domain Controllers
During the partitioning exercise, you decided which sites would have domain controllers for each domain, but you did not decide on the number of domain controllers that would be placed in each site for each domain. The number of domain controllers you will create for a given domain is driven by two factors: fault tolerance requirements and load distribution requirements.
For each domain, use the following guidelines to determine if more domain controllers are necessary:
Always create at least two domain controllers.
Even for small domains with small user populations, create at least two domain controllers so that there is no single point of failure for the domain.
For each site that contains a single domain controller, decide if you trust the WAN for failover.
Should the single domain controller fail, clients in the site can be serviced by other domain controllers for that domain that are located in other sites. If network connectivity is unreliable or intermittently available, you might not want to trust the network to handle failover. In that case, place a second domain controller for that domain into the site.
Place additional domain controllers for a domain into a site to handle the client workload.
The number of client computers that a particular server can handle depends on the workload characteristics and the hardware configuration of the server. Client computers randomly select from the available domain controllers in a site to distribute client load evenly.
The availability of global catalog servers is crucial to the operation of the directory. For example, a global catalog server must be available when processing a user log on request for a native mode domain, or when a user logs on with a user principal name.
Note
When processing a log on request for a user in a native mode domain, a domain controller sends a query to a global catalog server to determine the user’s universal group memberships. Since groups can be explicitly denied access to a resource, complete knowledge of a user’s group memberships are necessary to enforce access control correctly. If a domain controller of a native mode domain cannot contact a global catalog server when a user wants to log on, the domain controller will refuse the log on request.
As a general rule, designate at least one domain controller in each site as a global catalog server.
Use the same failover and load distribution rules that you used for individual domain controllers to determine whether additional global catalog servers are necessary in each site.
Note
In a single domain environment, global catalog servers are not required to process a user log on request. However, you should still designate global catalog servers using the suggested process. Client computers still seek global catalog servers for search operations. Also, having global catalog servers already in place allows the system to adapt gracefully if you add more domains later.
KEY MESSAGE: Explain the use of the HTTPS rule.
SLIDE BUILDS: None
SLIDE SCRIPT:
The HTTPS rule handles SSL traffic. The mapped protocol that you use in the publishing rule is HTTPS Server, which causes ISA Server to listen on TCP port 443. ISA Server receives inbound traffic on this port. It then regenerates new packets and forwards them to the OWA Servers. Using server publishing for this task preserves the source IP address and port.
SLIDE TRANSITION: Next, I will cover the security implications of using server publishing for SSL traffic.
ADDITIONAL INFORMATION FOR PRESENTER:
KEY MESSAGE: Explain how Web publishing for SSL connections allows for inspection of requests by ISA Server.
SLIDE BUILDS: None
SLIDE SCRIPT:
One potential issue with using server publishing is that encrypted traffic passes through ISA Server to an internal OWA Server. If this is not acceptable and if inspection of SSL requests is required, you must use Web publishing instead. This requires the configuration of listeners. If you decide to go this route, keep in mind that the ISA Server computer requires additional power to perform SSL processing. You may even consider using hardware encryption cards.
When using Web publishing, the SSL connection terminates at the ISA Server computer. To allow for this you have to configure configure a certificate for each IP address of the ISA Server computer on which you accept incoming requests.
You can also configure SSL bridging, which means that after the SSL session from the external client is terminated as ISA Server, a new SSL session is established from ISA Server to the OWA Server, encrypting traffic as it travels across your internal network. In this configuration you need certificates for the ISA Server computer and the OWA server.
SLIDE TRANSITION:
ADDITIONAL INFORMATION FOR PRESENTER:
KEY MESSAGE: Review SMTP server publishing rule
SLIDE BUILDS: None
SLIDE SCRIPT:
Finally, we created an SMTP server publishing rule. The mapped protocol that we used for this rule is SMTP Server. This rule gives us the typical ISA Server reverse proxy behavior. In addition, when we publish an SMTP server, we can also take advantage of the SMTP filter that provides protection by allowing you to specify whether ISA Server should forward, delete or hold messages with attachments that you specify. The SMTP filter can also reject e-mail based on senders and domains, it can perform SMTP command validation and limit allowed SMTP commands. Finally, this filter can filter e-mail based on keywords. Keep in mind that performing these functions requires additional configuration steps that are beyond the scope of this presentation.
SLIDE TRANSITION: Now that we configured ISA Server and reviewed the configuration, let’s test this configuration.
ADDITIONAL INFORMATION FOR PRESENTER:
Scans messages and attachments
Priority based Scanning Queue
Proactive Message Scanning
Enhanced Background Scanning
Thread pooling
Per-MDB Scanning
EDK Gateway content scanning
Message body and attachment scanning
Native MAPI/MIME content scanning
Scanner On-Demand Reload
Scans messages and attachments
Priority based Scanning Queue
Proactive Message Scanning
Enhanced Background Scanning
Thread pooling
Per-MDB Scanning
EDK Gateway content scanning
Message body and attachment scanning
Native MAPI/MIME content scanning
Scanner On-Demand Reload
On Access Scanning
When messages are accessed via client or agent
Proactive Scanning
As messages arrive inbound to the server
Background Scanning
Ongoing scanning of messages
Primarily used for re-scanning data when virus signatures are updated
