Network Infrastructure Upgrade Report: TFF Project Documentation

This report details the TFF Network Infrastructure Upgrade project, encompassing network design, server specifications, and implementation plans. It begins with an overview of network design and supporting documentation, including an evaluation of the collaborative Protection Profile for Network Devices (NDcPP) and State Traffic Filter Firewalls (FWcPP). The report provides two server specification proposals, detailing hardware configurations for PowerEdge R730 rack servers and HP ProLiant DL120 G7 servers. It includes a server build task template outlining physical and virtual server configurations, operating system installation procedures for both Windows and ESX environments, and OS optimization techniques. The report also covers a server test plan, maintenance plan, security policy and plan, user documentation, and a disaster recovery plan. Further sections address ongoing maintenance support (SLA), a project plan, and a handover schedule with a post-implementation review, providing a comprehensive guide to the network upgrade project.

TFF Network Infrastructure Upgrade

Table of Contents
Network Design and supporting documents 3
Server Specification – Two Proposals 4
Server Build Task Template 5
Server Test Plan 6
Server Maintenance Plan 7
Security Policy and Plan 8
User Documentation 9
Disaster Recovery Plan 10
Ongoing Maintenance Support (SLA) 11
Project Plan 12
Handover Schedule and Post Implementation Review 13

Network Design and supporting documents
Supporting Document defines the Evaluation Activities associated with the
collaborative Protection Profile for Network Devices [NDcPP]. The Network
Device technical area has a number of specialised aspects, such as those
relating to the secure implementation and use of protocols, and to the
particular ways in which remote management facilities need to be
assessed across a range of different physical and logical interfaces for
different types of infrastructure devices. This Supporting Document is
mandatory for evaluations of products that claim conformance to any of
the following cPP(s): a) collaborative Protection Profile for Network
Devices [NDcPP] b) collaborative Protection Profile for State Traffic Filter
Firewalls [FWcPP]. Although Evaluation Activities are defined mainly for
the evaluators to follow, the definitions in this Supporting Document aim
to provide a common understanding for developers, evaluators and users
as to what aspects of the TOE are tested in an evaluation against the
associated cPPs, and to what depth the testing is carried out. This
common understanding in turn contributes to the goal of ensuring that
evaluations against the cPP achieve comparable, transparent and
repeatable results. In general the definition of Evaluation Activities will
also help Developers to prepare for evaluation by identifying specific
requirements for their TOE. The specific requirements in Evaluation
Activities may in some cases clarify the meaning of SFRs, and may
identify particular requirements for the content of Security Targets
(especially the TOE Summary Specification), user guidance
documentation, and possibly supplementary information.
Structure of the Document
Evaluation Activities can be defined for both Security Functional
Requirements and Security Assurance Requirements. These are defined in
separate sections of this Supporting Document. 6 If any Evaluation
Activity cannot be successfully completed in an evaluation then the
overall verdict for the evaluation is a ‘fail’. In rare cases there may be
acceptable reasons why an Evaluation Activity may be modified or
deemed not applicable for a particular TOE, but this must be agreed with
the Certification Body for the evaluation.
Similarly, at the more granular level of Assurance Components, if the
Evaluation Activities for an Assurance Component and all of its related
SFR Evaluation Activities are successfully completed in an evaluation then
it would be expected that the verdict for the Assurance Component is a
‘pass’. To reach a ‘fail’ verdict for the Assurance Component when these
Evaluation Activities have been successfully completed would require a
specific justification from the evaluator as to why the Evaluation Activities
were not sufficient for that TOE.

Server Specification – Two Proposals
PowerEdge R730 Rack Server
Processor
Intel® Xeon® processor E5-2600 v4 product family
Operating System
Microsoft® Windows Server® 2008 R2
Microsoft Windows Server 2012
Microsoft Windows Server 2012 R2
Microsoft® Windows Server® 2016
Novell® SUSE® Linux Enterprise Server
Red Hat® Enterprise Linux
VMware® ESX®
Memory1
Up to 1.5TB (24 DIMM slots): 4GB/8GB/16GB/32GB/64GB DDR4 up to
2400MT/s
Drive Bays
Internal hard drive bay and hot-plug backplane:
Up to 16 x 2.5” HDD: SAS, SATA, Near-line SAS SSD: SAS, SATA
Up to 8 x 3.5” HDD: SAS, SATA, Near-line SAS SSD: SAS, SATA
Chassis
Dimensions: H: 8.73 cm (3.44 in.) x W: 44.40 cm (17.49 in.) x D:
68.40 cm (26.92 in.)
Availability
ECC memory
Hot-plug hard drives
Hot-plug redundant cooling
Hot-plug redundant power
iDRAC8
Internal Dual SD Module
Single Device Data Correction (SDDC)
Spare Rank
Tool-less chassis
Support for high availability clustering and virtualization
Proactive systems management alerts
iDRAC8 with Lifecycle Controller
Power
1100W AC, 86 mm (Platinum)
1100W DC, 86 mm (Gold)
750W AC, 86 mm (Platinum)
750W AC, 86 mm (Diamond)
495W AC, 86 mm (Platinum)
RAID Controllers
Internal:
PERC S130

PERC H330
PERC H730
PERC H730P
External:
PERC H830
Chipset
Intel C610 series chipset
Storage
HDD: SAS, SATA, near line SAS; SSD: SAS, SATA
16 x 2.5” – up to 29TB via 1.8TB hot-plug SAS hard drives
8 x 3.5” – up to 64TB via 8TB hot-plug near line SAS hard drives
Slots
Slot configuration #1:
Slot 1: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile brackett
Slot 2: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile brackett
Slot 3: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile brackett
Slot 4: Full Length, Full Height, and PCIe Gen3 x16 (x16 connector)
Slot 5: Full Length, Full Height, and PCIe Gen3 x8 (x16 connector)
Slot 6: Full Length, Full Height, and PCIe Gen3 x8 (x16 connector)
Slot 7: Full Length, Full Height, and PCIe Gen3 x8 (x16 connector)
Dedicated RAID card slot
Slot configuration #2:
Slot 1: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile bracket
Slot 2: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile bracket
Slot 3: Half Length, Half Height, and PCIe Gen3 x8 (x16 connector)
low profile bracket
Slot 4: Full Length, Full Height, and PCIe Gen3 x16 (x16 connector)
Slot 5: Full Length, Full Height, and PCIe Gen3 x8 (x16 connector)
Slot 6: Full Length, Full Height, and PCIe Gen3 x16 (x16 connector)
Dedicated RAID card slot
Network Controller
4 x 1Gb, 2 x 1Gb + 2 x 10Gb, 4 x 10Gb
Management
Dell Open Manage portfolio of systems management solutions,
including:
Open Manage Essentials console
iDRAC8 with Lifecycle Controller
iDRAC Direct
iDRAC Quick Sync
Open Manage Mobile
Embedded Hypervisor (Optional)
Optional supported hypervisors:

Microsoft® Windows Server® 2012, with Hyper-V®
Citrix® XenServer®
VMware® vSphere® ESXiTM
Communications
Broadcom 5719 quad-port 1Gb NIC
Broadcom 5720 dual-port 1Gb NIC
QLogic 57810 dual-port 10Gb DA/SFP+ CNA
QLogic 57810 dual-port 10Gb Base-T network adapter
Intel® Ethernet I350 dual-port 1Gb server adapter
Intel Ethernet I350 quad-port 1Gb server adapter
Intel Ethernet X540 dual-port 10GBASE-T server adapter
Mellanox® ConnectX®-3 dual-port 10Gb Direct Attach/SFP+ server
network adapter
Mellanox ConnectX-3 dual-port 40Gb Direct Attach/QSFP server
network adapter
Emulex® LPE 12000, single-port 8Gb Fibre Channel HBA
Emulex LPE 12002, dual-port 8Gb Fibre Channel HBA
Emulex LPe16000B, single-port 16Gb Fibre Channel HBA
Emulex LPe16002B, dual-port 16Gb Fibre Channel HBA
Emulex OneConnect OCe14102-U1-D 2-port PCIe 10GbE CNA
QLogic® 2560, single-port 8Gb Optical Fibre Channel HBA
QLogic 2562, dual-port 8Gb Optical Fibre Channel HBA
Qlogic 2660, single-port 16GB, Fibre Channel HBA, full height
Qlogic 2662, dual-port 16GB, Fibre Channel HBA, full height

Original HP ProLiant DL120 G7 1U Rack Mountable Server
(D8H79A) / Intel Xeon E3-1220/ 4GB / HP 500GB HDD/ RAID 0,1/
400W PS /3 Yrs Onsite
HP ProLiant DL120 G7 1U Rack Mountable Server (D8H79A) / Intel
Xeon E3-1220 (3.10GHz/4-core/8MB/80W) / 4GB / HP 500GB HDD
SATA / HP Smart Array B110i SATA RAID Controller/ 400W Power
Supply / 1-Port Ethernet Server Adapter (x2) / HP iLO 4 / 3 Yrs Onsite
Model HP ProLiant DL120 G7 Server
Processor Max Scalability 1
Configuration Intel® Xeon® E3-1220 (3.10GHz/4-
core/8MB/80W)
Memory Max Scalability 4 DiMM Slots
Configuration 4GB
Hard Disk Drive Max Scalability 4 LFF (3.5inch) Hot Plug
SATA/SAS
Configuration HP 500GB hot plug LFF SATA
RAID HP Smart Array B110i SATA RAID Controller
Optical Drive NONE
Power Supply Max scalability 2
Configuration 1 x 400W Power Supply
Network Controller 1-Port Ethernet Server Adapter (x2)
Expansion Slots PCIe G2 Full length, full height (x1) PCIe G2
Half height, low profile (x1)
Management HP iLO (Firmware: HP iLO 4)
Warranty 3 Yrs Onsite
Server Build Task Template
Physical Server Configurations (Windows)
Ite
m
No.
Description of Task Done
1 Minimum Disk Configuration shall be disk mirroring (RAID 1).
Backups will be STILL NEEDED even with disk mirror engaged.
2 Run at least 2 CAT5e/6 cables for NIC teaming
3 Run at least 2 power cables for dual power redundancy to the
system.
4 Use proper cable management mounting kit and run all cables
neatly
5 Connect failure indicator probe at the back of cable
management
6
Connect IP-KVM USB/PS2 dongle and register the machine
name on the KVM switch via LCD. Update your local IP-KVM
client database.
7 Make sure Memory Mirroring or Redundant Memory option is
disabled in BIOS
8 Label all network cables and any fiber cables using the

scheme defined in OS configuration for NICs (i.e.
TeamMember#1). Cabling should be done counter clockwise
on the back of the servers.
9 Disable DRAC if IP-KVM is connected
Physical Server Configurations (ESX)
Ite
m
No.
Description of Task Done
1 Follow all the steps above as described in Physical Server
Configurations (Windows)
2
Make sure all Hardware Virtualization features are turned on
in BIOS as per KB1003212, http://kb.vmware.com/kb/1003212
(VT, XD)
3 Add FC or iSCSI HBAs as required
4 Check hardware compatibility against HCL at
www.vmware.com/go/hcl
5 Disable onboard NICs and install quad ports PCI based NICs.
Operating System Installation (Windows – Physical)
Ite
m
No.
Description of Task Done
1
Partition the RAID enabled virtual disk into at least 2 logical
disks one for installing OS and other for applications and
Application Data.
2 Use C: for OS binaries and D: for application data. Name the
volumes as follows, C: - Local System, D: - Local Data
3 Apply all missing Windows Updates and Service Packs
4 Use the Dell System Build CD to install Open Manage software
and update drivers
5 Connect the machine to domain (domain.com)
6 Install Backup Exec Remote agent & schedule a backup
according to appropriate backup template(s) in Backup Exec.
7
Choose Best Performance for Visual Effects and Background
Services for better performance of the system unless different
options are required the application that will be installed on
the system.
8 Turn off Shutdown Event Tracker
9 Increase the paging file size by 1.5 times of physical RAM and
move it to a different drive (preferably different spindle).
10 Turn off Internet Explorer Enhanced Security Configuration for
Administrators
11 Configure at least two NICs team in Active/Active or

Active/Standby mode depending on switch topology. Name
the team NIC Team#1 and team members TeamMember#1,
TeamMember#2 depending on number of NICs present. For
servers with more than one NIC team, teams should be
numbered according to the scheme defined above. If more
than 2 NICs use beacon probing for Network failure detection.
12 Install MacAfee Anti-virus using required AV template
13 Change Local Administrator password to ‘AskYourManager’
Operating System Installation (Windows – Virtual Template)
Ite
m
No.
Description of Task Done
1
Create a new virtual machine and name it vt-w2k[version]-
[edition]-[service pack]-[C: space]. Use GPT if more than
2TB is required on the disks.
2 Assign the minimum system requirements in terms of RAM,
CPU, and disk space.
3 Align the disk with 512 KB offsets using diskpart. Follow the
this KB article, http://support.microsoft.com/kb/929491
4 Install appropriate OS
5
Follow steps 2 (DO NOT create D: drive), 3, 7-10, 13, 16 as
described above in Operating System Installation
(Windows – Physical)
6 Release/Remove any IP address(s) using ipconfig /release and
connect vNIC(s) to port group that is not routable
7 Follow appropriate Windows guides below in OS
Optimization & Performance Tuning (Windows)
8 Disconnect any mounted ISOs
Install VMware Tools (Complete with all features). Use host to
synchronize Windows time. Set VMware Descheduled Time
Accounting service to start automatically and start this
service. Disable Windows Time service
9 Convert VM to template
Operating System Installation (Windows – Virtual Machine)
Use an existing template to deploy a new VM unless a new
configuration is required
Ite
m
No.
Description of Task Done
1 Deploy a VM from template to cluster A initially for production
server. All tests, dev, and staging VMs should be deployed
cluster B. VMs for website should be deployed in Web cluster.

All tests machine used by individuals should be placed in Lab
& Test Machines folder in VC.
2 Customize OS using one of the customization specification
from the list
3
If adding additional disks follow step 3 above in Operating
System Installation (Windows – Virtual Template) for
each new disk
4
Assign appropriate VM Network and an IP address from the
subnet. Use x.x.x.x and x.x.x.x for DNS servers and x.x.x.1 as
default gateway depending on subnet.
5
Follow steps 3, 5 and 6 (only if VM will not be backed up by
vRanger Pro), 12, 14,15 above in Operating System
Installation (Windows – Physical)
6 Schedule Backup using backup software if required
OS Optimization & Performance Tuning (Windows)
Windows Server 2008 (x86 & 64-bit) – All Versions (Physical & VT)
Item
No. Description of Task Done
Turn off features
1
Turn off hibernation by issuing the following command in
command prompt:
powercfg -h off
2 Turn off Problem Reports and Solutions (Windows Error
Reporting)
3 Turn off IPv6
4 Turn off UAC
5 Install Remote Administration Tools as required
Disable Services: Turn off following services unless they are required the by
application(s) that will be installed on the system.
1 IP Helper
2
Base Filtering Engine (BFE): Depends on following services
- IPSec Policy Agent
- Windows Firewall
- IKE and AuthIP IPSec Keying Modules
3 Distributed Link Tracking Client
4 Human Interface Device Access
5 Print Spooler
6 Remote Registry
7 Windows Error Reporting Service
8 TPM Base Services

Windows Server 2003 (x86 & 64-bit) – All Versions (Physical & VT)
Item
No. Description of Task Done
Copy Source Binaries & Tools
1 Copy the content of i386 folder from CD to D:\i386 folder.
2 Install Windows Support Tools
3 Install Windows Resource Kit
Disable Services: Turn off following services unless they are required by
application(s) that will be installed on the system.
1 Distributed Link Tracking Client
2 Error Reporting Service
3 Performance Logs and Alerts
4 Remote Registry
Operating System Installation (ESX)
ESX 4.0 (64-bit x86 only)
Item
No. Description of Task Done
1 Gather following information prior to installation:
- Static IP address for management
- Host Name
- Domain Name if any
- DNS servers if any
- NTP servers if nay
- Names & IP addresses of other Hosts if joining a cluster

- Virtual Center name and IP address
- vRanger Pro server name and IP address if in use
- ESX serial key
- root Password
2
Use following Disk Partitioning recommendations. Give
service console partition maximum recommended size.
3
If installing on Dell server, download and use the latest Dell
System Installation CD to install OS and update drivers
(requires Systems Update Utility disks).
4 Change root password to ‘AskYourManager’
5
Allow root to connect to console:
Change PermitRootLogon to Yes in /etc/ssh/sshd_config file
Restart sshd by entering service sshd restart
6 Add all the hosts’ and machines’ FQDNs and IP addresses
that will communicate to this host to the host file.
7 After installing and configuring host, connect to host using
VIC
8 Apply necessary patches and driver updates to the host.
9 Install other software such as Open Manage or Cisco Nexus
1000v
10 Activate licensed features
11
Add appropriate Networking (vSwitches, vdSwitches, port
groups, service console etc.). Configure load balancing on
teams as follows:
- When connecting pNetworks to non-clustered
switches: Choose Load balancing type to Route
based on the original virtual port id, Choose
Network Failover detection to be Beacon probing
(only when 3 or more physical networks are
present), Notify Switches, and Failback. Use all
active adapters.
- When connecting pNetworks to clustered switches:
All same as previously except use Route based on
ip hash for load balancing type.
12
Modify ESX firewall to allow certain services such vRanger,
SCOM, and others as appropriate.
Incoming: SSH Server, SNMP Server, CIM Secure Server,
CIM Server, CIM SLIP
Outgoing: SSH client SNMP Server, VMware vCenter Agent,
VMware Update Manager, VMware Consolidated Backup,
CIM SLIP, Software iSCSI Client, SMB Client, NTP Client, NFS
Client,
13
Give maximum (800 MB) recommended RAM to service
console if using backup agents. Read this article for more
information, http://kb.vmware.com/kb/1003501
14 Add storage using either FC or iSCSI HBAs or software iSCSI

as appropriate. Format LUNs as VMFS3
15 Enable and configure NTP client to use ntp.metmusum.org
and tick.usno.navy.mil
16 Configure DNS and Routing in VIC
17 Add the host to appropriate cluster and apply cluster
policies
18 Test Vmotion, HA, DRS and other enterprise features
19 Enter host information in SMAC
Machine FQDN
Type
(Physical/Virtua
l)
Engineer
Date
Completed
Requester
Manager’s
Signature /
Initials
------------------------------------------------------------

Server Test Plan
Goals
The following test plan outlines the specific steps and configurations to be
tested in the validation process for VMware Infrastructure. The goals are
to quantify the likely performance of [product name], and to confirm that
support of such a configuration will not introduce new risk to our mutual
customers.
Outline additional goals/deliverables for this exercise below:
Application Configuration and Requirements:
This section provides details on the specific components of the
application. Where possible, a graphical representation of the application
should also be provided, with mappings of various functional requirements
to specific hardware hosts or virtual machines.
Application
Component
Software Version Hardware
Requirements
Application
Server
Product Version, OS CPU, RAM, DISK
Database
Server
Web Server
Virtual Machine Configurations
The test configuration consists of [n] VMware ESX hosts, each running
VMware ESX version [x.y] update [z].
Note: Configuration below is a sampling of hardware available at the
VMware validation lab, list out additional configurations as per the
requirements of the software product:

Hardwa
re Configuration (ESX) Virtual Machine

DL 580
2.93GHz 2 quad-core Intel
Xeon X7350
Four virtual machines
configured as application
servers, each with:
128GB RAM 2 vCPUs
4Gb Ethernet card 2GB memory
4 146GB SAS drives 1 Ethernet card
SAN NetApp FAS 3020 30GB storage
DL 380
3.16GHz 2 quad-core Intel
Xeon 7350
Four virtual machines
configured as Web servers,
each with:
32GB RAM <vCPU>
2Gb Ethernet card <RAM>
4 146GB SAS drives <Network>
SAN Net App FAS 3020 <Storage>
One virtual machines
configured as a data server
with:
<vCPU>
<RAM>
<Network>
<Storage>
460c
2.33GHz 2 Dual core Intel
Xeon 5460
One virtual machine configured
as an agent with:
16GB RAM <vCPU>
2Gb Ethernet card <RAM>
2 146GB SAS drives <Network>
SAN Net App FAS 3020 <Storage>
460c
2.33 GHz 2 Dual core Intel
Xeon 5460
One primary virtual machine
with:
16GB RAM <vCPU>
2Gb Ethernet card <RAM>
2 146GB SAS drives <Network>
SAN Net App FAS 3020 <Storage>
One client (workload driver)
virtual machine with:
<vCPU>
<RAM>
<Network>
<Storage>

Total storage required (for
example)
5 Disk Partitions:
 25GB for <OS>
 100GB for
<application>, backups,
flat file storage, page file
 150GB for data files
(actual database size will
be in the 50GB range)
 75GB for indexes
 50GB for logs
Benchmark Workload
This section describes the workload used, the load driver technology, and
the specific functional transactions included.
The workload is based on <load testing tool version x.y>. The workload
consists of the following transaction scripts (provide relevant workload
operations below):

Script Name Frequency of
Execution
Percentage of
Workload
Create New Ticket 4 per minute 20%
Add Workinfo to
Ticket
2 per minute 30%
Delete Ticket 1 per minute 10%
Close Ticket 6 per minute 20%
Escalate ticket 2 per minute 10%
Change User Info 2 per minute 5%
Update Support Team 2 per minute 5%
Driving the load of the workload will be done using <x> virtual machines,
each with <two virtual CPUs and 2GB of RAM>. The test usually runs for
<2 hours, with 30 minutes of ramp up, 30 minutes of ramp down, and 60
minutes of steady state execution where data is to be collected>.
Additional notes: <The database will incrementally grow during these
runs, but the overall volume is consistent enough that performance is not
expected to be effected by the small growth of the database>.

Test Cases
The following usecases will be tested, corresponding to our <medium and
large reference configurations>. Each configuration/workloads is
described below: <for example each configuration, 3 user counts will be
attempted, while resources and performance characteristics are
monitored and recorded>
<Medium> Configuration
The medium configuration consists of several virtual machines: two Web
servers, two application servers, a report server, and the database. The
test cases to be run and the data to be collected are as follows:
<User
Count>
Ave
Response
Time
CPU
Utilization
<Database>
Memory
Utilization
<
Database>
CPU
Utilizatio
n <Apps
tier
VM1>
200
400
800
<Large> Configuration

The large virtual machine configuration consists of 3 Web servers, 3
application servers, a report server, and the database. The test cases to
be run and the data to be collected are as follows:
<User
Count>
Ave
Response
Time
CPU
Utilization
<Database>
Memory
Utilization
<
Database>
CPU
Utilizatio
n <Apps
tier
VM1>
400
800
1000
(Optionally) VMware Infrastructure Testing
In order to understand how [ISV Product] works with higher level
functionality of VMware Infrastructure, we will perform one or more of the
following tests.
VMware vMotion Testing
While running the workload, VMware vMotion is used to execute manual
migration of the database virtual machine from one VMware ESX host to
another. During this test, response time and transaction rates are
monitored, and any observed slowdown in performance is measured. Five
such operations will be executed, and averages are then determined
across the five.
VMware Distributed Resource Scheduler (DRS) Testing
During this test, virtual machines are assigned to VMware ESX hosts such
that the majority of the load will be on one host. In the first test, set the
aggressiveness level of VMware DRS to “Conservative.” Start up the test
and monitor how VMware DRS moves virtual machines across a cluster to
balance the load. Monitor transaction throughput, as well as CPU
utilization of the various hosts in the cluster. You should see CPU
utilization balance across the hosts with little decrease in throughput. Now
run the same test after setting the aggressiveness of VMware DRS to a
substantially higher value. Typical deliverables are CPU charts from

VMware vCenter Server that reflect the balancing of the load during these
tests.
VMware High Availability (HA) Testing
Run the workload on a clustered resource pool, and then do a hard
shutdown of one host of the configuration. Note how the virtual machines
come up on another host in the cluster. Restart the application
components if necessary, and functionally verify that the application is
working again. Measure the time it takes for the virtual machine to start
accepting work again. This work is often most interesting in the case of
services that start automatically at reboot, such as Web servers, such that
the application will automatically be ready to work as soon as the virtual
machine is restarted on another host.
Wrap-up and Documentation
Where possible, results of testing are documented in a standard format
provided by VMware. This will then be entered into a template for a
deployment guide to be used as a starting place for documenting the
results of the testing. Where possible, the virtual machines used for
testing should be archived for possible use in the future. Any outstanding
issues should be documented for further follow-up with either VMware or
other ISV development teams.

Server Maintenance Plan
As part of our management services, we monitor over a dozen server
health metrics. By keeping track of things like swap usage, loads, mail
queue depth and more, our team of sysadmin often spot issues before
they become failures.
Should failures occur, our team can focus on fixing the issue rather than
worrying about maintenance items. This allows us to resolve most service
outages in minutes. We don’t have to stop and apply six months of OS
updates to see if a known bug is the issue.
We highly recommend automating server management and maintenance.
If you cannot automate, then create a schedule and stick to it. When we
first started in this business over 10 years ago, we did a lot of things
manually. That works well for a few severs, but once you have dozens of
systems to manage, you can miss things. Tools like Nagios, New Relic,
Pingdom, sysstat and many other open source and SaaS products can
help you keep tabs on your servers.
1. Verify your backups are working.
Before making any changes to your production system, be sure that your
backups are working. You may even want to run some test recoveries if
you are going to delete critical data. While focused on backups, you may
want to make sure you have selected the right backup location.
2. Check disk usage.
Don’t use your production system as an archival system. Delete old logs,
emails, and software versions no longer used. Keeping your system free of
old software limits security issues. A smaller data footprint means faster
recovery. If your usage is exceeding 90% of disk capacity, either reduce
usage or add more storage. If your partition reaches 100%, your server
may stop responding, database tables can corrupt and data may be lost.
3. Monitor RAID Alarms.
All production servers should use RAID. More importantly, you should be
monitoring your RAID status. In our decade plus in business, we have
worked on countless systems where the RAID failed. As a result, a single
disk failure caused a complete system failure. At rack AID, we either use
providers that monitor our RAID for us or we have setup direct RAID
monitoring. Roughly I estimate that RAID fails in about 1% of servers per
year. One percent may seem small, but a complete server failure can

turn a simple drive replacement into a multi-hour disaster recovery
scenario.
4. Update Your OS.
Updates for Linux systems are release frequently. Staying on top of these
updates can be challenging. This is why we use automated patch
management tools and have monitoring in place to alert us when a
system is out of date. If you are updating your server manually (or not at
all), you may miss important security updates. Hackers often scan for
vulnerably systems within hours of a issue being disclosed. If you cannot
automate your updates, then create a schedule to update your system. I
recommend weekly at a minimum for current versions and perhaps
monthly for older OS versions. I would also monitor release notices from
your distribution so you are aware of any major security threats and can
respond quickly.
5. Update your Control Panel.
If you are using a hosting or server control panel, be sure to update it as
well. Sometimes this means updating not only the control panel itself, but
also software it controls. For example, with WHM/cPanel, you must
manually update PHP versions to fix known issues. Simply updating the
control panel does not also update the underlying Apache and PHP
versions used by your OS.
6. Check application updates.
Web applications account for more than 95% of all security breaches we
investigate. Be sure to update your web applications, especially popular
programs like WordPress.
7. Check remote management tools.
If your server is co-located or with a dedicated server provider, you will
want to check that your remote management tools work. Remote console,
remote reboot and rescue mode are what I call the 3 essential tools for
remote server management. You want to know that these will work when
you need them.
8. Check for hardware errors.
You may want to review the logs for any signs of hardware problems.
Overheating notices, disk read errors; network failures could be early
indicators of potential hardware failure. These are rare but worth a look,
especially if the system has not been working within normal ranges.
9. Check server utilization.

Review your server’s disk, CPU, RAM and network utilization. If you are
nearing limits, you may need to plan on adding resources to your server
or migrating to a new one. If you are not using a performance monitoring
tool, you can install system on most Linux servers. This will provide you
some baseline performance data.
10. Review user accounts.
If you have had staff changes, client cancellations or other user changes,
you will want to remove these users from your system. Storing old sites
and users is both a security and legal risk. Depending on your service
contracts, you may not have the right to retain a client’s data after they
have terminated services.
11. Change passwords.
I recommend changing passwords every 6 to 12 months, especially if you
have given out passwords to others for maintenance.
12. Check system security.
I suggest a periodic review of your server’s security using a remote
auditing tool such as Nessus. Regular security audits serve as a check on
system configuration, OS updates and other potential security risks. I
suggest this at least 4 times a year and preferably monthly.

Security Policy and Plan
Policy Number: P001421CX
Policy Date: 25/09/2017
Purpose of the Policy
This policy provides guidelines for the protection and use of information
technology assets and resources within the business to ensure integrity,
confidentiality and availability of data and assets.
Procedures
Physical Security
For all servers, mainframes and other network assets, the area must be
secured with adequate ventilation and appropriate access through {insert
relevant security measure here, such as keypad, lock etc.}
It will be the responsibility of {insert relevant job title here} to ensure that
this requirement is followed at all times. Any employee becoming aware
of a breach to this security requirement is obliged to notify {insert
relevant job title here} immediately.
All security and safety of all portable technology, {insert relevant types
here, such as laptop, notepads, iPadetc.}Will be the responsibility of the
employee who has been issued with the {insert relevant types here, such
as laptop, notepads, iPads, mobile phones etc.}.Each employee is
required to use {insert relevant types here, such as locks, passwords,
etc.}And to ensure the asset is kept safely at all times to protect the
security of the asset issued to them.
In the event of loss or damage, {insert relevant job title here}will assess
the security measures undertaken to determine if the employee will be
required to reimburse the business for the loss or damage.
All {insert relevant types here, such as laptop, notepads, iPads etc.}When
kept at the office desk is to be secured by {insert relevant security
measure here, such as keypad, lock etc.}Provided by {insert relevant job
title here}

Information Security
All {insert relevant data to be backed up here – either general such as
sensitive, valuable, or critical business data or provide a checklist of all
data to be backed up }is to be backed-up.
It is the responsibility of {insert relevant job title here} to ensure that
data back-ups are conducted {insert frequency of back-ups here} and the
backed up data is kept {insert where back up data is to be kept e.g. cloud,
offsite venue, employees home etc. here}
All technology that has internet access must have anti-virus software
installed. It is the responsibility of {insert relevant job title here} to install
all anti-virus software and ensure that this software remains up to date on
all technology used by the business.
All information used within the business is to adhere to the privacy laws
and the business’s confidentiality requirements. Any employee breaching
this will be {insert relevant consequence here}
Technology Access
Every employee will be issued with a unique identification code to access
the business technology and will be required to set a password for access
every {insert frequency here}
Each password is to be {insert rules relating to password creation here,
such as number of alpha and numeric etc. Where an employee forgets the
password or is ‘locked out’ after {insert a number here e.g. three
attempts}, then{insert relevant job title here}is authorised to reissue a
new initial password that will be required to be changed when the
employee logs in using the new initial password.

User Documentation
The network managed by ISM Provision consists of your current existing network of
Extreme Network devices, or a subset of your devices. Many devices can be
managed by ISM Provision simultaneously. The devices are managed by querying
them for their configurations, and by sending new configuration commands to
them. Once ISM Provision manages a device, it will periodically check that the
device configuration for changes. ISM Provision Server the ISM Provision server is
the heart of ISM Provision. You may have more than one instance of the other
components, but only one server. The server contains the information about the
configurations of the managed devices, configurations that are scheduled to be
applied to the network at a later time, and previous configurations. An ISM
Provision server can contain the configurations of a large number of devices, but
does not communicate with the devices directly. Instead, it uses device
communicators to handle this task. The ISM Provision server also contains the
saved configuration changes that have not yet been applied to the network. These
changes may be saved to edit later, or may be applied at a future time to the
network. Device Communicators The device communicators control the
communication between the network devices and the ISM Provision server. All
queries to devices from the ISM Provision server and all commands from the ISM
Provision server to the devices are handled by the device communicators. To
spread the processing load across hosts, there can be more than one device
communicator in an ISM Provision installation, but only one per host.
Network Infrastructure Manager Client the Network Infrastructure Manager (NIM)
client is used to manage changes to the network infrastructure. With NIM you can
prepare and commit changes to the current network configuration, and add new
devices to be provisioned. Before changes are rolled out to your network, NIM tests
your proposed changes against a set of rules designed to spot and help you correct
errors (for example, duplicate IP addresses assigned to different VLANs).
Starting Network Infrastructure Manager
The following is a short summary of the steps to start Network Infrastructure
Manager
Summary Steps. To start Network Infrastructure Manager you must:
o 1 Launch the NIM Client
o 2 Specify the ISM Provision Server
o 3 Enter a User Account Name
o 4 Enter the Password for the Account
Launch the NIM Client
Launch the NIM client as you would launch other applications on
your host. For
example, Windows users can select Network Infrastructure
Manager from the
Start>Programs>Extreme Networks>ISM Provision>Applications
menu. Solaris
users can launch the nim executable file from the
/opt/extreme/ismprov/bin
directory by using a graphical file manager application to double-
click on its icon, or
by typing:
/opt/extreme/ismprov/bin/nim
Once the application starts, you will see the login screen
ISM Provision Server
Once the login screen appears, you will specify the ISM Provision server. Specify
the IP address of the server or the hostname by typing it into the server field.

Figure 2-2 shows the login screen and server field in more detail (if the server is on
the same host as the NIM client, you can also specify “localhost”).
NIM will store the IP addresses and names that you have specified in previous
sessions, so you may find your server already specified, or you may be able to
select.
Enter the Password for the Account
Enter the account password. The account passwords are not
saved and will need to be entered every session. Once the
information has been entered, click the Login to Server button,
then the NIM client will attempt to connect with the ISM
Provision server. While it is connecting you will see messages
similar to those in Figure 2-3.
Figure 2-3: The NIM Client Connecting to the ISM Provision Server
Once the NIM client is launched, you will see the Network Provision view.

Disaster Recovery Plan
The impact of a disaster that could have impacts including data loss,
corruption from hardware failure, human error, hacking, and malware
could have a significant and negative disruption to the all users. Having a
plan in place for data backup, and restoration of electronic information is
critical to ensuring a state of continuity to be able to restore from a
remote server is a vital step in having the right infrastructure for the
business or enterprise.
There are simple strategies to limit disruptions to workstations, servers,
users and the business effected including
 Having a secure computer room and with a backup power supply
 Ensuring and check the condition of hardware e.g. networks,
servers, desktops, laptops and other peripheral devices.
 Completing periodical connectivity checks on fibre, cable, wireless
 A backup, remote server for data restoration.
Critical
System
RTO Threat Prevention
Strategy
Response
Strategy
Recovery Strateg
Workstati
ons
6
Hour
s
Hardware
Failure, Flood,
Fire, Terrorism
Periodical
Backups on
both physical
and
cloud/remote
servers
Restore latest
backup from
physical server
Ensure cloud/rem
server with perio
backup is created
prior to backing o
physical server.
Physical
Server
6
Hour
s
Hardware
Failure, Flood,
Fire, Terrorism
Ensure
periodical
backups are
on
cloud/remote
server
Restore from
cloud/remote
server, and
keep making
periodical
backups
Download restore
backup from clou
remote server an
install on physica
server and
workstations
Cloud-
Remote
Server
6
Hour
s
Exploitation,
unable to
restore backup
if no internet
connection
Ensure
internet/wirel
ess is setup
first instance
after disaster
if effected
Ensure
internet/wireles
s is setup first
instance after
disaster if
effected
If there’s interne
wireless connect
restore cloud –
remote server
straight away.
Firewalls
– Security
2
Hour
s
Losing firewalls
specifications
perimeters,
settings, and
security
changes
Backup on
both physical
and cloud-
remote
server if
possible and
note
specification
If there’s
backup of
firewalls and
security
specifications
restore.
Otherwise need
to redo
Restore straight
away to ensure
workstations,
physical servers,
cloud- remote
servers are prote

s to restore
later.
specifications
from
knowledge.
Ongoing Maintenance Support (SLA)
Confidentiality Statement
This document contains confidential and proprietary information of the
Government of the Northwest Territories (GNWT) and <Service Provider
Name> (the “service provider”), which must be kept confidential.
Duplication or use other than for evaluation purposes in connection with
negotiating and implementing a definitive written agreement for the
provision of application maintenance outsourcing services is strictly
prohibited. This document must be returned to the GNWT in the event
such an agreement is not enacted.
Parties and Timeline
This service level agreement is between the service provider and the
GNWT from <Start Date (YYYY-MM-DD)> to <End Date (YYYY-MM-DD)>.
 This service level agreement is effective as of the date of the
signatures below. The GNWT and the service provider shall review
at least quarterly to determine if any modifications or amendments
are needed to reflect the GNWT’s support requirements and service
provider’s services.
 The purpose of this service level agreement is to document the service
delivery of the service provider to the GNWT.The service provider shall
deliver the services set forth in this document. The GNWT shall pay for
the services covered by this Agreement in accordance with billing and
payment terms that have been agreed upon by the GNWT and service
provider.
Service Catalogue
The service provider will provide the following services to the GNWT:
Service Description Examples
User Support Receive, document, and
prioritize issue tickets and help
GNWT staff in the use of
existing applications or services.
 Provide help desk
support
 Answer queries
about applications.
 Receive and
document bug
reports.
 Collect and
document requests

for changes.
 Share status of
requests.
Problem
Correction
Bring an application back to its
original functionality before the
problem arose. This may include
a permanent fix or a temporary
work around until a permanent
fix is found.
 Fix bugs.
 Retrieve
functionality after
abnormal program
terminations.
 Complete root
cause analysis.
Application
Enhancement
Modify the functionality of an
existing application.
 Apply new
functionality.
 Fulfil regulatory
requirements.
 Enhance run-time
efficiency.
 Modify applications
based on new
releases of
hardware or
software.
Process and
Application
Improvement
Assist GNWT in planning the
better use of applications to
meet business strategy and
goals. This is a proactive
attempt by the service provider
to improve applications and
processes, based on the service
provider’s increased application
and business knowledge over
time.
 Help GNWT staff to
make strategic
decisions that
meet business
goals.
 Provide functional,
architectural and
process
improvements as
required for the
support and
maintenance of the
system areas in
scope.
<Other
Services>
Rewards and Penalties
Each SLA is measurable and associated with a financial penalty if not met.
Some SLAs are associated with rewards for exceptional performance.
 Penalty. A deduction from the service provider’s monthly invoice
expressed as a percentage of the agreed upon service delivery fee
for the month in which a particular SLA was not met.

 Reward. A premium added to the service provider’s monthly
invoice expressed as a percentage of the agreed upon service
delivery fee for the month in which a particular SLA was exceeded.
Reporting
The following processes will be used in order to manage the application
maintenance outsourcing agreement:
Weekly Status Report
The service provider to provide the GNWT with a weekly status report that
gives an overall summary of the following:
 Project health
 On-going activities
 Completed tasks
 Upcoming milestones and releases
 Bug fixes
 Risk identification and mitigation plan
 Action items across different application areas
Monthly Review Meeting
Metrics will be tracked by service provider, summarized in a dashboard
format, and discussed in a monthly meeting. This activity includes the
following:
 Tracking unresolved issues from maintenance projects which impact
the SLA
 Updating maintenance project progress and resolving critical issues
 Capturing agreements and disagreements and items needing
escalation
Quarterly Review Meeting
A quarterly review meeting will include the following:
 The SLA will be reviewed with the IS managers involved and an
amendment addendum will be created if required
 Review process will be through teleconference or face-to-face
meeting session which will be booked in advance
 Review document prepared by service provider will include overall
project status, issues list, metrics reporting, supporting reasons for
metrics deviation, and items that need adjustment within SLA (e.g.
scope, metrics, etc.)
 SLA changes will be tracked by version number and date
Reporting Service Levels
Type Measurement Penalty
Weekly
Status
Report
Delivered at not less than seven calendar
day intervals
5% of
monthly
invoice

Monthly
Status
Report
Delivered at monthly intervals and not less
than two business days before scheduled
review meeting
5% of
monthly
invoice
Quarterly
Status
Report
Delivered at quarterly intervals and not
less than five business days before
scheduled review meeting
5% of
monthly
invoice
User Support and Problem Correction
The following procedures will be used to respond to problems that are
received by the help desk. A problem is defined as an unplanned system
event which adversely affects application processing or application
deliverables.
Measurement period for User Support and Problem Correction SLAs is a
calendar month. For example, if an SLA is not met during the month of
April, one penalty deduction (as outlined in the SLA associated with that
particular service) will be applied to the invoice for the month of April, and
if it is not met for the month of May, an additional penalty deduction will
be applied to the invoice for the month of May.
Prioritization Approach
Service requests for problems received by the help desk will be given a
Severity Code from 1 – 4 based on how important responding to the
problem is to the primary business of GNWT as a whole, as well as the
availability of workarounds. The Severity Code will be the basis for
scheduling work on the backlog and assigning resources to the request.
Critical, important, and supportive application functions are defined in the
section below on Application Function Type, with a complete list of
application functions included in this agreement listed in Appendix A.
Severity
Code Definition
1 A problem has made a critical application function unusable or
unavailable and no workaround exists.
2 A problem has made a critical application function unusable or
unavailable but a workaround exists.
or
A problem has made an important application function
unusable or unavailable and no workaround exists.
3 A problem has diminished critical or important application
functionality or performance but the functionality still
performs as specified in the user documentation.
4 A problem has diminished supportive application functionality
or performance.
Application Function Type
The table below provides a brief definition of critical, important, and
supportive application functions. See Appendix A for a complete list of the
application functions included in this agreement.

Application
Function
Type
Description Example
Critical
These application functions are critical
to ensuring business profitability or
GNWT reputation. Extended failure will
impact profit or damage GNWT
reputation.
Oracle
Financials,
Accounts
Receivable
Custom
Application,
Price index
engine
Important
These application functions are
important to business productivity, but
are not critical to profitability or GNWT
reputation.
<Add functions
as necessary…>
Supportive
These applications support
productivity, but are not essential to
business effectiveness.
<Add functions
as necessary…>
Response and Resolution Times
Severity codes are used in order to determine appropriate response and
resolution times. Response and resolution times are measured from when
the incident is opened by the help desk. If the problem is not resolved
within the defined timeframe, continuous effort will be applied until the
problem is resolved.
Severity
Code
Initial
Respons
e
Estimation
Response
Subsequent
Responses Resolution
1 15
minutes
2 hours Every 30 min. 4 hours
2 30
minutes
2 hours Every 2 hours 8 hours
3 1 hour 8 hours Every 4 hours 4 calendar
days
4 1 hour Next business
day
Weekly 20 calendar
days
 Initial Response is when a ticket is opened and acknowledged by
help desk staff.
 Estimation Response is when the user that logged the ticket is
informed of an estimated resolution time.
 Subsequent Responses is the frequency with which the user that
logged the ticket is updated on the resolution status.

 Resolution is the point at which the problem is resolved and the
application function is returned to a usable and available state.
Response and Resolution Service Levels
Type Measurement Reward Penalty
Severity 1
Resolution
All Severity 1 problems are
resolved in less than 2 hours.
10% of
monthly
fees
NA
One or more Severity 1
problems are resolved in
over 4 hours.
NA 10% of
monthly
fees
Severity 2
Resolution
Less than 95% of Severity 2
problems are resolved in 8
hours.
NA 10% of
monthly
fees
Severity 3
Resolution
Less than 95% of Severity 3
problems are resolved in 4
calendar days.
NA 5% of
monthly
fees
Severity 4
Resolution
Less than 95% of Severity 4
problems are resolved in 20
calendar days.
NA 5% of
monthly
fees
Response/
Estimate
Less than 95% of Initial
Response, Estimation
Response, and Subsequent
Response times are met.
NA 5% of
monthly
fees
End user
satisfaction
More than 95% of completed
scores on problem resolution
satisfaction survey have a
rating of satisfied or very
satisfied.
5% of
monthly
fees
NA
Less than 80% of completed
scores on problem resolution
satisfaction survey have a
rating of satisfied or very
satisfied.
NA 10% of
monthly
fees
Maximum
Problem Backlog
There are always less than
<maximum> unresolved
problems.
5% of
monthly
fees
NA
Maximum
Problem Aging
No problem is older than 60
days.
5% of
monthly
fees
NA
 End user satisfaction is the rating provided by end users after the
problem they logged is resolved.
 Problem backlog is the maximum number of unresolved problems.
 Problem aging tracks unresolved problems that is older than 60
days.

Application Availability
Availability is defined as the ability of an end user to access and execute
any of the included application functions from a functioning workstation
and live network connection. For an application to be available, all of its
supporting systems must be operational.
Application
Level
Business Hour
Availability Off-Hour Availability Scheduled
Down-Time
Definition
Monday - Friday
8:30am-5:30pm
MST
Monday – Friday 5:31pm-
8:29am MST AND
Saturday – Sunday 8am –
8am MST
Critical
99.5% 99.5% Sunday
12:01am –
8am MST
Important
99% 98% Sunday
12:01am –
8am MST
Supportive
98% 98% Sunday
12:01am –
8am MST
 Any additional outages must be scheduled and approved by the
GNWT at least two weeks in advance, unless there is an emergency.
Application Availability Service Levels
Type Measurement Reward Penalty
Critical
Application
Availability
Availability exceeds 99.5%
every day in a 1 month period.
10% of
monthly
fees
NA
Availability falls below 99.5%
for more than 2 days of the
month during regular business
hours.
NA 10% of
monthly
fees
Important
Application
Availability
Availability falls below 99% for
more than 2 days of the month
during regular business hours.
NA 10% of
monthly
fees
Supportive
Application
Availability
Availability falls below 98% for
more than 2 days of the month
during regular business hours.
NA 5% of
monthly
fees
Application Enhancement
Application enhancement projects involve functional enhancements made
to a properly working application to accommodate new or changed user
requirements. Examples include increasing an application’s performance,
enhancing a user interface, or optimizing code.
Application enhancements can be requested by the GNWT or proposed by
service provider. The GNWT will prioritize the order in which
enhancements are performed.

Project Management
The service provider is expected to manage application enhancement
projects in a structured, organized, and cost effective manner.
 Measurement period for Project Management SLAs is either the
entire project span or the milestone completion span.
Project Management Service Levels
Type Measurement Reward* Penalty
Project Delivery Total elapsed days
until delivery is
more than 20%
greater than
planned.
NA 10% of the
amount
invoiced for
the project.
Total elapsed days
until delivery is
20% less than
planned.
5% of the
amount
invoiced for the
project.
NA
Project Budget
for Time and
Material Based
Projects
Total billed hours
for the project are
more than 10%
greater than the
planned hours.
NA 10% of
invoiced hours
for the project
multiplied by
the average
hourly billing
rate for such
hours.
Total billed hours
for the project are
less than 80% of
the planned hours.
5% of the
amount
invoiced for the
project.
NA
Project
Milestones (for
Conventional
Projects)
Total elapsed days
until milestone
completion is 20%
less than planned.
5% of invoiced
hours for the
milestone task
multiplied by
the average
hourly billing
rate for such
hours.
NA
Total elapsed days
until milestone
completion is more
than 20% greater
than planned.
NA 10% of
invoiced hours
for the
milestone task
multiplied by
the average
hourly billing
rate for such
hours.

Sprint
Outcomes
(for Agile
Projects)
Total elapsed days
from the start to
the end of sprint
are greater than
planned.
or
Functionality
planned for a sprint
is not delivered or
documented.
NA 15% of the
amount
invoiced for
the sprint.
Documentation
Updates (both
technical and
functional)
Service provider
provides
documentation
later than 1 week
after user
acceptance testing
is completed.
NA 5% of the
amount
invoiced for
the project.
Software Quality
The service provider will apply appropriate process and practices in order
to deliver high quality software to the GNWT containing as few defects as
is practical. Defects can include the following:
 Software bugs (e.g. errors or faults in source code or design that
cause an application to produce an unexpected result).
 Software that is made up of working code but does not meet the
initial requirements lay out by the GNWT and described in the
functional specifications.
Software Quality Service Levels
Type Measurement Reward Penalty
Success
Rate at User
Acceptance
Test
More than 95% of
user acceptance
test cases in this
month pass on the
first execution.
10% of monthly
fees
NA
Less than 80% of
user acceptance
test cases in this
month pass on the
first execution.
NA 20% of monthly
fees
Number of
Severity 1
problems
post
production
There is no increase
in the number of
Severity 1 problems
for 30 days after
release to
production
10% of the
amount
invoiced for the
project.
NA
There is more than
a 15% increase in
NA 15% of the
amount invoiced

the number of
Severity 1 problems
for 30 days after
release to
production
for the project.
Number of
Severity 2
problems
post
production
There is no increase
in the number of
Severity 2 problems
for 30 days after
release to
production.
5% of the
amount
invoiced for the
project.
NA
There is more than
a 15% increase in
the number of
Severity 2 problems
for 30 days after
release to
production
NA 10% of the
amount invoiced
for the project.
Number of
Severity 3
problems
post
production
There is more than
a 20% increase in
the number of
Severity 3 problems
for 30 days after
release to
production.
NA 10% of the
amount invoiced
for the project.
End user
satisfaction
Less than 80% of
completed scores
on application
enhancement
satisfaction
surveys have a
rating of satisfied
or very satisfied.
NA 10% of the
amount
invoiced for the
project.
* When compared to the most recent month in which there were no new
application enhancements released into production.
Process and Application Improvement
The service provider will help the GNWT to improve its applications and
application maintenance processes over time, in line with the GNWT’s
business goals and strategy. As service provider gains increased
application and business knowledge, it is expected that service provider
will help the GNWT to plan the better use of applications to meet business
goals.
There are no SLAs associated with Process and Application Improvement.

Signatures
For the service provider
Name:
_________________________________
Signature:
______________________________
Title:
__________________________________
Date:
__________________________________
For the GNWT
Name:
_________________________________
Signature:
______________________________
Title:
__________________________________
Date:
__________________________________
The service provider and the GNWT agree to the service levels and terms
outlined in this agreement.

Project Plan
GOALS AND OBJECTIVES
Business Goals and Objectives
The business goals and objectives for this project will focus on
implementing mobile technology that:
 Improves officer, fire-fighter and citizen safety.
 Facilitates coordination and information sharing both internal and
external to the participating organizations.
 Enhances the ability and effectiveness of staff to perform their
jobs.
 Facilitates coordinated crime prevention and reduction.
 Provides high levels of data security.
 Provides an open, flexible, reliable technology base for the
future.
 Facilitates the electronic capture of data at its source.
 Is easy to use.
 Eliminate redundant data entry throughout the organization.
Project Goals and Objectives
Sample project goals and objectives:
 Ensure that end users have input into the design process.
 Accomplish project business goals and objectives within defined
budget and time parameters.
 Minimize impact to standard business operations within the
affected units.
 Craft a favourable and secure agreement between the
Department and the selected vendor.
Risk Assessment
The initial Risk Assessment (following page) attempts to identify,
characterize, prioritize and document a mitigation approach relative to
those risks which can be identified prior to the start of the project.
The Risk Assessment will be continuously monitored and updated
throughout the life of the project, with monthly assessments included in
the status report (see Communications Plan) and open to amendment by
the Project Manager.
Because mitigation approaches must be agreed upon by project
leadership (based on the assessed impact of the risk, the project’s ability

to accept the risk, and the feasibility of mitigating the risk), it is necessary
to allocate time into each Steering Committee meeting, dedicated to
identifying new risks and discussing mitigation strategies.
The Project Manager will convey amendments and recommended
contingencies to the Steering Committee monthly, or more frequently, as
conditions may warrant.
Poor Functional Match of Package to Initial System Requirements: Minimal
customization required Unlikely although a package has not yet been
selected; the Consultant has compared the initial requirements with
available functionality and determined that a functional match to the
initial requirements is very likely. Vendor selection will be based, in part,
on how well the proposed application matches defined functional
specifications.
Team’s Involvement in Package Selection Impacts Success of
Implementation L: High involvement in selection Unlikely
Comprehensive vendor evaluation and selection process
incorporated into Project Plan
Milestones
The following represent key project milestones, with estimated completion
dates:
Milestone Estimated Completion Date
Phase I: XXX
Initial Steering Committee Meeting 00/00/2003

ASSUMPTIONS
Project Assumptions
The following assumptions were made in preparing the Project Plan:
OPD employees are willing to change business operations to take
advantage of the functionality offered by the new mobile technology.
Management will ensure that project team members are available as
needed to complete project tasks and objectives.
The Steering Committee will participate in the timely execution of the
Project Plan (i.e., timely approval cycles and meeting when required).
Failure to identify changes to draft deliverables within the time specified
in the project timeline will result in project delays.
Project team members will adhere to the Communications Plan.
Mid and upper management will foster support and “buy-in” of project
goals and objectives.
The City will ensure the existence of a technological infrastructure that
can support the new mobile technology.
All project participants will abide by the guidelines identified within this
plan.
The Project Plan may change as new information and issues are
revealed.
CONSTRAINTS

Project Constraints
The following represent known project constraints:
Project funding sources are limited, with no contingency.
Due to the nature of law enforcement, resource availability is
inconsistent.
Related Projects
Critical Project Barriers
Unlike risks, critical project barriers are insurmountable issues that can be
destructive to a project’s initiative. In this project, the following are
possible critical barriers:
Removal of project funding Natural disasters or acts of war
Should any of these events occur the Project Plan would become invalid?
PROJECT MANAGEMENT APPROACH
Project Timeline
Insert here
Project Roles and Responsibilities
Role Responsibilities Participant(s)
Project Sponsor Ultimate decision-maker and tie-breaker Provide project oversight and guidance Review/approve some project elements Insert Name Commits department resources approves major funding and resource allocation strategies Resolves conflicts and issues Provides direction to the Project Manager Review project deliverables
Project Manager

 Manages project in accordance to the project plan Serves as liaison to the Steering Committee Receive guidance from Steering Committee Supervises consultants Supervise vendor(s) Provide overall project direction Direct/lead team members toward project objectives Handle problem resolution Manages the project budget Debbie Whitson
Project Participants Understand the user needs and business processes of their area Act as consumer advocate in representing their area Communicate project goals, status and progress throughout the
project Review and approve project deliverables Creates or helps create work products Coordinates participation of work groups, individuals and
stakeholders Provide knowledge and recommendations Helps identify and remove project barriers Assure quality of products that will meet the project goals and
objectives Identify risks and issues and help in resolutions
Issue Management
The information contained within the Project Plan will likely change as the
project progresses. While change is both certain and required, it is
important to note that any changes to the Project Plan will impact at least
one of three critical success factors: Available Time, Available Resources
(Financial, Personnel), or Project Quality. The decision by which to make
modifications to the Project Plan (including project scope and resources)
should be coordinated using the following process:
Step 1: As soon as a change which impacts project scope, schedule,
staffing or spending is identified, the Project Manager will document the
issue.
Step 2: The Project Manager will review the change and determine the
associated impact to the project and will forward the issue, along with a
recommendation, to the Steering Committee for review and decision.
Step 3: Upon receipt, the Steering Committee should reach a consensus
opinion on whether to approve, reject or modify the request based upon
the information contained within the project website, the Project

Manager’s recommendation and their own judgment. Should the Steering
Committee be unable to reach consensus on the approval or denial of a
change, the issue will be forwarded to the Project Sponsor, with a written
summation of the issue, for ultimate resolution.
Step 4: If required under the decision matrix or due to a lack of consensus,
the Project Sponsor shall review the issue(s) and render a final decision on
the approval or denial of a change.
Step 5: Following an approval or denial (by the Steering Committee or
Project Sponsor), the Project Manager will notify the original requestor of
the action taken. There is no appeal process.
Communications Plan
Disseminating knowledge about the project is essential to the project’s
success. Project participants desire knowledge of what the status of the
project is and how they are affected. Furthermore, they are anxious to
participate. The more that people are educated about the progress of the
project and how it will help them in the future, the more they are likely to
participate and benefit.
This plan provides a framework for informing, involving, and obtaining
buy-in from all participants throughout the duration of the project.
Audience this communication plan is for the following audiences:
 Project Sponsor
 Steering Committee
 Project Manager
 User Group Participants
 Subject Matter Experts
Communications Methodology The communications methodology utilizes
three directions for effective communication:
Top-Down It is absolutely crucial that all participants in this project sense
the executive support and guidance for this effort. The executive
leadership of the organization needs to speak with a unified, enthusiastic
voice about the project and what it holds for everyone involved. This will
be 'hands-on' change management, if it is to be successful. Not only will
the executives need to speak directly to all levels of the organization, they
will also need to listen directly to all levels of the organization, as well.
The transition from the project management practices of today to the
practices envisioned for tomorrow will be driven by a sure and convinced

leadership focused on a vision and guided by clearly defined, strategic,
measurable goals.
Bottom-Up to ensure the buy-in and confidence of the personnel involved
in bringing the proposed changes to reality, it will be important to
communicate the way in which the solutions were created. If the
perception in the organization is that only the Steering Committee created
the proposed changes, resistance is likely to occur. However, if it is
understood that all participants were consulted, acceptance seems more
promising.
Middle-Out Full support at all levels, where the changes will have to be
implemented, is important to sustainable improvement. At this level (as
with all levels), there must be an effort to find and communicate the
specific benefits of the changes. People need a personal stake in the
success of the project management practices.
Communications Outreach The following is a list of communication events
that are established for this project:
Monthly Status Reports the Project Manager shall provide monthly written
status reports to the Steering Committee. The reports shall include the
following information tracked against the Project Plan:
- Summary of tasks completed in previous month
- Summary of tasks scheduled for completion in the next month
- Summary of issue status and resolutions
Monthly Steering Committee Meeting These status meetings are held at
least once per month and are coordinated by the Project Manager. Every
member of the Steering Committee participates in the meeting. The
Project Manager sends the status report to each member of the team prior
to the meeting time so everyone can review it in advance.
Bi-Monthly Project Team Status Meeting These status meetings are held
every other month. Every member of the Project Team will be invited to
participate in the meeting. Project Manager sends the status report to
each member of the team prior to the meeting so everyone can review it
in advance.
Website Use User Group Participants and Subject Matter Experts may be
updated monthly at the discretion of the Project Manager. Information will
be posted to the project’s website.

Handover Schedule and Post Implementation
Review
1 Project Closing Process
The Project Transition Task Control Document will document the
successes and failures of the project. It provides a historical record of
the planned and actual budget and schedule, recommendations for
future projects of similar size and complexity, information on staffing
and skills used to meet project objectives and goals, how the customer
expectations were managed, lessons learned, and an official project
sign-off. Sections of this report include:
 Project Background– the purpose of this section is to provide
project background information for future team members who may
need to review this information.
 Project Completion – this section documents whether the project
objectives, benefits and deliverables were met successfully to the
customer’s satisfaction and any outstanding items to be addressed
in future phases.
Completion Criteria Tab
This part of the report should demonstrate how the customer’s
expectations were initially determined and how they were managed
throughout the life of the project. List the criteria which must be met to
confirm that the project is completed. For each criteria listed, assess
whether or not it has been achieved to the satisfaction of the customer.
Outstanding Items Tab
List any outstanding items which still need to be undertaken even
though the project has satisfied the above completion criteria. For each
item, list the actions required to be undertaken and the owner
responsible for undertaking the action.
 Project Closure–this section outlines the next steps required for
the handover of deliverables and documentation to the customer,
the termination of supplier contracts, the release of project
resources, and communication to all stakeholders that the project is
closed. Specific information related to closing the project budget,
developing a transition plan and archiving information is provided in
this document.
Final Budget vs. Actual Tab
Document the final budget vs. actual cost of the project. Provide any
other comments that relate to the overall budget and/or actual cost.

Deliverable Transition Tab
Identify a transition plan for the release of all project deliverables to
the customer.
Other Resource Transition Tab
Identify non-personnel resources that will require transition, what it has
been used for, what is required to transition, target release date and
person responsible for completing the transition.
Technical Transition Tab
Identify details needed to transition support to an identified technical
support group by listing the details for support hours, rollout plan to
the support group, how issues are escalated and to who, supporting
documentation and location where stored, any known users questions
and answers and any additional information that may be needed.
Closure Communication Tab
Identify a plan to communicate the project closure to all stakeholders
and interested parties. An example is provided.
2 Staffing Transfer and Release
Staffing Transfer/Release refers to the process used to accommodate
staff changes or shift staff project responsibilities as the project comes
to a close.
Maintaining full project staffing through the completion of the project is
an important element for project success. Employees who know that
management is actively managing their professional interests are less
likely to leave a project effort before completion.
Since employees are given employment expectations when joining the
project, they know what to expect at the end. Well planned Staffing
Transfer or Release efforts reflect professional courtesy and reduce the
prospect of disgruntled employees. Employees participate
wholeheartedly throughout the project, instead of looking for the next
assignment to the detriment of the current project.
Process of releasing staff
 Plan for the next assignment for project staff. Do not wait until the
last minute to care for project staff futures. Plan ahead and be
prepared.
 Honour and thank staff and contractors for project contributions.
 Consider current project employees for on-going Maintenance and
Operations roles.
 Provide resource manager with performance evaluation
recommendations.

Staff Planning Tab
Assign steps for handling the Staff Transitions, identify when the tasks
need to be complete, if there are any dependencies and the current
status.
Staff Transition Tab
Identify a hand-over plan for the release of all project staff. An
example is provided.
3 Financial Closure
Financial closure is the process of completing all project-related
financial transactions, finalizing and closing the project financial
accounts, disposing of project assets and releasing the work site.
Financial closure is a prerequisite to project closure and post
implementation review. Financial closure establishes final project costs
for comparison against budgeted costs as part of the post review.
Process of Financial Closure
 Establish and publish to all project staff and vendors the deadline
date for the completion of all financial transactions and closing of
financial accounts. This includes completing timesheets.
 Verify that all acceptance criteria in the Statement of Work have
been met prior to payments to vendors and consultants.
 Verify that there are no outstanding invoices or unresolved financial
obligations.
 Close financial accounts according to applicable agency, state and
federal accounting procedures.
 Comply with all applicable funding source requirements for records
retention and financial reporting.
Financial Closure Tab
Identify closure tasks, assign person responsible, set a date for
completion, identify any dependencies and indicate the current status.
4 Lessons Learned
This is valuable to the closure and release mechanism for team
members regardless of the project’s success. The lessons learned
session is a meeting including the project team, stakeholders
representation, management, and if applicable, the staff who will take
over operation of the product. This session will provide a forum for
praise and recognition and an opportunity to discuss ways to improve

future processes and procedures. Lessons learned should not only
identify the bad things that occurred but also those things that were
good and had a positive effect on the project. The intention is to
eliminating their occurrence of the negative items in future endeavors
from happening and to increase success of projects by repeating the
things that went right. It is important, that the discussion of lessons
learned do not point a finger at a target but to identify ownership for
the problem areas and to developing useful recommendations for future
processes. The Project team members and customers should submit
lessons learned as they occur, rather than waiting until the post
implementation review.
5 Project Archive
A Project Archive refers to the gathering and storing of project artifacts
(e.g., project charter, working documents, etc.) at the close of the
project. Retaining historical project documents can provide information
for future projects, for on-going operational support, and for answering
questions regarding the project.
Process of Project Archiving
 Use a folder structure to store electronic artefacts that is
documented.
 Secure artefacts so they cannot be modified.
 Include a description of the artefacts being stored, the software
used to create the artefacts, a point of contact, and description of
folder structure.
 Ensure the support team has knowledge of, and access to, all the
project artefacts.
Documentation Transition Tab
Identify a hand-over plan for the release of all project documentation
to the customer. A sample documentation plan is provided and may
not apply due to project uniqueness.
6 Contractor Closing Plan
After a project has been completed you must ensure that a contractor
closing plan is executed. The contractor closing plan is executed to
ensure that permissions are removed from project environment and to
ensure that knowledge transfer occurred with the appropriate people.
These steps are generally included in the overall project close-out.
 Ensure that security badges have been turned in
 Access to applications has been disabled. Accounts must be
disabled in the application(s) and in the database(s)
 Submit an account deletion form

 Knowledge Transfer Demonstrated
Supplier Transition/Termination Tab
Identify a hand-over plan for the termination of project supplier
contracts. An example is provided.
7 Customer Project Signoff
 An important task of closing a project is the acceptance of the
project deliverables by the customer. The best way to resolve this is
to convene a final customer review of the deliverables against the
requirements and specifications, any deviations from the
established requirements will have been documented and approved.
During the review you will go over the deviations and justifications.
In addition you will cover any open items (action items, issues, etc.)
in an effort to close them. By drawing all of the stakeholders
together in a single meeting, you can avoid closing these open
items on an individual basis. Approval – Certification by both the
customer and WVOT project managers that the project has been
officially closed.