One more thing, any third party software should be investigated before using it with W7. Outpost has some incompatibility issues I saw in a google search. Don't know for sure why.

Let W7 run with it's own security for a while till it's updated. I received numerous compatibility updates after the install. Give it a few days to adjust I'd think.

Something's screwy on the install of W7.

Clean fresh install though, with no ancient third-party software on it (yet), just Office and some crucial shareware.

Why would a language bar come up without an office program?

It's a standard feature of Windows, dating back at least to XP, but I think 95 may have had it as well. Like I said, maybe it's only activated on localized versions of Windows. It's not a part of Office. It's a toolbar that installs on the taskbar, next to your "quick launch" items. It has buttons on it to select input language and keyboard, in case you have more than one keyboard installed. On XP it's a good idea to disable it, because it's easy to accidentally do something that causes Windows to change the input language, and suddenly I can no longer type in Polish. However, if you are a translator like myself, or if you are simply bilingual, this is useful, since you can very quickly alter between different languages, which may require different keyboards (say, English and Russian, or even English and Spanish to get the accents).

Did you update any drivers through windows update-
ie-device manager-right click-update drivers.
Video controllers and ide controllers and network cards.

Who knows what Windows Update installed! I just let it run its course, so it prompted me a few times to reboot, but nothing major. There is no way to know beforehand if a particular update will mess things up, and trying them one by one would take ages. I hoped at this time the updates wouldn't be excessively bad - but then again, I should have done what has kept me safe so far: wait for the first service pack.

Are you running as admin? Even then sometimes I have to right click and choose 'run as admin'.

Yes, I was running as admin, with UAC set to default until I ultimately disabled it today.

It would be smart I think to disconnect any drives that you are not installing W7 on, then reconnect.

Just like it would have helped to unplug the secondary monitor, yes. But really, this is just voodoo to placate a crazy OS. I won't be stooping to unplugging internal drives, unplugging the monitor is where I draw the line

W7 works best to use a password to logon, a requirement for some things to work right.

I used the same username/pass as I had on XP. Kept LAN settings at whatever the installer made them. I had connectivity from the get-go, and everything else had to wait.

Also is this an upgrade W7 dvd? Then you have to have vista or xp already on the drive and working. The install options will let you do a clean install by choosing custom install. It will save your old version as windows.old.

Clean install, preceded by wiping the XP system drive and creating new partitions. You cannot upgrade XP to Seven, the installer refuses to do it (and I wouldn't try anyway).

Surely the issue is a BIOS issue - how can windows enable dual monitor access before it even starts up?

Well, in my case it was truly weird, but Windows *was* already up, in its own way. The PE environment is practically a fully-capable Windows, and it certainly has all the hardware support it needs. The strange thing was that during one phase of the installation, a short while before it prompts for the product key, it switched to the other monitor - the one that the video card considers secondary. I'd love to have an explanation for it.

The thing is, this is potentially an awful time-waster. My secondary monitor happened to be powered on only because I was creating my final backups in XP, then rebooted to the installation DVD, and didn't bother powering it off. If I had shut down the system first, I would probably have turned off both monitors using the power buttons, and it's as likely as not that the secondary monitor would have stayed off for the installation. If that had happened, I would not have seen the installer switch monitors. When the primary monitor went blank as it did (no signal), I'd have thought the installer crashed or hung, and I might have restarted the installation from scratch (and cursed profusely!) until it would have dawned on me to power on the other screen.

There is a programmer at Microsoft who needs some... re-education

I used the same username/pass as I had on XP. Kept LAN settings at whatever the installer made them. I had connectivity from the get-go, and everything else had to wait.

That's probably why you have permission issues - the computer name will not be the same as the old XP set up and the Workgroup won't be the same either (XP defaults to MSHOME and Windows 7 defaults to WORKGROUP workgroups) so if you have other connections with shared folders you probably won't see them.

Permissions are set by user name and computer name so that could account for the saving files and keeping settings issues - though why this is happening without an error message popping up I don't know.

I have to say I upgraded from a clean install of Windows Vista HP to Windows 7 Pro and I have had absolutely no issues at all.

I guess the best way to upgrade is to do a clean install and also make use of the files and settings wizard to move data to the new system or else make sure that your network settings are identical to your earlier installation to avoid broken permissions and shared folders.

- so what may be the reason cmpm and tranglos are having a quite different experience?

Oh, yes, that really IS the question, isn't it

- so what may be the reason cmpm and tranglos are having a quite different experience?

The answer is simple: YMMV

The harddisk issue is just simply that the files were created on another OS and so aren't owned by the Win7 user accounts.

In honesty UAC does need a bit of a attitude change but almost all cases of improving security there is some increased effort on behalf of the user.

Also a guess about the hot keys, perhaps they weren't setup with the application running with admin privileges hence those hot keys don't apply to privileged process. Only a guess but it would be the most appropriate behavior. User applications shouldn't be allowed disrupt admin programs.

The harddisk issue is just simply that the files were created on another OS and so aren't owned by the Win7 user accounts.

- can this be solved by mass re-writing of the attributes?

... whereas cmpm and tranglos upgraded from XP, no?

Moving from XP to Win7 is always a clean install, there is no upgrade, (what happens after that comes under YMMV as Lashiec said ).

I've done the same thing, XP Pro -> Win7HP, generally positive result but a few annoyances regarding things that were just so much easier to do under XP.

eg. sharing folders for access by anyone is a lot easier under XP.

OK, here's a few things to consider.

Apps failing to write userdata: this sounds serious, and weird - haven't run into it myself, so I'm a bit stumped as to why it might be happening. Read something somewhere sometime () that you can end up in weird situations if you install your apps with UAC disabled and then re-enable UAC, but... *shrug*

Hotkeys: there's several ways to define these, one of them has the possibility to override existing hotkeys (ie., built-in Win+X). This method requires setting up a system hook, injecting DLL into all processes, (try to) un-register hotkey in all processes (because you don't know which one has registered the hotkey), and then re-register the hotkey. It should be obvious why this won't work for elevated apps if the I-want-hotkey app is running from a LUA. Doesn't explain some of the Win7 hotkey weirdness fully, though!¹

Permissions on secondary drive: this has already been mentioned by Carol and Eóin, but needs a slight clarification: it's not because of acccount/computer name, but the SID (not GUID, they look slighty similar but aren't) assigned to your user account; if you upgrade Windows, the SID should carry over, when you do a fresh install you get a new (random) one. This is not a Windows 7 thing, but rather it's generic NT. You'll see the same if you carry an NTFS-formatted USB drive to another computer. Too bad there's no built-in "really take ownership and fix permissions of all these files, and get rid of the orphan SID".

Monitor woes: sounds weird too, defining primary monitor works fine on my win7 installation.

Win+{up,down} is a YMMV thing - I really like the behavior, as I often go between maximized and "restored" state. Maximized firefox is awful on a 1680-wide screen

¹: I override Win+F to locate32 and Win+E to xplorer², but in some applications those hotkeys are overridden - even though those apps aren't elevated! I'm pretty stumped as to why this happens, but I think it might happen in apps programmed in MFC.

Compared to one checkbox and clicking OK, yes.  Plus it just worked all the time here and it's so bl**dy slow to access the shares under Win7 from other computers not running Win7, (obviously a subtle prod by MS to get you to upgrade all your computers).

"Simple sharing" in XP never worked very well for me in a non-homogenous LAN... definitely not as no-brainer as the simple read/read-write sharing you could do in Win9x... thus I always ended up doing things properly, with matching user accounts (and passwords!) on all the involved machines... which is a PITA if you've got a lot of machines and no domain controller.

"Slow to access on non-Win7 machines" - in which way? Slow transfer rates, or is it "just" the initial connection that takes some time to establish? Haven't experienced slow transfer rates, but (on multiple Windows versions) I've had slow initial-connect delays when user accounts and/or security settings didn't match across machines.