TFS 2010 Пользователь переехал в новый домен до того, как сервер - идентификация / изменение TfsConfig не работает - опции?

Question

Мы мигрируем на новый домен. В документации по изменению среды (и для команды TfsConfig identities /change) говорится, что учетные записи пользователей не должны существовать в TFS, прежде чем вы попытаетесь перенести их в TFS.

Однако, кто-то вошел, потому что они были перенесены как тестовый пример и добавлены автоматически через групповую политику.

Как описано в документации, TfsConfig identities /change не будет работать для этой учетной записи, поскольку новая учетная запись уже находится в TFS.

TfsConfig identities показывает, что SID нового идентификатора не соответствует Windows.

Ни один из запросов пользователей не работает (конечно, потому что это новая учетная запись).

Что еще хуже, пользователь создал рабочие элементы. Так что теперь есть рабочие элементы под двумя отдельными учетными записями ....

У меня вопрос: есть ли у меня средство для уборки этого беспорядка?

Я хочу, чтобы новый идентификатор совпадал с Windows, рабочие элементы пользователей были объединены под новой учетной записью, а все пользователи запрашивали работу ...

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

ОБНОВЛЕНИЕ (для тех, кто совершает ту же ошибку, что и мы)

Мы перенесли наш сервер в новый домен прошлой ночью. К счастью, SID, кажется, исправили себя. Единственная проблема сейчас заключается в том, что пользователь не имеет доступа к своим старым рабочим элементам. Я могу обновить все поля, кроме Создано, с помощью кода. Создано только для чтения. Этот вопрос теперь только задает:

Как обновить поле «Создано» для рабочего элемента?

Я прочитал много постов, в которых говорится, что никогда, никогда, никогда не обновляйте данные непосредственно в базах данных TFS ... Но, похоже, это мой единственный вариант, если я хочу исправить запросы пользователей ...

Answer 1

Нет способа удалить личность, но вы можете поменять одну личность на другую, но вы должны иметь в виду следующее от Microsoft:

Если учетная запись пользователя присутствует в TFS, ее нельзя удалить или назначить другую учетную запись. Например, если вы перемещаете DomainA / UserA в DomainB / UserB, команда Identities будет работать только для переноса пользователя, если DomainB / UserB еще не присутствует в TFS.

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

Переместить Team Foundation Server

Answer 2

Мне удалось решить эту проблему с помощью консоли администрирования сервера TFS.

В окне «Уровень приложений» консоли администрирования добавьте пользователя в поле «Пользователи консоли администрирования», нажав рядом с ним кнопку «Добавить».

После того, как я это сделалпользователь, у которого был SID, который был не синхронизирован, был затем синхронизирован. Затем я удалил этого пользователя из консоли администрирования, и этот пользователь все еще был правильно синхронизирован.

Я смог проверить с помощью TfsConfig identities.

Answer 3

Если вы находитесь в этой лодке, то вы уже в шланге.Вы ДОЛЖНЫ придерживаться предписанной документации для перемещения домена, поскольку это невозможно исправить после.

• Перемещение Team Foundation Server из одной среды в другую

Даже если вы сожжете билет поддержки, я думаю, вы получите тот же ответ.Вы не можете редактировать базу данных напрямую.Хотя вы можете заставить его работать, вы, скорее всего, предотвратите будущие обновления ...

ps. Если служба поддержки MS предлагает вам отредактировать базу данных, вам следует запросить второе мнение у команды разработчиков продукта :) Поддержка MS не всегда верна...