cquirke (mvp windows shell/user)

On Fri, 14 Jul 2006 00:38:46 -0700, "cfman" <comtech.usa@gmail.com>

Long post, so this is 1 of 2 in a series!


Generally, you can't do that.

That's a pretty DIRE reflection on XP maintainability, isn't it?


Quite. But Windows doesn't such that badly (though it will if you
keep re-installing it); you'd do better to learn how to maintain the
same installation than "just" re-installing all the time. See...

http://cquirke.mvps.org/reinst.htm

I do agree that XP gives you nothing to help you reclaim your PC from
malware; in spite of obvious real-world mileage, the approach is still
"we will make the OS so secure you'll never be infected". Useless.

Do a Google for "Bart PE". An effective though demanding solution, at
least it's available - no thanks to MS. By 2006, I'd expect techs who
profess to be able to handle malware will be using Bart or some Linux
equivalent to approach active malware.


Sure - it's what I do on every PC I build, but it goes a bit deeper
than moving the whole of "Documents and Settings" (D&S).

Not only may moving all of D&S be impossible, the contents of D&S are
so poorly arranged that one is obliged to re-organise them in order to
facilitate clean and effective backups. Problems:

1) D&S is itself a risk for malware activity

Specifically, it includes the StartUp groups for AllUsers and each
user account. Malware can drop intio these and thus start whenever
Windows starts, and so persist in active form when D&S is preserved in
toto. Less obviously, malware can add or replace shortcuts in Start
Menus and SendTo, to persist in that way.

This makes D&S dangerous to blindly restore after avoiding having to
deal with malware activity by "just" destroying the installation. It
also makes it dangerous to write-share D&S on the network, as anything
infecting other PCs on the network can drop into yours in active form.

When "the Internet" is treated as "just a big network", the
implications are obvious, dwarfed only by the stupidity of
full-sharing all HD volumes with known "hidden" share names anyway.

2) D&S is a risk for malware entry and persistence

By duhfault, IE dumps incoming downloads in "My Documents", and both
MS and MSN Messenger dumps "My Received Files" in there as well. More
annoyingly, you can't control this behavior in MSN Messenger until
someone has logged on and started using it (thus being at risk).

So not only does D&S contain workspaces most likely to act as malware
points of entry (Temp, Temporary Internet Files, desktops), even a
narrower backup of "My Documents" is likely to be polluted.

3) D&S and "My Documents" is bloated with huge material

D&S contains a separate "Temporary Internet Files" for each user
account, and by duhfault these are bloated to massive sixze. Who
needs 1G of old web pages? Everyone, according to the IE team.

The "My Pictures", "My Music" and "My Videos" subtrees are nested
within "My Documents", so even a single "My Documents" subtree can
become too massive to drag onto a CDR or DVDR for easy backup.

4) XP's "CD Burning" is within D&S

Remember, we're dealing with a maintenance skill set so poor that the
plan is to "just" destory the installation rather than confront active
malware. The obvious way to attempt this is to simply drag the whole
of D&S onto a CDR or DVDR, and let XP's native burning support do the
rest. This will fail because XP creates a copy of everything to be

5) Many apps will not re-use data without "special treatment"

The applications most likely to be used by default, include Outlook
Express, Outlook, Windows Address Book, etc. These tend to break all
the rules of data survivability:
- data version bound to application version
- application version bound to a larger bundle (Windows, MS Office)
- atomic data sets that cannot be merged with existing data
- deeply-buried paths requiring more work during data recovery
- reliance on intra-application "import" and "export"
- fragile internal data structure that crashes app when broken

Simply banging new datasets in place not only destroys (rather than
merges into) whatever was there before, but may not be accepted by the
application as valid or current data anyway.

6) Malware is hidden within mail stores

You may amend the "just destroy and rebuild the installation, then
restore data" to "just destroy and rebuild the installation, then
restore data, but scan the data set before use" in order to reduce the
inevitability of your brand-new, un-patched installation from falling
prey to malware within a few hours or days.

But these scans can't penetrate the maliboxes to detect malware hidden
inside. Such malware remains a clickable risk, or (if it exploits the
IE HTML renderer or other exposed surface code defects) a risk that
can run the malware without any clicks.

The way around this is to choose a non-default email app that does not
hide incoming attachments within mailboxes but creates them as loose
scannable files, and that can be set not to use Microsoft's code to
process HTML "message text". Eudora's one such program:

http://cquirke.mvps.org/9x/eudwhy.htm


OK... you get the message: For what you're trying to do, simply
dumping all of D&S off C: isn't going to do it. See next post :-)

Drugs are usually safe. Inject? (Y/n)

cquirke (mvp windows shell/user)

On Fri, 14 Jul 2006 00:38:46 -0700, "cfman" <comtech.usa@gmail.com>

Long post, so part 2 of 2

Yep - you already know why moving all of D&S isn't the ticket :-)

OK, this will go through the whole thing from before you install
Windows in the first place...

1) Decide what partitioning you want

You don't need two physical hard drives to separate the core software
installation from data and other content. You can partition a single
hard drive so that it appears to be multiple drives. Typically, you'd
create a porimary C: for the installation and an extended partition
containing logical drives for everything else.

I'l use the word "volume" from now on, to refer to partitions or
logical drives that can be accessed by a drive letter. Each volume
can use one of three file systems:

a) NTFS
- no data recovery or interactive repair tools
- no access from DOS, DOS mode or Win9x
- only choice if files are over 2G and 4G in size
- only choice if you want file-level user security
- efficient for small files
- efficient for large numbers of files per directory
- paging-efficient 4k clusters even if > 8G

b) FAT32
- good data recovery and interactive repair tools
- access from DOS mode and Win9x if < 137G
- no support for files over 4G (some contexts, 2G)
- XP can't create volumes over 32G (use other tools)
- paging-efficient 4k clusters only if < 8G

c) FAT16
- better data recovery and interactive repair tools
- access from DOS, DOS mode and Win9x if < 137G
- maximum volume size 2G (4G if only for NT OSs)
- tiny file system structures, but larger cluster sizes

See http://cquirke.mvps.org/ntfs.htm

If data recovery is more important to you than being able to block
data access from other users, I'd avoid NTFS for data volumes. In
fact, because there's not even an interactive repair tool for NTFS, I
currently avoid NTFS altogether, and use a FAT32 C: just under 8G
(8174M) so that I have paging-friendly 4k clusters.

Plan what you will put where. For example, by keeping all core code
off volumes other than C:, I can disable System Restore on all volumes
other than C: - thus reducing head travel and overhead.

Plan your partitioning for speed. The further "away" the volume, the
slower the access may be if most activity is at the start of the drive
in C:. I keep C: small, so that no matter how fragmented it is, the
heads never have to travel very far, and the next volume is not too
far away. Next, I use a 2G FAT16 (!) logical D: for data, for ease of
data recovery; only small user data files go here. Then there's a
huge E: that starts pretty "close" to C: and goes on for most of the
drive, and then a small F: at the end for seldom-used crucials.

Plan for survivability and ease of maintenance. You're likely to
suffer crashes and bad exits, and that means having to wait while XP
auto-fixes/botches the file system on startup. If that's one huge C:,
you will wait for ever or you'll bad-exit (again) so you can Esc the
brief "I'm going to tie up the system for hours" prompt. If C: is
small, it will take a time short enough to live with, plus whatever
gets messed up won't mess up your data.

I apply the following to volumes C: to F:...
- C: core code and temp, small SR, allow AutoChk
- D: small user data, disable SR, disable AutoChk
- E: everything else, disable SR, disable AutoChk
- D: cold storage and backups, disable SR, disable AutoChk

If you want FAT32 volumes over 32G, you have to use better tools than
what XP provides. I use BING from www.bootitng.com without installing
this as a boot manager, i.e. cancel install and do "partition work".
Due to bugs, the best DOS mode FDisk is limited to capacities < 100G,
while the standard FDisk from Win98SE and earlier fails around 50G.

2) Install your OS(s)

If you want to dual-boot to the DOS mode part of a Win9x, you can, as
long as you do not use that DOS mode over the 137G barrier. With the
partitioning I use, I use DOS mode's Scandisk to maintain C: and D:,
preferring it to ChkDsk/AutoChk because it allows interactive control.

To do this, you would first "install" the DOS mode to C:, e.g. by
booting the relevant DOS mode diskette and using Sys C:

I'd use the DOS mode from Win98SE, as it supports FAT32 and has an
effective EBD (Emergency Boot Disk). Anything older than Win95SR2
will not work with FAT32 and should be avoided.

Once your DOS mode is in place, you can install Windows XP and it will
preserve your previous OS as a bootable alternative. See also:

http://cquirke.mvps.org/multplan.htm

http://cquirke.mvps.org/multboot.htm

http://cquirke.mvps.org/multos.htm

Do not create multiple user accounts (more on that later)

NB: Do not do anything else after installing XP until (3) onwards!!

3) Set up your shell locations

Often (but not always) you can get Windows to track path changes by
right-dragging things around (rather than the usual Copy, Cut and
Paste) and then renaming them. The trick is to do this early, before
secondary path references have been derived from initial values!

First, we will de-bulk and them move "My Documents"
- start two instances on Windows Explorer and tile them
- navigate destination window into E:
- navigate source into D&S, user account, My Documents
- rt-drag "My Music" to E:, then rename "MUSIC"
- rt-drag "My Pictures" to E:, then rename "PICTURES"
- start Movie Maker, then exit it
- rt-drag "My Videos" to E:, then rename "VIDEOS"
- go up a level in your source window
- rt-drag "My Documents" to D:, then rename "DOCS"
- rt-click "My Documents" on desktop, Properties; set to D:\DOCS

Next, we will create and populate an E:\SUSPECT subtree for incoming
material, workspaces, and other high-risk things:
- navigate destination window to E:, create and enter SUSPECT folder
- navigate source window to Local Settings, App Data, Microsoft
- rt-drag "CD Burning" to E:\SUSPECT
- navigate to base of user account
- rt-drag "desktop" to E:\SUSPECT
- navigate to base of "AllUsers" user account
- rename "desktop" to "alldesk"
- rt-drag "alldesk" to E:\SUSPECT
- create new folder OEMAIL in E:\SUSPECT
- create new folder IMESS in E:\SUSPECT
- run OE; Tools, Options, Maint.., set mail store E:\SUSPECT\OEMAIL
- exit and run OE again, OK
- run MS Messenger; Tools, Options, Pref..; set E:\SUSPECT\IMESS
- delete "My Received Files" from D:\DOCS
- run IE; Tools, Options; set IE cache to 20M (don't relocate)

I don't use MS address book or Outlook, so if you want to do battle
with those data locations, insert your attempts here. I just walk
away from the whole mess and use Eudora instead...
- create location E:\SUSPECT\ATTACH
- install Eudora, choose Custom
- set data location as D:\DOCS\E-MAIL (it will create it)
- run Eudora; Tools, Options, Attachments; set E:\SUSPECT\ATTACH
- so safe mail can back up with DOCS, but risky attachments exluded

Finally, restart Windows and do some clean-up (be careful here!):
- run Regedit
- search for "\My "
- if reference is incorrect, change to point to new location
- the main one is setting IE to dump in E:\SUSPECT not D:\DOCS

Many 3rd-party apps will derive their paths from the shell paths you
fixed earlier - that's why it's best to do those changes first. You
can also apply these settings directly through their options, e.g. get
WinZip to use E:\SUSPECT\UNZIPPED not C:\UNZIPPED, Firefox to download
to E:\SUSPECT instead of Desktop, Winamp to rip music to E:\MUSIC
instead of "C:\My Music", etc. Fortunately, even if apps (or users)
do dump on the desktop, that's not in C: anymore, so no bloat.

I keep Temp and "Temporary Internet Files" for speed, though I trim
the size of "Temporary Internet Files"

4) Installing large apps and games

It's crucial to stop junk dumping in C: if you keep C: as small as I
do (i.e. as a 7.99G FAT32). All apps should be installed as "custom",
so that the installation path can be controlled. I install MS Office
and core deeply-integrated apps such as av and CD writing on C: for
speed, but all games, multimedia titles etc. go on E:

5) Debulking C: as Windows Updates pile up

Freshly-installed XP is highly exploitable, especially if pre-SP2. As
you apply Service Packs, patches and updates, the Windows subtree gets
bloated with old code files and so on - eventually, for every one
active file, the heads hgave to step over 3 to 4 "dead" ones.

Once again, you'd open and tile two Windows Explorers...
- navigate source to Windows base directory
- navigate destination to E:
- create and enter E:\XPSTORE
- rt-drag all (hidden) $NT... subtres to E:\XPSTORE
- rt-drag "ServicePackFiles" to E:\XPSTORE
- repeat the above after every update binge
- defrag now to consolidate free space
- defrag a week later to optimize renewed code

The above assumes you've set Windows Explorer to show all files, etc.

6) Multiple user accounts

Short answer: Don't.

Long answer: If you want to use multiple user accounts, then good luck
in figuring out how to set up the "default" account template so that
intelligent choices are used for shell folder locations and IE's web
cache size. By duuuuhfault it will be the same "all deeply-nested in
C:, and lumped together in My Documents" and "huuuge web cache".

Or you can run after these settings every time someone creates a new
user account so that Johnny can have a different wallpaper to Jenny.


Drugs are usually safe. Inject? (Y/n)

cquirke (mvp windows shell/user)

Previous posts cover that.

Apps that are hard-wired to dump in "Application Data" (or "Local
Settings\Application Data") I simply avoid.

Once you don't need "Application Data", and have moved Desktop and the
various "My..." ghettos out of D&S, the rest of D&S is disposable.

Only two? ;-)


Yep. This is the "backup problem":
- keep all wanted material and changes
- lose all unwanted changes

How do you scope between "wanted" and "unwanted"?

A "full system backup" ASSumes you can do so on the basis of time,
i.e. the backup is made before the unwanted changes took effect, and
you don't care about losing any wanted changes made after that time.

A partition image backup is the only way to preserve an XP
installation, because XP is too fragile to survive a file-level backup
and restore (even if you preserve *every* file).

But a partition image has to be restored in total, destroying
everything that was there before. You can't browse and choose the
bits you want to leave out, or selectively restore, and you can't have
it not destroy everything where it is restored.

An answer suggests itself:
- keep only the OS and core code in C:
- use SR to maintain a "system undo" on C:
- keep all data off C:
- keep SR disabled on all volumes other than C:

Even if you do seek to preserve your installation via image backup,
you are still relying on the great universal X-axis (time) to separate
the state you wish to retain/restore from what you want to loose.

This has always been doomed because viruses were generally written to
hide in dormant form (thus permeating all "full system backups") until
the payload trigger or date rolled around.

It's doomed for another reason now; your code base is no longer a
known-good boilerplate state, but is subject to barrage of real-time
updates to avoid malware exploiting its way into the system. Couple
that with a "network client" OS permanently connected to the 'net via
broadband, and you can join the dots from there.

Is "doomed" too harsh a word? Yes, in that it may be useful to have
an image backup to hand in various situations. No, if you are
speaking about "just restore your backup" as a generic fix that avoids
having to detect and manage active malware.

Yep - but fixable, at least it for the shell folders (though multiple
and new user accounts increase the hassle). To go through as much
hassle for a single app that's hardwired to use some deeply-nested
"Application Data" location may be a waste of time, compared to
dumping that application and using something more clueful.

See above - really, as a way of "never" having to detect and manage
malware, it's prolly less reliable than "in av we trust".

They have NEVER been a substitute for "safe hex" clue, just as "just
make backups" is not a substitute for maintenance clue.

PC-on-Internet is more difficult than advertised.
Live with it :-)


Yep - can be the case even with a month-old backup, and who wants to
lose a month's worth of updates and installations, let alone data?

No, a better approach is to:
- scope out incoming trash, infectable code, and integration points
- scope in clean data

Previous posts refer as a "how-to" :-)


Drugs are usually safe. Inject? (Y/n)