Вы находитесь на странице: 1из 37

RFP Supporting Solution Doc for MSTD

Contents
Directory Services ....................................................................................................... 6
1.

Overview of Directory Services .......................................................................... 6

2. GOAL for AD DS deployment ................................................................................... 7


a. Improving the Security of the MSTD AD Infrastructure ............................................................... 7
b. Global Logon ................................................................................................................................. 7
c. Sharing Active Directory Contact Objects across AD Forests ....................................................... 7
d. Sharing AD-Dependent Applications across AD Forests ............................................................... 8
e. Optimize Rapid Reconfiguration/Agility ....................................................................................... 8
f. Optimize Affordability/Efficiency .................................................................................................. 8

3.

AD DS Current Scenario of MSTD. ...................................................................... 8

4.

Infrastructure for AD DS..................................................................................... 8

5.

AD DS Solution Design Archtecture. ................................................................... 8

a)

IMPLENTATION DECISIONS .................................................................................................... 8

Domain Name ............................................................................................................. 9


Domain Controller at Site:-............................................................................................................. 10

1 Scope of Mailing and Messaging .......................................................................... 18


2 Technical Requirements ...................................................................................... 20
2.1

Messaging ............................................................................................................................ 20

2.2

Unified Communication ....................................................................................................... 21

3 Messaging using Exchange 2013 .......................................................................... 22


3.1

Overview of Exchange 2013 ................................................................................................ 22

3.2

Exchange 2013 Server Roles ................................................................................................ 23

3.3

Exchange 2013 Server Editions ............................................................................................ 24

3.4

Supported Operating Systems for E2K13 ............................................................................ 24

3.5

Active Directory Dependencies ........................................................................................... 24

3.6

High Availability and Site Resiliency Approach.................................................................... 25

2.
All Exchange roles will be combined. This makes the solution simple, completely
modular that can be expanded brick by brick as needed ........................................ 25
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

3. Layer 4 hardware load balancer is recommended for load balancing. .................... 25


3.7

Exchange 2013 CAPACITY DESIGN ....................................................................................... 25


3.7.1

Global Design Specifications and Assumptions ....................................................................... 26

3.7.2

Exchange Design calculator for 9842 Mailbox Users ............................................................... 26

3.7.3

Exchange 2013 core BOM ........................................................................................................ 26

3.7.4

Locations. ................................................................................................................................. 26

4. Existing Platform and Migration ......................................................................................................... 27


As per RFP MSTD Department is not expecting any migration of existing email to the exchange 2013
solution. .................................................................................................................................................. 27
5. Design Components ........................................................................................................................... 27
The primary messaging solution is to deploy new Exchange 2013 environment that spans MSTD
physical data center locations. ............................................................................................................... 27
The main goals for this solution are: ...................................................................................................... 27
Minimize end-user impact: Minimizing the end-user impact is a key goal for MSTD. Significant effort
must be made to ensure that the transition of all e-mail related services are seamless to the end-user.
................................................................................................................................................................ 27
Reliable delivery of services: The messaging environment is a mission critical component of MSTD IT
infrastructure and adheres to strict Change Management practices. The solution must be able to
integrate with existing Operational and Change processes. .................................................................. 27
Longevity of solution: The new messaging solution must endure beyond the initial implementation as
it evolves into a production state. This requires the necessary attention to ensuring that operational
knowledge is transferred to IT Services technical teams such that they can maintain uptime
requirements. ......................................................................................................................................... 27

6 Lync Server Roles ................................................................................................ 29


6.1

Front End Server and Back End Server ................................................................................ 29

6.2

Edge Server .......................................................................................................................... 30

7 Lync High Availability Design ............................................................................... 30


7.1

Central Management Store Failover ................................................................................... 32

7.2

Lync Failover scenarios ........................................................................................................ 32

7.3

Edge Server Failover Scenarios ............................................................................................ 34

8 Lync Modular Design ........................................................................................... 35


8.1

Lync 2013 Front end ............................................................................................................ 35

8.2

Lync 2013 Back Ends ............................................................................................................ 35

9 AD, Exchange and Lync Monitoring & Server Management .................................. 36


10

Overall Solution Diagram ................................................................................. 37

11

Appendix ......................................................................................................... 38
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

11.1

Microsoft Product Mapping ............................................................................................. 38

11.2

Non Functional Requirements ......................................................................................... 38

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

Imp notes: - This Document is prepared on the Basis of RFP requirement and solutions, in each
point the Document is divided into three areas, 1. Role or Service, 2. Current Architecture and
Solution.

Directory Services
1. Overview of Directory Services
A directory service provides the ability to store information about networked devices and
services, and the people who use them, in a central location within a distributed environment. A
directory service also implements the services that make this information available to users,
computers, and applications. Therefore, a directory service is both a directory (the store of this
information) and a set of services that provide the means to securely add, modify, delete, and
locate data in the directory store.
By deploying Windows Server 2012 Active Directory Domain Services (AD DS) in MSTD
environment, MSTD can take the advantage of the centralized, delegated administrative model
and single sign-on (SSO) capability that AD DS provides or MSTD can use the AD DS for the
third party SSO.
MSTD can use Active Directory Domain Services (AD DS) in Windows Server 2012 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.
Figure 1 illustrates, the benefits of AD DS and how it acts as the focal point of the Windows
Server 2012 R2 network, demonstrating how it can be used to manage identities and broker
relationships between distributed resources.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

2. GOAL for AD DS deployment


The MSTD organizes this future-state vision below goals:

a. Improving the Security of the MSTD AD Infrastructure The ability to better defend the
AD infrastructure from exploitation and minimize the risk of information compromise as
documented.
b. Global Logon the ability for any authorized MSTD user to logon to any local MSTD
network (Active Directory forest) connected to the intranet or any Internet application which will
authenticating through AD DS of MSTD (Eg:- SSO)
c. Sharing Active Directory Contact Objects across AD Forests The ability for any
authorized MSTD user to look up and find any other MSTD user natively within the desktop
Outlook client, Outlook Web Access, or authorized mobile device (e.g. Microsoft Mobile
Application).

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

d. Sharing AD-Dependent Applications across AD Forests The ability for an authorized


MSTD user in one AD forest to securely access applications or systems located in a different AD
forest.
e. Optimize Rapid Reconfiguration/Agility Enhance the ability of Windows networks to
respond to changing mission needs and the ability to quickly reconstitute following a partial
network loss or breach.
f. Optimize Affordability/Efficiency Reduce the overall complexity and cost of operating and
defending MSTD networks by supporting their networks through AD consolidation and
rationalization.

3. AD DS Current Scenario of MSTD.


a) Currently MSTD is not having any AD Structure at any location.
b) The Domain Name is using as per the third party solution which is in the name of
MAHAVAT.GOV.IN
c) No Single or Multiple Forest Structure.

4. Infrastructure for AD DS.


a) Current Scenario: - Currently MSTD does not having any existing infrastructure.
b) Solution Design :1) Hardware: - PDC and DRC will have the 2 Physical Hosts of HP BL660 Gen8 at
each site on which Domain Controller will be deployed on Hyper-V instance.
2) Software :- AD DS will be configure on virtual OS of Windows 2012 Std.
Edition

5. AD DS Solution Design Archtecture.


a) IMPLENTATION DECISIONS
a) The following decisions were made in regard to the design and implementation:
Single forest, single domain model
b) Delegated Domain Name Server zones
c) Single Sign On accounts will be in the root Domain in People OU segregated by
Managed By affiliation (including users and groups).
d) Local accounts, used for service accounts, will be located in departmental OU.
e) Centralized DNS and WINS will be provided
f) Physical access to Domain Controllers limited to Data Center
g) Enterprise administrators will only make changes to Departmental Organizational Units
In emergencies after going through proper change control.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

6. AD Setup
h) The AD Services will be setup on the Virtual Instance of windows 2012 Std. Edition, as a
Single forest, single domain model.

7. Forest and Domain


A) Current Scenario: - Currently MSTD does not having any forest structure.
B) Solution Design: - New Domain will be deployed with name of
MAHAVAT.GOV.IN as per the single forest basis. In the deploying face we are
going to deploy the two AD DS server at each site (PDC 2 no. and DRC 2 no.).
Out of the two AD servers which are in PDC (Primary Data Center) one will be
the primary Domain Controller and another server will act as ADC (Additional
Domain Controller) and 2 at DRC which will also be the additional Domain
controller in this Domain.

Below is the Architecture of one forest two sites architecture.


MSTD Forest.

PDC

ADC1

DC Site

ADC2

ADC3

DRC Site

8. Domain Name
Active Directory domains can be identified using a DNS name, which can be the same as an
organization's public domain name, a sub-domain or an alternate version (which may end in
.local). While Group Policy can be applied to an entire domain, it is typical to apply policies to
sub-groups of objects known as organizational units (OUs). All object attributes, such as
usernames, must be unique within a single domain and, by extension, an OU.
A) Current Scenario: - Currently MSTD is using the Domain name as Mahavat.gov.in
with XYZ IP Address provided by ISP.
B) Solution Design : MSTD can use the same Domain for the new infrastructure setup this domain
system will also be used to mailing users. But at the time of implementation, the
new public IP nee to edit in the register DNS.
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

10

MSTD should take a specific down time for the changes of IP address from
existing to new IP address.

9. Domain Controller at Site:When you create the first domain controller in your organization, you are also creating the first
domain, the first forest, the first site, and installing Active Directory. Domain controllers running
Windows Server 2003 store directory data and manage user and domain interactions, including
user logon processes, authentication, and directory searches. Domain controllers are created by
using the Active Directory Installation Wizard.
It is often good practice to put at least one domain controller in each site to enhance network
performance. When users log on to the network, a domain controller must be contacted as part of
the logon process. If clients must connect to a domain controller located in a different site, the
logon process can take a long time. The best network performance is available when the domain
controller at a site is also a global catalog. This way, the server can fulfill queries about objects in
the entire forest. However, enabling many domain controllers as global catalogs can increase the
replication traffic on your network
A) Current Scenario: - MSTD does not have any Domain Controller at both the site.
B) Solution Design:MSTD will deploy the total four Domain Controller in both the site (2 at Each Site),
PDC (primary Data Center) will have two 2 Domain Controller out of which one will
be the Primary Domain and Other one will be the ADC (Additional Domain
Controller), Another Site (DRC) will have 2 Domain controller and both the server
will act as an ADC.
Reason for 2 Domain Controller at each Site: - MSTD will deploy the 2
Domain controller at each site for Disaster Recovery Purpose, If one DC fails the
user will not having any Impact for logon. This will required a zero down time.

10.

Domain and Forest Functional Level.

When you install Active Directory Domain Services (AD DS), a set of basic Active Directory
features is enabled by default. In addition to the basic Active Directory features on individual
domain controllers, there are new domain-wide and forest-wide Active Directory features
available when all domain controllers in a domain or forest are running a later version of
Windows Server.
A) Current Scenario: - MSTD does not have any Domain.
B) Solution Design: - The Functional level of the Domain will be Windows 2008.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

11

11.

FSMO Roles (Flexible Single Master of Operation)

During installation of Active Directory on a Windows Server 2000/2003/2008/2012 all FSMO roles
will automatically be installed on the first server. But Best Practice dictates to move some of this
Flexible Single Master of Operation (FSMO) roles to separate servers

A) Current Scenario: - MSTD does not have any Domain.


B) Solution Design: - MSTD will have 2 Domain Controller in PDC site, Out of which
as per the best practice Forest Roles will be places on the PDC and Domain Roles will
be places in the ADC.
Reason for FSMO role on Different Server: Out of 5 roles the Infrastructure
Master role will be on the same site, if we keep the Domain Roles in ADC1 at
PDC location, there no need to define the GC at the same site.

12.

AD Site & Service.

Active Directory Sites and Services is a Microsoft Management Console (MMC) snap-in that you can
use to administer the replication of directory data among all sites in an Active Directory Domain
Services (AD DS) forest. This snap-in also provides a view of the service-specific objects that are
published in AD DS.
Administrators who are responsible for forest-wide service administration can use Active Directory
Sites and Services to manage the intersite replication topology for the forest. Administrators who
are responsible for application services can be delegated responsibility for the service containers
into which application-specific objects are published

A) Current Scenario: - MSTD does not have any forest or Domain.


B) Solution Design: - MSTD will configure site and services as per the location and
each location will be added as per the below configuration steps. For this activity
MSTD should provide the Site Map of MSTD.

The tasks for configuring a new site include the following:

13.

Creating the site


Mapping the correct IP addresses to the site by creating a subnet
Linking the site to another site or sites by creating a site link and adding the
new site to it

AD Global Catalog.

The global catalog is a distributed data repository that contains a searchable, partial
representation of every object in every domain in a multidomain Active Directory Domain
Services (AD DS) forest. The global catalog is stored on domain controllers that have been
designated as global catalog servers and is distributed through multimaster replication. Searches
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

12

that are directed to the global catalog are faster because they do not involve referrals to different
domain controllers.
The global catalog provides the ability to locate objects from any domain without having to know
the domain name. A global catalog server is a domain controller that, in addition to its full,
writable domain directory partition replica, also stores a partial, read-only replica of all other
domain directory partitions in the forest. The additional domain directory partitions are partial
because only a limited set of attributes is included for each object. By including only the
attributes that are most used for searching, every object in every domain in even the largest forest
can be represented in the database of a single global catalog server.
Benefit for the GC Services.

User Logon Support faster


Universal Group Membership
User Principal Name,
Universal Group Membership Caching
Address Book Lookups :- Exchange Server uses the global catalog to store mail recipient data
that enables clients in a forest to send and receive e-mail messages
A) Current Scenario: - MSTD does not have any GC server.
B) Solution Design: - MSTD will configure GC services on one Domain Controller at
each site PDC and DRC. GC Services is needed because at both site Exchange Server
will be implemented which will require GC services for faster Addressbook Lookups

14.

AD Replication between Two Sites.

The replication topology of Active Directory directory service provides the network of connections
between domain controllers in a forest according to their location in Active Directory sites. A site is
an Active Directory object that you create and configure to represent an area of good network
connectivity, typically corresponding to a local area network (LAN). The site object is associated with
a set of one or more subnets, which are objects that identify a range of IP addresses. Each domain
controller has an IP address that maps to a subnet, and that mapping in turn identifies the site of the
domain controller. By recognizing domain controllers according to site locations, the replication
system ensures that each domain controller is updated with directory changes in the most efficient
and timely manner possible, given network conditions and directory service configuration. The
replication topology is generated automatically at regular intervals to accommodate network and
configuration changes, and is designed to ensure that all domain controllers are connected without
redundancy and with minimum cost.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

13

A) Current Scenario: - MSTD does not have any site currently so no current replication
tropology is present.
B) Solution Design: - Two Site replication will happen as per the below Map.

15.

AD DNS.

Domain Name System (DNS) is a system for naming computers and network services that is
organized into a hierarchy of domains. DNS naming is used in TCP/IP networks, such as the
Internet, to locate computers and services with user-friendly names. When a user enters a
DNS name in an application, DNS services can resolve the name to other information that is
associated with the name, such as an IP address.
For example, most users prefer a friendly name, such as corp.contoso.com, to locate a
computer, such as a mail server or Web server, on a network. A friendly name can be easier
to learn and remember. However, computers communicate over a network by using numeric
addresses. To make the use of network resources easier, name systems such as DNS provide
a way to map the user-friendly name for a computer or service to its numeric address.
The DNS Server role in Windows Server 2012 combines support for standard DNS protocols
with the benefits of integration with Active Directory Domain Services (AD DS) and other
Windows networking and security features, including such advanced capabilities as secure
dynamic update of DNS resource records

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

14

a) DNS Server features

A Request for Comments (RFC)-compliant DNS server


Interoperability with other DNS server implementations
Support for Active Directory Domain Services (AD DS)
Enhancements to DNS zone storage in AD DS
Conditional forwarders
Stub zones
Enhanced DNS security features
Integration with other Microsoft networking services3

Current Scenario: - MSTD does not have any Domain.


Solution Design: - AD Administrator will configure Primary Domain Controller
as DNS server, which will have all the A Record , SRV Record &
CNAME Record if require. This DNS server will work as a gateway for the
local machine. To access the internet and other application which will
authenticate by local domain.

16.

AD Schema.

Active Directory Schema is a Microsoft Management Console (MMC) snap-in that you can use to
view and manage the Active Directory Domain Services (AD DS) schema.
Current Scenario: - MSTD does not have any Domain.
Solution Design: - By default Schema will be installed with AD Directory
Services enabled, But due to Exchange 2013 in the MSTD infrastructure going to
deployed, Administration team need upgrade the Schema. This Schema will be
upgraded at the time of First Exchange Instance installation with the below help
command line.
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

17.

Computer and User Policy Management in AD.

Group Policy is an infrastructure that allows you to specify managed configurations for users and
computers through Group Policy settings and Group Policy Preferences. You can manage Group
Policy settings and Group Policy Preferences in an Active Directory Domain Services (AD DS)
environment through the Group Policy Management Console (GPMC). By using Group Policy, you
can significantly reduce our organizations total cost of ownership. Various factors, such as the large
number of policy settings available, the interaction between multiple policies, and inheritance
options, can make Group Policy design complex.
Current Scenario: - MSTD does not have any group policy.
Solution Design: - AD administrator will configure the all the new Group Policys
through (GPMC) tool which will done after the basic installation of AD services.
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

15

MSTD Management needs to discuss and Finalize the changes which is require to do
through GP.
Below is some of the application or services which we can controller through GP.
(lockout policy , screen saver settings , logon scripts publishing , folder shares allotment ,
populate desktop icons ,assign printers , to limit Internet explorer options as a result of
Managed Administrative Templates, USB disabled , Delegation Rights)

18.

AD DHCP.

Dynamic Host Configuration Protocol (DHCP) is a client-server technology that allows DHCP servers
to assign, or lease, IP addresses to computers and other devices that are enabled as DHCP clients.
When DHCP servers are deployed on our network, we can automatically provide client computers
and other TCP/IPv4 and IPv6 based network devices with valid IP addresses.
Current Scenario: - MSTD does not have any DHCP configure in any AD.
Solution Design: - AS per the new Infrastructure of PDC and DRC currently
there is no requirement of DHCP Services, But if Changes required by MSTD
management, AD administrator will enabled the DHCP services on PDC and
create the Scope as per network Subnet.

19.

AD OU Structure.

After domain planning is complete, an OU structure can be designed. In the best practices
OU model, departments within the domain manage their internal operations, while the
domain's IT staff manages the overall infrastructure. In other words, each department
manages its objects in the directory, while the domain IT staff manages the configuration of
the directory service itself.
Best practices for creating an OU design introduces the role of "OU owner." The Active
Directory OU owner is comparable to most Windows 2012 domain administrators. This
means that domain administrators who manage users and resources in a Windows 2012
domain will manage the same resources in an Active Directory domain, but will be owners of
OUs.
Expect to make periodic changes to your OU structure to reflect changes in your
administrative structure and to support policy-based administration. OUs are designed to be
easily changed.
OUs are containers within domains that can contain other OUs, users, groups, computers, and
other objects. These OUs and sub-OUs form a hierarchical structure within a domain, and are
primarily used to group objects for management purposes
Current Scenario: - MSTD does not have any OU structure. Below is the eg :- of
one location of MSTD .

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

16

Solution Design: - AS per the above CST office structure of MSTD AD


Administrator will create the OU in AD as per Type, location , Department. For
the OU Structure Configuration MSTD need to provide the complete location
chart and department chat for the OU Structure and Group policy implementation
on OU.

Below is sample OU architecture which will use in AD.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

17

20.

User and Computers creation in AD

You use Active Directory Users and Computers to manage recipients. Active Directory Users and
Computers is an MMC snap-in that is a standard part of Microsoft Windows Server operating
systems. However, when you install Exchange 2013, the setup wizard automatically extends the
functionality of Active Directory Users and Computers to include Exchange-specific tasks
You can use Active Directory Users and Computers to create new user accounts or manage existing
user accounts. Below is some of the example for which we can use AD User and Computer Snap-in
i)
j)
k)
l)
m)
n)
o)
p)
q)
r)

Understanding User Accounts


Create a New User Account
Reset a User Password
Copy a User Account
Move a User Account
Set Logon Hours
Disable or Enable a User Account
Map a Certificate to a User Account
Change a User's Primary Group
Delete a User Account
Current Scenario: - MSTD does not have any AD structure.
Solution Design: - AD administrator will create the User and Computer account
as per the MSTD requirement. Currently MSTD is having the following User and
Computer account setup which will be standardized as per new requirement at the
time operation face.

Current User creation sample:-

21.

AD Services Failover in Hyper-V Structure.

Windows Server 2012 Hyper-V also introduces VM-Generation ID (VMGenID). VMGenID provides a
way for the hypervisor to communicate to the guest OS when significant changes have occurred. For
example, the hypervisor can communicate to a virtualized DC that a restore from snapshot has
occurred (Hyper-V snapshot restore technology, not backup restore). AD DS in Windows Server 2012
is aware of VMGenID VM technology and uses it to detect when hypervisor operations are
performed, such as snapshot restore, which allows it to better protect itself.
Hyper-v Failover.
When a Hyper-V replica failover occurs (planned or unplanned), the Windows Server 2012
virtualized DC detects a VMGenID reset, triggering the aforementioned safety features. Active
Directory operations then proceed as normal. The replica VM runs in place of the primary VM.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

18

Current Scenario: - MSTD does not have any VM or Hyper-V setup


Solution Design :- Hyper-V administrator will create a virtual windows 2012 Std. OS
Instance on each HP BL660 Gen8 Host, 2 in PDC and 2 in DRC. On the Virtual
Windows 2012 instance, Active directory Domain will be setup. If any Host or Virtual
Instance fails the second Host Instance in the same Site will start acting as primary server
till the First Domain Controller Comes Up.

22.

AD Backup & Restoration.


Current Scenario: - MSTD does not have any AD so no backup procedure is done.
Solution Design: - Backup Administrator will keep the everyday backup history of AD,
The backup will take on the daily basis as per Microsoft best practice and the Symantec
Backup utility.

Messaging
1

Scope of Mailing and Messaging


The scope of Facility Management for mail and messaging service will cover the following aspects:
Maintenance of hardware of all units such as the Mail Messaging and other Servers, Security, Backup
and Storage Systems etc. supplied by the SI.
Configuring/ re-configuring end-to-end solution by securing all the hardware, system software,
Databases, Application software configurations, whenever required as per the requirements of the
department.
Secure the configurations as per the architecture deployed, operating systems deployed, application
software deployed etc. on ongoing basis and provide them to the department.
Maintenance and trouble shooting of Software supplied by the SI or by the department for running
the total Mail Messaging System (end-to-end) including patch and vulnerability management as per
departments requirement and version upgrades of Operating Systems and Application Software,
Hardening of the operating system/application software and other software components installed
for the solution, Implementation of security Policy, configuring storage and backup devices and
backup policies etc. as per the requirement of the department.
Follow Change Management and configuration controls as per MSTD policy. Assessing impact of
change on the security and implement after obtaining permission from MSTD.
Maintenance trouble shooting of Shared Storage Space if deployed by the SI till integration of the
same with the overall domain controlling system proposed to be set up by the department.
Maintaining reports with respect to SLA/ uptime guaranteed and submission of reports on Monthly
basis as per requirement of the MSTD

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

19

Day to day Management of mail messaging Servers and the related servers, storage, backup and security
systems such as

Management of mail boxes.


Configuring, maintaining and monitoring of the message policies, Group policies, user
security, message security policies etc. duly updating as per the policies of the MSTD
periodically.
Configuring, maintaining and monitoring the anti-virus, anti-spam solutions duly updating
them with latest version by coordination with the respective suppliers.
Coordinating with the MSTD officials for updating the mail messaging policies as per the
requirements.
Ensuring proper working of all the components of Mail Message Solution deployed by the SI
such as Mail transfer, Mail Storage, Authorization/Directory Services, Global Filtering,
Mobile Access, and Web Access etc.
Monitoring and trouble shooting of the mail message systems including the security, storage
and backup systems.
Maintenance and management of email Routing, lists, redirection and address books.
Implementing Security, storage and backup policies related to mail traffic on an on-going
basis as per the policies of the MSTD. Configuring and maintaining authentication and
encryption services using authentication server, tokens, smart cards etc. as per the
requirement of the MSTD.
Taking backup of system software, Databases and backup of mail data as per the policies of
the MSTD.
Assisting the MSTD in implementing, monitoring, testing contingency plans, drills and
recovery operations as per the policies of the MSTD and switching to DR setup when the
original setup fails.
Assisting the MSTD in verification of Security implementation and implementing/ updating
the same as per instructions of the MSTD. To run integrity checks daily, baselines secure
configurations and maintain them as per the MSTDs requirement.
Configuring, securing and analyzing the System Logs, audit logs etc. and provide information
on the system performance, review of the above logs to the MSTD. To undertake fine tuning
of the system performance basing on the above reports, if required, with the permission of
the MSTD.
Address the documentation requirements as per the MSTDs requirement.
Configure/ reconfigure duly Deploying, managing anti -virus, anti- spam, anti-phishing, antipharming. Configure spam, malicious content, configuring negative/positive list, domain
filtering, blocking black listed domains and IP Addresses etc. as per MSTDs requirements.
Pro-active coordination with the vendors of hardware and software systems related to mail
messaging solution including security, storage and backup systems.
Coordinating with their backend logistic for hardware and/or technical support for early
rectification and Maintaining the uptime as per SLA.
Gathering and presentation of statistical data related to mail messaging traffic to the MSTD.
Running the Help Desk for assisting the users of the MSTD centrally at HQ.
Co-ordination with any other Provider facilitating SMTP Broad Cast/ Relay Broad Cast.
Providing the MIS reports Daily/ Monthly as per the requirement of the MSTD from time to
time.
Built-in lists for screening common business terms, profanity and compliance terms.
Anti-virus and malware engine.
Pre-emptive blocking of suspicious messages based on traffic pattern behavior.
Image logic to detect and block pornographic image content as well as detect corporate
defined images.
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

20

Data Synchronization with ActiveSync like application to synchronize emails, calendar,


contacts and tasks.
Any other matter related to the mail messaging solution as per the requirement of the MSTD.

Technical Requirements
Below are the business and functional requirements that the target messaging system
should meet as understood at this stage. These requirements will be mapped to different
solution areas throughout the proposal document.

2.1

Messaging
Below is the Current users count and Mail box Size limit which is provided in RFP. As per MSTD users
count trend will increase every month wise.
Requirement
Exchange Version

Total Number
users (9842)

Details
2013

of

Primary
mailbox
quota in GB
4 GB (1075) and 2 GB
(8767)

Archive size in GB
4 GB (1075) and 2 GB
(8767)

Designation

Current Sanctioned Posts

Commissioner of Sales Tax


Special Commissioner of Sales Tax
Chief vigilance Officer
Additional Commissioner of Sales Tax
Joint Commissioner of Sales Tax
Deputy Commissioner of Sales Tax
Assistant commissioner of Sales Tax

1
1
1
9
72
401
590

Sales Tax Officer


Sales Tax inspector
Clerk
Total

1191
4726
2850
9842

Designation

Mail Box Storage Size

Joint Commissioner and Above


Deputy Commissioner
Assistant Commissioner
Sales Tax Officer
Sales Tax Inspector
Clerk

4 GB
4 GB
4 GB
2 GB
2 GB
2 GB

Designation

Mail Box Storage Size

Joint Commissioner and Above


Deputy Commissioner
Assistant Commissioner
Sales Tax Officer

4 GB
4 GB
4 GB
2 GB

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

21

Sales Tax Inspector


Clerk
Total
mail
sent
/received per day
Average message size
in KB
HA Required
DR Requirement
Load balancing
Client Support

2.2

2 GB
2 GB

50 (Assumption)
75 (Assumption)
Yes
Yes
Physical Load balancer to be deployed for mail flow.
Outlook Web access , POP & IMAP access
Outlook anywhere for internal as well as external users
Outlook (2007 and higher) & Active-Sync

Unified Communication
Instant Messaging: Instant messaging service (real-time interaction) should be provided to all the
Department users to facilitate inter and intra office communication.
Voice and Video Chat: The Voice and Video chat feature should allow the officers of the Department
to communicate with each other using live chat, video conferencing and real-time content sharing
(documents, presentations, images, etc.) This feature will be allowed for Deputy Commissioners and
above. Inter-office video conferencing facility will be enabled only during department mandated
time-slots for optimal utilization of the WAN. Intra-office video conferencing will be permissible
throughout the day over the LAN.

Current Scenario :- MSTD does not having any standard Unified Communication
device
Solution Design: - Infrastructure Team is going to deploy the New Communication Lync
Server through which below specified designation users will get the facility of unified
communication as per RFP.

Designation

e-mail

Instant Messaging Voice & Video


(Chat)
Conference

Joint Commissioner and Above


Deputy Commissioner
Assistant Commissioner
Sales Tax Officer
Sales Tax Inspector
Clerk

Yes
Yes
Yes
Yes
Yes
Yes

Yes
Yes
Yes
No
No
No

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

Yes
Yes
No
No
No
No

22

3
3.1

Messaging using Exchange 2013


Overview of Exchange 2013
Exchange 2013 is the next major release after Exchange 2010. This version offers significant
enhancements on its core functionalities such as e-mail, calendaring, voice messaging, and mobility.
New features are also introduced in the areas of server management, high availability, and
governance.
The key features of Exchange 2013 are summarized in the table below:
Business Needs

Exchange 2013 Features

Flexible and Reliable

Enable
Availability

Continues

Simplify Administration

Collaborate Effectively

Protection and Compliance

E-mail Archiving

Cost Effective Storage

Provide the flexibility needed to operate a scalable, high performing,


and easy to administer messaging infrastructure
Single platform for High Availability and Disaster Recovery
Role-based administration and user self-service
Simplified Mailbox High Availability and Disaster Recovery with New
Unified Platform
Evolution of Continuous Replication technology using Database
Availability Groups (DAGs)
Easier than traditional clustering to deploy and manage
Allows each database to have 16 replicated copies
Provides full redundancy of Exchange roles on as few as two servers
Empower Specialist Users to Perform Specific Tasks with Role-based
Administration
A Familiar and Rich Outlook Experience Across Clients, Devices and
Platforms
Ease Collaboration by Federating Calendar Details with External
Business Partners
E-mail archiving and more powerful retention policies
New Transport Rules for automated protection of e-mail
Powerful multi-mailbox search UI for eDiscovery
Manage Mail in a Central Archive While Maintaining a Familiar User
Experience
Apply Granular Per Message and Per Folder Policies as well as
Litigation/In Place Hold
Empower Compliance Officers to Conduct Multi-Mailbox Searches
with Ease
Designed for SATA and JBOD configuration
Reduction in IOPS from Exchange 2010, Smoother IO patterns,
Resilience against corruption

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

23

3.2

Exchange 2013 Server Roles


For Microsoft Exchange 2013, there have been major architectural changes to the Exchange server
roles. Instead of the five server roles that were present in Exchange 2010 and Exchange 2007, in
Exchange 2013, the number of server roles has been reduced to two: the Client Access server and
the Mailbox server. As a result of these architectural changes, there have been some changes to
client connectivity.
First, RPC is no longer a supported direct access protocol. This means that all Outlook connectivity
must occur using RPC over HTTPS (also known as Outlook Anywhere). At first glance, this may seem
like a limitation, but actually it provides some added benefits. The most obvious benefit is that
theres no need to have the RPC Client Access service on the Client Access server. Two fewer
namespaces are required for a site-resilient solution than were required in Exchange 2010, and its
no longer necessary to provide affinity for the RPC Client Access service. Also, Outlook clients no
longer connect to a server fully qualified domain name (FQDN) as theyve done in all previous
versions of Exchange. Using Autodiscover, Outlook finds a new connection point made up of the
users mailbox GUID + @ + the domain portion of the users primary SMTP address
The table below summarizes the available roles in Exchange 2013:
Role

Purpose

Client Access Server

The Client Access server in Exchange 2013 functions much like a front door,
admitting all client requests and routing them to the correct active Mailbox
database. The Client Access server provides network security functionality
such as Secure Sockets Layer (SSL) and client authentication, and manages
client connections through redirection and proxy functionality. The Client
Access server authenticates client connections and, in most cases, will proxy
a request to the Mailbox server that houses the currently active copy of the
database that contains the user's mailbox. The Client Access server provides
authentication, limited redirection, and proxy services, and offers all the
usual client access protocols: HTTP, POP and IMAP, and SMTP. The Client
Access server, a thin and stateless server, doesnt do any data rendering.
Theres never anything queued or stored on the Client Access server

Mailbox server

The Mailbox server includes all the traditional server components found in
Exchange 2010: the Client Access protocols, the Transport service, the
Mailbox databases, and Unified Messaging (the Client Access server redirects
SIP traffic generated from incoming calls to the Mailbox server). The Mailbox
server handles all activity for the active mailboxes on that server.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

24

Current Scenario: - MSTD does not having any In house Mailing system which can
manage by MSTD administrator team.
Solution Design: - Exchange Administrator will install both the roles on 2 Virtual
Exchange 2013 Instance in both the location and addition one Mailbox Role virtual
Instance in one more server in both the location for the High Database Aviability.
Total 6 Virtual Exchange 2013 Enterprise Edition instance will be install (3 at PDC and 3
at DRC). This 6 Virtual Instance will Install in 6 different HOST (HP BL660 gen8
Server).
Exchange 2013 Server Editions
Exchange Server 2013 comes with Standard and Enterprise editions. The Standard Edition is usually
targeted for small deployments or distributed branch servers. The Enterprise Edition, on the other
hand, addresses large and complex requirements of enterprise customers.
The table below compares the features of the two editions:
Edition

Available Features

Exchange Server 2013 Standard 5 databases per server


Edition
Exchange Server 2013 Enterprise 100 databases per server
Edition

Design Recommendation :- Keeping the future scalability in mind, Exchange 2013 Enterprise edition
need to be deployed in MSTD with maximum features utilization as per RFP.

3.3

Supported Operating Systems for E2K13


The following operating systems are supported for servers running Exchange Server 2013 roles:

Windows Server 2012 Standard or Datacentre


Windows Server 2008 R2 Standard, Enterprise edition with Service Pack 1
Windows Server 2008 R2 Datacentre SP1 or later

Design Recommendation: - The recommendation is for MSTD to use Windows 2012 Standard
edition for all Exchange 2013 server roles.

3.4

Active Directory Dependencies


Microsoft Exchange Server 2013 uses Active Directory to store and share directory information with
Windows. Active Directory forest design for Exchange 2013 is similar to Exchange Server 2010,
except in a few ways, which are discussed below

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

25

The Active Directory driver is the core Microsoft Exchange component that allows Exchange services
to create, modify, delete, and query for Active Directory Domain Services (AD DS) data. In Exchange
2013, all access to Active Directory is done using the Active Directory driver itself. Previously, in
Exchange 2010, DSAccess provided directory lookup services for components such as SMTP,
message transfer agent (MTA), and the Exchange store.
The Active Directory driver also uses Microsoft Exchange Active Directory Topology
(MSExchangeADTopology), which allows the Active Directory driver to use Directory Service Access
(DSAccess) topology data. This data includes the list of available domain controllers and global
catalog servers available to handle Exchange requests
Exchange 2013 relies on Active Directory services for user authentication, permissions management,
and directory information. As a deployment prerequisite, make sure that the functional level of your
forest is at least Windows Server 2003, and that the schema master is running Windows Server 2003
with Service Pack 2 or later. Although 32-bit global catalog servers are supported, 64-bit servers
should be considered for large environments e.g. more than 20,000 Active Directory objects. 64 bit
DCs / GCs also offer a higher consolidation ratio.
Design Recommendation: - Windows Server 2012 R2 Domain Controllers / Global Catalogs are
Recommended at two datacenter.

3.5

High Availability and Site Resiliency Approach


In Exchange 2013, High Availability is attained by having a minimum of 2 or more copies of each
mailbox database in the Primary Datacenter. Collectively the above functionality in Exchange 2013 is
offered by what are called Database Availability Groups or DAGs. A database availability group
(DAG) is the base component of the high availability and site resilience framework built into
Microsoft Exchange Server 2013
The DAG is a unit of replication that can be stretched to the failover datacenter. We can have a
single DAG spread across two datacentres by adding servers from both datacentres to the DAG. This
can be achieved without requiring the two locations to be in the same AD site.
Each DAG can have up to 16 mailbox database replicas and Servers. The database in one DAG will
replicate with its configured partner in the SAME DAG only and NOT between DAGs
Design Recommendations
1. 3 copies of each mailbox database in the primary datacenter, and 3 Copies will be in DR
Datacenter. Out of 6 Copies only 1 will be active and 5 will be Passive
2. All Exchange roles will be combined. This makes the solution simple, completely modular that can
be expanded brick by brick as needed
3. Layer 4 hardware load balancer is recommended for load balancing.

3.6

Exchange 2013 CAPACITY DESIGN


This section of the document provides the detailed component level design and capacity
specifications

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

26

3.6.1

Global Design Specifications and Assumptions

The following are the Design Assumptions for the target messaging solution:

3.6.2

64 bit Global Catalogs / Domain Controllers would be assumed to get a high GC


consolidation ratio
The design will work towards an Exchange 2013 multi role configuration with Client
Access Server (CAS) and the Mailbox roles combined Design would utilize Virtual Servers
wherever possible.
Deleted Item retention for 14 days and Single Item recovery will be available for all users
Mailboxes will be sized to be 4 & 2 GB for Primary mailbox and 4 & 2 GB for Archive,
with a Send/Receive emails per day assumed to be 50 and average message size of 75 KB.
1000 GB with 15K RPM SAS disks would be used.
8 core CPUs with a minimum SPECInit value of 757 would be used.

Exchange Design calculator for 9842 Mailbox Users

The completed mailbox role requirements calculator is attached below. A detailed description of the
Design Outputs follows.

MSTD_ExchangeCalcu
lator.xlsm

3.6.3

Exchange 2013 core BOM

The core minimum Bill of Material / Bill of Quotes for the Exchange 2013 solution is summarized
from the previous sections in the table below.

Core Exchange 2013 (Minimum required) BOM for a 2 Datacenter Model


No of
Mailboxes

Exchange
2013 Server
Edition

9842

Enterprise
Edition

Active Directory Domain


Controllers / Global Catalogs

3.6.4

Number
of
Servers

Configuration

Comments

Windows 2012
R2 STD

8 Core CPU
with 96
GB of RAM

All Exchange 2013


Servers are multi-role
combining the Client
Access & Mailbox Role.

Windows 2012
R2 STD edition

2X8, 16 GB of
RAM

Operating
System Edition

Locations.

Primary Data Center


Primary Data Centre at BSNL Data Centre (BSNL-IDC).
Secondary Data Center
Faridabad. (DRC)

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

27

4. Existing Platform and Migration


As per RFP MSTD Department is not expecting any migration of existing email to the exchange 2013
solution.

5. Design Components
The primary messaging solution is to deploy new Exchange 2013 environment that spans MSTD
physical data center locations.

The main goals for this solution are:


Minimize end-user impact: Minimizing the end-user impact is a key goal for MSTD. Significant effort
must be made to ensure that the transition of all e-mail related services are seamless to the enduser.
Reliable delivery of services: The messaging environment is a mission critical component of MSTD IT
infrastructure and adheres to strict Change Management practices. The solution must be able to
integrate with existing Operational and Change processes.
Longevity of solution: The new messaging solution must endure beyond the initial implementation
as it evolves into a production state. This requires the necessary attention to ensuring that
operational knowledge is transferred to IT Services technical teams such that they can maintain
uptime requirements.
The individual design components were subjected to a stringent evaluation process that included
the following design criteria:

Costs of Ownership
Technological engineering quality
Scalability
Fault Tolerance / Reliability
Industry best practices
Supportability
Ease of administration
Compatibility with existing systems
Reliability
Vendor specifications

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

28

5.A. Hardware technology


IT Services researched the server solutions from a number of hardware vendors and made a final
decision in favor of HP vendor Equipment for the Domain , Mailing and Lync server technology.

5.A.1 Server hardware


The server platform used is the seventh generation (G8) HP BL660 server. This is an Intel based
server system. The CPUSs in these systems are standardized (E5 4657 LV2) processors. The servers
are equipped with 192 GB of memory to accommodate their specific functions.

5.A.2 Storage hardware


HP 3PAR P10400 SAN Storage

It is with Remote replication capability that is used to periodically replicate same volume is
protected on two arrays, from the Primary DC Site (PDC Mumbai) to the NDR Site (SDC Mumbai)
synchronously and Primary DC Site (PDC Mumbai) to DR Site (DRC) Asynchronously.
3PAR Remote Copy, based on 3PARs Thin Copy technology, it allows remote storage capacity to be
sized for the written data versus the approach used with traditional architectures, which size remote
storage for allocated (but unwritten) capacity. Implemented natively over IP or Fibre Channel with
only a handful of simple, intuitive commands, 3PAR Remote Copy can be configured, managed, and
tested in a matter of minutes.

5.A.3 Interconnect technology


Connectivity between Server and Storage will be achieved by redundant SAN fabrics keeping NoSPOF
architecture.

5.A.4 Server Operating Systems technology


The majority of the messaging infrastructure components will be deployed onto the Microsoft
Windows Server 2012 Operating System platform, licensed to theSTD. Version of the operating
system.

5.A.5 Message Security and Protection technology


The following Security and Protection products have been selected:
Server Virus protection: - Symantec SYMC DATA CENTER SECURITY SERVER is proposed for Servers
hosted at PDC, DRC and NDR
Symantec Protection Suite Enterprise Edition is powered with Symantec Insight and protects with
the industrys fastest, most-effective endpoint security, combined with industry-leading messaging
protection and innovative web security. It provides:

Fastest, most-effective protection, powered by Symantec Insight, for laptops, desktops,


servers, messaging and web gatewaysprotection beyond antivirus.
Catch more than 99% of spam and prevent data loss with advanced content filtering to
identify and control the flow of sensitive data in email and IM.
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

29

Web gateway security that protects against web threats, including malicious software,
spyware, botnets, viruses, and malware.
Rapid data and system recovery recovers individual files and folders in seconds or complete
Windows systems in minutes to dissimilar hardware or virtual environments

Lync Server Roles


Lync server 2013 has distinct server roles as below:

6.1

Front End Server and Back End Server


Edge Server
SQL Server

Front End Server and Back End Server


In Lync Server Enterprise Edition, the Front End Server is the core server role, and runs many basic
Lync Server functions. The Front End Servers, along with the Back End Servers, are the only server
roles required to be in any Lync Server Enterprise Edition deployment.
A Front End pool is a set of Front End servers configured identically, that work together to provide
services for a common group of users. A pool of multiple servers running the same role provides
scalability and failover capability.
The Front End Server includes the following:

User authentication and registration


Presence information and contact card exchange
Address book services and distribution list expansion
IM functionality, including multiparty IM conferences
Web conferencing and A/V conferencing
Lync Server 2013 supports virtualization on both Windows Server 2012, Windows Server
2012 R2, and Windows Server 2008 R2. Support on Windows Server 2012 and Windows
Server 2012 R2 includes support for the Single Root I/O Virtualization (SR-IOV) capabilities.
With SR-IOV, the virtual function of a physical network adapter is assigned directly to a
virtual machine. This increases network throughput and reduces network latency while also
reducing the host CPU overhead that is required for processing network traffic.

Front End Pools are also the primary store for user and conference data. Information about each
user is replicated among three Front End Servers in the pool, and backed up on the Back End Servers.
Additionally, one Front End pool in the deployment also runs the Central Management Server, which
manages and deploys basic configuration data to all servers running Lync Server. The Central
Management Server also provides Lync Server Management Shell and file transfer capabilities.
The Back End Servers are database servers running Microsoft SQL Server that provide the database
services for the Front End pool. The Back End Servers serve as backup stores for the pools user and
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

30

conference data, and are the primary stores for other databases such as the Response Group
database. You can have a single Back End Server, but a solution that uses SQL Server mirroring is
recommended for failover. Back End Servers do not run any Lync Server software.
You may choose to deploy SQL mirroring with or without a witness. We recommend using a witness
because it enables failover of the Back End Server to be automatic. Otherwise, an administrator
must manually invoke failover. Note that even if a witness is deployed, an administrator can
manually invoke Back End Server failover, if necessary.
Design Recommendation: - 2 SQL servers should be used at MSTD with SQL mirroring as HA

6.2

Edge Server
Edge Server enables end users to communicate and collaborate with users outside the organizations
firewalls. These external users can include the organizations own users who are currently working
offsite, users from federated partner organizations, and outside users who have been invited to join
conferences hosted on your Lync Server deployment. Edge Server also enables connectivity to public
IM connectivity services, including Skype, AOL and Google Talk.
Deploying Edge Server also enables mobility services, together with a reverse proxy, which supports
Lync functionality on mobile devices. Users can use supported Apple iOS, Android, Windows Phone,
or Nokia mobile devices to perform activities such as sending and receiving instant messages,
viewing contacts, and viewing presence. In addition, mobile devices support some Enterprise Voice
features, such as click to join a conference, Call via Work, single number reach, voice mail, missed
calls and VOIP calls over WiFi. The mobility feature also supports push notifications for mobile
devices that do not support applications running in the background. A push notification is a
notification that is sent to a mobile device about an event that occurs while a mobile application is
inactive.
Edge Servers also include a fully-integrated Extensible Messaging and Presence Protocol (XMPP)
proxy, with an XMPP gateway included on Front End Servers. You can configure these XMPP
components to enable your Lync Server 2013 users to add contacts from XMPP-based partners (such
as Google Talk) for instant messaging and presence.
Design Recommendation: 2 Edge Server will be implemented at MSTD in HA mode for External
connectivity and for access from Mobile devices

Lync High Availability Design


Lync Server 2013 provides high availability by server redundancy via pooling. If a server running a
certain server role fails, the other servers in the pool running the same role take the load of that
server. This applies to Front End Servers, Edge Servers, Mediation Servers, and Directors.
Lync Server 2013 also provides disaster recovery measures by enabling pool pairing. We will deploy
Enterprise pool across 2 locations in MSTD and enable pool pairing for HA. If one pool or site goes
down, we can redirect the users of that pool to use the other pool in the pair, with minimal
interruption of service.
Lync Server 2013 also supports Back End Server high availability. This is an optional topology in
which two Back End Servers are deployed for a Front End pool, and set up synchronous SQL Server
mirroring for all the Lync databases running on the Back End Servers.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

31

Front End Server High Availability and Disaster Recovery

Other Email Organizations

Roaming Users (Outlook Anywhere, OWA,


ActiveSync)

TELCO / ISP
INTERNET

Router

Router

Reverse Proxy

Lync Edge Servers

Firewalls

WAN IP-Link to Primary


and Secondary Data Centers

Firewalls

Reverse Proxy

Exchange Edge Servers

Perimeter Network

Perimeter Network

Firewalls
Exchange Edge Servers

Lync Edge Servers

Firewalls

Hardware Load Balancers


Hardware Load Balancers
Hardware Load Balancers

Hardware Load Balancers

Multi Role Exchange Servers

Multi Role Exchange Servers

SAS

SAS
Front End

Front End

SQL Server

SQL Cluster
(mirroring) with
SQL Witness

SQL Cluster
(mirroring) with
SQL Witness

Front End

Front End

Front End

Front End

Pool 2

Pool 1

Front-End

Front-End
DAG

DAG
Directory Servers

Storage

Directory Servers

Storage

File Share

Lync File Share

Primary Data Center

Secondary (Disaster Recovery) Data Center

Unified Communication & Messaging Architecture

Lync Reference HA / DR Architecture

The Backup Service is a feature in Lync Server 2013, designed to support the disaster recovery
solution. It is installed on a Front End pool when you pair the pool with another Front End pool.
If the pool in one site fails, users can be failed over from that pool to the pool in the other site, which
then provides services to all the users in both pools. For capacity planning purposes, each pool will
be designed to handle the workloads of all users in both pools in the event of a disaster.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

32

In addition to providing disaster recovery ability, two paired pools serve as the backup Registrars for
each other. In Lync Server 2013, backup Registrar relationships between Front End pools are always
1:1 and reciprocal. This means that if P1 is the backup for P2, then P2 must be the backup for P1, and
neither can be the backup for any other Front End pool. This is a change from Lync Server 2010, in
which Front End pool backup relationships could be many to one.
Even though backup relationships between two Front End pools must be 1:1 and symmetrical, each
Front End pool can still also be the backup registrar for any number of Survivable Branch Appliances

7.1

Central Management Store Failover


The Central Management store contains configuration data about servers and services in the Lync
2013 deployment. It provides a robust, schematized storage of the data needed to define, set up,
maintain, administer, describe, and operate a Lync 2013 deployment. It also validates the data to
ensure configuration consistency. Each Lync deployment includes one Central Management store,
which is hosted by the Back End Server of one Front End pool.
When a pool pairing is established that includes the pool hosting the Central Management store, a
backup Central Management store database is set up in the backup pool, and Central Management
store services are installed in both pools. At any point in time, one of the two Central Management
store databases is the active master, and the other is a standby. The content is replicated by the
Backup Service from the active master to the standby.
During a pool failover that involves the pools hosting the Central Management store, the
administrator must fail over the Central Management store before failing over the Front End pool.
After the disaster is repaired, it is not necessary to fail back the Central Management store. After
repair, the Central Management store in the original backup pool can remain as the active master.

7.2

Lync Failover scenarios


Front-End Pool and Back-End Database failover Scenarios
If a pool is failed over, all users of the affected pool are forced to sign out and then sign into the
backup pool. For a brief period users who sign into the backup pool may be in resiliency mode. In
Resiliency mode, users are unable to perform tasks that would cause a persistent change on Lync
Server, such as adding a contact. After the failover is complete, all users can get all services from the
backup pool. Any sessions a user has when the pool fails are disrupted, and the user must reestablish those sessions after failover to continue.
Users are not rehomed during failover or failback. Users who are homed on a pool that fails will be
temporarily serviced by the backup pool.
When the home pool is restored, the administrator can fail back these users to be serviced by their
original home pool.
When a user is in a pool that fails, the user is logged out. Any peer-to-peer session the user was
participating in is terminated, as are conferences organized by that user. The user cannot log back in
until either the registrar resiliency timer expires or the administrator initiates failover procedures,
RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft
Prepared by Surinder Pal Singh

33

whichever comes first. When the user logs back in, they will log in to the backup pool. If they log in
before the failover has completed, they will be in Resiliency mode until failover is complete. Only
then the user is able to establish new sessions or re-establish previous sessions.

User Experience during Failback


The following tables show more details about how a user with a Lync 2013 client or a Microsoft Lync
2013 client is affected during and after failback, and also how users in other pools see and interact
with a user in a pool who is being failed back. Users with Microsoft Office Communicator 2007 R2
clients cannot sign in until the Front End pool is completely failed back.)
The term affected user refers to any user who was failed over from the home pool and is being
serviced by the backup pool. By definition, any user originally homed on the backup pool is not an
affected user.

User Experience for an Affected User in a Pool in Failback


User task

During failback

After failback completion

User stays signed in and connected to backup


User state of user already pool. At some point user will be signed out and User remains signed in and goes into
logged in
sign back in to the original home pool, in regular mode.
Resiliency mode.
New user logging in

User can sign in to the home pool in Resiliency User can sign in to the original home pool
mode.
in regular mode.

All modalities of conference are terminated.


All modalities now work. Every
Ongoing
conferences Rejoin button will appear, but no users can
participant needs to click to rejoin the
organized by affected user
rejoin while the affected user is in Resiliency
conference.
mode.
Ongoing
organized
user

Conference continues and affected user can


conferences
stay in the conference. Affected user is
by unaffected
restricted to what he/she can do in Resiliency
mode.

Scheduling or modifying
scheduled
meetings, Not possible while user is in Resiliency mode.
creating ad-hoc conferences

Conference continues, and affected user


can stay in the conference and all
modalities work after user exits Resiliency
mode.
Available for all modalities.

Shows the last presence state set by the


Presence as seen by other Presence unknown while user is signed into
user, and presence changes will now be
users in the same pool
backup pool during Resiliency mode.
reflected.
Contacts list and Address
Not available
Book Service availability

Available

All peer-to-peer sessions


Available
and modalities

Available

User Experience for a User Homed in an Unaffected Pool during Failback of another Pool

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

34

User task

During failback

Viewing
presence
affected user

of Shows the last presence state set by the Working. Unaffected users see updates made
affected user.
by affected users.

Ongoing
conferences
All modalities of conference are terminated.
organized by affected user
Ongoing
organized
user

by

All modalities now work. Every participant


needs to click to rejoin the conference.

conferences Conference continues, and affected user can Conference continues, and affected user can
unaffected stay in the conference and all modalities stay in the conference and all modalities
work.
work.

All peer-to-peer sessions


Available
and modalities

7.3

After failback completion

Available

Edge Server Failover Scenarios


Remote Access
If you have multiple sites, each with a pool of Edge Servers, and one entire Edge pool fails, the
remote access services will continue to function without needing administrator actions. Remote
users will automatically be routed to the Edge Servers in another site, because all Edge Server pools
in the organization have the same external FQDN.
To ensure that this automatic failover will work smoothly, be sure to add every Front End pool in
your organization to the publishing rules on the Reverse Proxy at each site. This way, Front End
Servers in one site can communicate with Edge Servers in every other site, if the Edge Servers in the
same site as the Front End Servers are unavailable.

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

35

8
8.1

Lync Modular Design


Lync 2013 Front end
Microsofts guidance is to have a maximum of 6,660 users per Lync 2013 front end server
2 Front end servers will be used in Primary Datacenter to have redundancy in case of a Server
failure and 2 Front end servers will be used in DR Datacenter

8.2

Lync 2013 Back Ends


The entire Lync infrastructure will be virtualized including the SQL Back end Servers
From Microsofts published and tested guidance at http://technet.microsoft.com/enus/library/gg398835.aspx , we recommend below hardware for the Lync roles
2 Cores and 8 GB of RAM for Lync Front Ends & Back Ends 1 dual-port network adapter, 1 Gbps or
higher (2 recommended)
All other Lync roles such as Archiving, Monitoring will be collocated on the FE servers and hence no
separate server role is needed for them
http://technet.microsoft.com/en-us/library/gg398102(OCS.15).aspx

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

36

AD, Exchange and Lync Monitoring & Server Management


Following are the Components will be used to monitor AD, Exchange and Lync Servers and manage
them
SCOM

Active Directory Domain Services Management Pack for System Centre


Exchange Management Pack for System Centre
Lync Management Pack for System Centre

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

37

10 Overall Solution Diagram

Other Email Organizations

Roaming Users (Outlook Anywhere, OWA,


ActiveSync)

TELCO / ISP
INTERNET

Router

Router

Reverse Proxy

Lync Edge Servers

Firewalls

WAN IP-Link to Primary


and Secondary Data Centers

Firewalls

Reverse Proxy

Exchange Edge Servers

Firewalls

Hardware Load Balancers


Hardware Load Balancers
Hardware Load Balancers

Hardware Load Balancers

Multi Role Exchange Servers

Multi Role Exchange Servers

SAS

SAS
Front End

Front End

SQL Server

SQL Cluster
(mirroring) with
SQL Witness

SQL Cluster
(mirroring) with
SQL Witness

Front End

Front End

Front End

Front End

Pool 2

Pool 1

Front-End

Front-End
DAG

DAG
Directory Servers

Storage

Directory Servers

Storage

File Share

Lync File Share

Primary Data Center

Secondary (Disaster Recovery) Data Center

Unified Communication & Messaging Architecture

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

Perimeter Network

Perimeter Network

Firewalls
Exchange Edge Servers

Lync Edge Servers

38

11 Appendix
11.1 Microsoft Product Mapping

S.No

Technical Capability requirement

MS Solution mapping

Messaging

Exchange Server 2013

Active Directory

Windows Server 2012 R2

Instant Presence and Messaging

Lync Server 2013

Operating System

Windows Server 2012 R2

11.2 Non Functional Requirements


S. No

Non
Functional Recommended
Solution Specific comment
Characteristic
Technical capability

Scalability

Private Cloud

High availability

Application level HA Exchange, Active Directory and Lync Server


provides application level High availability for
the solution. Along with that, Hyper V failover
capabilities can be leveraged for applications
that does not provide redundancy by design

Monitoring

SCOM

Microsoft System Center operations manager


can be leveraged for monitoring capabilities.

Disaster recovery

Application Level

Site DR is not a requirement as of now but


unified messaging solution can be easily scaled
to Site DR capabilities by extended Exchange
DAG to DR site and by implementing Lync
Server 2013 pool pairing

Multi Tenancy

NA

NA

Authentication/Authorizat Active Directory


ion

Authentication/Authorization will be provided


by Active Directory

Scale Unit

Solution is highly scalable in terms of scale up


capabilities (adding more compute power) or
scale out capabilities (Adding more Virtual
machines)

RFP Supporting Solution Doc for MSTD, Version 0. 3 Draft


Prepared by Surinder Pal Singh

Solution provides Private cloud Scalability


where virtual machines can be provisioned and
de-provisioned as per business needs.

Вам также может понравиться