Pages

Wednesday, April 28, 2010

Deconstructing the Quest Resource Processing Configuration File (vmover.ini)


    For anyone that has worked with the Quest Migration Manager to perform Microsoft Active Directory Domain migrations, you find that one of the most critical components is the Resource Processing tasks. In a migration, one has the original environment (Source) and the destination environment (target). A migration consists of moving source users, groups, workstations, servers, applications, group policies, scripts, etc… to the target as per migration requirements. Resource Processing is, in simple terms, the process of adding access for target user and groups (security principals) to source computers and applications (resources). Additionally, with Quest, one has the option to update the identities of services, scheduled tasks, etc...
    How does Quest pull off such a monumental task of updating all the resources? For computers, it is all based on a small binary (vmover.exe) and a configuration file – commonly known as vmover.ini. Let us now dive in and examine the INI configuration file.
Below is the top portion of the INI file. For the most part it is self explanatory. It is a list of resource processing options.
FileSystem=Yes DCOM=Yes LogFile=VMover.log
Shares=Yes COMPlus=Yes StateFile=VMover.txt
LocalGroups=Yes RoamingProfiles=Yes Version=400
UserPrivileges=Yes InstallProfilesAgent=Yes MaxCriticalErrors=1
Printers=Yes Clone=Yes MaxRegUsage=95
IIS=Yes CleanUp=No ProcessRegGroupOwner=No
Registry=Yes Undo=No UpdateStateSec=1
Profiles=Yes AutoRemove=No SetArchiveBit=No
Services=Yes MaxErrors=10 SharesExtendedLogging=Yes
ScheduledTasks=Yes LogMask=15  

This is where it gets interesting. Following the options section, there are 1 or more domain pair sections. These sections contain a mapping of security principals between source and target. If you are unfamiliar with the concept of a Security Identifier or SID, I suggest you read 'How to understand the anatomy of security identifiers'. Everything in the domain pair sections is directly correlated to the SID. There are several great tools to help find the SID of objects such as PSGetSID from PSTools. For the sake of this post we only need to know two things about the SID - the domain Identifier and the Relative Identifier (RID). Given the SID 'S-1-5-21-715486182-2557611466-615292504-1012' the Domain Identifier would be 'S-1-5-21-715486182-2557611466-615292504' and the RID would be '1012'.

The first 3 lines of a domain pair section are as follows

[]
SourceDomainName;S-1-5-21-SourceDomainIdentifier;SourceDomainDNSName
TargetDomainName;S-1-5-21-TagertDomainIdentifier;TargetDomainDNSName

 

Example Contoso migrating to Fabrikam:

[]
CONTOSO;S-1-5-21-715486182-2557611466-615292504;constoso.com
FABRIKAM;S-1-5-21-1960408961-3247738952-4268959921;fabrikam.com
The next line(s) in the configuration file define the source and target object mapping.
SourceRID;SourcesAMAccountName;TargetRID;TargetsAMAccountName;;;Object Type

 

Object Types Defined:

Object Type Description Series
1 User A
2 Global Security Group B
3 Global Distribution Group B
4 Domain Local Security Group B
5 Domain Local Distribution Group B
6 Universal Security Group B
7 Universal Distribution Group B
8 Computer B

 

Rules for the object mapping section:

  1. All object mapping entries are sorted by SourceRID (Ascending)
  2. The SourceRID value for the first object mapping entry in each series uses the actual SourceRID value.
  3. Subsequent object mapping entries in each series uses a calculated offset from the previous entry in the series for the SourceRID value.
  4. There are only 2 series of object mappings.
  5. The TargetsAMAccountName may be omitted if it is the same as the sourcesAMAccountName.

Example for a single user:

Scenario Information
SourceRID SourcesAMAccountName TargetRID TargetsAMAccountName Object Type
1012 Jdoe 23127 john.doe User


Objet Mapping Entries Rules Applied - Notes
1012;jdoe;23127;john.doe;;;1 2- Source RID for the user or 'A' Series

So far, things are making sense. However, it gets tricky when you add more than 1 object mapping entry.

Example for multiple users:

Scenario Information (Sorted by SourceRID)
SourceRID SourcesAMAccountName TargetRID TargetsAMAccountName Object Type
1012 Jdoe 23127 john.doe User
1050 Ssmith 10345 Sally.smith User
1053 lskywalker 5038 lskywalker User


Objet Mapping Entries Rules Applied - Notes
1012;jdoe;23127;john.doe;;;1 1- All Source RIDS Sorted
2- Source RID for the user or 'A' Series
38;ssmith;10345;sally.smith;;;1 3- Source RID is current RID less the previous RID (1050-1012=38)
3;lskywalker;5038;;;;1 3- Source RID (1053-1050)
5- Target sAMAccountName is omitted


Example for multiple object types:

Scenario Information (Sorted by SourceRID)
SourceRID SourceSAM TargetRID TargetSAM Object Type
1012 Jdoe 23127 john.doe User
1015 Accounting 48885 Accounting Global Sec. Group
1038 ORION$ 45566 ORION$ Computer
1050 Ssmith 10345 Sally.smith User
1052 AllEmps 123445 AllEmployees Global Dist. Group
1053 lskywalker 5038 lskywalker User
2034 Sales 44755 Sales Local Sec. Group
3123 AppAccess 476665 AppAccess Universal Sec. Group


Objet Mapping Entries Rules Applied - Notes
1012;jdoe;23127;john.doe;;;1 2- Source RID for the user or 'A' Series
1015;Accounting;48885;;;;2 2- Source RID for the user or 'B' Series
5- Target sAMAccountName is omitted
23;ORION$;45566;;;;8 3- (B) Source RID is current RID less the previous RID (1038-1015=23)
38;ssmith;10345;sally.smith;;;1 3- (A) Source RID is current RID less the previous RID (1050-1012=38)
14;AllEmps;123445;AllEmployees;;;3 3- (B) Source RID is current RID less the previous RID (1052-1038=14)
3;lskywalker;5038;;;;1 3- (A) Source RID (1053-1050)
5- Target sAMAccountName is omitted
982;Sales;44755;;;;4 3- (B) Source RID is current RID less the previous RID (2034-1052=982)
5- Target sAMAccountName is omitted
1098;AppAccess;476665;;;;6 3- (B) Source RID is current RID less the previous RID (3123-2034=1098)
5- Target sAMAccountName is omitted

Domain Section Example Completed:

[]
CONTOSO;S-1-5-21-715486182-2557611466-615292504;constoso.com
FABRIKAM;S-1-5-21-1960408961-3247738952-4268959921;fabrikam.com
1012;jdoe;23127;john.doe;;;1
1015;Accounting;48885;;;;2
23;ORION$;45566;;;;8
38;ssmith;10345;sally.smith;;;1
14;AllEmps;123445;AllEmployees;;;3
3;lskywalker;5038;;;;1
982;Sales;44755;;;;4
1098;AppAccess;476665;;;;6
With this information, you have the ability to generate your own INI configuration files. This gives you the ability to automate and fine-tune what vmover is actually doing in your environment.

2 comments:

Mac said...

This is money... still applies in 8.14 -- doing 20,000 users / groups with CIFS shares on source domain. VMOVER works great, and to be able to fine tune as described here, priceless. I wrote PowerShell that can do all the work and create the INI just from the QMM PROJECT ADAM database. Thanks for reposting

https://support.quest.com/migration-manager-for-ad/kb/56091

Jason Bell said...

Wow - glad this post helped you out. Awesome to hear that it is still relevant.