XP Virtual Mode isn't (IMHO) a full XP Install. "Everything" might be there but you're "stuck" with XP SP3 that can't be slipstreamed due to the fact that it follows the old OEM axiom "Just give them the bare minumum so they'll be dependent upon us." Indeed, you just stated "EOS" so what would be your solution?
I have yet to complete my little "project" but its entirely feasible to pull the Drivers (which also support USB AFAICT) from the SysPrepped XP Mode VHD, integrate them and all (workable) updates into an Install Medium, reformat the VHD, reinstall, thus having a *real* (e.g. fully updated and slipstreamed, even customized to user's taste) Virtual Machine, given the key components.
In regards to Windows XP Mode not being a full install, I’m not sure exactly what you mean. I think I disagree. Windows XP Mode is a complete Windows XP Professional environment, there is no code difference between it and Windows XP Professional installed from installation media.
If what you are implying is that it is a difficult solution to implement because you can’t deploy it complete with updates, applications, and configuration, then you do have a legitimate concern. Windows XP Mode is deployed to individual systems as the equivalent of a fresh installation and will need to be configured, updated, and have applications installed for each one. This is precisely the scenario that MED-V is designed to address. MED-V effectively allows you to deploy a centrally configured image to XP Mode across an organization, but it requires access to MDOP and thus SA (Software Assurance).
Another potential concern with Windows XP Mode are the restrictions of running in a virtual environment, especially a Type 2 Hypervisor. Any virtualization solution will abstract the operating system from hardware resources and that can affect performance. The three big concerns here are memory, graphics, and peripherals.
- Memory is only a concern if you have less than 4GB of RAM. For example, on a 2GB system you may choose to allocate 1GB to the host and 1GB to the guest, effectively halving the amount of available memory. By contrast if you have 6GB of RAM you can easily allocate the maximum 4GB to the guest and 2GB for the host.
- Virtual environments are abstracted from the physical hardware of their host. For graphics intensive applications like CAD or design software, this means no hardware acceleration and poor graphics performance.
- Again because of the abstraction from the host, connectivity to physical devices can be difficult to manage. If your software requires direct access to physical devices, i.e. USB, PCI, Serial, Parallel, you may be better off with a physical environment.
Hyper-V on Windows 8.1 (as opposed to Windows XP Mode on Windows 7) warrants many of the same considerations. Hyper-V virtual machines can be managed more easily, either by managing the VHD files or by managing the virtual machines the same way you manage physical machines. On the other hand Hyper-V doesn’t include a free license for Windows XP.
My point is not that you should do one thing or another, but that there are many options and they all warrant serious consideration. I would also like to stress that virtualization is absolutely not the universal fix. First consider updating the application (which I imagine the OP has, since it is the easiest route) then the next step is to consider making the application compatible.
Fixing compatibility isn’t always as hard as it seems. You can use Orca to get past installation errors (MSIs) if that is the hang-up. If the program doesn’t run or has errors, it’s usually caused by looking for resources that have been relocated in new versions of Windows or which the application doesn’t have access to. Shims are used as a layer between the application and the resources. For example, if the application looks in C:\Program Files\ as a hard coded link, but is installed on a 64 bit system and thus the program files are actually stored in C:\Program Files (x86)\, the CorrectFilePaths shim can be used to sit between the program and the operating system to translate any queries from C:\Program Files\ to C:\Program Files (x86)\. You can use pre-configured sets of shims that mimic older environments via compatibility modes, or you can use ACT to build custom sets of shims if the built-in compatibility modes don’t work.
Each scenario is unique, with different applications, hardware, budgets, etc. but I’ll see if I can list some of the more common solutions and their considerations:
- Upgrade Apps:
This is the easiest solution, but often costs money. Even so, consider the cost of the app upgrade vs. the time to develop and implement other solutions. The true cost to upgrade the app could be less than the cost to develop another solution. Think about how much time is being spent here trying to figure out Windows XP deployment, what is the cost of that vs the app upgrade?
- Fix Compatibility:
While fixing compatibility issues is more difficult than upgrading the apps to compatible versions, it is free and allows you to run the application on an operating system that is current with today’s management and deployment tools, compatible with new hardware or software should you chose to add it, and kept up-to-date against security vulnerabilities and stability issues.
If you have to run an out-of-support, vulnerable Windows XP environment, it is far better to do so in a minimal, isolated environment. If the environment breaks, it doesn’t take down the whole operating system and the user can continue to work without the app. If the environment gets infected, only data used by the app and exposed to the virtual environment is compromised. Better yet, the environment can be kept offline to best prevent the possibility for compromised data. We’ve only talked about client-side virtualization, but you could also consider server-side virtualization where you host your XP environments on a Hyper-V server, etc. and remote into them from the workstations.
- Physical Deployment:
If you consider all the options and it still makes sense, then you might not have a choice but to deploy to a physical workstation. To accomplish this requires older tools and methods that won’t be applicable to modern operating systems. If you deploy the workstations on the network you can never be certain of their security, even if running security solutions, because there are core vulnerabilities that aren’t patched. If you need to replace or add hardware you are likely to run into compatibility issues. If the system is unstable and it crashes, you lose the ability to use the computer altogether while the issue is repaired. You may want to consider isolating the workstation(s) by an air gap.
I don’t want to tell you what to do or imply that any one solution fits all, but I do hope you’ll consider the above before you decide to implement an EOS or EOL component in a production environment.
If you do move forward, learning MDT 2012 makes deployment of different app configurations easier, makes deployment more feasible via USB or network, and is much closer to the deployment methods used for Windows 7, Windows 8.1, and Windows 10; so the knowledge you gain can be reused the next time you need to deploy, regardless of operating system.
It’s a little shocking to see an XP deployment in the works well after End Of Support.
haven't you noticed, on this board we also assist people having issues with a number of other Operating Systems well after End of Support, including Windows 3.1/3.11, Windows 95 and 98, Windows NT4 and 2000.
We even support people using Windows Me .
Please don’t infer that I’m trying to prevent you from assisting someone using Windows XP; that certainly isn’t my intent. I merely wanted to add my two cents about considering the alternatives, and add my recommendation for MDT.
However, this isn't what the OP asked for and you're seemingly "promoting" Upgrading (sounds like a hard-sell to me).
Licensing for various options is a whole other consideration, one that I won’t (and can’t) get into. I am merely providing options that are technically possible. I assume the OP is familiar with what they can or cannot do and can judge for themselves. The OP might be running Windows 8.1 VL and SA (and thus upgrade rights to Windows 10 and downgrade rights through Windows 95).
Windows Outreach Team- IT Pro
Windows for IT Pros on TechNet