The unattend file lets you configure Windows while it’s installing, and in some cases it’s your only chance


Some Windows settings can only be established as part of the installation process. This is done with a so-called unattend file. (Remember, no matter where you put an advanced setting, somebody will tell you that you are an idiot.) In earlier versions of Windows, the unattend file took the form of an INI file, but Windows Vista hopped aboard the XML bandwagon, and the unattend file format changed to XML. The nice thing about using XML is that you can publish a schema so people can validate their unattend file without having to perform a test install (only to discover twenty minutes later that a typo resulted in an entire section of the unattend file being ignored, say).

If you spend a lot of time setting up computers, you can use an unattend file to answer all the Setup questions (like "enter your product key") so all you have to do is type "setup /unattend:myconfiguration.xml" and go out to lunch. When you come back, your machine will be installed and ready.

Here are two of the most popular unattend settings which must be set during installation. (There are a bunch of popular unattend settings for things that can also be changed post-install; for those other settings, the unattend file is not your only chance.)

Wait, the C:\Program Files directory isn't on the list of directories that can be relocated. There's a reason for that, which we'll look at next time.

Comments (32)
  1. Preemptive guess:

    Too many people hardcoding to c:Program Files

  2. Billy O'Neal says:

    @Lockwood, I don't think it's that. That's worked around easily with a Junction, symlink, or similar.

  3. Brian Friesen says:

    I discovered years ago that the unattended file allows you to join Windows XP Media Center to a Windows domain.  This is the only way to join XP Media Center to a domain, once XP Media Center is installed joining a domain is not permitted.  Although I suspect this is more of a bug and less of a feature. :)

  4. MItaly says:

    Out of curiosity: putting the profiles directory on some other drive is not such an uncommon thing, why are these settings made available only via unattended installation file?

    @Lockwood: the program files directory name is localised since the times of Windows 95 (e.g. in Italian editions of Windows it's c:Programmi), and only since Vista they started to create a compatibility symlink, so I wouldn't think that the problem lies there.

    [The path to the profiles directory gets incorporated into data written to numerous locations, often by third party components, so you can't change it after the fact. It's like trying to change your phone number after you already handed out your business cards. -Raymond]
  5. @Matteo Italia:  you're assuming that the programmers of some US English piece of software were smart enough to think about localization in the first place…

  6. MItaly says:

    [The path to the profiles directory gets incorporated into data written to numerous locations, often by third party components, so you can't change it after the fact. It's like trying to change your phone number after you already handed out your business cards. -Raymond]

    Sure, I know, but what I meant is: why don't you add a way to set them also during a "normal" (attended) installation, instead of requiring an unattended setup file? Is there some technical reason why it would be complicated to add a step to the installation procedure allowing the user to set them?

  7. MItaly says:

    @JamesJohnston: what I'm saying is that if for Microsoft it isn't a problem to change the Program Files directory name for localization purposes, it shouldn't even be a problem to let the user customize it freely. I'm quite interested in Raymond's answer, I think that the problem isn't the name, but there is some other caveat that prevents a free relocation.

  8. MC says:

    @Matteo Italia, that's explained in Raymond's sidebar "Remember, no matter where you put an advanced setting, somebody will tell you that you are an idiot."

  9. MItaly says:

    @MC: heh, I know, and I also know that "any new feature starts with minus 100 points", I was curious if this has always been omitted because it never got out of the "-100 points well" or there was some other reason.

    IMHO it wouldn't be wrong to add such a setting to the installer: after all, a fresh install isn't done by complete beginners (and the default would be to just use the "normal" locations). But, again, I may be biased from my needs, and there surely are items of much higher priority on the todo list.

  10. SuperKoko says:

    Sure, I know, but what I meant is: why don't you add a way to set them also during

    a "normal" (attended) installation, instead of requiring an unattended setup file?

    Very, very few people need to change FolderLocations. Adding a question to the setup would take the time of many people who don't care.

  11. anonymous says:

    What is the point of letting users change folders if the installation cannot be serviced?

    "This setting should be used only in a test environment. By changing the default location of the user profile directories or program data folders to a volume other than the System volume, you will not be able to service your Windows installation. Any updates, fixes, or service packs will fail to be applied to the installation. Microsoft does not recommend that you change the location of the user profile directories or program data folders."

  12. Jonathan says:

    I've always thought it was called an unattended file, and the "unattend" name stems only from the 8.3-compliant unattend.ini (it had other extensions too).

  13. Eric Brown says:

    I've redirected my Users directory to D:users (since that's on the big disk, not the small one), and updates, fixes, and service packs apply just fine.  Never had any trouble.

    I haven't tried redirecting ProgramData; that might cause some problems.

  14. Eric Brown says:

    I've redirected my Users directory to D:users (since that's on the big disk, not the small one), and updates, fixes, and service packs apply just fine.  Never had any trouble.

    I haven't tried redirecting ProgramData; that might cause some problems.

  15. Henning Makholm says:

    @Jonathan: The file itself is not unattended — it's the installation process that is. So the full unfolding would be "[unattended installation] file", and whether you shorten that first term to "unattend" or "unattended", it's a shortening in both cases.

  16. Powerlord says:

    I wish the company that set up my computer had moved the Users directory off from my SSD.

    Instead, I had to use the recovery console to copy it over, then junction its location on C to its real location on D.

  17. Alex Grigoriev says:

    [It's like trying to change your phone number after you already handed out your business cards.]

    Well, sometimes it can be handy.

    But jokes aside, the user-visible Program Files name can be different for different users on the same host, because of localization on the fly. The actual NTFS name is always Program Files now. Or so I think.

  18. xpclient says:

    There was the InstallDir="Windows" setting for Windows XP (Don't think an equivalent still exists for Windows 7/Vista).

    There were also settings which can be easily set by the unattended file which require registry tweaking later because no GUI exists. Like System Restore settings on Windows XP which also no longer work.

  19. Nick says:

    Ahhh, now I can put my user directory back in C:WINNTProfiles where it belongs!

  20. Joshua says:

    [The path to the profiles directory gets incorporated into data written to numerous locations, often by third party components, so you can't change it after the fact. It's like trying to change your phone number after you already handed out your business cards. -Raymond]

    If changing the directory only changed new profiles, nothing would break. In fact, the effect would be particularly desirable where the administrator account ends up on the C: drive along with Local Service & Network Service but all others end up on the D: drive.

    [It would still break the GetProfilesDirectory function, since it cannot return multiple directories. -Raymond]
  21. MItaly says:

    @Joshua: …which is what happens on *NIX machines with /root and /home. Yes, it would surely be a good idea.

  22. Anon says:

    I did some work testing Vista SP1, and while it may have been covered by other test groups, noone I know of tested the relocated folders scenario.

    I know of no reason it would fail, but I think it falls into the 'Unsupported' category, that you're welcome to try, and good luck with it, but you're on your own.

  23. Joshua says:

    [It would still break the GetProfilesDirectory function, since it cannot return multiple directories. -Raymond]

    Meh. It was possible in NT4 to move a profile (there was a well-hidden UI function that disappeared somewhere between NT4 and XP) that worked.

  24. Stefan Kanthak says:

    [It would still break the GetProfilesDirectory function, since it cannot return multiple directories. -Raymond]

    No, GetProfilesDirectory() returns the CURRENT path. It is needed only when a new profile has to be setup.

    The paths to existing profiles do not depend on GetProfilesDirectory() — except for "All Users" and "Default User" in NT4 and NT5.x; since NT6.0 the registry holds the full paths to "Public" and "Default":

    [HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList]

    "ProfilesDirectory"=expand:"%SystemDrive%Users"

    "Default"=expand:"%SystemDrive%UsersDefault"

    "Public"=expand:"%SystemDrive%UsersPublic"

    "ProgramData"=expand:"%SystemDrive%ProgramData"

    Also see "%SystemRoot%System32Configsystemprofile" in NT5.1 and later, as well as

    "%SystemRoot%ServiceProfiles" in NT6.0 and later.

    [HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList<sid>]

    "ProfileImagePath"=expand:"…"

    [Since the documentation does not say "current", odds are good that applications assume that all profiles are subdirectories of GetProfilesDirectory(). -Raymond]
  25. Joshua says:

    I suggest we cut this particular subtopic before we tick Raymond off.

  26. Cheong says:

    Very, very few people need to change FolderLocations. Adding a question to the setup would take the time of many people who don't care.

    Btw, just want to let you know that most of my friends like to switch system folders path to D or even E drive just hope to let malwares existance become more verbose.

    But then again they may not be considered average users.

  27. Neil says:

    There are people who call API functions to locate folders and then save the result using another API rather than using the first API again? Weird.

    And I can't believe it's so hard to change the default wallpaper.

    [The result may be saved for somebody who doesn't support "before using this string, call GetProfilesDirectory and put that in front." e.g., putting a file name into another component's configuration file. -Raymond]
  28. Stefan Kanthak says:

    [Since the documentation does not say "current", odds are good that applications assume that all profiles are subdirectories of GetProfilesDirectory(). -Raymond]

    That's why I proved this assumption wrong before you came up with.-)

    Since 10 years at least one user profile, and since 5 years 3 of them are not located in

    the path returned by GetProfilesDirectory().

    JFTR: since 15 years a Domain Administrator can place the "All Users" and "Default User" profiles for Domain Users in the NETLOGON share.

  29. Medinoc says:

    Does one need to fill *everything* in the Unattend file? I guess it's not possible to, say, change the folder locations via the file and set everything else interactively…

  30. SuperKoko says:

    > Does one need to fill *everything* in the Unattend file?

    No, you can leave some (or all) parameters for interactive installation.

    > I guess it's not possible to, say, change the folder locations via the file and set everything else interactively…

    It is possible.

  31. Medinoc says:

    Thanks. That's awesome.

  32. Butch says:

    And like GetProfilesDirectory(), %ProgramFiles% cannot refer to multiple directories and whould break if you try to adress programs in different directories, thus all batchfiles which use this variable to refer to programs would break.

Comments are closed.