(U)_VCPS_Breakout_Storage_Pool_2.pptx

Rich Howard 11/03/2025

UNCLASSIFIED

UNCLASSIFIED

VCPS Breakout / Storage Pool Overview

UNCLASSIFIED

Version 2

The overall classification of this presentation is:

UNCLASSIFIED

Change Log

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

The current VCPS Shared Storage Pool architecture is patterned deployment of Windows Server 2019 on a dedicated EC2 at all security domains (Kr, Ur, Cu, Ti), regions and environments (Sandbox/Development, TP1, Operations)

The Storage Pool is deployed as a shared resource to Mission, FS2 and FGMOD; along with enablement for non-FGMOD UPEs to access and leverage data/artifacts produced by FGMOD mission areas Expanded use by Mission and coupling of the Storage Pool to Production and Operations processes took place gradually and organically since capability was introduced in 2019 The FS2 approach has been to enable and maintain the storage pool capabilities and instances on behalf of mission, with deference that the data held within the virtual drives by SF (Offices and Missions) is only to be moved/deleted/archived upon approval by SF

Usage patterns/Use-Cases fulfilled by the current Storage Pool design include:

Mission Users (SF-G, SF-H): Holdings for Production artifacts, in-work data, outputs (pre/post QA) across Offices, Enterprise Active Directory (AD)-backed/tailored Security Groups and folder structures Mission Areas/Groups Mission Users (SF-G, SF-H): Personal folder holdings, shared artifacts (connection files, NPE certs, documentation) management FS2: Windows Server Shadow Copy support (non-AWS snapshot / intra-day file restoration) on Mission User behalf FS2: Citrix Profile hosting, tailored Virtual Drive (M:/, K:/) mapping based on User/Mission/VDA Group FS2: Systems Team-designed/hosted administrative and patching solutions; some tied to AD Group Policy Objects

VCPS Storage Pool Implementation

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

VCPS Shared Storage Pools deployments/separate integration of Storage Pool for each environment Sizing/implementation of EBS storage drives and virtual drives is reflective of the Mission Areas/User base at each domain These are adapted and aligned for Active Directory implementations at each security Domain (Organizational Units, Security Groups, GPOs)

Example EBS Drive Alignment to Storage Pool EC2 (m5.4xlarge, sized for instance throughput/performance):

VCPS Storage Pool Use-Case / Implementation Background

*Expanded to largest addressable size available for Windows Server

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Active Directory Organization Unit / Mission Security Group Dependencies:

Virtual Desktop logon scripts developed and assigned per-mission team (Virtual drive mounting and assignment) Security Groups are aligned to Mission Offices, with User Domain credentials requiring approval from Mission Offices prior to user access Within virtual drives (ex: M:\ or K:\) the root of the share drive is accessible to all authenticated users, with the ability to create folders. Access to subfolders is locked down by mission and controlled by Active Directory Security Groups.

Permission structures are not fully administered by the FS2 team; Folders are created with creator owner permission, allowing the folder owner to manage permissions to their data.

Data Maintenance:

FS2 Operations directly monitors the AWS Instance and attached EBS volumes through Cloudwatch and AWS Console Additional checks for storage space utilization are managed by FS2 Ops, as well as snapshot status When increased use/space limitations are approached, FS2 notifies affected mission to manage their data (eg remove, archive to s3, compress). If required and approved, FS2 can allocate more space to the drive, or additional drives to the mission.

FS2 does not institute space quotas on drive use to a given office or Group

Windows Shadow Copy / File Restoration Operations Team provides escalation support to restore files (intra-day Shadow Copy) or snapshot restoration, with minimal disruption Used/requested frequently Dedicated EBS storage supports shadow copy files and management Details on the structure of the Windows Server Shadow Copy are provided in backup slides

VCPS Storage Pool Use-Case / Implementation Background (Cont’d)

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Common Services Breakout (Phase 1) of VCPS Breakout does not have a direct impact on the existing VCPS Storage Pool, target VDA locations/servicing

As Mission Systems (TD-X, UPEs, BPS, GEMS VDA) move into their own accounts (Phase 2):

New Citrix Profiles will be established within their breakout AWS account. (Possible impact, in plan) Access to Storage Pool Mission Shares in VCPS must be maintained (UPEs) (No VCPS Impact, UPE Account connection validation) Systems with their own dedicated mission storage (TD-X, BPS) FS2 will recreate and migrate that storage into their new account (No impact, in plan)

With Phase 3 (VCPS/Common services transition) and Phase 5 (transition out), management of the existing Storage Pool and Citrix profiles is not coupled nor controlled by the Citrix Management environment Changes to Citrix Profile locations on the Storage Pool and resident environment access must be maintained to make the profiles reachable from external sources (Common Services) Access (NACL/Security Group) from external UPE accounts into the VCPS Storage Pool to support sharing of mission data must be maintained or transitioned to alternative approach (S3) VCPS Breakout / Storage Pool Impacts

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Post VCPS Breakout Storage Pool Alignment (Systems Diagram)

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Storage Pool Data Holdings:

FS2 Operations has inquired on multiple occasions with Mission (SF-H and SF-G) on the data holdings and status of items stored in the Shared Storage Pool regarding Record retention No specific guidance or decisions have been shared from Mission to FS2 on status or management of holdings as records Out of an abundance of caution, FS2 does not independently archive or remove data in SF virtual drives or personal folders Risk does exist that partial holdings in the Shared storage pool could be identified for retention

UPE Storage Pool Access Access from outside AWS accounts as part of VCPS breakout is planned as a mitigation to shared mission holdings which UPEs need access to Alternative approaches (S3 buckets) may be considered to facilitate cross-account communication; but would require input from mission and repeatable/timely replication of data

Future Items:

FSx - Windows FS2 has performed prototyping of FSx for Windows Server in XC and Ur TP1 as a future replacement of the existing storage pool This would be considered a Pathfinder effort for Enterprise, novel adoption Is there is desire to continue that approach or vet with Cloud Ops/TESR?

Storage Pool Availability needs for ESRi/K8?

Are there defined use cases for Production or holdings to be transferred from/referenced within the K8 environment?

Considerations

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Backup Slides

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

Storage Pool - Windows Server Shadow Copy Architecture

UNCLASSIFIED

UNCLASSIFIED

Future - VCPS System Breakout (Systems Diagram)

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

VCPS Breakout Project Overview Phase 1 – Shared Services and Tandem-X mission breakout (May 2025 – January 2026) FS2 establishes new AWS accounts and SPIDs at each security fabric (Ur, Ti, Cu, Kr) and environment (TP1, Operations) for redeployment of shared services All deployments of instances and services are separate and non-impacting to existing shared services including Citrix Shared services defined as Citrix technical stack, Shared Software artifact S3 buckets, Operations monitoring software/log ingest services, Gx integration proxies) Tandem-X mission area nominated for first mission breakout due to heavy reliance on Citrix/external interconnectivity

Phase 2 – Non-FGMOD Mission Breakout from VCPS Account (January 2026 – June 2026) Non-FGMOD Mission Areas within VCPS (including User Production Environments [virtual desktops]) are redeployed into new AWS accounts/SPIDS in alignment with COA designations New accounts integrate directly with Shared Services account vice existing VCPS-based Citrix and shared services

Phase 3 – VCPS/FGMOD Citrix cutover to Shared Services Account (January 2026 – March 2026) Transition is specifically for Citrix management stack (initial connection to delivery groups, then pointed to existing Virtual Desktops No change to FGMOD mission virtual desktop baselines, hosting, or mission configurations Earliest Target readiness:

Ur TP1*: Early December 2025 (*pre-Tandem-X integration) Ti TP1: Early January 2026 Cu TP1: Early February 2026

Phase 4 – High Availability Implementation of Citrix within Shared Services (March 2026 – August 2026) Procure additional Citrix licenses and perform PoC with latest Citrix delivered baseline, transition shared services configuration to H-A

UNCLASSIFIED

UNCLASSIFIED

Common Services Citrix / VCPS (System Workflow/Segment Arch)

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

image2.png image3.png image4.png image5.png image6.png image7.png image8.png image9.png image10.png image11.jpg image12.jpg image13.jpg image14.jpg image1.wmf