Mr Snrub

So now you have different symptoms? First you had a new profile being created every time you logged on, and it was being left on disk but not used for subsequent logons. Now you have a profile created for the domain user logging on, but after logging off it is deleted every time? I've only heard of deletion of locally cached profiles when used in association with roaming profiles, typically on TS servers to stop their disks filling up with stale user profiles... When you are logged on as a domain user, what is the folder created under C:\Users? username? username.domainname? username.temp? I would expect a temporary profile to get deleted at logoff, but you should get a balloon popup presented in the notification area to let you know when you have one immediately after logon, it's far from subtle... Create a brand new domain user called TEST and log on for the first time - look at what profile is created, make a small change like desktop wallpaper, then log off. Log on as a local user account, check in the C:\Users folder - is TEST still there? (if yes, named as what?) Log back on as TEST - is the wallpaper change reverted? What profiles exist for TEST under C:\Users now?

What about the other 2 questions?Also, is this domain user able to drill down into each of those profile folders, or do they get access denied? If you check the Security tab on one of the profiles, who is listed (users & groups), and what type of access do they have?

Are you using a roaming profile for yor domain user? If you log off, wait 30 seconds, then log back on again, are the changes still lost? (Or only specifically after rebooting?) If you logon as a local user account, are the changes saved? If you check in %systemdrive%\Users, do you see a whole load of profiles for the same user, ending with .000, .001, .002, etc.?

There is already FSB throttling to have dynamic power consumption under load, but in effect what you are talking about here is core parking, and it's already in Windows 7 / Server 2008 R2: http://blogs.technet.com/mattmcspirit/arch...-in-action.aspx A lot of work was done in NT 6.0 for power management, and improved even further in NT 6.1.

The nice thing with Windows is that it's a symmetric multi-processing (SMP) OS, so you know every thread on the system is treated equally (taking into exception process priorities) - it sounds like you would find the history of the thread scheduler (and possily memory manager) an interesting read, I recommend strongly that you take a look at Windows Internals. One common misconception is that dual-proc systems are twice as fast as uni-proc counterparts - the performance can't scale linearly due to controlled access to shared data structures and synchronization between processors - but Windows does take advantage of multiple processors itself, even if none of your applications do. Up to Windows Server 2003, the OS loaded either the uni-proc (UP) or multi-proc (MP) kernel at startup - from Vista onwards there is only 1 kernel now, and with Windows 7 there have been some cool advances like getting rid of the dispatcher lock entirely. This webcast from Mark Russinovich is interesting viewing too.

Your single thread is one of many that is (most of the time) "ready to run", so it pre-emptively shares all the available CPU time with every other thread in the same state - it doesn't just get associated with a processor and run forever until it decides to stop. (Physical) processor affinity can have some value because of the ability to get high L2 cache hits, but ultimately if your thread's turn comes around to get some processor time, you want it to use whichever processor is available right now, not wait around for a specific one. You have to understand that the system has threads of its own, then there are services running in the background, then the shell itself has threads of course... your apps' threads are not the only ones that need love

If you boot from the DVD and format partition 1 alone then select it as the destination, you will likely end up with 2 entries in the BCD (held on partition 0) to boot into Windows 7 - the original one will be left behind.If you want a single boot entry by doing (yet another) reinstall, then format partition 0 as well as partition 1. Alternatively, you can use BCDEDIT from an elevated command prompt to find & remove the old reference. Use bcdedit with no arguments to list the Boot Loader entries - "{current}" is the indicator of which entry your current instance booted from, and if you have a second entry with the same values for device and path, then there is your old invalid reference. You can take the GUID in the identifier field and use that with bcdedit /delete {your GUID} If you enter bcdedit /delete /? at a command prompt then you can see the syntax with examples. As an example I made a duplicate entry in my BCD with the command bcdedit /copy {current} /d "Test Entry", and here is the output from bcdedit afterwards: Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume1 description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {3febdef3-7348-11de-b396-a2b5a893540b} displayorder {current} {3febdf03-7348-11de-b396-a2b5a893540b} toolsdisplayorder {memdiag} timeout 5 Windows Boot Loader ------------------- identifier {current} device partition=C: path \Windows\system32\winload.exe description Windows 7 Ultimate x64 locale en-US inherit {bootloadersettings} recoverysequence {3febdef5-7348-11de-b396-a2b5a893540b} recoveryenabled Yes osdevice partition=C: systemroot \Windows resumeobject {3febdef3-7348-11de-b396-a2b5a893540b} nx OptOut debug No Windows Boot Loader ------------------- identifier {3febdf03-7348-11de-b396-a2b5a893540b} device partition=C: path \Windows\system32\winload.exe description Test Entry locale en-US inherit {bootloadersettings} recoverysequence {3febdef5-7348-11de-b396-a2b5a893540b} recoveryenabled Yes osdevice partition=C: systemroot \Windows resumeobject {3febdef3-7348-11de-b396-a2b5a893540b} nx OptOut debug No I then entered the command bcdedit /delete {3febdf03-7348-11de-b396-a2b5a893540b} which returned the result "The operation completed successfully.", and here is the output from bcdedit after this: Windows Boot Manager -------------------- identifier {bootmgr} device partition=\Device\HarddiskVolume1 description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {3febdef3-7348-11de-b396-a2b5a893540b} displayorder {current} toolsdisplayorder {memdiag} timeout 5 Windows Boot Loader ------------------- identifier {current} device partition=C: path \Windows\system32\winload.exe description Windows 7 Ultimate x64 locale en-US inherit {bootloadersettings} recoverysequence {3febdef5-7348-11de-b396-a2b5a893540b} recoveryenabled Yes osdevice partition=C: systemroot \Windows resumeobject {3febdef3-7348-11de-b396-a2b5a893540b} nx OptOut debug No

File copy speed estimations can only come from "amount of data transferred in the last X seconds", so the initial guesstimates cannot be accurate. Speed of copying files can be affected by: - amount of system cache available - filter drivers such as AV or backup agents (also firewall filter drivers if the copy goes over a network) - fragmentation of the source data - location on the physical disk platter where the data resides: the closer to the end of the disk, the lower the read/write performance

Very simplified (it is an OS function): All the threads on the system in the "ready (to run)" state sit in a single list on XP - this is where the scheduler will pick the next thread to run from when the currently running thread enters the "wait" state or reaches the end of its allotted time slice (quantum). So if the number of threads "ready to run" is greater than the number of logical processors, threads will bounce around processors as they reach the head of the list and the processors become available through pre-emptive scheduling. (With Windows Server 2003 this single list was replaced with per-processor lists, which makes better use of the CPU cache and reduces delays by having to lock the system-wide dispatcher database - this does not mean that processors can go idle when their list alone is empty, however, as they can yank threads from other processors' lists.) For an excellent, detailed description of the whole design, see Windows Internals 4th Edition - chapter 6 : Processes, Threads and Jobs. (The 4th edition covers up to Windows Server 2003, and the new 5th edition covers Windows Vista/Server 2008 as there have been major redesigns under the hood.) Edit: What cluberti said *mental note, preview posts before submitting*

Your onboard graphics chipset most likely has no RAM of its own, so robs a region of the system RAM for itself - in your case 64MB.Sometimes this amount can be changed in the BIOS, e.g. from 16MB-256MB. Only advice I can suggest is to check for device & chipset drivers before installation so you're ready to roll, or at least are aware of which things don't have Vista-specific drivers for.

There might be a smarter way that I don't know of, but out of the box you can use the folder as the basis for a new toolbar and then shrink it down to its smallest size - the ">>" icon the acts as a hack-job jump list. There is this tool "Jumplist Launcher" that I've not tried myself to know if it does what you want, but it might be worth investigation: Jumplist Launcher

UDP port 137 is used by NetBIOS Name Service. (In addition to UDP 137 you often see UDP 138, TCP 139 and TCP 445 - the latter being "NetBIOS over TCP/IP", also the primary port for SMB traffic.) You sure it was 192.168.1.225 and not 192.168.1.255? The first would be a unicast (packet sent explicitly to one machine), the second would be a broadcast (client "yelling" to everyone in the subnet, the old method of network discovery).

Start / All Programs / Windows Virtual PC > Windows Virtual PC[this opens a window with your virtual machines, and a toolbar specific for it] Click Create virtual machine on the toolbar [i named mine Test] Complete the configuration wizard, then right-click on Test and click Settings [Now you have your VM properties up whilst the new machine is offline, no Integreation Features are installed yet as there is no OS] Select DVD Drive on the left, then Open an ISO image on the right, use the Browse button to locate the 32-bit bootable ISO you want [Now you start your new VM and it boots from the ISO] I just verified this with a Win7 RTM x86 ISO image and went through the install - first boot is from the DVD as there is no bootable OS on the VHD, and after the first stage of setup each subsequent boot is from the VHD directly. Once the OS is installed (XP SP3, Vista SP1 or Win7 minimum), Tools / Install Integration Components adds the software into the VM to allow the host to interact with it for extra functionality. (Before the OS is installed, if the mouse cursor is captured within the window, use CTRL+ALT+left arrow to release it.) In the Settings sheet for the VM you will now see the various Integration Features can be enabled/disabled to suit. As the boot order is VHD before DVD, if you already have an OS on the VHD then you will need to change the virtual BIOS boot order before you can boot from an ISO or DVD - hit DEL immediately on starting the VM during its very quick POST, then go to Boot / Boot Device Priority.

Odd indeed - have you taken a network trace from a client after you unplug/turn off the primary DNS server and then try a simple name resolution (open a web page, ping a server, enter \\servername), to see if there are even any UDP port 53 packets being sent to the secondary DNS server? What happens if a client is rebooted and doesn't get a response from the offline primary DNS server from the first moment, does it use the secondary one then?

Yes - the license entitles you to have 1 installed copy of the OS, either architecture, and the key works for whichever architecture you pick.

If you delete it, the list of all the installable packages is presented, just like Vista used to if no product key was entered during Setup.The trick is you need to be able to edit and repackage the ISO, leaving it intact (I know from experience that MagicISO wasn't able to manage this for whatever reason). Alternatively, you could try something like this, though I've not tried it myself to vouch for it.

Sanboxie FAQ

It seems your needs would be better suited by a router instead of a multi-homed PC. As for why the design changed for ICS, seeing as the networking stack was written from the ground up for Vista, it was probably reviewed for security to specify a private NIC rather than assume all NICs - also the functionality you are looking at is more of a "server" feature (RRAS/IAS).

Also from Forum Rules, for daryln:

Yeah, unless I misunderstood the last post from the OP, he said copying over the network to write to a share on the C: drive is fine, but copying the same data to write to a share on the mirrored RAID volume is slow.At this point I'd be looking at write performance to that RAID set by bouncing a file back and forth between the 2 local volumes.

So it's sounding more like disk writes to the software RAID is slower than reads, if I follow you correctly? The iperf test and your local disk share test would imply the network throughput is not the issue. If you copy a huge file (or a collection of files) between the local volumes, is the C: -> RAID slow but RAID -> C: fast? Mirrored RAID writes can be slower than single disk writes as each I/O turns into 2 and both have to report completion, whereas reads don't have that problem (either device, or the same one every time, satisfied the single I/O request). Software RAID in particular is something I've avoided because of this kind of issue.

Are the machines in a domain, and have you looked at SMB signing? Have you taken a look at a network trace copying the same file in both directions so see what is different? (I would be looking at MTU negotiation, sliding windows, SMB block size 64k vs 4k, selective ACKing, delayed ACKs, that kind of thing.)

Okay, I did an in-place upgrade of Vista x64 SP2 to Win7 x64 RTM after creating some dummy files in the Documents and Music folders in the user profile. The profile contents were successfully migrated, and there were 2 hidden folders created in the root: $INPLACE.~TR and $WINDOWS.~Q. I had to change the Folder Options to show hidden files and folders, and then grant myself permission to access the 2 folders when prompted, then I was able to browse them. Take a look and see if you can find those folders, and do a search for *.mp3 when you are in them in Explorer...

Okay, so we know it's something specific to the virtual network bound to the physical NIC - the same partitions communicating using the same disks over a private virtual network run at a reasonable speed, yes? At this point I'd be looking at what options exist for updating the drivers in the root partition for the NIC. I would move all child partitions onto a private or internal network temporarily, then remove the external virtual network, giving it back to the host. Then I'd check for different drivers for the NIC and install them, and ensure in the properties of the NIC that all "advanced" features are off (jumbo frames, offloading, etc.). Then I would recreate the external virtual network and move the child partitions back onto it. (You would have to move the child partitions off the virtual network first, as Hyper-V Manager will not let you delete a virtual network which has partitions on it.) Does the host have a dedicated NIC, and you are using a separate NIC for the external virtual network? Or is it just 1 NIC used by the host and VMs?

KB953940 shows a scenario where an XP to Vista upgrade can throw some odd issues with the "My Music" > Music migration - I realise you said this was a clean Vista installation, but this is also why I cannot see how you managed to get the old XP profile under Documents in the first place... The article mentions the following path used during the Vista upgrade, ir might be worth checking if a Win7 upgrade creates a similar folder when migrating user data: %SystemDrive%\$INPLACE.~TR\Machine\DATA\Documents and Settings\<username> (A WINDOWS.OLD folder would imply a clean installation on the same volume as a previous Windows install, not an in-place upgrade, that's why you don't have one - but there may well be a "$INPLACE.~TR" folder...)