Context & Question

When you wish to trigger your migrations, for example kick-start a migration session at high-noon or mid-night, you currently need to consider using the MigrationConsole utility.  One of the options is to pass a configuration file, however, the automated “silent” trigger falls flat as the MigrationConsole recognizes that a configuration with the same name exists in the database and prompts someone to press D(iscard) to use the cached version.

Hmmm, now what?

MigrationConsole Utility – Parameter Help

If we run the MigrationConsole with the /h or /help or /? parameter, we visit the following code, which talks about SessionGroupUniqueId and SessionUniqueId:

   1: private static void PrintHelp()
   2:         {
   3:             Console.WriteLine("Usage:");
   4:             Console.WriteLine("\tMigrationConsole.exe [configurationFileName [minutesTimeout]] [/IgnoreUnmappedPath]");
   5:             Console.WriteLine("\tMigrationConsole.exe StartStandaloneSession SessionGroupUniqueId SessionUniqueId [/IgnoreUnmappedPath]");
   6:             Console.WriteLine("\tMigrationConsole.exe MergeStandaloneSession SessionGroupUniqueId SessionUniqueId [/IgnoreUnmappedPath]");
   7:         }

The easy and safe backdoor to the GUIDs

Other than digging into the database and figuring out the schema, Holger S. submitted a great and easy way to get the information needed:

  1. In the TFS Integration shell export the configuration file or alternatively view the XML.
  2. You will find one SessionGroupGUID and one of more SessionUniqueId. See the post What is the EnableBypassRuleDataSubmission in the Configuration File for an example of a typical configuration file.
  3. Jot down the GUIDs and voilà, you have the identifiers.
  4. Now launch the MigrationConsole utility at a specific time or when a specific event occurs, passing StartStandaloneSession and the two IDs you have jotted down in step 3.
  5. The migration should now start without any further interruption.

Thanks Holger!