Vmware Process

Contents
TCRS / VMWare Process............................................................................................................ 1

Contents.................................................................................................................................. 2
Description of Workflow and Field Documentation:..........................................................3
Request Initiation.................................................................................................................... 4
A. Process Overview......................................................................................................... 4
B. Exit Point Validations.................................................................................................... 8
C. Required Fields............................................................................................................. 9
A.
Process Overview.................................................................................................... 15
B.
Required Fields........................................................................................................ 16
C.
Exit Point Validations............................................................................................... 16
Business P&L Approval and CSI Approval (Parallel)...............................................................16

A1. Process Overview..................................................................................................... 16
B1. Required Fields......................................................................................................... 16
C1. Exit Point Validations................................................................................................ 17
A2. Process Overview..................................................................................................... 17
B2. Required Fields......................................................................................................... 18
C2. Exit Point Validations................................................................................................ 18
CTI Acceptance..................................................................................................................... 19
A.
B.
Required Fields........................................................................................................ 20
C. Exit Point Validations.................................................................................................. 20

VMWare Provisioning............................................................................................................. 20
A.
B.
Required Fields........................................................................................................ 21
C. Exit Point Validations:................................................................................................. 22

O/S Build Approval................................................................................................................ 23
A.
B.
Required Fields........................................................................................................ 23

SA Validation........................................................................................................................... 24
A.
B.
Required Fields........................................................................................................ 25
Description of Workflow and Field Documentation:

User/Group Role: Person/Group Responsible for the Process/Phase
Entry Point: Phase start point
Exit Point: Phase end point
Why Required: Explains why step is important to process
Notifications: Who is notified and when are they notified
Validation: Is there validation against the field
Attachments: Does the field accept attachments
Menu/Source: Is there a menu on the field and the source of the menu data
Downstream: Where is this information used downstream?
Exit Point Validations: Validations before request can move to the next phase.
Summary of VMWare Phases

1.
2.
3.
4.
5.
6.
7.
Request Initiation
Server Design Complete
P&L Approval / CSI Approval (parallel)
CTI Acceptance
VM Provisioning
Server O/S Build
SA Validation
Request Initiation
A. Process Overview
The Requester (Business/SA) enters the request information into the Business information tab.
Once the information is captured in the Business information tab, the Submit button is clicked and
the request is submitted. This will generate a TCRS CAP ID. At this point, the other tabs in the
application will become active. Below is a description of the main tabs used in Request Initiation.
Business Information
This page captures the initial information needed to submit a request into TCRS. It captures
information such as, Project Name, Requester details, Business details, SA Details, Justification,
Executive Summary, and the Type of Request.
Justification Form
Decommission tab
The Requester (Business/SA) enters the servers that will be decommissioned as part of the new
installation. This information is usually provided by the business and is used to calculate savings
once these servers have been decommissioned.
Design Server tab:

Requester (Business/SA) enters the VMWare server details in the Design tab. This includes the
Data Center where the VMWare will be installed. It also captures the CPU Speed, Memory
Amount, Storage, and VMWare details.
System Details tab:

Requester (Business/SA) enters the VMWare system details. This includes the required info in
order for the request to be sent to Aperture and to create the System Build Sheet.
Application IDs
Application IDs must be added prior to Server Pre-design checkbox being checked to Yes or
otherwise the user will get an error to add the APP IDs. APP IDs are usually entered/ added by
the user that submitted the request. How to enter APP IDs:
1.
2.
3.
4.
5.
6.
Click add the Add/View APP IDs button the Pre-design tab
When window opens
Enter the APP ID or APP Name
Click on the binoculars image
Click Add APP ID button
Click on Close Form
Once the Server details, App IDs, and all required fields have been completed by the requestor,
they will submit the request to the next workflow phase by clicking on the Request Validations tab
and checking Submitter Finalized field to Yes.
Finance Tab
This screen display the allocation costs based on Product Rate Card.
Submi
tter Finalized
User/Group Role:
Requester (Business/SA)
Entry Point:
Request Create Date
Exit Point:
Submitter Finalized
1. When submitted notification is sent to the Requestor and
Business Manager of the request.
Notifications
2. When submitter finalized is check to Yes notification is
sent to the SA Group.
Why Required?
Captures Business related information and VMWare related specs

for VMWare provisioning and reporting
B. Exit Point Validations

1)
2)
3)
4)
5)
A Server has been entered into the VMWare Design tab.

Validates Justification form is complete
Validates APP ID has been entered
Sets Business Based of APP ID
Validates the Business fields are not null.
C. Required Fields
Business Information tab
Field Name
Project Name
Requestor SOEID
Requestor (Full Name)
Requestor Phone
Requestor Email
Type of Request
Sr. Business Mgr SOEID
Sr. Business Mgr
(Full Name)
Sr. Business Mgr Phone
Sr. Business Mgr Email
Requesting Business P&L
Business Sector
Business Group
Business Line
Business
CTI P&L Signing Authority
SA Manager (Full Name)
Validation, Integration, and/or Downstream Usage

Validation: None
Attachments: None
Menu/Source: Table Driven within TCRS
Downstream: Reporting
Source: Global Data Warehouse
Downstream: Passed to Aperture record
Workflow: Populates Requestor Name, Phone, Email
Downstream: Emails Notifications and Reporting
Downstream: Email Notifications
Workflow: Drives the workflow for the selected Type of Request.
Must equal VMWare to drive the Virtual workflow
Workflow: Populates Sr. Business Mgr Name, Phone, Email
Downstream: Emails Notifications and Reporting
Source: CSI (Based on level 1-4 business)
Validation: Must be selection form menu
Downstream: Drivers Business Approvers
Source: CSI
Source: CSI
Source: CSI
Downstream: Reporting; Drives Approver for SA Approval phase
Workflow: Sets SA Manager SOEID for Notifications Purposes.
SA Name
Source: Aperture (Must have valid Aperture Login and belong to an Aperture
Support Group.
Downstream: Reporting ; Drives approver for SA Approval phase; Value is
pushed to Aperture and mapped to Requestor field in Aperture, if no other
SA Name is selected during SA Approval.
Workflow: Sets SA Name SOEID for Notifications Purposes
Sets Support Group/SA Team Menu based on SA Name
Support Group/SA Team
Source: Aperture (Must be active Support Group with Active SAs assigned)
Workflows: Drives additional Approvers in the SA Approval
Downstream: Passed to Aperture Repository for Support Group

Request Category
(Commodity or NonCommodity)
PTS Name
Archer Deviation Tracking
ID
Impact of Late/Non
Delivery
TCRS PM Assigned to
Project
Sr. Manager of
Technology
Investment Category
Sector
Investment Category
Status
Current Approval Status

Reason for Pending
Platinum
App ID
Existing Application
Submitter
Date Entered
Last Modified By
Modified Date
Region
Future Use: may be used to drive further Commodity Request
Downstream: Reporting; ( Does not apply for VMWare: However for EMEA
Commodity servers Drives user that receives rename record in Aperture)
Source: CSI
Values:
Open
Pending
On Hold
Cancelled
Closed.
Workflow: Display the current status and pending approvals for a request
Workflow: Required is Status is set to Pending
Downstream: Reporting; Passed to Aperture Storage Add Requests to the
Urgent field.
Read-Only field. Displays APP IDs added in the Server Design.
Downstream Reporting: Automatically Captures APP IDs assigned in Server
Tab to a server.
N/A
Person that submits the request
Date request submitted in TCRS
Person that last modified the request
Last Date Request was modified.
Downstream: Drives Business and CTI Approvers, Drop Down Menus, and
Notifications Groups based on Region
10
Justification Questionnaire Form

The questions completed in the Justification Questionnaire are used by NPI team during Solution Design
for downstream PEP creation and financial approvals. Also used by Global Design Authority (GDA)
document generation.
Scope tab > All

Fields
Questions: Scope
Business & Financial

tab > All Fields
Questions:
What are the business requirements? ; Does this address a
regulatory, security, or risk issues? ; What are the financial
benefits? ; Is this critical? ; Will CTI Recover expenses
through the Standard Product Rate card.
Technology tab > All

Fields
Questions: Explain, if servers cannot be virtual; Please

provide capacity details in attachment field; Which other
alternative were analyzed?; are requirements consistent with
CATE standards?
Attachment fields: Captures Capacity Planning information
Validation: Validates CATE Publishing Standards Question is
answered.
Audit History fields and Dates for when questions were
completed and approved by NPI.
Audit tab > All Fields
Workflow: Tracks if the Justification form was returned back to

the requestor due to incomplete information.
Notification: Sends Notifications to Submitter and Requestor
to review and complete the missing information;
Workflow: Audits changes to fields in all tabs in Justification
Questionnaire.
Downstream: Reporting, enables NPI to tracks time lost due
to incomplete information.
11
Decommission
A server being decommissioned uses data from Aperture, CGICs, and Product Rate
card to determine the current Allocations Costs.
DC or Tech Room
Server Name
Site Address
Server Machine Type
Server Machine
Category
Total Servers
O/S Images
Memory
CPUs
CPU Speed
Server Vendor
Server Model
Server O/S
O/S Version
# of Gig-e Ports
# of 10 Gig-e Ports
Storage Tier
Storage Amount
Server Comments
Source: Aperture
Workflow: Drives Site Address Menu
Source: Aperture
Name of Server being decommissioned
Source: Aperture
Workflow Based on Region and Selection of DC or Tech Room
Field.
Source: Aperture
Downstream: Reporting; Passed to Aperture for VMWare P2V
records; Passed to Aperture Repository for Non-P2V records
Source: Aperture
Workflow: Captures number of server being requested; Since
only 1 VM Device can be ordered per post-design record, the
value for this field defaults to 1 for VMWare Servers.
Downstream: Reporting;
Workflow: Used to Calculate Costs
Validation: Must be selected from Menu
Source: Aperture
Downstream: Reporting; Passed to Aperture
records
Source: Aperture
records
Source: Aperture
records
Source: Aperture
records
for VMWare P2V

for VMWare P2V
for VMWare P2V
for VMWare P2V
12
Expected
Decommission Date
Actual
Decommission Date
Original Install Date
Decommission
Equipment
Redeployable
Net Book Value
Serial Number
Date the server is supposed to be decommissioning for

business to realize the cost savings.
Date the server is actually decommission from Aperture;
Downstream: Reporting for Fincon Report for Scott Weiss
Optional: Date Server was originally installed in DC/Tech
room.
Downstream: Reporting for Fincon Report for Scott Weiss
Net Book Value is determined by NPI
Source: Aperture
Server Design
The requested VMWare Server design specs are entered in this tab.
Aperture Install Type
Downstream: Drives Aperture Install record type; For VMWare

its set by default
DC or Tech Room
Used to determine of Location is a Data Center or Tech room

Source: Aperture
Workflow: Drives Site Address Menu
Source: Aperture
Workflow Based on Region and Selection of DC or Tech Room
Field.
Source: Aperture
Source: Aperture
Workflow: Captures number of server being requested; Since
only 1 VM Device can be ordered per post-design record, the
value for this field defaults to 1 for VMWare Servers.
Source: Aperture
Validation: Must be selection from Menu Lookup.
records;
Passed to Aperture Repository for Non-P2V records
Workflow: Populates hidden cluster related fields used to
pass information to Aperture for P2V requests
records;
Passed to Aperture Repository for Non-P2V records
Workflow: Determines if record is sent to Aperture Repository
or sent as an Aperture Install record
13
Site Address
Server Machine Type
Server Machine
Category
Total Servers
VM Cluster Name
Server Name (VM)

VMWare Request
Type
# of Apps
O/S Images
Memory
CPUs
CPU Speed
Server Vendor
Server Model
Server O/S
O/S Version
SA Group Folder
Owning Group
Drive 1
Drive 1 Amount GB
Drive 2
Drive 2 Amount GB
SA Name
APP ID Fields
Application ID
Application Name
Chargeback Profile
Validation: Must be selected from Menu.

Workflow: Field is populated when an APP ID is added to the
VMWare Device
Validation: Used to determine APP IDs have been added to
the device during the Submitter Finalized completion phase.
Source: Aperture
records
Source: Aperture
records
Source: Aperture
records
Source: Aperture
records
Source: Aperture
Downstream: Passed to Aperture as the requestor of the
request for P2V records.
Workflow: Sets SA SOEID for SA Notifications
Source: CSI:
Application status must be Production OR Development
Application must have a minimum of one (1) chargeback
profile defined
Downstream: Sent to CSI for approval
Workflow: Populates App ID field on Business information tab
for reporting purposes
CSI App ID name
Source: CSI
Downstream: Sent to CSI for Approval
Chargeback Profile for APP ID in CSI. If more than one profile
is displayed user must select the correct profile from pick list
14
Percentage of Server
menu.
Source: CSI
Percentage of APP on Server. (for servers with multiple App
IDs)
Source: CSI
Finance tab
The finance tab shows costs based on the Product Rate Card.
Current Allocation
Costs
Pre-Design Cost
Post-Design Cost
Cost Voidance
Workflow: Calculates Cost of Servers being decommission

Source: Product Rate Card / CGICs
Workflow: Calculates Cost of Servers being ordered in Predesign (Not used for VM)
Source: Product Rate Card / CGICs
Workflow: Calculates Cost of Servers being ordered in Postdesign/Server Design
Source: Product Rate Card
Calculated Field:
Current + Pre-design Costs minus Post-design Costs.
VMWare Design Complete

A. Process Overview
After the Submitter Finalized is checked to yes, the request is sent to the designated Business
Design Approver to review. The Design Approver role is to review the request for completeness
and ensure it matches with the business goals. After reviewing the Business Design Approver
checks the Design Complete Checkbox to Yes to approve the request. This will move the
VMWare request to P&L Approval, and will also in parallel send the records in the request to CSI
for app ID approval.
User/Group Role
Initial Business Design Approver
Entry Point
Submitter Finalized
Exit Point

When Server Design is complete the Business Initial P&L Approver
is notified.
Notifications
When P&L is approved and CSI Approval is complete, a notification
is sent to VICA Build team
Why Required?
Provides designated Business approver an opportunity to review the

request and confirm that what is being requested is correct.
15
B. Required Fields
Validations: App ID is included for each server in the request.

Date
Captures Date when Server Design Complete field is checked to

Yes
C. Exit Point Validations

1) Validates that an APP ID has been added to VM servers
2) Validates Approver is part of the Business Approval Matrix.
Business P&L Approval and CSI Approval (Parallel)

I)
CSI App ID Approval
A1. Process Overview

Depending if the business is ICG or Non-ICG, the requests take a different path in the workflow.
The APP IDs for ICG requests are approved the P&L Approver in TCRS. Non-ICG requests are
sent to CSI for APP ID Approval by the App Manager.
User/Group Role
If ICG Business then the P&L Approver in TCRS / If Non-ICG

Business then App Manager in CSI
Entry Point
Server Design Completed
Exit Point
CSI App ID Approval

If the Business is ICG, the notification for APP ID approval is sent to
the Business Initial P&L Approver by TCRS.
Notifications
If the Business is Non-ICG, the notification for App ID approval is

sent to the App Manager by CSI.
is sent to VICA Build team.
Why Required?
Financial Transparency and Business Chargebacks
B1. Required Fields

The following fields are hidden and only used for TCRS workflow; however they are important
because they trigger workflow for approving CSI App IDs.
16
ARS Server ID
Workflow: Field Captures the ARS Server ID that is

used by CSI and Aperture to identify a server
device generated by TCRS.
Downstream: Passed to CSI and Aperture to
identify server.
REQ Status (Request

Status)
Workflow: Captures CSI Approval Status and

updates TCRS records with the Approval or
Rejection status from CSI.
Downstream: Passes approved App ID to Aperture
Repository or Aperture install record
Validations: Validates CSI App ID is approved before
updating the TCRS server records. If an APP ID is
rejected, it uses CSI Approver and the Resubmitted
Count to determine if the App ID should be
automatically sent back to CSI
CSI Approver
Workflow: Captures the CSI Approvers SOEID

Validation: Determines if the APP ID was rejected
by the CSI system, if so it sends the request back
to CSI as long as the Resubmitted Count is under 4.
Resubmitted Count
Workflow: If APP ID is rejected due to timeout, this

field will trigger the records to be sent back to CSI
as long as the value in this field is under 4.
C1. Exit Point Validations

1. Validates all CSI App ID are approved before moving request to the next
phase.
II) Business P&L Approval
A2. Process Overview

During the Business P&L Approval phase, the business has an opportunity to review the cost of
the request and ensure the request is business aligned and included in book of work. If the
request is ICG business, then the P&L Approver is also responsible for approving the APP IDs on
the request.
User/Group Role
P&L Approver
Entry Point
Server Design Completed
Exit Point
P&L Approved
Notifications
When Server Design is set to Yes the Business P&L Approver is

notified.
17
When P&L is approved and CSI Approval is complete, a

notification is sent to VICA Build team
Business is required to review all orders to determine if there is
budget to complete the order.
Why Required?
B2. Required Fields

P&L Approver
SOEID
Workflow: Captures SOEID of Business Approver and

Validation: Validates it against the Business Approver
Information to ensure user has access to Approve
request.
Source: Table Driven within TCRS
P&L Approval
Yes or No field
Workflow: Captures approval to move the request
forward to proceed to CTI Validations phase.
Downstream: Triggers Notification to the VMWare CTI
Validation team, Requestor, Submitter, and Sr.
Business Manager.
Approve APP IDs
Workflow: Is Visible for ICG requests where APP IDs

are pre-approved, instead of being sent to CSI to be
approved by APP Manager.
Downstream: Sends Pre-approved APP IDs to CSI
which speeds time to market, since request does not
have to wait for App Manager to Approve in CSI.
Budgeted?
Validations: Must be Yes or No value prior to P&L

Approval being set to Yes
Budgeted/Forecast
ID
Forecast ID is used to validate the request is on the

approved business book of work.
Validations: If the value of Budgeted? = Yes, then a
value is required in this field.
C2. Exit Point Validations

1) Validates Approver is part of the Business P&L Approval Matrix.
2) Validates all CSI App IDs have been approved before moving the request to CTI Acceptance
phase.
18
CTI Acceptance
A. Process Overview
CTI Approval tab:
The CTI Approvals tab has a drop down menu to select VMWare from the Approval Type.
Selecting a VMWare causes the Assignee menu appear. The Assignee menu is used to capture
the Approver/Reviewers name. Once the Approval type is set to VMWare and the Reviewer is
select from the VMWare Reviewer field. The Approve button is clicked to approve the request.
User/Group Role:
VICA Build Team - VICA/VMWare Build, this is the team
Entry Point:
CSI Approval and P&L Approval Complete
Exit Point:
CTI Approval Complete
from CTI that manages the VM Build.

is sent to VICA Build team
Notifications
When the CTI Approval is complete, a notification is sent to the VM
Provisioning team.
Why Required?
Provides designated CTI work stream an opportunity to review the

request and confirm all the information required to complete the
request is complete.
19
B. Required Fields
CTI Validations
Approval Type (Menu)
Validation: Validate s approver belongs to the correct CTI

Approval Group.
Menu/Source: Selection must be from menu which is
based on a table matrix.
Approver/Assignee/Revi
ewer Menu
Validation: Validates the selected user has permission to

approve the request.
Menu/Source: Selection must be from menu which is
based on a table matrix.
Downstream: Email Notifications to Approvers.
All Approved
Validation: Validates all Approvals in CTI Phase have been

completed.
Workflow: Automatically populated when all approvals are
complete:
Downstream: Triggers Email Notifications to all Approval
Groups, Requestor, Submitter, Sr. Business Mgr that CTI
Validations is complete.
CTI Acceptance Date
Shows Date the request was approved by the VMWare

Reviewer.

1. Validates Approver is part of the CTI Approvers group (in this case the VMWare VICA team)
After the VMWare VICA approves the CTI Acceptance, the request is considered
closed and the provisioning phase begin.
P2V Records
After CTI Acceptance is complete, VMWare records designated as VMWare Request
Type P2V are sent to Aperture via Web services as Install Aperture records in New
Status.
VMWare Provisioning
The VMWare Provisioning process takes place in TCRS for requests which have VMWare Request Type
for Build & Swing and Net New devices. For P2V type of devices, the provisioning process occurs in
Aperture via the install workflow.
A. Process Overview
Once CTI approval finish the request get closed in TCRS Initiation phase and move for VMWare
Provisioning approval, the approver need to review/update VM Device Name, Cluster Name and
IP Address for each device requested and provide approval.
20
VM Provisioning Update screen also provide option to Validation IP address which will validate if
provided IP address is not assigned to any other VM device in aperture.
(VICA Build Approver get selected based on Region & Sector)

User/Group Role:
VICA Build Team
Entry Point:
CTI Approval
Exit Point:
VM Provisioning Complete
1.
Notifications
After CTI approval notification goes out to region and

business sector specific VICA Build approvers for VM
Provisioning approval
2. Once approved notification goes to OS Engineer for OS

Build
Why Required
This part of VM installation process VICA build team need to

record this process for tracking and proper management of the
VM Provisioning phase.
Fields on VM Provisioning tab
B. Required Fields
Update Cluster / IP Address
(Button)
Opens pop window to the screen to update/review VM Device name,

Cluster Name, IP Address
VICA Build Over SLA Reason
Approver can select one of the list value to provide Over SLA Reason
Checking this checkbox will complete VM Provisioning approval
VICA SOEID
Records the Approvers SOE ID
VICA Provisioning Date
Records the VM Provisioning Complete date
3 Informational fields
3 informational fields will provide at-a-glance information to VM

approvers like, Number of VM device request in the request and how
many of those are missing Cluster / IP address information
21
Fields on Cluster/IP Address screen
Table Field
List show all the VM Devices requested on the selected TCRS request
Read only
columns
Server Model/ Server Machine Type/ Server Machine Category/DC Location/Site

Address are read only display fields showing the entered information for selected
device
Server Name
Field to enter VM Device name

Workflow: Passed to Aperture Repository for P2V and Non-P2V records
Cluster name
Source: Aperture
Drop down will show list of clusters approver will select cluster where VM device is
getting installed.
Workflow: Passed to Aperture Repository for P2V and Non-P2V records
IP Address
IP address of the VM device

Workflow: Passed to Aperture Repository for Non-P2V records
Validate IP
(Button)
Workflow: Uses Web Service to validate IP is available in Aperture.

It will if check the provided IP address is already been used by another device in
Aperture
C. Exit Point Validations:

1) Validates all the VM device on the request have Device Name/Cluster Name/IP Address are
entered.
2) Validates approver is defined as VMWare VICA Build approver
22
O/S Build Approval

A. Process Overview
After VM Provisioning complete request goes to OS Build phase, once OS build is complete OS Build
Engineer need to provide OS Build complete marked on TCRS request.
User/Group Role:
VMWare OS Build Engineer
Entry Point:
Exit Point:
O/s Build Complete

1.
Notifications
After VM Provisioning Complete notification goes out to region

specific VMWare OS Build Engineers for OS Build process
2. Once approved notification goes to SA and SA Manager

Why Required
This part of VM installation process OS Build team records the process

in TCRS for tracking and proper management of the VM Provisioning
phase.
B. Required Fields
O/S Build Complete
Checkbox to make the OS Build Complete
O/s Build Engineer
To select the Engineer who performed OS Build on all the VM devices.

Source: Table Matrix in TCRS
O/S Build Complete Date
Date when O/S build completed
O/S Build Completed By
Record the User who marked OS Build Complete on the selected

request

1) Validates if the OS Build Engineer name has been entered.
2) Validates the approver is defined as VMWare OS Build Engineer in TCRS.
23
SA Validation
A. Process Overview
After OS Build process is completed the request moves to Final Validation. In this phase the SA will
review and update additional information required prior to pushing the VMwares directly to the Aperture
Repository via web service.
Fields to provide additional information
User/Group Role:
SA / SA Manager
Entry Point:
OS Build Complete
Exit Point:
SA Validation Complete
Notifications
1. Notification goes out to SA / SA manager to review and

update additional information on VM Device
Why Required
This is the final review and validation step before VM Device is

marked for installed in Aperture Repository.
B. Required Fields
Table Field
Will display all the VM device requested in selected TCRS request
24
Informational Fields
Display Only field:

Server Name, Support Group Type, Server Machine Type, Server Machine
Category, Cluster Name, IP Address fields provided on the screen are read only
and only for informational purpose
Support Group
Field will provide the list of Support Groups, SA need to provide the select VM
device Support Group name
Source: Aperture
Downstream: Passed to Aperture Repository for Non-P2V records
Primary Contact
List will provide list of SA on the selected support group, SA will provide the primary
SA name who support the selected device
Source: Aperture
Business Area
SA need to select the name of the business using the selected VM Device
Source: Aperture
Device Monitoring
Type of device monitoring required for selected device

Source: Aperture
Device Monitoring
Tier
Name of the Device Monitoring Tier

Source: Aperture
Backup Type
Type of the Backup required for selected device

Source: Aperture
Validate IP (Button)
Workflow: Uses Web Service to validate IP is available in Aperture.

It will if check the provided IP address is already been used by another device in
Aperture.
25
Fields for SA Validation Complete Process
Update Additional
Information (Button)
Clicking this button will open additional information screen for SA / Sa Manager to
review and update additional information
SA Validation
Complete
Checkbox to mark completion of SA Validation process
SA Validation
Complete Date
Record the date when SA Validation is completed
SA Validation
Completed By
Record the person who completed the SA Validation
Validation: Validates all the required information in the SA Validation screen has
been completed is completed.
Downstream: Triggers VM Records to be sent to the Aperture Repository;
Reporting

1) Validates whether all the required information is filled on all the VM Devices requested in the request.
2) Validates the approver is SA / SA Manager selected on the request
WSDL Used to send VMs to Aperture Repository (Not for Physical Servers)
PROD
http://apswdcpweb01.nam.nsroot.net/dcimweb/ApertureServiceservi
ceagent.asmx?wsdl
UAT
http://assetprovisioning.uat.citigroup.net/dcimweb/ApertureService
serviceagent.asmx?wsdl
26
External Systems Used for VMWare

Application
Application Description
CSI
CSI is a repository of internallydeveloped and customized vendor

applications. It provides a process for
application managers to manage and
approve the servers on which their
applications are installed and how the
servers are linked and charged back to
the client.
Aperture
Aperture is a Data Center management

tool for installing physical servers and
virtuals into the Citigroup Data Centers
and Tech Rooms.
CGICS (for NAM Only)
CGICS tracks the monthly

chargebacks for all Citigroup
servers
Aperture Reporting
Servers (Veronica
Amaya)
Provide reporting capabilities for

Aperture data and TCRS in the
near future
eWorkflow
Global Data warehouse

(Employee) feed from HR
Review and Approval system for
the Project Expenditure Proposal
(PEP) and is used to approve
purchases over $100k
Crystal Report server

(CTI reporting)
Provide reporting capabilities for

TCRS data
CTI Product Rate Card

file
The file contains the monthly

FINCON chargeback values for all
physical servers, virtuals, SAND,
and peripherals.
GDW
Integration Description
TCRS connects with CSI for

approval of application ID's
associated to a server
TCRS generates Aperture Install
records or writes directly to
repository for VMWare server
devices.
An MS Access DB containing the
monthly NAM server
chargebacks is loaded into TCRS.
This information is used to
determine the cost savings of
servers being decommissioned
vs. new servers.
These reporting servers will
produce reports the aggregate
TCRS and Aperture data to
generate E2E reporting
Uploaded quarterly into TCRS.
This information is used to
populate contact user
information in TCRS requests.
File is loaded into TCRS weekly
that populate PEP Create and
Approval dates
Used to generate daily and
weekly reports for example,
Over SLA, E2E, and Forecasting
reports.
Manually uploaded at the
beginning of every year based
on the data file provided by
Fincon. Used to estimate the
monthly charge for new server
orders
27

Vmware Process

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Vmware Process

Încărcat de

Drepturi de autor:

Formate disponibile

Contents

TCRS / VMWare Process............................................................................................................ 1

Exit Point Validations............................................................................................... 16

Business P&L Approval and CSI Approval (Parallel)...............................................................16

C. Exit Point Validations.................................................................................................. 20

C. Exit Point Validations:................................................................................................. 22

C. Exit Point Validations:................................................................................................. 23

C. Exit Point Validations:................................................................................................. 26

Description of Workflow and Field Documentation:

Summary of VMWare Phases

Design Server tab:

System Details tab:

Request Create Date

Captures Business related information and VMWare related specs

B. Exit Point Validations

A Server has been entered into the VMWare Design tab.

Validation, Integration, and/or Downstream Usage

Support Group/SA Team

Downstream: Passed to Aperture Repository for Support Group

Current Approval Status

Justification Questionnaire Form

Scope tab > All

Business & Financial

Technology tab > All

Questions: Explain, if servers cannot be virtual; Please

Audit tab > All Fields

Workflow: Tracks if the Justification form was returned back to

Server Machine Type

for VMWare P2V

Date the server is supposed to be decommissioning for

Downstream: Drives Aperture Install record type; For VMWare

Used to determine of Location is a Data Center or Tech room

Server Machine Type

Server Name (VM)

Validation: Must be selected from Menu.

Workflow: Calculates Cost of Servers being decommission

VMWare Design Complete

Initial Business Design Approver

Server Design Complete

Provides designated Business approver an opportunity to review the

Validations: App ID is included for each server in the request.

Server Design Complete

Captures Date when Server Design Complete field is checked to

C. Exit Point Validations

Business P&L Approval and CSI Approval (Parallel)

CSI App ID Approval

A1. Process Overview

If ICG Business then the P&L Approver in TCRS / If Non-ICG

Server Design Completed

CSI App ID Approval

If the Business is Non-ICG, the notification for App ID approval is

Financial Transparency and Business Chargebacks

B1. Required Fields

Workflow: Field Captures the ARS Server ID that is

REQ Status (Request

Workflow: Captures CSI Approval Status and

Workflow: Captures the CSI Approvers SOEID

Workflow: If APP ID is rejected due to timeout, this

C1. Exit Point Validations

II) Business P&L Approval

A2. Process Overview

Server Design Completed

When Server Design is set to Yes the Business P&L Approver is

When P&L is approved and CSI Approval is complete, a