EDIT: Modified title and added update.

UPDATE: We no longer believe this is a 64bit vs 32bit problem. We have found that the only people that were seeing this, were people that were set in the farm policy as "full control." (Not acting as System Account) Once we tested regular users, we found none had the problem. Removing the "problem" users from the farm policy and adding them back, fixed all but one user(a fellow dev:)).

We started out our Farm with 2 32bit WFE's and a 32bit Application server. We have decided to add 64bit front ends to our farm, and for the most part, almost everything worked fine. The exception is a custom web part that accesses the user profile database. Works fine on 32bit front end, but we get the following error on the 64bit front end:

User Not Found: Could not load profile data from the database.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: Microsoft.Office.Server.UserProfiles.UserNotFoundException: User Not Found: Could not load profile data from the database.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[UserNotFoundException: User Not Found: Could not load profile data from the database.]
Microsoft.Office.Server.UserProfiles.UserProfile.Load(SqlDataReader myReader, Boolean bFirstRead, Boolean 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, Boolean 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

Since the WFE is on the same farm, it should be looking at the same database.

Let me know if any more info is needed.

Any ideas would be appreciated!


+3  A: 

"Word on the street" is you can't mix 32bit and 64bit servers on the same farm (with the exception of the database server). says:

You can deploy an Office SharePoint Server 2007 farm on a mix of 32-bit and 64-bit servers, provided that you maintain architecture homogeneity at each topology layer. For example, you should not mix 32-bit and 64-bit Web front-end (WFE) servers, but you may use 64-bit database servers in a farm with 32-bit WFE servers and application servers.

So, you CAN mix 64bit and 32bit, but apparently not 32bit and 64bit WFEs. I'm not saying it's true, I'm saying that Technet says it's true. Technet is often more conservative, so uh, go ask your MVP guy.

Peter Seale
Can you explain further "Word on the street"? We had a Microsoft "Sharepoint" MVP help us set up the 64 bit WFE. He seemed to think that there would be no problem.
I'd also add that some webparts just won't work on 64bit at all (even if not in a mixed 32/64 bit environment). I've no idea why, but it's just my experience. We've taken to only deploying 32bit WFE's (generally in VM's running on a 64bit host OS).
Kevin Dostalek
Thanx for the info, Kevin. This is the only WP that has given us problems, and we now believe it is not a 64bit issue.
Thanks for the effort, Peter. Giving you the check mark. :)
+1  A: 

Peter, thanks much for the additional information. I will be asking the MVP about this.

This webpart is the only thing giving us a problem on the 64bit WFE. Everything else is working fine. We have other custom code (webparts, event receivers, content types ... and so on) that have no problems running in 64bit mode.

Thanks for the reply; I will post anything the MVP says about this.

Edit: Response from MVP

They assume you are load balancing 32 and 64 in the same NLB and that wouldn't balance well. It is absolutely supported architectually, however. It should work.

try recompiling your web part to target 64bit? I seem to remember something weird about the User Profiles dll, it (or maybe the Microsoft.Office.Server.SignleSignon) references a native DLL and maybe that reference is 32bit-only. Totally guessing at this point.
Peter Seale
+1  A: 

I am seeing exactly same exception stack trace. Were you ever able to exactly pinpoint what the issue was? Only a specific end user has reported this issue.

@ Sree - are you seeing this for all users or just a small subset? ... See the UPDATE text on my original post if it is just for a subset. We also found that 1 user had actually been updated in AD, but the Profile user DB had his old account info.
I am seeing this issue for subset of users but they are end users not users with full control. Any ways, I just deleted a user from user profiles in ssp and running the full synch again... Let's see if it fixes the issue. BTW, I am able to reproduce this issue in 2 environments for same user.
Deleting User Profile and Resynching did not fixed. But, and following commands resolved our end user issues. After running following command wait for the top of the hour let the databases recreated.stsadm -o sync -deleteolddatabases 0