HOW TO: Migrate Symantec Encryption Desktop / PGP Desktop Users from one Active Directory Domain to Another


Article ID: 181490


Updated On:


Symantec Products




Migrating managed desktop users from one Active Directory domain to another is a straightforward process.  This HowTo shows an example of the process that needs to be followed.


  • PGP Universal Server 3.2.1 MP5
  • PGP Desktop 10.2 MP5 on Windows 7 SP1 x64
  • Both the source and destination Active Directories are on Windows Server 2003
  • Whole Disk Encryption only
  • SCKM (Server Client Key Mode) keys
  • SSO (Single Sign-On) disabled via Consumer Policy
  • Simple Bootguard authentication enabled via Consumer Policy
  • Automatic encryption of boot disk enabled via Consumer Policy
  • Directory Synchronization enabled on the Universal Server and LDAP enrolment is enabled.
  • Both the source and destination LDAP Directories are configured in Directory Synchronization and confirmed working.
  • Directory Synchronization is configured to check the AD servers for both AD domains.
  • Consumer Group Membership for the users being migrated is configured to check the appropriate AD security groups on both domains.

Source Configuration

  • Prior to the migration, a user with username user32 is enrolled on PGP Desktop.
  • The user is a member of an AD domain called pgptest.
  • The user belongs to an AD security group called pgptestgroup.
  • The user belongs to an Universal Server Consumer Policy called WDE-users.
  • The user's boot disk is encrypted.
  • The user has an SCKM format key.
  • The user's keyring is in the default location, ie, Documents\PGP folder on the C drive.
  • The user does not have local admin rights on their machine.

Destination Configuration

  • The user32 user is a member of the AD domain called pwpgp.
  • The user belongs to an AD security group called pwpgpgroup.
  • The password for user32 on the pwpgp domain is different to the one for the user32 user on the source AD domain.

Migration Process

  • User32 is added to the pwpgp domain via the Properties page of Computer in Windows 7.  An administrator needs to do this because user32 has insufficient rights.
  • After user32 has joined the pwpgp domain, Windows prompts the user to reboot.
  • User32's bootguard passphrase is still valid.
  • User32 logs into Windows using the PWPGP\user32 account.
  • Windows creates a new profile in the C:\Users\user32.PWPGP folder.
  • Prior to enrolment, a local administrator copies user32's keyring files from C:\Users\user32\Documents\PGP to C:\Users\user32.PWPGP\Documents\PGP
  • User32 is prompted to enrol and enters their pwpgp credentials.
  • Universal Server does an LDAP lookup on the AD server hosting the pwpgp domain and finds user32.
  • PWPGP\user32 is in the AD security group pwpgpgroup which is linked to the WDE-users Consumer Policy, ie, no change of policy.
  • In the key setup assistant user32 chooses the option that says they have existing keys and points to the folder C:\Users\user32.PWPGP\Documents\PGP
  • The PGP Whole Disk Encryption Assistant states that the boot drive will be encrypted. User32 continues through the Assistant as normal by clicking the Next button.
  • User32 chooses a WDE passphrase.
  • The WDE Assistant starts to encrypt the drive but completes the task almost immediately.  It does not re-encrypt the drive.
  • The User Access list of WDE users shows two users: PGPTEST\user32 and PWPGP\user32.
  • When user32 reboots they use their new WDE passphrase at bootguard.
  • The User, Computer and Device records on Universal Server appear the same as when user32 was in the pgptest AD domain.

Note that changing AD domain is not the same as changing the DNS domain.

If after migrating to the new AD domain the user cannot enrol, this is probably because of configuration errors with Directory Synchronization and/or the LDAP settings under Consumer Group Membership.