1. Get-ActivesyncDeviceStatistics -mailbox raji.subramanian@domain.com
2. Get-CASMailbox | where {$_.HasActiveSyncDevicePartnership} | select Name
3. Get-CASMailbox -Filter {HasActiveSyncDevicePartnership -eq $true} | Select Name
Saturday, October 31, 2009
Friday, October 30, 2009
Tarpitting in Exchange 2007
Tarpitting is the practice of slowing the transmission of e-mail messages sent in bulk as a means of thwarting spammers. The intent is to maintain a high quality of service for legitimate users while making the sending process impractical for spammers, who -- because of low response rates -- must be able to send vast volumes of messages quickly and inexpensively. The delay is insignificant for typical recipient lists, and administrators can grant exemptions to people with valid reasons to send messages to a large number of recipients.
There are a number of approaches to tarpitting. One method is to insert small delays (sometimes called sleeps) after a certain number of recipients in a Simple Mail Transfer Protocol (SMTP) session. For example, the first 20 messages in a session might be sent without delay and then a few seconds' delay added for each recipient in the list beyond that number. If a spam mailing list contains 10,000 recipients and a delay of even two seconds is applied for each recipient after the twentieth, the total delay incurred is over five and a half hours.
Tarpitting is closely related to the concept of the teergrube (German for tar pit), a server that is intentionally configured to be slow, generally as a means of trapping address harvester programs.
There are a number of approaches to tarpitting. One method is to insert small delays (sometimes called sleeps) after a certain number of recipients in a Simple Mail Transfer Protocol (SMTP) session. For example, the first 20 messages in a session might be sent without delay and then a few seconds' delay added for each recipient in the list beyond that number. If a spam mailing list contains 10,000 recipients and a delay of even two seconds is applied for each recipient after the twentieth, the total delay incurred is over five and a half hours.
Tarpitting is closely related to the concept of the teergrube (German for tar pit), a server that is intentionally configured to be slow, generally as a means of trapping address harvester programs.
Thursday, October 29, 2009
Types of Exchange 2007 Queues
Exchange 2007 uses the following types of queues:
Submission Queue: The submission queue is used by the categorizer to temporarily store all messages pending further action by the Transport agents - messages that should be resolved, routed and processed. Each transport server has one submission queue; all messages that enter the transport server go to the submission queue for processing. Messages that are in the submission queue cannot be in any other queues at the same time.
Mailbox Delivery Queue: The mailbox delivery queue holds messages that are being delivered to a mailbox server by using encrypted Exchange RPC. Only Hub Transport servers have mailbox delivery queues. They temporarily store messages that are being routed to the destination mailbox on a remote mailbox server in the same organization as the Hub Transport server.
Remote Delivery Queue: Hub Transport servers and Edge Transport servers can have remote delivery queues; they hold messages temporarily while they are routed to remote destinations using SMTP. These remote destinations can be an external domain, SMTP connector, or a destination which is outside the scope of the Active Directory site in which the Hub Transport server is located.
Poison Message Queue: The poison message queue holds any messages that are considered to be problematic after there has been a server failure. All messages in this queue are suspended and can be deleted manually. Each transport server has one poison message queue.
Unreachable Queue: The unreachable queue holds messages that cannot be routed to the intended destination. Each transport server has one unreachable queue.
Submission Queue: The submission queue is used by the categorizer to temporarily store all messages pending further action by the Transport agents - messages that should be resolved, routed and processed. Each transport server has one submission queue; all messages that enter the transport server go to the submission queue for processing. Messages that are in the submission queue cannot be in any other queues at the same time.
Mailbox Delivery Queue: The mailbox delivery queue holds messages that are being delivered to a mailbox server by using encrypted Exchange RPC. Only Hub Transport servers have mailbox delivery queues. They temporarily store messages that are being routed to the destination mailbox on a remote mailbox server in the same organization as the Hub Transport server.
Remote Delivery Queue: Hub Transport servers and Edge Transport servers can have remote delivery queues; they hold messages temporarily while they are routed to remote destinations using SMTP. These remote destinations can be an external domain, SMTP connector, or a destination which is outside the scope of the Active Directory site in which the Hub Transport server is located.
Poison Message Queue: The poison message queue holds any messages that are considered to be problematic after there has been a server failure. All messages in this queue are suspended and can be deleted manually. Each transport server has one poison message queue.
Unreachable Queue: The unreachable queue holds messages that cannot be routed to the intended destination. Each transport server has one unreachable queue.
Wednesday, October 28, 2009
Exchange server 2007 Services.
This article explains the different type of services, its description. Since exchange 2007 has so many new features, changes and different mailing architecture when compared to earlier exchange versions. We know that exchange server 2007 has five different server roles which has its specific services. In this article, I am going to concentrate only on the exchange specific services, though there are many dependent services like WWW, RPC, WMI and etc.
Common Services on all Server roles:
The below services are present in all five server roles,
1. Microsoft Exchange Active Directory Topology Service: This is the core exchange services which communicate with AD often. This service uses DSACCESS component for accessing the active directory. Since, AD tightly integrated with Exchange, all server roles will have this service up running.
2. Microsoft Exchange Monitoring Service: This service is responsible for collecting all kind of diagnostic logs from the exchange application.
Services in Mailbox server role:
1. Microsoft Exchange information store: This is the service related to core exchange databases. It is the main services in the Mailbox server role and this is services is not dependent to other exchange services.
2. Microsoft Exchange Mail Submission: This service maintains the mail queue for transferring mails from mailbox server to hub transport server. Used to notify a Hub Transport server located in the Mailbox server's Active Directory site that messages are ready for retrieval from a sender's outbox. This service is also responsible for relaying and other tasks like Transport rules, Message Records Management etc.
3. Microsoft Exchange mailbox assistants: Provides functionality for Calendar Attendant, Resource Booking Attendant, Out of Office Assistant, and Managed Folder Mailbox Assistant.
4. Microsoft Exchange Replication Service: This service responsible for the replication of database information in the LCR and SCR cluster environment. This does the log shipping/seeding b/w the cluster peers.
5. Microsoft Exchange Search Indexer: This service is responsible for indexing the mail content in the database which in turn helps in improving the faster access/searching of the mail contents.
6. Microsoft Exchange Service Host: Configures the RPC virtual directory in Internet Information Services (IIS), and registry data for Valid Ports, NSPI Interface Protocol Sequences, and Allow Anonymous for Outlook Anywhere. It basically acts as a host for holding exchange related services like IIS.
7. Microsoft Exchange System Attendant: This service is responsible for following components. It provides maintaining, monitoring and directory lookup services functionality.
• DSAccess (DSAccess.dll) – Provides Exchange Active Directory Access
• DSProxy (DSProxy.dll) – Provides Directory Service Lookup for older Outlook clients
• Server Monitor Component - Monitoring server resources
• Mailbox Manager Component - Managing mailboxes
• Metabase update service - Replicating settings from Active Directory to the IIS metabase
• System Attendant Component - Verifies computer account configuration
8. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
9. Microsoft Search (Exchange): Provides full-text indexing of mailbox data content. This is a Microsoft Exchange-customized version of Microsoft Search.
Services in CAS Servers:
1. Microsoft Exchange File Distribution: Used to distribute offline address book and custom Unified Messaging prompts.
2. Microsoft Exchange IMAP4: Responsible for Internet Message Access Protocol IMAP4 Clients connections.
3. Microsoft Exchange POP3: Responsible for Post Office Protocol POP3 Client connections.
4. Microsoft Exchange Service Host: Configures the RPC virtual directory in Internet Information Services (IIS), and registry data for Valid Ports, NSPI Interface Protocol Sequences, and Allow Anonymous for Outlook Anywhere. It basically acts as a host for holding exchange related services like IIS.
Services in Hub transport Servers:
1. Microsoft Exchange Anti-Spam Update: Used to automatically download anti-spam filter updates from Microsoft Update.
2. Microsoft Exchange Edgesync: Connects to ADAM instance on subscribed Edge Transport servers over secure Lightweight Directory Access Protocol (LDAP) channel to synchronize data between a Hub Transport server and an Edge Transport server.
3. Microsoft Exchange Transport: This is the new SMTP service in exchange 2007, which don’t rely on Windows server SMTP services as like in previous version of the exchange. It is the core transport stacks which process the routing of messages.
4. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
Services in Edge Transport Servers:
1. Microsoft Exchange ADAM: Connects to ADAM instance on subscribed Edge Transport servers over secure Lightweight Directory Access Protocol (LDAP) channel to synchronize data between a Hub Transport server and an Edge Transport server.
2. Microsoft Exchange Anti-Spam Update: Used to automatically download anti-spam filter updates from Microsoft Update.
3. Microsoft Exchange Credential Service: Monitors credential changes in ADAM and installs the changes on the Edge Transport server.
4. Microsoft Exchange Transport: This is the new SMTP service in exchange 2007, which don’t rely on Windows server SMTP services as like in previous version of the exchange. It is the core transport stacks which process the routing of messages.
5. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
Services in Unified Messaging Servers:
1. Microsoft Exchange Unified Messaging: Provides Unified Messaging features, such as the storing of inbound faxes and voice mail messages in a user's mailbox, and access to that mailbox via Outlook Voice Access.
2. Microsoft Exchange Speech Engine: Provides speech processing services for Unified Messaging.
Common Services on all Server roles:
The below services are present in all five server roles,
1. Microsoft Exchange Active Directory Topology Service: This is the core exchange services which communicate with AD often. This service uses DSACCESS component for accessing the active directory. Since, AD tightly integrated with Exchange, all server roles will have this service up running.
2. Microsoft Exchange Monitoring Service: This service is responsible for collecting all kind of diagnostic logs from the exchange application.
Services in Mailbox server role:
1. Microsoft Exchange information store: This is the service related to core exchange databases. It is the main services in the Mailbox server role and this is services is not dependent to other exchange services.
2. Microsoft Exchange Mail Submission: This service maintains the mail queue for transferring mails from mailbox server to hub transport server. Used to notify a Hub Transport server located in the Mailbox server's Active Directory site that messages are ready for retrieval from a sender's outbox. This service is also responsible for relaying and other tasks like Transport rules, Message Records Management etc.
3. Microsoft Exchange mailbox assistants: Provides functionality for Calendar Attendant, Resource Booking Attendant, Out of Office Assistant, and Managed Folder Mailbox Assistant.
4. Microsoft Exchange Replication Service: This service responsible for the replication of database information in the LCR and SCR cluster environment. This does the log shipping/seeding b/w the cluster peers.
5. Microsoft Exchange Search Indexer: This service is responsible for indexing the mail content in the database which in turn helps in improving the faster access/searching of the mail contents.
6. Microsoft Exchange Service Host: Configures the RPC virtual directory in Internet Information Services (IIS), and registry data for Valid Ports, NSPI Interface Protocol Sequences, and Allow Anonymous for Outlook Anywhere. It basically acts as a host for holding exchange related services like IIS.
7. Microsoft Exchange System Attendant: This service is responsible for following components. It provides maintaining, monitoring and directory lookup services functionality.
• DSAccess (DSAccess.dll) – Provides Exchange Active Directory Access
• DSProxy (DSProxy.dll) – Provides Directory Service Lookup for older Outlook clients
• Server Monitor Component - Monitoring server resources
• Mailbox Manager Component - Managing mailboxes
• Metabase update service - Replicating settings from Active Directory to the IIS metabase
• System Attendant Component - Verifies computer account configuration
8. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
9. Microsoft Search (Exchange): Provides full-text indexing of mailbox data content. This is a Microsoft Exchange-customized version of Microsoft Search.
Services in CAS Servers:
1. Microsoft Exchange File Distribution: Used to distribute offline address book and custom Unified Messaging prompts.
2. Microsoft Exchange IMAP4: Responsible for Internet Message Access Protocol IMAP4 Clients connections.
3. Microsoft Exchange POP3: Responsible for Post Office Protocol POP3 Client connections.
4. Microsoft Exchange Service Host: Configures the RPC virtual directory in Internet Information Services (IIS), and registry data for Valid Ports, NSPI Interface Protocol Sequences, and Allow Anonymous for Outlook Anywhere. It basically acts as a host for holding exchange related services like IIS.
Services in Hub transport Servers:
1. Microsoft Exchange Anti-Spam Update: Used to automatically download anti-spam filter updates from Microsoft Update.
2. Microsoft Exchange Edgesync: Connects to ADAM instance on subscribed Edge Transport servers over secure Lightweight Directory Access Protocol (LDAP) channel to synchronize data between a Hub Transport server and an Edge Transport server.
3. Microsoft Exchange Transport: This is the new SMTP service in exchange 2007, which don’t rely on Windows server SMTP services as like in previous version of the exchange. It is the core transport stacks which process the routing of messages.
4. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
Services in Edge Transport Servers:
1. Microsoft Exchange ADAM: Connects to ADAM instance on subscribed Edge Transport servers over secure Lightweight Directory Access Protocol (LDAP) channel to synchronize data between a Hub Transport server and an Edge Transport server.
2. Microsoft Exchange Anti-Spam Update: Used to automatically download anti-spam filter updates from Microsoft Update.
3. Microsoft Exchange Credential Service: Monitors credential changes in ADAM and installs the changes on the Edge Transport server.
4. Microsoft Exchange Transport: This is the new SMTP service in exchange 2007, which don’t rely on Windows server SMTP services as like in previous version of the exchange. It is the core transport stacks which process the routing of messages.
5. Microsoft Exchange Transport Log Search: Provides message tracking and transport log searching. It is basically used for querying of transport log remotely.
Services in Unified Messaging Servers:
1. Microsoft Exchange Unified Messaging: Provides Unified Messaging features, such as the storing of inbound faxes and voice mail messages in a user's mailbox, and access to that mailbox via Outlook Voice Access.
2. Microsoft Exchange Speech Engine: Provides speech processing services for Unified Messaging.
Tuesday, October 27, 2009
Understanding DSProxy, DSReferral, DSAccess and the Categorizer:
We already aware that both AD and Exchange are highly integrated, the relationship b/w AD and exchange is more complex and often misunderstood.
Exchange server uses two services – Dsproxy and Dsaccess – to access the GC Global Catalog.
Dsproxy is an exchange specific service, whereas Dsaccess is a Windows service in turn used by the exchange server.
Dsproxy:
1. In general, Outlook 2000 clients and above can access the GC directly, but the old outlook client doesn’t.
2. To address the above lack of access, exchange server provides a proxy service called Dsproxy, acts as an intermediary b/w client and the GC.
3. Dsproxy works as a facilitator to allow outlook clients to access information within the AD through the Name Service Provider Interface (NSPI).
Dsreferral:
1. Since the dsproxy helps outlook client to reach the GC directly. Dsreferral also enhance or work to facilitate dsproxy.
2. Dsreferaal is used especially when exchange server not running on GC server. In such cases, DS Referral has the capability to update the Outlook 2000 client's MAPI profile with an appropriate GC server.
Dsaccess:
1. In general, the exchange server shares the GC functionality with the other AD services, It is important to reduce the impact of exchange server queries on GC. Dsaccess become solution for this.
2. Dsaccess implement a cache that stores recently accessed information for a configurable length of time. This cache reduces the number of direct query on GC drastically.
Role of the Categorizer:
The SMTP Categorizer is a component of Exchange that is used to submit mail messages to the proper destination. When a mail message is sent, the Categorizer queries the DSAccess component to locate an Active Directory server list, which is then directly queried for information that can be used to deliver the message. Problems with the Categorizer are often the cause of DNS or AD lookup issues. When troubleshooting mail-flow problems, please use message tracking in Exchange Server 2007 to find the course of a message. If the message stops at the Categorizer, it is often wise to start troubleshooting the issue from a directory access perspective.
Exchange server uses two services – Dsproxy and Dsaccess – to access the GC Global Catalog.
Dsproxy is an exchange specific service, whereas Dsaccess is a Windows service in turn used by the exchange server.
Dsproxy:
1. In general, Outlook 2000 clients and above can access the GC directly, but the old outlook client doesn’t.
2. To address the above lack of access, exchange server provides a proxy service called Dsproxy, acts as an intermediary b/w client and the GC.
3. Dsproxy works as a facilitator to allow outlook clients to access information within the AD through the Name Service Provider Interface (NSPI).
Dsreferral:
1. Since the dsproxy helps outlook client to reach the GC directly. Dsreferral also enhance or work to facilitate dsproxy.
2. Dsreferaal is used especially when exchange server not running on GC server. In such cases, DS Referral has the capability to update the Outlook 2000 client's MAPI profile with an appropriate GC server.
Dsaccess:
1. In general, the exchange server shares the GC functionality with the other AD services, It is important to reduce the impact of exchange server queries on GC. Dsaccess become solution for this.
2. Dsaccess implement a cache that stores recently accessed information for a configurable length of time. This cache reduces the number of direct query on GC drastically.
Role of the Categorizer:
The SMTP Categorizer is a component of Exchange that is used to submit mail messages to the proper destination. When a mail message is sent, the Categorizer queries the DSAccess component to locate an Active Directory server list, which is then directly queried for information that can be used to deliver the message. Problems with the Categorizer are often the cause of DNS or AD lookup issues. When troubleshooting mail-flow problems, please use message tracking in Exchange Server 2007 to find the course of a message. If the message stops at the Categorizer, it is often wise to start troubleshooting the issue from a directory access perspective.
Installation of Exchange 2007 SP2 on Windows Server 2008
Step 1: Preparation of Schema
C:\Users\Administrator\Desktop\New Folder>setup.com /Prepareschema
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Extending Active Directory schema
Progress .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 2: Preparation of Active Directory
C:\Users\Administrator\Desktop\New Folder>setup.com /PrepareAD
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Exchange organization name is required for this mode. To specify an organizatio
n name, use the /OrganizationName parameter.
Exchange Server setup encountered an error.
C:\Users\Administrator\Desktop\New Folder>setup.com /PrepareAd /organization:test
is not a valid command line option. To list the available c
ommand line parameters, type Setup /?
C:\Users\Administrator\Desktop\New Folder>setup.com /preparead /organizationname:test
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Organization Preparation .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 3: Preparation of Domain
C:\Users\Administrator\Desktop\New Folder>setup.com /help
Welcome to Microsoft Exchange Server 2007 Setup Help
Please type one of the below options for detailed help on each subject:
Setup.com /help:Install - Installing Exchange Server roles.
Setup.com /help:Uninstall - Uninstalling Exchange Server roles.
Setup.com /help:Upgrade - Upgrading Exchange Server roles.
Setup.com /help:RecoverServer - Recovering an existing Exchange Server.
Setup.com /help:PrepareTopology - Preparing your topology for Exchange.
Setup.com /help:Cluster - Installing Exchange on Clusters.
Setup.com /help:Delegation - Delegated server installations.
Setup.com /help:UmLanguagePacks - Adding/removing UM language packs.
C:\Users\Administrator\Desktop\New Folder>setup.com /help:preparetopology
Prepare Topology Usage:
Setup.com /PrepareAD [/DomainController:]
Setup.com /PrepareSchema [/DomainController:]
Setup.com /PrepareDomain [/DomainController:]
Setup.com /PrepareDomain: [/DomainController:]
Setup.com /PrepareAllDomains [/DomainController:]
Setup.com /PrepareLegacyExchangePermissions [/DomainController:]
Setup.com /PrepareLegacyExchangePermissions: [/DomainController:]
--Prepare Topology Required Parameters--
/PrepareLegacyExchangePermissions, /pl
Prepares the permissions in a legacy forest.
Use this parameter only if you have Exchange 2000 or 2003 servers in your organization.
/PrepareLegacyExchangePermissions:, /pl:
Prepares the permissions for the specified domain.
/PrepareAD, /p
Prepares the Active Directory forest for the Exchange installation.
This will perform all the operations listed below in the local domain.
/PrepareSchema, /ps
Prepares the Active Directory Schema for the Exchange installation.
/PrepareDomain, /pd
Prepares the local domain for the Exchange installation.
/PrepareDomain:, /pd:
Prepares the specified domain for the Exchange installation.
/PrepareAllDomains, /pad
Prepares all domains in the forest for the Exchange
installation.
--Prepare Topology Optional Parameters--
[/DomainController, /dc]
Specifies the domain controller that setup will use to read
and write to Active Directory. Netbios or FQDN format can be used.
C:\Users\Administrator\Desktop\New Folder>setup.com /preparedomain:wipro.com
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks ......................... FAILED
Setup encountered a problem while validating the state of Active Directory:
Could not find any Domain Controller in domain wipro.com.
The Exchange Server Setup operation did not complete. For more information, visit http://support.microsoft.com and enter the Error ID.
Exchange Server setup encountered an error.
C:\Users\Administrator\Desktop\New Folder>setup.com /preparedomain:wipro.com
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Prepare Domain Progress .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 5: Installation of Roles in Exchange 07
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:h
Setup cannot continue while another setup is in progress. Please exit any runnin
g Exchange 2007 setup and try again.
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:h
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Management Tools
Hub Transport Role
Performing Microsoft Exchange Server Prerequisite Check
Hub Transport Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
'SCLRejectEnabled' Setting will be reset after Hub Transport role is installed.
If you wish to turn off SCL rating in your environment, please re-run 'Set-Cont
entFilterConfig -SCLRejectEnabled:$false' from Exchange Management Shell after t
his installation.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Exchange Management Tools .........................COMPLETED
Hub Transport Server Role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\administrator.WIPRO>cd..
C:\Users>cd..
C:\>cd Users
C:\Users>cd Administrator
C:\Users\Administrator>cd Desktop
C:\Users\Administrator\Desktop>cd "New Folder"
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:clientaccess /noselfsignedcertificates
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Client Access Role
Performing Microsoft Exchange Server Prerequisite Check
Client Access Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Client Access server role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:mailbox
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Mailbox Role
Performing Microsoft Exchange Server Prerequisite Check
Mailbox Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Mailbox Server Role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
C:\Users\Administrator\Desktop\New Folder>setup.com /Prepareschema
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Extending Active Directory schema
Progress .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 2: Preparation of Active Directory
C:\Users\Administrator\Desktop\New Folder>setup.com /PrepareAD
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Exchange organization name is required for this mode. To specify an organizatio
n name, use the /OrganizationName parameter.
Exchange Server setup encountered an error.
C:\Users\Administrator\Desktop\New Folder>setup.com /PrepareAd /organization:test
is not a valid command line option. To list the available c
ommand line parameters, type Setup /?
C:\Users\Administrator\Desktop\New Folder>setup.com /preparead /organizationname:test
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Organization Preparation .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 3: Preparation of Domain
C:\Users\Administrator\Desktop\New Folder>setup.com /help
Welcome to Microsoft Exchange Server 2007 Setup Help
Please type one of the below options for detailed help on each subject:
Setup.com /help:Install - Installing Exchange Server roles.
Setup.com /help:Uninstall - Uninstalling Exchange Server roles.
Setup.com /help:Upgrade - Upgrading Exchange Server roles.
Setup.com /help:RecoverServer - Recovering an existing Exchange Server.
Setup.com /help:PrepareTopology - Preparing your topology for Exchange.
Setup.com /help:Cluster - Installing Exchange on Clusters.
Setup.com /help:Delegation - Delegated server installations.
Setup.com /help:UmLanguagePacks - Adding/removing UM language packs.
C:\Users\Administrator\Desktop\New Folder>setup.com /help:preparetopology
Prepare Topology Usage:
Setup.com /PrepareAD [/DomainController:
Setup.com /PrepareSchema [/DomainController:
Setup.com /PrepareDomain [/DomainController:
Setup.com /PrepareDomain:
Setup.com /PrepareAllDomains [/DomainController:
Setup.com /PrepareLegacyExchangePermissions [/DomainController:
Setup.com /PrepareLegacyExchangePermissions:
--Prepare Topology Required Parameters--
/PrepareLegacyExchangePermissions, /pl
Prepares the permissions in a legacy forest.
Use this parameter only if you have Exchange 2000 or 2003 servers in your organization.
/PrepareLegacyExchangePermissions:
Prepares the permissions for the specified domain.
/PrepareAD, /p
Prepares the Active Directory forest for the Exchange installation.
This will perform all the operations listed below in the local domain.
/PrepareSchema, /ps
Prepares the Active Directory Schema for the Exchange installation.
/PrepareDomain, /pd
Prepares the local domain for the Exchange installation.
/PrepareDomain:
Prepares the specified domain for the Exchange installation.
/PrepareAllDomains, /pad
Prepares all domains in the forest for the Exchange
installation.
--Prepare Topology Optional Parameters--
[/DomainController, /dc]
Specifies the domain controller that setup will use to read
and write to Active Directory. Netbios or FQDN format can be used.
C:\Users\Administrator\Desktop\New Folder>setup.com /preparedomain:wipro.com
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks ......................... FAILED
Setup encountered a problem while validating the state of Active Directory:
Could not find any Domain Controller in domain wipro.com.
The Exchange Server Setup operation did not complete. For more information, visit http://support.microsoft.com and enter the Error ID.
Exchange Server setup encountered an error.
C:\Users\Administrator\Desktop\New Folder>setup.com /preparedomain:wipro.com
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks .........................COMPLETED
Configuring Microsoft Exchange Server
Prepare Domain Progress .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Step 5: Installation of Roles in Exchange 07
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:h
Setup cannot continue while another setup is in progress. Please exit any runnin
g Exchange 2007 setup and try again.
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:h
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Management Tools
Hub Transport Role
Performing Microsoft Exchange Server Prerequisite Check
Hub Transport Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
'SCLRejectEnabled' Setting will be reset after Hub Transport role is installed.
If you wish to turn off SCL rating in your environment, please re-run 'Set-Cont
entFilterConfig -SCLRejectEnabled:$false' from Exchange Management Shell after t
his installation.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Exchange Management Tools .........................COMPLETED
Hub Transport Server Role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\administrator.WIPRO>cd..
C:\Users>cd..
C:\>cd Users
C:\Users>cd Administrator
C:\Users\Administrator>cd Desktop
C:\Users\Administrator\Desktop>cd "New Folder"
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:clientaccess /noselfsignedcertificates
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Client Access Role
Performing Microsoft Exchange Server Prerequisite Check
Client Access Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Client Access server role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
C:\Users\Administrator\Desktop\New Folder>setup.com /mode:install /roles:mailbox
Welcome to Microsoft Exchange Server 2007 Unattended Setup
Preparing Exchange Setup
The following server roles will be installed
Mailbox Role
Performing Microsoft Exchange Server Prerequisite Check
Mailbox Role Checks .........................COMPLETED
The 32-bit version of Exchange Server 2007 is not supported for production use.
Configuring Microsoft Exchange Server
Copying Exchange files .........................COMPLETED
Mailbox Server Role .........................COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to take effect. Please reboot this server prior to placing it into production.
Tuesday, October 20, 2009
How public folder referrals have changed in Exchange 2007
Exchange 2007 change in the elimination of a couple of well-known key concepts in prior versions: Administrative Groups and Routing Groups. The elimination of the routing group, and consequently the routing group connector, changes the way that public folder referrals are handled in Exchange 2007.
Previously, the public folder server would call into the routing engine to gather routing cost information, and use this information to control content referrals and pick servers for backfill requests. Now, the server connects directly to Active Directory to get the inter-site costs among all the public folder servers.
There's no way to indicate on an AD site connector that you don't want public folder referrals to happen. No longer can you check a checkbox and stop PF referrals from happening from one corner of your company to another. But don't panic! The server still implements a method to ensure client referrals don't end up going to the wrong end of the planet. The server has the notion of other servers which are "too expensive" to accept referrals. As of this writing, that "too expensive" threshold is 500. Yes, that really needs to be configurable, and we will examine doing that in a future release.
We still have the feature where you can specify a specific cost list for a single server. Instead of calling into AD, we'll simply read this cost list and use whatever data it provides. Unlisted servers implicitly have an "infinite" cost, so this provides a simple method for disallowing referrals from a specific server to a set of other servers.
This new source of cost information also controls the backfill picker. Previously, the code always queried for cost information once (an hour) and cached it. This cached info was used to prepare client referrals and to pick servers to ask for backfill. Now that we're querying AD instead of the routing engine, all users of that cost information benefit from the new source and all can see the same information.
It's important to note that Exchange 2007 exclusively uses the AD site connector cost information, while pre-Exchange 2007 exclusively uses the data from the routing group connectors. Since all Exchange 2007 servers appear to be in a single routing group from pre-Exchange 2007's point of view, without some additional configuration you may experience truly bizarre referrals for users whose default public folder database is on a pre-Exchange 2007 server, but all the replicas live solely on Exchange 2007 servers. In this specific case, the pre-Exchange 2007 server will perceive all the Exchange 2007 servers as having the same cost (because they're all in the same routing group). Clients will get referrals all over the place. To prevent this from happening, you should set all default PFDBs for all mailbox DBs to point to Exchange 2007 as soon as you've replicated content to any Exchange 2007 servers.
NOTE: If you have Exchange 2003 users that use OWA, you should not point the Exchange 2003 mailbox database to an Exchange 2007 public folder database, until you move all users that need OWA public folder access to Exchange 2007.
Previously, the public folder server would call into the routing engine to gather routing cost information, and use this information to control content referrals and pick servers for backfill requests. Now, the server connects directly to Active Directory to get the inter-site costs among all the public folder servers.
There's no way to indicate on an AD site connector that you don't want public folder referrals to happen. No longer can you check a checkbox and stop PF referrals from happening from one corner of your company to another. But don't panic! The server still implements a method to ensure client referrals don't end up going to the wrong end of the planet. The server has the notion of other servers which are "too expensive" to accept referrals. As of this writing, that "too expensive" threshold is 500. Yes, that really needs to be configurable, and we will examine doing that in a future release.
We still have the feature where you can specify a specific cost list for a single server. Instead of calling into AD, we'll simply read this cost list and use whatever data it provides. Unlisted servers implicitly have an "infinite" cost, so this provides a simple method for disallowing referrals from a specific server to a set of other servers.
This new source of cost information also controls the backfill picker. Previously, the code always queried for cost information once (an hour) and cached it. This cached info was used to prepare client referrals and to pick servers to ask for backfill. Now that we're querying AD instead of the routing engine, all users of that cost information benefit from the new source and all can see the same information.
It's important to note that Exchange 2007 exclusively uses the AD site connector cost information, while pre-Exchange 2007 exclusively uses the data from the routing group connectors. Since all Exchange 2007 servers appear to be in a single routing group from pre-Exchange 2007's point of view, without some additional configuration you may experience truly bizarre referrals for users whose default public folder database is on a pre-Exchange 2007 server, but all the replicas live solely on Exchange 2007 servers. In this specific case, the pre-Exchange 2007 server will perceive all the Exchange 2007 servers as having the same cost (because they're all in the same routing group). Clients will get referrals all over the place. To prevent this from happening, you should set all default PFDBs for all mailbox DBs to point to Exchange 2007 as soon as you've replicated content to any Exchange 2007 servers.
NOTE: If you have Exchange 2003 users that use OWA, you should not point the Exchange 2003 mailbox database to an Exchange 2007 public folder database, until you move all users that need OWA public folder access to Exchange 2007.
Wednesday, October 14, 2009
Moving from free-busy information to Availability service
The Public Folder database is created in Exchange 2007 so that you can replicate any Public Folder data stored on your legacy Exchange servers to Exchange 2007. Even though you don’t use Public Folders to store data in your environment, there’s one other reason why you might want to keep the Public Folder database mounted on your Exchange 2007 Server.
As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service.
The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service.
As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service.
The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service.
Saturday, October 10, 2009
Outlook Web Access and Exchange 2007, 2003 and 2000 coexistence
To get started, let me take you on a trip down memory lane to dark ages of computing and e-mail. Journey with me to the years 2000 and 2003, when Exchange was a much different product. In Exchange 2003 and 2000, there were two server configurations: front-end (FE) and back-end (BE). From OWA's point of view, the FE server was little more than a proxy. It accepted requests and forwarded them to the BE server. The BE handled all the business logic and rendered the UI. If you looked at the IIS metabase on an FE or BE server, you'd see three virtual directories normally associated with OWA:
/exchange: handles mailbox access requests for OWA and WebDAV
/public: handles requests for public folders
/exchweb: contains resource files used by OWA and WebDAV
If you accessed /exchange on an FE server, you would be prompted to enter your credentials and then proxied to /exchange on the BE server, which would serve up OWA.
Fast forward to 2007, where we made a great leap forward with Exchange. We did away with the FE and BE roles in favour of the CAS and Mailbox roles. The key difference between CAS and FE is that CAS contains the business logic and renders the OWA UI. This presented us with a challenge: how do we allow Exchange 2007 CAS servers to coexist with Exchange 2007 Mailbox and Exchange 2003/2000 Mailbox servers? The solution depends on how the server is configured.
First things first, though:
• If you intend to keep E2007 and E2003/2000 servers running side by side, we recommend that you keep the E2007 CAS and E2007 Mailbox servers on separate machines. If you want to combine CAS and Mailbox on a single server while still maintaining E2003/2000 servers, you will need to expose two URLs. One goes to the E2007 server (e.g., https://e2007.contoso.com/owa), while the other goes to the E2003/2000 servers (e.g., https://e2003.contoso.com/exchange).
• We don't support putting an Exchange 2003/2000 FE server in front of an Exchange 2007 Mailbox server. OWA 2007 also doesn't support Exchange 2007 public folders yet. Look for it in an Exchange 2007 Service Pack. In addition, you should replace all your E2003/2000 FE servers with E2007 CAS servers before moving your mailboxes to E2007 (see this page in Exchange 2007 documentation). Note that a CAS will require more powerful hardware than an FE server, so account for that in your planning (see this blog post for details).
If you look at IIS on CAS-only, Mailbox-only, and CAS+Mailbox servers, you'll see that they look very similar:
CAS-only /owa /exchange /public /exchweb
Mailbox-only /exchange /public
CAS+Mailbox - /owa /exchange /public /exchweb
Looks, in this case, are deceiving. /owa, which handles OWA 2007 business logic and UI rendering, is the only one that behaves the same wherever it appears. The remaining virtual directories, affectionately dubbed "legacy virtual directories", handle Exchange 2003/2000 and WebDAV requests. They work differently based on which server roles are installed.
By reserving /owa for OWA 2007, we made the Exchange 2007 legacy virtual directories analogous to Exchange 2003/2000 virtual directories. From the legacy virtual directory point of view, the CAS role acts like an Exchange 2003/2000 FE server. That is, it takes requests and proxies them to a BE server. The logic for this is in exprox.dll, which is applied as a scriptmap on the legacy virtual directories. Exprox doesn't do anything beyond proxy requests from the CAS to the Exchange 2007/2003/2000 Mailbox server.
All the intelligence for handling legacy requests lives in davex.dll, which is the scriptmap on the Mailbox server's legacy virtual directories. Davex contains logic for handling DAV requests, redirecting Exchange 2007 mailbox users to /owa, and serving up the Exchange 2003/2000 OWA experience. It is important to understand that exprox only directs traffic to davex on a mailbox server. Davex figures out what the right or the best server to use is.
There are two important caveats when working with davex:
1. Davex responds to both DAV and OWA requests. If you are pointing your browser to a URL, such as https://mail.company.com/exchange, and davex responds to it, it is treating it as an OWA request.
2. Davex will redirect a request based on the internal (intranet) name of the server. This means that users on the internet may receive a DNS error because the internal name of a server may not be the one that is exposed on the internet.
To understand how it all fits together, let's take a look at a few examples:
Example #1
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
All mailboxes are Exchange 2007
• Requests for /owa return the OWA 2007 experience
• Requests for /exchange: exprox proxies requests to /exchange on the Mailbox server, where davex redirects the user to /owa on the CAS
• Requests for /public: exprox proxies the user to /public on the Mailbox server. Davex then looks for an E2003 PF server but doesn't find one. It then returns an error message.
• Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them (more on this later)
Example #2
1 Exchange 2007 CAS-only server
1 Exchange 2003 BE server
All mailboxes on the BE server
• Requests for /owa returns the following error since there are no Exchange 2007 mailboxes.
Outlook Web Access could not find a mailbox for DOMAIN\USER. If the problem continues, contact technical support for your organization and tell them the following: The mailbox may be stored on a Microsoft Exchange 2000 or Microsoft Exchange 2003 server, or the Active Directory user account was created recently and has not yet replicated to the Active Directory site where this Client Access server is hosted.
• Requests for /exchange on the CAS are proxied to /exchange on the BE server, which returns the OWA 2003 experience
• Requests for /public on the CAS are proxied to /public on the BE server, which returns the OWA 2003 PF experience
• Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them
Example #3
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
1 Exchange 2003 BE server
Mailboxes on both Exchange 2007 and 2003 servers
If the your mailbox is on an E2007 server
• requests to /owa will return the OWA 2007 experience
• requests to /exchange on the CAS or Mailbox server will redirect the user to /owa. Authentication credentials transparently passed through.
• requests to /exchange on the BE will direct the user to the CAS, but the user may need to be authenticated again
• requests to /public will be directed to /public on the BE server
• requests to /exchweb will be directed to the BE server or return nothing
If your mailbox is on an E2003 server
• requests to /owa will yield the error message from Example 2
• requests to /exchange or /public on a CAS will be proxied by exprox to /exchange or /public on the BE server and yield the OWA 2003 experience
• requests to /exchange or /public on the BE server will yield the OWA 2003 experience
• requests to /exchweb will be directed to the BE server or return nothing
Example #4
1 Exchange 2007 CAS+Mailbox server
• requests for /owa yield the OWA 2007 experience
• requests for /exchange will be redirected by davex to /owa
• requests for /public will return an error since there are no E2003 PF servers
Example #5
1 Exchange 2007 CAS+Mailbox server
1 Exchange 2003 BE server
If your mailbox is on the E2007 server
• Requests to /owa will yield the OWA 2007 experience
• Requests to /exchange will redirect to /owa
• Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.
If your mailbox is on the E2003 server
• Requests to /owa will yield the Example 2 error message
• Requests to /exchange redirect to the E2003 server and yield the OWA 2003 experience
o If accessing /exchange on the E2007 server, you will need to reauthenticate after being redirected to the E2003 server
• Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.
/exchange: handles mailbox access requests for OWA and WebDAV
/public: handles requests for public folders
/exchweb: contains resource files used by OWA and WebDAV
If you accessed /exchange on an FE server, you would be prompted to enter your credentials and then proxied to /exchange on the BE server, which would serve up OWA.
Fast forward to 2007, where we made a great leap forward with Exchange. We did away with the FE and BE roles in favour of the CAS and Mailbox roles. The key difference between CAS and FE is that CAS contains the business logic and renders the OWA UI. This presented us with a challenge: how do we allow Exchange 2007 CAS servers to coexist with Exchange 2007 Mailbox and Exchange 2003/2000 Mailbox servers? The solution depends on how the server is configured.
First things first, though:
• If you intend to keep E2007 and E2003/2000 servers running side by side, we recommend that you keep the E2007 CAS and E2007 Mailbox servers on separate machines. If you want to combine CAS and Mailbox on a single server while still maintaining E2003/2000 servers, you will need to expose two URLs. One goes to the E2007 server (e.g., https://e2007.contoso.com/owa), while the other goes to the E2003/2000 servers (e.g., https://e2003.contoso.com/exchange).
• We don't support putting an Exchange 2003/2000 FE server in front of an Exchange 2007 Mailbox server. OWA 2007 also doesn't support Exchange 2007 public folders yet. Look for it in an Exchange 2007 Service Pack. In addition, you should replace all your E2003/2000 FE servers with E2007 CAS servers before moving your mailboxes to E2007 (see this page in Exchange 2007 documentation). Note that a CAS will require more powerful hardware than an FE server, so account for that in your planning (see this blog post for details).
If you look at IIS on CAS-only, Mailbox-only, and CAS+Mailbox servers, you'll see that they look very similar:
CAS-only /owa /exchange /public /exchweb
Mailbox-only /exchange /public
CAS+Mailbox - /owa /exchange /public /exchweb
Looks, in this case, are deceiving. /owa, which handles OWA 2007 business logic and UI rendering, is the only one that behaves the same wherever it appears. The remaining virtual directories, affectionately dubbed "legacy virtual directories", handle Exchange 2003/2000 and WebDAV requests. They work differently based on which server roles are installed.
By reserving /owa for OWA 2007, we made the Exchange 2007 legacy virtual directories analogous to Exchange 2003/2000 virtual directories. From the legacy virtual directory point of view, the CAS role acts like an Exchange 2003/2000 FE server. That is, it takes requests and proxies them to a BE server. The logic for this is in exprox.dll, which is applied as a scriptmap on the legacy virtual directories. Exprox doesn't do anything beyond proxy requests from the CAS to the Exchange 2007/2003/2000 Mailbox server.
All the intelligence for handling legacy requests lives in davex.dll, which is the scriptmap on the Mailbox server's legacy virtual directories. Davex contains logic for handling DAV requests, redirecting Exchange 2007 mailbox users to /owa, and serving up the Exchange 2003/2000 OWA experience. It is important to understand that exprox only directs traffic to davex on a mailbox server. Davex figures out what the right or the best server to use is.
There are two important caveats when working with davex:
1. Davex responds to both DAV and OWA requests. If you are pointing your browser to a URL, such as https://mail.company.com/exchange, and davex responds to it, it is treating it as an OWA request.
2. Davex will redirect a request based on the internal (intranet) name of the server. This means that users on the internet may receive a DNS error because the internal name of a server may not be the one that is exposed on the internet.
To understand how it all fits together, let's take a look at a few examples:
Example #1
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
All mailboxes are Exchange 2007
• Requests for /owa return the OWA 2007 experience
• Requests for /exchange: exprox proxies requests to /exchange on the Mailbox server, where davex redirects the user to /owa on the CAS
• Requests for /public: exprox proxies the user to /public on the Mailbox server. Davex then looks for an E2003 PF server but doesn't find one. It then returns an error message.
• Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them (more on this later)
Example #2
1 Exchange 2007 CAS-only server
1 Exchange 2003 BE server
All mailboxes on the BE server
• Requests for /owa returns the following error since there are no Exchange 2007 mailboxes.
Outlook Web Access could not find a mailbox for DOMAIN\USER. If the problem continues, contact technical support for your organization and tell them the following: The mailbox may be stored on a Microsoft Exchange 2000 or Microsoft Exchange 2003 server, or the Active Directory user account was created recently and has not yet replicated to the Active Directory site where this Client Access server is hosted.
• Requests for /exchange on the CAS are proxied to /exchange on the BE server, which returns the OWA 2003 experience
• Requests for /public on the CAS are proxied to /public on the BE server, which returns the OWA 2003 PF experience
• Requests for /exchweb: exprox either proxies them to /exchange or /public on the Mailbox server, or does nothing with them
Example #3
1 Exchange 2007 CAS-only server
1 Exchange 2007 Mailbox-only server
1 Exchange 2003 BE server
Mailboxes on both Exchange 2007 and 2003 servers
If the your mailbox is on an E2007 server
• requests to /owa will return the OWA 2007 experience
• requests to /exchange on the CAS or Mailbox server will redirect the user to /owa. Authentication credentials transparently passed through.
• requests to /exchange on the BE will direct the user to the CAS, but the user may need to be authenticated again
• requests to /public will be directed to /public on the BE server
• requests to /exchweb will be directed to the BE server or return nothing
If your mailbox is on an E2003 server
• requests to /owa will yield the error message from Example 2
• requests to /exchange or /public on a CAS will be proxied by exprox to /exchange or /public on the BE server and yield the OWA 2003 experience
• requests to /exchange or /public on the BE server will yield the OWA 2003 experience
• requests to /exchweb will be directed to the BE server or return nothing
Example #4
1 Exchange 2007 CAS+Mailbox server
• requests for /owa yield the OWA 2007 experience
• requests for /exchange will be redirected by davex to /owa
• requests for /public will return an error since there are no E2003 PF servers
Example #5
1 Exchange 2007 CAS+Mailbox server
1 Exchange 2003 BE server
If your mailbox is on the E2007 server
• Requests to /owa will yield the OWA 2007 experience
• Requests to /exchange will redirect to /owa
• Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.
If your mailbox is on the E2003 server
• Requests to /owa will yield the Example 2 error message
• Requests to /exchange redirect to the E2003 server and yield the OWA 2003 experience
o If accessing /exchange on the E2007 server, you will need to reauthenticate after being redirected to the E2003 server
• Requests to /public will likely yield an error because DAV will not redirect OWA requests to the E2003 PF server correctly.
Monday, October 5, 2009
How DSAccess service improves Exchange Server 2007 reliability
On my small network, DSAccess service chooses two domain controllers and one global catalog server to work with. However, on a larger network, the DSAccess service could choose up to 10 domain controllers and 10 global catalog servers. Why does Exchange 2007 need to work with so many Active Directory (AD) servers?
The answer has to do with stability. A server may occasionally fail, a router may go down or any number of other events can make an Exchange server temporarily inaccessible. By maintaining a list of multiple domain controllers and global catalog servers, Exchange can contact Active Directory in several ways if there is a problem contacting a server.
The DSAccess service is designed to perform specific tests every 15 minutes to make Exchange's Active Directory connectivity as reliable as possible. This makes Exchange aware of new domain controllers, changes to AD topology or even server failures and allows it to react accordingly.
The notion that Exchange can fall back on alternate domain controllers if one fails implies that some domain controllers are more important than others. Exchange designates one domain controller as the configuration domain controller. Exchange Server's configuration is written to this domain controller and then replicated to others.
Exchange is designed this way to prevent problems associated with replication latency. If contradictory configuration information was written to two different domain controllers, those controllers would begin replicating to other domain controllers. This would result in mass confusion. Designating a single domain controller to replicate Exchange configuration information solves this problem.
By default, the first domain controller that DSAccess is bound to during the initial dynamic detection process is designated as the configuration domain controller. You can designate a specific domain controller to act as the configuration controller, but I recommend allowing Exchange to choose which one to use. If you manually select a domain controller, Exchange won't automatically select a replacement configuration domain controller if the selected one fails.
If you're curious about which domain controller Exchange is using as a configuration domain controller, you can examine the Event Log entries. To do this, open the event logs and search for Event ID 2150.
The answer has to do with stability. A server may occasionally fail, a router may go down or any number of other events can make an Exchange server temporarily inaccessible. By maintaining a list of multiple domain controllers and global catalog servers, Exchange can contact Active Directory in several ways if there is a problem contacting a server.
The DSAccess service is designed to perform specific tests every 15 minutes to make Exchange's Active Directory connectivity as reliable as possible. This makes Exchange aware of new domain controllers, changes to AD topology or even server failures and allows it to react accordingly.
The notion that Exchange can fall back on alternate domain controllers if one fails implies that some domain controllers are more important than others. Exchange designates one domain controller as the configuration domain controller. Exchange Server's configuration is written to this domain controller and then replicated to others.
Exchange is designed this way to prevent problems associated with replication latency. If contradictory configuration information was written to two different domain controllers, those controllers would begin replicating to other domain controllers. This would result in mass confusion. Designating a single domain controller to replicate Exchange configuration information solves this problem.
By default, the first domain controller that DSAccess is bound to during the initial dynamic detection process is designated as the configuration domain controller. You can designate a specific domain controller to act as the configuration controller, but I recommend allowing Exchange to choose which one to use. If you manually select a domain controller, Exchange won't automatically select a replacement configuration domain controller if the selected one fails.
If you're curious about which domain controller Exchange is using as a configuration domain controller, you can examine the Event Log entries. To do this, open the event logs and search for Event ID 2150.
Subscribe to:
Posts (Atom)