Can I Use the Same User Profile on 32-bit and 64-bit Windows?
|
by Helge Klein on 10/19/2010 | 10 Comments | 4,789 Views
|
More and more people are upgrading to a 64-bit version of Windows. Many of them would probably like to keep their existing configuration. The question is: can you use the 32-bit profile on Windows x64? Is there even such a thing as a 32-bit or a 64-bit user profile? Or are profiles independent of the system's bitness?
Profiles and Operating System Bitness
We had those very questions at sepago, so we performed some tests. First, we analyzed the entire file system and registry content of a default profile on x86 and on x64 Windows. When comparing the results, we found zero differences. Then we tried to log on to a 64-bit machine with a profile created on a 32-bit system. All went well - no mysterious signs, no funny sounds, nothing. We also did it the other way around, again, without noticeable wrath of the gods.
That answers the question: Can you use a 32-bit profile on a 64-bit machine? Yes, you can!
You Can - But Should You?
The fact that something is possible does not mean that it is clever. Although technically possible, using profiles across OS bitnesses has the potential for trouble. If you want to know why, just search for "Program Files (x86)" in the HKEY_CURRENT_USER hive on a 64-bit system. You will find many references (unless you installed 64-bit software only, which I doubt). Applications store file system paths to all kinds of configuration files, helper executables and installation directories in the registry. In the case of 32-bit applications on 64-bit Windows those paths all start with "Program Files (x86)". Now use the same registry hive on a 32-bit machine that has the same 32-bit applications installed ... and all paths are invalid. 32-bit Windows does not have a WoW64 subsystem that redirects 32-bit processes from "C:\Program Files" to "C:\Program Files (x86)".
What are the consequences?
Profile sharing across operating system bitnesses may cause applications to malfunction in strange ways. Some programs may be entirely unaffected, whereas others may not work at all. How exactly your most important application is going to deal with such a situation cannot be foreseen - because one thing is certain: that its developers never thought such a thing might happen.
Not to forget: shared profiles are not supported.
- ‹ previous
- 135 of 156
- next ›
+++ Your opportunity +++ Use Profile Migrator 2, the new sepago product that makes migrating user personalities between different platforms a breeze.! Download your free version now!
10 responses for "Can I Use the Same User Profile on 32-bit and 64-bit Windows?" |
Recent Articles
About the author
![]() |
Helge Klein IT-Architect Blogs about Windows, Terminal Services and other things |
Most viewed
| 155,223 Views |
Where is the Hosts File on Windows x64? |
| 83,078 Views |
Deleting a Local User Profile - Not as easy as one Might Assume |
| 53,093 Views |
Printer Driver Isolation in Windows 7 and Server 2008 R2 |








I've only seen two minor
I've only seen two minor issues - the Internet Explorer shortcuts (on x64 Windows, both x64 and x86 shortcuts are included in the user's Start Menu) and Microsoft Office stores some paths to the Program Files locations in the user's profile.
Fortunately Group Policy Preferences (and other user environment management tools) can solve both of these issues, so they should be only small hurdles to get profiles shared across processor architectures.
We used Environment Variables
We used Environment Variables to separate the different OSs, and set the UserStore according to that variable. Works a treat...
Yes, that is a very popular
Yes, that is a very popular concept.
Great article Helge. I've
Great article Helge. I've been deploying mixed architecture farms for quite some time and have not found any major issues using the same profiles. And when you do, you simply create a logon script, or as Aaron suggests, use Group Policy Preferences to address it.
One could rephrase the
One could rephrase the options like this:
If you are the (overly?) cautious type, use separate profiles. If not, use the same profiles, but be prepared to deal with the issues, which may very well be only minor.
yes,very good,I also have
yes,very good,I also have been deploying mixed architecture farms for quite some time and have not found any major issues using the same profiles. And when you do, you simply create a logon script, or as Aaron suggests, use Group Policy Preferences to address it.
The question is what is
The question is what is worse, doing it or not doing it.
If we use seperate profiles won't the user expect that a change done on an x64 workstation be reflected on an x86 (or vice versa)?
Just a thought as I didn't encouter this situation before but what about creating the ProgramFiles(x86) environment var and creating a symbol link Program Files (x86) -> Program Files (etc)?
Can someone explain how to
Can someone explain how to take those small hurdles Aaron suggest?
I have a mixed x86 / x64 win7 client environment with 2k8 r2 and i do not want to make two seperated profiles for lack of clear user experience.
TIA!
Hey Helge, Could you perhaps
Hey Helge,
Could you perhaps explain how UMP would handle profiles in a mixed env. like Win 2003, 32 bit and WIn 2008, 64 bit. For a lot of organizations trying to set up XenApp6 env. running a parallel environment will be a reality.
My user profile in the XenApp4.5 env (2003, 32 bit) points to \\SERVER\TSProfile\UserID\UPM_Profile. When using UPM on Win 2008 R2 env. I would expect UPM to create something like \\SERVER\TSProfile\UserID\UPM_V2Profile so that when users launch apps from either XA4.5 or XA6.0 env, they receive the respective profile. With some testing I have done, this doesnot seems to be the case.
Any insight on how to handle a parallel env. would be very helpful.
Thanks
VJ
Regarding multiple platforms
Regarding multiple platforms / multiple profiles there is not too much of a difference between Citrix Profile Management (aka UPM) and Windows roaming profiles. I suggest you treat the as equal in this respect.
This is true as long as Citrix does not release the cross-platform feature they have in beta.