DC Migration Execution Guide

Juan Munoz -- System Administrator

Prepared by	Max Simon, Director of ITOps
Your role	Technical execution lead
Date	March 21 2026
Contact Max	Slack DM -- any time, any phase

Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.

What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item	Why It Matters to You
fslsto storage account conversion (Zendesk #17454)	Must be done before Phase 1 pilot starts
PIM roles for Max and Juan	Must exist before domain admin accounts are decommissioned
SSPR enabled for all users	Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation	Confirms service desk can support AVD users without DC admin accounts

Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.

PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes

User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:

Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate

The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:

ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt

PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes

User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:

foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}

Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:

All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding

PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes

User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):

$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}

Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:

foreach ($acct in $decommission) {
    try {
        Disable-ADAccount -Identity $acct
        Write-Host "DISABLED: $acct" -ForegroundColor Green
    } catch {
        Write-Host "FAILED: $acct -- $(DC Migration Execution Guide
Juan Munoz -- System Administrator

Prepared by Max Simon, Director of ITOps
Your role Technical execution lead
Date March 21 2026
Contact Max Slack DM -- any time, any phase



Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.



What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item Why It Matters to You
fslsto storage account conversion (Zendesk #17454) Must be done before Phase 1 pilot starts
PIM roles for Max and Juan Must exist before domain admin accounts are decommissioned
SSPR enabled for all users Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation Confirms service desk can support AVD users without DC admin accounts



Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.



PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes
User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:
Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate
The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:
ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt



PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes
User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}
Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:
All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding



PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes
User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):
$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}
Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:
CODE_BLOCK_PLACEHOLDER_3
Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:
All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:
Enable-ADAccount -Identity [account-name]



PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours
User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:
   - Group type: Security
   - Group name: exactly as listed in the table (capitalisation matters)
   - Membership type: Assigned
   - Members: match the AD group membership exactly

Group Name Member Count
AVD_Admins 4
AVD_Users_AsiaPacificEastAsia 17
AVD_Users_EastUS 19
AVD_Users_SouthCentralUS 2
AVD_Users_SouthAfricaNorth 2
AVD_Users_SouthAmericaBrazilSouth 4
AVD_Users_Dev 10
AVD_Users_Medium 5
AVD_Users_Light 2
AVD_Manager_1hourTimeOut 7
AVD-BusinessPremiumLicense 20
AVD-DefenderLicense 17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:
All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.



PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)
User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:
PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:
Get-AVDGroupAssignments.ps1 -RunMode after
This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:
All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap



PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour
User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO What It Does Build as
RS_AVD Computer Policy Core session host config, Zoiper5 VoIP Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults Default app associations on login Intune Configuration Profile (User)
RS_AVD Idle Session Timeout 1-hour idle + disconnect limits Intune Configuration Profile (Device)
RS_AVD Drive Mappings Drive maps per region PowerShell logon script
RS_AVD_Five9_Install Five9 softphone deployment Intune Win32 App
RS_AVD_Five9SC_Install Five9 screen capture agent Intune Win32 App
RS_AVD_Five9ScreenCapture UAC setting for Five9 screen capture Intune Configuration Profile (Device)
Default Domain Policy Password policy and lockout Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:
Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria



PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.



PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes
User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:
$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"
Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:
CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt



Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:
Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.



P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)
User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:
Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:
Start-ADSyncSyncCycle -PolicyType Delta
All 5 users restored within 5 minutes.



P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days
User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check How to Verify
VPN User confirms Azure VPN connects
Teams / SharePoint / OneDrive User confirms all three load normally
SSO apps User confirms their usual apps open without re-login prompts
Device login Windows Hello works, no unexpected sign-in prompts
Password reset User can access portal.office.com and reset password if needed
Group memberships Check in Entra that the user's groups are intact
ScreenConnect You can successfully remote into the user's machine via ScreenConnect

Done when:
All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2



Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:
~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3



Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:
Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:
All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins



Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**



P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:
Get-EventLog -LogName Security -InstanceId 4624 -Newest 1000 |
    Where-Object { DC Migration Execution Guide
Juan Munoz -- System Administrator

Prepared by Max Simon, Director of ITOps
Your role Technical execution lead
Date March 21 2026
Contact Max Slack DM -- any time, any phase



Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.



What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item Why It Matters to You
fslsto storage account conversion (Zendesk #17454) Must be done before Phase 1 pilot starts
PIM roles for Max and Juan Must exist before domain admin accounts are decommissioned
SSPR enabled for all users Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation Confirms service desk can support AVD users without DC admin accounts



Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.



PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes
User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:
Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate
The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:
ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt



PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes
User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}
Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:
All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding



PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes
User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):
$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}
Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:
foreach ($acct in $decommission) {
    try {
        Disable-ADAccount -Identity $acct
        Write-Host "DISABLED: $acct" -ForegroundColor Green
    } catch {
        Write-Host "FAILED: $acct -- $(DC Migration Execution Guide
Juan Munoz -- System Administrator

Prepared by Max Simon, Director of ITOps
Your role Technical execution lead
Date March 21 2026
Contact Max Slack DM -- any time, any phase



Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.



What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item Why It Matters to You
fslsto storage account conversion (Zendesk #17454) Must be done before Phase 1 pilot starts
PIM roles for Max and Juan Must exist before domain admin accounts are decommissioned
SSPR enabled for all users Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation Confirms service desk can support AVD users without DC admin accounts



Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.



PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes
User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:
Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate
The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:
ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt



PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes
User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}
Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:
All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding



PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes
User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):
$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}
Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:
CODE_BLOCK_PLACEHOLDER_3
Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:
All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:
Enable-ADAccount -Identity [account-name]



PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours
User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:
   - Group type: Security
   - Group name: exactly as listed in the table (capitalisation matters)
   - Membership type: Assigned
   - Members: match the AD group membership exactly

Group Name Member Count
AVD_Admins 4
AVD_Users_AsiaPacificEastAsia 17
AVD_Users_EastUS 19
AVD_Users_SouthCentralUS 2
AVD_Users_SouthAfricaNorth 2
AVD_Users_SouthAmericaBrazilSouth 4
AVD_Users_Dev 10
AVD_Users_Medium 5
AVD_Users_Light 2
AVD_Manager_1hourTimeOut 7
AVD-BusinessPremiumLicense 20
AVD-DefenderLicense 17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:
All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.



PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)
User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:
PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:
Get-AVDGroupAssignments.ps1 -RunMode after
This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:
All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap



PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour
User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO What It Does Build as
RS_AVD Computer Policy Core session host config, Zoiper5 VoIP Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults Default app associations on login Intune Configuration Profile (User)
RS_AVD Idle Session Timeout 1-hour idle + disconnect limits Intune Configuration Profile (Device)
RS_AVD Drive Mappings Drive maps per region PowerShell logon script
RS_AVD_Five9_Install Five9 softphone deployment Intune Win32 App
RS_AVD_Five9SC_Install Five9 screen capture agent Intune Win32 App
RS_AVD_Five9ScreenCapture UAC setting for Five9 screen capture Intune Configuration Profile (Device)
Default Domain Policy Password policy and lockout Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:
Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria



PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.



PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes
User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:
$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"
Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:
CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt



Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:
Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.



P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)
User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:
Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:
Start-ADSyncSyncCycle -PolicyType Delta
All 5 users restored within 5 minutes.



P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days
User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check How to Verify
VPN User confirms Azure VPN connects
Teams / SharePoint / OneDrive User confirms all three load normally
SSO apps User confirms their usual apps open without re-login prompts
Device login Windows Hello works, no unexpected sign-in prompts
Password reset User can access portal.office.com and reset password if needed
Group memberships Check in Entra that the user's groups are intact
ScreenConnect You can successfully remote into the user's machine via ScreenConnect

Done when:
All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2



Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:
~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3



Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:
Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:
All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins



Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**



P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:
CODE_BLOCK_PLACEHOLDER_9
Send the CSV to Max for review

Done when:
Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02



P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:
Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:
Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:
RDP into any active AVD session host
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}0
Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:
Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts



P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:
pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.



P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:
Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:
Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}1

Delete stale computer objects (Max-approved list from PRE-08):
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}2

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:
VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation



Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.



Key Contacts

Person Role Contact
Max Simon Director of ITOps -- decision authority Slack DM
RapidScale account team MSP -- billing and DC VM questions Via existing ticket channel



DC Migration -- Pacific Debt Relief -- March 2026
Prepared by Max Simon for Juan Munoz
.Exception.Message)" -ForegroundColor Red
    }
}
Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:
All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:
Enable-ADAccount -Identity [account-name]



PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours
User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:
   - Group type: Security
   - Group name: exactly as listed in the table (capitalisation matters)
   - Membership type: Assigned
   - Members: match the AD group membership exactly

Group Name Member Count
AVD_Admins 4
AVD_Users_AsiaPacificEastAsia 17
AVD_Users_EastUS 19
AVD_Users_SouthCentralUS 2
AVD_Users_SouthAfricaNorth 2
AVD_Users_SouthAmericaBrazilSouth 4
AVD_Users_Dev 10
AVD_Users_Medium 5
AVD_Users_Light 2
AVD_Manager_1hourTimeOut 7
AVD-BusinessPremiumLicense 20
AVD-DefenderLicense 17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:
All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.



PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)
User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:
PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:
Get-AVDGroupAssignments.ps1 -RunMode after
This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:
All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap



PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour
User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO What It Does Build as
RS_AVD Computer Policy Core session host config, Zoiper5 VoIP Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults Default app associations on login Intune Configuration Profile (User)
RS_AVD Idle Session Timeout 1-hour idle + disconnect limits Intune Configuration Profile (Device)
RS_AVD Drive Mappings Drive maps per region PowerShell logon script
RS_AVD_Five9_Install Five9 softphone deployment Intune Win32 App
RS_AVD_Five9SC_Install Five9 screen capture agent Intune Win32 App
RS_AVD_Five9ScreenCapture UAC setting for Five9 screen capture Intune Configuration Profile (Device)
Default Domain Policy Password policy and lockout Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:
Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria



PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.



PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes
User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:
$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"
Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:
CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt



Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:
Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.



P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)
User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:
Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:
Start-ADSyncSyncCycle -PolicyType Delta
All 5 users restored within 5 minutes.



P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days
User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check How to Verify
VPN User confirms Azure VPN connects
Teams / SharePoint / OneDrive User confirms all three load normally
SSO apps User confirms their usual apps open without re-login prompts
Device login Windows Hello works, no unexpected sign-in prompts
Password reset User can access portal.office.com and reset password if needed
Group memberships Check in Entra that the user's groups are intact
ScreenConnect You can successfully remote into the user's machine via ScreenConnect

Done when:
All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2



Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:
~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3



Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:
Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:
All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins



Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**



P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:
CODE_BLOCK_PLACEHOLDER_9
Send the CSV to Max for review

Done when:
Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02



P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:
Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:
Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:
RDP into any active AVD session host
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}0
Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:
Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts



P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:
pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.



P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:
Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:
Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}1

Delete stale computer objects (Max-approved list from PRE-08):
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}2

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:
VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation



Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.



Key Contacts

Person Role Contact
Max Simon Director of ITOps -- decision authority Slack DM
RapidScale account team MSP -- billing and DC VM questions Via existing ticket channel



DC Migration -- Pacific Debt Relief -- March 2026
Prepared by Max Simon for Juan Munoz
.Message -notmatch 'pcddc01\CODE_BLOCK_PLACEHOLDER_9#39; } |
    Select-Object TimeGenerated, Message |
    Export-Csv C:\Temp\dc-recon\final-auth-check.csv
Send the CSV to Max for review

Done when:
Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02



P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:
Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:
Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:
RDP into any active AVD session host
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}0
Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:
Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts



P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:
pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.



P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:
Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:
Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}1

Delete stale computer objects (Max-approved list from PRE-08):
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}2

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:
VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation



Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.



Key Contacts

Person Role Contact
Max Simon Director of ITOps -- decision authority Slack DM
RapidScale account team MSP -- billing and DC VM questions Via existing ticket channel



DC Migration -- Pacific Debt Relief -- March 2026
Prepared by Max Simon for Juan Munoz
.Exception.Message)" -ForegroundColor Red
    }
}

Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:

All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:

Enable-ADAccount -Identity [account-name]

PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours

User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:

- Group type: Security

- Group name: exactly as listed in the table (capitalisation matters)

- Membership type: Assigned

- Members: match the AD group membership exactly

Group Name	Member Count
`AVD_Admins`	4
`AVD_Users_AsiaPacificEastAsia`	17
`AVD_Users_EastUS`	19
`AVD_Users_SouthCentralUS`	2
`AVD_Users_SouthAfricaNorth`	2
`AVD_Users_SouthAmericaBrazilSouth`	4
`AVD_Users_Dev`	10
`AVD_Users_Medium`	5
`AVD_Users_Light`	2
`AVD_Manager_1hourTimeOut`	7
`AVD-BusinessPremiumLicense`	20
`AVD-DefenderLicense`	17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:

All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.

PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)

User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:

PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:

Get-AVDGroupAssignments.ps1 -RunMode after

This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:

All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap

PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour

User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO	What It Does	Build as
RS_AVD Computer Policy	Core session host config, Zoiper5 VoIP	Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults	Default app associations on login	Intune Configuration Profile (User)
RS_AVD Idle Session Timeout	1-hour idle + disconnect limits	Intune Configuration Profile (Device)
RS_AVD Drive Mappings	Drive maps per region	PowerShell logon script
RS_AVD_Five9_Install	Five9 softphone deployment	Intune Win32 App
RS_AVD_Five9SC_Install	Five9 screen capture agent	Intune Win32 App
RS_AVD_Five9ScreenCapture	UAC setting for Five9 screen capture	Intune Configuration Profile (Device)
Default Domain Policy	Password policy and lockout	Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:

Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria

PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.

PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes

User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:

$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"

Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:

CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt

Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:

Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.

P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)

User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:

Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:

Start-ADSyncSyncCycle -PolicyType Delta

All 5 users restored within 5 minutes.

P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days

User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check	How to Verify
VPN	User confirms Azure VPN connects
Teams / SharePoint / OneDrive	User confirms all three load normally
SSO apps	User confirms their usual apps open without re-login prompts
Device login	Windows Hello works, no unexpected sign-in prompts
Password reset	User can access `portal.office.com` and reset password if needed
Group memberships	Check in Entra that the user's groups are intact
ScreenConnect	You can successfully remote into the user's machine via ScreenConnect

Done when:

All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2

Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:

~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3

Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:

Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:

All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins

Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**

P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:

Get-EventLog -LogName Security -InstanceId 4624 -Newest 1000 |
    Where-Object { DC Migration Execution Guide
Juan Munoz -- System Administrator

Prepared by Max Simon, Director of ITOps
Your role Technical execution lead
Date March 21 2026
Contact Max Slack DM -- any time, any phase



Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.



What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item Why It Matters to You
fslsto storage account conversion (Zendesk #17454) Must be done before Phase 1 pilot starts
PIM roles for Max and Juan Must exist before domain admin accounts are decommissioned
SSPR enabled for all users Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation Confirms service desk can support AVD users without DC admin accounts



Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.



PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes
User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:
Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate
The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:
ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt



PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes
User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}
Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:
All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding



PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes
User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):
$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}
Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:
foreach ($acct in $decommission) {
    try {
        Disable-ADAccount -Identity $acct
        Write-Host "DISABLED: $acct" -ForegroundColor Green
    } catch {
        Write-Host "FAILED: $acct -- $(DC Migration Execution Guide
Juan Munoz -- System Administrator

Prepared by Max Simon, Director of ITOps
Your role Technical execution lead
Date March 21 2026
Contact Max Slack DM -- any time, any phase



Before You Start -- Read This

This document is your complete guide for migrating PDR off the on-premises Domain Controller (pcddc01) to pure Entra ID (Azure AD). Work top to bottom. Do not skip steps. Do not improvise.

The one rule: If something behaves unexpectedly, stop immediately and message Max on Slack. Include what step you were on and what happened. Do not wait more than 15 minutes before escalating. Max makes the call on whether to continue or roll back -- that decision is never yours alone beyond the pilot phase.

Every task in this document has a rollback procedure. Know where it is before you execute the task.

What this migration does: Moves all PDR user accounts from being managed by the DC to being managed directly in Entra. Users keep the same email, passwords, licenses, and access. The DC just stops being the source of truth. Once complete, the DC VM gets deleted and PDR saves the monthly hosting cost.

What this migration does NOT do: It does not touch VPN, Teams, SharePoint, OneDrive, Defender, or any end-user applications. It does not change how users log into their devices. It does not affect AVD session hosts -- those stay domain-joined throughout and are handled separately.



What Max Is Handling (Not Your Work)

These items are in flight. Max will tell you when they are done. Your pre-phase work starts now -- you do not need to wait for these before PRE-01 through PRE-03.

Item Why It Matters to You
fslsto storage account conversion (Zendesk #17454) Must be done before Phase 1 pilot starts
PIM roles for Max and Juan Must exist before domain admin accounts are decommissioned
SSPR enabled for all users Users need self-service password reset before they lose DC sync
ScreenConnect PAM validation Confirms service desk can support AVD users without DC admin accounts



Pre-Phase Tasks

These tasks prepare the environment before any user migration begins. They have no user impact. Start PRE-01 through PRE-03 now. PRE-04 onwards requires Max to confirm B-008 (fslsto) is cleared first.



PRE-01 -- Confirm ldap_svc Is Disabled

Time estimate: 10 minutes
User impact: None

There is a zombie service account called ldap_svc that was used by a decommissioned Palo Alto VPN. The March audit confirmed it should be disabled. This task verifies that.

RDP into the DC at 40.78.86.128 using your max.admin credentials
Open PowerShell as Administrator (right-click > Run as Administrator)
Run this command:
Get-ADUser -Identity ldap_svc -Properties Enabled, LastLogonDate |
    Select-Object SamAccountName, Enabled, LastLogonDate
The output should show Enabled = False
If it shows Enabled = True -- stop and message Max immediately before doing anything else

Done when:
ldap_svc confirmed Enabled = False
You've saved the output to a text file named pre-01-ldap-svc-[today's date].txt



PRE-02 -- Identify the Three Unknown Windows 11 Machines

Time estimate: 20 minutes
User impact: None

Three Windows 11 machines showed up in AD with last logon March 19 2026 and no clear owner. Based on the Azure infrastructure scan, they are likely the gold master VMs (GM-test at 10.20.240.26 and Win11GoldMaster at 10.20.240.27) plus one other. This task confirms their identity.

RDP into the DC at 40.78.86.128
Open PowerShell as Administrator
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}
Note the IP addresses from the output
Open Azure portal and go to Virtual Machines > filter by PCD-WUS-INFRA-RG
Match the IPs to VMs in that resource group
Document what each machine is

Done when:
All three machines identified with their purpose written down
Saved to pre-02-unknown-machines-[today's date].txt
If any machine's ownership is unclear, message Max before proceeding



PRE-03 -- Disable 13 Domain Admin Accounts (Zendesk #17453)

Time estimate: 30 minutes
User impact: None -- these accounts are not used for day-to-day operations

The DC has 14 domain admin accounts. Only 2 survive this migration: Max.Admin and juanadmin. The other 13 are being decommissioned. This was confirmed safe in the March 21 dependency audit. This is the first official DC migration action.

Run the dry-run first -- confirm the list before disabling anything:

RDP into the DC at 40.78.86.128 using max.admin
Open PowerShell as Administrator
Dry-run (read-only -- confirms what will be disabled):
$decommission = @('Anthony.Admin','tinaaspera-admin','edward-admin','queenie.admin',
                  'jet.admin','alvin.tagatac','jazzer.sales','diana.gabat',
                  'jordan-admin','rapidscale','rapidadmin','joiner')
foreach ($acct in $decommission) {
    $u = Get-ADUser -Identity $acct -Properties Enabled -ErrorAction SilentlyContinue
    if ($u) { Write-Host "WILL DISABLE: $acct (Enabled=$($u.Enabled))" -ForegroundColor Yellow }
    else { Write-Host "NOT FOUND: $acct" -ForegroundColor Gray }
}
Review the output -- confirm Max.Admin and juanadmin are NOT on this list
If the list looks correct, run the actual disable:
CODE_BLOCK_PLACEHOLDER_3
Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:
All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:
Enable-ADAccount -Identity [account-name]



PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours
User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:
   - Group type: Security
   - Group name: exactly as listed in the table (capitalisation matters)
   - Membership type: Assigned
   - Members: match the AD group membership exactly

Group Name Member Count
AVD_Admins 4
AVD_Users_AsiaPacificEastAsia 17
AVD_Users_EastUS 19
AVD_Users_SouthCentralUS 2
AVD_Users_SouthAfricaNorth 2
AVD_Users_SouthAmericaBrazilSouth 4
AVD_Users_Dev 10
AVD_Users_Medium 5
AVD_Users_Light 2
AVD_Manager_1hourTimeOut 7
AVD-BusinessPremiumLicense 20
AVD-DefenderLicense 17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:
All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.



PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)
User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:
PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:
Get-AVDGroupAssignments.ps1 -RunMode after
This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:
All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap



PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour
User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO What It Does Build as
RS_AVD Computer Policy Core session host config, Zoiper5 VoIP Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults Default app associations on login Intune Configuration Profile (User)
RS_AVD Idle Session Timeout 1-hour idle + disconnect limits Intune Configuration Profile (Device)
RS_AVD Drive Mappings Drive maps per region PowerShell logon script
RS_AVD_Five9_Install Five9 softphone deployment Intune Win32 App
RS_AVD_Five9SC_Install Five9 screen capture agent Intune Win32 App
RS_AVD_Five9ScreenCapture UAC setting for Five9 screen capture Intune Configuration Profile (Device)
Default Domain Policy Password policy and lockout Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:
Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria



PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.



PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes
User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:
$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"
Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:
CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt



Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:
Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.



P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)
User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:
Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:
Start-ADSyncSyncCycle -PolicyType Delta
All 5 users restored within 5 minutes.



P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days
User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check How to Verify
VPN User confirms Azure VPN connects
Teams / SharePoint / OneDrive User confirms all three load normally
SSO apps User confirms their usual apps open without re-login prompts
Device login Windows Hello works, no unexpected sign-in prompts
Password reset User can access portal.office.com and reset password if needed
Group memberships Check in Entra that the user's groups are intact
ScreenConnect You can successfully remote into the user's machine via ScreenConnect

Done when:
All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2



Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:
~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3



Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:
Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:
All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins



Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**



P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:
CODE_BLOCK_PLACEHOLDER_9
Send the CSV to Max for review

Done when:
Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02



P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:
Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:
Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:
RDP into any active AVD session host
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}0
Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:
Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts



P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:
pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.



P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:
Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:
Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}1

Delete stale computer objects (Max-approved list from PRE-08):
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}2

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:
VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation



Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.



Key Contacts

Person Role Contact
Max Simon Director of ITOps -- decision authority Slack DM
RapidScale account team MSP -- billing and DC VM questions Via existing ticket channel



DC Migration -- Pacific Debt Relief -- March 2026
Prepared by Max Simon for Juan Munoz
.Exception.Message)" -ForegroundColor Red
    }
}
Save all output to pre-03-admin-disable-[today's date].txt
Update Zendesk #17453 and close it

Done when:
All 13 accounts confirmed disabled
Max.Admin and juanadmin confirmed still enabled
Zendesk #17453 closed

If you need to re-enable an account:
Enable-ADAccount -Identity [account-name]



PRE-04 -- Recreate All 12 AVD Groups in Entra

Wait for Max confirmation that fslsto (B-008) is cleared before starting this task.

Time estimate: 1-2 hours
User impact: None -- new groups created in parallel, old groups still in place

All 12 AVD security groups currently live in the DC. Before we can cut over, identical groups need to exist in Entra with the same members. This task creates them.

Source of truth for membership: The AD snapshot captured March 21 2026. Message Max to pull the member list for each group from the snapshot JSON if you need it.

Open Entra admin center at https://entra.microsoft.com
Go to Groups > All groups > New group
For each group in the table below, create a group with these settings:
   - Group type: Security
   - Group name: exactly as listed in the table (capitalisation matters)
   - Membership type: Assigned
   - Members: match the AD group membership exactly

Group Name Member Count
AVD_Admins 4
AVD_Users_AsiaPacificEastAsia 17
AVD_Users_EastUS 19
AVD_Users_SouthCentralUS 2
AVD_Users_SouthAfricaNorth 2
AVD_Users_SouthAmericaBrazilSouth 4
AVD_Users_Dev 10
AVD_Users_Medium 5
AVD_Users_Light 2
AVD_Manager_1hourTimeOut 7
AVD-BusinessPremiumLicense 20
AVD-DefenderLicense 17

After creating all 12, verify member counts match the table
Record the Object ID for each new group -- you need these for the next task. Copy them into a text file.

Done when:
All 12 groups exist in Entra
Member counts all verified
All 12 Object IDs saved to pre-04-entra-groups-[date].txt

If something goes wrong: Delete the new Entra groups you created. The old DC-synced groups and all AVD assignments are completely unaffected.



PRE-05 -- Swap AVD Application Group Assignments

Time estimate: 2-3 hours (includes validation between each pool)
User impact: Minimal -- brief reconnect may be required for users already in an AVD session during the swap

This is the highest-risk pre-phase task. Read all the steps before you start. Execute one host pool at a time. Do not rush.

What you are doing: Each AVD host pool has an application group that controls which users can connect. Right now those application groups point to DC-synced groups (the old ones). You are updating them to point to the new Entra-native groups you created in PRE-04.

This is a pointer swap. You are not touching the session hosts, the VMs, the user profiles, or any network configuration.

Before you start:
PRE-04 must be 100% complete with all 12 group Object IDs recorded
Have the Azure portal open at portal.azure.com > Azure Virtual Desktop > Host Pools
Have the Object IDs from PRE-04 in front of you

For each host pool (repeat these steps one pool at a time):

Azure portal > Azure Virtual Desktop > Host Pools
Click on a host pool
Click Application groups in the left menu
Click on the Desktop Application Group
Click Role assignments in the left menu
Click Add > Add role assignment
Role: select Desktop Virtualization User
Members: search for the matching new Entra group (same name as the old one)
Click Save
Once the new assignment shows up, click the old DC-synced group assignment
Click Remove
Test immediately -- ask a user in that group to open their AVD session and confirm it connects
If the user can connect: move to the next host pool
If the user cannot connect: re-add the old group immediately and message Max

After all pools are swapped, run the parity check. Message Max and ask him to run:
Get-AVDGroupAssignments.ps1 -RunMode after
This confirms all 12 groups are now pointing to Entra-native groups. You need a clean result before Phase 1.

Done when:
All AVD application group assignments updated
Parity check returns clean (Max confirms)
At least one user per host pool confirmed connected post-swap



PRE-06 -- GPO Review and Intune Task Creation

Time estimate: 1 hour
User impact: None -- planning only

The DC has 20 Group Policy Objects (GPOs) that configure AVD session hosts. When the DC goes offline, these stop applying. Before Phase 4 (DC decommission), Intune policies need to exist to replace them.

This does not block Phase 1, 2, or 3. You have time to build these. But the work needs to start now because the Five9 policies are complex.

Create a Zendesk task for each of these 8 HIGH priority GPOs:

GPO What It Does Build as
RS_AVD Computer Policy Core session host config, Zoiper5 VoIP Intune Configuration Profile (Device)
RS_AVD User Policy and Defaults Default app associations on login Intune Configuration Profile (User)
RS_AVD Idle Session Timeout 1-hour idle + disconnect limits Intune Configuration Profile (Device)
RS_AVD Drive Mappings Drive maps per region PowerShell logon script
RS_AVD_Five9_Install Five9 softphone deployment Intune Win32 App
RS_AVD_Five9SC_Install Five9 screen capture agent Intune Win32 App
RS_AVD_Five9ScreenCapture UAC setting for Five9 screen capture Intune Configuration Profile (Device)
Default Domain Policy Password policy and lockout Entra password protection + CA policy (Max owns this one)

Tag all tickets dc-migration and intune-policy. Set target date as pre-Phase 4.

The XML files for all 20 GPOs are in the repo at evidence/dc-migration/gpo-reports-20260321_152720/. Open the XML for each HIGH priority GPO to see the exact settings you need to replicate.

Done when:
Zendesk tasks created for all 8 HIGH priority GPOs
Tasks include the specific settings as acceptance criteria



PRE-07 -- fslsto Storage Account Conversion

Owner: Max. You assist with AVD session host RDP access if Max needs it.

The fslsto storage account currently uses the DC for authentication. Max is converting it to Entra authentication. When Max asks you to test on an AVD session host, RDP into a dev pool host, log in as a test user, and confirm file share access works. Report back to Max with what you see.



PRE-08 -- Stale Computer Object Audit

Time estimate: 30 minutes
User impact: None

The DC has stale computer objects from old AVD host pool generations that were never cleaned up. This task identifies them for deletion.

RDP into pcddc01
Run:
$stalePatterns = @('PCDAPAVDDH9-*','PCDAVDDHL-9-*','PCDAVDDH-8-*',
                   'PCDAVDDHL-8-*','PCDAVDDH-6-*','PCDAVDDHM-6-*','pcdavdsh*')
$staleExact = @('orphantest','test-avd-001','goldmasterm','MAXBOX3000',
                'pcdfs01','PCDAVDDT01-0','vm-21ff05')

$candidates = @()
foreach ($p in $stalePatterns) {
    $candidates += Get-ADComputer -Filter "Name -like '$p'" `
        -Properties LastLogonDate, Enabled -ErrorAction SilentlyContinue
}
foreach ($n in $staleExact) {
    try { $candidates += Get-ADComputer -Identity $n `
        -Properties LastLogonDate, Enabled } catch {}
}
$candidates | Select-Object Name, Enabled, LastLogonDate |
    Export-Csv C:\Temp\dc-recon\stale-candidates.csv -NoTypeInformation
Write-Host "$($candidates.Count) candidates found"
Transfer the CSV to Max for approval
Do not delete anything until Max approves the list
After approval: disable the objects first, wait 7 days, then delete

Done when:
CSV generated and sent to Max
After Max approval: objects disabled, 7-day wait, then deleted
Logged to pre-08-stale-cleanup-[date].txt



Phase 1 -- Service Desk Pilot (5 Users)

Do not start Phase 1 until Max confirms all pre-phase tasks and blocked items are complete.

Who is in the pilot:
Tina Aspera
Queenie Duyac
Diana Gabat
Two additional service desk agents (Max will confirm)

These 5 users are the safest possible pilot group -- they are IT-adjacent, have no AVD dependency, and you can support them immediately if anything breaks.



P1-01 -- Remove Service Desk OU from Entra Connect Sync

Time estimate: 45 minutes (including 30-min sync wait)
User impact: The 5 pilot users move from DC-synced to cloud-only. Same passwords, same access. They just won't depend on the DC anymore.

RDP into pcddc01 at 40.78.86.128
Open Azure AD Connect from the Start menu (or C:\Program Files\Microsoft Azure AD Sync\AADConnectAuthUI.exe)
Click Configure
Select Customize synchronization options > Next
Sign in when prompted
Navigate through until you reach Domain and OU filtering
Find the Service Desk OU in the tree
Uncheck the checkbox next to it
Click Next through the remaining screens and Apply
Wait 30 minutes for the sync cycle to complete automatically
After 30 minutes, open Entra admin center (entra.microsoft.com) and search for each of the 5 pilot users
For each user, confirm their profile shows no "On-premises sync" information -- this confirms they are cloud-only

Done when:
Service Desk OU unchecked in Entra Connect
30-minute sync wait completed
All 5 users confirmed cloud-only in Entra
Logged to p1-01-sync-exclusion-[date].txt

To roll back: Re-open Entra Connect, re-check the Service Desk OU, apply. Then run:
Start-ADSyncSyncCycle -PolicyType Delta
All 5 users restored within 5 minutes.



P1-02 -- Validate Pilot Users for 7 Days

Time estimate: 15 minutes per day for 7 days
User impact: None -- validation only

Run this checklist for each of the 5 pilot users every day for 7 days. Log the results each day.

Check How to Verify
VPN User confirms Azure VPN connects
Teams / SharePoint / OneDrive User confirms all three load normally
SSO apps User confirms their usual apps open without re-login prompts
Device login Windows Hello works, no unexpected sign-in prompts
Password reset User can access portal.office.com and reset password if needed
Group memberships Check in Entra that the user's groups are intact
ScreenConnect You can successfully remote into the user's machine via ScreenConnect

Done when:
All 7 checks pass for all 5 users on day 1
Daily logs saved for 7 consecutive days
No issues escalated to Max
Max gives written go-ahead for Phase 2



Phase 2 -- Expanded Pilot (~40 Users)

Start condition: Max confirms Phase 1 is clean and gives go-ahead.**

Target departments in order: Sales first, then Operations, then HR. Max will confirm the exact user list for each batch before you proceed.

Follow the same process as P1-01 for each department -- exclude the OU from Entra Connect sync, wait 30 minutes, validate. Do one department at a time. Do not exclude all three at once.

For AVD users included in this batch: after the sync exclusion, ask one user per AVD pool to connect and confirm their session works. This validates the Entra-native group pointer swaps from PRE-05 are working end-to-end for real users.

Monitoring window: 7 days after all three departments are migrated. Same validation checklist as P1-02.

Done when:
~40 users migrated and confirmed working
AVD session access validated for included AVD users
7 days clean monitoring logs
Max gives go-ahead for Phase 3



Phase 3 -- Full Cutover

Start condition: Max confirms Phase 2 is clean and gives go-ahead.**

This phase migrates all remaining users (~135) and permanently stops Entra Connect sync. After this phase, rollback takes 2-4 hours instead of 5 minutes -- coordinate timing with Max.

Batch 1: 50% of remaining users. Same OU exclusion process. Validate for 48 hours.

Batch 2: Remaining 50%. Validate for 48 hours.

After both batches are confirmed clean, stop Entra Connect:
Stop-Service -Name ADSync
Set-Service -Name ADSync -StartupType Disabled

Leave the DC powered on. It stays online for 30-60 days as a safety net. Do not touch it.

Done when:
All users confirmed cloud-only in Entra
ADSync stopped and disabled
DC still powered on and reachable
30-day clean operation window begins



Phase 4 -- DC Decommission

Start condition: 30-60 days of all users working without DC. All 8 HIGH priority Intune policies built and applied. Max sign-off received.**



P4-01 -- Final Validation

Confirm nothing has silently broken during the 30-60 day monitoring window.

Message Max to run the final readiness crawl -- confirms 0 users still DC-dependent
In Intune admin center, confirm all 8 HIGH priority policies are active and applying to AVD session hosts
Confirm ScreenConnect PAM has been used for all AVD session escalations in the past 30 days -- no one has used a DC admin account
RDP into pcddc01 and check the Security event log for unexpected authentication activity:
CODE_BLOCK_PLACEHOLDER_9
Send the CSV to Max for review

Done when:
Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02



P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:
Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:
Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:
RDP into any active AVD session host
Run:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}0
Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:
Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts



P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:
pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.



P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:
Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:
Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}1

Delete stale computer objects (Max-approved list from PRE-08):
foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}2

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:
VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation



Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.



Key Contacts

Person Role Contact
Max Simon Director of ITOps -- decision authority Slack DM
RapidScale account team MSP -- billing and DC VM questions Via existing ticket channel



DC Migration -- Pacific Debt Relief -- March 2026
Prepared by Max Simon for Juan Munoz
.Message -notmatch 'pcddc01\CODE_BLOCK_PLACEHOLDER_9#39; } |
    Select-Object TimeGenerated, Message |
    Export-Csv C:\Temp\dc-recon\final-auth-check.csv

Send the CSV to Max for review

Done when:

Max confirms 0 DC-dependent users in final crawl
All Intune policies confirmed active
Event log reviewed and sent to Max
Max gives written go-ahead for P4-02

P4-02 -- Pre-Decommission Azure Cleanup

Before powering off the DC, clean up its Azure dependencies.

Stop Azure Backup for pcddc01:

Azure portal > search "Backup center"
Backup instances > find pcddc01
Stop backup > choose "Retain backup data" (keep 60 days as safety net)

Remove monitoring extensions from pcddc01:

Azure portal > Virtual Machines > pcddc01 > Extensions + applications
Select MicrosoftMonitoringAgent > Uninstall > confirm
Select AzureMonitorWindowsAgent > Uninstall > confirm

Confirm AVD session host DNS is not pointing at the DC:

RDP into any active AVD session host
Run:

foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}

Confirm 10.20.240.11 (pcddc01's IP) does NOT appear in the output
If it does appear, message Max immediately -- DNS must be updated before the DC goes offline

Done when:

Azure Backup stopped (data retained)
Both extensions removed
DNS confirmed clean on AVD session hosts

P4-03 -- Power Off DC VM

Message Max immediately before doing this. Max should be available while you execute.

Azure portal > Virtual Machines > pcddc01
Click Stop at the top
Confirm when prompted -- select Deallocate (not just Stop)
Wait for status to show Stopped (deallocated)
Monitor for 2 weeks -- watch for any user reports, authentication failures, or app errors

Done when:

pcddc01 showing Stopped (deallocated) in Azure portal
2-week monitoring window complete with zero DC-related incidents
RapidScale account team notified to confirm billing reduction

To bring the DC back: Azure portal > Virtual Machines > pcddc01 > Start. Online within 5 minutes.

P4-04 -- Delete DC VM and Final Cleanup

Do not proceed without explicit written approval from Max. Slack message or Zendesk ticket with Max's name on it.

This is irreversible. Once deleted, the VM cannot be recovered.

Delete DC VM:

Azure portal > Virtual Machines > pcddc01 > Delete
Check: Delete OS disk
Check: Delete network interfaces
Click Delete and confirm
Confirm VM, NIC, and disk all show deleted in PCD-WUS-INFRA-RG

Delete Azure Backup collection:

Azure portal > search "Recovery Services vaults"
Find the vault protecting pcddc01 > Backup items > Azure Virtual Machine
Find pcddc01 > Delete backup data > confirm

Remove AZUREADSSOACC computer object:

foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}

Delete stale computer objects (Max-approved list from PRE-08):

foreach ($name in @('PCDSANSH-4c57', 'PCDSANSH-29af', 'pcdbssh-785a')) {
    Get-ADComputer -Identity $name -Properties Description, ManagedBy,
        LastLogonDate, OperatingSystem, IPv4Address |
        Select-Object Name, Description, ManagedBy, LastLogonDate, IPv4Address
}

Confirm RapidScale billing reduction: Contact RapidScale account team and confirm the Standard_D2s_v4 VM line and 3 concurrent connection fees are removed from the next invoice. Get it in writing.

Done when:

VM, NIC, disk, and backup collection all deleted
Billing reduction confirmed from RapidScale in writing
AZUREADSSOACC removed
Stale objects deleted
Message Max to close out the migration in Zendesk and update documentation

Escalation -- When to Call Max

Message Max on Slack immediately if any of these happen:

ldap_svc shows as Enabled in PRE-01
Any unknown machine identity cannot be confirmed in PRE-02
A domain admin disable fails in PRE-03
A user cannot connect to AVD after a pointer swap in PRE-05
Any pilot user fails validation in P1-02
Any AVD user cannot connect after their OU is excluded from sync
DNS shows 10.20.240.11 on any AVD session host in P4-02
Anything you are not sure about

When you message Max include: which task you are on (e.g. PRE-05, step 7), exactly what happened, and the timestamp. Screenshot if possible.

Key Contacts

Person	Role	Contact
Max Simon	Director of ITOps -- decision authority	Slack DM
RapidScale account team	MSP -- billing and DC VM questions	Via existing ticket channel

DC Migration -- Pacific Debt Relief -- March 2026

Prepared by Max Simon for Juan Munoz

Source: secops-pipeline/runbooks/dc-migration-juan.md | Last synced: 2026-03-23T08:24:26Z | Do not edit in Zendesk -- changes will be overwritten on next sync.