Installing / Configuring Exchange 2010 in a Multi-Domain / Hosting Implementation
- Tutorial
I want to describe the difficulties that an administrator may encounter when setting up Exchange for multiple domains. I will not go into details of solving these problems, however, I will describe in general terms how to solve them and provide links to resources (Microsoft or the blogs of Exchange specialists) where a solution to various difficulties is described in detail.
I try to grasp as many “subtleties” as possible, but I could forget something :)
Who cares - under cat. Attention: a lot of letters!
First of all, it is worth mentioning the difficulties that we will encounter when implementing Exchange in the configuration described in the topic:
• Preparation and creation of objects.One of the most important points. You need to be sure that the objects are created correctly, in the right place and with the right attributes, which will further help the Exchange environment to function properly.
• Security for each domain / client. This includes a huge variety of functions and settings, but simply put, we need to make sure that users of one organization will not see users / data from another organization. You should think about this right away when creating an AD infrastructure (for example, the OU hierarchy and rights to them).
• System settings and policies.Exchange has many functions available to users and administrators, and these functions can be controlled in many ways. Some settings affect an individual user, some affect the database, and some affect the entire Exchange organization.
• Transport. The next item in the setting, which will affect all users, is transport. We are talking about problems when Exchange tries to route mail between two domains in the mode as if they are within the same organization, and tries to provide all the rich functionality that should be provided to users of one AD-domain.
• Design and architecture of the system.Here I am trying to talk about names for services such as OWA; URLs provided to clients with Outlook; Endpoints for services such as AutoDiscover and Outlook Anywhere. These / hostname addresses are visible to all clients and should not be tied to any of them (non-branded) to avoid further problems.
• Scalability. Another key attribute is scalability. This is not only about the maximum number of domains / users, but also about calculating the load, predicting growth and identifying weaknesses in order to understand how to avoid problems.
Now I will try to say about each item in particular:
AD structure. There are a few rules to follow:
1) Each domain is a separate OU.
2) All users of each domain - acc. group for this domain.
3) Using Active Directory List Object Mode . When you enable the List Object Mode in the Security (Advanced) settings for each OU, you can set the rights to the List. This is where we need the group from the second paragraph - only users of this domain can allow the List OU of a certain domain. This will allow to distinguish between the visibility of objects.
Security for each domain / client. I already started discussing this in the previous paragraph:
1) Using AD List Object Mode.
2) Using modified Global Address List and Offline Address Book for each domain. To do this, create an Address Book Policy (which became available only in Exchange 2010 SP2). The blog of Mikhail Tokarev describes this process in detail .
3) Administration portals for administrators in each domain. In order for a specific user to administer a specific group of Exchange users (through ECP), Microsoft created the Role Groups mechanism. How to create role groups (where you create a set of rights for administrators) is written here. However, when creating these roles, you will need to specify Scope - the zones to which they apply. I recommend using OU as a "zone" (for each client - its own). You can read about creating such Management Scopes using PowerShell and the New-ManagementScope cmdlet here .
4) I do not recommend giving rights to view Message Tracking Logs (delivery confirmation), as they apply to the entire organization and administrators will see all the mail.
5) Change of rights to calendars. By default, ALL Exchange users will see the Free / Busy status of ALL other Exchange users. Using the Set-MailboxFolderPermission cmdlet or utilities such as ExFolders, select access from the “Default” user, but grant the necessary permissions to users of this domain.
6) Optional: Billing for customers. Unfortunately, Exchange has no built-in billing mechanisms, however, you can even create your own based on Excel. To get statistics on mailboxes, I recommend that you familiarize yourself with the Get-MailboxStatistics and Get-ActivesyncDeviceStatistics cmdlets , using which (you can filter statistics by client / domain using PowerShell), you can get statistics and upload it to CSV / XLS.
7) I do not recommend including Outlook Protection Rules, as when Outlook Advanced Logging is enabled, data on the SMTP domains of all clients will be available.
8) Exchange bases. Many of those who have experience working with Exchange will say that it is “more convenient” for each client to create their own database and store all the mailboxes of the same domain in a separate database. But, if you have no good reason to do so, do not divide the clients into bases. Indeed, in case of problems with 1 database, all domain mail will be unavailable, which is unacceptable. Create several databases and use Automatic Mailbox Distribution and let Exchange choose which database to put the mailbox into. You can read about how Automatic Mailbox Distribution works here .
System Settings and Policies. This point is very “intersect” with the previous one, so here I will say a little.
1) It is not necessary to provide clients with direct access (LDAP + MAPI). It is a bad idea. Many hosters do this (for example, Masterhost), but I can not agree with the correctness of such a solution. RPC over HTTPs ONLY (especially in the next version of Exchange there is only such access). This type of access is a little more difficult in the initial setup, but it is guaranteed to save you from problems in the future.
2) Keep track of your firewall. For DDoS attacks, for possible bruteforce attacks. Do not leave network security for later.
3) I recommend disabling the “auto-blocking” policy of accounts in case of incorrect password entry (otherwise it will be very easy for an attacker to block an account), but be sure to use policies that require complex passwords from users.
Transport.
1) It is required to prohibit sending to Distribution groups from other domains. To do this, restrict senders who are allowed to send to DG and require authentication to send to DG. This can be configured through the EMC or the Set-DistributionGroup cmdlet .
2) Limiting the size of letters. For example, the size limit for incoming messages on the Edge server should be less than or equal to the limit set for internal mail. The converse will be a waste of Edge server resources. Remember that with user limits, you can let a user or group of users exceed the limits set for the entire Exchange organization.
3) Configure mail routing for "neighboring" domains through an external relay. This is required if you want to completely "mask" mail from domains on this Exchange, if they are sent to the "neighbor" domain. Of course, some information will remain in the headers, however, you will ensure that the mail is received from the Internet, which, in turn, will prevent this sender from being resolved internally.
4) Remember that if you want to use Mutual TLS (what it is, you can read here), the TLSRecieveDomainSecureList and TLSSendDomainSecureList settings are configured for the entire Exchange organization. And if you intend to offer this feature to customers, you will need to make sure that they understand why the “Safe” flag will be displayed on some letters that they will receive.
5) It is recommended that you enable Anti-Spam agents on Hub servers so that mail between domains is checked. How to do this is written here .
6) It is required to disable Out Of Office internal messages between domains. Indeed, if a user chooses to “send OOF only within my organization”, an OOF letter may go to a user of this Exchange, but from another domain. To prevent this, you need to create several transport rules that will allow messages of the IPM.Note.Rules.Oof.Template.Microsoft class (this class has OOF messages) only between the same domains (by the rule per domain).
7) Disable some "tips" when sending letters. With a multi-domain structure, you will have to sacrifice some functionality, such as displaying group members and warnings that the recipient has OOF auto answer enabled, etc. You can change these settings through the Set-OrganizationConfig cmdlet .
Design and architecture.
1) Use shared URLs. For example, register a domain exchsuperhost.ru . Create the nodes m.exchsuperhost.ru and m2.exchsuperhost.ru (for fault-tolerant EDGEs , these will be MX with different priorities), mail.exchsuperhost.ru (for client access and OutlookAnywhere) and autodiscover.exchsuperhost.ru for Autodiscover. Let your customers use CNAME for web interfaces and your MX addresses for MX and SPF records. This will greatly simplify the administration and tracking of mail.
2) I recommend not to provide users with POP and IMAP access, as this can create problems during migrations, as well as during user work.
3) Think about virtualization. Microsoft has nothing against virtualizing certain Exchange roles. This will help reduce equipment and license costs.
Scalability. It all depends on your customers, equipment, etc. All I can advise: do not use "outdated" technologies (such as Public Folders), calculate the "iron" capacities and storage space and disk shelves, try to use dynamic distribution groups and maximize your work - PowerShell scripts, transport rules, GAL, naming and storage policies.
I will be glad to answer your questions and listen to your advice :) Thank you!
I try to grasp as many “subtleties” as possible, but I could forget something :)
Who cares - under cat. Attention: a lot of letters!
First of all, it is worth mentioning the difficulties that we will encounter when implementing Exchange in the configuration described in the topic:
• Preparation and creation of objects.One of the most important points. You need to be sure that the objects are created correctly, in the right place and with the right attributes, which will further help the Exchange environment to function properly.
• Security for each domain / client. This includes a huge variety of functions and settings, but simply put, we need to make sure that users of one organization will not see users / data from another organization. You should think about this right away when creating an AD infrastructure (for example, the OU hierarchy and rights to them).
• System settings and policies.Exchange has many functions available to users and administrators, and these functions can be controlled in many ways. Some settings affect an individual user, some affect the database, and some affect the entire Exchange organization.
• Transport. The next item in the setting, which will affect all users, is transport. We are talking about problems when Exchange tries to route mail between two domains in the mode as if they are within the same organization, and tries to provide all the rich functionality that should be provided to users of one AD-domain.
• Design and architecture of the system.Here I am trying to talk about names for services such as OWA; URLs provided to clients with Outlook; Endpoints for services such as AutoDiscover and Outlook Anywhere. These / hostname addresses are visible to all clients and should not be tied to any of them (non-branded) to avoid further problems.
• Scalability. Another key attribute is scalability. This is not only about the maximum number of domains / users, but also about calculating the load, predicting growth and identifying weaknesses in order to understand how to avoid problems.
Now I will try to say about each item in particular:
AD structure. There are a few rules to follow:
1) Each domain is a separate OU.
2) All users of each domain - acc. group for this domain.
3) Using Active Directory List Object Mode . When you enable the List Object Mode in the Security (Advanced) settings for each OU, you can set the rights to the List. This is where we need the group from the second paragraph - only users of this domain can allow the List OU of a certain domain. This will allow to distinguish between the visibility of objects.
Security for each domain / client. I already started discussing this in the previous paragraph:
1) Using AD List Object Mode.
2) Using modified Global Address List and Offline Address Book for each domain. To do this, create an Address Book Policy (which became available only in Exchange 2010 SP2). The blog of Mikhail Tokarev describes this process in detail .
3) Administration portals for administrators in each domain. In order for a specific user to administer a specific group of Exchange users (through ECP), Microsoft created the Role Groups mechanism. How to create role groups (where you create a set of rights for administrators) is written here. However, when creating these roles, you will need to specify Scope - the zones to which they apply. I recommend using OU as a "zone" (for each client - its own). You can read about creating such Management Scopes using PowerShell and the New-ManagementScope cmdlet here .
4) I do not recommend giving rights to view Message Tracking Logs (delivery confirmation), as they apply to the entire organization and administrators will see all the mail.
5) Change of rights to calendars. By default, ALL Exchange users will see the Free / Busy status of ALL other Exchange users. Using the Set-MailboxFolderPermission cmdlet or utilities such as ExFolders, select access from the “Default” user, but grant the necessary permissions to users of this domain.
6) Optional: Billing for customers. Unfortunately, Exchange has no built-in billing mechanisms, however, you can even create your own based on Excel. To get statistics on mailboxes, I recommend that you familiarize yourself with the Get-MailboxStatistics and Get-ActivesyncDeviceStatistics cmdlets , using which (you can filter statistics by client / domain using PowerShell), you can get statistics and upload it to CSV / XLS.
7) I do not recommend including Outlook Protection Rules, as when Outlook Advanced Logging is enabled, data on the SMTP domains of all clients will be available.
8) Exchange bases. Many of those who have experience working with Exchange will say that it is “more convenient” for each client to create their own database and store all the mailboxes of the same domain in a separate database. But, if you have no good reason to do so, do not divide the clients into bases. Indeed, in case of problems with 1 database, all domain mail will be unavailable, which is unacceptable. Create several databases and use Automatic Mailbox Distribution and let Exchange choose which database to put the mailbox into. You can read about how Automatic Mailbox Distribution works here .
System Settings and Policies. This point is very “intersect” with the previous one, so here I will say a little.
1) It is not necessary to provide clients with direct access (LDAP + MAPI). It is a bad idea. Many hosters do this (for example, Masterhost), but I can not agree with the correctness of such a solution. RPC over HTTPs ONLY (especially in the next version of Exchange there is only such access). This type of access is a little more difficult in the initial setup, but it is guaranteed to save you from problems in the future.
2) Keep track of your firewall. For DDoS attacks, for possible bruteforce attacks. Do not leave network security for later.
3) I recommend disabling the “auto-blocking” policy of accounts in case of incorrect password entry (otherwise it will be very easy for an attacker to block an account), but be sure to use policies that require complex passwords from users.
Transport.
1) It is required to prohibit sending to Distribution groups from other domains. To do this, restrict senders who are allowed to send to DG and require authentication to send to DG. This can be configured through the EMC or the Set-DistributionGroup cmdlet .
2) Limiting the size of letters. For example, the size limit for incoming messages on the Edge server should be less than or equal to the limit set for internal mail. The converse will be a waste of Edge server resources. Remember that with user limits, you can let a user or group of users exceed the limits set for the entire Exchange organization.
3) Configure mail routing for "neighboring" domains through an external relay. This is required if you want to completely "mask" mail from domains on this Exchange, if they are sent to the "neighbor" domain. Of course, some information will remain in the headers, however, you will ensure that the mail is received from the Internet, which, in turn, will prevent this sender from being resolved internally.
4) Remember that if you want to use Mutual TLS (what it is, you can read here), the TLSRecieveDomainSecureList and TLSSendDomainSecureList settings are configured for the entire Exchange organization. And if you intend to offer this feature to customers, you will need to make sure that they understand why the “Safe” flag will be displayed on some letters that they will receive.
5) It is recommended that you enable Anti-Spam agents on Hub servers so that mail between domains is checked. How to do this is written here .
6) It is required to disable Out Of Office internal messages between domains. Indeed, if a user chooses to “send OOF only within my organization”, an OOF letter may go to a user of this Exchange, but from another domain. To prevent this, you need to create several transport rules that will allow messages of the IPM.Note.Rules.Oof.Template.Microsoft class (this class has OOF messages) only between the same domains (by the rule per domain).
7) Disable some "tips" when sending letters. With a multi-domain structure, you will have to sacrifice some functionality, such as displaying group members and warnings that the recipient has OOF auto answer enabled, etc. You can change these settings through the Set-OrganizationConfig cmdlet .
Design and architecture.
1) Use shared URLs. For example, register a domain exchsuperhost.ru . Create the nodes m.exchsuperhost.ru and m2.exchsuperhost.ru (for fault-tolerant EDGEs , these will be MX with different priorities), mail.exchsuperhost.ru (for client access and OutlookAnywhere) and autodiscover.exchsuperhost.ru for Autodiscover. Let your customers use CNAME for web interfaces and your MX addresses for MX and SPF records. This will greatly simplify the administration and tracking of mail.
2) I recommend not to provide users with POP and IMAP access, as this can create problems during migrations, as well as during user work.
3) Think about virtualization. Microsoft has nothing against virtualizing certain Exchange roles. This will help reduce equipment and license costs.
Scalability. It all depends on your customers, equipment, etc. All I can advise: do not use "outdated" technologies (such as Public Folders), calculate the "iron" capacities and storage space and disk shelves, try to use dynamic distribution groups and maximize your work - PowerShell scripts, transport rules, GAL, naming and storage policies.
I will be glad to answer your questions and listen to your advice :) Thank you!