PowerSyncPro Migration Agent can convert a device from a workgroup to e.g. Entra Joined retaining the user profile. 

NOTE: ensure the version of the Windows 10 or 11 is Pro, so it can connect to your corporate network. Home editions do not allow this. As in any project, you should also consult your device management team and identity access teams to ensure the machine will meet device compliance policies (or have a exclusion) and will meet any conditional access requirements. Furthermore, you will need line of sight to AD or the internet to join the device to the appropriate target environment. If on AD this may require to be on the LAN.

There are some challenges with the process which this document will describe. Most of these will be managed in future versions of the migration agent to make this process much more streamlined.

NOTE: as a precaution create a backup administrative account on the device. You can also chose to do this in the runbook configuration but be sure to not remove the admin account for a number of days until you can verify the machine.

The challenges which this document will overcome are as follows.

1. we do not know the security identifier (SiD) of the local workgroup workstation user to create the translation mapping to perform permission updates of the registry and file system.
    
2. we do not know the intended target user for the migration, and more importantly target security identifier (SiD) of the user
    
3. PSP server currently scopes machines into batches using a list of computers it retrieves from a source AD environment, this evidently is not possible in a workgroup scenario in the current design on PSP server. But would will need a source AD for scoping and registration reasons.
    
4. The execution of runbooks and batches is coordinated by the workstation itself, Migration Agent only communicates with the PSP server to ascertain and download the runbooks which are allocated to it. So we need to import the translation table into the correct runbook directory on the local machine.
    
5. We only will migrate 1 user from the device (the user logged in), no others will be permissioned as we do know know the target accounts for all local profiles. (you can enhance the translation file with more entries if you wish however this article only covers 1 entry/user)

You will need to create an runbook for the migration to your desired target, and a batch. The source environment will need to be any AD environment PSP can connect to. We will need to put in a computer account into the source AD environment to act as a mechanism to scope & register the machine in PowerSyncPro and in the batch, the computer account will not be used for anything else and can be deleted after the migration, consider having a dedicated OU for them. It is important to ensure your runbook is configured to add permissions of the target account to places like the file system.

Once you have followed this process, it is simple to reproduce for any number of machines as you would have collected the core components which can be used on any machine. These are $DomainName and $RunbookGUIDs

Load administrative PowerShell on the workgroup machine, then collect the hostname of the computer with this code

$env:COMPUTERNAME

Now add this computer into the source Active Directory using ADUC

After the sync schedules have run in PowerSyncPro Server, ensure you can add the computer to the batch.

Whist on the machine with ADUC you will need the domain name where you have registered the computer, typically you can use this powershell:

(get-addomain).dnsroot

Or it can be at the top of ADUC.

Once you have done this, install PowerSyncPro on the workgroup workstation using the normal PSK and URL for your environment. 

NOTE: The workstation will not register as all the requirements for registration have not been met.

Return to the administrative PowerShell on the workgroup machine.

Put the domain name into a variable

$DomainName="what you collected earlier"

For example mine is

$DomainName="migsource.net"

Now, lets get the SiD of the current logged in user into a parameter. (this is the user migrating)

This is so we can identify which local user to migrate.

$LocalSiD=[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value

Alternatively, you can also perform a whoami /user and copy the value into the $LocalSiD parameter

Now we need the target user SID. Consider if you're migrating to AD or to Entra Joined.

For active directory the simplest method is to run the following command.

(get-aduser <username>).sid.value

Ensure you have the correct user, as choosing the wrong one will corrupt your workgroup machine.

You must now put this into the same powershell session where the $LocalSiD parameter is recorded.

$TargetSiD="results from your collection"

for example

$targetSiD="S-1-5-21-3501267240-3051813510-3927905062-1115"

When going Entra Joined, you will first need to collect the target user ObjectID from the Entra ID portal. Put it into the $objectid parameter on the workgroup workstation powershell you have open.

$objectid="d49043fc-c389-4652-9eb5-d9815a30a92c"

Now you need to convert this into a SID; you can use this powershell code:

function Convert-AzureAdObjectIdToSid {
    param (
        [Parameter(Mandatory = $true)]
        [String]$ObjectId
    )

    # Parse the Object ID into a GUID and convert it to a byte array
    $guidBytes = [Guid]::Parse($ObjectId).ToByteArray()

    # Initialize an array to hold the UInt32 values
    $uintArray = New-Object 'UInt32[]' 4

    # Copy the byte array into the UInt32 array
    [Buffer]::BlockCopy($guidBytes, 0, $uintArray, 0, 16)

    # Construct the SID string
    $sid = "S-1-12-1-$($uintArray[0])-$($uintArray[1])-$($uintArray[2])-$($uintArray[3])"

    return $sid
}

$targetsid = Convert-AzureAdObjectIdToSid -ObjectId $objectId
Write-Output $targetsid

Verify you have both SiDs and the domain name recorded using this script.

$targetsid
$LocalSiD
$DomainName

If you do not have these, then follow the process again.

Now create the translation file with the data you have collected, it will create the translation file in the directory where the powershell context is currently running. (this code is only applicable for 1 user)

$TranslationTableString = '{"' + $Localsid + '":"' + $targetsid +'"}'
$TranslationTableString | Out-File -FilePath "TranslationTable.json" -Encoding UTF8

We need to know the runbook ID your workstation is assigned to, so we can place the translation file into the correct place. On the PSP server, using SMSS, navigate to the dbo.Runbooks and copy the ID of the runbook

Back on the workgroup machine, now put this into the parameter $RunbookGUIDs. Double check the syntax here, as the variable must be in within quotes and an @ sign, as displayed below.

$RunbookGUIDs=@("23B89F9D-58E0-4EF4-DCE1-08DD145A48FE")

To complete the process, run download the following script.

Workgroup-Migrate.ps1

Then, when in the same directory as the script, run the following with administrative rights in the same powershell window.

.\Workgroup-Migrate.ps1 -DomainName $DomainName -ComputerName $env:COMPUTERNAME -RunbookGUIDs $RunbookGUIDs