What do the parameters and data stored in the vmover.ini mean? (4265754)

The vmover.ini has a lot of information stored in it when created.  What do the parameters and data stored in the vmover.ini mean?

For further detailed information, please see the attached document below.


Vmover.ini consists of several sections. The contents of each section is described below.

[dmw7] - This is a static header.  In this example it says that the file is in format of Migration Manager 7.x.

[Options] - This section contains parameters you specify in user interface. For example:

[Options]
FileSystem=Yes
Shares=Yes
LocalGroups=Yes
UserPrivileges=Yes
Printers=Yes
IIS=Yes
Registry=Yes
Profiles=Yes
Services=Yes
ScheduledTasks=Yes

DCOM=Yes
COMPlus=Yes
Details for DCOM and COM+ Processing can be found here
DCOM & COM+ Processing details
RoamingProfiles=Yes
InstallProfilesAgent=Yes
Clone=Yes
CleanUp=No
Undo=No
AutoRemove=No
MaxErrors=10
LogMask=15
LogFile=VMover.log
StateFile=VMover.txt
Version=400
MaxCriticalErrors=1
MaxRegUsage=95
ProcessRegGroupOwner=No
UpdateStateSec=1
SetArchiveBit=No
SharesExtendedLogging=Yes

Parameter meanings:

UpdateStateSec=1 Statistic updating frequency(sec.). Time delay between log messages from share processing.

MaxRegUsage=95  Registry processing quota usage https://support.microsoft.com/kb/124594/EN-US 'Understanding and configuring Registry Size Limit (RSL)'

AutoRemove=No For legacy RUM - removing agent after processing SharesExtendedLogging=No Extended log for shares processing. Will dump share SD to the log file.

ProcessRegGroupOwner=No - group processing which were set in owner group in Security Descriptor, while registry processing. (yes=process no=don't process).  The Owner bit of the ACL is getting changed. In most cases it is a non issue as the "Administrators" groups owns almost all of the Registry objects within the HKLM, and a User Object Owns HKCU (NTUser.dat) at the top most level. I know of only a few cases where the user owns something within the registry (HKLM\SW\MS\WinNT\CV\ProfileList\S-1-15-xxx) But this is it.  So the option is really a mute point. You would have to migrate the local objects for it to even come into play.

SetArchiveBit=No - don't set archived bit attribute  for files and folders after filesystem processing.

The last section with an empty header ([ ]) contains the source and target object mapping.

The first two lines in this section are source and target domain names in the following format:

Then comes a list of objects in format:

For first object of each type QMM stores full object RID.  For next objects of the same type - difference with previous value.

Note that objects are not sorted by type.

Not all columns are populated.  UPNs are not stored at all.  Contacts dont have sAMAccountName.  If target name is the same as source one then its skipped.

Multiple sections for the same source and target domains are supported.

Consider the following example:


ARIES;S-1-5-21-3615896700-3591135701-218077433;aries.local
LIBRA;S-1-5-21-3773081184-434920676-2815480428;libra.local
2265;JSmith;1314;;;;1
1;JJohnson;1320;;;;1
4;DDavis;1322;;;;1
1;RMiller;1316;;;;1
2;JMoore;1317;;;;1
1;TTaylor;1315;;;;1
2275;group1;1313;;;;2
7;group2;1332;;;;2
9;RWilliams;1321;;;;1
1;MJones;1319;;;;1
1;WBrown;1318;;;;1
In this example:

TTaylors RID is 2274
RWilliams RID is 2283.
WBrowns RID is 2285

Please see solution SOL37936 - How to enable extended logging for Vmover in DMW/QMM when processing resources? -https://support.quest.com/SUPPORT/index?page=solution&id=SOL37936