The Old New Thing

"nor can it be changed after Windows has been installed"

That sounds like a challenge.

A challenge that has already been met: http://joshmouch.wordpress.com/2007/04/07/change-user-profile-folder-location-in-vista/

Of course, if you DO change it, you can't apply service packs or patches to your OS.  That seems silly.

Don't try moving the c:\windows\Installer folder to a Join on another drive either.

Unless you get the permissions and ownership (Local System I'm told, but having been burned once, I've just given up) just right, Windows Installer will delete the Join and start again as a "security measure".

For Join in my previous message, read Junction.

Oops.

So microsoft suggests we don't move the "users" folder location.

MY QUESTION (to Raymond):

Can we "junction" a specific user folder to another drive?

> Can we "junction" a specific user folder to another drive

The linked article says "The servicing stack does not handle cross-volume transactions" so I would guess not. A volume on a junction is still a different volume.

Good to know, I'll be using that next time I reinstall the os (which will probably be with Windows 7, I don't reinstall casualy).

I would recommend also making a C:\Users symlink or junction that points to your new user folder to catch any hard-coded programs that refuse to use the proper APIs.

I imagine the C:\Documents and Settings symlink would already point to the proper location, so that would cover all bases.

Note that doing this will most likely prevent you from doing an upgrade installation.

At least, it did with XP => Vista.  Incidentally, in XP you could move Program Files as well via the unattend file, but not anymore, for some reason.

I’m guessing that the servicing stack uses Transactional NTFS (TxF). TxF doesn’t seem to have a cross-volume constraint so why would the servicing stack add that constraint? Is this something that will be addressed in the future?

Also where are the Vista Rants?

"Unless you get the permissions and ownership (Local System I'm told, but having been burned once, I've just given up) just right, Windows Installer will delete the Join and start again as a "security measure"."

A string ACL is a great way to solve this problem.

LocalSystem requires full access to the C:\Windows\Installer directory to work ( and a few others to boot ).  If it can't get access to it then yeah, it will start taking over.

Re: cross volume transactions:

There are (at least) three considerations.

First, read this page from MSDN:

http://msdn.microsoft.com/en-us/library/aa365519(VS.85).aspx

For those who don't want to read the link, you don't want a transaction against system resources (files or reg keys) to become inferior due to a transaction involving off machine resources or resources which may not be available during boot.  If this were possible, we would be unable to resolve whether the transaction had committed or not during startup.

Second, note that NTFS isn't the only filesystem out there.  The Vista servicing code isn't willing to have half its rollback burden managed by the facility designed for it and the other half on a filesystem where some other rollback techniques are required.

Finally, if the directory is not on the Windows boot volume, there's good likelihood that it's shared across multiple OS installations which won't work.  In the Vista code we took it as a design point to avoid looking at individual resources (files, reg values, reg keys) and trying to make "should I change it or not?" decisions.

I could elaborate more at some point on the finer points here but the long and short of it is that sometimes (often or even usually) it works but sometimes it doesn't.  The documentation and test burden around trying to explain when it does and does not work was excessive and would probably be trounced by the support burden of people who just saw that you "could" do it and didn't try to manage the situation carefully.

And this is really the wrong problem to solve.  Installing system software on windows can't touch anything in any user's profile in the first place since the profile may be roaming etc.  The "real" design point we'd like to improve over time is that there is OS managed state (\users\all users and \users\public) in a location (\users) that people for fairly obvious reasons want to move off the boot volume.

The issue here is not one of intent but of making the best engineering choices with the resources available.  As is true of most of what Raymond writes about here.

Now if only someone could wring the necks of the bastard application designers that absolutely refuse to install to anything other than C:. While modern installers don't have this issue, I've had plenty of crappy installers (it always seems to be driver installers that won't let me decompress them with WinRAR or 7Zip, too...) that refuse to install anywhere other than C:

Michael:

Thanks for the excellent explanation and the link.

During my first read through the TxF section I missed that part about why the system drive's TM is so important, particularly the bit about the life of the in-doubt transactions and what that might mean if you write to system files.

When I installed Windows on my current home computer, I intentionally used unattend.txt to change the paths for the Windows, profile, and programs folders to something bizarre *specifically* to cause badly-written installers/malware to fail.  (And because I wanted to have a smaller C: partition, but that was secondary.)  I think it's worked out fairly well.

Ahh yes, the Installers folder!

I stupidly partitioned my work machine to have 20GB C, and 200GB D. Thinking I'd install everything onto D and leave C for a clean Windows XP.

After Product X,Product Y, 3 different Product Z installs, Product W, Product V and a whole lot more I had about 12GB of stuff in my installers folder. Product X had it's own cache of the CD contents somewhere else on C.

Lucky I had a copy of partition magic ready. An interface to change this folder (and copy and existing files in it) would be useful.

Product U is worse. It leaves about 600MB of files in the roaming profile after setup!

This is a bit off-topic, but can somebody point me to a place that explains what the LocalLow folder is supposed to be, and how is it different from Local?

John: LocalLow is like Local but for "low-integrity" processes. It's to separate their files from those of other processes as a security measure.

The most common low-integrity process is Internet Explorer (when browsing the web; it'll launch at normal integrity if you browse files on the local filesystem and for trusted sites).

I'm a little puzzled here. You can do it after you install XP and there is a whole article on the Microsoft site telling you how to do it.

It's a pain as you have to change all the myriad entries manually (though I think someone has written a script) but takes less than an hour, and I've done it on all my three machines.

And all the service packs have been applied with no problem. Possibly the block is a Vista thing. Another reason for not even thinking of Vista.

The problem with unattend.txt is that I install Windows from a directory on a FAT 32 Setup Partition, accessed from a bootable thumb drive, and can't be sure what drive letters will be applied to the partitions.

Stephen:

From what I gathered from the docs and Michaels comment, yes it’s a Vista thing. In XP if you apply an SP and something bad happens you will most likely need to go trough a manual recovery process (boo). In Vista you don’t because the SP will get rolled back at startup (yay). This is because it the Vista servicing stack uses Transactional NTFS (TxF), which didn’t exist in XP.

Unfortunately there is OS managed state in \users (\all users and \public) and these folders need to be on the same volume drive as the system folders. If they’re not and the servicing stack was okay with this then " if a transaction in which the system drive's TM is enlisted as a subordinate becomes in-doubt, and there are system files involved in that transaction, the system may not be able to successfully boot for a very long time (the life of the in-doubt transaction, which could be weeks in length) because system files could be locked by the in-doubt transaction"

So the servicing stack folks had a decision to make.

1) Don’t use TxF

2) Use TxF but don’t allow \users\all users and \users\public to be on a different volume than system

3) Write psychic code (never a good thing) to figure out when and when not to use TxF

4) Use TxF but be okay with the potential that machines may not boot up after applying an SP.

I think the option they when with (number two) was the best one. (Assuming they couldn’t move "all users" and "public") for other reasons.

Remember you can still change the location of a lot of the stuff you care about like \users\stephen\documents it’s just \users\public and \users\all users\ that can’t be moved.

We're confusing several points here.

Moving the users directory after initial installation is just not supported today.

For better or worse, absolute paths to directories under there are recorded all over the place.  Stephen thinks he found the ones that matter but I guarantee you that you haven't found them all.  They can be stored in text files, binary files, compressed binary files, encrypted files, etc.

One of the reasons you can only do this during initial deployment is because there is some hope that:

1. The OS installation code found all the places that have to be munged and has correctly munged them

2. In case #1 is wrong, since the scenario here is about OEMs shipping images or corporate deployment of images, presumably they will undergo adequate testing before deployment.

This argument has absolutely nothing to do with the cross-volume TxF issues.

I can't really answer about path interpretation in the OS installation environment; as I alluded to before the intent is that someone using the WAIK to author unattend.xml tests their deployments so they'll probably know all about what the volumes are on the machines that they're deploying to.

-----"We're confusing several points here."-----

True, but without wishing to appear ungracious it is you and Raymond who are the cause of much of the confusion.

Firstly, can we presume that both you and Raymond are talking about Vista, and nothing you say (apart from the fact you can use an unattend.txt file to change the setting) applies to XP? Remember that XP is by a long shot the most frequently installed version of Windows.

Secondly when you say "Moving the users directory after initial installation is just not supported today" you mean MS no longer suggests it for Vista. It obviously can be done, basically the same way as with XP, since there is a post higher up from somebody who has done it with Vista.

"For better or worse, absolute paths to directories under there are recorded all over the place.  Stephen thinks he found the ones that matter but I guarantee you that you haven't found them all" I can pretty well guarantee I have. But that is because I changing the path to the profile was the first thing I did when the machine rebooted after the initial install. I wouldn't dream of trying to do it after other programs had been installed.

What is the situation going to be like with Windows 7? Or is my copy of XP going to be still in service in the decade after next? The reason I move the whole Documents and Settings folder is that things such as Word Templates end up in strange places if I just do it piecemeal.

And. although you'll hate me for saying this, why don't you do what Linux installs have been able to do painlessly for ten years or more, and have the installer partition on the fly, and have all user data in a separate partition from the system volume.

Re: do what Linux does:

Pretty much the same reason that Linux doesn't do all the great things that Windows does better.  It takes time and effort to get things done.  And for Windows, generally they get done in the order that makes sense for the business.

If you would like more perspective on this you should visit the "Engineering Windows 7" blog.