Active Directory planning and design
It's important to know how to design a plan to implement Active Directory. You should always fully document your intended domains, forests, organizational units, sites, DNS infrastructure and security strategies. This documentation becomes the plan for your new infrastructure when you make the migration.
The basics of Active Directory planning
When you are performing an Active Directory migration, you basically have two options: domain upgrading or domain restructuring. Domain upgrading is little more than upgrading each existing Windows domain controller to a more current Windows domain controller. The upgrade process starts by upgrading the PDCs in each domain, followed by the BDCs. Domain restructuring involves creating an Active Directory network from scratch. In a restructure, you will move systems and reroute connections to comply with a new infrastructure and layout design. Often restructuring will result in fewer but larger domains.
So the question becomes, "Should you upgrade or restructure?"
Deciding which path to take, or which process to perform first, all depends on your specific situation. But there are a few guidelines that can help you make the choice.
First, if your current domain structure is supporting your work tasks and doesn't seem to involve an inordinate amount of extraneous administration, then upgrading may be preferable. However, if the current domain structure is not adequate and is the primary motivation for the migration, restructuring is likely the way to go. Secondly, if you must support the production environment throughout the migration process, upgrading will retain overall network functionality and therefore is preferable. But if you can afford to lose productivity during the migration, restructuring is better. However, restructuring can be performed on a staggered schedule so no significant loss of productivity is noticed.
Rememeber that while upgrading will cause the least downtime in terms of getting the domain back into working order, it often is an insufficient migration. Many of the benefits of Windows 2000 and Windows 2003-based Active Directory domains cannot be fully realized without reconfiguring the design of your network. Restructuring will require significant work to implement, but it makes reaping the benefits of Active Directory easier to exploit for your organization.
Developing an Active Directory migration strategy
When taking on an Active Directory migration project, like with all large projects, it's best to have a strategy in place. It is key to create an Active Directory migration checklist, with steps such as collecting diagrams and configuration of the current DNS and network structure (bandwidth, remote locations, stability, etc.), determining the rights, objects and policies that will need to be migrated, and creating fall back procedures in case of failure.
Another part of developing your migration strategy, is being aware of the key things you should and should not do when performing an Active Directory migration.
For starters , it's important to make sure that your support staff is brought up to speed before you begin migrating any production system. Depending on the size and structure of your organization, you should have a help desk staff taking support calls. For a complex project like Active Directory, it's a good idea to make a couple of network engineers available as well. Be sure to train all members of the support staff involved in the process. Otherwise, you'll have IT staff fielding questions that they don't know how to answer, and frustration will abound on all sides.
You should also establish a test bed that mimics your production environment as closely as possible in terms of hardware specifications and network speed. Leave nothing to chance in the testing phase. Speaking of testing, be sure to test name resolution and replication before deploying Active Directory in production. Unlike replication under NT4, Active Directory replication is possibly the single most important item required for AD to function correctly. Second only to file replication for a solid Active Directory implementation is name resolution. Whether you are deploying WINS or DNS, ensure that all systems that need to can effectively talk to one another.
Designing Active Directory simply
Active Directory is very flexible. So flexible that you can design an Active Directory forest that is complex beyond imagination. Both Windows 2000 Server and Windows Server 2003 support the Active Directory containers of forest, domain, site, and organizational unit (OU). With the only real restriction of one forest per namespace, you can deploy as many domains, sites, and OUs as you deem necessary.
However, don't be so fast to rush off and design an Active Directory network that includes a domain for every department in your enterprise. The key to Active Directory design is simplicity. As a general rule, you want to keep the number of domains to a minimum whenever possible. If you really need department level divisions on your network that reflect the organization of your business, then use OUs instead. OUs are much more flexible and easier overall to manage than domains.
If you are migrating from a Windows NT 4.0 network to a Windows 2000 Server or Windows Server 2003 Active Directory network, compare the number of domains from your existing legacy system and compare that with the number of domains in your new AD-based design. If your new Active Directory network has more domains than your legacy network, you may need to re-think your design. Yes, it is possible to use as many domains as you wish, but you'll likely regret that decision down the line. If you need lots of groupings and divisions, it is best to rely upon OUs.
Active Directory domain design
When you are designing your Active Directory network, it is important to use the four divisions (forests, domains, organizational units, and sites) to their maximum potential. This is especially true for Active Directory domain design.
Domain divisions are most often used as logical containers. However, Microsoft recommends that you employ domains also as physical containers. In other words, create domains whose members are all geographically close rather than distant. This is an important design aspect since the level of traffic within a domain is considerably higher than that between one domain and another. In general, a domain with limited physical size is less likely to include expensive WAN links or pay-per-bit connections. When slow links must be included in a network design, it is often beneficial to create multiple domains connected by the slower connections.
Remember that it is not necessary to create separate domains to divide administrative privileges. Within Active Directory, it is possible to delegate administrative privileges based on organizational units.
Designing groups and organizational units
With the proper preparation and advance knowledge of their use, a functional organizational unit (OU) and group design can do wonders to simplify your Active Directory environment. It can also go a long way toward helping you gain control and reduce overhead.
Often, OUs are indiscriminately used without reason, and group structure is ineffectual and confusing. Without some form of logical organization of users within your network environment, chaos reigns and administration grinds to a halt. Some best practices when designing OUs include:
Keep the OU structure as simple as possible
Do not nest OUs more than 10 layers deep
Keep the number of OUs to a minimum
Apply Group Policy to groups through Group Policy filtering
Don't utilize local groups for permissions in a domain environment
Use domain local groups to control access to resources, and use global groups to organize similar groups of users.
You also have the option of hiding your OUs. The primary purpose of hidden OUs is to prevent an administrator from one OU from being able to view, access, or alter another OU. Hidden OUs are often used in environments that offer network application services to internal departments or external customers. It allows for a solid separation of duties without requiring separate domains or forests.
Design rules for Active Directory sites
Sites are an extremely useful design element for Active Directory domains. Sites are limited to any computer object within a forest. Thus, they can cross domains and organizational units (OUs) with indifference. An object's membership in a domain or OU does not exclude simultaneous membership in a site. Sites are used to impose physical network divisions for the purpose of traffic flow.
By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links. This can result in more efficient traffic flow for productivity tasks. It can also serve to keep WAN link costs down on the pay-by-the-bit services.
In general, when designing sites, keep the following in mind:
Sites should generally reflect the physical or geographic topology of the network.
Each site should contain at least one local DC.
Sites should not contain slow links of any type.
Remote-access clients do not need a dedicated site.
Sites should be used whenever control over replication traffic is needed or desired.
Sites can be added, removed, changed, and moved easily without affecting any other AD container configuration.
Friday, July 17, 2009
Avoiding Active Directory security breaches
Avoiding Active Directory security breaches
The importance of protecting your Active Directory has already been touched on in reference to DNS security. However, that is just the tip of the iceberg when it comes to maintaining a secure environment.
As far as Active Directory security best practices go, layered security is the best method to use when planning and designing a security solution. Layered security or defense in depth is the simple concept of placing your valued assets at the center of your environment and building or deploying multiple concentric circles or rings of protection around those assets. Thus, violations to confidentiality, integrity, or availability must overcome numerous security restrictions, precautions, and protections before being able to affect your assets.
While Microsoft has increased the default security within Active Directory (especially if you have a Windows Server 2003 Active Directory installation), you still need to consider additional security settings after it is installed.
Securing your domain controllers
One of the first steps you should take involves developing a solid domain controller security policy. Protecting your domain controllers is at the core of protecting your Active Directory investment. Without your domain controllers you won't have your Active Directory network infrastructure. With exposed and unprotected domain controllers you also are at risk for attackers to enumerate shared folders and usernames, giving up valuable information that can be used to further attack the network.
Therefore, it is critical that domain controllers are running and protected in order for the Active Directory environment to remain functioning and stable. To protect domain controllers, you should consider the following areas of security protection: physical access (keeping DCs in a secure location that is only accessible by the IT staff) and network access (protecting DCs from those who might attack your network).
As an administrator, you need to be concerned with making sure internal users have proper access and that potential intruders are frustrated in their attempts to compromise a DC. One danger is for a person to be physically in the room and touch a DC even without any rights granted to them. Thus, if a person has physical access, he or she owns your computer, since physical access grants them control. Keeping DCs in a secure location is a simple way to ensure Active Direcotry security, but it is often overlooked.
As far as network access is concerned, it is important not to give domain admin privileges to someone who isn't skilled enough to handle the job or to someone you're not sure you can trust. Anyone with the ability to install/modify system files, including services/drivers (such as server operators, backup operators or print operators) owns your computer. There are many ways for this to happen. Naturally, a secure account could be compromised, giving the intruder the rights to do this, but a valid holder of these rights could cause harm unintentionally by installing an application without testing it first.
How well you handle Microsoft patch emergencies and updates is also key to the security of your DCs. You should always deploy the same patches on all domain controllers. DCs should be kept as close to mirror images of each other as possible, at least in terms of the OS configuration. This will help eliminate incompatibilities, lost or corrupted data and replication errors.
However, it is important not to patch just because Microsoft offers a patch. Every patch needs to be tested in your environment for relevance and reliability. If you don't need it, don't install it. Patches can damage your environment if the install fails to perform perfectly. You don't want to place your DCs at risk if you can avoid it.
Kerberos security with Microsoft
With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol. Not only was it much more secure and efficient than NTLM (which was used prior), but it also plays nicely with other operating systems such as Unix.
Before learning how Kerberos works in the world of Windows, it's best to first understand normal Kerberos authentication and authorization.
Authentication is the process of presenting credentials (username/password) to a service and having that service validate you. It works like this. When a user enters his or her username/password in a Kerberos environment, that information is sent to a server running the Authentication Service. The Authentication Service passes that information to a database called the Key Distribution Center (KDC). If the username/password checks out, the Authentication Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the logon process. The TGT contains a time stamp, the public key and a certificate.
Authorization is the process of granting access to resources on a server that is in the network. Continuing from the authentication discussion, once the client gets the TGT, the client can then request access to resources. The TGT is presented to the Ticket Granting Service and requests a session ticket to access a resource on, say, Server 1. If Server 1 is in the domain, the Ticket Granting Service sees that there is a valid TGT, so credentials check out, and a session ticket is granted for Server 1. The client then presents the session ticket to Server 1 for access to a resource such as a printer, file share or document. Server 1 will then check access rights on that resource to see what the user can do (read, write, etc.).
In a Windows domain, all of the Kerberos-related services just described are held by each domain controller. When a user presents credentials for authentication in a Windows domain, the same Kerberos authentication process described above is used -- with one exception. In order to find a domain controller that is also the KDC, a client must use the DC Locator process, which requires a DNS server to locate an appropriate DC and send that information back to the client. The client then passes the credentials to the domain controller, which grants the TGT and then a session ticket if the server to be accessed is in the DC's domain. The access rights are checked by the server and granted to the client.
Group Policy security settings
One of the most important steps toward Active Directory security involves Group Policy security settings. With almost 1,800 policy settings in a single Group Policy Object (GPO), it is no wonder they provide so much power, control, security, and management over an Active Directory enterprise.
There are two default GPOs in every Active Directory domain. These default GPOs are there for very distinct reasons and should be investigated to ensure they are configured properly to provide the best security for your company network. The first default GPO is the Default Domain Policy. This GPO is responsible for establishing and maintaining the account policies for the domain user accounts, which are essential for helping secure the domain user account passwords.
The second default GPO is the Default Domain Controller Policy. This GPO is responsible for establishing the baseline security for all domain controllers in the domain. The primary security settings that are established in the GPO are the user rights. Common user rights include:
Allowing a user to logon using the keyboard attached to the computer (locally)
Changing the system time
Backing up files and folders
Accessing the computer and its resources over a network
However, every network running Active Directory should have more than just the default two GPOs. The reason is that Group Policy provides an automated, centralized method for configuring and deploying security settings to all computers and users within the domain. Some common security related settings and areas of configuration include the ability to restrict which applications can be run on each computer, use IP Security to encrypt data between computers, restrict anonymous connections to computers and audit policy settings per computer.
Remember that there are several network security attacks that can be easily avoided with Group Policy, including simple steps for Kerberos configuration, so be sure to take advantage.
The importance of protecting your Active Directory has already been touched on in reference to DNS security. However, that is just the tip of the iceberg when it comes to maintaining a secure environment.
As far as Active Directory security best practices go, layered security is the best method to use when planning and designing a security solution. Layered security or defense in depth is the simple concept of placing your valued assets at the center of your environment and building or deploying multiple concentric circles or rings of protection around those assets. Thus, violations to confidentiality, integrity, or availability must overcome numerous security restrictions, precautions, and protections before being able to affect your assets.
While Microsoft has increased the default security within Active Directory (especially if you have a Windows Server 2003 Active Directory installation), you still need to consider additional security settings after it is installed.
Securing your domain controllers
One of the first steps you should take involves developing a solid domain controller security policy. Protecting your domain controllers is at the core of protecting your Active Directory investment. Without your domain controllers you won't have your Active Directory network infrastructure. With exposed and unprotected domain controllers you also are at risk for attackers to enumerate shared folders and usernames, giving up valuable information that can be used to further attack the network.
Therefore, it is critical that domain controllers are running and protected in order for the Active Directory environment to remain functioning and stable. To protect domain controllers, you should consider the following areas of security protection: physical access (keeping DCs in a secure location that is only accessible by the IT staff) and network access (protecting DCs from those who might attack your network).
As an administrator, you need to be concerned with making sure internal users have proper access and that potential intruders are frustrated in their attempts to compromise a DC. One danger is for a person to be physically in the room and touch a DC even without any rights granted to them. Thus, if a person has physical access, he or she owns your computer, since physical access grants them control. Keeping DCs in a secure location is a simple way to ensure Active Direcotry security, but it is often overlooked.
As far as network access is concerned, it is important not to give domain admin privileges to someone who isn't skilled enough to handle the job or to someone you're not sure you can trust. Anyone with the ability to install/modify system files, including services/drivers (such as server operators, backup operators or print operators) owns your computer. There are many ways for this to happen. Naturally, a secure account could be compromised, giving the intruder the rights to do this, but a valid holder of these rights could cause harm unintentionally by installing an application without testing it first.
How well you handle Microsoft patch emergencies and updates is also key to the security of your DCs. You should always deploy the same patches on all domain controllers. DCs should be kept as close to mirror images of each other as possible, at least in terms of the OS configuration. This will help eliminate incompatibilities, lost or corrupted data and replication errors.
However, it is important not to patch just because Microsoft offers a patch. Every patch needs to be tested in your environment for relevance and reliability. If you don't need it, don't install it. Patches can damage your environment if the install fails to perform perfectly. You don't want to place your DCs at risk if you can avoid it.
Kerberos security with Microsoft
With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol. Not only was it much more secure and efficient than NTLM (which was used prior), but it also plays nicely with other operating systems such as Unix.
Before learning how Kerberos works in the world of Windows, it's best to first understand normal Kerberos authentication and authorization.
Authentication is the process of presenting credentials (username/password) to a service and having that service validate you. It works like this. When a user enters his or her username/password in a Kerberos environment, that information is sent to a server running the Authentication Service. The Authentication Service passes that information to a database called the Key Distribution Center (KDC). If the username/password checks out, the Authentication Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the logon process. The TGT contains a time stamp, the public key and a certificate.
Authorization is the process of granting access to resources on a server that is in the network. Continuing from the authentication discussion, once the client gets the TGT, the client can then request access to resources. The TGT is presented to the Ticket Granting Service and requests a session ticket to access a resource on, say, Server 1. If Server 1 is in the domain, the Ticket Granting Service sees that there is a valid TGT, so credentials check out, and a session ticket is granted for Server 1. The client then presents the session ticket to Server 1 for access to a resource such as a printer, file share or document. Server 1 will then check access rights on that resource to see what the user can do (read, write, etc.).
In a Windows domain, all of the Kerberos-related services just described are held by each domain controller. When a user presents credentials for authentication in a Windows domain, the same Kerberos authentication process described above is used -- with one exception. In order to find a domain controller that is also the KDC, a client must use the DC Locator process, which requires a DNS server to locate an appropriate DC and send that information back to the client. The client then passes the credentials to the domain controller, which grants the TGT and then a session ticket if the server to be accessed is in the DC's domain. The access rights are checked by the server and granted to the client.
Group Policy security settings
One of the most important steps toward Active Directory security involves Group Policy security settings. With almost 1,800 policy settings in a single Group Policy Object (GPO), it is no wonder they provide so much power, control, security, and management over an Active Directory enterprise.
There are two default GPOs in every Active Directory domain. These default GPOs are there for very distinct reasons and should be investigated to ensure they are configured properly to provide the best security for your company network. The first default GPO is the Default Domain Policy. This GPO is responsible for establishing and maintaining the account policies for the domain user accounts, which are essential for helping secure the domain user account passwords.
The second default GPO is the Default Domain Controller Policy. This GPO is responsible for establishing the baseline security for all domain controllers in the domain. The primary security settings that are established in the GPO are the user rights. Common user rights include:
Allowing a user to logon using the keyboard attached to the computer (locally)
Changing the system time
Backing up files and folders
Accessing the computer and its resources over a network
However, every network running Active Directory should have more than just the default two GPOs. The reason is that Group Policy provides an automated, centralized method for configuring and deploying security settings to all computers and users within the domain. Some common security related settings and areas of configuration include the ability to restrict which applications can be run on each computer, use IP Security to encrypt data between computers, restrict anonymous connections to computers and audit policy settings per computer.
Remember that there are several network security attacks that can be easily avoided with Group Policy, including simple steps for Kerberos configuration, so be sure to take advantage.
Understanding Active Directory replication
Understanding Active Directory replication
Active Directory replication is key to the health and stability of an Active Directory environment. Without proper and timely replication, a domain will be unable to function effectively. Replication is the process of sending update information for data that has changed in the directory to other domain controllers. It is important to have a firm understanding of replication and how it takes place, both within the domain and in multiple-site environments.
There are three main elements or components that are replicated between domain controllers: the domain partition replica, the global catalog and the schema.
The domain partition replica is the Active Directory database of a domain. Each domain controller maintains a duplicate copy of its local domain partition replica. Domain controllers do not maintain copies of replicas from other domains. When an administrator makes a change to the domain, that change is replicated to all domain controllers immediately.
Each forest contains only a single global catalog. By default, the first domain controller installed into a forest is the global catalog server. The global catalog contains a partial replica of every object within each domain of the forest. The global catalog serves as a master index for the forest, which allows for easy and efficient searching for users, computers, resources and other objects. Any domain controller can be configured to act as a peer global catalog server. You should have at least two global catalog servers per domain and at least one per site. As changes are made to objects within the forest, the global catalog is updated. Once the global catalog is changed on one domain controller, it is replicated to all other domain controllers in the forest.
Every domain controller in a forest has a copy of the schema. Just as with changes to the Active Directory database (i.e., domain partition replica), any changes to the Active Directory schema are replicated to all other domain controllers in the forest. Fortunately, the schema is usually static so there is little replication traffic caused by schema changes.
Multi-master replication
Within Windows-based Active Directory domains, each domain controller is a peer server. Each domain controller has equal power and responsibility to support and maintain the Active Directory database. It is this database that is essential to the well-being and existence of the domain itself. This is such an important task that Microsoft elected to make it possible to deploy multi-redundant systems to support Active Directory by making each domain controller a peer.
Whenever a change occurs to any object within an Active Directory domain, that change is replicated automatically to all domain controllers within the domain. This process is called multi-master replication. Multi-master replication does not happen instantly across all servers simultaneously. Rather, it is a controlled process where each domain controller peer is updated and validated in a logically controlled procedure.
As an administrator, you have some control over how multi-master replication occurs. Most of your control is obtained through the use of sites. A site is a logical designation of domain controllers in a network that are all located within a defined physical area. In most cases, sites control traffic over high-expense low-bandwidth WAN links. When a domain exists on two or more sites, normal Active Directory replication between the domain controllers in different sites is terminated. Instead, a single server within each site, labeled as a bridgehead server, performs all replication communications. You can configure this bridgehead server for when replication is allowed to occur and how much traffic it can generate when performing replication.
You can use sites to control replication even if you do not employ WAN links on your network. Sites effectively give administrators control over how and when AD multi-master replication occurs within their network.
Active Directory replication topology design
One of the secrets to an efficient and error-free Active Directory infrastructure is a well-designed replication topology. While this can be easy to design in a simple network, a large, complex network presents a challenge. Designing the AD topology efficiently is to construct it so that it takes advantage of the strengths and minimizes the weaknesses of the network. In a complex network, you are likely to have a number of different link speeds connecting remote sites.
The best practices for Active Directory replication design include:
Design the AD topology to take advantage of the network topology and link speeds.
Define lower speed links with higher cost site links. The cost of the links reduces as you get to faster areas in the topology.
Avoid "dead spots" -- all sites must connect to each other eventually. I have seen some topologies that left certain sites isolated because they didn't design the site links to connect them.
Site links should only have two sites per link. The exception to this is the Core site link which can have more. Defining more than two sites per link can result in unpredictable results when a DC failure occurs.
Diagram the overall flow of replication (like the figures here). You can use sophisticated features available in tools like HP OpenView (see the example in Figure 3) or Microsoft MOM, or you can simply draw it in a PowerPoint slide as I did in Figure 2. You'd be surprised at how many errors you will find by making a drawing of the topology.
Don't define scheduling unless you really have a good reason, and then you should test it thoroughly. Since you can schedule replication over the site link as well as the connection object itself, and since the resultant replication schedule is a merge of the two, you can end up with a schedule that prohibits replication. You also define replication frequency, which further complicates it. For instance, if you schedule the site links to replicate Monday through Friday from 8 a.m. to 6 p.m., and then have some connection objects that only replicate Tuesday and Thursday from 6 p.m. to 10 p.m., those connection objects will never replicate. Unless you have a very slow or limited network (such as VPN links), you should avoid this level of manual intervention.
Run the AD in Windows 2003 Forest mode. This means all DCs are at Windows Server 2003, and all domains are running in Windows 2003 mode. This takes advantage of the new spanning tree and compression algorithms available in Windows Server 2003, as well as other features that make replication much more efficient than were available in Windows 2000.
Monitor the AD. Once you get it in place, monitor it. One of the easiest ways to monitor it, outside of using Microsoft or third-party tools, is using the Repadmin tool and its "Replsum" option: Repadmin /replsum /bydest /bysrc /sort:delta. This will provide a nice, neat table of all DCs in all domains in the forest, telling you how long it has been for outbound and inbound replication (i.e. where each DC appears as a source and destination). Watching this over several days will give you a chance to find any holes in the topology.
Troubleshooting Active Directory replication
Replication should occur automatically. When it doesn't, the best solution isn't just to force Active Directory replication, but to check out the topology. If the replication topology has become unstable or misconfigured, it needs to be corrected before initiating a manual replication procedure.
The Knowledge Consistency Checker (KCC) creates the replication topology used for intra-site replication automatically. Rather than creating a full mesh for replication, the KCC designs a topology where every DC has at least two replication partners and is no more than three hops away from any other DC. With such a topology, every DC can be fully updated with as little as three replication cycles.
The REPAdmin tool from the Windows Support Tools and Resource Kit can be used to check the topology. The command "repadmin /showreps" runs on a domain controller and produces a list of replication partners as designated by the KCC. To check the topology, verify that every DC lists at least two replication partners and that all named partners see each other as partners. For example, if Server A lists Server B and C as partners, then both Server B and C should list Server A in return as a partner. If you discover a problem or inconsistency in the topology, use the KCC to regenerate the topology.
Once you are sure the topology is correct, then and only then should you force Active Directory replication.
Debugging replication errors
The lion's share of Active Directory problems are to some degree caused by replication failures, and one of the most notorious replication errors is the Event ID 1311.
The first step in resolving this replication error is to determine the scope of the error. The easiest way to do this is with the Repadmin/Replsum command. This will give you a complete summary of all the DCs in the forest, including the relevant event ID if it is in an error state. The general form of the command is this:
Repadmin /Replsum /bysrc /bydest /sort:delta
Here is a sample output of this command. Note that there are four domain controllers failing replication. While the 1311 may not show up in the output of this command, it is common for it to be paired up with the 1722 event (which basically means no physical connectivity). Obviously, if there is no physical connectivity (which would mean there was a network failure), replication isn't going to happen. The first thing to do is to check the general health of the domain using the Repadmin /replsum command just described. You can also ping broken DCs by address and FQDN, and you can run NetDiag and DCDiag commands from the command line (with the /v switch on each). This will give you more details about the errors and perhaps related ones.
Note: The network connecting all the sites should be fully routed. Don't create a site link if there is no underlying network link to get between the sites in the site link.
Logical connectivity is a bit more difficult to diagnose. It means, bottom line, that something in the AD site topology configuration is wrong, creating a hole in the topology. This could be solved by one of the following actions: configuring a preferred bridgehead server, making sure all sites are defined in site links and making sure there is a complete mesh of sites in site links.
DNS also must be taken into account. Since Active Directory replication relies on DNS name resolution to find DCs to replicate with, if DNS is broken, it could cause the 1311 events to occur. The helpful thing here is that if DNS is the culprit, the 1311 event will have the phrase "DNS Lookup Failure" included in the description. If you see this phrase, then you absolutely, positively have a DNS problem that must be fixed.
When debugging 1311 events, you should get a scope of the entire forest to see which DCs are not replicating. You can do this easily using the Repadmin /Replsum command. Note that the loss of physical connectivity, an incomplete AD site topology or DNS failure usually cause these events, with an outside chance it will be an orphaned object (an object that connot be found in the directory tree). Usually, other events will accompany them, such as the 1722 (RPC Server Unavailable), or the event will contain a descriptive statement such as "DNS Lookup Failure." This is a critical event that must be resolved in order for Active Directory replication to function properly to all DCs.
Active Directory replication is key to the health and stability of an Active Directory environment. Without proper and timely replication, a domain will be unable to function effectively. Replication is the process of sending update information for data that has changed in the directory to other domain controllers. It is important to have a firm understanding of replication and how it takes place, both within the domain and in multiple-site environments.
There are three main elements or components that are replicated between domain controllers: the domain partition replica, the global catalog and the schema.
The domain partition replica is the Active Directory database of a domain. Each domain controller maintains a duplicate copy of its local domain partition replica. Domain controllers do not maintain copies of replicas from other domains. When an administrator makes a change to the domain, that change is replicated to all domain controllers immediately.
Each forest contains only a single global catalog. By default, the first domain controller installed into a forest is the global catalog server. The global catalog contains a partial replica of every object within each domain of the forest. The global catalog serves as a master index for the forest, which allows for easy and efficient searching for users, computers, resources and other objects. Any domain controller can be configured to act as a peer global catalog server. You should have at least two global catalog servers per domain and at least one per site. As changes are made to objects within the forest, the global catalog is updated. Once the global catalog is changed on one domain controller, it is replicated to all other domain controllers in the forest.
Every domain controller in a forest has a copy of the schema. Just as with changes to the Active Directory database (i.e., domain partition replica), any changes to the Active Directory schema are replicated to all other domain controllers in the forest. Fortunately, the schema is usually static so there is little replication traffic caused by schema changes.
Multi-master replication
Within Windows-based Active Directory domains, each domain controller is a peer server. Each domain controller has equal power and responsibility to support and maintain the Active Directory database. It is this database that is essential to the well-being and existence of the domain itself. This is such an important task that Microsoft elected to make it possible to deploy multi-redundant systems to support Active Directory by making each domain controller a peer.
Whenever a change occurs to any object within an Active Directory domain, that change is replicated automatically to all domain controllers within the domain. This process is called multi-master replication. Multi-master replication does not happen instantly across all servers simultaneously. Rather, it is a controlled process where each domain controller peer is updated and validated in a logically controlled procedure.
As an administrator, you have some control over how multi-master replication occurs. Most of your control is obtained through the use of sites. A site is a logical designation of domain controllers in a network that are all located within a defined physical area. In most cases, sites control traffic over high-expense low-bandwidth WAN links. When a domain exists on two or more sites, normal Active Directory replication between the domain controllers in different sites is terminated. Instead, a single server within each site, labeled as a bridgehead server, performs all replication communications. You can configure this bridgehead server for when replication is allowed to occur and how much traffic it can generate when performing replication.
You can use sites to control replication even if you do not employ WAN links on your network. Sites effectively give administrators control over how and when AD multi-master replication occurs within their network.
Active Directory replication topology design
One of the secrets to an efficient and error-free Active Directory infrastructure is a well-designed replication topology. While this can be easy to design in a simple network, a large, complex network presents a challenge. Designing the AD topology efficiently is to construct it so that it takes advantage of the strengths and minimizes the weaknesses of the network. In a complex network, you are likely to have a number of different link speeds connecting remote sites.
The best practices for Active Directory replication design include:
Design the AD topology to take advantage of the network topology and link speeds.
Define lower speed links with higher cost site links. The cost of the links reduces as you get to faster areas in the topology.
Avoid "dead spots" -- all sites must connect to each other eventually. I have seen some topologies that left certain sites isolated because they didn't design the site links to connect them.
Site links should only have two sites per link. The exception to this is the Core site link which can have more. Defining more than two sites per link can result in unpredictable results when a DC failure occurs.
Diagram the overall flow of replication (like the figures here). You can use sophisticated features available in tools like HP OpenView (see the example in Figure 3) or Microsoft MOM, or you can simply draw it in a PowerPoint slide as I did in Figure 2. You'd be surprised at how many errors you will find by making a drawing of the topology.
Don't define scheduling unless you really have a good reason, and then you should test it thoroughly. Since you can schedule replication over the site link as well as the connection object itself, and since the resultant replication schedule is a merge of the two, you can end up with a schedule that prohibits replication. You also define replication frequency, which further complicates it. For instance, if you schedule the site links to replicate Monday through Friday from 8 a.m. to 6 p.m., and then have some connection objects that only replicate Tuesday and Thursday from 6 p.m. to 10 p.m., those connection objects will never replicate. Unless you have a very slow or limited network (such as VPN links), you should avoid this level of manual intervention.
Run the AD in Windows 2003 Forest mode. This means all DCs are at Windows Server 2003, and all domains are running in Windows 2003 mode. This takes advantage of the new spanning tree and compression algorithms available in Windows Server 2003, as well as other features that make replication much more efficient than were available in Windows 2000.
Monitor the AD. Once you get it in place, monitor it. One of the easiest ways to monitor it, outside of using Microsoft or third-party tools, is using the Repadmin tool and its "Replsum" option: Repadmin /replsum /bydest /bysrc /sort:delta. This will provide a nice, neat table of all DCs in all domains in the forest, telling you how long it has been for outbound and inbound replication (i.e. where each DC appears as a source and destination). Watching this over several days will give you a chance to find any holes in the topology.
Troubleshooting Active Directory replication
Replication should occur automatically. When it doesn't, the best solution isn't just to force Active Directory replication, but to check out the topology. If the replication topology has become unstable or misconfigured, it needs to be corrected before initiating a manual replication procedure.
The Knowledge Consistency Checker (KCC) creates the replication topology used for intra-site replication automatically. Rather than creating a full mesh for replication, the KCC designs a topology where every DC has at least two replication partners and is no more than three hops away from any other DC. With such a topology, every DC can be fully updated with as little as three replication cycles.
The REPAdmin tool from the Windows Support Tools and Resource Kit can be used to check the topology. The command "repadmin /showreps" runs on a domain controller and produces a list of replication partners as designated by the KCC. To check the topology, verify that every DC lists at least two replication partners and that all named partners see each other as partners. For example, if Server A lists Server B and C as partners, then both Server B and C should list Server A in return as a partner. If you discover a problem or inconsistency in the topology, use the KCC to regenerate the topology.
Once you are sure the topology is correct, then and only then should you force Active Directory replication.
Debugging replication errors
The lion's share of Active Directory problems are to some degree caused by replication failures, and one of the most notorious replication errors is the Event ID 1311.
The first step in resolving this replication error is to determine the scope of the error. The easiest way to do this is with the Repadmin/Replsum command. This will give you a complete summary of all the DCs in the forest, including the relevant event ID if it is in an error state. The general form of the command is this:
Repadmin /Replsum /bysrc /bydest /sort:delta
Here is a sample output of this command. Note that there are four domain controllers failing replication. While the 1311 may not show up in the output of this command, it is common for it to be paired up with the 1722 event (which basically means no physical connectivity). Obviously, if there is no physical connectivity (which would mean there was a network failure), replication isn't going to happen. The first thing to do is to check the general health of the domain using the Repadmin /replsum command just described. You can also ping broken DCs by address and FQDN, and you can run NetDiag and DCDiag commands from the command line (with the /v switch on each). This will give you more details about the errors and perhaps related ones.
Note: The network connecting all the sites should be fully routed. Don't create a site link if there is no underlying network link to get between the sites in the site link.
Logical connectivity is a bit more difficult to diagnose. It means, bottom line, that something in the AD site topology configuration is wrong, creating a hole in the topology. This could be solved by one of the following actions: configuring a preferred bridgehead server, making sure all sites are defined in site links and making sure there is a complete mesh of sites in site links.
DNS also must be taken into account. Since Active Directory replication relies on DNS name resolution to find DCs to replicate with, if DNS is broken, it could cause the 1311 events to occur. The helpful thing here is that if DNS is the culprit, the 1311 event will have the phrase "DNS Lookup Failure" included in the description. If you see this phrase, then you absolutely, positively have a DNS problem that must be fixed.
When debugging 1311 events, you should get a scope of the entire forest to see which DCs are not replicating. You can do this easily using the Repadmin /Replsum command. Note that the loss of physical connectivity, an incomplete AD site topology or DNS failure usually cause these events, with an outside chance it will be an orphaned object (an object that connot be found in the directory tree). Usually, other events will accompany them, such as the 1722 (RPC Server Unavailable), or the event will contain a descriptive statement such as "DNS Lookup Failure." This is a critical event that must be resolved in order for Active Directory replication to function properly to all DCs.
Active Directory and the Domain Name System
Active Directory and the Domain Name System (DNS)
What is DNS? One can define the domain name system as the way that Internet domain names are located and translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.
Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory is highly dependent on the Microsoft DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents. However, though not highly recommended, it is possible integrate a non-Microsoft DNS to use with Active Directory.
Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features: Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these DNS features, Active Directory cannot function. Therfore, it is essential to understand how DNS works.
DNS is extremely important to all aspects of proper Active Directory operation. Any time a client makes a request for a domain service, it must find a domain controller to service that request, which is where DNS comes in to play.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.
Adhering to proper DNS settings and best practices is crucial to Active Directory processes, such as replication.
DNS server configuration
DNS is fairly simple and straightforward. As long as you follow the basic rules of configuration, DNS will give you few problems. However, there are certain complex configurations that are important to know about and remember when configuring DNS servers, which can allow administrators to get a better handle on options that can make a difference in DNS operation, logging and troubleshooting.
One of the first things to figure out when learning DNS in Active Directory is knowing if a property is that of the DNS server or a zone. Both are exposed in the DNS Management snap-in tool.
Here are a couple of ways to keep them straight:
Server properties are general properties that apply to the whole DNS environment, such as Forwarding, Name Servers, root hints and logging.
Zone properties are specific properties that vary with the zone, such as dynamic updates, zone type (AD, Standard Primary or Secondary) and replication type.
DNS structure and design
DNS architecture design is also very important. When designing the DNS structure, it is important to keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect Active Directory performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
One key to designing DNS involves the use of Active Directory integrated zones (ADI). An ADI zone is a writeable copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are all held in Active Directory, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a single DNS server (primary) that will add the client's host and resource records.
So how is a DNS structure using Active Directory integrated zones designed? ADI zones can only be hosted on DCs. However, many administrators want to put domain name servers in remote sites to provide better name-resolution performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server. However, an administrator may not want to put a DC in that location. Windows 2000 Server and Windows Server 2003 allow admins to put a standard secondary zone (read only) on a member server and use one of the ADI primary servers as the master.
The rule is that an ADI primary zone can only exist on a DC, but admins can have a standard secondary of that zone on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive a referral to one of the primaries to be registered.
Protecting DNS
DNS security is a major priority. Many of the functions and features of Active Directory use DNS to locate domain controllers, systems, services, clients, and other objects. It should be obvious that protecting DNS is almost as important as protecting Active Directory itself. Basically, if DNS fails, so does Active Directory. This, in turn, means that if DNS fails, an entire network may be disabled.
Providing protection for DNS as a means to provide additional protection for AD DCs is an essential part of establishing a truly secure networking environment. Protecting your DNS servers will require a multi-pronged approach. First and foremost, establish the same secure design, implementation and deployment procedures for your DNS servers as I've recommended for your AD DCs.
Next, consider implementing secured communications with DNS servers, monitor all network traffic, and re-evaluate the open ports on your firewall. By encrypting all communications between DNS servers and all DNS clients (which includes not just end user clients but also Active Directory DCs and member servers), it will minimize or eliminate the possibility of traffic interception and manipulation. One of the best ways to implement this is through IPSec, which is is a framework for a set of protocols for security at the network or packet processing layer of network communication.
Note: While the implementation of IPSec across all systems will likely cause a measurable decrease in the performance of network communications due to the overhead of encrypting and decrypting communications, many experts feel the increased security should more than compensate for the slight reduction in throughput.
It is also important to monitor all network traffic and re-evaluate the open ports on your firewall. By monitoring network traffic, admins should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter their network.
Even with all recommended precautions in place, however, there is still a possibility of a malicious person gaining access to a DNS server. If that happens, admins must rely upon internal DNS security precautions, which include:
Secure dynamic updates
DNS resource record registration quotas
Delegate DNS administration
Use secured routing
Maintain a split DNS namespace
Disable recursion
Troubleshooting DNS
DNS troubleshooting is an absolutely vital process in Active Directory. It is important to keep DNS healthy and to know how to repair it when it breaks.
This article reviews some of the common DNS problems and the tools to use for DNS troubleshooting .
What is DNS? One can define the domain name system as the way that Internet domain names are located and translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.
Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory is highly dependent on the Microsoft DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents. However, though not highly recommended, it is possible integrate a non-Microsoft DNS to use with Active Directory.
Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features: Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these DNS features, Active Directory cannot function. Therfore, it is essential to understand how DNS works.
DNS is extremely important to all aspects of proper Active Directory operation. Any time a client makes a request for a domain service, it must find a domain controller to service that request, which is where DNS comes in to play.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.
Adhering to proper DNS settings and best practices is crucial to Active Directory processes, such as replication.
DNS server configuration
DNS is fairly simple and straightforward. As long as you follow the basic rules of configuration, DNS will give you few problems. However, there are certain complex configurations that are important to know about and remember when configuring DNS servers, which can allow administrators to get a better handle on options that can make a difference in DNS operation, logging and troubleshooting.
One of the first things to figure out when learning DNS in Active Directory is knowing if a property is that of the DNS server or a zone. Both are exposed in the DNS Management snap-in tool.
Here are a couple of ways to keep them straight:
Server properties are general properties that apply to the whole DNS environment, such as Forwarding, Name Servers, root hints and logging.
Zone properties are specific properties that vary with the zone, such as dynamic updates, zone type (AD, Standard Primary or Secondary) and replication type.
DNS structure and design
DNS architecture design is also very important. When designing the DNS structure, it is important to keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect Active Directory performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
One key to designing DNS involves the use of Active Directory integrated zones (ADI). An ADI zone is a writeable copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are all held in Active Directory, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a single DNS server (primary) that will add the client's host and resource records.
So how is a DNS structure using Active Directory integrated zones designed? ADI zones can only be hosted on DCs. However, many administrators want to put domain name servers in remote sites to provide better name-resolution performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server. However, an administrator may not want to put a DC in that location. Windows 2000 Server and Windows Server 2003 allow admins to put a standard secondary zone (read only) on a member server and use one of the ADI primary servers as the master.
The rule is that an ADI primary zone can only exist on a DC, but admins can have a standard secondary of that zone on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive a referral to one of the primaries to be registered.
Protecting DNS
DNS security is a major priority. Many of the functions and features of Active Directory use DNS to locate domain controllers, systems, services, clients, and other objects. It should be obvious that protecting DNS is almost as important as protecting Active Directory itself. Basically, if DNS fails, so does Active Directory. This, in turn, means that if DNS fails, an entire network may be disabled.
Providing protection for DNS as a means to provide additional protection for AD DCs is an essential part of establishing a truly secure networking environment. Protecting your DNS servers will require a multi-pronged approach. First and foremost, establish the same secure design, implementation and deployment procedures for your DNS servers as I've recommended for your AD DCs.
Next, consider implementing secured communications with DNS servers, monitor all network traffic, and re-evaluate the open ports on your firewall. By encrypting all communications between DNS servers and all DNS clients (which includes not just end user clients but also Active Directory DCs and member servers), it will minimize or eliminate the possibility of traffic interception and manipulation. One of the best ways to implement this is through IPSec, which is is a framework for a set of protocols for security at the network or packet processing layer of network communication.
Note: While the implementation of IPSec across all systems will likely cause a measurable decrease in the performance of network communications due to the overhead of encrypting and decrypting communications, many experts feel the increased security should more than compensate for the slight reduction in throughput.
It is also important to monitor all network traffic and re-evaluate the open ports on your firewall. By monitoring network traffic, admins should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter their network.
Even with all recommended precautions in place, however, there is still a possibility of a malicious person gaining access to a DNS server. If that happens, admins must rely upon internal DNS security precautions, which include:
Secure dynamic updates
DNS resource record registration quotas
Delegate DNS administration
Use secured routing
Maintain a split DNS namespace
Disable recursion
Troubleshooting DNS
DNS troubleshooting is an absolutely vital process in Active Directory. It is important to keep DNS healthy and to know how to repair it when it breaks.
This article reviews some of the common DNS problems and the tools to use for DNS troubleshooting .
The basics of Active Directory
The basics of Active Directory
What is Active Directory? Active Directory is Microsoft's trademarked directory service, an integral part of the Windows architecture. Like other directory services, such as Novell Directory Services (NDS), Active Directory is a centralized and standardized system that automates network management of user data, security and distributed resources and enables interoperation with other directories. Active Directory is designed especially for distributed networking environments.
Active Directory was new to Windows 2000 Server and further enhanced for Windows Server 2003, making it an even more important part of the operating system. Windows Server 2003 Active Directory provides a single reference, called a directory service, to all the objects in a network, including users, groups, computers, printers, policies and permissions.
For a user or an administrator, Active Directory provides a single hierarchical view from which to access and manage all of the network's resources.
Why implement Active Directory?
There are many reasons to implement Active Directory. First and foremost, Microsoft Active Directory is generally considered to be a significant improvement over Windows NT Server 4.0 domains or even standalone server networks. Active Directory has a centralized administration mechanism over the entire network. It also provides for redundancy and fault tolerance when two or more domain controllers are deployed within a domain.
Active Directory automatically manages the communications between domain controllers to ensure the network remains viable. Users can access all resources on the network for which they are authorized through a single sign-on. All resources in the network are protected by a robust security mechanism that verifies the identity of users and the authorizations of resources on each access.
Even with Active Directory's improved security and control over the network, most of its features are invisible to end users; therefore, migrating users to an Active Directory network will require little re-training. Active Directory offers a means of easily promoting and demoting domain controllers and member servers. Systems can be managed and secured via Group Policies. It is a flexible hierarchical organizational model that allows for easy management and detailed specific delegation of administrative responsibilities. Perhaps most importantly, however, is that Active Directory is capable of managing millions of objects within a single domain.
Basic divisions of Active Directory
Active Directory networks are organized using four types of divisions or container structures. These four divisions are forests, domains, organizational units and sites.
Forests: The collection of every object, its attributes and attribute syntax in the Active Directory.
Domain: A collection of computers that share a common set of policies, a name and a database of their members.
Organizational units: Containers in which domains can be grouped. They create a hierarchy for the domain and create the structure of the Active Directory's company in geographical or organizational terms.
Sites: Physical groupings independent of the domain and OU structure. Sites distinguish between locations connected by low- and high-speed connections and are defined by one or more IP subnets.
Forests are not limited in geography or network topology. A single forest can contain numerous domains, each sharing a common schema. Domain members of the same forest need not even have a dedicated LAN or WAN connection between them. A single network can also be the home of multiple independent forests. In general, a single forest should be used for each corporate entity. However, additional forests may be desired for testing and research purposes outside of the production forest.
Domains serve as containers for security policies and administrative assignments. All objects within a domain are subject to domain-wide Group Policies by default. Likewise, any domain administrator can manage all objects within a domain. Furthermore, each domain has its own unique accounts database. Thus, authentication is on a domain basis. Once a user account is authenticated to a domain, that user account has access to resources within that domain.
Active Directory requires one or more domains in which to operate. As mentioned before, an Active Directory domain is a collection of computers that share a common set of policies, a name and a database of their members. A domain must have one or more servers that serve as domain controllers (DCs) and store the database, maintain the policies and provide the authentication of domain logons.
With Windows NT, primary domain controller (PDC) and backup domain controller (BDC) were roles that could be assigned to a server in a network of computers that used a Windows operating system. Windows used the idea of a domain to manage access to a set of network resources (applications, printers and so forth) for a group of users. The user need only to log in to the domain to gain access to the resources, which may be located on a number of different servers in the network.
One server, known as the primary domain controller, managed the master user database for the domain. One or more other servers were designated as backup domain controllers. The primary domain controller periodically sent copies of the database to the backup domain controllers. A backup domain controller could step in as primary domain controller if the PDC server failed and could also help balance the workload if the network was busy enough.
With Windows 2000 Server, while domain controllers were retained, the PDC and BDC server roles were basically replaced by Active Directory. It is no longer necessary to create separate domains to divide administrative privileges. Within Active Directory, it is possible to delegate administrative privileges based on organizational units. Domains are no longer restricted by a 40,000-user limit. Active Directory domains can manage millions of objects. As there are no longer PDCs and BDCs, Active Directory uses multi-master replication and all domain controllers are peers.
Organizational units are much more flexible and easier overall to manage than domains. OUs grant you nearly infinite flexibility as you can move them, delete them and create new OUs as needed. However, domains are much more rigid in their existence. Domains can be deleted and new ones created, but this process is more disruptive of an environment than is the case with OUs and should be avoided whenever possible.
By definition, sites are collections of IP subnets that have fast and reliable communication links between all hosts. Another way of putting this is a site contains LAN connections, but not WAN connections, with the general understanding that WAN connections are significantly slower and less reliable than LAN connections. By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links. This can result in more efficient traffic flow for productivity tasks. It can also keep WAN link costs down for pay-by-the-bit services.
The Infrastructure Master and Global Catalog
Among the other key components within Active Directory is the Infrastructure Master. The Infrastructure Master (IM) is a domain-wide FSMO (Flexible Single Master of Operations) role responsible for an unattended process that "fixes-up" stale references, known as phantoms, within the Active Directory database.
Phantoms are created on DCs that require a database cross-reference between an object within their own database and an object from another domain within the forest. This occurs, for example, when you add a user from one domain to a group within another domain in the same forest. Phantoms are deemed stale when they no longer contain up-to-date data, which occurs because of changes that have been made to the foreign object the phantom represents, e.g., when the target object is renamed, moved, migrated between domains or deleted. The Infrastructure Master is exclusively responsible for locating and fixing stale phantoms. Any changes introduced as a result of the "fix-up" process must then be replicated to all remaining DCs within the domain.
The Infrastructure Master is sometimes confused with the Global Catalog (GC), which maintains a partial, read-only copy of every domain in a forest and is used for universal group storage and logon processing, among other things. Since GCs store a partial copy of all objects within the forest, they are able to create cross-domain references without the need for phantoms.
Active Directory and LDAP
Microsoft includes LDAP (Lightweight Directory Access Protocol) as part of Active Directory. LDAP is a software protocol for enabling anyone to locate organizations, individuals and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet.
In a network, a directory tells you where in the network something is located. On TCP/IP networks (including the Internet), the domain name system (DNS) is the directory system used to relate the domain name to a specific network address (a unique location on the network). However, you may not know the domain name. LDAP allows you to search for individuals without knowing where they're located (although additional information will help with the search).
An LDAP directory is organized in a simple "tree" hierarchy consisting of the following levels:
The root directory (the starting place or the source of the tree), which branches out to
Countries, each of which branches out to
Organizations, which branch out to
Organizational units (divisions, departments and so forth), which branch out to (include an entry for)
Individuals (which include people, files and shared resources, such as printers)
An LDAP directory can be distributed among many servers. Each server can have a replicated version of the total directory that is synchronized periodically.
It is important for every administrator to have an understanding of what LDAP is when searching for information in Active Directory and to be able to create LDAP queries is especially useful when looking for information stored in your Active Directory database. For this reason, many admins go to great lengths to master the LDAP search filter.
Group Policy management and Active Directory
It's difficult to discuss Active Directory without mentioning Group Policy. Admins can use Group Policies in Microsoft Active Directory to define settings for users and computers throughout a network. These setting are configured and stored in what are called Group Policy Objects (GPOs), which are then associated with Active Directory objects, including domains and sites. It is the primary mechanism for applying changes to computers and users throughout a Windows environment.
Through Group Policy management, administrators can globally configure desktop settings on user computers, restrict/allow access to certain files and folders within a network and more.
It is important to understand how GPOs are used and applied. Group Policy Objects are applied in the following order: Local machine policies are applied first, followed by site policies, followed by domain policies, followed by policies applied to individual organizational units. A user or computer object can only belong to a single site and a single domain at any one time, so they will receive only GPOs that are linked to that site or domain.
GPOs are split into two distinct parts: the Group Policy Template (GPT) and the Group Policy Container (GPC). The Group Policy Template is responsible for storing the specific settings created within the GPO and is essential to its success. It stores these settings in a large structure of folders and files. In order for the settings to apply successfully to all user and computer objects, the GPT must be replicated to all domain controllers within the domain.
The Group Policy Container is the portion of a GPO stored in Active Directory that resides on each domain controller in the domain. The GPC is responsible for keeping references to Client Side Extensions (CSEs), the path to the GPT, paths to software installation packages, and other referential aspects of the GPO. The GPC does not contain a wealth of information related to its corresponding GPO, but it is essential to the functionality of Group Policy. When software installation policies are configured, the GPC helps keep the links associated within the GPO. The GPC also keeps other relational links and paths stored within the object attributes. Knowing the structure of the GPC and how to access the hidden information stored in the attributes will pay off when you need to track down an issue related to Group Policy.
For Windows Server 2003, Microsoft released a Group Policy management solution as a means of unifying management of Group Policy in the form of a snap-in known as the Group Policy Management Console (GPMC). The GPMC provides a GPO-focused management interface, thus making the administration, management and location of GPOs much simpler. Through GPMC you can create new GPOs, modify and edit GPOs, cut/copy/paste GPOs, back up GPOs and perform Resultant Set of Policy modeling.
What is Active Directory? Active Directory is Microsoft's trademarked directory service, an integral part of the Windows architecture. Like other directory services, such as Novell Directory Services (NDS), Active Directory is a centralized and standardized system that automates network management of user data, security and distributed resources and enables interoperation with other directories. Active Directory is designed especially for distributed networking environments.
Active Directory was new to Windows 2000 Server and further enhanced for Windows Server 2003, making it an even more important part of the operating system. Windows Server 2003 Active Directory provides a single reference, called a directory service, to all the objects in a network, including users, groups, computers, printers, policies and permissions.
For a user or an administrator, Active Directory provides a single hierarchical view from which to access and manage all of the network's resources.
Why implement Active Directory?
There are many reasons to implement Active Directory. First and foremost, Microsoft Active Directory is generally considered to be a significant improvement over Windows NT Server 4.0 domains or even standalone server networks. Active Directory has a centralized administration mechanism over the entire network. It also provides for redundancy and fault tolerance when two or more domain controllers are deployed within a domain.
Active Directory automatically manages the communications between domain controllers to ensure the network remains viable. Users can access all resources on the network for which they are authorized through a single sign-on. All resources in the network are protected by a robust security mechanism that verifies the identity of users and the authorizations of resources on each access.
Even with Active Directory's improved security and control over the network, most of its features are invisible to end users; therefore, migrating users to an Active Directory network will require little re-training. Active Directory offers a means of easily promoting and demoting domain controllers and member servers. Systems can be managed and secured via Group Policies. It is a flexible hierarchical organizational model that allows for easy management and detailed specific delegation of administrative responsibilities. Perhaps most importantly, however, is that Active Directory is capable of managing millions of objects within a single domain.
Basic divisions of Active Directory
Active Directory networks are organized using four types of divisions or container structures. These four divisions are forests, domains, organizational units and sites.
Forests: The collection of every object, its attributes and attribute syntax in the Active Directory.
Domain: A collection of computers that share a common set of policies, a name and a database of their members.
Organizational units: Containers in which domains can be grouped. They create a hierarchy for the domain and create the structure of the Active Directory's company in geographical or organizational terms.
Sites: Physical groupings independent of the domain and OU structure. Sites distinguish between locations connected by low- and high-speed connections and are defined by one or more IP subnets.
Forests are not limited in geography or network topology. A single forest can contain numerous domains, each sharing a common schema. Domain members of the same forest need not even have a dedicated LAN or WAN connection between them. A single network can also be the home of multiple independent forests. In general, a single forest should be used for each corporate entity. However, additional forests may be desired for testing and research purposes outside of the production forest.
Domains serve as containers for security policies and administrative assignments. All objects within a domain are subject to domain-wide Group Policies by default. Likewise, any domain administrator can manage all objects within a domain. Furthermore, each domain has its own unique accounts database. Thus, authentication is on a domain basis. Once a user account is authenticated to a domain, that user account has access to resources within that domain.
Active Directory requires one or more domains in which to operate. As mentioned before, an Active Directory domain is a collection of computers that share a common set of policies, a name and a database of their members. A domain must have one or more servers that serve as domain controllers (DCs) and store the database, maintain the policies and provide the authentication of domain logons.
With Windows NT, primary domain controller (PDC) and backup domain controller (BDC) were roles that could be assigned to a server in a network of computers that used a Windows operating system. Windows used the idea of a domain to manage access to a set of network resources (applications, printers and so forth) for a group of users. The user need only to log in to the domain to gain access to the resources, which may be located on a number of different servers in the network.
One server, known as the primary domain controller, managed the master user database for the domain. One or more other servers were designated as backup domain controllers. The primary domain controller periodically sent copies of the database to the backup domain controllers. A backup domain controller could step in as primary domain controller if the PDC server failed and could also help balance the workload if the network was busy enough.
With Windows 2000 Server, while domain controllers were retained, the PDC and BDC server roles were basically replaced by Active Directory. It is no longer necessary to create separate domains to divide administrative privileges. Within Active Directory, it is possible to delegate administrative privileges based on organizational units. Domains are no longer restricted by a 40,000-user limit. Active Directory domains can manage millions of objects. As there are no longer PDCs and BDCs, Active Directory uses multi-master replication and all domain controllers are peers.
Organizational units are much more flexible and easier overall to manage than domains. OUs grant you nearly infinite flexibility as you can move them, delete them and create new OUs as needed. However, domains are much more rigid in their existence. Domains can be deleted and new ones created, but this process is more disruptive of an environment than is the case with OUs and should be avoided whenever possible.
By definition, sites are collections of IP subnets that have fast and reliable communication links between all hosts. Another way of putting this is a site contains LAN connections, but not WAN connections, with the general understanding that WAN connections are significantly slower and less reliable than LAN connections. By using sites, you can control and reduce the amount of traffic that flows over your slower WAN links. This can result in more efficient traffic flow for productivity tasks. It can also keep WAN link costs down for pay-by-the-bit services.
The Infrastructure Master and Global Catalog
Among the other key components within Active Directory is the Infrastructure Master. The Infrastructure Master (IM) is a domain-wide FSMO (Flexible Single Master of Operations) role responsible for an unattended process that "fixes-up" stale references, known as phantoms, within the Active Directory database.
Phantoms are created on DCs that require a database cross-reference between an object within their own database and an object from another domain within the forest. This occurs, for example, when you add a user from one domain to a group within another domain in the same forest. Phantoms are deemed stale when they no longer contain up-to-date data, which occurs because of changes that have been made to the foreign object the phantom represents, e.g., when the target object is renamed, moved, migrated between domains or deleted. The Infrastructure Master is exclusively responsible for locating and fixing stale phantoms. Any changes introduced as a result of the "fix-up" process must then be replicated to all remaining DCs within the domain.
The Infrastructure Master is sometimes confused with the Global Catalog (GC), which maintains a partial, read-only copy of every domain in a forest and is used for universal group storage and logon processing, among other things. Since GCs store a partial copy of all objects within the forest, they are able to create cross-domain references without the need for phantoms.
Active Directory and LDAP
Microsoft includes LDAP (Lightweight Directory Access Protocol) as part of Active Directory. LDAP is a software protocol for enabling anyone to locate organizations, individuals and other resources such as files and devices in a network, whether on the public Internet or on a corporate intranet.
In a network, a directory tells you where in the network something is located. On TCP/IP networks (including the Internet), the domain name system (DNS) is the directory system used to relate the domain name to a specific network address (a unique location on the network). However, you may not know the domain name. LDAP allows you to search for individuals without knowing where they're located (although additional information will help with the search).
An LDAP directory is organized in a simple "tree" hierarchy consisting of the following levels:
The root directory (the starting place or the source of the tree), which branches out to
Countries, each of which branches out to
Organizations, which branch out to
Organizational units (divisions, departments and so forth), which branch out to (include an entry for)
Individuals (which include people, files and shared resources, such as printers)
An LDAP directory can be distributed among many servers. Each server can have a replicated version of the total directory that is synchronized periodically.
It is important for every administrator to have an understanding of what LDAP is when searching for information in Active Directory and to be able to create LDAP queries is especially useful when looking for information stored in your Active Directory database. For this reason, many admins go to great lengths to master the LDAP search filter.
Group Policy management and Active Directory
It's difficult to discuss Active Directory without mentioning Group Policy. Admins can use Group Policies in Microsoft Active Directory to define settings for users and computers throughout a network. These setting are configured and stored in what are called Group Policy Objects (GPOs), which are then associated with Active Directory objects, including domains and sites. It is the primary mechanism for applying changes to computers and users throughout a Windows environment.
Through Group Policy management, administrators can globally configure desktop settings on user computers, restrict/allow access to certain files and folders within a network and more.
It is important to understand how GPOs are used and applied. Group Policy Objects are applied in the following order: Local machine policies are applied first, followed by site policies, followed by domain policies, followed by policies applied to individual organizational units. A user or computer object can only belong to a single site and a single domain at any one time, so they will receive only GPOs that are linked to that site or domain.
GPOs are split into two distinct parts: the Group Policy Template (GPT) and the Group Policy Container (GPC). The Group Policy Template is responsible for storing the specific settings created within the GPO and is essential to its success. It stores these settings in a large structure of folders and files. In order for the settings to apply successfully to all user and computer objects, the GPT must be replicated to all domain controllers within the domain.
The Group Policy Container is the portion of a GPO stored in Active Directory that resides on each domain controller in the domain. The GPC is responsible for keeping references to Client Side Extensions (CSEs), the path to the GPT, paths to software installation packages, and other referential aspects of the GPO. The GPC does not contain a wealth of information related to its corresponding GPO, but it is essential to the functionality of Group Policy. When software installation policies are configured, the GPC helps keep the links associated within the GPO. The GPC also keeps other relational links and paths stored within the object attributes. Knowing the structure of the GPC and how to access the hidden information stored in the attributes will pay off when you need to track down an issue related to Group Policy.
For Windows Server 2003, Microsoft released a Group Policy management solution as a means of unifying management of Group Policy in the form of a snap-in known as the Group Policy Management Console (GPMC). The GPMC provides a GPO-focused management interface, thus making the administration, management and location of GPOs much simpler. Through GPMC you can create new GPOs, modify and edit GPOs, cut/copy/paste GPOs, back up GPOs and perform Resultant Set of Policy modeling.
Introduction to Exchange 2007 Server Roles
Exchange 2007 introduces a new concept to Exchange organizations, the concept of server roles. Similar to how a Windows server can host one or more roles, this type of configuration has been implemented in Exchange Server 2007.
Server roles allow an administrator to split the functions of an Exchange server and place each role, or a combination of roles, on different servers in the organization. This can be done for performance reasons, management reasons, or any other reason deemed necessary by the organization's policies.
With current Exchange servers you can make a server a Front-End server or a Back-End server and that is about it. Exchange 2007 introduces five roles to the Exchange organization.
Edge Transport
Hub Transport
Client Access
Mailbox
Unified Messaging
The following graphic (Figure 1) shows the placement of each role in a typical organization.
Edge Transport Role
The Edge Transport role is installed on the edge of the network and therefore is installed on a standalone server that is not a member of the Active Directory domain. Because the server is not a member of the Active Directory domain, Active Directory Application Mode (ADAM) is used to sync AD with the Edge Transport server. ADAM and a component called EdgeSync are used to perform scheduled one-way synchronization of the configuration and recipient information from Active Directory. This allows the Edge Transport to perform recipient lookups and Spam filtering.
The Edge Transport role performs a number of functions including Anti-spam and Anti-virus protection. The Edge Transport uses connection filtering, content filtering, recipient filtering, SenderID, sender and IP reputation to reduce the amount of Spam delivered to the end users inbox. Mail tagged as Spam will sit in a Spam quarantine from which administrators can delete or allow messages tagged as Spam. One of the top features is the ability for Outlook 2003 and 2007 clients to merge their Spam settings (like white and black lists) to the Edge Transport server to increase the efficiency and accuracy of the filters. The built in VSAPI has been improved and the introduction of transport agents will allow third party AV applications to provide stronger AV filtering.
Edge Transport Rules are used to protect the Exchange organization by applying rules and, based on whether the message passes or fails, appropriate action is taken. Unlike the Anti-virus and Anti-Spam processing, Edge Transport rules are based on SMTP and MIME addresses, words in the subject or message body, and SCL rating. The Edge Transport role also handles address rewriting; in Exchange 2007 an administrator can modify the SMTP address on in or outbound mail.
The Edge Transport server is also responsible for all mail entering or leaving the Exchange organization. Mail travels inbound through the Edge Transport and once the Edge Transport Rules have been applied the message is passed on to the Hub Transport server. Because the Edge Transport is responsible for all in and outbound mail, you can configure multiple Edge Transport servers for redundancy and load balancing.
Hub Transport Role
The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.
The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.
Inbound mail is accepted from the Edge Transport and passed on to the user's mailbox and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet. Hub Transport agents can also be deployed to enforce corporate message policies such as message retention, something that will come as good news to administrators attempting to comply with SarbOx rules.
The Anti-Spam and Anti-virus features of the Edge Transport can be configured on the Hub Transport in order to reduce the number of servers required. It is quite feasible that you may only have one server in your Exchange organization with all the roles installed on it. In this case you cannot have an Edge Transport and all those features will be passed on to the Hub Transport role.
Mailbox Role
The simplest of the roles has to be the Mailbox Role. Quite simply the Mailbox role holds the Exchange databases within which the user mailboxes are contained. It is also home to the Public Folder databases if you enabled Public Folders. (They are not enabled by default in Exchange 2007)
Client Access Role
The Client Access Role is similar to the role a Front-End server would play in an Exchange 2000/2003 organization. The Client Access server is the server that users connect to with their mail client, mobile device, or web browser. The Client Access server handles all connections whether they come from an application such as Outlook 2003 or 2007, Outlook Express, or any other MAPI, POP3 or IMAP4 client. The Client Access server also handles connections made from mobile devices such as a Windows Mobile 5 Smartphone, or any other device using Exchange ActiveSync. Exchange ActiveSync in Exchange 2007 supports all devices with PocketPC 2002/2003 and Windows Mobile 5. Figure 2 shows how all the clients and roles connect to each other
This role also provides Outlook Web Access (OWA). OWA allows a user to access his or her mailbox from a web browser and have full access to all the information in the mailbox including task lists, calendar information, mail items and public folders. One of the hot new functions of OWA is Sharepoint and UNC access. Now users can access UNC shares (\\servername\share) and Sharepoint document libraries reducing the need for complex VPN configurations.
Unified Messaging Role
The last, and in my opinion, coolest role is the Unified Messaging Role. The Unified Messaging role is responsible for merging your VOIP infrastructure with your Exchange organization. What does this allow for?
combined voice, fax, and mail in one inbox
access to voice, fax and mail via multiple interfaces
Need to check your voicemail but all you have is Internet access? No problem, connect to the Exchange server with OWA and you will find your voicemail as attachments in email messages. Running late for a meeting and no access to email or your calendar? Call the Exchange server and move the start of the appointment in your calendar and the attendees with get an email notifying them of the change.
Unified messaging will change the way user’s access voice, fax and email and they will love you for it. Now before you get too excited this will require some special hardware to interact with your phone system and more information will be released as Exchange 2007 gets closer to RTM.
Server roles allow an administrator to split the functions of an Exchange server and place each role, or a combination of roles, on different servers in the organization. This can be done for performance reasons, management reasons, or any other reason deemed necessary by the organization's policies.
With current Exchange servers you can make a server a Front-End server or a Back-End server and that is about it. Exchange 2007 introduces five roles to the Exchange organization.
Edge Transport
Hub Transport
Client Access
Mailbox
Unified Messaging
The following graphic (Figure 1) shows the placement of each role in a typical organization.
Edge Transport Role
The Edge Transport role is installed on the edge of the network and therefore is installed on a standalone server that is not a member of the Active Directory domain. Because the server is not a member of the Active Directory domain, Active Directory Application Mode (ADAM) is used to sync AD with the Edge Transport server. ADAM and a component called EdgeSync are used to perform scheduled one-way synchronization of the configuration and recipient information from Active Directory. This allows the Edge Transport to perform recipient lookups and Spam filtering.
The Edge Transport role performs a number of functions including Anti-spam and Anti-virus protection. The Edge Transport uses connection filtering, content filtering, recipient filtering, SenderID, sender and IP reputation to reduce the amount of Spam delivered to the end users inbox. Mail tagged as Spam will sit in a Spam quarantine from which administrators can delete or allow messages tagged as Spam. One of the top features is the ability for Outlook 2003 and 2007 clients to merge their Spam settings (like white and black lists) to the Edge Transport server to increase the efficiency and accuracy of the filters. The built in VSAPI has been improved and the introduction of transport agents will allow third party AV applications to provide stronger AV filtering.
Edge Transport Rules are used to protect the Exchange organization by applying rules and, based on whether the message passes or fails, appropriate action is taken. Unlike the Anti-virus and Anti-Spam processing, Edge Transport rules are based on SMTP and MIME addresses, words in the subject or message body, and SCL rating. The Edge Transport role also handles address rewriting; in Exchange 2007 an administrator can modify the SMTP address on in or outbound mail.
The Edge Transport server is also responsible for all mail entering or leaving the Exchange organization. Mail travels inbound through the Edge Transport and once the Edge Transport Rules have been applied the message is passed on to the Hub Transport server. Because the Edge Transport is responsible for all in and outbound mail, you can configure multiple Edge Transport servers for redundancy and load balancing.
Hub Transport Role
The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.
The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.
Inbound mail is accepted from the Edge Transport and passed on to the user's mailbox and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet. Hub Transport agents can also be deployed to enforce corporate message policies such as message retention, something that will come as good news to administrators attempting to comply with SarbOx rules.
The Anti-Spam and Anti-virus features of the Edge Transport can be configured on the Hub Transport in order to reduce the number of servers required. It is quite feasible that you may only have one server in your Exchange organization with all the roles installed on it. In this case you cannot have an Edge Transport and all those features will be passed on to the Hub Transport role.
Mailbox Role
The simplest of the roles has to be the Mailbox Role. Quite simply the Mailbox role holds the Exchange databases within which the user mailboxes are contained. It is also home to the Public Folder databases if you enabled Public Folders. (They are not enabled by default in Exchange 2007)
Client Access Role
The Client Access Role is similar to the role a Front-End server would play in an Exchange 2000/2003 organization. The Client Access server is the server that users connect to with their mail client, mobile device, or web browser. The Client Access server handles all connections whether they come from an application such as Outlook 2003 or 2007, Outlook Express, or any other MAPI, POP3 or IMAP4 client. The Client Access server also handles connections made from mobile devices such as a Windows Mobile 5 Smartphone, or any other device using Exchange ActiveSync. Exchange ActiveSync in Exchange 2007 supports all devices with PocketPC 2002/2003 and Windows Mobile 5. Figure 2 shows how all the clients and roles connect to each other
This role also provides Outlook Web Access (OWA). OWA allows a user to access his or her mailbox from a web browser and have full access to all the information in the mailbox including task lists, calendar information, mail items and public folders. One of the hot new functions of OWA is Sharepoint and UNC access. Now users can access UNC shares (\\servername\share) and Sharepoint document libraries reducing the need for complex VPN configurations.
Unified Messaging Role
The last, and in my opinion, coolest role is the Unified Messaging Role. The Unified Messaging role is responsible for merging your VOIP infrastructure with your Exchange organization. What does this allow for?
combined voice, fax, and mail in one inbox
access to voice, fax and mail via multiple interfaces
Need to check your voicemail but all you have is Internet access? No problem, connect to the Exchange server with OWA and you will find your voicemail as attachments in email messages. Running late for a meeting and no access to email or your calendar? Call the Exchange server and move the start of the appointment in your calendar and the attendees with get an email notifying them of the change.
Unified messaging will change the way user’s access voice, fax and email and they will love you for it. Now before you get too excited this will require some special hardware to interact with your phone system and more information will be released as Exchange 2007 gets closer to RTM.
Subscribe to:
Posts (Atom)