Ошибка профиля пользователя БД в WebPart

Question

РЕДАКТИРОВАТЬ: Изменен заголовок и добавлено обновление.

UPDATE : Мы больше не считаем, что это проблема 64-битного или 32-битного. Мы обнаружили, что единственными людьми, которые видели это, были люди, которые были определены в политике фермы как «полный контроль». (Не действует как системная учетная запись). После того, как мы протестировали обычных пользователей, мы обнаружили, что ни у кого не было проблемы. Удаление «проблемных» пользователей из политики фермы и добавление их обратно, исправление всех пользователей, кроме одного (сотрудник dev:)).

Мы запустили нашу ферму с 2 32-битными WFE и 32-битным сервером приложений. Мы решили добавить 64-битные интерфейсы к нашей ферме, и по большей части почти все работало нормально. Исключением является пользовательская веб-часть, которая обращается к базе данных профиля пользователя. Работает нормально на 32-битном интерфейсе, но мы получаем следующую ошибку на 64-битном интерфейсе:

Пользователь не найден: не удалось загрузить данные профиля из базы данных.

Описание: необработанное исключение произошло во время исполнения текущий веб-запрос. Пожалуйста, просмотрите трассировка стека для получения дополнительной информации о ошибка и откуда она возникла код.

Сведения об исключении: Microsoft.Office.Server.UserProfiles.UserNotFoundException: Пользователь не найден: не удалось загрузить профиль данные из базы данных.

Ошибка источника:

Создано необработанное исключение во время исполнения текущего веб-запрос. Информация относительно Происхождение и место исключения можно определить с помощью исключения трассировка стека ниже.

Трассировка стека:

[UserNotFoundException: пользователь не Найдено: не удалось загрузить данные профиля из базы данных.]
Microsoft.Office.Server.UserProfiles.UserProfile.Load (SqlDataReader myReader, логическое значение bFirstRead, логическое значение bWssId) + 930
Microsoft.Office.Server.UserProfiles.UserProfile.Load (SqlDataReader myReader) + 64
Microsoft.Office.Server.UserProfiles.UserProfile.RetrieveUser (String strAcct, Guid gAcct, Byte [] bSid, Nullable`1 recordId, логическое значение doNotResolveToMasterAccount) + 1507
Microsoft.Office.Server.UserProfiles.UserProfile..ctor (UserProfileManager objManager, String strAcct, Boolean doNotResolveToMasterAccount, Boolean forceUserIsSelf) + 584
Microsoft.Office.Server.UserProfiles.UserProfile..ctor (UserProfileManager objManager, String strAcct) + 80
Microsoft.Office.Server.UserProfiles.UserProfileManager.GetUserProfile (String strAccountName) + 205

Поскольку WFE находится на одной ферме, он должен искать в одной базе данных.

Дайте мне знать, если потребуется дополнительная информация.

Любые идеи приветствуются!

Спасибо.

Answer 1

«Слово на улице» : нельзя смешивать 32-разрядные и 64-разрядные серверы в одной ферме (за исключением сервера базы данных).

http://technet.microsoft.com/en-us/library/cc261700.aspx говорит:

Вы можете развернуть ферму Office SharePoint Server 2007 на сочетании 32-разрядных и 64-разрядных серверов при условии, что вы поддерживаете однородность архитектуры на каждом уровне топологии. Например, вам не следует смешивать 32-разрядные и 64-разрядные интерфейсные веб-серверы (WFE), но вы можете использовать 64-разрядные серверы баз данных в ферме с 32-разрядными серверами WFE и серверами приложений.

Итак, вы МОЖЕТЕ смешать 64-битные и 32-битные, но, очевидно, не 32-битные и 64-битные WFE. Я не говорю, что это правда, я говорю, что Technet говорит, что это правда. Technet часто более консервативен, так что спросите своего парня из MVP.

Answer 2

Питер, большое спасибо за дополнительную информацию. Я буду просить MVP об этом.

Эта веб-часть - единственная проблема, которая дает нам проблему с 64-битным WFE. Все остальное работает нормально. У нас есть другой пользовательский код (веб-части, получатели событий, типы контента и т. Д.), Которые без проблем работают в 64-битном режиме.

Спасибо за ответ; Я опубликую все, что MVP говорит об этом.

Редактировать: Ответ от MVP

Они предполагают, что вы балансируете нагрузку. 32 и 64 в том же NLB и что не будет хорошо сбалансирован. это абсолютно поддерживается архитектурно, тем не мение. Это должно работать.