Интересный и даже полезный инструмент для неудомимых TFS-миграторов: http://tfsintegration.codeplex.com/
Целая "платформа", позволяющая перекачивать и даже синхронизировать по-разному и Source Code и Workitems между TFS-серверами Поддерживаются 2008 и 2010, причём можно и 2008-2010 делать.
На сегодняшний день это единственный способ перенести проект из одной Collection в другую, который я знаю.
Или вообще добавить существующий проект в существующую коллекцию.

В прошлый раз я написал целую инструкцию по поводу того, как обновить 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. Так что, подождите немного”. Вопрос с датой обошли.
Вот, ждём.

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

Взялся обновлять TFS, пока на тестовом сервере, чтобы проверить, что всё будет работать.

Я уже писал, что сама по себе установка TFS теперь – дело очень простое, оно даже умеет работать без Sharepoint Services, а если всё же хочется, то умеет установить и настроить их само.

Обновление с предыдущих версий TFS – тоже, в принципе, не проблема, теперь это можно сделать прямо в процессе установки (хотя предварительно и сделать кое-что руками).

Но в нашем случае обновление – это комбинация сразу трёх задач:

1. Переезд на новый (физический) сервер;
2. Переезд в новый домен;
3. Собственно, обновление TFS.

Оказалось, что и это сделать не так страшно, как оно казалось.

Итак, для этого потребовалось:

1. Сделать backup всех баз данных с TFS2008, включая базы ReportingService и Sharepoint. Для Reporting Services, похоже, даже encryption key не надо бекапить и потом восстанавливать;
2. Установить то, что требуется для TFS2010 на новый сервер, а именно (пошаговая инструкция, куда ткнуть и что написать есть в прилагаемом TFSInstall.chm, очень советую смотреть туда):
• SQL Server Standard 2008 SP1 (да, оно больше не работает с SQL 2005. Можно даже Express-версию, если но там нет Analysis Services, а без него репорты не будут работать, но если они не нужны – то и отлично, можно вообще Reporting Services не ставить);
• Sharepoint Services 3.0 SP2 (да, оно больше не работает с 2.0. Можно обойтись и без Sharepoint, и даже Web Access работать будет. Чего не будет, не помню, смотрите прямо в инсталлере, там всё написано. Ценители могут воспользоваться MS Sharepoint Server 2007, тоже поддерживается).
  Опять отсылаю к TFSInstall.chm, там сказано, какой порт указать для административного портала;
• IIS, понятное дело.
3. Восстановить бекапы из пункта 1) на новом сервере;
4. Если устанавливали Reporting Services, то пойти в Configure Reporting Services и “починить” там всё:
• Выбрать только что восстановленную базу данных на вкладке Database;
• На вкладке Report Manage URL задать имя виртуального каталога “Reports” и нажать Apply. Если кнопка задизейблена – попечатайте что-нибудь в текстовом поле, чтобы она стала доступной :)
• На вкладке Web Service URL задать имя виртуального каталога “ReportServer”, тоже Apply его на всякий случай.
• На вкладке про encryption key удалить этот самый encryption key.
5. Если ставили Sharepoint Services, то нужно подключить предыдущие коллекции сайтов. Для этого:
• Пойти в админилку Sharepoint и убедиться, что там есть web site для Вашего http://<servername>:80. Если такового нет – тогда создать (спасибо Мише, подсказал в нужном направлении). Site Collection создавать не надо.
• Подключить старую базу данных (от имени администратора):
  stsadm -o addcontentdb -url http://<ServerName>/sites -databasename <Wss_ContentDBName> -databaseserver <server\instance>
• Дать пользователю TFSSETUP, от имени которого вы и делаете всё это, немного прав (от имени администратора):
  stsadm -o addpermissionpolicy -url http://<ServerName> -userlogin <TFSSETUP user> -permissionlevel "full control"
• iisreset;
6. Запустить, наконец-то, инсталяцию TFS. В списке типов инсталяции выбрать Upgrade, а там дальше всё будет прозрачно совсем. Только пройдитесь по всем вкладочкам визарда внимательно, там кое-где надо будет логин/пароль для TFSSERVICE указать, например… Сложного ничего нет.
   Вот тут есть в картинках.
7. Непосредственно перед установкой оно попробует произвести проверку “всё ли правильно сконфигурировано”. У меня показывал два красных креста – на Reporting Services и на Sharepoint. Выяснилось, что я забыл в первом случае encryption key удалить, а во втором – уже не помню что.
   В общем, перед началом обновления всё должно быть зелёным. Ну, в крайнем случае жёлтеньким :)
8. Пойти пообедать. Попить чаю с баранками, я не знаю. Поскольку данные он будет перегонять физически из всего того немереного количества баз данных, что были сбекаплены, в две всего, скорость напрямую зависит от скорости сервера и винтов. Говорят, что на 50-гигабайтную базу уходит где-то часа три. У меня столько не было, но я и обедать ходил. Вернулся – готово.
9. Не спешить радоваться ;)
10. Слазать в TFS Admin Console и убедиться, что URL’ы все нормально там выставлены. Апгрейд на этом закончен.
11. Переехать пользователей TFS со старого домена в новый (если надо, мне – надо). Это чтобы все права, история, команды и т.д продолжали вестись. Чтобы Вася Пупкин как был Васей, так и остался Пупкиным.
    Для этого:
• Запустить командную строку от имени администратора, пойти в каталог TFS, где-то в Program Files, там в каталог Tools.
• Выполнить команду:
  TFSConfig identities /change /fromdomain:<FromDomainName> /todomain:<NewDomainName>
  Эта команда “переведёт” всех пользователей TFS из “старого” домена в “новый”. То есть, LH\alexey.raga станет INCITE\alexey.raga, например.
  НО: только для тех пользователей, которые есть в “новом” домене. То есть, имена должны совпадать.
  Если нужно перевести не всех, а кого-то одного, например, то там есть и такие ключики, смотреть здесь: http://msdn.microsoft.com/en-us/library/ms404883.aspx#MoveAccounts
  У меня, кстати, все перевелись, кроме меня самого. Не знаю почему, все операции я делал под TFSSETUP, то есть, просто совпадение :) Но вот именно мой пользователь не хочет мигрироваться.
• Там же выполнить:
  TFSConfig Accounts /change /AccountType:ApplicationTier /account:<TFSSERVICE account> /password:<Password>
  Это потому, что TFSSERVICE-то теперь другой у Вас.
• Если ставили Reporting Services, то там же выполнить:
  TFSConfig Accounts /change /AccountType:ReportingDataSource /account:<AccountName> /password:<Password>
• Если ставили прокси (а его кто-то ставит?), то то же самое, но для /AccountType:Proxy и его аккаунта.
12. Пойти в админилку Sharepoint, пробежаться по Site Collections и посмотреть, чтобы Primary и Secondary админы были правильными пользователями, а не старыми, из старого домена. У меня почему-то было так.

После этого, в принципе, TFS должен работать. Вы можете делать чекауты, чекины, история вся хранится, словом, работать можно.

Какие проблемы.

1. У меня пока не работают репорты. Но я даже ещё не смотрел, в чём там дело, отчего-то папка с репортами вообще недоступна в Team Explorer. Может что-то с правами, может от того, что темплейт у проекта был нестандартный, не майкрософтовский.
2. Никто из разработчиков не имеет прав на Sharepoint Portal проекта. В Team Explorer нет доступа в папку Documents. Это точно что-то с правами.

С этим разберусь в следующий раз и отпишусь.

P.S. Честно говоря, я не понимаю.. Если у TFS2010 и так есть web access, то зачем ему sharepoint сдался?!…

Вышли релиз-кандидаты Visual Studio 2010 и TFS 2010. Поставил, смотрю…

Про “студию” могу сказать пока только то, что работать стала существенно быстрее, чем прошлая Beta2. Предыдущая версия своей производительностью, признаться, наводила на мысль о том, не пошло ли использование WPF в ущерб. Однако, теперь этого ощущения нет. Работает не медленнее 2008-й – это точно.

А вот TFS стоит отметить отдельно. Устанавливать его теперь гораздо приятнее, чем его 2008-го предка, с которым ещё намучаешься устанавливая, да и немало (помню, как в Алкателе сидел до 10 вечера, выполняя установочные инструкции по шагам).
Установка же 2010-й версии проста и даже примитивна. Два этапа: собственно, установка, которая занимает всего пару минут, и конфигурация в визарде, что тоже занимает примерно столько же времени.
Сразу скажу, что я пробовал только Basic конфигурацию (там есть ещё пара вариантов), так как устанавливал на локальную машину. Приятно, что в Basic-варианте работает и билд сервис, и даже web access, и при этом ему не нужно ничего, что начинается с “Sharepoint”. И работает даже с SQL Server Express.
Поставил – и работай. Просто, удобно, как и хотелось.

Много всяких интересных штук там, в TFS 2010, но я хочу отметить две:

1. Билд-сервисы:
• На одной машине можно без хаков иметь несколько build-агентов, что не может не радовать;
• Билд-скрипт, который был раньше MSBuild-проектом, теперь представляет собой Workflow. Редактировать его в Workflow-дизайнере, добавлять и даже создавать свои собственные задачи теперь гораздо удобнее и приятнее.
  
2. Gated Check-Ins.
   Здесь я, признаться, в замешательстве. Поясню: Gated check-in – это когда разработчик делает check-in в репозиторий, при этом выполняется build, если хотите – прогон unit test’ов, и если что-то пошло не так, то внесённое изменение отвергается и не попадает в систему контроля версий. А если всё прошло как надо, то изменение попадает в соурс контрол, конечно. Соответственно, в соурс контроле мы имеем ветку, которая никогда не будет сломана и всегда будет как минимум компилироваться, а как максимум – зависит от вашего покрытия юнит тестами.

Так вот, Gated Check-Ins работают в TFS2010 замечательно, билд никогда не ломается и всё такое. Но есть у меня одно недопонимание, одна фича, которую, как я надеялся, исправят после Beta2, но она осталась…

Выглядит это так:

1. Я изменяю код и делаю check-in.
2. Поскольку мои изменения, пока не прошла валидация, де-факто не попадают в репозиторий, я всё ещё вижу изменённые файлы как checked-out.
3. Билд и юнит-тесты проходят успешно, код попадает в репозиторий.
4. Здесь я ожидаю, что файлы станут checked-in, если я их больше не трогал. Онако, этого не происходит.
5. Я пытаюсь делать Get Latest Version или Check In снова, не важно что из этого.
6. TFS, внимание, заявляет, что у меня локально присутствует версия файла #7, а в репозитории она уже #9 (очевидно, #8-это мой промежуточный check-in, #9 – финальный после валидации).
7. Мне необходимо сделать merge версий 7 и 9! Хотя, ежу понятно, что они одинаковы, ибо это изменение делал я, только я и никто больше!
8. Я признаю, что merge в VS2010 и в VS2008 – вещи очень и очень разные в пользу VS2010, там надо нажать ровно одну кнопку, даже никаких всплывающих окон, но сам факт… И так, делаю auto merge, всё проходит отлично, так как нет разницы, но файлы-то остаются в состоянии checked out!
9. Я должен снова сделать check-in, и тогда оно мне скажет: изменений нет. И пометит файлы как checked in, чего мне и хотелось.

Звучит, возможно, сложнее, чем есть на деле, но вы попробуйте :)

Я понимаю, что это, наверное, достаточно сложно – отследить, что я действительно не менял файлов пока шла валидация, поэтому нельзя просто сделать их checked out когда она закончена.. Ну, вдруг я менял.
Я понимаю, что в общем случае при таком вот “отложенном” check-in может возникнуть automerge от нескольких разработчиков и в этом случае нужно просить делать merge…
Но я не понимаю, разве нельзя было ввести ещё один статус “в процессе валидации" для файлов в солюшн эксплорере? И “сбрасывать” его обратно в “checked out” если я меняю эти файлы? Пусть даже и на основе read-only атрибута в файловой системе?
Разве нельзя отследить, что во всём этом процессе вот для этого конкретного файла не было никакого автоматического merge’а сделано на уровне TFS? И не просить меня делать merge если файл не меняли ни локально, ни в TFS?
Во всех остальных случаях – спрашивайте, пожалуйста, я только рад буду и буду делать merge с удовольствием!

Короче, тут можно, конечно задать вопрос “Вам шашечки или ехать?”, и утверждать, что целостность билда важнее всех этих мелких неудобств.. Но ведь хочется, чтобы и их не было… :)

В общем, пока как-то так…

Мы, как и многие-многие команды, используем TFS для организации командной работы. Штука-то удобная. Но речь не об этом. А о том, что проект в TFS предполагает использование какой-либо методологии. Чаще всего это MS Agile, реже люди используют CMMI (эти два типа доступны в TFS сразу после установки), реже люди устанавливают и используют что-то свое.

Опять же, чаще всего выбор какой-либо из двух этих методологий (CMMI или Agile) производится неосознанно и только лишь потому, что нужно же что-то выбрать, иначе проект создать не получится. Поэтому часто бывает так, что следование методологии заканчивается на требовании каждый checkin привязывать к воркайтему. Получается так потому, что обе эти методологии, если ими пользоваться “как положено”, достаточно затратны, сами эти методологии недосточно “прозрачны” и, как следствие, отдача от них, в общем-то не слишком и велика.

Затратны потому, что слишком велико количество ролей в команде, слишком формализованы их взаимоотношения, на поддержание “курса” требуется ощутимое время.

Непрозрачны потому, что, с точки зрения разработчика плюсов практически не видно, его лишь заставляют следовать определенному набору правил, а почему и зачем..
Со стороны менеджера (того, который настоящий менеджер, а не того, который непонятный PM), в общем-то, тоже не ахти. В каком состоянии продукт прямо сейчас? Что нужно для того, чтобы успешно закончить проект? Сколько времени это займет? Непонятно. Нет, конечно, некоторое понимание есть…
Отсюда получается, что единственный человек, который понимает, что происходит – это тот самый непонятный PM, который ведет этот проект в рамках этой методологии.

Естественно, я утрирую – конечно, существуют организации, в которых все, как один, пронизаны духом той или иной методологии, прекрасно взаимодействуют друг с другом, отлично понимают, что делают и зачем. В этом случае и отдача есть. Но, думаю, утрирую я не сильно, ибо и мировой опыт применения CMMI, да и просто здравый смысл показывает, что таких команд мало.

Поэтому для очередного проекта (продукта, состоящего из нескольких проектов), было решено использовать что-нибудь очень простое, эффективное и максимально прозрачное.

Этим “чем-то” оказался Scrum. Scrum настолько прост, чтобы вся методология уместилась на одном листе А4, затраты на его поддержание выливаются в 10-15 минут в день, а прозрачность такова, что в любой момент любой (даже совершенно незнакомый с методологией) человек может увидеть и понять, в каком состоянии находится проект сейчас, что уже сделано, что еще будет сделано и сколько времени еще понадобится для того, чтобы получить продукт с нужной функциональностью.

При этом вся эта информаци доступна для понимания и дивелоперов, и менеджеров, и кастомеров. Всё гениальное просто, впрочем, поэтому Scrum и пользуется такой популярностью.

Впрочем, Scrum – это лишь методология, её еще необходимо связать с реальностью рабочим окружением. Да, он настолько прост, что достаточно Excel для полноценной его поддержки, но работать с TFS (удобно же!) и еще и с Excel параллельно тоже не хотелось (хотя недели три и это давало свои ощутимые плоды).

Для осуществления этой связи мы перебрали несколько шаблонов Scrum для TFS. В результате я нашел шаблон, который отлично соответствует как букве методологии (нехитрая терминология, жизненный цикл), так и ее духу (простота и прозрачность). Взять его можно вот здесь: http://www.scrumforteamsystem.com/en/default.aspx

Примечательно, один из наших тимлидов, который работал на “пилотном” для нас проекте Scrum, очень сильно проникся выгодой его применения и даже купил книжку от создателя этой методологии о том, как выгодно применять ее в enterprise-среде, когда увидел портрет при инсталляции темплейта закричал: “О! Это он! Это он!” :) Оказалось, что в создании этого шаблона автор методологии принимал участие лично :)

Конечно, шаблон “умеет” гораздо побольше Excel-проектика, особенно в части отчетности. Выполнен шаблон тоже очень качественно в части того, что из себя представляют воркайтемы, как они выглядят, какие имеют поля. Портал проекта тоже на высоте.

Что важно для меня как для дивелопера – наряду с тем, что интуитивно понятно, как заполнять тот или иной воркайтем, сами они перестали быть некими абстрактными единицами, как было ранее (разве что воркайтем Bug имел какой-то интуитивно понятный смысл), но приобрели какое-то значение, стали обладать, можно сказать, своей функциональностью и смыслом. А раз появился четко выраженный смысл и функциональность, то и отпадают всякие вопросы о том, какой воркайтем в каких условиях создается и в какое состояние когда переходит.
То есть, не как было с Task и Scenario – потому, что “вот так договорились, так предполагает Agile, а вообще-то, физически, разницы никакой”, а вполне себе четко, повторяюсь, интуитивно понятно и, главное, для проекта действительно _имеет_ смысл то, какой тип воркайтема ты создаешь.

Кроме этого темплейта у той же команды и еще одна интересная штука: Task Board. Это WPF-приложение, работающее с TFS посредством веб-сервисов и отлично визуализирующее процесс (и позволяющее управлять им). Вот оно: http://www.scrumforteamsystem.com/en/TaskBoardBeta/Default.aspx

Там есть видеоролики, наглядно демонстрирующие возможности, и скриншоты.

Словом, если у вас тоже есть команда (или несколько) из нескольких человек, вы хотите получить дополнительный ресурс в дивелоперскую команду (роли непонятного PM’а там нет, поэтому он сможет заняться делом вместо того, чтобы спрашивать “как продвигается”), если вы тоже пользуете Agile или CMMI-шаблон, но не используете саму парадигму, если вы хотите сделать проект прозрачным для себя, руководства и заказчиков и при этом не погрязнуть в формализации – есть смысл посмотреть на Scrum и на его “инкарнацию” в TFS :)

Сегодня переустанавливал Team Foundation Server, пришел таки диск с новой, 2008-й версией.

Вспоминая про установку 2005-й версии, обновление ее с ознакомительной версии до лицензионной а так же последующую миграцию на другой сервер, ожидал, что называется, ночного кошмара.

Оказалось зря. В Майкрософте времени даром не теряли и сделали-таки нормальный инсталятор, который сам обновлял базы данных, перезапускал IIS и так далее. Все произошло очень быстро, я только успевал замечать ход работ по task manager'у.

Клиентские машины даже не поняли, что что-то поменялось (внешне, конечно).

Однако, не обошлось и без "ложки дёгтя".

После обновления оказалось, что функция Undo Pending Changes не работает по причине несоответствия кодировок базы tempdb и TfsVersionControl (вроде). Поиски в интернете привели к тому, что я такой не один, а причина в том, что в сохраненной процедуре, отвечающей за Undo Pending Changes, ребята из Майкрософт забыли указать правильную кодировку, создавая временные таблицы. Именно что забыли :)
В качестве решения было предложено пересоздать системные таблицы с нужной кодировкой, что равносильно переустановке SQL-сервера. Даже хуже, пересоздать базы для SQL-сервера с установленными сервиспаками ни капли не просто, а быть может даже невозможно, в виду отсутствия дистрибутива со включенными сервиспаками.

Однако я нашел слухи, что Майкрософтовцы сделали hotfix для этого дела, но никому его не дают - надо отдельно запрашивать. Я написал разработчикам из команды TFS, они ответили, что hotfix действительно есть, но просить его надо не у них лично, а у support-команды ("команды поддержки", чтоли, на русском? Смешно :))

Позвонили в саппорт. Там обещали перезвонить через недолгое время и заплатку дать. Посмотрим, что получится.

Быть может потом расскажу о впечатлениях от новых фич TFS :)

Я уже писал как-то о своем опыте переустановки Team Foundation Server (тогда нужно было снести триальные версии и поставить лицензионные).
Тогда прошло все хорошо, кроме одной детали:  не работали сайты проектов в SharePoint.

С тех пор произошло много интересного. Например в форумах MSDN я прочел, что нужно просто переустановить SharePoint Services. Не поверил, но вот беда - сделал. Чем Microsoft не шутит.
Словом, пришлось после этого снова переустанавливать TFS.

Сегодня я повторил попытку "починить" SharePoint порталы, в следствие чего я снова "убил" TFS(не знаю уж как именно) , но зато разобрался, как починить SharePoint.

После очередной переустановки TFS (естественно, порталы не работали, как и после предыдущих переустановок) все достаточно просто удалось пофиксить.

Итак, "рецепт":

• После установки и восстановления TFS (тут прямо по инструкции) у вас должно работать подключение из Visual Studio (ключевой момент), но порталы будут "молчать".
• Открываете базу данных STS_Config_TFS и запускаете на ней SQL Profiler.
• Пытаетесь открыть сайт портала проекта (я знаю, что не работает, но нам нужно поймать запрос)
• Смотрите в лог профайлера. Там должен быть вызов хранимой процедуры, возвращающей параметры виртуального сервера. К сожалению имени процедуры я не помню, но оно очевидно, найдете сразу.
• В качестве параметра этой хранимой процедуре передается GUID. Это - идентификатор виртуального сервера, который и должен был бы содержать ваши сайты проектов. Запомните (запишите) этот GUID.
• В базе STS_Config_TFS открываем таблицу "VirtualServers" (или как-то так, сразу видно) и смотрим в нее. Там должна быть запись о дефолтном сервере (Default Server, или как-то так, у меня она вообще была одна, не ошибетесь). Обратите внимание на GUID этого сервера. Он другой :)
• Идем в индексы этой таблицы (которая VirtualServers) и изменяем параметры связи с таблицей "Databases" - нам нужно установить значение "Cascade" для "Update" ключа. Потому, что ключ мы сейчас будем менять.
  Сохраняем это дело.
• Изменяем GUID дефолтного виртуального сервера на тот, что был получен нами из профайлера и сохраняем. Понятное дело, что ссылка в таблице "Databases" тоже должна проапдейтиться.
• Убираем "Cascade", который мы выставили выше.

Все, порталы должны заработать. Во всяком случае у меня дважды получилось :)

Удачной работы!