With Exchange 2007 and the unified messaging coming up big time, I guess more and more IT'ers are reading into this in order to keep up with the new technologies.
Microsoft has put together a ZIP file that holds documents on all Exchange 2007 protocols, which can be downloaded at this link
The documentation is designed to describe each protocol in detail as it is used by the Microsoft Exchange Server system. Each protocol specification documents the technical requirements, limitations, dependencies, and Microsoft-specific protocol behavior.
The documentation also includes a set of companion overview and reference documents that supplement the technical specifications with conceptual background, overviews of inter-protocol relationships and interactions, and technical reference information, such as common data types and error codes.
Also, on Technet, a document has been published that describes best practices how to design storage for various needs: high-availabilty, high capacity, low cost, ...
Certainly very interesting to read: Storage Design
Monday, April 28, 2008
Wednesday, April 16, 2008
Domain Functional Levels: Overview
In connection to my previous post about the "AD Design Best Practices" and the project I worked on, the Domain Functional Level is a very important factor to choose which has major impacts on the domain.
I often get asked what the differences are between the different levels and, also in the classes I teach. Now except for the obvious ones: universal groups, group nesting and Kerberos authentication, I don't know the other improvements by heart.
If you want to know all the differences between the functional levels, here is a nice short overview table:
I often get asked what the differences are between the different levels and, also in the classes I teach. Now except for the obvious ones: universal groups, group nesting and Kerberos authentication, I don't know the other improvements by heart.
If you want to know all the differences between the functional levels, here is a nice short overview table:
AD Design: Best Practices
I've been working a few months ago on a AD design for a customer of the company I work for. The AD was not huge, but it was more than just a little 1 forest, 1 tree, 1 domain Active Directory. In the end, the short summary is a single forest, with a empty root domain and 2 child domains.
Of course, for this, lots of documentation need to be read (and created), lots of collaboration, meetings, ... You know, the usual stuff.
I have now created a summary of Best Practices of various documents I've read, which I think make up the ultimate "Best Practice" for AD Design.
These are just copy pastes of various, publicly available documents, so I'm not trying to take any credit for these great "Best Practices".
Forest Design Best Practices
The forest design process includes the following best practices:
• Identify the number of forests and write a justification for each one.
• Identify the number of trees and write a justification for each one.
• Wherever possible, create a Protected Forest Root Domain.
• Wherever possible, create a Single Global Child Domain for production in each tree.
• Identify the number of additional domains required in each tree.
• Identify the scope and contents of each domain.
• Justify each domain.
• Choose the generic name for each domain.
• Once the domain structure for the production forest is complete, design the domain structure for the other forests you created.
Naming Best Practices
Use the following best practices to name your AD forests:
• Use standard Internet characters. If they work on the Internet, they will definitely work in your network. Avoid accents and solely numeric names.
• Use 15 characters or less for each name.
• For the root name, use a simple, short name that is representative of the identity of the organization.
• Follow all DNS standards and make sure the internal DNS name is different from your
external name.
• Finally, before proceeding, buy the name.
Production OU Design Best Practices
Keep the following rules in mind when you create OU structures:
• Think in terms of equipment and objects in the directory.
• Determine how you will implement the administrative delegation process.
• Identify standards for all administrative categories in the organization.
• Use the administrative service or function or the line of business to name OUs. These tend to be more stable than organizational structure.
• Limit your structure to five levels, three if you are not responsible for the finalization of the structure. Recommend a maximum of five levels even though ten are possible. This gives you some breathing room.
• Remember the four reasons for the creation of OUs: categorization, administration, delegation, and segregation.
• Each OU you create must add value to the system.
• Never create an OU that does not contain any objects.
• Never create an OU that does not have a specific purpose.
• If an OU reaches an empty state, consider removing it. This may not be necessary because it may only be temporarily empty. If not, remove it.
• Identify an OU owner for each one you create. If no owner can be identified, remove the OU
• Justify all OUs you create.
• If you find that two OUs have the same purpose, merge them. This means that the combination of owner plus GPO plus delegation strategy is the same for both OUs.
• Use default OUs to administer the whole domain. Domain controllers should be kept in the DC OU. Domain Administrator accounts and groups should be kept in the Users OU. Domain Administrator PCs should be kept in the Computers OU.
• Use the production domain OU strategy to define the OU strategy for other domains and forests.
• Don’t forget to define and put in place standards for the recurring creation and deletion of OUs. These will help control the proliferation of OUs in your directory.
AD Integration Best Practices
Use the following best practices during this process:
• Active Directory should be the core directory service. AD can be modified through a graphical interface. You can also use scripts to perform massive modifications with AD. AD also supports a powerful delegation model. Finally, it supports PC management, something few directory services can perform.
• Use AD as your single point of interaction. AD provides a single point of interaction because it is a distributed database that uses a multimaster replication process. Users can modify data in any regional office and it will automatically be updated through the directory.
• If you need to maintain data integrity between multiple directories, use Microsoft
MetaDirectory Services with Active Directory as your primary data source.
• If you need to install NOS-related applications that modify the schema, add them to the forest root domain before creating the child domains.
• If you need to integrate in-house applications to the directory, use AD in Application Mode. This will have no impact on your NOS directory.
• Integrate NOS-related and other applications to AD only if it is absolutely required. Schema modifications can be retired and reused, but only through a complex process that will involve replication throughout your distributed NOS directory.
• Maintain your Active Directory as a NOS directory first and foremost. This will limit the amount of replication in the forest and will make it easier to upgrade to future versions of Windows server operating systems.
Service Positioning Best Practices
Use the following rules to design your Service Positioning scenario:
• In large AD structures, place the forest-wide Operation Masters in a Protect Forest Root Domain.
• If your forest spans multiple sites, place the Schema Master in one site and the Domain Naming Master in another.
• Carefully protect the access to the Schema Master role.
• Place the RID Master and the PDC Emulator roles on the same DC.
• Create a dedicated PDC Emulator role in domains that have more than 50,000 users.
• Separate Global Catalogs and Infrastructure Masters if you can.
• Place at least two domain controllers per domain.
• If a small domain spans two sites, use at least two domain controllers, one for each site.
• Place a Global Catalog server in each geographic site that contains at least one domain controller.
• Enable Universal group membership caching in each geographic site.
• Place a domain controller wherever there are more than ten users unless the WAN link speed will adequately support remote logon attempts
• Add a regional domain controller whenever there are more than 50 users per DC, especially if it is a multipurpose server.
• Install the Domain Naming Service on every domain controller.
• Use application partitions to designate DNS replication scopes.
Best Practices for Site Topology Design
Use the following best practices to design your site topology:
• Use the default configuration for inter-site replication.
• Do not disable the Knowledge Consistency Checker.
• Do not disable transitive trusts.
• Do not specify Bridgehead Servers.
• Calculate replication latency between sites.
• Create sites according to network topology; Site Links and WAN links should correspond.
• Make sure that no single site is connected to more than 20 other sites.
• Each site must host at least one DC.
• Do not use SMTP for domain-centric replication.
• Do not use SMTP replication if at all possible.
• Use 128 Kbps as the minimum WAN circuit for a Site Link.
• Associate every site with at least one subnet and one Site Link, otherwise it will be unusable.
• Create backup Site Links for each site. Assign higher costs to backup Site Links.
• Create Site Link Bridges wherever there are two hops between sites to reduce replication latency.
• If your available network bandwidth can afford it, ignore replication schedules in all sites. Replication will be performed when required with this option, but it will be more demanding on WAN bandwidth.
• Enable Universal Group Membership Caching in all sites.
• Use Preferred Bridgehead Servers only if replication must cross a firewall.
• Size your DCs accordingly.
• Monitor replication once your forest is in place to determine the impact on your WAN links.
Schema Modification Strategy Best Practices
Use the following schema modification best practices:
• Don’t make your own modifications to the schema unless they are absolutely necessary.
• Use AD primarily as a NOS directory.
• Use AD/AM to integrate applications.
• Use MMS 2003, Standard Edition to synchronize AD and AD/AM directories.
• Make sure all commercial products that will modify the schema are Windows Server 2003 Logo approved.
• Limit your initial modifications to modifications by commercial software.
• Create a Schema Change Policy Holder role early in the AD Implementation Process.
• Document the Schema Modification Policy and Process.
Enjoy!
Of course, for this, lots of documentation need to be read (and created), lots of collaboration, meetings, ... You know, the usual stuff.
I have now created a summary of Best Practices of various documents I've read, which I think make up the ultimate "Best Practice" for AD Design.
These are just copy pastes of various, publicly available documents, so I'm not trying to take any credit for these great "Best Practices".
Forest Design Best Practices
The forest design process includes the following best practices:
• Identify the number of forests and write a justification for each one.
• Identify the number of trees and write a justification for each one.
• Wherever possible, create a Protected Forest Root Domain.
• Wherever possible, create a Single Global Child Domain for production in each tree.
• Identify the number of additional domains required in each tree.
• Identify the scope and contents of each domain.
• Justify each domain.
• Choose the generic name for each domain.
• Once the domain structure for the production forest is complete, design the domain structure for the other forests you created.
Naming Best Practices
Use the following best practices to name your AD forests:
• Use standard Internet characters. If they work on the Internet, they will definitely work in your network. Avoid accents and solely numeric names.
• Use 15 characters or less for each name.
• For the root name, use a simple, short name that is representative of the identity of the organization.
• Follow all DNS standards and make sure the internal DNS name is different from your
external name.
• Finally, before proceeding, buy the name.
Production OU Design Best Practices
Keep the following rules in mind when you create OU structures:
• Think in terms of equipment and objects in the directory.
• Determine how you will implement the administrative delegation process.
• Identify standards for all administrative categories in the organization.
• Use the administrative service or function or the line of business to name OUs. These tend to be more stable than organizational structure.
• Limit your structure to five levels, three if you are not responsible for the finalization of the structure. Recommend a maximum of five levels even though ten are possible. This gives you some breathing room.
• Remember the four reasons for the creation of OUs: categorization, administration, delegation, and segregation.
• Each OU you create must add value to the system.
• Never create an OU that does not contain any objects.
• Never create an OU that does not have a specific purpose.
• If an OU reaches an empty state, consider removing it. This may not be necessary because it may only be temporarily empty. If not, remove it.
• Identify an OU owner for each one you create. If no owner can be identified, remove the OU
• Justify all OUs you create.
• If you find that two OUs have the same purpose, merge them. This means that the combination of owner plus GPO plus delegation strategy is the same for both OUs.
• Use default OUs to administer the whole domain. Domain controllers should be kept in the DC OU. Domain Administrator accounts and groups should be kept in the Users OU. Domain Administrator PCs should be kept in the Computers OU.
• Use the production domain OU strategy to define the OU strategy for other domains and forests.
• Don’t forget to define and put in place standards for the recurring creation and deletion of OUs. These will help control the proliferation of OUs in your directory.
AD Integration Best Practices
Use the following best practices during this process:
• Active Directory should be the core directory service. AD can be modified through a graphical interface. You can also use scripts to perform massive modifications with AD. AD also supports a powerful delegation model. Finally, it supports PC management, something few directory services can perform.
• Use AD as your single point of interaction. AD provides a single point of interaction because it is a distributed database that uses a multimaster replication process. Users can modify data in any regional office and it will automatically be updated through the directory.
• If you need to maintain data integrity between multiple directories, use Microsoft
MetaDirectory Services with Active Directory as your primary data source.
• If you need to install NOS-related applications that modify the schema, add them to the forest root domain before creating the child domains.
• If you need to integrate in-house applications to the directory, use AD in Application Mode. This will have no impact on your NOS directory.
• Integrate NOS-related and other applications to AD only if it is absolutely required. Schema modifications can be retired and reused, but only through a complex process that will involve replication throughout your distributed NOS directory.
• Maintain your Active Directory as a NOS directory first and foremost. This will limit the amount of replication in the forest and will make it easier to upgrade to future versions of Windows server operating systems.
Service Positioning Best Practices
Use the following rules to design your Service Positioning scenario:
• In large AD structures, place the forest-wide Operation Masters in a Protect Forest Root Domain.
• If your forest spans multiple sites, place the Schema Master in one site and the Domain Naming Master in another.
• Carefully protect the access to the Schema Master role.
• Place the RID Master and the PDC Emulator roles on the same DC.
• Create a dedicated PDC Emulator role in domains that have more than 50,000 users.
• Separate Global Catalogs and Infrastructure Masters if you can.
• Place at least two domain controllers per domain.
• If a small domain spans two sites, use at least two domain controllers, one for each site.
• Place a Global Catalog server in each geographic site that contains at least one domain controller.
• Enable Universal group membership caching in each geographic site.
• Place a domain controller wherever there are more than ten users unless the WAN link speed will adequately support remote logon attempts
• Add a regional domain controller whenever there are more than 50 users per DC, especially if it is a multipurpose server.
• Install the Domain Naming Service on every domain controller.
• Use application partitions to designate DNS replication scopes.
Best Practices for Site Topology Design
Use the following best practices to design your site topology:
• Use the default configuration for inter-site replication.
• Do not disable the Knowledge Consistency Checker.
• Do not disable transitive trusts.
• Do not specify Bridgehead Servers.
• Calculate replication latency between sites.
• Create sites according to network topology; Site Links and WAN links should correspond.
• Make sure that no single site is connected to more than 20 other sites.
• Each site must host at least one DC.
• Do not use SMTP for domain-centric replication.
• Do not use SMTP replication if at all possible.
• Use 128 Kbps as the minimum WAN circuit for a Site Link.
• Associate every site with at least one subnet and one Site Link, otherwise it will be unusable.
• Create backup Site Links for each site. Assign higher costs to backup Site Links.
• Create Site Link Bridges wherever there are two hops between sites to reduce replication latency.
• If your available network bandwidth can afford it, ignore replication schedules in all sites. Replication will be performed when required with this option, but it will be more demanding on WAN bandwidth.
• Enable Universal Group Membership Caching in all sites.
• Use Preferred Bridgehead Servers only if replication must cross a firewall.
• Size your DCs accordingly.
• Monitor replication once your forest is in place to determine the impact on your WAN links.
Schema Modification Strategy Best Practices
Use the following schema modification best practices:
• Don’t make your own modifications to the schema unless they are absolutely necessary.
• Use AD primarily as a NOS directory.
• Use AD/AM to integrate applications.
• Use MMS 2003, Standard Edition to synchronize AD and AD/AM directories.
• Make sure all commercial products that will modify the schema are Windows Server 2003 Logo approved.
• Limit your initial modifications to modifications by commercial software.
• Create a Schema Change Policy Holder role early in the AD Implementation Process.
• Document the Schema Modification Policy and Process.
Enjoy!
Wednesday, April 09, 2008
Message hygiene in Exchange 2003 & Exchange 2007
Message hygiene is nothing more than a fancy expression that Microsoft uses when they mean techniques to defend your Exchange environment against spam, virusses and other e-mail attacks.
Below is a short overview of the various components that are natively available to you for the job of hardening your Exchange 2003 system:
Filtering:
- Connection filtering: Filters inbound messages by comparing their IP address against a block list provided by a third-party real-time block list service. You can also enter your own set of accepted/restricted IP addresses at a global level.
- Sender filtering: By default, SMTP connections that are created by senders on this list are dropped.
- Recipient filtering: Allows you to set global restrictions on mail to specific recipients.
These filtering options can be specified under the Global Settings of your Exchange Organization and choose for Message Delivery.
Restricted Distribution Lists
As you are aware, there are probably DL's in your organization that hold all contacts or at least divided per department.
By default, all users can use these DL's to send e-mails to. That's not just dangerous from an internal user point of view (a typing/clicking mistake is quickly made), but of course, hackers love this even more ...
You can restrict access to these DL's based on userID's. To do this, open the AD Users & Computers snap-in, browse to the DL and on the properties specify the "message Restrictions".
Intelligent Message Filtering (IMF)
Based on the characteristics of millions of messages, Intelligent Message Filter can accurately assess the probability that an incoming e-mail message is either a legitimate message or UCE(Unsolicited Commercial Email).
Based on the probability that the message is UCE, IMF rates it with a property called a spam confidence level (SCL).
You can specify 2 thresholds, the gateway threshold and the mailbox threshold, on the SCL that determine what is done with the incoming e-mail. If the e-mail has a rating equal or greater than the gateway threshold, your specified action is taken.
If the rating is lower than the mailbox threshold, the mail is delivered, if the rating is greater it is delivered to the junk inbox.
Anti-virus
In Exchange 2003 there is not a built-in protection against virusses, but there is a anti-virus framework that is used by third-party companies, such as McAfee, TrendMicro, Kaspersky, ...
Address Spoofing Protection
By default, Exchange 2003 preserves the original SMTP message submission method and does not resolve the sender's address if the SMTP submission is anonymous. If the original message was submitted without authentication, Exchange 2003 marks the message as un-authenticated and, in this case, the sender's address is not resolved to the GAL display name (in the From line), instead it is displayed to the recipient in its SMTP format (for example, whatever@duh.euh).
Another mechanism you can use is to configure your SMTP virtual server to perform a reverse DNS lookup on incoming e-mail messages, verifying that the IP address and fully qualified domain name (FQDN) of the sender's mail server corresponds to the domain name listed in the message.
However, consider the following limitations to reverse DNS lookups:
- The sender's IP address may not be in the reverse DNS lookup record, or the sending server may have multiple names for the same IP, not all of which may be available from the reverse DNS lookup record.
- Reverse DNS lookups place an additional load on the Exchange server.
- Reverse DNS lookups require that the Exchange server is able to contact the reverse lookup zones for the sending domain.
- Performing reverse DNS lookups on each message can result in a substantial decrease in performance due to increased latency.
Tar pitting
SMTP tar pitting is the practice of artificially delaying server responses for certain SMTP communication patterns and it's used to help fight spam attacks, such as Directory Harvest Attack (DHA).
If a hacker guesses all the possible recipients in a domain, he will receive a bunch of "550 User unknown" messages to the non-existing addresses. So the other addresses are valid. A DHA attack with 4 caracters can be done in 20 minutes, if you delay the SMTP replies with 5 seconds, it will take several months!
With Exchange 2007, these roles have been moved to an "Edge Transport Server". This Exchange 2007 server role can not be combined with other roles and should be done on a server that is not part of your domain and resides in your DMZ. It's obvious this way of doing things is still much better since spam and virusses won't be entering your network at any point.
This in combination with the Forefront security for Exchange 2007 for anti-virus and anti-spam, your users will complain a lot less about spam and you will have to worry less about virusses entering your network.
Of course, the threat will always stay, hackers find always find a way ...
Below is a short overview of the various components that are natively available to you for the job of hardening your Exchange 2003 system:
Filtering:
- Connection filtering: Filters inbound messages by comparing their IP address against a block list provided by a third-party real-time block list service. You can also enter your own set of accepted/restricted IP addresses at a global level.
- Sender filtering: By default, SMTP connections that are created by senders on this list are dropped.
- Recipient filtering: Allows you to set global restrictions on mail to specific recipients.
These filtering options can be specified under the Global Settings of your Exchange Organization and choose for Message Delivery.
Restricted Distribution Lists
As you are aware, there are probably DL's in your organization that hold all contacts or at least divided per department.
By default, all users can use these DL's to send e-mails to. That's not just dangerous from an internal user point of view (a typing/clicking mistake is quickly made), but of course, hackers love this even more ...
You can restrict access to these DL's based on userID's. To do this, open the AD Users & Computers snap-in, browse to the DL and on the properties specify the "message Restrictions".
Intelligent Message Filtering (IMF)
Based on the characteristics of millions of messages, Intelligent Message Filter can accurately assess the probability that an incoming e-mail message is either a legitimate message or UCE(Unsolicited Commercial Email).
Based on the probability that the message is UCE, IMF rates it with a property called a spam confidence level (SCL).
You can specify 2 thresholds, the gateway threshold and the mailbox threshold, on the SCL that determine what is done with the incoming e-mail. If the e-mail has a rating equal or greater than the gateway threshold, your specified action is taken.
If the rating is lower than the mailbox threshold, the mail is delivered, if the rating is greater it is delivered to the junk inbox.
Anti-virus
In Exchange 2003 there is not a built-in protection against virusses, but there is a anti-virus framework that is used by third-party companies, such as McAfee, TrendMicro, Kaspersky, ...
Address Spoofing Protection
By default, Exchange 2003 preserves the original SMTP message submission method and does not resolve the sender's address if the SMTP submission is anonymous. If the original message was submitted without authentication, Exchange 2003 marks the message as un-authenticated and, in this case, the sender's address is not resolved to the GAL display name (in the From line), instead it is displayed to the recipient in its SMTP format (for example, whatever@duh.euh).
Another mechanism you can use is to configure your SMTP virtual server to perform a reverse DNS lookup on incoming e-mail messages, verifying that the IP address and fully qualified domain name (FQDN) of the sender's mail server corresponds to the domain name listed in the message.
However, consider the following limitations to reverse DNS lookups:
- The sender's IP address may not be in the reverse DNS lookup record, or the sending server may have multiple names for the same IP, not all of which may be available from the reverse DNS lookup record.
- Reverse DNS lookups place an additional load on the Exchange server.
- Reverse DNS lookups require that the Exchange server is able to contact the reverse lookup zones for the sending domain.
- Performing reverse DNS lookups on each message can result in a substantial decrease in performance due to increased latency.
Tar pitting
SMTP tar pitting is the practice of artificially delaying server responses for certain SMTP communication patterns and it's used to help fight spam attacks, such as Directory Harvest Attack (DHA).
If a hacker guesses all the possible recipients in a domain, he will receive a bunch of "550 User unknown" messages to the non-existing addresses. So the other addresses are valid. A DHA attack with 4 caracters can be done in 20 minutes, if you delay the SMTP replies with 5 seconds, it will take several months!
With Exchange 2007, these roles have been moved to an "Edge Transport Server". This Exchange 2007 server role can not be combined with other roles and should be done on a server that is not part of your domain and resides in your DMZ. It's obvious this way of doing things is still much better since spam and virusses won't be entering your network at any point.
This in combination with the Forefront security for Exchange 2007 for anti-virus and anti-spam, your users will complain a lot less about spam and you will have to worry less about virusses entering your network.
Of course, the threat will always stay, hackers find always find a way ...
Thursday, April 03, 2008
MSExchange System Attendant Mailbox: Error 4001: Exchange 2007 on DC with GC
At home, in my test environment I've installed an Exchange 2007 on a Domain Controller that is also a Global Catalog. A little preparation made sure of an easy installation, but everytime I restarted my Domain Controller, Exchange services would not come up correctly and error events were logged in my Application eventlog.
More specifically:MSExchange System Attendant Mailbox EventID 4001
A bunch of information that still gives every vage inside.
With a little searching online I found this Microsoft article.
The cause for these errors is located in the fact that several Exchange server dependent services are still starting when Exchange 2007 tries to start.
You can keep starting the services manually or add some registry keys to delay the startup a specific number of seconds as described in the article.
More specifically:MSExchange System Attendant Mailbox EventID 4001
A bunch of information that still gives every vage inside.
With a little searching online I found this Microsoft article.
The cause for these errors is located in the fact that several Exchange server dependent services are still starting when Exchange 2007 tries to start.
You can keep starting the services manually or add some registry keys to delay the startup a specific number of seconds as described in the article.
Subscribe to:
Posts (Atom)
