1

CONTENTS

1. Purpose of the document ................................................................................................................................................... 5

2. eOffice Deployment Framework ..................................................................................................................................... 6

3. Type I Deployment Guidelines ........................................................................................................................................ 7

4. Type II Deployment Guidelines ....................................................................................................................................... 8

Annexure–A (REQUIREMENTS FOR EOFFICE) .............................................................................................................. 9

1. Hardware Requirements ........................................................................................................................................... 9

2. Data Redundancy ....................................................................................................................................................... 17

3. Software ........................................................................................................................................................................ 18

4. Minimum OS Partitioning ....................................................................................................................................... 18

5. Other requirements .................................................................................................................................................. 18

6. Disaster Recovery ...................................................................................................................................................... 18

ANNEXURE–B (CHECK LISTS) BEFORE GO-LIVE ...................................................................................................... 19

1. Check List – Type I eOffice Deployments ......................................................................................................... 19

2. Check List – Type II eOffice Deployments ........................................................................................................ 21

ANNEXURE–C (CHECK LISTS) AFTER GO-LIVE .......................................................................................................... 23

1. Check List – Type I eOffice Deployments ......................................................................................................... 23

2. Check List – Type II eOffice Deployments ........................................................................................................ 24

ANNEXURE–D (ROLES AND RESPONSIBILITIES) ..................................................................................................... 25

1. Roles and Responsibilities for Type I Deployments .................................................................................... 25

2. Roles and Responsibilities for Type II Deployments ................................................................................... 26

ANNEXURE-E (EOFFICE DEPLOYMENT READY RECKONER) ............................................................................... 28

2
Abbreviations

CRL Certificate Revocation List

DC Data Centre
DR Disaster Recovery
DNS Domain Name Server
DSC Digital Signature Certificate
ESA eOffice Systems Administrators
LDAP Lightweight Directory Access Protocol
LDC Local Data Centre
LR Logical Replication (PostgreSQL Database)
NDC National Data Centre
NTP Network Time Protocol
PITR Point In Time Recovery
RAID Redundant Array of Independent Disks
SAN Storage Area Network
SDC State Data Centre
SSL Secure Socket Layer
SR Streaming Replication (PostgreSQL Database)
VM Virtual Machine

3
Amendment History

Date of Date of Amended

S.No. Version Amendments
Release Amendment By
1. 1.0 19-01-2014
 Specifications revised in Annexure – A:
Requirements for eOffice Premium
eOffice
2. 1.1 12-12-2014 11-12-2014 edition.
Division
 Specifications revised in Annexure – A:
Requirements for eOffice Lite edition.
 Revision of categories based on user base
revised in Annexure – A.
eOffice  eOffice deployment types based on
3. 2.0 01-06-2016 01-06-2016
Division products revised in Annexure – A.
 Hardware requirements revised in
Annexure – A.
 Revision in eOffice deployment types.
 Revision in Hardware and Software
eOffice requirements in Annexure - A.
4. 3.0 26-03-2018 26-03-2018
Division  Deletion of “PERFORMA FOR FORMAL
HANDING OVER AND TAKING OVER OF
EOFFICE SERVERS”
 Revision in Section 2 (Pre-requisites for
eOffice Deployment)
 Revision in Section 3 (Type I
Deployment Guidelines)
 Revision in Section 4 (Type II
Deployment Guidelines)
 Revision in “Hardware Requirements”
and “Software” in Annexure – A.
eOffice
5. 4.0 07-11-2019 07-11-2019  Addition of “Data Redundancy” and
Division
“Minimum OS Partitioning” sections in
Annexure – A.
 Revision in Check Lists for Type I and
Type II Deployments (Annexure – B and
Annexure – C)
 Revision in Roles and Responsibilities for
Type I and Type II Deployments
(Annexure – D)
 Revision in Section 1 (Purpose of the
Document)
 Revision in Section 2 (Pre-requisites for
eOffice eOffice Deployment)
6. 5.0 15-05-2020 14-05-2020
Division  Revision in “Hardware Requirements” in
Annexure – A
 Revision in Annexure–E (eOffice
Deployment Ready Reckoner)

4
1. PURPOSE OF THE DOCUM ENT

The eOffice Product is being implemented across the Government levels of Centre, States, Districts,
PSUs, etc. The deployment of eOffice product can be done in eOffice Cloud, NIC/NICSI Data Centres,
State Data Centres (SDC), Local Data Centres (LDC) or in any other data centre / cloud environment.

Establishing an eOffice Deployment Framework is important and the areas to be included in

framework for ensuring effective deployment management and sustainability of eOffice are as follows:

 Deployment Strategy
 Approach & Model for Deployment
 Defining the Responsibility Matrix
 Process and Guidelines
 Availability of Deployment Infrastructure

This document includes all the above factors.

5
2. EOFFICE DEPLOYMENT FRAMEWORK

The eOffice Deployment Framework categorizes eOffice deployment into two broad types and for each
type, the check lists & roles and responsibilities matrix is defined.

Deployment Types:

 Type I: Deployment of eOffice in eOffice Cloud

Under this type, only the ministries, departments and apex bodies of GOI are deployed in
eOffice Cloud.

 Type II: Deployment in NIC/NICSI Data Centres / State Data Centres (SDC) / Local Data
Centres (LDC) / any other data centre or cloud environment
Under this type, the deployment is done in NIC/NICSI Data Centres / State Data Centres (SDC)
/ Local Data Centres (LDC) / any other data centre or cloud environment. The data centres
may not be fully fledged data centres but subject to fulfilling of eOffice pre-requisites, the
eOffice deployment is done. The access to eOffice in these departments is strictly made
available as per the department’s / data centre’s rules & regulations.

Pre-requisites for eOffice Deployment

eOffice Project Division has prepared the server (or compute) and storage requirements based
primarily on the total numbers of users and eOffice version. These requirements are arrived at by the
deployment experience gathered over the years, inputs from the Data Centre teams and also on the
basis of performance testing of eOffice application. (Ref: Annexure-A)

As eOffice data is very critical and the implementing organizations are increasingly dependent on
eOffice services, therefore, there is a strong need of data redundancy mandatorily at Primary Data
Centre. Apart from this, data redundancy is strongly recommended to be built at Remote Data Centre
also. The data redundancy has been achieved by bringing in additional infrastructure by configuring
the following:
a) Database replication is through DB SR and also by storing the PITR logs.
b) Replication of documents and configurations is achieved by rsync in provisioned Backup
Server.
In order to identify security breaches and data tempering, if any, in eOffice applications; recording the
access trails and transactions of all the applications and servers is necessary. For storing these audit
logs, Logs Server is required to be provisioned along with its backup mandatorily at the Primary Data
Centre. Apart from this, Logs Backup Server is strongly recommended to be configured at Remote Data
Centre also.

The requirements will be mildly on the higher side keeping in view the horizon of 2-3 years. Further,
the requirements are kept higher by a factor of 20% as a best practice. It is expected that requirements
are defined in such a manner that it will be convenient for IT heads or decision makers as incremental
additions to infrastructure is not only difficult in terms of internal approvals but also inconvenient for
technical teams to add new infrastructure on routine basis without disrupting the services and other
impacts known and unknown.

6
3. TYPE I DEPLOYMENT GUIDELINES

The Type I deployment is essentially meant for the Central Government Ministries, Departments and
Apex Bodies and will start once the approval for hosting is received by eOffice Project Division.
The steps involved in deployment are as follows:
1. Based on the eOffice version (Premium or Lite), the necessary provisioning will be done as
per the details mentioned in Annexure-A.
2. The DNS will be registered under the sub-domain eoffice.gov.in
3. eOffice instance will be setup as per the eOffice Setup instructions provided time to time.
4. The eOffice is restricted to NICNET/NKN and check at firewall level may be ascertained.
5. The user authentication happens through NIC/GOI email-id. The LDAP forms etc. are to be
submitted by concerned departments directly to Mail services group. The departments must
also obtain the LDAP bind string from Mail services group and shared it with ESA.
6. All eOffice sites have to be mandatorily SSL enabled. The SSL certificate must be obtained for
each eOffice instance and configured.
7. Sync the server timings with NDC NTP server. This is critical activity and must be doubly
assured.
8. Register the site with Data Centre monitoring tools like Nagios, Zabbix, etc. so that it comes
under monitoring dashboard.
9. Ensure that all the forms for scheduling the offline backups are submitted to NDC.
10. Ensure that DB replication and PITR are running.
11. Ensure that Logs along with their backup are being maintained.
12. The eOffice System Administrator must fill the check list provided in Annexure-B and ensure
that all the activities are checked before going live. The duly signed and stamped check list
must also be submitted by NIC official looking after eOffice System Administration to eOffice
PMU for records.
13. The eOffice System Administrator must fill the check list provided in Annexure-C and ensure
that all the activities are checked after Go-Live of eOffice. The duly signed and stamped check
list must also be submitted by NIC official looking after eOffice System Administration to
eOffice PMU for records on quarterly basis i.e. before 7th of April, July, October and January.
14. The duly signed and stamped check lists provided in Annexure-B and Annexure-C are
required to be mandatorily submitted by NIC official looking after eOffice System
Administration to eOffice PMU for compliance towards eOffice Data Redundancy.
15. The eOffice System Administration must prepare the Deployment Document.
16. The roles and responsibilities for Type I deployment need to be strictly followed (Ref:
Annexure-D).

7
4. TYPE II DEPLOYMENT GUIDELINES

Under this type, the deployment is done either in NIC/NICSI Data Centres / State Data Centres (SDC)
/ Local Data Centres (LDC) / any other data centre or cloud environment, as the case may be.
The steps involved in deployment are as follows:
1. Based on the eOffice version (Premium or Lite), the necessary provisioning is made available
by the concerned department as per Annexure-A.
2. DNS registration as per department policy.
3. Training to be provided to the system admin team of department.
4. eOffice instance will be setup by local admin team under the supervision of eOffice team as
per the eOffice setup instructions provided time to time.
5. The user authentication mechanism will be done through LDAP.
6. SSL certificate is mandatory.
7. Sync the server timings with NTP server.
8. Department may register their eOffice instance with local monitoring tools, if available.
9. Schedule the offline backups as per DC/Department policy. It is mandatory to identify storage
& backup servers for copying of configuration files, uploaded documents and logs data other
than offline backup.
10. Setup the DB replication. PITR is mandatory and for this additional storage will be required.
11. For DSC signing, a separate CRL server may be established at data centre, if required.
12. For availing eSign facility, department may contact empanelled eSign Service Providers and
sign an agreement with them as ASP (Application Service Provider). Department may also
provision the necessary infrastructure at data centre, if required.
13. For SMS & Email alerts services, necessary configuration and port opening will be the
responsibility of department / data centre.
14. For Inter-departmental file exchange, a separate server for running ActiveMQ service may be
established at data centre, if required.
15. For verification of eOffice Activation Key, ports (80, 443) of Application Server to
https://eoffice.gov.in are required to be opened.
16. The eOffice System Administrator identified by department must fill the check list provided in
Annexure-B and ensure that all the activities are checked before going live. The duly signed
and stamped check list must also be submitted by eOffice Nodal Coordinator of the
department to eOffice PMU for records.
17. The eOffice System Administrator identified by department must fill the check list provided in
Annexure-C and ensure that all the activities are checked after Go-Live of eOffice. The duly
signed and stamped check list must also be submitted by eOffice Nodal Coordinator of the
department to eOffice PMU for records on quarterly basis i.e. before 7th of April, July, October
and January.
18. The duly signed and stamped check lists provided in Annexure-B and Annexure-C are
required to be mandatorily submitted by eOffice Nodal Coordinator of the department to
eOffice PMU for compliance towards eOffice Data Redundancy.
19. The eOffice System Administrator identified by department, in coordination with eOffice
System Administration Team, must prepare the Deployment Document and share it with
eOffice PMU. As and when any revision is made in the Deployment Document, the same may
be again shared with eOffice PMU for records.
20. The roles and responsibilities for Type II deployment need to be strictly followed (Ref:
Annexure-D).

8
ANNEXURE–A (REQUIREMENTS FOR EOFFICE)

1. HARDWARE REQUIREMENTS

1.1 eOffice Premium

9
a) */eOffice must be mounted to each application server and /Uploads must be mounted to only one application server as per the storage defined in above table.
b) SAN is the recommended storage media.
c) Storage (GB) is the additional storage required at Mount Point after minimum OS partitioning as specified in Point No. 4 at Page 18.
d) Whenever services are required to run from DB SR Server / Application Failover Server, then the resources of DB SR Server / Application Failover Server to be made
equivalent to Database Server / Application Server.
e) In DB SR Server, PITR is required to be configured.
f) $ Storage for Logs (including PITR) has been calculated for a period of two years keeping in view that the approximate compression level is 80%.

g) @ CRL Server is required in case department is using DSC signing.

h) Logs Backup Server, if required, can be minimized by mounting the Storage required for Logs Backup with Application Failover/ Backup Server. By doing this, additional
data redundancy of logs is ensured and also the cost of additional Server/ VM for Logs Backup Server is saved for the concerned user department.

10
i) For deployments upto 500 users, following is submitted.
i. DB LR Server is not mandatory, in case the requirements related to generation of MIS Reports are not very frequent. However DB LR Server is mandatory, in cases
where the requirements related to generation of MIS Reports are very frequent.
ii. As a standard approach and best practice, Web Server and Application Server must be separately provisioned. However in case user department due to
whatsoever reason is unable to provision separate Web Server and Application Server, then in that case, both these servers can be clubbed into one by adding the
compute (vCPU and RAM) of both the servers. By doing this, the cost of licenses (Operating System and virtualization) for one server is saved for user department.

1.2 eOffice Lite (eFile)

11
a) */eOffice must be mounted to each application server and /Uploads must be mounted to only one application server as per the storage defined in above table.
b) SAN is the recommended storage media.
c) Storage (GB) is the additional storage required at Mount Point after minimum OS partitioning as specified in Point No. 4 at Page 18.
d) Whenever services are required to run from DB SR Server / Application Failover Server, then the resources of DB SR Server / Application Failover Server to be made
equivalent to Database Server / Application Server.
e) In DB SR Server, PITR is required to be configured.
f) $ Storage for Logs (including PITR) has been calculated for a period of two years keeping in view that the approximate compression level is 80%.

g) @ CRL Server is required in case department is using DSC signing.

h) Logs Backup Server, if required, can be minimized by mounting the Storage required for Logs Backup with Application Failover/ Backup Server. By doing this, additional
data redundancy of logs is ensured and also the cost of additional Server/ VM for Logs Backup Server is saved for the concerned user department.

12
i) For deployments upto 500 users, following is submitted.
i. DB LR Server is not mandatory, in case the requirements related to generation of MIS Reports are not very frequent. However DB LR Server is mandatory, in cases
where the requirements related to generation of MIS Reports are very frequent.
ii. As a standard approach and best practice, Web Server and Application Server must be separately provisioned. However in case user department due to
whatsoever reason is unable to provision separate Web Server and Application Server, then in that case, both these servers can be clubbed into one by adding the
compute (vCPU and RAM) of both the servers. By doing this, the cost of licenses (Operating System and virtualization) for one server is saved for user department.

1.3 eOffice Lite (eLeave – eTour)

13
a) */eOffice must be mounted to each application server and /Uploads must be mounted to only one application server as per the storage defined in above table.
b) SAN is the recommended storage media.
c) Storage (GB) is the additional storage required at Mount Point after minimum OS partitioning as specified in Point No. 4 at Page 18.
d) Whenever services are required to run from DB SR Server / Application Failover Server, then the resources of DB SR Server / Application Failover Server to be made
equivalent to Database Server / Application Server.
e) In DB SR Server, PITR is required to be configured.
f) $ Storage for Logs (including PITR) has been calculated for a period of two years keeping in view that the approximate compression level is 80%.

g) @ CRL Server is required in case department is using DSC signing.

h) Logs Backup Server, if required, can be minimized by mounting the Storage required for Logs Backup with Application Failover/ Backup Server. By doing this, additional
data redundancy of logs is ensured and also the cost of additional Server/ VM for Logs Backup Server is saved for the concerned user department.

14
i) For deployments upto 500 users, following is submitted.
i. DB LR Server is not mandatory, in case the requirements related to generation of MIS Reports are not very frequent. However DB LR Server is mandatory, in cases
where the requirements related to generation of MIS Reports are very frequent.
ii. As a standard approach and best practice, Web Server and Application Server must be separately provisioned. However in case user department due to
whatsoever reason is unable to provision separate Web Server and Application Server, then in that case, both these servers can be clubbed into one by adding the
compute (vCPU and RAM) of both the servers. By doing this, the cost of licenses (Operating System and virtualization) for one server is saved for user department.

1.4 eOffice Lite (SPARROW)

15
a) */eOffice must be mounted to each application server and /Uploads must be mounted to only one application server as per the storage defined in above table.
b) SAN is the recommended storage media.
c) Storage (GB) is the additional storage required at Mount Point after minimum OS partitioning as specified in Point No. 4 at Page 18.
d) Whenever services are required to run from DB SR Server / Application Failover Server, then the resources of DB SR Server / Application Failover Server to be made
equivalent to Database Server / Application Server.
e) In DB SR Server, PITR is required to be configured.
f) $ Storage for Logs (including PITR) has been calculated for a period of two years keeping in view that the approximate compression level is 80%.

g) @ CRL Server is required in case department is using DSC signing.

h) Logs Backup Server, if required, can be minimized by mounting the Storage required for Logs Backup with Application Failover/ Backup Server. By doing this, additional
data redundancy of logs is ensured and also the cost of additional Server/ VM for Logs Backup Server is saved for the concerned user department.
i) For deployments upto 500 users, as a standard approach and best practice, Web Server and Application Server must be separately provisioned. However in case user
department due to whatsoever reason is unable to provision separate Web Server and Application Server, then in that case, both these servers can be clubbed into one by
adding the compute (vCPU & RAM) of both the servers. By doing this, the cost of licenses (Operating System & virtualization) for one server is saved for user department.
j) If multiple services are from same service/cadre controlling authority, then single sharable instance(s) can be created for all services and infra requirements will be as
per above table.

16
2. DATA REDUNDANCY

a) For availability of data (to recover from Data Centre failure/System failures), it is mandatory to
create data redundancy by configuring DR SR Server, Backup Server and Logs Backup Server at
Primary Data Centre. Apart from this, it is strongly recommended to configure DB SR Server,
Backup Server and Logs Backup Server at Remote Data Centre.

b) The data redundancy must be mandatorily created at Primary Data Centre by configuring DB SR
Server, Backup Server and Logs Backup Server to ensure data is intact in the case of Primary
Site’s eOffice systems failures. In such event, respective services and data can be made available
from the DB SR Server, Application Failover/Backup Server and Logs Backup Server by
augmenting their resources.

It is mandatory to create data redundancy of DB SR Server, Backup Servers and Logs Backup
Server at Primary Data Centre, whenever the services are required to be resumed from the
aforesaid servers’ setup at Primary Data Centre. Apart from that, backup of these aforesaid
servers are strongly required to be configured at Remote Data Centre along with offline backups,
as mentioned in Point 2.d. given below.

c) The data redundancy is strongly recommended to be created at Remote Data Centre also by
configuring DB SR Server, Backup Server and Logs Backup Server to ensure data is intact in the
case of Primary Data Centre failure. In such event, data can be recovered from Remote Data
Centre till the last consistent backup taken.

d) Offline Backups of DB File System, Uploads File System and Log Files should also be additionally
undertaken mandatorily, as weekly full backup, preferably on Saturday night at 10:00 P.M. or as
per the data centre policy. Followed by daily incremental/differential backup, preferably twice a
day, for example, incremental backups at 01:00 P.M. and 10:00 P.M. or as per the data centre
policy. This offline backup will ensure availability of eOffice data (DB File System, Uploads File
System and Log Files) in the case of loss of live and redundant data, till the last consistent backup
taken.

`
17
3. SOFTWARE

Version of Linux Server (Redhat/CentOS), PostgreSQL and other related softwares’, as recommended
by NIC eOffice Project Division may be made available at the time of deployment.

4. MINIMUM OS PARTITIONING

Mount Point Partition Size (GB) Partition Type

/boot 1 part
/home 5 lvm
/var 15 lvm
/tmp 10 lvm
/opt 5 lvm
[SWAP] 8 lvm
/ 16 lvm

5. OTHER REQUIREMENTS

a) Hiring / Identification of skilled team for System Administration and DB Administration, for
effective administration of eOffice System for Type II deployments is mandatory before going live
with the eOffice Implementation.

b) All the network and infrastructure requirements must be in place to make eOffice operational.

6. DISASTER RECOVERY

Due to the critical nature of applications, there is a strong need of DR. DR should be at remote
location. The typical setup is same as the primary and any changes in applications (WAR/Version or
Products) and data to be replicated, either using storage-based replication, or host-based replication.
The DR solution should support, DR Drills and failover. The hardware, software and other
infrastructure resources for DR need to be provisioned separately.

Note: The following requirements are based on typical usage and based on empirical data.
Occasionally there may be slightly higher/lower requirements in each category due to the
different nature of working of an organization.

18
ANNEXURE–B (CHECK LISTS) BEFORE GO-LIVE

1. CHECK LIST – TYPE I EOFFICE DEPLOYMENTS

(Fill Boxes with ‘Y’ or ‘N’ or as mentioned in activity)

1. Copy/email for approval of hosting of eOffice instance of department

2. Deployment Sub category: eOffice Lite or eOffice Premium
3. VMs and Storage provisioned as specified in Annexure-A
3.1 Database Server provisioned at Primary Data Centre (Mandatory)
3.2 DB LR Server provisioned at Primary Data Centre (Mandatory)
3.3 DB SR Server provisioned at Primary Data Centre (Mandatory)
3.4 Web Server provisioned at Primary Data Centre (Mandatory)
3.5 Application Server(s) provisioned at Primary Data Centre (Mandatory)
3.6 CRL Server provisioned at Primary Data Centre (Mandatory)
3.7 Application Failover / Backup Server provisioned at Primary Data Centre (Mandatory)
3.8 Logs Server provisioned at Primary Data Centre (Mandatory)
3.9 Logs Backup Server provisioned at Primary Data Centre (Mandatory)
3.10 DB SR Server provisioned at Remote Data Centre (Strongly Recommended)
Application Failover / Backup Server provisioned at Remote Data Centre (Strongly
3.11
Recommended)
3.12 Logs Backup Server provisioned at Remote Data Centre (Strongly Recommended)
4. Public/Private IPs assigned
5. Servers accessibility and connectivity ensured (by Ping and Telnet)
6. Time syncing with Network Time Protocol Server (NTP)
7. Registered DNS (under eoffice.gov.in) received
8. Sent IP details to Project Manager for filling LDAP form, Email and SMS Alerts form
9. Firewall rules placed as per the policy
10. eOffice Stack deployed in Application Server(s), Web Server and Database Server
11. SSL Certificate generated and deployed
12. Activation key deployed and eOffice Activation Revocation file downloaded
13. LDAP Bind string received and configured
DB replication setup in DB SR Server and DB LR Server at Primary Data Centre
14.
(Mandatory)
DB replication setup in DB SR Server at Remote Data Centre (Strongly
15.
Recommended)
16. PITR setup in DB SR Server at Primary Data Centre (Mandatory)
17. PITR setup in DB SR Server at Remote Data Centre (Strongly Recommended)

19
18. Logs Server configured at Primary Data Centre (Mandatory)
19. Logs Backup Server configured at Primary Data Centre (Mandatory)
20. Logs Backup Server configured at Remote Data Centre (Strongly Recommended)
21. Application Failover / Backup Server configured at Primary Data Centre (Mandatory)
22. Backup Server configured at Remote Data Centre (Strongly Recommended)
23. CRONS scheduled
24. eOffice Data Offline Backups scheduled at DC
25. Email & SMS Alerts configuration
26. CRL configured
27. eSign configured
28. Deployment Document prepared
29. Registered with Data Centre Monitoring Tools like Nagios, Zabbix, etc. for monitoring
30. Deployment confirmation sent to eOffice Project Team
31. Go Live Date intimation received from eOffice PMU

20
2. CHECK LIST – TYPE II EOFFICE DEPLOYMENTS

(Fill Boxes with ‘Y’ or ‘N’ or as mentioned in activity)

1. Copy/email for approval of hosting of eOffice instance at local servers

2. Deployment Sub category: eOffice Lite or eOffice Premium
3. VMs and Storage provisioned as specified in Annexure-A
3.1 Database Server provisioned at Primary Data Centre (Mandatory)
3.2 DB LR Server provisioned at Primary Data Centre (Mandatory)
3.3 DB SR Server provisioned at Primary Data Centre (Mandatory)
3.4 Web Server provisioned at Primary Data Centre (Mandatory)
3.5 Application Server(s) provisioned at Primary Data Centre (Mandatory)
3.6 CRL Server provisioned at Primary Data Centre (Mandatory)
3.7 Application Failover / Backup Server provisioned at Primary Data Centre (Mandatory)
3.8 Logs Server provisioned at Primary Data Centre (Mandatory)
3.9 Logs Backup Server provisioned at Primary Data Centre (Mandatory)
3.10 DB SR Server provisioned at Remote Data Centre (Strongly Recommended)
Application Failover / Backup Server provisioned at Remote Data Centre (Strongly
3.11
Recommended)
3.12 Logs Backup Server provisioned at Remote Data Centre (Strongly Recommended)
4. Network configured
5. Servers accessibility and connectivity ensured (by Ping and Telnet)
6. Time syncing with Network Time Protocol Server (NTP)
7. DNS Registration
8. Firewall rules placed as per the policy
9. eOffice Stack deployed in Application Server(s), Web Server and Database Server
10. SSL Certificate procured & configured
11. Activation key deployed and eOffice Activation Revocation file downloaded
12. Authentication through LDAP
DB replication setup in DB SR Server and DB LR Server at Primary Data Centre
13.
(Mandatory)
DB replication setup in DB SR Server at Remote Data Centre (Strongly
14.
Recommended)
15. PITR setup in DB SR Server at Primary Data Centre (Mandatory)
16. PITR setup in DB SR Server at Remote Data Centre (Strongly Recommended)
17. Logs Server configured at Primary Data Centre (Mandatory)
18. Logs Backup Server configured at Primary Data Centre (Mandatory)
19. Logs Backup Server configured at Remote Data Centre (Strongly Recommended)

21
20. Application Failover / Backup Server configured at Primary Data Centre (Mandatory)
21. Backup Server configured at Remote Data Centre (Strongly Recommended)
22. CRONS scheduled
23. eOffice Data Offline Backups scheduled at DC
24. Email & SMS Alerts Configuration (if required)
25. CRL Setup (if required)
26. eSign configured (if required)
27. Deployment Document prepared and shared with eOffice PMU
28. Registered with Data Centre Monitoring Tools for monitoring, if any
29. Deployment confirmation sent to eOffice Project Team
30. Training to local system administration team
31. Go Live Date intimation sent to eOffice Project Team

22
ANNEXURE–C (CHECK LISTS) AFTER GO-LIVE

1. CHECK LIST – TYPE I EOFFICE DEPLOYMENTS

(Fill Boxes with ‘Y’ or ‘N’ or as mentioned in activity and submit the duly signed & stamped check
list on quarterly basis i.e. before 7th of April, July, October and January to eOffice PMU)

1. Go Live confirmation sent to eOffice Project Team

2. Downloading of eOffice Activation Revocation file
3. Configuration of DB Scripts for showcasing eOffice Usage Statistics
4. Time syncing with Network Time Protocol Server (NTP)
5. Servers accessibility and connectivity ensured (by Ping and Telnet)
6. SSL Certificate valid
7. DB SR and DB LR working and in sync at Primary Data Centre (Mandatory)
8. PITR working in DB SR Server at Primary Data Centre (Mandatory)
9. Backups (/Uploads) running and in sync at Primary Data Centre (Mandatory)
10. Backups (/eOffice) running and in sync at Primary Data Centre (Mandatory)
11. Backups (/Logs) running and in sync at Primary Data Centre (Mandatory)
12. Offline Backups running (Mandatory)
13. DB replication working and in sync at Remote Data Centre (Strongly Recommended)
14. PITR working in DB SR Server at Remote Data Centre (Strongly Recommended)
Backups (/Uploads) running and in sync at Remote Data Centre (Strongly
15.
Recommended)
Backups (/eOffice) running and in sync at Remote Data Centre (Strongly
16.
Recommended)
Backups (/Logs) running and in sync at Remote Data Centre (Strongly
17.
Recommended)
18. CRONS working
19. DB Maintenance Scripts working
20. Email & SMS Alerts working
21. CRL Downloading working
22. Revision in Deployment Document (if applicable)
23. Configured in Monitoring Tools
24. Latest Applications version deployed
25. Servers VA done and patched

23
2. CHECK LIST – TYPE II EOFFICE DEPLOYMENTS

(Fill Boxes with ‘Y’ or ‘N’ or as mentioned in activity and submit the duly signed & stamped check
list on quarterly basis i.e. before 7th of April, July, October and January to eOffice PMU)

1. Go Live confirmation sent to eOffice Project Team

2. Downloading of eOffice Activation Revocation file
3. Configuration of XML Scripts for showcasing eOffice Usage Statistics
4. Time syncing with Network Time Protocol Server (NTP)
5. Servers accessibility and connectivity ensured (by Ping and Telnet)
6. SSL Certificate valid
7. DB SR and DB LR working and in sync at Primary Data Centre (Mandatory)
8. PITR working in DB SR Server at Primary Data Centre (Mandatory)
9. Backups (/Uploads) running and in sync at Primary Data Centre (Mandatory)
10. Backups (/eOffice) running and in sync at Primary Data Centre (Mandatory)
11. Backups (/Logs) running and in sync at Primary Data Centre (Mandatory)
12. Offline Backups running (Mandatory)
13. DB replication working and in sync at Remote Data Centre (Strongly Recommended)
14. PITR working in DB SR Server at Remote Data Centre (Strongly Recommended)
Backups (/Uploads) running and in sync at Remote Data Centre (Strongly
15.
Recommended)
Backups (/eOffice) running and in sync at Remote Data Centre (Strongly
16.
Recommended)
Backups (/Logs) running and in sync at Remote Data Centre (Strongly
17.
Recommended)
18. CRONS working
19. DB Maintenance Scripts working
20. Email & SMS Alerts working (if configured)
21. CRL Downloading working (if configured)
22. Revision in Deployment Document and sharing with eOffice PMU (if applicable)
23. Configured in Monitoring Tools
24. Latest Applications version deployed
25. Servers VA done and patched

24
 ANNEXURE–D (ROLES AND RESPONSIBILITIES)

1. ROLES AND RESPONSIBI LITIES FOR TYPE I DEPLOYMENTS

S.No. Activity/Service Responsibility Remarks

1. Allocation of VMs and Storage ESA Subject to availability and approval
2. Configuring and making VMs ready ESA
3. Allotment of Public/Private IPs to VMs ESA + NDC
4. Time syncing with NTP ESA
5. Firewall rules placement ESA+ CSG NIC Ensure Audit certificate is available
6. DNS registration ESA
Generation and Deployment of SSL
7. ESA
Certificate
8. eOffice Stack deployment ESA
Activation Key deployment and
9. downloading of eOffice Activation ESA
Revocation file
Subject to forwarding of LDAP Bind
10. LDAP Bind String configuration ESA
String by user department to ESA
11. DB SR and DB LR setup ESA
12. PITR setup ESA
13. Logs Server configuration ESA
14. Backups Servers configuration ESA
15. CRONS scheduling ESA
eOffice Data Offline Backups scheduling
16. ESA +NDC
at DC
17. Email & SMS Alerts configuration ESA
18. CRL configuration ESA
Subject to receiving of Application ID
19. eSign configuration ESA
and ASP ID from eSign Division
Creation and revision of Deployment
20. ESA
Document
Registering with Data Centre
21. Monitoring Tools like Nagios, Zabbix, ESA
etc.
22. Monitoring and trouble shooting ESA
Network and DC specific issues will
23. Server maintenance and management ESA + NDC
be coordinated with NDC team.
This will be a planned activity with
24. Release management ESA
advance intimation.
Configuration of DB Scripts for
25. ESA
showcasing eOffice Usage Statistics
Timely submission of Check Lists
26. ESA
(Annexure-B) to PMU
27. Servers VA and patching ESA

25
 2. ROLES AND RESPONSIBI LITIES FOR TYPE II DEPLOYMENTS

S.No. Activity/Service Responsibility Remarks

1. H/W procurement and shipping Department
2. Placing servers in DC DC
Necessary network and infrastructure
3. DC
setup
H/W assembling, RAID configuration
4. Department
and Firmware upgradation of servers
5. Management IP assignment (OA/ILO) DC
6. Hypervisor installation on servers Local Admin Team If applicable
7. IP allocation to servers DC
8. Storage allocation DC
9. VMs/Servers and Storage provisioning Local Admin Team
10. Network configuration Local Admin Team
11. Time syncing with NTP Local Admin Team
12. Firewall rules placement Local Admin Team
13. Load Balancer configuration DC & Local Admin Team If applicable
14. Yum repository creation Local Admin Team
Department & Local
15. DNS registration and mapping
Admin Team
Generation and Deployment of SSL
16. Local Admin Team
Certificate
17. Remote access of servers to ESA Local Admin Team If required
ESA will provide training to
the Local Admin Team & will
supervise the installation.
18. eOffice Stack deployment Local Admin Team However, ESA team’s role
during supervision will be
limited to specific issue
resolution only.
Activation Key deployment and
19. downloading of eOffice Activation Local Admin Team
Revocation file
LDAP Group & Local
20. Secondary LDAP setup If required
Admin Team
21. LDAP Bind String configuration Local Admin Team
22. DB SR and DB LR setup Local Admin Team
23. PITR setup Local Admin Team
24. Logs Server configuration Local Admin Team
25. Backups Servers configuration Local Admin Team
26. CRONS scheduling Local Admin Team
eOffice Data Offline Backups scheduling
27. DC & Local Admin Team
at DC
28. Email & SMS Alerts configuration Local Admin Team If required
29. CRL configuration Local Admin Team If required

26
30. eSign configuration Local Admin Team If required
Creation and revision of Deployment
31. Document and sharing with eOffice Local Admin Team
PMU
Registering with Data Centre
32. Local Admin Team If required
Monitoring Tools
Department & Local
33. Starting of services and Go live
Admin Team
34. Disaster Recovery setup DC & Local Admin Team If applicable
ESA team can provide
35. Monitoring and trouble shooting Local Admin Team support for specific issue
resolution only
ESA team will provide
36. Performance and availability Issues Local Admin Team support for specific issue
resolution only
37. Data ownership Department
This will be a planned
activity with advance
38. Release management Local Admin Team intimation. The release
document will be provided
by ESA team.
Configuration of XML Scripts for
39. Local Admin Team
showcasing eOffice Usage Statistics
Timely submission of Check Lists
40. Local Admin Team
(Annexure-B) to PMU
41. Servers VA and patching Local Admin Team

27
ANNEXURE-E (EOFFICE DEPLOYMENT R EADY RECKONER)

eOffice Deployment Ready Reckoner

Deployment
Scope Hosting Activities Annexures
Type
 Approval by concerned NIC Cell/Division. Annexure-A
Central Government Annexure-B
Type I eOffice Cloud  Provision of resources by NDC/eOffice
Ministries/Departments/Apex
 New updates from eOffice as and when Annexure-C
Bodies
available Annexure-D
NIC/NICSI Data  Approval by concerned NIC Cell/Division.
Centres / State Data  Provision of resources by department Annexure-A
Centres (SDC) / Local  Constitution of a dedicated System Annexure-B
Type II Any Government Organization Administration Team by the department for
Data Centres (LDC) / Annexure-C
eOffice deployment and system support
any other data centre Annexure-D
 New updates from eOffice as and when
or cloud environment available

28
29