WinOutreach2

Just to add a point for anyone trying the above method. It is absolutely required that you do not try to update or install apps through the Windows Store before resealing. See KB2769827 at Microsoft Support. I’d also recommend giving the Surface Pro 3 Deployment and Administration Guide a read, it provides a comprehensive review of the recommended deployment process and techniques. Brandon Windows Outreach Team- IT Pro Windows for IT Pros on TechNet

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. Virtualize: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. Dear Brandon, 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. 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). Brandon Windows Outreach Team- IT Pro Windows for IT Pros on TechNet

It’s a little shocking to see an XP deployment in the works well after End Of Support. I would strongly recommend alternative routes to an XP deployment/installation directly on hardware. Step one for me would be to see if I could get the applications to work in a modern version of Windows. Some applications may be completely incompatible with Windows 7, Windows 8.1, or Windows 10, but you might be surprised just how many “legacy” applications can be easily made compatible with some work in the Application Compatibility Toolkit (ACT) or sometimes just some tweaking of the installers with Orca. Step two for me would be to look into virtualization solutions. This could be the simple virtualization solution of Windows XP Mode with application integration if your workstations are running Windows 7. The enterprise equivalent Microsoft Enterprise Desktop Virtualization (MED-V) if you are running Windows 7 and have the Microsoft Desktop Optimization Pack (MDOP) through Software Assurance. Or for Windows 8 or newer, Client Hyper-V. Step three would be to really evaluate the costs of your remaining options. What is the cost of getting an XP image up and running? Does your hardware even support Windows XP and are drivers available? What is the cost of having your legacy applications on an insecure platform? By comparison, what is the cost of updating the applications to compatible versions? Updating or replacing an application is often more cost-effective than you think when you consider the ramifications of compromised customer data due to an infected machine, the difficulty of managing that machine as modern management tools are incompatible, even the difficulty of something as simple as replacing a printer when compatible drivers aren’t available. If despite these alternatives you still end up moving forward with a Windows XP deployment, you might want to consider using the Microsoft Deployment Toolkit (MDT) 2012 Update 1, the most recent version to still support Windows XP deployment. With MDT you can easily create the ISO/DVD/USB installation media you’ve described and you can even deploy over the network with PXE if desired. You can also deploy applications separate from the operating system, so you can ultimately use the same disk to deploy the “finance” department with their accounting software as you use for the “design” department with CAD and graphics software and the “production” software with CAD/CAM software, for example. Brandon Windows Outreach Team- IT Pro Windows for IT Pros on TechNet

You can poke the holes you need through the firewall using the same answer file that you are using to copy the profile. See the commands outlined here on TechNet.

There are quite a few guides and resources on the Deliver and Deploy Page for Windows 8 on the Springboard Site on TechNet. Like Tripredacus says, the process uses many of the same tools and is very similar to the process for Windows 7. As for Shift+Ctrl+F3 to enter Audit Mode to customize the Administrator profile in order to use the copyprofile setting to customize the default profile, this sequence is still valid for Windows 8. Really though, the Microsoft Deployment Toolkit is the way to go for deployment of Windows today. The unified interface from which you can control almost all Microsoft deployment technologies gives you the ability to perform an amazing amount of tasks. You can create an installation and deploy it either through the network, using PXE if you have it installed in a Windows Server environment with WDS, or via USB key or disk, you can create an image able to be deployed to multiple configurations of hardware or which has various sets of software installed upon it, you can take the user data for an existing environment, back it up on the local hard disk, then restore it once the system has been upgraded, and quite a bit more, these are just some of the examples of how it can be used.

As was suggested, you can simply right click the application or the shortcut, select properties, and set it to run in Windows 7 compatibility mode under the compatibility tab. This essentially masks the Windows version and reports to the application that you are running Windows 7. If for whatever reason this does not work, you can get far more detailed in how the compatibility issues are resolved using the Application Compatibility Toolkit. With ACT you can customize in detail what incompatible settings are mitigated. For example, you can set it to inform your application that you are running Windows 7 and that the Program Files are located in Program Files (x86) rather than Program Files to help resolve an application which worked in Windows 7 32 bit but will not work in Windows 8 64 bit. You can find guides and instructions on how to use ACT to resolve compatibility issues in the Application Compatibility Center on the Springboard Site on TechNet.

Trip, For the scenario you describe, where the Start Screen is interfering with scripts during the customization of the reference image, there is a method provided within Audit Mode to allow the system to bypass the Start Screen to facilitate the script automation. This is done by using Sysprep to launch AuditShD.exe which is found under C:\Windows\System32\OOBE\ via your Answer File. Details on how to add this to your answer file can be found in the Audit Mode Overview for Windows 8 on TechNet under Automatically Display the Windows 8 Desktop.