Move from Windows 7 x64 to Windows 7 x86

Due to the need to run a 16-bit application, I have several PC's that need to be x86 installs.  They currently have x64 on them and I would like to do a refresh/reinstall in-place to the x86 install and make it painless.
USMT does not support going from x64 to x86, which is unfortunate.  The only option I can think of is enabling Roaming profiles, let the user's log in and out a couple of times, then try the refresh/reinstall but I'm not sure how well that would work.
Anyone else have any thoughts on this one?
LVL 1
Jody WhitlockSystem AdministratorAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jcimarronCommented:
Jody Whitlock--
Have you tried running the app in Compatibility Mode?
Right click the app's executable file|Properties|Compatibility tab?

The following reference
http://www.pcworld.com/article/2045345/run-an-old-program-on-a-new-pc.html
makes this point
"There is no really good solution for running a 16bit program on a 64bit OS. A virtual machine is the only, admittedly weak, solution.

If this is a DOS application, you could try DosBox or Vdos.  Links are provided here
http://www.tomshardware.com/answers/id-2131399/run-bit-application-windows-windows-bit-system.html
0
Lee W, MVPTechnology and Business Process AdvisorCommented:
Depending on the app's purpose, I would definitely investigate other options first.

I would also say you should be redirecting profile folders.  Then on a rebuild, the important stuff is on a server and doesn't need to travel across the wire.  

Finally, you might want to test User Profile Wizard by FORENSIT.COM
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
- If your applications not working are 32-bit and you are having connectivity issues to the database, ensure to run create your ODBC connections by running c:\windows\syswow64\odbcad32.exe

- Download XP mode VM from Microsoft which is available at:
http://www.microsoft.com/en-ca/download/details.aspx?id=8002

- Try compatibility mode
0
Cloud Class® Course: SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

Jody WhitlockSystem AdministratorAuthor Commented:
So with it being a 16 bit application x64 can't emulate it. Currently it is running in XP Mode but that still poses the same risk as running XP on bare metal, and has the same issues.
The application is a custom ERP system and the company really doesn't want to spend the 6 figures to replace it.
We do Folder Redirection but that doesn't do anything for AppData and proper Windows programs that use ProgramData.
It's starting to sound like a manual migration will need to be done.
0
McKnifeCommented:
"Currently it is running in XP Mode but that still poses the same risk as running XP on bare metal, and has the same issues." - this is disputable. Using xp in some way or the other does not necessarily mean being insecure, it depends on what attack surface you allow. If that xp has no ports open to the world around it, tell me, how would it be attackable? Not over network.
If you use xp only for this application inside xp mode, how would OS exploits be usable? Only via this one application, via files or methods this application allows and uses. And those would be the same as you'd use on win7 x86.

Please explain your statement.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
What about the DOSBox approach? It should be able to run 16bit  applications. Not very well, of course, because of the emulation, but it should work.
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
Dosbox may not be an option if the application was written in a very old version of VisualBasic, etc.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
Isn't that exactly the purpose? Supporting antique VB (alias QBasic) and native MS-DOS applications?
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
We have an EDI application with was written with VB 5.0 and it does not run under DOS but requires Windows Server 2000 or earlier to work properly (doesn't work under Win2K3 due to errors in getting DLLs working).
0
Jody WhitlockSystem AdministratorAuthor Commented:
In response to McKnife, XP Mode is just a VM running full XP so it has the same vulnerabilities as having an XP machine running on the network.  It still doesn't get updates anymore, and because of the requirement of mapped drives for this FoxPro application to run then it means it touches various parts of the network.
I will look into DOSBox but I have concerns with the age and lack of active development I see with it. Otherwise I will have to go old school and write a script to performs the user state transfer.
0
McKnifeCommented:
Please understand: We can use XP safely if we do it right, that is, firewall on and use no components but tho remoteapp. In your case, I see no additional danger compared to win7 32bit. That's why I asked you to explain: Why do you see danger in using XP mode?

You mentioned mapped drives, but I guess these drives are mapped on XP - so the direction is outgoing, not incoming, so no ports but rdp are open on XP. And this rdp traffic can be firewall protected, too, so that the port is only available to the win7 host. There will be no open ports to the general network.
0
Jody WhitlockSystem AdministratorAuthor Commented:
While all that is true to a point, high ports are not blocked by Windows firewall. Win7 is inherently more secure than XP due to USC Virtualization and patches to new zero day items. Also, what I have found is printing is very problematic with XP mode and newer printers.
Now one thing to consider is this client must be HIPAA compliant which means no unsupported software is allowed.
Lastly, I will not ever recommend anyone run a line of business program in an unsupported manner, and XP is not supported.  Microsoft put out a statement that they will not support XP Mode, so the point of this exercise is bring these systems into compliance.
0
McKnifeCommented:
There's nothing listening on high ports. You can of course block those, if you like. Zero day items don't matter as long as the affected OS components are not used but instead only the program. Those vulnerabilities are not touched as the incoming data is controlled by you.

The unsupported state would not be an issue: If it now just works as it used to, it will logically continue to work just because xp will not be changed anymore, same is true for win7's xp mode.

xp mode is a way. If you prefer something else, I can understand that, About printing to new printers without an xp driver, ok, that would be an issue.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
"this client must be HIPAA compliant which means no unsupported software is allowed."

This sounds strange. They run a 16bit app??? Highly unsupported for sure. Though the app itself is not vulnerable (most probably), the system it runs on needs to be because of a lot of compatibility issues.

So the question is what "unsupported" means. I'm not informed about the requirements for "Covered Entities and Business Associates", but HIPPA compliance might mean a serious restriction on tools you can use. Emulators might be an issue, though they do not increase the vulnerability more than just using a 16bit app does.

Going back to the original question: I don't think there is a way you can incorporate 64bit OS settings into a 32bit OS, because there are different registry and file paths to merge into one, and contradicting settings for both.

Instead of XP mode you could run other VM software hosting 32bit OS VMs. E.g. VirtualBox or VMWare Workstation plus W7 x86 VM.
0
Jody WhitlockSystem AdministratorAuthor Commented:
So for these reasons I am re-imaging the client PCs with Win 7 x86, but the crux of the question is how to get the user state front the current Win 7 x64 and migrate it.
As for FoxPro, it is oddly enough still a supported platform.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
I see your point, but no automated solution, sorry. Only manual editing of migration data (registry and file paths) might work. Roaming profiles will have the same issue, I don't think you can change between the bitness.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jcimarronCommented:
Jody Whitlock--
I feel some credit is due to my post http:#a41199829  in which I said
""There is no really good solution for running a 16bit program on a 64bit OS. A virtual machine is the only, admittedly weak, solution."
You seem to have realized that by installing Win 7 32 bit.
0
Jody WhitlockSystem AdministratorAuthor Commented:
I agree jcimarron, I apologize for overlooking your comment.  How to I go back and add yours as a second solution after the fact?
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows 7

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.