В прошлый раз я написал целую инструкцию по поводу того, как обновить TFS до 2010, да на новой машине, да в новом домене. Однако, ряд вопросов остался не решённым, в частности не работали репорты и документы, кроме того, пользователи не имели доступа к Sharepoint порталу проектов.

Проблема оказалась в том, что “TFSConfig identities” по всей видимости не делает remap для пользователей, прописанных в Sharepoint и в Reporting Services.

А для “старых”-то пользователей там, безусловно, всё есть.

Мигрировать пользователей в Sharepoint можно, видимо, двумя способами:

1. С помощью команды “stadm –o migrateuser”. Делается это так:
   stsadm –o migrateuser –oldlogin LH\alexey.raga –newlogin INCITE\alexey.raga –ignoresidhistory
   Засада здесь в том, что stsadm не имеет опций для пакетного апдейта, поэтому каждого пользователя придётся мигрировать вручную. Сочувствую, если у Вас их сотни :)
   Ключ “ignoresidhistory” в документации (что я видел) описан очень невнятно, что он точно делает я не понял, но без него пользователь не мигрируется :)
   Для себя я решил, что поскольку это новый сервер с новой (чистой) инсталяцией Sharepoint, то использование этого ключа ничего лишнего ни дописать, ни удалить в правах пользователей не сможет. Ибо никаких прав для тех, кто там в –newlogin никогда задано не было.
2. Да просто пойти в табличку UserInfo и сделать UPDATE туда.

Я делал всё через stsadm. Во-первых потому, что кто его знает, что он ещё делает, кроме обновления вышеуказанной таблички (есть овнования полагать, что ничего), а во-вторых некоторые имена пользователей не совпадают (был OLD\vpupkin, стал NEW\vasya.pupkin), поэтому просто сменить имя домена недостаточно, всё равно приходится обрабатывать таких вручную.
Ну и, как я говорил, это у меня тестовая миграция на тестовые серверы, с тем, чтобы всё проверить и сказать “Да! Мы можем это сделать!”.

А вот с Reporting Services грустнее.
Там, в базе, в таблице Users, хранятся не только имена пользователей, но и их SIDы. Понятное дело, что SIDы у “новых” пользователей будут иные, так что просто обновить имена недостаточно.
Утилиты для такой миграции я не нашёл. Понятно, что можно написать, или можно сделать вручную, но как-то это не так.
Поэтому, если у каких-то пользователей были почему-то заданы какие-то права в RS (чего в случае нормальной эксплуатации TFS делать, в общем-то, не приходится обычно), то права проще всего перенастроить заново.

А, да. Ещё темплейт проекта TFS.

Мы используем темплейт SCRUM от http://scrumforteamsystem.com/Products, версию 2.1.
Возможности обновить темплейт на проекте нет.
Как вариант – создать новый проект с нужным темплейтом. Если делать так, то TFS даже спросит, сделать ли новый пустой проект, либо же сделать ветку от другого проекта.

Сделать ветку, наверное, самый правильный вариант: сохраняется всё состояние на момент “до миграции” в нетронутом виде.
Однако, возникает неудобство в том случае, если в исходном проекте уже используются ветки. То есть, если в исходном проекте есть ветка A и от неё сделана ветка B, то после ветвления в новый проект мы получим ветки A1 и B1, где A1 есть потомок A, в B1 – потомок B.
Получается, что если в исходном проекте ветки A и B можно сливать друг в друга (B потомок А), то в результирующем – уже нет (B1 – потомок B, а не A1).
Да, в TFS2010 есть такая замечательная штука, как reparenting для веток, но тогда мы теряем связь с реальностью исходным проектом..
Надо попробовать :)

Сделать пустой проект – тоже вариант. В том смысле, что можно просто переместить код из предыдущего проекта в новый. Move. И всё. Все зависимости сохранятся, все workitems, к которым были “привязаны” предыдущие checkins – тоже.

В любом случае, у ребят из http://scrumforteamsystem.com/Products пока ещё нет релиза 3-й версии темплейта, так что, ждём.
Я, кстати, спросил у них: “Раз уж вы делаете шаблон для SCRUM, то, наверное, вы и сами используете SCRUM, следовательно, можете приблизительно сказать, когда же?”
На что они ответили: “Да шаблон-то давно готов. Не готов guidance для него, а шаблон содержит ссылки на этот guidance. Так что, подождите немного”. Вопрос с датой обошли.
Вот, ждём.

Админы готовят “настоящие” серверы для “настоящей” миграции. А там уже и будем наступать на грабли :)