Technology Blog

Quote on Enterprise Architecture!


“Most of us who come from IT today are thinking of building and running systems and not about engineering and manufacturing enterprises. My argument here is that the end objective is to engineer and manufacture the enterprise, not simply to build and run systems” – John Zachman, Inventor of Enterprise Architecture

Preliminary Phase – TOGAF 9


[Preliminary Phase]

Preliminary Phase describes the preparation and initiation activities required to meet the business directive for a new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.

Preliminary_Phase

                       Figure: Preliminary Phase

Preliminary Phase – Objectives:

The objectives of the Preliminary Phase are:

  1. Determine the Architecture Capability desired by the organization:
    • Review the organizational context for conducting enterprise architecture
    • Identify and scope the elements of the enterprise organizations affected by the Architecture Capability
    • Identify the established frameworks, methods, and processes that intersect with the Architecture Capability
    • Establish Capability Maturity target
  2. Establish the Architecture Capability:
    • Define and establish the Organizational Model for Enterprise Architecture
    • Define and establish the detailed process and resources for architecture governance
    • Select and implement tools that support the Architecture Capability
    • Define the Architecture Principles

Preliminary Phase – Approach:

This Preliminary Phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned. The main aspects are as follows:

  • Defining the enterprise
  • Identifying key drivers and elements in the organizational context
  • Defining the requirements for architecture work
  • Defining the Architecture Principles that will inform any architecture work
  • Defining the framework to be used
  • Defining the relationships between management frameworks
  • Evaluating the enterprise architecture maturity

Preliminary Phase – Inputs:

This section defines the inputs to the Preliminary Phase.

Reference Materials External to the Enterprise

  •        TOGAF
  •        Other architecture framework(s), like Zachman or others if required

Non-Architectural Inputs

  •       Board strategies and board business plans, business strategy, IT strategy, business principles, business goals, and business drivers, when pre-existing
  •       Major frameworks operating in the business; e.g., portfolio/project management
  •       Governance and legal frameworks, including architecture governance strategy, when pre-existing
  •       Architecture capability
  •       Partnership and contract agreements

Architectural Inputs

Pre-existing models for operating an enterprise Architecture Capability can be used as a baseline for the Preliminary Phase. Inputs would include:

Organizational Model for Enterprise Architecture (see Organizational Model for Enterprise Architecture), including:

  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Budget requirements
  • Governance and support strategy

Existing Architecture Framework, if any, including:

  • Architecture method
  • Architecture content
  • Configured and deployed tools
  • Architecture Principles
  • Architecture Repository

Preliminary Phase – Steps:

The TOGAF ADM is a generic method, intended to be used by a wide variety of different enterprises, and in conjunction with a wide variety of other architecture frameworks, if required. The Preliminary Phase therefore involves doing any necessary work to initiate and adapt the ADM to define an organization-specific framework.

The order of the steps in the Preliminary Phase (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps within the Preliminary Phase are as follows:

Preliminary Phase – Outputs:

The outputs of the Preliminary Phase may include, but are not restricted to:

Organizational Model for Enterprise Architecture (see Organizational Model for Enterprise Architecture), including:

  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy

Tailored Architecture Framework (see Tailored Architecture Framework), including:

  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Architecture Principles (see Architecture Principles)
  • Configured and deployed tools

Initial Architecture Repository (see Architecture Repository), populated with framework content

Restatement of, or reference to, business principles, business goals, and business drivers (see Business Principles, Business Goals, and Business Drivers)

Request for Architecture Work (optional) (see Request for Architecture Work)

Architecture Governance Framework (see Architecture Governance Framework)

Architecture Development Method (ADM) – TOGAF 9


[Architecture Development Method (ADM) cycle, adapting the ADM, architecture scope, and architecture integration]

ADM Overview

The TOGAF (The Open Group Architecture Framework) ADM (Architecture Development Method) is the result of continuous contributions from a large number of architecture practitioners. It describes a method for developing and managing the lifecycle of an enterprise architecture, and forms the core of TOGAF. It integrates elements of TOGAF framework as well as other available architectural assets, to meet the business and IT needs of an organization.

The TOGAF ADM defines a recommended sequence for the various phases and steps involved in developing an architecture, but it cannot recommend a scope – this has to be determined by the organization itself, bearing in mind that the recommended sequence of development in the ADM process is an iterative one, with the depth and breadth of scope and deliverables increasing with each iteration. Each iteration will add resources to the organization’s Architecture Repository.

The ADM, Enterprise Continuum, and Architecture Repository

The Enterprise Continuum provides a framework and context to support the leverage of relevant architecture assets in executing the ADM. These assets may include architecture descriptions, models, and patterns taken from a variety of sources, as explained in Enterprise Continuum & Tools.

The Enterprise Continuum categorizes architectural source material – both the contents of the organization’s own enterprise repositories and the set of relevant, available reference models and standards in the industry.

The practical implementation of the Enterprise Continuum will typically take the form of an Architecture Repository (see Architecture Repository) that includes reference architectures, models, and patterns that have been accepted for use within the enterprise, and actual architectural work done previously within the enterprise. The architect would seek to re-use as much as possible from the Architecture Repository that was relevant to the project at hand. (In addition to the collection of architecture source material, the repository would also contain architecture development work-in-progress.)

The criteria for including source materials in an organization’s Architecture Repository will typically form part of the enterprise architecture governance process. These governance processes should consider available resources both within and outside the enterprise in order to determine when general resources can be adapted for specific enterprise needs and also to determine where specific solutions can be generalized to support wider re-use.

While using the ADM, the architect is developing a snapshot of the enterprise’s decisions and their implications at particular points in time. Each iteration of the ADM will populate an organization-specific landscape with all the architecture assets identified and leveraged through the process, including the final organization-specific architecture delivered.

“Architecture development is a continuous, cyclical process, and in executing the ADM repeatedly over time, the architect gradually adds more and more content to the organization’s Architecture Repository. Although the primary focus of the ADM is on the development of the enterprise-specific architecture, in this wider context the ADM can also be viewed as the process of populating the enterprise’s own Architecture Repository with relevant re-usable building blocks taken from the “left”, more generic side of the Enterprise Continuum”

In fact, the first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources such as TOGAF, as well as the IT industry at large, that could be leveraged in support of the effort.

Subsequent executions will be easier, as more and more architecture assets become identified, are used to populate the organization’s Architecture Repository, and are thus available for future re-use.

The ADM and the Foundation Architecture

The ADM is also useful to populate the Foundation Architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture. This could be a set of re-usable common models, policy and governance definitions, or even as specific as overriding technology selections (e.g., if mandated by law). Population of the Foundation Architecture follows similar principles as for an enterprise architecture, with the difference that requirements for a whole enterprise are restricted to the overall concerns and thus less complete than for a specific enterprise.

ADM and Supporting Guidelines and Techniques

ADM Guidelines and Techniques is a set of resources – guidelines, templates, checklists, and other detailed materials – that support application of the TOGAF ADM.

Architecture Development Cycle

Key Points

The following are the key points about the ADM:

The ADM is iterative, over the whole process, between phases, and within phases (see Applying Iteration to the ADM). For each iteration of the ADM, a fresh decision must be taken as to:

  • The breadth of coverage of the enterprise to be defined
  • The level of detail to be defined
  • The extent of the time period aimed at, including the number and extent of any intermediate time periods
  • The architectural assets to be leveraged, including:
    • Assets created in previous iterations of the ADM cycle within the enterprise
    • Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)

These decisions should be based on a practical assessment of resource and competence availability, and the value that can   realistically be expected to accrue to the enterprise from the chosen scope of the architecture work.

As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs.

Basic Structure

The basic structure of the ADM is shown in below diagram:

Throughout the ADM cycle, there needs to be frequent validation of results against the original expectations, both those for the whole ADM cycle, and those for the particular phase of the process.

ADM9

Figure: Architecture Development Cycle

The phases of the ADM cycle are further divided into steps; for example, the steps within the architecture development phases (B, C, D) are as follows:

  • Select – reference models, viewpoints, and tools
  • Develop – Baseline Architecture Description
  • Develop – Target Architecture Description
  • Perform – gap analysis
  • Define – candidate roadmap components
  • Resolve – impacts across the Architecture Landscape
  • Conduct – formal stakeholder review
  • Finalize – the Architecture
  • Create – Architecture Definition Document

The Requirements Management phase is a continuous phase which ensures that any changes to requirements are handled through appropriate governance processes and reflected in all other phases.

An enterprise may choose to record all new requirements, including those which are in scope of the current Statement of Architecture Work through a single Requirements Repository.

Adapting the ADM

The ADM is a generic method for architecture development, which is designed to deal with most system and organizational requirements. However, it will often be necessary to modify or extend the ADM to suit specific needs. One of the tasks before applying the ADM is to review its components for applicability, and then tailor them as appropriate to the circumstances of the individual enterprise. This activity may well produce an “enterprise-specific” ADM.

One reason for wanting to adapt the ADM, which it is important to stress, is that the order of the phases in the ADM is to some extent dependent on the maturity of the architecture discipline within the enterprise –

For example, if the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work. In other cases a slightly different order may be preferred; for example, a detailed inventory of the baseline environment may be done before undertaking the Business Architecture.

The order of phases may also be defined by the architecture principles and business principles of an enterprise.

For example, The business principles may dictate that the enterprise be prepared to adjust its business processes to meet the needs of a packaged solution, so that it can be implemented quickly to enable fast response to market changes. In such a case, the Business Architecture (or at least the completion of it) may well follow completion of the Information Systems Architecture or the Technology Architecture

Another reason for wanting to adapt the ADM is if TOGAF is to be integrated with another enterprise framework (as explained in Using TOGAF with Other Frameworks).

For example, an enterprise may wish to use TOGAF and its generic ADM in conjunction with the well-known Zachman Framework, or another enterprise architecture framework that has a defined set of deliverables specific to a particular vertical sector: Government, Defense, e-Business, Telecommunications, etc. The ADM has been specifically designed with this potential integration in mind.

Other possible reasons for wanting to adapt the ADM include:

  • The ADM is one of the many corporate processes that make up the corporate governance model. It is complementary to, and supportive of, other standard program management processes, such as those for authorization, risk management, business planning and budgeting, development planning, systems development, and procurement.
  • The ADM is being mandated for use by a prime or lead contractor in an outsourcing situation, and needs to be tailored to achieve a suitable compromise between the contractor’s existing practices and the contracting enterprise’s requirements.
  • The enterprise is a small-to-medium enterprise, and wishes to use a “cut-down” method more attuned to the reduced level of resources and system complexity typical of such an environment.
  • The enterprise is very large and complex, comprising many separate but interlinked “enterprises” within an overall collaborative business framework, and the architecture method needs to be adapted to recognize this. Different approaches to planning and integration may be used in such cases, including the following (possibly in combination):
    • Top-down planning and development – designing the whole interconnected meta-enterprise as a single entity (an exercise that typically stretches the limits of practicality)
    • Development of a “generic” or “reference” architecture, typical of the enterprises within the organization, but not representing any specific enterprise, which individual enterprises are then expected to adapt in order to produce an architecture “instance” suited to the particular enterprise concerned.
    • Replication – developing a specific architecture for one enterprise, implementing it as a proof-of-concept, and then taking that as a “reference architecture” to be cloned in other enterprises.
  • In a vendor or production environment, a generic architecture for a family of related products is often referred to as a “Product Line Architecture” and the analogous process to that outlined above is termed “(Architecture-based) Product Line Engineering”. The ADM is targeted primarily at architects in IT user enterprises, but a vendor organization whose products are IT-based might well wish to adapt it as a generic method for a Product Line Architecture development.

Architecture Governance

The ADM, whether adapted by the organization or used as documented here, is a key process to be managed in the same manner as other architecture artifacts classified through the Enterprise Continuum and held in the Architecture Repository. The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.

The management of all architectural artifacts, governance, and related processes should be supported by a controlled environment. Typically this would be based on one or more repositories supporting versioned object and process control and status.

The major information areas managed by a governance repository should contain the following types of information:

Reference Data (collateral from the organization’s own repositories/Enterprise Continuum, including external data; e.g., COBIT, ITIL): Used for guidance and instruction during project implementation. This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves.

Process Status: All information regarding the state of any governance processes will be managed; examples of this include outstanding compliance requests, dispensation requests, and compliance assessments investigations.

Audit Information: This will record all completed governance process actions and will be used to support:

  • Key decisions and responsible personnel for any architecture project that has been sanctioned by the governance process
  • A reference for future architectural and supporting process developments, guidance, and precedence

The governance artifacts and process are themselves part of the contents of the Architecture Repository.

Scoping the Architecture

There are many reasons to constrain (or restrict) the scope of the architectural activity to be undertaken, most of which relate to limits in:

The organizational authority of the team producing the architecture

The objectives and stakeholder concerns to be addressed within the architecture

The availability of people, finance, and other resources

The scope chosen for the architecture activity should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned “architecture partitions” that ensure architects are not working on duplicate or conflicting activities. It also requires the definition of re-use and compliance relationships between architecture partitions.

Four dimensions are typically used in order to define and limit the scope of an architecture:

Breadth: What is the full extent of the enterprise, and what part of that extent will this architecting effort deal with?

  • Many enterprises are very large, effectively comprising a federation of organizational units that could validly be considered enterprises in their own right.
  • The modern enterprise increasingly extends beyond its traditional boundaries, to embrace a fuzzy combination of traditional business enterprise combined with suppliers, customers, and partners.

Depth: To what level of detail should the architecting effort go? How much architecture is “enough”? What is the appropriate demarcation between the architecture effort and other, related activities (system design, system engineering, system development)?

Time Period: What is the time period that needs to be articulated for the Architecture Vision, and does it make sense (in terms of practicality and resources) for the same period to be covered in the detailed architecture description? If not, how many Transition Architectures are to be defined, and what are their time periods?

Architecture Domains: A complete enterprise architecture description should contain all Four Architecture Domains (Business, Data, Application, Technology), but the realities of resource and time constraints often mean there is not enough time, funding, or resources to build a top-down, all-inclusive architecture description encompassing all four architecture domains, even if the enterprise scope is chosen to be less than the full extent of the overall enterprise.

Typically, the scope of architecture is first expressed in terms of breadth, depth, and time. Once these dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed. Techniques for using the ADM to develop a number of related architectures are discussed in Applying the ADM across the Architecture Landscape.

The four dimensions of architecture scope are explored in detail below. In each case, particularly in large-scale environments where architectures are necessarily developed in a federated manner, there is a danger of architects optimizing within their own scope of activity, instead of at the level of the overall enterprise. It is often necessary to sub-optimize in a particular area, in order to optimize at the enterprise level. The aim should always be to seek the highest level of commonality and focus on scalable and re-usable modules in order to maximize re-use at the enterprise level.

Architecture Integration

Architectures that are created to address a subset of issues within an enterprise require a consistent frame of reference so that they can be considered as a group as well as point deliverables. The dimensions that are used to define the scope boundary of a single architecture (e.g., level of detail, architecture domain, etc.) are typically the same dimensions that must be addressed when considering the integration of many architectures. Figure below illustrates how different types of architecture need to co-exist.

At the present time, the state of the art is such that architecture integration can be accomplished only at the lower end of the integratability spectrum. Key factors to consider are the granularity and level of detail in each artifact, and the maturity of standards for the interchange of architectural descriptions.

4Domains

Figure: Integration of Architecture Artifacts

What’s new in Microsoft Deployment Toolkit (MDT) 2013 !!!


Microsoft® Deployment Toolkit (MDT) 2013

Microsoft® Deployment Toolkit (MDT) 2013 is the next version of the Microsoft Solution Accelerator for operating system and application deployment in a Standard Opertaing Environment (SOE)

Being a part of Solution Accelerator, Microsoft has released the Microsoft Deployment Toolkit 2013 to cover up the latest release of R2 Series Product like Windows Server 2012 R2, System Center Configuration Manager 2012 R2 and Windows 8.1. It seems that there are no major changes except adding up R2 supports and few bug fixes from previous version of MDT (MDT 2012 Update 1)

Some of the key changes in MDT 2013 are:

MDT provides you with the following benefits:

  • Unified tools and processes, including a set of guidance, for deploying desktops and servers in a common deployment console.
  • Reduced deployment time and standardized desktop and server images.

Important – This release of MDT does not include the following features that existed in previous versions of MDT:

  • Deployment of Windows 8.1 Preview
  • Deployment of Windows Server 2012 R2 Preview
  • ZTI with
    • System Center Configuration Manager 2007
    • System Center 2012 Configuration Manager
    • System Center 2012 Configuration Manager SP1
    • System Center 2012 R2 Configuration Manager Preview
  • Use of the Windows ADK for Windows 8
  • Use of the Windows AIK for Windows 7
  • Deployment of Windows XP or Windows Server 2003
  • Deployment of Windows Vista or Windows Server 2008
  • Out-of-box Group Policy objects (GPOs) from Security Compliance Manager (SCM). Tools and GPOs must be installed with SCM before they can be used in MDT.

MDT Operating System and ADK Support

Operating System/ADK LTI ZTI UDI
Windows 8.1 Yes Yes Yes
Windows Server 2012 R2 Yes Yes No
Windows 8 Yes Yes Yes
Windows Server 2012 Yes Yes No
Windows 7 Yes Yes Yes
Windows Server 2008 R2 Yes Yes No
Windows PE version 5.0 Yes Yes Yes
Windows ADK for Windows 8.1 Yes Yes Yes

Microsoft Deployment Toolkit (MDT) 2013 is available for download and can directly access from Microsoft Download Center along with MDT 2013  guide and Release Notes.

Major Improvements in Exchange 2013’s High Availability – An Exchange Architecture Perspective!


Exchange

Exchange Server 2010

Exchange 2010 introduced a new features called Database Availability Group (DAG) has many changes to its core architecture as compared to previous version of Exchange 2007. In Exchange 2010, these new features such as incremental deployment, mailbox database copies, and available database copies works in a groups along with other features such as shadow redundancy and transport dumpster to provides a new, unified platform for High Availability and Site Resilience.

In other words, we’d experience quite substantial downtime with Exchange Server 2007 SP3 (CCR and SCR) features while restoring the database. Fortunately, Exchange 2010 DAG overcomes these limitations and avoids this substantial downtime in email services.  Important point here is that we are not talking about one Exchange server mirroring with another – It actually goes further into mailbox database level where mailbox database copies will be shared between Exchange servers.

At any point in time, only one mailbox database copy will be active while the other mailbox database copy will stay in standby mode and will be upto date in healthy state. In Exchange 2010, Administrator can add up to 16 Mailbox servers to a DAG and potentially have 16 copies of each Mailbox database

No doubt, Exchange 2010 has made tremendous achievement in terms of site resilience for the messaging service and data as compared to previous version of Exchange. By using the native site resilience features in Exchange 2010 and proper planning, you will be able to activate a second datacenter to serve a failed datacenter’s clients. The process you perform to do this is referred to as a datacenter switchover. This is a well-documented and generally well-understood process, although it takes time to perform, and it requires Administrator intervention in order to begin the process.

As we all experienced, a datacenter switchover in Exchange 2010 is operationally complex. This is because recovery of mailbox database (DAG) and client access (namespace) are tied together in Exchange 2010. This leads to other challenges for Exchange 2010 in certain scenarios:

If you lose a significant portion of Client Access servers, or CAS Array, or if you lose a significant portion of DAG, you were in a situation where we needed to do a datacenter switchover.

You could deploy a DAG across two datacenters and host the witness in a third datacenter and enable failover for the Mailbox role for either datacenter. But you didn’t get failover for the messaging service, because the namespace still needed to be switched over for the non-Mailbox roles.

But all saying that, the biggest challenge with Exchange 2010 is that the namespace is a single point of failure. In Exchange 2010, the most significant single point of failure in the messaging system is the Published FQDN that you provide to end users because it tells the user where to connect. Changing the IP address for that Published FQDN is not that easy because you have to change DNS and deal with DNS latency, which in some parts of the world is very bad. And you have name caches in browsers which are typically around 30 minutes or more that also have to be dealt with.

Exchange Server 2013

In Exchange 2013, the DAG architecture remains unchanged but there are plenty of enhancements in Exchange 2013’s high-availability

Reduction in IOPS over Exchange 2010: In Exchange 2013, the system is able to provide fast failover because it’s using a high checkpoint depth on the passive copy (100 MB) as compared to low checkpoint depth (5 MB) in Exchange 2010.

By using 100-MB checkpoint depth on passive copy, they’ve been de-tuned to no longer be so aggressive. As a result of increasing the checkpoint depth and de-tuning the aggressive pre-reads, IOPS for a passive copy is about 50 percent of the active copy IOPS in Exchange 2013 and IOPS for a passive database copy is not equal to IOPS for an active copy as it was in Exchange 2010

As a result of these changes, Exchange 2013 provides a 50 percent reduction in IOPS over Exchange 2010

Multiple Databases Per Volume: Exchange 2013 is optimized in such a way so that it can use large, multi-terabyte disks in a JBOD configuration more efficiently.

With multiple databases per volume, you can have the same size disks storing multiple database copies, including lagged copies. The goal is to drive the distribution of users across the number of volumes that exist, providing you with a symmetric design where during normal operations each DAG member hosts a combination of active, passive, and optional lagged copies on the same volumes.

Another benefit of using multiple databases per volume is that it reduces the amount of time to restore data protection in the event of a failure that necessitates a reseed (for example, disk failure)

Auto-Reseed: In Exchange 2013, Auto-Reseed is designed to automatically restore database redundancy after a disk failure by using spare disks that have been provisioned on the system. In the event of a disk failure where the disk is no longer available to the operating system, or is no longer writable, a spare volume is allocated by the system, and the affected database copies are reseeded automatically.

AutoReseed is integrated with multiple databases per volume and it is capable of restoring redundancy for multiple databases in parallel.

Managed availability: Exchange 2013 server roles include a new monitoring and high availability feature known as Managed Availability.

With the Exchange Server 2013 Management Pack, Managed Availability is also integrated with Microsoft System Center Operations Manager (SCOM). Any issues that Managed Availability escalates are sent to SCOM via an event monitor

Managed Availability includes three main asynchronous components that are constantly doing work. Administrators remain in control with the ability to configure server-specific and global overrides.

Probe Engine: Responsible for taking measurements on the server and collecting the data; results of those measurements flow into the monitor.

Monitor: Contains business logic used by the system to determine whether something is healthy, based on the data that is collected and the patterns that emerge from all collected measurements.

Responder Engine: Responsible for recovery actions. When something is unhealthy, the first action is to attempt to recover that component via multi-stage recovery actions that can include recycling an application pool, service, server and removing a server from service.

If recovery actions are unsuccessful, Managed Availability escalates the issue to a human through event log notifications.

High Availability Message Flow: In Exchange 2013, A Mailbox server receives a message from any SMTP server that’s outside the Transport high availability boundary. The Transport high availability boundary is a database availability group (DAG) or an Active Directory site in non-DAG environments

Before acknowledging receipt of the primary message, the primary Mailbox server initiates a new SMTP session to a shadow Mailbox server within the Transport High Availability boundary and makes a shadow copy of the message. In DAG environments, a shadow server in a remote Active Directory site is preferred.

The primary server processes the primary message and delivers it to users within the Transport high availability boundary or relays it to the next hop. The primary server queues a discard status for the shadow server that indicates the primary message was successfully delivered, and the primary server moves the primary message into the local Primary Safety Net.

The shadow server periodically polls the primary server for the discard status of the primary message.

When the shadow server determines the primary server successfully delivered the primary message or relayed it to the next hop, the shadow server moves the shadow message into the local Shadow Safety Net.

The message is retained in the Primary Safety Net and the Shadow Safety Net until the message expires.

Site Resilience: In Exchange 2013, significant changes have been made to address the challenges of Exchange 2010 site resilience. With the Namespace Simplification, Consolidation of Server Roles (this seems to be the biggest change to the Exchange architecture in the 2013 release is the consolidation of roles that were introduced in Exchange 2007 – Now all 5 Exchange Roles has been consolidated into CAS and Mailbox Role in Exchange 2013), Separation of CAS Array and DAG Recovery, and Easier Load Balancing changes. Exchange 2013 provides new Site Resilience options, such as the ability to use a single Global Namespace.

In addition, for customers with more than two locations in which to deploy messaging service components, Exchange 2013 also provides the ability to configure the messaging service for Automatic Failover in response to failures that required manual intervention in Exchange 2010.

As Microsoft Exchange Server 2013 adds a lot of other features as well, so to go through all features in details please visit to Alan Maddison’s TechNet Magazine Article –“Microsoft Exchange Server 2013: E-mail improved” – http://technet.microsoft.com/en-us/magazine/jj851175.aspx

%d bloggers like this: