Microsoft Infrastructure
Windows Server
By deploying Windows Server 2008 Active Directory Domain Services (AD DS) in your environment, you can take advantage of the centralized, delegated administrative model and single sign-on (SSO) capability that AD DS provides. After you identify the deployment tasks and current environment for your organization, you can create the AD DS deployment strategy that meets your organization’s needs.
Organizations can use Active Directory Domain Services (AD DS) in Windows Server 2008 to simplify user and resource management while creating scalable, secure, and manageable infrastructures. You can use AD DS to manage your network infrastructure, including branch office, Microsoft Exchange Server, and multiple forest environments.
An AD DS deployment project involves three phases: a design phase, a deployment phase, and an operations phase. During the design phase, the design team creates a design for the AD DS logical structure that best meets the needs of each division in the organization that will use the directory service. After the design is approved, the deployment team tests the design in a lab environment and then implements the design in the production environment. Because testing is performed by the deployment team and it potentially affects the design phase, it is an interim activity that overlaps both design and deployment. When the deployment is complete, the operations team is responsible for maintaining the directory service.
Performing a high-level assessment of your current environment and correctly identifying your Active Directory Domain Services (AD DS) deployment tasks is essential for the success of your AD DS deployment strategy.
Your AD DS deployment strategy depends on your existing network configuration. For example, if your organization currently runs Windows Server 2003, you can upgrade your operating system to Windows Server 2008. Your deployment process might involve restructuring existing domains, either within an Active Directory forest or between Active Directory forests.
Exchange Server
In previous versions of Microsoft Exchange Server, administrators were offered limited choices on what features could or could not be installed. For example, in Exchange Server 2003 and Exchange 2000 Server, the setup process installed all features regardless of which features the administrator planned to use. This behavior required the administrator to turn off or disable the undesired features.
Because organizations tend to group their management tasks around a core set of server roles, Exchange Server 2007 maps Exchange Server management to this more natural way of doing things. System management in Exchange 2007 fundamentally shifts the administrative experience for deploying and managing servers to focus on server roles.
Overview of Server Roles
A server role is a unit that logically groups the required features and components needed to perform a specific function in the messaging environment. The requirement of a server role is that it is a server that could be run as an atomic unit of scalability. A server role is composed of a group of features.
Server roles, the primary unit of deployment, enable administrators to easily choose which features are installed on an Exchange server. Logically grouping features in server roles offers the following advantages:
· Reduces attack surface on an Exchange server.
· Allows you to install and configure an Exchange server the way you intend to use it.