Monday 17 October 2011

Collection: Exchange Server 2003 (2)



1.    TELL ME WHY WE R USEING EXCHANGE SERVER?
This is a mail server. We can use this Server to send mails in Intranet as well as outside.

2.    What is a smart host?
DNS-
This is the standard for sending mail. When Exchange needs to send mail to another domain it will look for the MX records of that domain and will attempt to contact the mail server directly.
Smart host-
In this case Exchange takes your outgoing mail and sends it to another mail server (which is called a “smart host”, hence the name). The smart host will deliver your mail to the other mail servers on your behalf. This is exactly what you do when you use Outlook Express to send mail using your ISP SMTP servers.

3.     An Exchange server is having bandwidth issues, explain how you would look at fixing the issue?

4.    What are the different Exchange 2003 versions?          

Standard Exchange version, Enterprise Exchange version and Small Business Server.

5.     What are the main differences between Exchange 5.5 and Exchange 2000/2003?
The primary differences are.
-Exchange 2000 does not have its own directory or directory service; it uses Active Directory instead.
-Exchange 2000 uses native components of Windows 2000 (namely, IIS and its SMTP, NNTP, W3SVC and other components, Kerberos and others) for many core functions.
-SMTP is now a full peer to RPC, and is it the default transport protocol between Exchange 2000 servers.
-Exchange 2000 supports Active/Active clustering and was recently certified for Windows 2000 Datacenter.
-Exchange 2000 scales much higher.
-It boasts conferencing services and instant messaging.

6.    What are the major network infrastructures for installing Exchange 2003?
Hardware Requirements
There are several factors that affect the hardware requirements for Exchange Server 2003: the number of users that will be accessing the server; the size and number of messages transferred on a daily basis (not to mention during peak usage periods); availability requirements; and so on. These factors will have a significant influence on the type of hardware you use for your deployment.
Component                           Minimum requirements
Processor                         Pentium 133
Operating system                         Windows 2000 Server + SP3
Memory                                     256 megabyte (MB)
Disk space                        200 MB on system drive, 500 MB on partition where Exchange Server 2003 is installed
Drive                               CD-ROM drive
Display                                       VGA or better
File system                       All partitions involving Exchange Server 2003 must be NTFS file system (NTFS), including
■System partition
■Partition storing Exchange binaries
■Partition containing Exchange database files
■Partition containing Exchange transaction logs
■Partitions containing other Exchange files.

Component                           Recommended requirements
Processor                         Pentium III 500 (Exchange Server 2003, Standard Edition) Pentium III 733 (Exchange Server 2003, Enterprise Edition)
Operating system                         Windows Server 2003
Memory                                     512 MB
Disk space                        200 MB on system drive, 500 MB on partition where Exchange Server 2003 is installed. Separate physical disks for the Exchange binaries, database files, and transaction logs.
Drive                               CD-ROM drive
Display                                       SVGA or better
File system All partitions involving Exchange must be NTFS, including
■System partition
■Partition storing Exchange binaries
■Partition containing Exchange database files
■Partition containing Exchange transaction logs
■Partitions containing other Exchange files

7.    What are the disk considerations when installing Exchange (RAID types, locations and so on).
 RAID -5, 200 MB on system drive, 500 MB on partition where Exchange Server 2003 is installed. Separate physical disks for the Exchange binaries, database files, and transaction logs.


8.    Why not install Exchange on the same machine as a DC? Are there any other installation considerations?
Microsoft recommends against installing Exchange on a domain controller, but does support this practice in environments that need to run this way. However, if you do find that you need to run Exchange on a domain controller--perhaps for budgetary reasons--make sure you know the limitations and make an informed decision:
·         Once Exchange is installed on the domain controller, you cannot reduce the server to member server status.
·         Normally considered a best practice, don't use the /3GB switch on domain controllers that are also running    Exchange as this can result in Exchange using too much system RAM.
·         A shut down or restart of a domain controller running Exchange can take more than 10 minutes due to the order in which services are unloaded for a shutdown. Before you restart these servers, manually stop the Exchange services to avoid these delays.
·         This installation method seriously hinders your high availability efforts as Exchange will use only the services offered by the host domain controller and will not seek out others if the AD services (i.e. Global Catalog servers) experience a problem.
In general, unless you absolutely have to run Exchange on a domain controller, you should try to install Exchange to a member server.

Exchange on a DC
One question that often pops up in the Exchange world is whether it's a good idea (or not, as the case may be) to install Exchange on a domain controller. Generally, this has not been recommended in the past, with the two most common reasons being:
An increase in disaster recovery complexity. This was certainly true in an NT4 environment, but it would be fair to say that, since much of Exchange's configuration information is stored in Active Directory (assuming Exchange 200x), this is no longer so much of an issue.
The performance impact of locating these two services on the same machine. Logic dictates that separating these two roles will be best for performance, since the domain controller has plenty of other work to do.
Exchange 2003 running on a domain controller is supported, but you should be aware of the following additional reasons on why this isn't such a good idea:
The old "my Exchange server takes a long time to shut down" issue
When Exchange 2003 is installed on a domain controller, it will take around 10 minutes to shut this server down. The technical reason is because the Active Directory service shuts down before the Exchange services, causing DSAccess to go through several timeouts before terminating. The workaround, as before, is to manually stop the Exchange services before shutting down the server.
Memory management
I've heard it said to not use the /3GB boot.ini switch on the server if Exchange is on a domain controller to prevent Exchange from dominating the memory.
DSAccess will no longer failover
Normally, if Active Directory services are busy or not responding, the Exchange services will failover to use other domain controllers. When Exchange is on a domain controller, this failover will not occur; this is by design.
Security considerations
You can decrease your attack surface area by not installing Exchange on a domain controller. Since all services run under the Local System context, any attacker that gains access to Active Directory will also be able to gain access to Exchange.
More security considerations
Your Exchange administrators will have log on locally rights to the Exchange server. Do you also want them to be logging on locally to your domain controllers?
Installing Exchange on a domain controller is best avoided. However, there are situations when you cannot practically avoid this. I know, as I've been involved in several projects where we've installed Exchange on a domain controller, mainly in the branch-office scenario. Outlook 2003's cached mode will now give us the chance to review this situation on future projects.

1. It is recommended and I second the motion, not to install Exchange 2003 on a DC though it can be done. This is a decision you'll really have to think about (This will get you started - http://www.microsoft.com/technet/prodtechnol/exchange/Analyzer/7423376e-686b-4cda-b90f-cf5cff4f8981.mspx). It's best to run Exchange on it's own server.

If you are running Exchange Server 2003 on a domain controller, using the domain controller promotion tool (DCPromo) to change the computer role is not supported, and it is known to break components such as Microsoft Outlook® Mobile Access (<- an issue listed below).

If you are running Exchange Server on a domain controller without Small Business Server, consider the following issues:
• Exchange Server and Active Directory are both resource-intensive applications. There are performance implications to be considered when both applications are running on the same computer.
• If Exchange Server is running on a domain controller, you must also make that domain controller a global catalog server.
• Several Exchange Server directory components, such as Directory Service Access (DSAccess), Directory Service Proxy (DSProxy), and the Message Categorizer will not fail over to any other domain controller or global catalog server.
• You should not take advantage of the /3GB startup switch in Windows because it could cause Exchange Server to consume all memory, therefore reducing the memory available for Active Directory.
• System shutdown will take considerably longer if the Exchange Server services are not stopped before shutting down or restarting the server.
• This configuration is less secure because Exchange administrators will have local administrative access to Active Directory, enabling them to elevate their own privileges. Additionally, any security vulnerability found in either Exchange Server or Active Directory exposes the other to compromise.


9.    How would you prepare the AD Schema in advance before installing Exchange? 
By running Forest prep.

10. What type or permissions do you need in order to install the first Exchange server in a forest? In a domain?
 Permissions for Installing New Exchange Server 2003 Servers
After ensuring that your organization meets the necessary prerequisites, the procedures referenced in this topic guide you through the deployment process. This process includes installing the first Exchange Server 2003 computer into your organization.
Table 1 lists the required permissions or roles for the procedures referenced in this topic.

Procedure
Required permissions or roles
Enable Microsoft Windows® 2000 Server or Microsoft Windows Server™ 2003 services
·      See Windows 2000 or Windows Server 2003 Help
Run ForestPrep on a domain controller (updates the Active Directory schema)
·      Enterprise Administrator
·      Schema Administrator
·      Domain Administrator
·      Local Machine Administrator
Run DomainPrep
·      Domain Administrator
·      Local Machine Administrator
Install Active Directory Connector (ADC)
·      Enterprise Administrator
·      Schema Administrator
·      Domain Administrator
·      Local Machine Administrator
Install Exchange 2003 on the first server in a domain
·      Exchange Full Administrator role applied at the organization level
·      Exchange 5.5 Administrator under the organization, site, and configuration nodes (if installing into an Exchange 5.5 site)
·      Local Machine Administrator
Install Exchange 2003 on additional servers in the domain
·      Exchange Full Administrator role applied at the administrative group level
·      Exchange 5.5 Site Administrator (if installing into an Exchange 5.5 site)
·      Exchange 5.5 service account password
·      Local Machine Administrator
Run Active Directory Account Cleanup Wizard
·      Enterprise Administrator

11. How would you verify that the schema was in fact updated?

Use adsiedit.msc to verify the changes.

Steps for Extending the Schema

Before you install one of the new features that is described in Active Directory Schema Update or before you add a domain controller running Windows Server 2003 R2 to a forest for the first time (unless it is the first domain controller in a new forest), you must first extend the schema with the Adprep tool. Perform the following steps to extend the schema:
  • Verify Active Directory functionality before you apply the schema extension
  • Apply the schema extension
  • Verify the schema extension

Verify Active Directory functionality before you apply the schema extension

Verify Active Directory functionality before you update the schema to help ensure that the schema extension proceeds without error. At a minimum, ensure that all domain controllers for the forest are online and performing inbound replication.
To verify Active Directory functionality before you apply the schema extension
1.    Log on to an administrative workstation that has the Windows Support Tool Repadmin.exe installed.
noteNote
The Support Tools are located on the operating system installation media in the Support\Tools folder.
2.    Open a command prompt, and then change directories to the folder in which the Windows Support Tools are installed.
3.    At a command prompt, type the following, and then press ENTER:
repadmin /replsum /bysrc /bydest /sort:delta
All domain controllers should show 0 in the Fails column, and the largest deltas (which indicate the number of changes that have been made to the Active Directory database since the last successful replication) should be less than or roughly equal to the replication frequency of the site link that is used by the domain controller for replication. The default replication frequency is 180 minutes.
For more information about additional steps that you can take to verify Active Directory functionality before you apply the schema extension, see article 325379 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=71057).

Apply the schema extension

Use the following procedure to apply the Windows Server 2003 R2 schema extension to the Active Directory schema.
To apply the Windows Server 2003 R2 schema extension to the Active Directory schema
1.    Log on to the computer that holds the schema master operations role (also known as flexible single master operations or FSMO) as a member of the Schema Admins group and the Enterprise Admins group. If you are not sure which computer holds the schema master operations role, type the following at a command prompt, and then press ENTER:
Netdom query FSMO
noteNote
The built-in Administrator account in the forest root domain is a member of the Schema Admins group by default.
2.    Verify that the schema operations master has performed inbound replication of the schema directory partition since the last time that the server restarted. Type the following at a command prompt, and then press ENTER:
repadmin /showrepl
3.    Locate the version of Adprep, either in the \cmpnents\R2 folder of the Windows Server 2003 R2 Disc 2 or from Microsoft hotfix 919151, that is compatible with the version of Windows that runs on your schema master.
Each version of Windows Server 2003 R2 (x86-based or x64-based) ships with a single version of Adprep on Disc 2 that is compatible only with operation masters that run that version of Windows Server 2003 R2 (x86-based or x64-based).
If your schema master is running run an x86-based version of Windows, run the x86-based version of Adprep.
If your schema master is running run an x64-based version of Windows, run the x64-based version of Adprep.
If your schema master does not run a version of Windows that is compatible with the version of Adprep that you plan to run, but your forest contains a domain controller that does run a compatible version of Windows, transfer the schema master role to that domain controller. Continue to step 4, and transfer the role back to the original role holder after the schema update is complete.
If you do not have a compatible domain controller, obtain the hotfix described in article 919151 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=82345).
To determine the version of the Windows operating system that is running on the schema master, type the following at a command prompt, and then press ENTER:
winver
ImportantImportant
Be sure to use the version of Adprep that is on Windows Server 2003 R2 Disc 2 or hotfix 919151, not the version of Adprep that is on Windows Server 2003 R2 Disc 1.
4.    Run adprep /forestprep. Change directories to the location that contains the appropriate Adprep version. Type the following command at the command prompt, and then press ENTER:
cd cmpnents\R2\ADPREP
adprep /forestprep
noteNote
When you change the schema on the schema operations master, the changes are automatically propagated to all other domain controllers in the forest. Therefore, it is not necessary to perform this operation on other domain controllers. Also, there is no need to run adprep /domainprep in any child domain where you have already installed a domain controller running Windows Server 2003 with Service Pack 1 (SP1); the necessary domain partition updates were performed when the domain controller running Windows Server 2003 SP1 was installed.

Verify the schema extension

After you run Adprep, you can use the Windows Support tool ADSI Edit to verify the schema extension.
To verify the schema extension
1.    Log on to an administrative workstation that has ADSI Edit installed.
2.    Click Start, click Run, type adsiedit.msc, and then click OK.
3.    Double-click Configuration Container, and then double-click CN=Configuration,DC=forest_root_domain
where forest_root_domain is the fully qualified domain name (FQDN) of your forest root domain.
4.    Double-click CN=ForestUpdates.
5.    Right-click CN=Windows2003Update, and then click Properties.
6.    Verify that the Revision attribute value is 9, and then close the Properties dialog box.
7.    Double-click Schema.
8.    Right-click CN=Schema,CN=Configuration,DC=forest_root_domain
where forest_root_domain is the FQDN of your forest root domain.
9.    Click Properties.
10. On the Attribute Editor tab, for Select a property to view, select objectVersion, and verify that the attribute Value(s) equals 31.


12.  What are the Exchange management tools? How and where can you install them?

Tools for Exchange Server 2003

Add Root Certificate (English only)
Add a custom root certificate to your Microsoft Windows Mobile
based PocketPC.

Address Rewrite (English only)
May 24, 2004. Rewrite return e-mail addresses on outgoing messages sent from a non-Microsoft mail system to Exchange Server and destined to external or Internet addresses.

ArchiveSink (English only)
Archive message and log recipient details and other information about messages sent to or received by your server that is running Exchange Server.

ASP.NET Mobile Controls Device Updates
Update the supported devices you can use with Microsoft Outlook Mobile Access on your Exchange server.

Authoritative Restore (English only)
Force a restored directory database to replicate to your other servers after restoring from a backup by using this tool.

Auto Accept Agent
Automatically process meeting requests for resource mailboxes. The agent checks the availability of the resource mailbox based on the resource schedule (not free/busy) and accepts or declines new or updated meeting requests.

Badmail Deletion and Archiving (English only)
Delete or archive files automatically in the Badmail directory of specified Simple Mail Transfer Protocol (SMTP) virtual servers.

Calendar Connector for Lotus Notes/Domino
The updated Microsoft Exchange Server 2003 Calendar Connector for Lotus Notes/Domino is used for coexistence and migration of free/busy calendar data between Microsoft Exchange Server 2003 and Lotus Domino.

Collaboration Data Objects, Version 1.2.1
Provides access to data in any MAPI store through a set of strongly typed interfaces that correspond to the common Microsoft Office Outlook items types, including Message, Appointment, and Person.

Connector for Lotus Notes/Domino
The updated Microsoft Exchange Server 2003 Connector for Lotus Notes/Domino is used for coexistence and migration of message flow, calendar requests, and directory synchronization between Microsoft Exchange Server 2003 and Lotus Domino.

Deployment Tools
Find out the steps you should take, the diagnostic tools you should use, and the Setup links to help you successfully install Exchange Server
2003 (requires Exchange Server2003 Service Pack 1 [SP1]).

Disable Certificate Verification (English only)
Disable the Secure Sockets Layer (SSL) certificate check that is performed on a server running Exchange ActiveSync.

Domain Rename Fixup
Repair Exchange Server attributes in Active Directory directory service after using the Microsoft Windows Server
2003 domain rename tool. All Exchange servers in the renamed forest must be running Exchange Server2003 SP1.

E-Mail Journaling Advanced Configuration (English only)
Augment the current Exchange Server archiving features and capture recipients on expanded distribution lists, Bcc recipients, and other message details.

Error Code Lookup (English only)
Determine error values from decimal and hexadecimal error codes in Microsoft Windows operating systems.

Exchange ActiveSync Mobile Web Administration (English only)
Manage the process of remotely erasing lost, stolen, or otherwise compromised mobile devices.

Exchange MAPI Client and Collaboration Data Objects 1.2.1
Starting with the Beta 2 release of Microsoft Exchange Server 2007, neither the Messaging API (MAPI) client libraries nor CDO 1.2.1 are provided as part of the product. The result is missing functionality that many server applications depend on. This tool provides access to these APIs, thereby providing access to the contents of the Exchange store and Active Directory.

Exchange Server 2003 Management Pack Configuration Wizard (English only)
Configure test mailboxes, message tracking, and monitoring services in the Exchange
2000 Server and Exchange Server2003 Management Packs with this graphical user interface.

Exchange Server ActiveSync Certificate-Based Authentication (English only)
Provides several tools to help an Exchange administrator configure and validate client certificate authentication for Exchange Server ActiveSync.

Exchange Server Management Pack for Microsoft Operations Manager 2005
The Exchange Server Management Pack includes rules and scripts to track performance, availability, and reliability of Exchange components, such as Internet-related services, Extensible Storage Engine, System Attendant, Microsoft Exchange Information Store service, and SMTP.

ExchDump (English only)
March 12, 2004. Gather Exchange Server configuration information from various sources used in troubleshooting support issues with this command-line tool.

GroupWise Migration Tools
Get the Connector for Novell GroupWise for Exchange
2000 Server or Exchange Server5.5 Service Pack4, a GroupWise Migration Wizard demo, and more. For the Exchange Server2003 version of these tools, explore the Exchange Server2003 CD.

GUIDGen (English only)
Generate globally unique identifiers (GUIDs) with this tool.

Information Store Viewer (MDBVU32) (English only)
The Information Store Viewer tool has been replaced by the MAPI Editor. The new tool, while still providing the functionality of the older tool for tasks such as browsing storage, is easier to use and is more stable. MAPI Editor is downloadable from this Exchange Server 2003 Tools page.

Inter-Organization Replication (English only)
Replicate public folder and free and busy information between Exchange Server organizations.

Jetstress (English only)
This tool has been revised to work with Exchange 2007 and is backward compatible with Exchange 2003. You will be directed to the new version when you click the tool name.

LegacyDN (English only)
Change Exchange
2000 Server and Exchange Server2003 organization names and administrative group names on critical system objects. You can also use this tool to view or change legacyExchangeDN values.

Load Simulator 2003 (LoadSim) (English only)
Load Simulator 2003 has been replaced with the new Exchange Load Generator for Exchange Server 2007. Exchange Load Generator works with Exchange Server 2003 as well.

Lotus Applications Migration Tools
Get Office Outlook Connector for Lotus Domino, Importer for Lotus cc:Mail archives, Microsoft Application Analyzer 2006 for Lotus Domino, and more.

Mailbox Merge Wizard (ExMerge) (English only)
Extract data from mailboxes on one Exchange server and then merge that data into mailboxes on another Exchange server.

MAPI Editor (English only)
This tool, which replaces the current Information Store Viewer (MDBVU32), provides access to the contents of Messaging API (MAPI) stores. This is done through a graphical user interface.

Microsoft Baseline Security Analyzer
Scan for missing security updates for Exchange Server
5.5 and later. Visit the Microsoft TechNet site to find out the details.

Microsoft Exchange Best Practices Analyzer, Version2.8
Better integration with Microsoft Operations Manager 2005 enables you to identify and help resolve configuration issues before problems arise.

Microsoft Exchange Intelligent Message Filter
Find out how you can improve productivity and trim costs while lessening spam by exploring the resources listed on this page.

Microsoft Exchange Intelligent Message Filter Update with Microsoft Update
Starting with Exchange Server 2003 SP2, you can update your Intelligent Message Filter spam definitions using Microsoft Update.

Microsoft Exchange Troubleshooting Assistant, Version 1.1 (English only)
Access the following functionality by using the Exchange Troubleshooting Assistant: Exchange Performance Troubleshooter, Exchange Database Recovery Management, and Exchange Mail Flow Troubleshooter.

Microsoft Search Administrative Tool (MSSearch)
Use this command-line tool to perform administrative tasks against a full-text index such as enabling and disabling a full-text index for searching, obtaining the current status of a full-text index, and stopping the current population on a full-text index.

Migration Wizard for Lotus Notes/Domino
The Microsoft Exchange Server 2003 Migration Wizard for Lotus Notes/Domino is used for migrating Lotus Domino Accounts and mailboxes to Exchange Server 2003 and Active Directory.

MTA Check (English only)
Look for message transfer agent (MTA) database consistency and perform repairs.

Outlook Web Access Web Administration
Administer Microsoft Outlook Web Access with this Web-based tool.

Profile Analyzer (English only)
This tool has been revised to work with Exchange 2007 and is backward compatible with Exchange 2003. You will be directed to the new version when you click the tool name.

Profile Redirector or Exchange Profile Update
Exchange Redirector (ExProfRe.exe), also known as the Exchange Profile Update tool, updates Microsoft Office Outlook profiles after moving mailboxes across Exchange Server organizations or administrative groups.

Public Folder DAV-based Administration (English only)
Use the Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool (PFDAVAdmin) to perform various management tasks related to public folders and mailboxes. Note that this tool now works with Exchange Server 2007.

Quota Message Service (English only)
Generate custom quota messages that inform users that they have exceeded their message quotas. This tool is a mailbox agent, and it uses template messages to format the body of the quota messages.

SMTP Internet Protocol Restriction and Accept/Deny List Configuration (English only)
Programmatically set Internet Protocol (IP) restrictions on an SMTP virtual server.

SMTPDiag
Determine whether SMTP and DNS are configured to reliably deliver mail to an external e-mail address.

Software Development Kit (SDK) Development Tools
Get tools and components for creating and debugging collaborative applications on Exchange Server.

Stress and Performance2003 (English only)
This tool has been revised to work with Exchange 2007 and is backward compatible with Exchange 2003. You will be directed to the new version when you click the tool name.

Up-to-Date Notifications Binding Cleanup (English only)
View and remove existing up-to-date notifications event registration items (bindings) on an individual as well as on a bulk level.

Up-to-Date Notifications Troubleshooting (English only)
Solve common notification issues and test e-mail message delivery to specified mobile devices with this troubleshooting tool.

User Monitor (English only)
Enables system administrators to view and evaluate individual user's usage and experience with Exchange Server.

WinRoute
Get a visual representation of the Exchange Server routing topology and the status of the different routing components.

Workflow Designer for Exchange Server
The Workflow Designer for Exchange Server is no longer available to download. Click the tool name to go to the download page where you can download documentation that fully explains why the tool has been removed, and what you can use instead of this tool.

13. How can you grant access for an administrator to access all mailboxes on a specific server?
How do I grant the administrator(s) (or any other user) full mailbox right on Exchange 2000/2003 mailboxes?
In Microsoft Exchange Server 5.5, when you grant Service Account Admin privileges on the Site container to a Microsoft Windows account, you grant that account unrestricted access to all mailboxes. Because Exchange 2000 and Exchange Server 2003 do not use a service account, even accounts with Enterprise Administrators rights are denied rights to access all mailboxes, by default.
This means that Exchange Full Administrators do not have the right to open any mailbox found on any server within the Exchange organization.
In fact, if your logon account is the Administrator account or is a member of the Domain Admins or Enterprise Admins groups, then you are explicitly denied access to all mailboxes other than your own, even if you otherwise have full administrative rights over the Exchange system.
However, unlike Exchange Server 5.5, all Exchange 2000/2003 administrative tasks can be performed without having to grant an administrator sufficient rights to read other people's mail.
This default restriction can be overridden in several ways, but doing so should be in accordance with your organization's security and privacy policies. In most cases, using these methods is appropriate only in a recovery server environment.

Granting right to a specific mailbox

Use the following procedure to grant access to Exchange 2000 or an Exchange 2003 mailbox:
Note: You must have the appropriate Exchange administrative permissions to do so.
  1. Start Active Directory Users and Computers.
  2. On the View menu, ensure that the Advanced Features check box is selected.
Note: This is not necessary on Exchange Server 2003 because of the fact that the Exchange Advanced tab is exposed by default.
  1. Right-click the user whose mailbox you want to give permissions to and choose Properties.




      4.On the Exchange Advanced tab, click Mailbox Rights.


  1. Notice that the Domain Admins and Enterprise Admins have both been given Deny access to Full Mailbox access.
  2. Click Add, click the user or group who you want to have access to this mailbox, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Mailbox Access, and then click OK. 
9.Click Ok all the way out.

Warning: If the Group or User name list is empty and you only see one line with the name of SELF - do NOT touch the permission settings before you read SELF Permission on Exchange Mailboxes.
 = Bad!


 = Good
Note: If the purpose of granting such access is to permit use of the EXMERGE utility (see Delete Messages from Mailboxes by using EXMERGE for an example of such a requirement), grant Receive As permissions. You can also grant Full Control permissions if you want complete access.

Granting right to a mailboxes located within a specific mailbox store

Use the following procedure to grant access to Exchange 2000 or an Exchange 2003 mailboxes found on a specific mailbox store:
Note: You must have the appropriate Exchange administrative permissions to do so.
  1. Start Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Expand the server object and find the required mailbox store within the appropriate Storage Group. Right-click it and choose Properties. 
  1. In the Properties window go to the Security tab.
  2. Click Add, click the user or group who you want to have access to the mailboxes, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Control, and then click OK.
Note: Make sure there is no Deny checkbox selected next to the Send As and Receive As permissions.



  1. Click Ok all the way out.

Granting right to a mailboxes located on a specific server

Use the following procedure to grant access to Exchange 2000 or an Exchange 2003 mailboxes found on a specific server:
Note: You must have the appropriate Exchange administrative permissions to do so.
  1. Start Exchange System Manager.
  2. Drill down to your server object within the appropriate Administrative Group. Right-click it and choose Properties. 

  1. In the Properties window go to the Security tab.
  2. Click Add, click the user or group who you want to have access to the mailboxes, and then click OK.
  3. Be sure that the user or group is selected in the Name box.
  4. In the Permissions list, click Allow next to Full Control, and then click OK.
Note: Make sure there is no Deny checkbox selected next to the Send As and Receive As permissions.



  1. Click Ok all the way out.
Note: It might take some time before the changes you've made will take effect. The amount of time needed is influenced by the number of domain controllers, Global Catalogs and site replication schedules and intervals. On one domain with one site containing multiple domain controllers it might take up to 15 minutes before you can begin using these new permissions. On single servers that are also DCs you can speed up the process by restarting the Information Store service.

59. What is the Send As permission? How to grant Send As permission?

"Send As" allows one user to send an email as though it came from another user. The recipient will not be given any indication that the email was composed by someone other than the stated sender.
"Send As" can only be granted by a system administrator. "Send on Behalf of" may be more appropriate in many situations, it allows the recipient to be notified both who the author was and on whose behalf the email was sent

The following procedure will allow system managers to grant users the ability to send as another:
1.       Log onto the server running Exchange.
2.       Run Active Directory Users and Computers.
3.       Under the "View" menu ensure that "Advanced Features" is ticked.
4.       Find the user's account that you want to be able to send as, and open up the account properties.
5.       Select the "Security" tab.
6.       Click [Add ...] (under "Group or user names") and add the user (users or group) that is to be granted permission to send-as this account.
7.       For each account added, highlight the account under "Group or user names" and in the "Permissions for ..." window grant the account "Send As" permission.
8.       Click [OK] to close the account properties dialog.
Note:
       If there is an account for which a number of people need to be able to send as (such as an account used as a single point of contact for a distribution lists) then administratively it may be simpler to add a group of users who should have that permission and grant the permission to the group and not to the accounts individually.
       The process of sending an email as coming from another account is the same as sending on behalf-of.


Set Mailbox Send as Permission
To set up a mailbox so another person can send mail on behalf of that person (send as) follow the procedure below. This procedure works when using Exchange 2000 for the mail server. For example if you have a person who is an executive with an office assistant, they may want the office assistant to be able to send mail on their behalf. In the procedure below, the first user whose properties are vied would be the executive, and the user granted the permission is the office assistant.
Open Active Directory Users and Computers.
On the Menu, select "View".
Either double click the user who you want someone else to send e-mail on behalf of or right click the user and select "Properties"
A user properties dialog box will appear. Select the "Exchange General" tab. 


Click the "Delivery Options" button.
A "Delivery Options" dialog box will appear. To the right side of the box labeled "Grant this permission to", click the "Add" button. 


A select recipient dialog box will appear. Select the recipients that you want to be able to send mail on behalf of the user whose properties you are editing.
Click OK to close the select recipient dialog box.
Click OK to close the "Delivery Options" dialog box.
Click OK to close the user properties dialog box.

14. What are Exchange Recipient types? Name 5.
Exchange Server 2003 allows you to create several different types of recipient objects:
Mailbox-enabled users, mail-enabled users, contact recipients, group recipients and public folder recipients.

Part 1: Exchange Server mailbox-enabled and mail-enabled recipients

There is a world of difference between an Exchange Server mailbox-enabled recipient object and a mail-enabled recipient object. An Exchange Server mailbox-enabled recipient object is a user who actually has a user account on your system. On the other hand, a mail-enabled recipient object is a user who does not have a valid user account, but who does have an email address that reflects your organization's domain.

You would typically create a mail-enabled Exchange Server recipient object for someone who doesn't actually work for your company, but who needs to maintain the appearance of working there.

By using a mail-enabled recipient object, you would be able to publish an external user's email address as externaluser@yourcompany.com. Any email messages sent to that address would pass through your Exchange server and be forwarded to that person's normal email account in his own domain.

The process for creating an Exchange Server mail-enabled user is fairly similar to the procedure for creating a mailbox-enabled user. Both processes start with creating a user account. Exchange Server extends the user creation wizard and gives you a chance to create an Exchange Server mailbox for the user, as shown in Figure A.

If you wanted to create a mailbox-enabled user, you would create an Exchange Server mailbox for the new user and then complete the account creation process in the normal way.

Figure A: Set up an Exchange mailbox to create a mailbox-enabled user object. 



If you are creating a mail-enabled recipient though, you would deselect the "Create an Exchange Mailbox" checkbox shown in Figure A prior to completing the account creation process.

Since a mail-enabled recipient is someone who has no business logging onto your network, you also need to disable that user account right away. To disable an Exchange Server mail-enabled recipient, right click on the user account in the Active Directory Users and Computers (ADUC) console and select the "Disable Account" command.

Now it's time to mail-enable the user account:


Right click on the account and select the Exchange Tasks command to launch the Exchange Tasks Wizard.

Click Next to bypass the wizard's Welcome screen and you will see a list of the tasks that can be applied to the user object.

Select the "Establish Email Address" option from the list and click Next to see the screen shown in Figure B.
Figure B: You must enter the user's external email address.



As you can see in Figure B, the user's alias is filled in automatically. However, you must enter the user's external email address. This is the user's real email address where he normally receives his email.


Click the modify button and you will be prompted to select the type of address that you want to enter.

Select the SMTP Address option and click OK.

Enter the user's external email address and click OK once again. The "External Email Address" field on the screen shown in Figure B will now be filled in.

Click Next, followed by Finish, to complete the process.
You will be able to tell that the process was successful because the newly mail-enabled user will now appear in the Exchange Server Global Address List (GAL).

Part 2: Exchange Server contact recipients
An Exchange Server contact recipient object is very similar to a mail-enabled recipient object in that it points to an external email address. Contact recipient objects and mail-enabled recipient objects have totally different purposes though.
An Exchange Server contact recipient object also points to an external email address, but its purpose is not to provide an email address from your domain to an external recipient. Instead, its goal is to make it easier for your users to send messages to that external person.
For example, let's say that your company outsources printing to a local print shop, and your employees regularly email documents there. If you create a contact recipient object for the print shop, its email address will be added to your Exchange Server Global Address List (GAL). This will save your users the time and effort of having to manually type in the print shop's email address every time they want to send email.
When you create a contact recipient, you do not have to create a user account. However, you do have to create an Active Directory object to link to the external email address.
To create an Exchange Server contact recipient:
Open the Active Directory Users and Computers (ADUC) console.
Right click on the Users folder and select New -> Contact to view the New Object -- Contact dialog box.
Enter a first name, last name, full name, and display name and click Next.
This screen asks if you want to create an Exchange Server email address. Make sure that the "Create an Exchange Email Address" checkbox is selected and click the Modify button.
You will now be asked what type of address you want to enter. Select the SMTP address option and click OK.
Enter the recipients email address and click OK one more time.
Click Next, followed by Finish, to create the new contact recipient object.
The newly created contact will reside in the Users folder (or whatever folder you created it in) of the ADUC console. You can tell it apart from a normal user because the contact's icon looks like a business card rather than a person.
Now that you have created the new contact, it should appear on the Exchange Server Global Address List. When you view the GAL through Microsoft Outlook, you will be able to tell that the entry uses an external mailbox, because Microsoft Outlook will display a globe icon next to the contact.

Part 3: Exchange Server group recipients
For all practical purposes, a group recipient object is the same as an Exchange Server distribution list. It is basically just a group that has been mail-enabled (not mailbox-enabled). When an email message is sent to the group's email address, the message is forwarded to the group members' individual mailboxes.
To create an Exchange Server group recipient object:
Open the Active Directory Users and Computers (ADUC) console and select the Users container.
Right click on the Users container and select New -> Group To view the New Object -- Group dialog box.
Enter a name for the group and then set the group type to Distribution.
Click Next to see a screen asking you if you want to create an Exchange Server address for the group.
Make sure that the "Create an Exchange Email Address" checkbox is selected and click Next.
Click Next one more time, followed by Finish, to create the Exchange Server group recipient object.
To add users to the group, click on the group, select Properties, and click the Add button on the Members tab.

Part 4: Exchange Server public folder recipients
The last type of Exchange Server recipient object that I want to talk about is a public folder recipient -- also known as a mail-enabled public folder. A public folder recipient is simply an Exchange Server public folder that has an email address associated with it.
There are many different uses for mail-enabled Exchange public folders, but the first example that comes to mind is a situation in which your company launches a new product and wants to receive feedback from customers. With a a mail-enabled Exchange public folder, you could receive all customer feedback in a central location, instead of flooding multiple personal mailboxes with those messages.
To create an Exchange Server public folder recipient object:
Open Exchange System Manager.
Navigate through the console tree to Administrative Groups -> your administrative group -> Folders -> Public Folders -> the public folder you want to mail enable.
Right click on the Exchange Server public folder you want to mail enable and select the All Tasks -> Mail Enable command.
The folder is technically now mail-enabled, but you still need to verify that an email address has been assigned to the Exchange public folder.
To do so, right click on the folder and select Properties.
Select the Email Addresses tab to view the SMTP address assigned to the Exchange public folder.
Use the Add and Edit buttons to add an alternate address or to modify the existing address, if necessary.

What Happens when I create a Mailbox in Exchange 2003?


I have been asked this question a fair bit recently by members of my team, or indeed staff whom have delegated rights to the ESM whom worry when the don’t see the new mailbox that they have created appear in the Exchange System Manager.
The most recent related question that I have been asked is “why is the only permission on the mailbox the self permission”, which prompted me to have a look around the web for some information, whereas I understand why the mailbox does not appear in the ESM and why the self permission is the sole permission upon creation I was hoping to find some resources on the web to distribute to my team.
I was very surprised to find that although I tracked down a very good explanation for the “self” permission, I could not find anything that really explains what happens when you go through the mailbox creation process, therefore I have decided to write my own explanation (and await the flogging from people that know better!)
Ok, a common misconception about creating a Mailbox is that when you have completed the Mailbox creation Wizard there is a nice shiny mailbox created in the store that you have chosen.
This is not the case, the Mailbox wizard at this stage only updates the following attributes in Active Directory with the values that are specific to you Exchange Organisation;

  • homeMDB - Home Location of your Mailbox in the correct Exchange Database
  • homeMTA - Your Native Message Transport Agent
  • legacyExchangeDN - Used for compatibility with Exchange 5.5 systems
  • mail - Your primary e-mail address
  • mailNickname - Your mailbox alias
  • msExchHomeServerName - The server which your mailbox is located on
  • msExchMailboxGuid - GUID of the Primary samAccount for the mailbox
  • msExchMailboxSecurityDescriptor - Defines mailbox rights
  • proxyAddresses - Additional Addresses.

What then happens is the Recipient Update Service will run (usually every 15 minutes) and stamp the mail and proxy addresses to the account in Active Directory - at this stage there is still no physical mailbox in the Exchange store (which can be verified by check the mailbox list from the ESM).
In addition to the above if you check the “Exchange Advanced” tab and click ”Mailbox Rights” (you will need to turn on the Advanced Features of ADUC) you will see that the only permission on the mailbox at this point is the “self” permission. 
This situation happens because the securityDescriptor object (msExchMailboxSecurityDescriptor) is not read from Active Directory until the user first logs on to the mailbox or the mailbox is sent an item of mail.
A common misconception is that the Recipient Update Service plays a part in both the mailbox creation and indeed the configuration of security permissions on the mailbox, however the RUS does not work out any permissions (as that is not its job) it is the store service that works these out when the user logs on or mail is received which co-incidentally is the point where the store process creates the mailbox in the database based upon the data that is contained in Active Directory for the account. 
15. What are Query Based Distribution groups?

A query-based distribution group works much like a standard distribution group. The difference being that the query-based Distribution Groups assign group membership based on LDAP queries. Query-based distribution groups are only supported when running in Exchange Server 2003 Native Mode. The main advantage of creating a query-based distribution group is that administrators can dynamically assign members to the group – you do not have to manually add/remove accounts from the query-based distribution group.
You can use the Filter option to define group membership for the query-based distribution group. Then, when new account objects are created, these objects too are added to the group when they defined as being mail-enabled in Active Directory.
The different Filter options for defining a query-based distribution group are listed here:
Users with Exchange Mailboxes
Users with External Mail Addresses
Mail-Enabled Groups
Contacts with External Email Addresses
Mail-Enabled Public Folders
Customer Filters

How to create a query-based distribution group

Open the Active Directory Users and Computers console.
Click the View menu and enable the Advanced Features option.
Navigate to and expand the Organizational Unit that should contain the query-based distribution group.
Click the Action menu and select New and then Query-Based Distribution Group.
Provide a name for the query-based distribution group
Click Change, and then select the domain and organizational unit. The filter will be applied to all users in the organizational unit.
Select the Users with Exchange Mailbox option.
Click Next and then click Finish.

16. What type of groups would you use when configuring distribution groups in a multiple domain forest?
17. Name a few configuration options for Exchange recipients.
18. Name a few configuration options related to mailbox stores.
19. What are System Public Folders? Where would you find them?
Types of public folders
There are two types of public folders in Exchange 2003:
Public Folder
System Folder
Puchange distinguishs between different public folder trees:
ONE public folder tree type called “MAPI Clients” and
MANY public folder tree types called “General purpose”
Every public folder tree must be associated with an Exchange 2003 Public Folder Store.
Public folders under the MAPI public folder tree are visible in Outlook.
Public folders under the General purpose public folder tree are visible in Explorer and various other clients, except Outlook, like HTTP clients.
System Folder
System folders are hidden folders for internal Exchange System Management. Exchange needs this System Folders for Offline Address Book generation, Free+Busy information and many more.
Exchange generates the following System Folders:
EForms Registry
Events Root
Nntp Control Folder
Offline Address Book
Schedule+ Free Busy
StoreEvents
System Configuration
To view System Folders start Exchange System Manager, navigate to Public Folders and right click “View System Folders”.


Figure 2: Display System folders in ESMblic folders
Public folders are the visible public folders for your users to organize and publish informations. You can create as much public folders you want.

20. How would you plan and configure Public Folder redundancy?
Go to the individual mailbox stores (not the storage group) on Server A. Open the properties page and set the Default Public folder store to Server B.

21. How can you immediately stop PF replication?
22. How can you prevent PF referral across slow WAN links?
23. What types of PF management tools might you use?
 New Tools Available for Public Folders and Mailbox Management, and for Mobility
With the release of Microsoft® Exchange Server 2003 Service Pack 2 (SP2), you now have two new tools that can make your day-to-day operations tasks easier and more productive.
1.The Microsoft Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool, version 2.4, is a tool previously available for internal use only, but now is available publicly. This tool helps IT Administrators to manage various server tasks related to:
Public folders
Mailboxes
2.The Microsoft Exchange ActiveSync Mobile Administration Web tool is part of the overall new Mobility feature that was introduced with SP2. This tool enables IT Administrators to manage the process of remotely erasing or wiping lost, stolen, or otherwise compromised mobile devices.
For more information about downloading these tools, see Tools for Exchange Server 2003. Download these tools to start taking advantage of the many tasks they can perform both for public folder and mailbox administration, and for an enhanced administrator mobility experience.
The following sections describe the tools in more detail.
 Microsoft Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration Tool
The Microsoft® Exchange Server Public Folder Distributed Authoring and Versioning (DAV)-based Administration tool version 2.4 (PFDAVAdmin 2.4) is an Exchange 2000 and later tool that assists Exchange administrators in fulfilling various server management tasks. As the name of the tool implies, many of these tasks are related to public folder management, but this tool can be used with mailboxes, too.
What PFDAVAdmin Can Do
Probably the most popular usage of PFDAVAdmin is permissions management of public folders. This tool is especially useful when correcting problems in permissions caused by M drive scanning or modifications made through a non-MAPI interface. Another common usage is to export or import folder permissions set on public folders and mailboxes.
The following examples show additional you can do with PFDAVAdmin.
Content Report
Did you ever want to know how many items each public folder contains? Or do you want to know when the newest item was created in a folder? The Content Report menu is here to help you. Use this menu to create a report for all the public folders or any single folder (and its subfolders) with information such as the following:
Item count
Size of the folder
Largest item size in the folder
Most recent modification date of any item in the folder
Centralized Permission change
Did you ever want to assign certain permission to all the user mailboxes, such as reviewer permission on Calendar folders of all the users? You can use Propagate ACE to add the permission to all the folders named Calendar, or you can export or import permissions through text files.
Aa996025Note:
For Calendar folders, you must take an extra action. For more information, see Microsoft Knowledge Base article 237924, "PRB: ACL: Outlook 2000 Doesn't Properly Read ACL Settings."
Permission Migrate
Do you need to migrate from an Exchange Server 5.5 organization to a new Exchange Server 2003 organization? If you do, you may also want to migrate the permissions of public folders rather than manually assigning the permissions on Exchange Server 2003. You can use PFInfo to export the permissions of Exchange Server 5.5 public folders and use PFDAVAdmin to import the file into Exchange Server 2003.
Frequently Asked Questions
The following questions are frequently asked.
Question   Does PFDAVAdmin only work against public folders?
Answer
   No, in spite of its name, PFDAVAdmin works against mailboxes as well.
Question   Can you run PFDAVAdmin against Exchange Server 5.5?
Answer   No, PFDAVAdmin works only with Exchange 2000 and later servers. However, PFDAVAdmin can work with the data you exported from Exchange Server 5.5 with tools such as PFInfo.
Question   Is it possible to run PFDAVAdmin from a command line?
Answer   Yes. You can specify various switches to indicate what type of operations you want to perform, as well as the scope of the operations. To see what options are available, type pfdavadmin -? at a command prompt.
Question   Can you run PFDAVAdmin from a computer that is not a member of the forest where the target Exchange server resides?
Answer
   Yes. This feature is new with version 2.4. Also, you can use an account that is not a member of the Exchange forest if it has appropriate Exchange Administrator permissions (for example, in a resource forest scenario).
Question   What is the typical 'folders per hour' that PFDAVAdmin can process?
Answer
   This answer depends on many factors such as the hardware specifications of the server and client, and the types of operations (Export Permissions, Export Replica Lists, Content Report). generally, you can get a higher performance when you run PFDAVAdmin against Exchange Server 2003 than against Exchange 2000 Server. Also, for Exchange Server 2003, it is faster when installed on Microsoft Windows Server™ 2003. As a broad estimate, 20,000 to 50,000 folders per hour is a good benchmark. Do note, though, that the performance in version 2.4 is significantly improved over the previous versions.

minus Microsoft Exchange ActiveSync Mobile Administration Web Tool
The Microsoft Exchange ActiveSync Mobile Administration Web tool enables administrators to manage the process of remotely erasing lost, stolen, or otherwise compromised mobile devices.
By using the Exchange ActiveSync Mobile Administration Web tool, administrators can perform the following actions:
View a list of all devices that are being used by any enterprise user.
Select or cancel the selection of devices to be remotely erased.
View the status of pending remote erase requests for each device.
View a transaction log that indicates which administrators have issued remote erase commands, in addition to the devices that those commands pertained to.
Installation
To install the Exchange ActiveSync Mobile Administration Web tool on a front-end server that runs Exchange Server 2003 with Service Pack 2 (SP2), run the .msi package. The installation package creates the MobileAdmin virtual directory, through which the tool can be accessed.
When installed correctly, the Exchange ActiveSync Mobile Administration Web tool is available from any remote computer that has a browser that can access the virtual directory associated with the tool. However, to access the Exchange ActiveSync Mobile Administration Web tool from the same computer that it is installed on, you must use one of the following approaches:
Add the server name to the Local intranet list for Internet Explorer: In Internet Explorer, click Tools, click Internet Options, click Security, click Local intranet, and then click Sites.
Use localhost as the server name when specifying the mobileAdmin URL in the browser (for example, https://localhost/mobileAdmin).
Adding Administrators
By default, access to the Exchange ActiveSync Mobile Administration Web tool is restricted to Exchange administrators and local administrators. A user from either of these groups can enable additional users to access the tool by modifying the security settings on the MobileAdmin folder in the installation directory. You make this change by right-clicking the folder, and then selecting sharing & security, which displays the Insert Folder Security properties dialog box.
By using this user interface, an administrator can add a user or group by clicking Add and then entering the name of the user or group to which the administrator wants to grant access.
Similarly, a user or group can be removed by selecting that user or group and then clicking Remove.
Using the Tool
The Welcome Screen presents the Administrator with a list of available administrative options. Select one of these options to start the associated Web page. The following options are displayed on the Welcome page.
Remote Wipe   Run a remote wipe command for a lost or stolen mobile device
Transaction Log   View a log of administrative actions, noting time/action/user
Running and Monitoring a Remote Device Wipe
The Remote Device Wipe administrator console provides the following functions:
Issue a remote wipe command for a lost or stolen mobile device.
To issue a remote wipe command, search for a user’s mobile devices by specifying the user’s name. The tool displays the device ID, device type, and the time the device last synchronized with the server for each of the user's devices. Locate the desired device, and then click Wipe. The tool then displays the up-to-date status for the device, displaying when or if the device has been successfully wiped.
View the status on a pending remote wipe command.
When a Wipe action is specified for a device, it stays active until the administrator specifies otherwise. This means that, after the initial remote wipe has been completed, the server continues to send a remote wipe directive if the same device ever tries to reconnect.
Undo (cancel) a remote wipe command if a lost or stolen device is recovered.
If a lost device is recovered, the administrator can cancel this directive to enable the device to successfully connect again. You cancel the wipe by locating the mobile device that has the remote wipe action set, and then clicking Cancel Wipe.
Delete a device partnership.
The administrator can use the remote wipe console to delete a device partnership from the server. This action has the effect of cleaning up all state associated with a specified device on the server and is primarily useful for housekeeping purposes. If a device tries to connect after its partnership has been deleted, it will be forced to re-establish that partnership with the server through a recovery process that is transparent to both the IT administrator and the device user. This action is carried out by locating the mobile device, and then clicking Delete.
Viewing a Log of Remote Wipe Transactions
The transaction log displays the following information for all critical administrative actions performed with the Exchange ActiveSync Mobile Administration Web tool:
Date Time   Date and time when the action was executed
User   The user who executed the action
Mailbox   The mailbox that the action pertained to
Device ID   The device that the action pertained to
Type   The type of device that the action pertained to
Action   The action taken by the administrator

1.    What are the differences between administrative permissions and client permissions in PF?
          Using Public Folder Permissions
The following sections discuss how to use public folder permissions.
Understanding the Three Types of Public Folder Permissions
You can control access to public folders using the following types of permissions:

Client permissions   These settings control who can use client applications to access folders and messages. By default, all users have permissions to read and write content in the public folder. You can change permissions for all users or create different permissions for specific users. The default client permissions do not include the Exchange administrative roles (Exchange Full Administrators, Exchange Administrators, or Exchange View Only Administrators).
Depending on the type of public folder that you are working with, you may see different forms of the client permissions.
Folders in the Public Folders tree use MAPI permissions.
Folders in general-purpose public folder trees use Windows 2000 Server permissions.

Directory rights   These settings are normal Active Directory permissions, and control who can change the e-mail–related attributes of a mail-enabled public folder. Exchange stores these attributes in Active Directory, in the public folder's directory object in the Microsoft Exchange System Objects container. The default directory permissions include extensive permissions for the domain local Administrators group. Normally, any user that you have assigned to one of the Exchange administrative roles is a member of this group.

Administrative rights   These settings control who can use Exchange System Manager (or a custom administration program) to change the replication, limits, and other settings for a public folder. Some of these permissions are inherited from the public folder store and include permissions for the Exchange administrative roles. These permissions are Windows 2000 Server permissions, although they reside only in the public folder store.
If you are working with a public folder tree that has multiple levels of public folders, you can modify client permissions or administrative rights for a single folder, and you can use the Propagate Settings command to propagate the changes to all subfolders of that folder. To propagate client permissions, use Propagate Settings with the Folder rights option. To propagate administrative rights, use Propagate Settings with the Administrative rights option.
Special Considerations for Working with Client Permissions
When you use Exchange System Manager to view client permissions for a public folder, the information that you see can depend on what type of folder tree you are working with. You also have access to different views of the same information. The procedures in this section provide information about how to use and how not to use the different views.
To view permissions that control client access to a public folder
In Exchange System Manager, right-click the folder that you want to change, and then click Properties.
In the Properties dialog box, click the Permissions tab, and then click Client permissions.



After you click Client permissions, one of two different dialog boxes appears, depending on the type of public folder tree with which you are working.
If you are working with a folder in the Public Folders tree, you see a dialog box that contains MAPI permissions and roles.



      
If you are working with a folder in a general-purpose
 public folder tree, you see a dialog box that contains
Windows 2000 Server permissions, users, and groups.

You can also use Exchange System Manager to view the Windows 2000 version of the permissions on a folder in the Public Folders tree.
Aa996122Caution:
Although you can view the Windows 2000 Server version of the Public Folders tree permissions, do not attempt to edit the permissions in this view. The Windows user interface that displays the permissions formats the ACL in such a way that Exchange Server will no longer be able to convert the permissions to their MAPI form. If this happens, you will no longer be able to use Outlook or the regular Exchange System Manager dialog boxes to edit the permissions.
To view the Windows 2000 version of MAPI permissions
In Exchange System Manager, right-click the folder whose permissions you want to view, and then click Properties.
From the Properties dialog box, click the Permissions tab, and then press and hold the CTRL key and click Client permissions.
The resultant dialog displays as below. Note that all of the permissions check boxes are cleared:



To see the actual permissions information, click Advanced. The resulting dialog box is shown below:


To view detailed permissions information, click a permissions entry and then click View/Edit.
Remember, do not use this dialog box to edit the permissions. As stated earlier, using this interface to modify permissions would save the changes in a form that Exchange Server could not convert to the MAPI format. The following screenshot shows an example of the detailed Windows 2000 Server permissions information you can view.


Designating a User as a Public Folder Delegate
You can configure a mail-enabled public folder so that a user can send mail on the public folder's behalf. For example, if the folder serves as a shared storage location or workspace for a group of users, one user could send notifications to the group. A custom application could also perform such a function, if you created an account for it to use.
To give a user the ability to send mail on behalf of a public folder
From Exchange System Manager, expand Folders, right-click the public folder for which you want to give a user the ability to send mail and click Properties.
Click Exchange General, and then click Delivery Options.
Click Add to specify a user.
You may need to make additional modifications if the following conditions apply:
The user's mailbox resides in a domain that is different from the public folder's domain.
The user's mailbox resides on a server that is located in a site that does not contain any domain controllers for the domain that hosts the public folder.
Use one of the following additional steps:
Add the Exchange Domain Servers security group of the child domain with Read permissions to the ACL of the Microsoft Exchange System Objects container in the parent domain. This method is the recommended method for working around this problem.
Move one domain controller from the parent domain to the user's Exchange Server 2003 site.
Maintaining the Minimum Permissions Required for Mail-Enabled Public Folders
This section explains the minimum permissions that are required for mailbox stores and public folder stores to function correctly.
If you modify the default client permissions and roles on a mail-enabled public folder, make sure you maintain the Contributor role for the Anonymous account. Otherwise, mail sent to the public folder will be returned as undeliverable. When the public folder receives e-mail from a user who has no permissions on the folder, it treats the mail as a message posted using the Anonymous account.

Aa996122Note:
This is a change from Exchange Server 5.5, where the default role of the Anonymous account was None.
minus Maintaining the Minimum Permissions Required for Mailbox Stores and Public Folder Stores
If you modify the default permissions on Exchange Server 2003 mailbox stores and public folder stores, make sure you maintain the following minimum permissions:
Administrators group   Full Control
Authenticated Users group   Read and Execute, List Folder Contents, and Read
Creator Owner   None
Server Operators group   Modify, Read and Execute, List Folder Contents, Read, and Write
System account   Full Control
You may experience difficulties in mounting the mailbox stores or public folder stores if you do not maintain these permissions for these groups and accounts. The following error messages and events indicate that the accounts and groups in the preceding list do not have the correct permissions:
An internal processing error has occurred. Try restarting Exchange System Manager or the Microsoft Exchange Information Store service, or both.
MAPI or an unspecified service provider. ID no: 00000476-0000-00000000.
Information Store (2520) An attempt to determine the minimum I/O block size for the volume "[drive:\]" containing "[drive:\]Exchsrvr\Mdbdata\" failed with system error 5 (0x00000005): "Access is denied." The operation will fail with error -1032 (0xfffffbf8).
Error 0xfffffbf8 starting Storage Group [dn of storage group] on the Microsoft Exchange Information Store.
The MAPI call 'OpenMsgStore' failed with the following error: The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance. The MAPI provider failed. Microsoft Exchange Server Information Store ID no: 8004011d-0526-00000000.
You may also encounter problems when mounting public folder stores if you have cleared the Allow inheritable permissions from parent to propagate to this object option for the public folder hierarchy. The following error messages indicate that you have cleared this option:
The store could not be mounted because the Active Directory information was not replicated yet.
The Microsoft Exchange Information Store service could not find the specified object. ID no: c1041722.
To restore the permissions required by Exchange Server:
In Exchange System Manager, right-click the Folder container, select the public folder tree, and then click Properties.
In the Properties dialog box, click the Security tab, click Advanced, and then select Allow inheritable permissions from parent to propagate to this object.
Wait for Active Directory to replicate the change to all of the domain controllers.
Right-click the public folder store and click Mount Store.

2.    How can you configure PF replication from the command prompt in Exchange 2003?
Replicating Public Folders from Exchange 2000 to Exchange Server 2003
Just as the mailboxes are migrated from one set of Exchange 2000 servers to another set of Exchange Server 2003 systems, the public folders should be replicated before retiring the old Exchange 2000 servers. Previously, this procedure involved a manual replication of folder hierarchy, which could prove to be a tedious process. Microsoft addressed this drawback with a new utility called PFMigrate, which is accessible via the Exchange Deployment Tools. PFMigrate can create public and system folder replicas on new systems, and remove them from old servers. The following procedure outlines how to use PFMigrate to migrate from an Exchange 2000 Server to an Exchange Server 2003 system:

Open a Command Prompt (select Start, Run; type cmd; and press Enter).
Type cd D:\support\Exdeploy and press Enter.

To create a report of current public folder replication, type the following:

pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /R /F:c:\LOGNAME.log

This generates a report named LOGNAME.log on the C: drive. OLDSERVERNAME should be the name of the Exchange 2000 system, and NEWSERVERNAME should be the new Exchange Server 2003 system.

To replicate System Folders from the Exchange 2000 server to the Exchange 2003 server, type the following:

pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /SF /A /N:100 /F:c:\LOGNAME.log

To replicate Public Folders from Exchange 2000 to Exchange Server 2003, type the following:

pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /A /N:100 /F:c:\LOGNAME.log

After all public folders have replicated, the old replicas can be removed from the Exchange 2000 Servers by typing the following, as illustrated in Figure 16.11:

pfmigrate.wsf /S:OLDSERVERNAME /T:NEWSERVERNAME /D

Figure 16.11. Command-line PFMigrate functionality.


 
The LOGNAME.log file can be reviewed to ensure that replication has occurred successfully and that a copy of each public folder exists on the new server. A sample log from this procedure is illustrated in Figure 16.12.
Figure 16.12. Sample PFMigrate log file.


TIP
Become familiar with the command-line options that are available with the PFMigrate tool, because they can be useful for managing the replication of public folders across a newly deployed Exchange Server 2003 environment.

3.    What are the message hygiene options you can use natively in Exchange 2003?
4.    What are the configuration options in IMF?
IMF SCL Configuration - getting it right
Correct SCL configuration is the key to a successful Exchange Intelligent Message Filter setup. With a good understanding of SCLs we can get the best results out of IMF. In this article I look at how to do this with the help of windeveloper IMF Tune, a freeware application released for this purpose.
 
Note: This article makes references to WinDeveloper IMF Tune, an application that was available as freeware at the time of writing. IMF Tune is today a commercial product.

The Intelligent Message Filter IMF, is one of the anti-spam products with the least configuration settings I ever came across. It boils down to four settings, Gateway SCL, Gateway Action, Junk Email SCL, and enabling of IMF per SMTP virtual server. The lack of options may easily give the impression that the configuration is trivial.
What's an SCL by the way? The SCL rating is a value from 0 to 9 assigned to emails as a classification of their likelihood of being spam. 0 indicates lowest probability whereas 9 indicates near certainty of the email being spam. Values in between indicate a varying degree of certainty.
Given the SCL value, an administrator is expected to decide what to do with the email. Emails with ratings at the lower range of SCL values are typically permitted to go through as valid email. High SCL ratings enable Administrators to be brave and take drastic actions such as delete, reject or archive. Values in between typically require emails to be deposited to the Junk Email folder for verification by the end-recipient. So effectively our goal is that of identifying these three SCL value ranges. Getting them wrong may lead to many valid emails ending in the Junk Email folder. Getting them totally wrong (and some do!!) may lead to loss of valuable emails.
Quick IMF Configuration Tour
Before delving deeper into SCLs, let's have a very quick look at the IMF configuration to make sure everyone is in sync. The main IMF configuration settings are available from:
<Organization> | Global Settings | Message Delivery <properties> | Intelligent Message Filtering <property sheet>


Here you will find Gateway SCL, Gateway Action and Junk Email SCL. The Gateway settings are used to filter emails scoring very high SCLs. At this end one can configure IMF to reject, delete or archive emails. The Junk Email SCL identifies the emails that should be deposited to the Junk Email folder. Obviously this is set to a lower value than the Gateway SCL. Note that there is a typo in the IMF configuration. The text "Move messages with an SCL rating greater than or equal to:" should read "Move messages with an SCL rating greater than:". Combining these two SCL values we end up with three buckets for email classification as depicted below:


Enabling of IMF per virtual server is done from:
<Organization> | Servers | <Exchange Server> | Protocols | SMTP | 'Intelligent Message Filtering'


What does the SCL really mean?
The first point to make clear is the fact that the SCL range between 0 and 9 is not linear. Let's rephrase this. Do SCL values such as 4 or 5 indicate 50:50 chance of an email being spam? Does it mean that half of these emails are spam and half ham? The answer is no. Such linearity would make large part of the SCL values useless.
Using IMF Archiving feature it is possible to get an idea how the level of certainty changes from one SCL value to another. To compile this table I just looked at a few sample emails between SCL1 and SCL 9, hence the values are purely indicative to illustrate this point.


X-SCL
Confidence Level (%)
1
52.68
2
57.43
3
63.87
4
67.41
5
82.82
6
90.50
7
94.72
8
97.82
9
99.58
As already said these values are purely indicative but it is clear that anyone rejecting/deleting/archiving emails with SCL lower than 7 is looking for trouble. Also values up to 3 or 4 can cause quite a large number of false positives.
Did I already say these values are purely indicative? This means that in practice one has to see IMF in action to see the real meaning of SCL values. My aim so far was to block anyone (see the newsgroups) from doing crazy stuff. What we need is to start off with some reasonable SCL values and fine tune our settings by checking what is being filtered.
Initial SCL settings
Putting myself in the position of an administrator deploying IMF for the first time this is how I would start the configuration settings:
Gateway Action
NoAction

Gateway SCL
8
In this case this is not relevant, but 8 would be my starting value for any other gateway action setting.
Junk Email SCL
4
Emails with SCL values between 0 and 4 will go straight to the inbox. All the rest goes to the Junk Email folders.
Starting with no gateway action is wise. It is first best to build your confidence in IMF before giving it the trust to remove emails. This is of course true for any other application as well. Once configuration is done make sure to enable IMF per virtual SMTP server as shown previously.
Next we need to check which emails are ending in the Junk Email folder and which in the Inbox. Note that for the Junk Email folder to be active, must be enabled through Outlook 2003: Tools | Options | Preferences | Junk E-mail... or through OWA: Options | 'Privacy and Junk E-mail Prevention'.
WinDeveloper IMF Tune freeware
It is now time to verify how well our initial SCL settings are doing. There are two things to check:
Valid emails ending in the Junk Email folder (false positives).
Spam remaining unfiltered ending in the recipient Inbox (false negatives).
To do this we need to identify the SCL ratings for mails with false results. This information is not readily available unless a tool such as WinDeveloper IMF Tune is used. IMF Tune processes all emails whose SCL score is larger than the Junk Email SCL. It then prefixes their subject with the SCL score as shown below.



IMF Tune now enables us to look into the Junk Email folder and see how each of the individual emails is being classified. The subject prefix enables us to sort all emails by SCL which is very useful.
Let's say a number of false positives are identified with SCL 5. The next step would be to determine what would happen if we were to raise the Junk Email SCL level to 5. Naturally this will cause all emails with rating of 5 or less to remain unfiltered. So it is best to determine how many false negatives will this cause. Sorting emails by SCL rating will enable us to visualize this. If a good number of emails with SCL 5 are valid then one should certainly raise this level. On the other hand if this is a small percentage it might be best to leave it as is. This decision can only be taken by analyzing real live data.
IMF Tune is not configurable. It reads the IMF configuration every 5 minutes and adjusts which emails to process accordingly. Hence on changing the IMF configuration, for a short while, you may end up with some missing SCL prefixes at the Junk Email folder or some SCL prefixes at the Inbox. To avoid this restart the IIS Admin service, otherwise just be patient for a few minutes.
IMF Tune only processes Junk Email. The subject is clearly an important piece of information which is best left alone for legitimate emails. So IMF Tune is most useful when analyzing false positives. If a significant amount of spam is reaching your Inbox then you may of course lower the Junk Email SCL. You may then use IMF Tune to analyze the result of this change.
Determining the Gateway SCL settings is another area where IMF Tune comes handy. We started our IMF setup with no gateway action. Now that the system has been running for some time it is good to look at the emails being assigned high SCL values such as 8 and 9. Most organizations are unlikely to get false positives at this level. If you feel enough confident in IMF SCL ratings at this end, then you may want to switch to archiving or even something more drastic like delete or reject.
To conclude this, my client is currently using archiving as Gateway Action, 8 for Gateway SCL and 5 for Junk Email SCL. He is also using another commercial Anti-spam product.

5.    What are virtual servers? When would you use more than one?

An SMTP virtual server is an instance of the SMTP service running on an Exchange server. It is bound to a particular IP address (or group of IP addresses) and port, usually the well-known TCP port 25.

Windows Exchange Servers use the word 'Virtual' in many contexts.  To begin with, one physical machine can act as a server for several Virtual SMTP domains, for example ourcomp.com and mergecomp.net.  Moreover, in addition to SMTP, one Exchange Server can also control Virtual servers for IMAP4, NNTP and POP3.  From another point of view, you could interpret these Exchange Virtual servers as aliases for physical folders in Microsoft's IIS.
In a completely different context, the term Virtual Server is used in clustering. The Outlook clients connect not to the individual Exchange 2003 nodes, but to a Virtual server with a virtual IP address.

6.    Name some of the SMTP Virtual Server configuration options.
Introduction to Virtual Servers in Exchange Server 2003
Finding Microsoft's Virtual Servers must be one of the longest 'drill downs' in the Exchange 2003 System Manager.  It's as though one of Exchange server's most important configuration settings is hidden away, rather than being visible as a top level folder.
Topics for Virtual Servers in Exchange Server 2003
*         Explaining Virtual Servers
*         How to Configure a Microsoft Virtual SMTP server
*         Summary
Windows Exchange Servers use the word 'Virtual' in many contexts.  To begin with, one physical machine can act as a server for several Virtual SMTP domains, for example ourcomp.com and mergecomp.net.  Moreover, in addition to SMTP, one Exchange Server can also control Virtual servers for IMAP4, NNTP and POP3.  From another point of view, you could interpret these Exchange Virtual servers as aliases for physical folders in Microsoft's IIS.
In a completely different context, the term Virtual Server is used in clustering. The Outlook clients connect not to the individual Exchange 2003 nodes, but to a Virtual server with a virtual IP address.

                       
 Opposite is a diagram to help you navigate to the various Virtual Servers folders.  Once you have found your Exchange 2003 server object, expand the Protocols folder.  Each protocol has its own Virtual server.  SMTP for MAPI clients (Outlook), HTTP is for OWA (Outlook Web Access).
We are most interested in the Default SMTP Virtual Server.  As its name suggests, this is the container where you check settings for regular SMTP mail.  (See this SMTP server object at the very bottom of the screen shot.)
SMTP Virtual Server
*         General Tab - For Connection Filter and Port Numbers
*         Access Tab - For Permissions
*         Messages Tab - For Limits
*         Delivery Tab - DNS Settings



One of the most important jobs in the Virtual Server is to configure any Filters that you set at the Global Settings, Message Delivery Tab.  See Global Settings here.
To find the screen shot opposite click on the Advanced Tab next to the IP address.  Select the IP address and Edit, now the Identification dialog box will appear, see diagram opposite.  At last you can check: Apply Sender, Recipient or Connection Filter.
General Tab - Port Numbers
Rather like IIS, each SMTP Virtual server needs a unique combination of IP address and Port number. Here are the common Exchange port numbers:
      Default   Secure Port
HTTP      80     443
IMAP4   143     993
NNTP    119     563
POP3    110     995
SMTP     25      25

The access tab is where you configure authentication.  Who will be allowed to use your SMTP Virtual server?  Authenticated users - yes, but anonymous users?  I think not, but you decide.
The first section deals with setting limits - if any.  For example, what would be the maximum number of recipients for your company's emails?
The lower section invites you to configure accounts to hold NDR (non deliverable reports).  This is where you troubleshoot the location of the BadMail folder and the Queue directory.
  As ever, DNS plays a central role in name resolution.  Most likely your servers are
  registered on the internet as being authoritative for your email domain.  This
  involves MX (Mail exchange) records on the InterNic servers that point to your
  Exchange 2003 server.
The other side of the DNS coin is that your server must be able to deliver outgoing email.  If your server is (rightly) protected by a firewall delivering external email can be an extra challenge. The answer is to forward the name resolution to a Smart host on the outside of the firewall.
Reverse DNS
Configuring, Perform reverse DNS lookup, seems like a great idea to prevent spammers spoofing addresses in their evil emails.  However, everyone that I have talked to has found that it slows down the system so much, that they put Reverse DNS lookup in that pigeon hole: 'more trouble than it's worth '.

Summary of Windows Exchange Server 2003 - Virtual Server
Once you discover where Microsoft's SMTP Virtual servers are hiding, then you can get on with the important task of configuring the Exchange 2003 server to accept your email, while not relaying spam.  Remember the link between Global Settings and SMTP filtering.

7.    What is a Mail Relay? Name a few known mail relay software or hardware options.
Often referred to as an e-mail server, a device and/or program that routes an e-mail to the correct destination. Mail relays are typically used within local networks to transmit e-mails among local users. (For example, all of the student and faculty e-mail of a college campus.) Mail relays are particularly useful in e-mail aliasing where multiple e-mail addresses are used but the mail relay forwards all messages to the specified e-mail addresses to one single address.
A mail relay is different than an open relay, where an e-mail server processes a mail message that that neither originates or ends with a user that is within the server’s local domain (i.e., local IP range).

No comments:

Post a Comment