MS Exchange Server 

Microsoft Exchange Server interview questions

1.    What is a Distribution List?
     In e-mail applications, a distribution list is a group of mail recipients that is addressed as a single recipient. Distribution lists are used to send e-mail to groups of people without having to enter each recipient's individual address. A distribution list is different from an e-mail list in that members cannot reply to the distribution list's name to send messages to everyone else in the group.

Distribution list is a term sometimes used for a function of email clients where lists of email addresses are used to email everyone on the list at once. This can be referred to as an electronic mailshot. It differs from a mailing list, electronic mailing list or the email option found in an Internet forum as it is usually for one way traffic and not for coordinating a discussion. In effect, only members of a distribution list can send mails to the list.

2.    GAL, Routing Group, Stm files, Eseutil & ininteg - what are they used for?
(.STM) Streaming store file. A file used by Microsoft Exchange (mail) server to store user emails. The file is
called a streaming file since data is added to it sequentially in its native format. The data itself inside
the STM file is not encoded or encrypted in any way so if a store is dismounted the file can be viewed
using a text editor.
ESEUTIL is a repair utility. It is a tool to defragment your exchange databases offline, to check their integrity and to
  repair a damaged/lost database.
ESEUTIL is located in the \EXCHSRVR\BIN directory. This directory is not in the system path so you must open the
 tool in the BIN directory or enhance the system path with the \EXCHSRVR\BIN directory.
GAL : is Global Address List, it contains most if not all email addresses in your Exchange organization.

3.    What is MIME & MAPI?
MIME = Multipurpose Internet Mail Extensions It defines non-ASCII message formats. It  is a coding standard that defines the structure of E-Mails and other Internet messages. MIME is also used for declaration of content from other Internet protocols like HTTP, Desktop environments like KDE, Gnome or Mac OS X Aqua. The standard is defined in RFC 2045.
With MIME it is possible to exchange information about the type of messages (the content type) between the sender and the recipient of the message. MIME also defines the art of coding (Content-Transfer-Encoding).
These are different coding methods defined for the transportation of non ASCII characters in plain text documents and non text documents like Images, Voice and Video for transportation through text based delivery systems like e-mail or the Usenet.
The non text elements will be encoded from the sender of the message and will be decoded by the message recipient. Coding of non ASCII characters is often based on “quoted printable” coding, binary data typically using Base64-coding.
There is an extension of this Standard called S/MIME (Secure Multipurpose Internet Mail Extensions) that allows the signing and encryption of messages. There are other e-mail encryption solutions like PGP/MIME (RFC 2015 and 3156).

 MAPI = Messaging Application Programming Interface It's the programming interface for email. It is a Microsoft Windows program interface that enables you to send e-mail from within a Windows application and attach the document you are working on to the e-mail note. Applications that take advantage of MAPI include word processors, spreadsheets, and graphics applications. MAPI-compatible applications typically include a Send Mail or Send in the File pulldown menu of the application. Selecting one of these sends a request to a MAPI server

4.    List the services of Exchange Server 2003?
There are several services involved with Exchange Server, and stopping different services will accomplish different things. The services are interdependent, so when you stop or start various services you may see a message about having to stop dependent services. If you do stop dependent services, don't forget to restart them again when you restart the service that you began with.
To shut down Exchange completely on a given machine, you need to stop all of the following services:

Microsoft Exchange Event (MSExchangeES)
This service was used for launching event-based scripts in Exchange 5.5 when folder changes were detected. Exchange 2000 offered the ability to create Event Sinks directly, so this use of this service has decreased. This service is not started by default.

Microsoft Exchange IMAP4 (IMAP4Svc)
This service supplies IMAP4 protocol message server functionality. This service is disabled by default. To use IMAP4 you must enable this service, configure it to auto-start, and start the service.

Microsoft Exchange Information Store (MSExchangeIS)
This service is used to access the Exchange mail and public folder stores. If this service is not running, users will not be able to use Exchange. This service is started by default.

Microsoft Exchange Management (MSExchangeMGMT)
This service is responsible for various management functions available through WMI, such as message tracking. This service is started by default.

Microsoft Exchange MTA Stacks (MSExchangeMTA)
This service is used to transfer X.400 messages sent to and from foreign systems, including Exchange 5.5 Servers. This service was extremely important in Exchange 5.5, which used X.400 as the default message transfer protocol. Before stopping or disabling this service, review MS KB 810489. This service is started by default.

Microsoft Exchange POP3 (POP3Svc)
This service supplies POP3 protocol message server functionality. This service is disabled by default. To use POP3 you must enable this service, configure it to auto-start, and start the service.

Microsoft Exchange Routing Engine (RESvc)
This service is used for routing and topology information for routing SMTP based messages. This service is started by default.

Microsoft Exchange System Attendant (MSExchangeSA)
This service handles various cleanup and monitoring functions. One of the most important functions of the System Attendant is the Recipient Update Service (RUS), which is responsible for mapping attributes in Active Directory to the Exchange subsystem and enforcing recipient policies. When you create a mailbox for a user, you simply set some attributes on a user object. The RUS takes that information and does all of the work in the background with Exchange to really make the mailbox. If you mailbox-enable or mail-enable objects and they don't seem to work, the RUS is one of the first places you will look for an issue. If you need to enable diagnostics for the RUS, the parameters are maintained in a separate service registry entry called MSExchangeAL. This isn't a real service; it is simply the supplied location to modify RUS functionality. This service is started by default.

Microsoft Exchange Site Replication Service (MSExchangeSRS)
This service is used in Organizations that have Exchange 5.5 combined with Exchange 2000/2003. This service is not started by default.

Network News Transfer Protocol (NntpSvc)
This service is responsible for supplying NNTP Protocol Server functionality. This service is started by default.

Simple Mail Transfer Protocol (SMTPSVC)
This service is responsible for supplying SMTP Protocol Server functionality. This service is started by default.

Core Exchange Server 2003 Services
Topic Last Modified: 2005-05-23
The following figure illustrates the core components of Exchange Server 2003, together with their service dependencies. Core components are System Attendant, the Exchange Information Store service, the IIS Admin service, the SMTP service, and the Exchange installable file system (ExIFS). All of these services must be running on every Exchange Server 2003 server to guarantee a fully functioning messaging system.
Core Windows services and their dependent core Exchange Server 2003 services


IIS Admin service and SMTP service are integrated with IIS, as discussed in the previous section. The SMTP service must run on every server running Exchange Server 2003 because all messages sent to or from local recipients must pass through the SMTP transport engine. If the SMTP service is stopped or unavailable, Exchange Server 2003 cannot deliver messages. For more information about the routing architecture of Exchange Server 2003, see Message Routing Architecture.
The core components of Exchange Server 2003 have the following responsibilities.
•    Microsoft Exchange System Attendant service   System Attendant is one of the most important services in Exchange Server 2003. This component has many responsibilities, including maintaining communication with Active Directory, generating offline address lists, performing message tracking, and so forth. The executable file is Mad.exe and is located in the \Program Files\Exchsrvr\Bin directory. There are several registry keys that System Attendant uses for its various internal components under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\, such MSExchangeSA, MSExchangeDSAccess, MSExchangeAL, MSExchangeFBPublish, MSExchangeMU, and MSExchangeADDXA.
The following table lists the responsibilities of System Attendant.
•    Exchange Information Store service   The Microsoft Exchange Information Store service is another very important component in Exchange Server 2003, because it maintains the messaging databases that contain all server-based mailboxes and public folders. The executable file of the Exchange Information Store service is Store.exe, located in the \Program Files\Exchsrvr\Bin directory. The corresponding registry key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS.
The Exchange store uses Extensible Storage Engine (ESE) to maintain the messaging databases and supports a variety of clients through corresponding store extensions. The following figure illustrates how the various client types can access messaging data.
Exchange store architecture and supported messaging clients


MAPI clients communicate directly with the Exchange Information Store service through MAPI RPCs. Internet clients, however, use protocol engines integrated with IIS, as explained earlier in this section. Internet clients and Web applications communicate with the Exchange store through IIS protocol engines. This communication takes place through a store driver, Epoxy.dll, and store extensions, such as ExSMTP.dll or ExIMAP.dll. The EPOXY layer is a fast inter-process communication (IPC) mechanism based on shared memory, which is used by Drviis.dll and store extensions to coordinate their processing. For example, when delivering an inbound message through SMTP, Drviis.dll uses the Exchange installable file system to create a message item in the Exchange store, and then communicates with ExSMTP.dll through EPOXY to instruct the Exchange store to further process the message (that is, to place the message into the recipient's mailbox). For more information about the interaction between Drviis.dll, Epoxy.dll, store extensions, Store.exe and ExIFS, see Exchange Information Store Service Architecture.
•    Exchange Installable File System   The Exchange installable file system is a kernel-mode driver, implemented in ExIfs.sys, which IIS protocol engines and Web applications can use to read and write items from and to messaging databases. To gain access to the databases, the ExIFS file system driver must communicate with the Exchange store. This is accomplished through a store extension (ExWin32.Dll) and a user-mode wrapper (Ifsproxy.dll). The Exchange store, on the other hand, uses ESE to access .stm and .edb files, which are files that reside on a drive formatted with the NTFS file system. The following figure illustrates this architecture.
The ExIFS architecture


As mentioned in Exchange Server 2003 Technical Overview, a mailbox store or public folder store is made up of a streaming database (.stm) and a MAPI database (.edb). The IIS components use ExIFS to work with streaming databases, while MAPI clients, such as Outlook, work with MAPI-based databases (.edb). A streaming database holds Internet messages in their native format, such as MIME, while an .edb database stores e-mail messages in MAPI format. The Exchange store must keep both the streaming databases and the corresponding MAPI-based databases synchronized. To accomplish this, the Exchange store must communicate with ExIFS, in addition to ESE. For example, when allocating free space in a database, ExIFS requests space from ESE. ESE must track which pages in the streaming database are reserved and committed. Thus, the Exchange Information Store service depends on ExIFS. The registry key for ExIFS is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS. For more information about ExIFS and the architecture of the Exchange store, see Exchange Information Store Service Architecture.
 Note:

ExIFS is the only kernel-mode component in Exchange Server 2003.

5.    How would you recover Exchange server when the log file is corrupted?
To resolve this issue, you must remove the corrupted log file from your Microsoft Exchange 2000 Server computer. To remove the corrupted log file, follow these steps:
6.    What is required for using RPC over Https with MS Outlook ?
You can configure user accounts in Microsoft® Office Outlook® 2003 to connect to Microsoft Exchange Server 2003 over the Internet without the need to use virtual private network (VPN) connections. This feature — connecting to an Exchange account by using Remote Procedure Call (RPC) over HTTP — allows Outlook users to access their Exchange Server accounts from the Internet when they are traveling or are working outside their organization's firewall.
There are several requirements for this feature. These include:
     Microsoft Windows® XP with Service Pack 1 and the Q331320 hotfix (or a later service pack) installed on users' computers
     Outlook 2003
     Microsoft Exchange Server 2003 e-mail accounts
     Microsoft Windows Server™ 2003 (required for server components only)

SERVER REQUIREMENTS
RPC over HTTP/S requires Windows Server 2003 and Exchange Server 2003. RPC over HTTP/S also requires Windows Server 2003 in a Global Catalog role.
CLIENT REQUIREMENTS
•    The client computer must be running Microsoft Windows XP Professional Service Pack 1 (SP1) or later.
If you're running SP1, you must install the following update package:
Outlook 2003 Performs Slowly or Stops Responding When Connected to Exchange Server 2003 Through HTTP - 331320
If you have installed Windows XP SP2, you do NOT have to install the update package.

You can also run Windows Server 2003 as the client operating system.
•    The client computer must be running Microsoft Office Outlook 2003.
RECOMMENDATIONS
Here are some of Microsoft's (and my) recommendations when using Exchange with RPC over HTTP:
•    Use basic authentication over Secure Sockets Layer (SSL) - You should enable and require the use of SSL on the RPC proxy server for all client-to-server communications.
•    Use an advanced firewall server on the perimeter network - A dedicated firewall server is recommended to help enhance the security of your Exchange computer. Microsoft Internet Security and Acceleration (ISA) Server 2000 is an example of a dedicated firewall server product.
•    Obtain a certificate from a third-party certification authority (CA) - When using the Basic Authentication you MUST use an SSL-based connection, and you will have to configure a Digital Certificate for your Default Website. Read Configure SSL on Your Website with IIS for more on this issue.
A Digital Certificate needs to be obtained from a CA (Certification Authority), either a 3rd-party commercial CA such as Verisign, Thawte and others, or from an internal CA.
Windows 2000/2003 has a built-in CA that can be installed and used, however, when issuing a Digital Certificate from your internal CA you MUST be 100% sure that the client computers that are going to connect to the server are properly configured to trust this CA.
Most operating systems are pre-configured to trust known 3rd-party CAs such as Verisign, Thawte and others. However unless these computers are made members of the Active Directory domain where you've installed your CA, they will NOT automatically trust your internal CA, and thus your connection will fail! In these scenarios, when a user tries to connect by using RPC over HTTP/S, that user loses the connection to Exchange and is NOT notified.
In such scenarios you must import the ROOT CA Digital Certificate into the client computers in order to make them trust your CA.
When using 3rd-party trusted CAs, in most cases you won't be required to import anything to the client computers, however you will be required to pay a few hundred dollars for such a Digital Certificate.
Additionally, if you use your own certification authority, when you issue a certificate to your RPC proxy server, you must make sure that the Common Name field or the Issued to field on that certificate contains the same name as the URL of the RPC proxy server that is available on the Internet.

7.    If you have deleted the user, after you recreated the same user. How you will give the access of previous mail box ?
Reconnect the Deleted user’ s mailbox to the recreated user. Provided the recreated user doesn’t have mailbox .

8.    If NNTP service get stoped, what features of exchange will be effected ?
9.    Which protocol is used for Public Folder ?         NNTP Network News Transfer Protocol, both nntp and imap helps clients to access the public folder. but actually, Smtp send the mails across the public folder.
10.    What is latest service pack Exchange 2003?     SP2
11.    What is latest service pack Exchange 2000?       SP4
12.    What is the name of Exchange Databases?        priv1.edb
13.    How many databases in Standard Exchange version   1
14.    How many databases in Enterprise Exchange version  20
15.    What is Storage Group?
The Exchange store has several logical components that interact with each other. These components can reside on a single server, or they can be distributed across multiple servers. This topic provides details about the following primary components of the Exchange store:
•    Storage groups (including recovery storage groups)
•    Mailbox databases
•    Public folder databases
  Storage groups
An Exchange storage group is a logical container for Exchange databases and their associated system and transaction log files.
Storage groups are the basic unit for backing up and restoring data in Microsoft Exchange (although you can restore a single database). All databases in a storage group share a single backup schedule and a single set of transaction log files.
Exchange Server 2007 Enterprise Edition supports up to 50 storage groups. Exchange 2007 Standard Edition supports up to five storage groups.

16.    What is mail store?
MAIL STORE
The mail store is a directory or Universal Naming Convention (UNC) path where the POP3 service stores all e-mail until users retrieve it to their client computer.

The basic structure of the mail store, or mail root, is a directory on the local hard disk where all e-mail is stored.
When a domain is created, the POP3 service creates a corresponding directory in the directory that has been designated for the mail store. For each user with a mailbox in that domain, POP3 creates a directory in the domain directory. E-mail that a user receives is stored as an individual file within the user's directory until the user retrieves it using a POP3 e-mail client.
The following is an example of the path to an e-mail message in the mail store:
C:\inetpub\mailroot\mailbox\example.com\P3_someone.mbx\P347865.eml

where mailroot corresponds to the mail store directory, example.com to the domain directory, P3_somone.mbx to the directory for a mailbox named someone and P347865.eml to a single saved e-mail message.
The directory and file permissions for each directory in the mail store are identical. When you configure the mail store, the permissions are set so that only local or domain administrators and the local network service, which the POP3 service is configured to run under, are assigned permissions to the directories. No other user is assigned read/write permissions.
The mail store's functionality depends on having adequate hard disk space available. To ensure the mail store's functionality, you should develop a disk-space requirement estimate based on the number of users on the server, the volume of e-mail that they will receive, and the average size of the e-mail they will receive.
In addition, you can protect the server from situations where the mail store's disk usage might increase unexpectedly by implementing disk quotas. Disk quotas monitor and control disk space that is used on NTFS file system volumes. For more information, see Configuring disk quotas for the POP3 service.
Notes
Because the mail store can potentially use large amounts of disk space, you should either set a disk quota limit on the volume of the mail store (to control its disk space usage) or set it to use a volume other than the one where the operating system is installed. This will prevent the possibility of the operating system running out of disk space if the mail store becomes too large. For more information, see Set the mail store. For more information on disk quotas, see Configuring disk quotas for the POP3 service.
The mail store must be configured to use either a directory on the local hard disk or a UNC path; other storage options, such as mapped drives, are not supported.
You cannot set the mail store to the root directory of the hard disk, for example C:\, or to a directory in which files are currently in use.
If you restore the mail store from a backup or move it to a new location, you must reset the permissions on the mail store directory using the command-line procedure described in Set the mail store.
If you transfer the mail store to a new directory, you must move the mail store directory to ensure the directory retains the correct ownership; copying the mail store will not work.
Physical access to a server is a high security risk. To maintain a more secure environment, restrict physical access to the server where the mail store resides.

17.    Explain Exchange transaction logs

Before changes are actually made to an Exchange database file, Exchange writes the changes to a transaction log file. After a change has been safely logged, it can then be written to the database file.
One of the most important components of Exchange server is the transaction logs. Exchange server was designed to write all transactions to these log files and commit the changes to the databases when the system allows. Users can send and receive messages without touching the database thanks to this write-ahead method of logging.
When a message is sent, the transaction is first recorded in the transaction logs. Until the transaction is committed to the Exchange database (EDB), the only existence of this data is in the system memory and the transaction logs. In the event of a crash, you lose the contents of the memory and all you are left with is the record in the transaction log. These transaction logs are crucial to the recovery of a failed Exchange server, whether it was a minor crash that required a reboot, or a more catastrophic failure requiring the deployment of your disaster recovery plans. The same goes for other transactions such as received messages, deleted items and messages moved to different folders.
18.    What is default size for Transaction logs?
5 MB for 2003 and 1 MB for 2007

19.    Why exchange is using transaction logs? Why not to write to data directly to the Exchange database?
One of the most important components of Exchange server is the transaction logs. Exchange server was designed to write all transactions to these log files and commit the changes to the databases when the system allows. Users can send and receive messages without touching the database thanks to this write-ahead method of logging.
When a message is sent, the transaction is first recorded in the transaction logs. Until the transaction is committed to the Exchange database (EDB), the only existence of this data is in the system memory and the transaction logs. In the event of a crash, you lose the contents of the memory and all you are left with is the record in the transaction log. These transaction logs are crucial to the recovery of a failed Exchange server, whether it was a minor crash that required a reboot, or a more catastrophic failure requiring the deployment of your disaster recovery plans. The same goes for other transactions such as received messages, deleted items and messages moved to different folders.
For this reason, it is recommended to house the transaction files on a redundant storage system, like a RAID 1 array, so that in the event of a hardware failure, no data is lost. Losing a set of transaction logs will not prevent you from restoring from your backups, but you will lose all the messages and changes since the last full backup.

20.    How exchange database gets defragmented?
There are two types of Exchange database defragmentation: online and offline.

Online Defragmentation
Online defragmentation is one of several database-related processes that occur during Exchange database maintenance. By default, on servers running Exchange 2000 Server and Exchange Server 2003, Exchange Server database maintenance occurs daily between 01:00 (1:00 A.M.) and 05:00 (5:00 A.M.). Online defragmentation occurs while Exchange Server databases remain online. Therefore, your e-mail users have complete access to mailbox data during the online defragmentation process.

The online defragmentation process involves automatically detecting and deleting objects that are no longer being used. This process provides more database space without actually changing the file size of the databases that are being defragmented.

Note: To increase the efficiency of defragmentation and backup processes, schedule your maintenance processes and backup operations to run at different times.

Offline Defragmentation
Offline defragmentation involves using the Exchange Server Database Utilities (Eseutil.exe). ESEUTIL is an Exchange Server utility that you can use to defragment, repair, and check the integrity of Exchange Server databases. It is available through the following sources:

If you are running Exchange 2000 Server, ESEUTIL is located in the E:\Support\Utils folder of your Exchange 2000 CD (where E:\ is the drive letter of your CD-ROM drive).
If you are running Exchange Server 2003, ESEUTIL is located in the F:\Program Files\exchsrvr\bin directory after running Exchange Server 2003 Setup (where F:\ is the drive letter of the drive to which you installed Exchange Server).
You can only perform offline defragmentation when your Exchange Server databases are offline. Therefore, your e-mail users will not have access to mailbox data during the offline defragmentation processes.

During the offline defragmentation process, Eseutil.exe creates a new database, copies the old database records to the new one, and then discards unused pages, resulting in a new compact database file. To reduce the physical file size of the databases, you must perform an offline defragmentation in the following situations:
After performing a database repair (using Eseutil /p)
After moving a considerable amount of data from an Exchange Server database.
When an Exchange Server database is much larger than it should be.
Defragmenting an Exchange 2000 or Exchange 2003 database
Defragmenting a database requires free disk space equal to 110 percent of the size of the database being processed.
1. In Exchange System Manager, right-click the information store that you want to defragment, and then click Dismount Store.
2. At the command prompt, change to the Exchsrvr\Bin folder, and then type the eseutil /d command, a database switch, and any options that you want to use.

For example, the following command runs the standard defragmentation utility on a mailbox store database:
C:\program files\exchsrvr\bin> eseutil /d c:\progra~1\exchsrvr\mdbdata\priv1.edb
Use the following database switch to run Eseutil defragmentation on a specific database:
eseutil /d <database_name> [options]

21.    What is white space, and how can it be reclaimed?
White space is nothing but free space.
When the 16 GB database size limit is reached on the Standard version of Exchange and white space must be reclaimed in order to mount the database. If you are running Exchange Server 2003, then Service Pack 2 (SP2) should be installed to raise the limit to 75 GB.
Free Space Reclamation
The version store is the area of the database that manages version control. When a transaction is committed to the database, a cleanup process returns space that is freed by modify and delete transactions to the database. For each modify or delete operation, the existing version of the record is written to the version store so that the database maintains a copy of the old version until the new version is written to the database. After the transaction is committed to the database, any space that is freed from deleted records and long values is returned to the table or index that owns the space. Until the change is committed to the database, requests for the object continue to access the old version. If the transaction is rolled back, the version store record is used to undo the transaction.
The version store has a size limit that is the lesser of the following: one-fourth of total random access memory (RAM) or 100 MB.
Because most domain controllers have more than 400 MB of RAM, the most common version store size is the maximum size of 100 MB. If too many large changes or deletions occur simultaneously, it is possible for the version store to run out of processing space. In this event, cleanup of free space is suspended temporarily. On domain controllers running Windows 2000 Server, the most common cause of version store overload is large-scale bulk deletions.
Bulk deletions and database growth in Windows 2000
Delete operations are the most CPU-intensive operations that the version store processes. On domain controllers running Windows 2000 Server, bulk deletions, such as the deletion of an entire tree of objects at one time, can cause a temporary condition in which free space cannot be returned to the database in a timely fashion because the cleanup process cannot keep up with the deletions. Event ID 602 is logged in the Directory Services event log to indicate this condition.
During the time that pages are being skipped by the cleanup process, free space is not released to the database, and space is not reclaimed until the next scheduled online defragmentation occurs. In the meantime, processing requirements can cause the database to grow. In particular, when bulk deletions or other bulk changes coincide with database additions, significant growth can occur. In addition, space from the deletion of long values is not returned to the database by online defragmentation. As a result of these conditions, the directory database on domain controllers running Windows 2000 Server can actually increase in size following a bulk deletion.
On domain controllers running Windows Server 2003, the effects of these conditions are greatly reduced by improvements in version store cleanup and online defragmentation. However, if event ID 602 is logged in the Directory Services event log, running online defragmentation manually can alleviate the problem. On domain controllers running Windows 2000 Server, the only way to prompt online defragmentation is to change the garbage collection interval to the minimum value of one hour to force garbage collection and online defragmentation to occur as soon as possible.
Improved space processing in Windows Server 2003
Two improvements in the Windows Server 2003 processing of free space eliminate the database growth problems that can result from large-scale bulk deletions:
•    The threshold at which the database begins skipping cleanup operations is increased from 5 percent to 90 percent.
•    Space is reclaimed from long-value deletions.
The threshold of maximum pages that can be processed by the version store is the limiting factor in whether the cleanup process can keep pace with deletions. The version store cleanup process can take place only as long as the version store has sufficient space. With a maximum version store size of 100 MB, only 5 MB (5 percent) is available in Windows 2000 Server, and this low threshold is responsible for early suspension of the cleanup process. The threshold of 90 MB (90 percent) in Windows Server 2003 eliminates this problem. For this reason, large-scale bulk deletions that can be problematic on domain controllers running Windows 2000 Server present no significant growth concerns on domain controllers running Windows Server 2003.
In addition, online defragmentation on domain controllers running Windows Server 2003 returns the space that is freed by long values to the long-value table, which further optimizes the availability of space in the database.

22.    What time online maintenance runs by default in Exchange?
Exchange Server database maintenance occurs daily between 01:00 (1:00 A.M.) and 05:00 (5:00 A.M.).

23.    What event log exchange logs after online defragmentation   What is the maximum storage capacity for Exchange standard version? What would you do if it reaches    maximum capacity?”

For Exchange Server 5.5, an Event 179 from source ESE97 is logged for each database at the beginning of online defragmentation. An Event 180 signals completion of online defragmentation. An Event 183 indicates that online defragmentation did not complete, but has been suspended and will finish later. Online defragmentation may be suspended if the online maintenance period that is defined for the database expires before online defragmentation completes. In this case, online defragmentation will resume where it left off during the next online maintenance window.

In Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003, event ID 700 signals the beginning of a full pass, and event ID 701 signals the completion of a full pass.

You may view or adjust the Information Store Maintenance schedule in the Exchange Server Administrator program for individual databases.

The free space that is reported by Event 1221 is a conservative estimate. If you perform offline defragmentation, you will recover at least the amount of space that is reported as free. All space in an Exchange database is owned either by the database root or by particular tables in the database. Event 1221 estimates free space by calculating the number of empty pages owned by the messages table, the attachments table, and the database root. Free pages that are owned by other tables in the database are not taken into account.

24.    . Retention Period: The retention period specifies how long Exchange will keep items that users have deleted. Upon deleting an item, Exchange marks the item for complete removal based on the retention period. The default retention period is set to 30 days: