Installing / Configuring Exchange 2010 in a multi-domain / hosting implementation
I want to describe the difficulties that an administrator may encounter when setting up Exchange for several domains. I will not go into the details of solving these problems, but I will describe in general terms how they should be solved and provide links to resources (Microsoft or Exchange experts blogs) where the solution of various difficulties is described in detail.
I try to embrace as many “subtleties” as possible, however I could forget something :)
Who cares - under cat. Warning: 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 correct attributes, which will further help the Exchange environment to function correctly.
• Security for each domain / client. This includes a huge variety of functions and settings, but if we talk simply - we need to make sure that users of one organization will not see users / data from another organization. This should be thought of right away when creating the AD infrastructure (for example, the hierarchy of OU and the rights to them).
• System settings and policies. Exchange has many functions available to users and administrators, and these functions can be managed in different ways. Some settings affect a single user, some on the database, and some on the entire Exchange organization.
• Transportation. The next item in the setting that 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 the same AD domain.
• Design and system architecture. Here I am trying to talk about names for services such as OWA; URLs that are 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) in order to avoid further problems.
• Scalable. Another key attribute is scalability. It is not only about the maximum number of domains / users, but also about calculating the load, predicting growth and identifying weak points in order to understand how to avoid problems.
Now I will try to say about each item in particular:
AD structure. There are several rules to follow:
1) Each domain is a separate OU.
2) All users of each domain - acc. group for this domain.
3) Use Active Directory List Object Mode . When you turn on the List Object Mode in the Security (Advanced) settings for each OU, you can set permissions on the List. It is here that we will need a group from the second point - only users of this domain can allow the List OU of a specific domain. This will allow to distinguish the visibility of objects.
')
Security for each domain / client. I already started to discuss this in the previous paragraph:
1) Use AD List Object Mode.
2) Using the modified Global Address List and Offline Address Book for each domain. To do this, you will need to create an Address Book Policy (which became available only in Exchange 2010 SP2). Mikhail Tokarev’s blog describes this process in detail .
3) Administration portals for administrators in each domain. In order for a certain user to be able to administer a specific group of Exchange users (via ECP), Role Groups mechanism was created in Microsoft. How to create role groups (where you will create a set of rights for administrators) is written here . However, when creating these roles, you will need to specify the Scope - zones to which they apply. As “zones” I recommend using OU (for each client - their own). You can read about creating such Management Scopes using PowerShell and the New-ManagementScope cmdlet.
4) I do not recommend giving permission to view Message Tracking Logs (delivery confirmation), because they are distributed to the entire organization and all mail will be visible to the Administrators.
5) Changing the 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 , take user access away from “Default”, but grant the necessary permissions to users of this domain.
6) Optional: Billing for customers. Unfortunately, billing mechanisms are not built into Exchange, but you can even create your own ones based on Excel. For statistics on mailboxes, I recommend that you familiarize yourself with the Get-MailboxStatistics and Get-ActivesyncDeviceStatistics cmdlets , using which (you can filter statistics for clients / domains using PowerShell), you can get the statistics and upload it to CSV / XLS.
7) I do not recommend including Outlook Protection Rules, since when Outlook Advanced Logging is enabled, data on the SMTP domains of all clients will be available.
8) Exchange databases. Many of those who have experience with Exchange will say that it is “more convenient” for each client to create their own database and store all the boxes of one domain in a separate database. But, if you do not have a good reason to do so, do not separate customers into databases. After all, in case of problems with 1 base - all domain mail will be unavailable, and this is unacceptable. Create several databases and use Automatic Mailbox Distribution and let Exchange choose which database to put the mailboxes on. You can read about how Automatic Mailbox Distribution works here .
System settings and policies. This item is very much "intersected" with the previous one, so here I will say not much.
1) Do not provide direct access to clients (LDAP + MAPI). It is a bad idea. Many hosters do this (for example, Masterhost), but I cannot agree with the correctness of such a decision. ONLY RPC over HTTPs (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 is guaranteed to relieve you of future problems.
2) Watch 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 input of passwords (otherwise it would 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, you need to limit the senders who have the right to send to the DG and require authentication to send to the DG. This can be configured via EMC or the Set-DistributionGroup cmdlet.
2) Limiting the size of letters. For example, the restriction on the size of incoming emails on the Edge server must be less than or equal to the limit set for internal mail. The opposite would be a waste of Edge server resources. Remember that using custom limits you can give a user or group of users more than 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 a “neighbor” domain. Of course, some information will remain in the headers, but you will ensure that the mail is received from the Internet, which in turn will prevent this sender from resolving to internal.
4) Remember that if you want to use Mutual TLS (what it is, you can read here ), the settings TLSRecieveDomainSecureList and TLSSendDomainSecureList are configured for the entire Exchange organization. And if you are going to offer this feature to customers, you will need to make sure that they understand why the “Safely” flag will be displayed on some letters that they will receive.
5) It is recommended to enable Anti-spam agents on Hub servers in order to check mail between domains. How to do it - is written here .
6) It is required to disable internal Out Of Office messages between domains. After all, if a user chooses to “send OOF only within my organization,” an OOF letter may go to the 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 particular class has OOF letters) only between the same domains (according to the rule per domain).
7) Disable some "tips" when sending emails. With a multi-domain structure, you will have to sacrifice some functionality, such as displaying group members and warnings that the recipient has an OOF auto answer, 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 nodes m.exchsuperhost.ru and m2.exchsuperhost.ru (for fault-tolerant EDGE - these will be MX with different priority), mail.exchsuperhost.ru (for client access and OutlookAnywhere) and autodiscover.exchsuperhost.ru for Autodiscover. Let your clients use CNAME for web interfaces and your MX addresses for MX and SPF records. This greatly simplifies mail administration and tracking.
2) I recommend not to give users access to POP and IMAP, because This can cause problems during migrations, as well as with users.
3) Think about virtualization. Microsoft has nothing against virtualizing certain Exchange roles. This will help reduce equipment costs and licenses.
Scalable. It all depends on your customers, equipment, etc. All I can advise is: don't use “outdated” technologies (such as Public Folders), count on “iron” capacities and space on storage and disk shelves, try to use dynamic distribution groups and automate your work as much as possible - 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 embrace as many “subtleties” as possible, however I could forget something :)
Who cares - under cat. Warning: 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 correct attributes, which will further help the Exchange environment to function correctly.
• Security for each domain / client. This includes a huge variety of functions and settings, but if we talk simply - we need to make sure that users of one organization will not see users / data from another organization. This should be thought of right away when creating the AD infrastructure (for example, the hierarchy of OU and the rights to them).
• System settings and policies. Exchange has many functions available to users and administrators, and these functions can be managed in different ways. Some settings affect a single user, some on the database, and some on the entire Exchange organization.
• Transportation. The next item in the setting that 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 the same AD domain.
• Design and system architecture. Here I am trying to talk about names for services such as OWA; URLs that are 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) in order to avoid further problems.
• Scalable. Another key attribute is scalability. It is not only about the maximum number of domains / users, but also about calculating the load, predicting growth and identifying weak points in order to understand how to avoid problems.
Now I will try to say about each item in particular:
AD structure. There are several rules to follow:
1) Each domain is a separate OU.
2) All users of each domain - acc. group for this domain.
3) Use Active Directory List Object Mode . When you turn on the List Object Mode in the Security (Advanced) settings for each OU, you can set permissions on the List. It is here that we will need a group from the second point - only users of this domain can allow the List OU of a specific domain. This will allow to distinguish the visibility of objects.
')
Security for each domain / client. I already started to discuss this in the previous paragraph:
1) Use AD List Object Mode.
2) Using the modified Global Address List and Offline Address Book for each domain. To do this, you will need to create an Address Book Policy (which became available only in Exchange 2010 SP2). Mikhail Tokarev’s blog describes this process in detail .
3) Administration portals for administrators in each domain. In order for a certain user to be able to administer a specific group of Exchange users (via ECP), Role Groups mechanism was created in Microsoft. How to create role groups (where you will create a set of rights for administrators) is written here . However, when creating these roles, you will need to specify the Scope - zones to which they apply. As “zones” I recommend using OU (for each client - their own). You can read about creating such Management Scopes using PowerShell and the New-ManagementScope cmdlet.
4) I do not recommend giving permission to view Message Tracking Logs (delivery confirmation), because they are distributed to the entire organization and all mail will be visible to the Administrators.
5) Changing the 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 , take user access away from “Default”, but grant the necessary permissions to users of this domain.
6) Optional: Billing for customers. Unfortunately, billing mechanisms are not built into Exchange, but you can even create your own ones based on Excel. For statistics on mailboxes, I recommend that you familiarize yourself with the Get-MailboxStatistics and Get-ActivesyncDeviceStatistics cmdlets , using which (you can filter statistics for clients / domains using PowerShell), you can get the statistics and upload it to CSV / XLS.
7) I do not recommend including Outlook Protection Rules, since when Outlook Advanced Logging is enabled, data on the SMTP domains of all clients will be available.
8) Exchange databases. Many of those who have experience with Exchange will say that it is “more convenient” for each client to create their own database and store all the boxes of one domain in a separate database. But, if you do not have a good reason to do so, do not separate customers into databases. After all, in case of problems with 1 base - all domain mail will be unavailable, and this is unacceptable. Create several databases and use Automatic Mailbox Distribution and let Exchange choose which database to put the mailboxes on. You can read about how Automatic Mailbox Distribution works here .
System settings and policies. This item is very much "intersected" with the previous one, so here I will say not much.
1) Do not provide direct access to clients (LDAP + MAPI). It is a bad idea. Many hosters do this (for example, Masterhost), but I cannot agree with the correctness of such a decision. ONLY RPC over HTTPs (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 is guaranteed to relieve you of future problems.
2) Watch 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 input of passwords (otherwise it would 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, you need to limit the senders who have the right to send to the DG and require authentication to send to the DG. This can be configured via EMC or the Set-DistributionGroup cmdlet.
2) Limiting the size of letters. For example, the restriction on the size of incoming emails on the Edge server must be less than or equal to the limit set for internal mail. The opposite would be a waste of Edge server resources. Remember that using custom limits you can give a user or group of users more than 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 a “neighbor” domain. Of course, some information will remain in the headers, but you will ensure that the mail is received from the Internet, which in turn will prevent this sender from resolving to internal.
4) Remember that if you want to use Mutual TLS (what it is, you can read here ), the settings TLSRecieveDomainSecureList and TLSSendDomainSecureList are configured for the entire Exchange organization. And if you are going to offer this feature to customers, you will need to make sure that they understand why the “Safely” flag will be displayed on some letters that they will receive.
5) It is recommended to enable Anti-spam agents on Hub servers in order to check mail between domains. How to do it - is written here .
6) It is required to disable internal Out Of Office messages between domains. After all, if a user chooses to “send OOF only within my organization,” an OOF letter may go to the 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 particular class has OOF letters) only between the same domains (according to the rule per domain).
7) Disable some "tips" when sending emails. With a multi-domain structure, you will have to sacrifice some functionality, such as displaying group members and warnings that the recipient has an OOF auto answer, 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 nodes m.exchsuperhost.ru and m2.exchsuperhost.ru (for fault-tolerant EDGE - these will be MX with different priority), mail.exchsuperhost.ru (for client access and OutlookAnywhere) and autodiscover.exchsuperhost.ru for Autodiscover. Let your clients use CNAME for web interfaces and your MX addresses for MX and SPF records. This greatly simplifies mail administration and tracking.
2) I recommend not to give users access to POP and IMAP, because This can cause problems during migrations, as well as with users.
3) Think about virtualization. Microsoft has nothing against virtualizing certain Exchange roles. This will help reduce equipment costs and licenses.
Scalable. It all depends on your customers, equipment, etc. All I can advise is: don't use “outdated” technologies (such as Public Folders), count on “iron” capacities and space on storage and disk shelves, try to use dynamic distribution groups and automate your work as much as possible - PowerShell scripts, transport rules, GAL, naming and storage policies.
I will be glad to answer your questions and listen to your advice :) Thank you!
Source: https://habr.com/ru/post/155751/
All Articles