I recently stumbled over this question from a MVP colleague: “I am planning a TFS to TFS integration project and we would like the console application as a service or using task scheduler, so it can run without a manual intervention to start it. However if we get prompts that is not an option”. Good question, but before we answer that, we will look at ask the other common question, namely “Should I use the MigrationConsole application or move to the new Shell?”
The migration console application is a powerful tool and a trusted friend when creating and testing a migration or synchronisation configuration, although the output, especially in verbose mode, can be an overload. All of our Getting Started hands-on-labs (HOL) are based on the Migration Console … whereby we could migrate the labs to using the new shell moving away from rolled up sleeves, console applications and console output that dazzles anyone’s mind.
… the new shell introduces a professional and user friendly administration, monitoring and configuration environment. See TFS Integration Platform – A new administrative era is upon us … for more information.
For the foreseeable future, however, the MigrationConsole will remain a friend and trusted companion as a testing and migration management tool. The choice whether to use console or the GUI or both user interface experience is yours … which is a good thing 🙂
XML Configuration Files … why does the title elude to doomed?
The topic that drives me insane at times and will be following me into the TFS integration Platform session on Thursday is the XML configuration file. The configuration files can range from simple, such as those we use in the Getting Started environment, to pages and pages of field and value mapping and other configuration. What I like and hate about XML configuration files, is the ease with which we can tweak the configuration, which at the same time can be the door to gloom and doom if you accidentally and completely unintentionally delete, insert or overwrite content. This is another opportunity to familiarize yourself with the new shell and explore its support for configuration management and schema, content and sanity enforcement.
So now can we look at how to schedule the MigrationConsole application …
The answer is simple, “Do not use task scheduler” and the MigrationConsole to create a migration environment that runs continuously. Instead you should consider select the Synchronization Services install option, which installs a windows service that hosts the migration sessions.
With the service the sync session will be started automatically when the machine restarts, so once again we have an opportunity to use the MigrationConsole utility to test the configuration, before we activate the auto-pilot.
Some facts on this synchronization service:
- It will pick up ALL active sessions.
- It will run these sessions on separate threads, concurrently.
- If a session group is configured to be “ContinuousAutomatic”, when the service resumes, e.g. from a machine reboot, it automatically starts that group
- If a session group is configured to be “ContinuousManual” and a sync cycle has not completed yet, when the service resumes, e.g. from a machine reboot, it automatically starts that group
See WorkFlowTypeEnum Configuration element is being deprecated for more information on the session group configuration options mentioned above.
On Thursday we will be hosting a TFS Integration Platform session to position the project, look at timelines, explore the current and future platform through demos and collaborate (chalktalk) on scenarios. Come back after Thursday for a report back on that session and most likely a list of interesting questions and answers that raised their head during the session.