2019

Playbook Guide to Accessing

Biosimilar Virtual Machines and
Images
VERSION 1.0
COSTEA, OCTAVIA

Pfizer | Confidential
 Page 1 of 20

Contents
1 OVERVIEW ........................................................................................................................ 3

1.1 Playbook Purpose ......................................................................................................................... 3

1.2 How to Use This Document .......................................................................................................... 3
1.3 Playbook Structure........................................................................................................................ 4
1.4 Background ................................................................................................................................... 4
2 SCOPE ............................................................................................................................... 4

2.1 Physical Workstation in Scope ...................................................................................................... 5

2.2 Backed Up Images in Scope .......................................................................................................... 5
2.3 Archive VM in Scope ..................................................................................................................... 5
2.4 Analysis Workstations in Scope .................................................................................................... 6
3 PREREQUISITES FOR INITIATING A REQUEST ............................................................. 7

4 DATA RETRIEVAL REQUEST ........................................................................................... 7

4.1 How to Submit, Track and Close Out a Request for a Backed Up Image ...................................... 7
4.2 How to Submit, Track and Close Out a Request for a VM ............................................................ 8
5 CASE STUDIES ................................................................................................................10

5.1 Case Study 1 ................................................................................................................................ 10

5.2 Case Study 2 ................................................................................................................................ 11
6 PLAYBOOKS ....................................................................................................................11

6.1 XXX .............................................................................................................................................. 11

6.2 YYY............................................................................................................................................... 12
6.3 ZZZ ............................................................................................................................................... 12
6.4 AAA.............................................................................................................................................. 12
6.5 BBB .............................................................................................................................................. 13
6.6 BBB .............................................................................................................................................. 14
6.7 CCC .............................................................................................................................................. 14
6.8 … .................................................................................................................................................. 14
6.9 … .................................................................................................................................................. 14
6.10 … .................................................................................................................................................. 14
6.11 … .................................................................................................................................................. 14
6.12 … .................................................................................................................................................. 14
 Page 2 of 20

6.13 … .................................................................................................................................................. 14
6.14 … .................................................................................................................................................. 14
6.15 … .................................................................................................................................................. 14
6.16 … .................................................................................................................................................. 14
6.17 … .................................................................................................................................................. 14
6.18 … .................................................................................................................................................. 14
6.19 … .................................................................................................................................................. 14
6.20 … .................................................................................................................................................. 14
6.21 … .................................................................................................................................................. 14
6.22 … .................................................................................................................................................. 14
6.23 … .................................................................................................................................................. 14
6.24 … .................................................................................................................................................. 14
6.25 … .................................................................................................................................................. 14
6.26 … .................................................................................................................................................. 14
6.27 … .................................................................................................................................................. 14
6.28 … .................................................................................................................................................. 14
6.29 … .................................................................................................................................................. 14
6.30 Analysis Workstations* ............................................................................................................... 14
7 KEY POINTS OF CONTACT .............................................................................................17

8 VERSION HISTORY ..........................................................................................................17

9 APPENDIX ........................................................................................................................17

9.1 Table 37: Terminology Description ............................................................................................. 17

9.2 Table 38: Equipment/Model Mapped to Type: VM, Backed Up Image or Physical Workstation
17
9.3 Table 39: Equipment and Data Location – Local or on a Network Share ................................... 19
 Page 3 of 20

1 OVERVIEW
1.1 Playbook Purpose
A playbook is a document intended to provide:

1. General information for the Virtual Machines (VM), images or physical workstations in scope 
Section 2
2. Step by step process on how to access and obtain meaningful data archived (as an image) or
stored (with a VM or physical workstation located at a different site)  Section 3 and Section 4
3. Guidance for data analysis via various analysis applications Section 6.31.

Such information is needed in case of audits or inspections. This document encompasses a collection of
playbooks (see Section 6 for detailed playbooks) for the VM in scope (see Section 2 for scope). In
addition, this document maps data analysis applications to the VM that need to be recalled in order to
accelerate and simplify the process (see Section 9 for a comprehensive list of workstations).

The audience of this document consists of individuals authorized to be part of audits or inspections and
assigned to provide the requested data.

1.2 How to Use This Document

If a first-time user of this document, it is important to review Section 1 through Section 5, before
searching for specific information. The user can search in this document steps on 3 key types of
activities:

1. Data retrieval from a VM

2. Accessing an Analysis Workstation
3. Accessing a Backed Up Image

If already familiar with the structure of this document and searching for data retrieval from a VM,
follow these steps:

 Go to the Table of Contents and select the equipment number targeted

 Navigate to that section
 Find the following information that will be needed to fill out a data retrieval request
 Equipment/model ID
 Data location (local or on a shared network)
 VM to Recall
 If one needs help initiating the data retrieval or access request (if the data is on the share drive),
there are links throughout the document that will take one through each process

If searching information for the Analysis Workstations and how to access data, navigate to Section 6.31
for detailed steps.

If searching to access a Backed-Up Image, follow these steps:

1. Go to Section 4.1
2. Read and follow the detailed steps on how to start, manage and close out the process to obtain
the information needed
 Page 4 of 20

Section 2 and the Appendix are particularly useful because they have consolidated tables with the
workstations found in this document, data location and additional information.

1.3 Playbook Structure

This document is structured in 6 key sections:

 Section 2 – Scope  highlights the workstations that can be found in this document
 Section 3 – Prerequisites for Initiating a Request  outlines the prerequisites for starting a
request (E.g., data access)
 Section 4 – Data Retrieval Request  describes the process on how to manage a request
 Section 5 – Case Studies  showcases real examples
 Section 6 – Playbooks  details the steps on how to manage the end-to-end process of
requesting information for each VM and backed up images
 Section 7 – Points of Contact  provides information for key points of contact

1.4 Background
In general, over time, some workstations are kept in their physical form while others are being
decommissioned. In the latter, the data needs to be accessible in case of an audit or inspection. There
are 2 ways to achieve that:

1. Create a VM to replace the physical workstation

2. Create and archive an image of the physical workstation

When a VM is created, the data can be:

 Local to the VM
 External to the VM
 Local and external to the VM

There are scenarios when an analysis workstation is needed, in addition to the VM, to allow the data to
be analyzed. Those scenarios are described in more detail in Section 6.31.

2 SCOPE
This section provides quick access to the physical workstations, backed up images and VM information
that can be found in this document. A comprehensive lookup table with all consolidated workstations
can be found in Section 9.2.

XXX and YYY do not require VMWare. XXX is a cell counter and the rationale is that the printouts and the
counts are all that would ever be required. For further information, please contact XYZ

XXX  The app – ABC - used by XXX is out of scope because there was no data associated with the
system. This was the only system using the app – ABC – for data acquisition. Since there was no
apparent data acquired, there was no need for the system to be virtualized.

Abc Analysis Workstations  Data was not found associated with these systems and the apps installed
were out of scope, hence these workstations weren’t virtualized.
 Page 5 of 20

Analysis Workstation System Scope

xxxx xx Out of scope

yyy yy Out of scope

zzz zz Out of scope

2.1 Physical Workstation in Scope

There are physical assets in the … location, identified as:

1. …, with Asset Tag ... More details can be found below:

 Location:
 Points of contact:

2.2 Backed Up Images in Scope

Table 1 includes a comprehensive list of workstations (equipment) and models that had an image
created and archived to enable later data access.

Table 1: In Scope Workstations (Equipment) with Backed Up Images

Equipment ID Model

xxx xx

aaa aa

2.3 Archive VM in Scope

The table below lists the workstations (equipment) and models that had VM created and are in scope
for this document.

Table 2: In Scope Equipment with VM

Equipment ID Model
ccc
cc

zz zz
 Page 6 of 20

2.4 Analysis Workstations in Scope

The following analysis workstations are in scope for this document.
 Page 7 of 20

Table 3: Analysis Workstations in Scope

Analysis Workstation System

For details on Analysis Workstations, please go to Section 6.31.

3 PREREQUISITES FOR INITIATING A REQUEST

In general, the requestor needs to have the following information prior to initiating a request:

 Equipment number (E.g., ccc)

 Data location
 Software used for analysis

This information can be found in eLN.

If the data is not on the local drive, the requestor will need to obtain access to that data and follow
these steps:

1. Visit the Security Group site …

2. Search for the security group […]
3. Select [Request Access]
4. Type [Last Name] or User ID, and select the name from the list
5. Click [Save]
6. Select [View Cart], then click [Submit Request]
7. Once approved, access will be granted

The process of requesting access to the data can be started in parallel with the process of initiating a
request, which is outlined in the next section.

For details pertaining to each equipment with a VM and corresponding data locations, see details in
Section 6 (VM Playbook).

4 DATA RETRIEVAL REQUEST

This section contains information on 3 phases for each scenario for Backed Up Images (Section 4.1) and
VM (Section 4.2).

1. How to submit a request to retrieve data

2. How to track the request
3. How to close out the request

4.1 How to Submit, Track and Close Out a Request for a Backed Up Image
When the auditing team specifies the type of information needed, the assigned individual (requestor)
will start the process of obtaining the data in a consumable format and make it available to the auditing
team. To do so, the requestor will need to know:

1. System’s name
 Page 8 of 20

2. Application used to retrieve the data

3. Type of data: structured or unstructured

All backed up images are located here. For further information on how to access the materials needed
once the images were restored, please contact …

4.2 How to Submit, Track and Close Out a Request for a VM

There are 3 types of VM requests that impact the retrieval process:
1. Requests where the data is local to the VM
2. Requests where the data is external to the VM
3. Requests where the data is local and external to the VM
When the auditing team specifies the type of information needed, the assigned individual (requestor)
will start the process of obtaining the data in a consumable format and make it available. To do so, the
requestor will need to know the system and application used to retrieve the data. For example, … (the
application is … and the device is …) is the unique identifier key item one would need in order to locate
the VM and retrieve the data. See Section 6 for detailed playbooks. Here are the next steps:

1. Access …
2. Select [Retrieve Records] link (Figure 1)

Figure 1: eRIM Landing Page

….

A new interface (Figure 2) with multiple fields opens. These fields need to be filled out as outlined
below:
1. [Reason for Request]  Audit/Inspection
2. [Date Information Needed]  Date
3. [Request Description]  Equipment, system, application name and details of the data retrieval
request
4. [Record Format Type]  Structured, unless it is a raw file requested in a network share, which
would then be unstructured
5. [Original Source System]  Usually blank, and while not required, the requestor can enter the
system name
6. [Archive Repository]  VADAR
7. [Restore Archive Content to Active State]  Usually left unchecked, but there are rare scenarios
where the archive system will be taken out of archive and back into an active state where the
business will once again take custodianship and the system will actively be used by the business

Figure 2: Retrieve Records Landing Page

 Page 9 of 20

1.

2.

3.

4.

5.

6.

7.

For any issues, the requestor can contact the Help Desk.
 Page 10 of 20

Once the request is submitted, it goes through a back-end process, not visible to the requestor.
1. The Help Desk receives it and assigns it to the VADAR queue.
2. The … request managers will evaluate the validity of the request and if valid, they will assign
it to the Archival Group.
3. The Archival Group will start the process of fulfilling the request. They will reach out to the
requestor via email/call with an acknowledgement of request. Figure 3 depicts the detailed
process, starting with the submission of the request and ending with the close out.

Figure 3: Request Submission and Management Process

….

The Archival Group will work with the requestor and provide the information needed in a
consumable format (E.g., PDF). The Archival Group will then communicate to the Help Desk when
they finalized the request. The Help Desk will reach out to the requestor to confirm that the
information needed was provided and the ticket can be closed.

When the data is local to the VM, the process is straight forward. When the data is external to the
VM, the Archival Group will send out an email to the requestor with information on how the external
data can be uploaded to a shared drive.

Standard working hours for the Archival Group are Monday through Friday, 8am ET to 4:30pm ET.
For exceptional and urgent situations, the escalation process is outlined below:
1. Requestor submits request in … (follow the steps outlined above), with the additional
specification in the [Request Description] field  “Please assign to …”.
In case … is OOO, add: “Please assign to … ” (and vice versa).
2. Once the … data retrieval request is submitted, requestor sends a follow up email to … -
notifying of the request and urgency.
3. The requestor will receive a response via email or call (as applicable) within 2 to 4 hrs.

5 CASE STUDIES
5.1 Case Study 1
This is an example of request where a VM was created and the data was:

 Generated by one workstation

 Analyzed with two applications
 Located in a network share

FDA is visiting the site for a pre-approval inspection regarding the … The auditing team has a question
about source data from the technical report, …. This report references eLN notebook pages …

After logging into the eLN system, it is determined that the data in question was:

 Generated on the …
 Analyzed using both … & … applications
 Page 11 of 20

At this point, there is enough information to look up data retrieval instructions from the VM playbook,
Section 6.22.

5.2 Case Study 2

This is an example of request where a VM was created and the data was:

 Generated by one workstation

 Local to the hard drive

The auditing team has a question about the source data from …. This references eLN notebook page …

After logging into the eLN system, it is determined that the data in question was generated on …

There is enough information to look up data retrieval instructions from the VM playbook, Section 6.27.

6 PLAYBOOKS
6.1 XXX
For XXX, the requestor can encounter 3 types of scenarios:

1. When the raw data or audit trail information is needed  In this case, the VM to retrieve is …
2. When the analyzed data is needed  In this case, the VM to recall can be found by reviewing
information in Section 6.31.
3. When both - the raw and analyzed data - are needed  In this case, both VMs, as outlined
above, need to be recalled.
In order to retrieve meaningful information, the requestor will need to know:

1. Data location - Data is not local and the network share data location is …
Since the data is not local, the requestor will need to obtain access to data from the Security
Group site and by following the detailed steps outlined in Section 3. This step can be started in
parallel with the eRIM request.
2. VM to retrieve - The VM to retrieve for … is …
3. eLN details - The requestor will access eLN referencing the eLN pages found in the technical
report number provided by the auditing team.

Next, the requestor will initiate the request in eRIM and follow the request management process as
outlined in Section 4.2. The final data is processed in Empower and the requestor needs to have an
Empower account.

Table 4: Summary of Key Information

Equipment Model VM to Recall Application Data GDMS DRP ID

ID on VM Location
NOT
LOCAL
 Page 12 of 20

6.2 YYY
In order to retrieve meaningful information, the requestor will need to know:

1. Data location - Data is local to the hard drive for the ... Requestor doesn’t need to get access to
the data because it is local to the VM.
2. VM to retrieve - The VM to retrieve for … is ...
3. eLN details - The requestor will access eLN referencing the eLN pages found in the technical
report number provided by the auditing team.

Next, the requestor will initiate the request in eRIM and follow the request management process as
outlined in Section 4.2.

Table 5: Summary of Key Information

Equipment Model VM to Recall Application Data GDMS DRP ID

ID on VM Location

6.3 ZZZ
For…, the requestor can encounter 3 types of scenarios:

1. Data location - Data is local to the hard drive. Requestor doesn’t need to get access to the data
because it is local to the VM.
2. VM to retrieve - The VM to retrieve for …
3. eLN details - The requestor will access eLN referencing the eLN pages found in the technical
report number provided by the auditing team.

Next, the requestor will initiate the request in eRIM and follow the request management process as
outlined in Section 4.2.

Table 6: Summary of Key Information

Equipment Model VM to Recall Application Data GDMS DRP ID

ID on VM Location

6.4 AAA
In order to retrieve meaningful information, the requestor will need to know:

1. Data location - Data is local to the hard drive for … Requestor doesn’t need to get access to the
data because it is local to the VM.
2. VM to retrieve - The VM to retrieve for …
3. eLN details - The requestor will access eLN referencing the eLN pages found in the technical
report number provided by the auditing team.
 Page 13 of 20

Next, the requestor will initiate the request in eRIM and follow the request management process as
outlined in Section 4.2.The final data is processed in Empower and the requestor needs to have an
Empower account.

Table 7: Summary of Key Information

Equipment Model VM to Recall Application on VM Data Location GDMS DRP ID

ID

6.5 BBB
For …, the requestor can encounter 3 types of scenarios:

1. When the raw data or audit trail information is needed  In this case, the VM to retrieve is …
2. When the analyzed data is needed  In this case, the VM to recall can be found by reviewing
information in Section 6.31.
3. When both - the raw and analyzed data - are needed  In this case, both VMs, as outlined
above, need to be recalled.

In order to retrieve meaningful information, the requestor will need to know:

1. Data location - Data is not local and the network share data location is …
Since the data is not local, the requestor will need to obtain access to data from the Security
Group site and by following the detailed steps outlined in Section 3. This step can be started in
parallel with the eRIM request.
2. VM to retrieve - The VM to retrieve for …
3. eLN details - The requestor will access eLN referencing the eLN pages found in the technical
report number provided by the auditing team.

Next, the requestor will initiate the request in eRIM and follow the request management process as
outlined in Section 4.2. The final data is processed in Empower and the requestor needs to have an
Empower account.

Table 8: Summary of Key Information

Equipment Model VM to Recall Application on VM Data Location GDMS DRP ID

ID
 Page 14 of 20

6.6 BBB
6.7 CCC
6.8 …
6.9 …
6.10 …
6.11 …
6.12 …
6.13 …
6.14 …
6.15 …
6.16 …
6.17 …
6.18 …
6.19 …
6.20 …
6.21 …
6.22 …
6.23 …
6.24 …
6.25 …
6.26 …
6.27 …
6.28 …
6.29 …
6.30 Analysis Workstations*
Information related to all analysis workstations used in Biosimilars analysis is included in this section. A
total of eight analysis workstations were utilized, however after evaluation only two had data and were
determined in scope for archive VM creation: … and …. After examination of software applications and
project utilization, it was determined that …. and … VMs were not needed.

1. The identified workstations were used to analyze data from five instruments in the Biosimilars
labs: …
2. This section is focused on archive VM retrieval for data analysis inquiries. If there are questions
related to raw data collection or audit trails, please refer to the playbook section for retrieval of
the corresponding instrument archive VM in addition to any analysis workstation VM retrieval
needed.
 Page 15 of 20

3. Data is located on a network share for all five instruments. To obtain access to this data, follow
the steps below:
a. Visit the Security Group site …
b. Search for the security group [..]
c. Select [Request Access]
d. Type [Last Name] or User ID, and select the name from the list
e. Click [Save]
f. Select [View Cart], then click [Submit Request]
g. Once approved, access to the data will be granted
4. The eLN notebook page identifies the instrument and software(s) used for data analysis. All
possible analysis applications are included in the table below.
If only one application was used, select a single archive VM associated with that application to
retrieve. If more than one application was used for analysis, select the minimum number of
Archive VM(s) needed by looking up the analysis applications needed in the below table.

Table 33: Analysis Application and Archive VM to Choices to Recall

Analysis Application Archive VM Choices to Recall

5. Visit the eRIM website and access … (eRIM on demand). Here are the next steps in eRIM:
a. Select [Retrieve Records] link (Figure 4)
b. A new interface opens (Figure 5) with multiple fields that need to be filled out as
outlined below:
 [Reason for Request]  Audit/Inspection
 [Date Information Needed]  Date
 Page 16 of 20

 [Request Description]  System, application name and details of the data retrieval
request.
 [Record Format Type]  Structured, unless it is raw files requested in a network
share, which would then be unstructured
 [Original Source System]  Usually blank, and while not required, the requestor can
enter the system name
 [Archive Repository]  VADAR
 [Restore Archive Content to Active State]  Usually left unchecked, but there are
rare scenarios where the archive system will be taken out of archive and back into
an active state where the business will once again take custodianship and the
system will actively be used by the business
 An Archive SME will contact the requestor and work to retrieve the data needed

Figure 4: eRIM Landing Page

….

Figure 5: Retrieve Records Landing Page

6. When requested by Archive SME, copy source data from the data area below to the location
provided by archive VM team

Table 34: Equipment ID Mapped to the Data Network Share Location

Equipment ID Data Network Share Location

7. Work with Archive SME to access and retrieve data needed.

a. Reference the DRP for the appropriate analysis workstation, as needed (usually the DRP
is used by the Archival Group in the Request Management Process, but it is available in
GDMS – see details in Section 6 for GDMS DRP ID corresponding to various
workstations)
b. Provides the information to the audit team
 Page 17 of 20

8. Once the request is successfully fulfilled, the case is closed.

7 KEY POINTS OF CONTACT

This section includes the owners and contributors to this document.

Table 35: Responsibilities and POC

Name/Title Role Role Description How to contact

8 VERSION HISTORY
Table 36: Version History

Version # Date Author Description of Changes

9 APPENDIX
9.1 Table 37: Terminology Description
Terms Description
Virtual Machine (VM) A VM is a software emulation of a physical system. VM are needed to limit the costs
associated with increased time, resources and reliance on physical systems.
A VM can run in an isolated container alongside other VMs within a hardware
virtualization environment. This technology is being used to archive benchtop systems,
so that either their data or their data presentation functionality can be retained, while
the actual systems are decommissioned or redeployed. The expected business
outcomes are:
 Increased data integrity and reliability when accessing data compared to
physical standalone machines
 Improved ability to stand up benchtop
 Optimized access to data that meets audit/inspection requirements

9.2 Table 38: Equipment/Model Mapped to Type: VM, Backed Up Image or Physical
Workstation
No Equipment ID Model Type
1 Andover Asset
2 Andover Asset
 Page 18 of 20

3 Andover Asset
4 Backed Up Image
5 Backed Up Image
6 Backed Up Image
7 Backed Up Image
Backed Up Image
8
9 Backed Up Image
10 Backed Up Image
11 Backed Up Image
12 Backed Up Image
13 Backed Up Image
14 Backed Up Image
15 Backed Up Image
16 Backed Up Image
17 Backed Up Image
18 Backed Up Image
19 Backed Up Image
20 Backed Up Image
21 Backed Up Image
22 Backed Up Image
23 Backed Up Image
24 Backed Up Image
25 Backed Up Image
26 Backed Up Image
27 Backed Up Image
28 Backed Up Image
29 VM
30 VM
31 VM
32 VM
33 VM
34 VM
35 VM
36 VM
37 VM
38 VM
39 VM
40 VM
41 VM
42 VM
43 VM
 Page 19 of 20

44 VM
45 VM
46 VM
47 VM
48 VM
49 VM
50 VM
51 VM
52 VM
53 VM
54 VM
55 VM
56 VM
57 VM
58 VM
59 VM

9.3 Table 39: Equipment and Data Location – Local or on a Network Share
Equipment Model Local? Network Data Location
ID
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
 Page 20 of 20

Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
No
No