Solved SSD; Moved 'Users' and 'ProgData', SP1 OK. About 'Program Files'?

[DeaconFrost]

You definitely don't want to disable the pagefile, especially on a system that will be doing anything intensive. That myth died a long time ago, and should be left to rest in peace.

 

[USASAgencyman]

You definitely don't want to disable the pagefile, especially on a system that will be doing anything intensive. That myth died a long time ago, and should be left to rest in peace.

I think I am staying on board with that. I wanted all the space on the SSD C: for the intensive programs and scratchpad.

I am going to call this solved, until some update messes me up. But it went from fresh build, with folders moved in audit mode during build, to SP1 and seems happy.

This forum is a valuable resource of knowledge and experience, hope I can contribute some, when I wring out a couple of these peculiar builds.

Bruce

 

[flirno]

I haven't run into this at all with the unattend implementation. The problem comes from moving Program Files which is why moving Program Files is not supported by Microsoft in the setup XML but moving Users and ProgramData is.

Be aware that moving the ProgramData folder will break servicing, so the next time a service pack or a major servicing engine patch comes out you're going to be rebuilding rather than upgrading. Just be aware that folder is finnicky when it comes to servicing, and one of the drawbacks of moving it means you can't service the OS going forward. Moving the rest is technically OK, although for Program Files it is usually better to leave that alone (due to UAC trust paths being broken if you move it) and just force installation for new programs to the \Program Files folder on whichever drive you desire. I have had updates in the past for both Windows and other software packages that don't work or don't work properly due to the location. If you've tested the apps and they work OK from a different location (technically they should, but that doesn't necessarily mean that they always will), you should be OK.

 

[USASAgencyman]

I haven't run into this at all with the unattend implementation. The problem comes from moving Program Files which is why moving Program Files is not supported by Microsoft in the setup XML but moving Users and ProgramData is.

Since I am very new to these things that alter Windows, I just copied over the entire .xml file as I found it in that guide, Win7: how do I move user folder to a different drive - Microsoft Answers.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup"  processorArchitecture="amd64" 
publicKeyToken="31bf3856ad364e35"  language="neutral" versionScope="nonSxS"  
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"  
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <FolderLocations>
                <ProfilesDirectory>d:\Users</ProfilesDirectory>
                <ProgramData>d:\ProgramData</ProgramData>
            </FolderLocations>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="wim:h:/sources/install.wim#Windows 7  
ULTIMATE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

There are things in it that I don't understand, and wonder if it needs updating or tuning in any way for x64 systems or particular systems.

For instance; I looked in SYSWOW64/sysprep and there was a mention of sysprep succeeding. I had tried to run the .xml from there and it said no sysprep.exe was present, if I remember this correctly. Seems like the whole folder was empty.

The guide said to run from the sys32, which I did. Perhaps the process is so thorough, it updates both 32 & 64 sysprep folders?

 

[flirno]

There are not that many things to tune generally.

As far as I know processorArchitecture="amd64" is all you need for x64 systems.

The only thing I would have done differently is here:

<cpifflineImage cpi:source="wim:h:/sources/install.wim#Windows 7
ULTIMATE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />

I would do the entire product name in bold characters as:

<cpifflineImage cpi:source="wim:h:/sources/install.wim#WINDOWS 7
ULTIMATE" xmlns:cpi="urn:schemas-microsoft-com:cpi" />

However maybe that isn't necessary.

This is assuming there is not other text needed for the product name. Some googling will turn up more about the string used there.