If you won’t translate RDS profiles; I will!

Out of pure frustration with the fact that the Active Directory Migration Tool (ADMT) is unable (unwilling is my guess) to do security translation for users’ Remote Desktop Services (RDS) roaming profiles, I decided to take matters into my own hands and created the script below. It is not very refined just now, but I have a lot of ideas for future versions. In the meantime, if you can use it for something; great!

# TranslateRDSProfiles.ps1
# Morgan Simonsen
# http://morgansimonsen.wordpress.com
#
# Script to translate a user profile belonging to a migrated user.
# Primarily intended to solve the problem with ADMT not translating
# Remote Desktop Service roaming profiles.
#
# Version: 1.0 (13.02.2012)
#     Initial version.

#----------------------------------
# User changeable strings
# Only edit in this section!
#
# Root of folder or sharing storing the profiles
$RDSProfileRootDirectory = "Z:" # Include trailing backslash
# NetBIOS Name of source domain; the domain the user was migrated from
$SourceNBTDomainName = "DOMAIN_1" # Include trailing backslash
# NetBIOS Name of target domain; the domain the user was migrated to
$TargetNBTDomainName = "DDS" # Include trailing backslash
# DNS name of target domain
$TargetDNSDomainName = "dds.intern"
# FQDN of Domain Controller in target domain
$TargetDomainDC = "ddsdc1.dds.intern"
# Location of subinacl.exe
$SUBINACLLocation = "C:Program Files (x86)Windows Resource KitsToolssubinacl.exe"
# Location of echoArgs.exe (not actually used by the script)
$echoArgs = ($PSHome+"ModulesPscxAppsechoArgs.exe")
#----------------------------------

Get-ChildItem $RDSProfileRootDirectory | ForEach `
{
    Write-Host ("Processing folder: "+$_.name)
    If (Get-QADUser ($TargetNBTDomainName+$_.name) -service $TargetDomainDC)
    {
        $user = Get-QADUser ($TargetNBTDomainName+$_.name) -service $TargetDomainDC
        Write-Host (" Found matching user: "+$user.Userprincipalname)

        If ( (Test-Path ($_.FullName+"NTUSER.DAT")) -or (Test-Path ($_.FullName+"NTUSER.MAN")) )
        {
            Write-Host (" Found user registry hive: "+($_.FullName+"NTUSER.DAT"))
            Write-Host (" Updating permissions...")
            $entireprofile = ($_.FullName+"*.*")
            $completeusername = ($TargetNBTDomainName+$user.samaccountname)
            Write-Host (" SubInACL.exe File Output:")
            & $SUBINACLLocation /noverbose /subdirectories $entireprofile /grant="$completeusername=f" /setowner=$completeusername  > $null
            Write-Host (" SubInACL.exe Registry Output:")
            reg.exe load ("HKU"+$_.Name) ($_.FullName+"NTUSER.DAT") > $null
            $regkey = ("HKEY_USERS"+$_.Name)
            & $SUBINACLLocation /noverbose /subkeyreg $regkey /grant="$completeusername=f"  > $null
            reg.exe unload ("HKU"+$_.Name) > $null
        }
    }
    Else
    {
        Write-Host " Cannot find user in domain that matches folder name."
        Write-Host " Continuing with next user."
    }
}

	

Join the Conversation

6 Comments

  1. Hello,

    Glad I found this site. We have numerous Terminal Servers we in a current major migration I’m working on. One question on this script: Do you run this after the server is migrated or before the server migration?

    Any other issues to be aware of? Thanks so much for posting this!!

    Derek

    1. Hello Derek

      This script is not dependent on whether your terminal servers have been migrated or not. It works by looking at the root of the shared folder containing all your TS profiles. It then loops through them all replacing any occurence of “old domain” with “new domain”, using the same username. The effect being that if user1 had access to the profile; user1 now has the equivalent access. The only requirement here is that there is a trust between the old and new domains and that the server you are running the script from is able to contact a domain controller in both domains. Please not that this is something I whipped together late one night whilst very frustrated with ADMT! Although it will correctly translate your profiles, it could certainly need some more work to make it more generic. Anyway, hope it can help you some way!

      Regards
      Morgan

  2. Hi Morgan,

    I am currently in the process of migration on a new domain with ADMT and I am facing the RDS profiles translation problem right now.

    I read your script and I have one interrogation:
    In your script, you replace the ntfs rights and the users right in the registry;
    Is there not anything else that need to be modified for a profile to work on an other user? Some file content or registry keys/values ?

    Thanks for your help!

    1. Hello Eric

      No, changing the NTFS rights in the file system and the Registry rights inside the user’s hive is all that is required. I also have another post on this blog that goes into a bit more detail for how a profile can be transferred from one user to another, but the basic steps are the same.

      Good Luck!

      Morgan

  3. Do you have this script to test it for one user for testing?

Leave a comment

Your email address will not be published. Required fields are marked *