Mr Snrub

Get them to download the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) package direct from microsoft.com and see if it fixes the problem. (The 2008 package has a different version of the runtimes so will not help.) I ran into a similar problem this week with a very Win32 console app I built in Visual Studio 2008 - because of 1 call to MessageBox() I had to install the Visual C++ 2008 runtime on the target (W2K3 or W2K8) machine in order to run the single .EXE. If I had built with Visual Studio 2005 then I guess I would have needed the Visual C++ 2005 runtimes, as your user does.

The user accounts on the ACLs from the XP system will be completely different to the Win7 ones, so only "well known SIDs" (like Administrator, Everyone, Authenticated Users, etc.) work on both (even if you name the accounts the same). User profiles in particular have permission inheritance disabled so users don't go poking around in each others' documents, so if anything is under "Documents and Settings" or was moved from one of those folders then that can cause issues. (Moving objects on the file system within a volume does not re-enumerate the permissions, so moving an object from a folder with inheritance turned off to somewhere with it turned on will not let the parent object's permission trickle down.) By default Windows will honour permissions placed on files, so the fact that you managed to copy the data when booted outside of the OS would imply it was a permissions issue on the items/volume (copying to another volume forces a file creation, so the ACLs for the target volume, if applicable, are used). Alternatively backup programs use the SeBackupPrivilege and SeRestorePrivilege to read & write to locations regardless of what permissions are set on them, or if the XP installation will no longer be used to boot then a taking ownership of the objects allows you to assign whatever permissions you want. You might find the root of a volume marked as system is also treated as a special case, like %windir% and %programfiles%, so it is worth creating a folder to put the data in (I tend to put stuff into \TEMP if it is in transit, so I know what to clean up afterwards). I don't think there is a bug here to fix, tbh.

Do you have file & printer sharing enabled on the target machine?(In the following commands, replace "remote" with the network name of the remote client, and "user1" / "user1pw" with the name and password of an Administrator on the remote machine.) If you run the following in a command prompt, what does it report? net view \\remote Have you tried psexec to run shutdown on the remote machine? Something like: psexec \\remote -s -u remote\user1 -p user1pw shutdown -s -t 0 You can't - local user accounts mean nothing outside of the machine on which they are defined, it is an isolated security realm.(The old-school method of creating the a user with the same name and password on 2 machines appeared to work as the security realm is first tried as the calling client, which fails, then as the remote client, which works - but the local user account is not being used for the remote authentication.)

Aha, so not even seen as a running task in the session... sounds like you managed to run it non-interactively somehow - not heard of that except through launching as a task.Does this happen for all user accounts? You can see the cmd.exe process running in Task Manager - is it running in your user session? (Add the Session column to the view) If you make a copy of cmd.exe and name it something like cmd2.exe, does cmd2 have the same issue? This is just Win7 logged on the console directly, right? Not a Remote Desktop connection or anything?

If the window is being rendered off-screen, this issue is as old as the hills, I remember hitting this in Windows 3.1 whenever I'd changed monitors/graphics drivers. For Windows 7, hover over the task in the task bar, right-click the preview window and click Move, then tap a directional arrow key on the keyboard once, then move your mouse – you will find the application window is attached to the mouse cursor until you click to drop it.

If you don't receive it through Windows Update or find it when seaching the Microsoft KB, don't install it. Even the wording of the articles on official non-security fixes from Microsoft say to only install the hotfix if you are experiencing the symptoms described - these hotfixes are not as rigorously tested as the ones delivered through Windows Update. If a hotfix package doesn't appear on KB then it was likely a private test package, totally unsupported and with possible instrumentation (debug code) which might impact performance without helping anything. Private packages are sometimes created to do extra logging or try to provoke a hard-to-find problem to identify the root - not often likely to "fix" or "improve performance". I would also be way of anything with a "v" in the filename - that means at least 1 version of the package didn't help or do what it was meant to (possibly even made things worse) I would recommend: 1. Let Windows Update keep the machine up to date. 2. Install other non-security updates if they are downloaded from a link on a Microsoft article or provided by Microsoft Support if you have the symptoms of the problem described. 3. Wait for service packs (and backup or test on an unimportant machine before rolling out).

Mixing up XP's prefetch and Vista's system cache usage there.Prefetch waits for a process to start and then monitors the file I/O activity for the first portion of its lifetime, making a note of the files requested and in which order. On subsequent launches, the prefetch (.pf) file for that specific process is used to read the files in before the application has actually requested them - so when the application gets round to sending the file open request it incurs no disk I/O. Prefetch is only effective when the process requests the same files each time, otherwise the prefetcher loads in files that don't get used. It only makes an attempt to reactively pre-load files on a per-process basis when the process fires up. (Vista's Superfetch is a lot smarter and prefetches files before the application is even launched, if the user's activity is consistent.) The system cache on XP is a limited resource, regardless of the RAM, and it isn't prepopulated because there is no Superfetch. On Vista, the system cache can use almost all physical memory (as "free RAM is wasted RAM").

Extracting and copying in the binaries manually has 2 possible issues: 1. If the package does more than just replacing/adding binaries (such as ACL changes or registry modifications/additions) 2. You have to do version control manually and might end up regressing other fixes for the same binary (e.g. replacing QFE v1.5 of a binary with GDR v1.6) The other guaranteed side effect is that the hotfix will not be listed in "installed updates" so it's easy to lose track of which you have processed.

Yes, if the XP clients are on SP3 and the Vista clients are SP1 or SP2, they will have the Remote Desktop Client 6.1 which supports RemoteApps. Not tried a RemoteApp using an UNC path, I must admit, but I don't see any restrictions in the step-by-step guide stipulating you can't do that.The same restrictions apply as if you were to log onto the server directly - the RemoteApp is specified with a command line just like a regular shortcut. It is also possible to create an MSI package for clients to act as a file association and launch a specified RemoteApp to open a file with an app running remotely, this is quite neat. Then it's down to the individual apps, they might need to be "TS aware" so they don't have problems running multiple instances in different sessions.

You're maybe thinking of RemoteApps, similar to Citrix's "published apps" concept for SMEs - this feature came along with Windows Server 2008, and just requires the server runs with the Terminal Services role added (and hence TS CALs on a discoverable TS Licensing server).http://technet.microsoft.com/en-us/magazin...ms.aspx?pr=blog http://technet.microsoft.com/en-us/library...673(WS.10).aspx With R2, the Terminal Services role has rebranded to Remote Desktop Services, and RemoteApps can now be filtered based on group membership (when viewed through RDS Web Access). For external access to TS/RDS servers, it is preferred to have users come in through a TS Gateway (another of the roles on Windows Server 2008), as this can be a single point of access for any number of TS servers on the internal network using the standard Remote Desktop Client (6.x and later). http://technet.microsoft.com/en-us/library...264(WS.10).aspx http://technet.microsoft.com/en-us/library...530(WS.10).aspx Windows Server 2008 R2 also brings "DirectAccess", where Windows 7 clients are able to connect remotely to the corporate network securely: http://www.microsoft.com/windows/enterpris...7/features.aspx http://technet.microsoft.com/en-us/windows/dd572177.aspx

Assuming the documentation is up to date: Here is the start of chapter 4 : Customizing your network settings From there you can go into Using the LAN IP Setup Options At the bottom of this screenshot I can see the Address Reservation table There, you can see the Add button which was referred to in the other page here - you enter the IP address to reserve, a name for the entry and the MAC address of the client which should receive that IP address.

If you have 2 clients that have issues with colliding DHCP leases then things like this can happen, yes. You can use the following command to manuall realease all your IP address leases on the client: IPCONFIG /RELEASE * and then this command to renew them: IPCONFIG /RENEW DHCP reservation basically associated a hardware MAC address with a logical IP address, so that a particular machine will always be given the same IP address, and that address will never be given to other clients. I found this from an Internet search for "WGR614V9 dhcp reservation", which might answer your question: http://documentation.netgear.com/wgr614v9/...14v9-06-06.html Using DHCP reservations to statically assign IP addresses for machines is smarter than configuring it on the client end, as moving the network adapter to a different port will require a reconfiguration - those using USB adapters and static IPs will have encountered this pain - and it rules out the possibility of statically assigning the same address twice. RDP is encrypted by default, and it is more likely to be a denial of service rather than a successful intrusion that you get over TCP port 3389. If it's a concern then you can change the external listening port to something else (but keep it above 1023), but leave the forwarded destination port as 3389. To connect to the client from the outside, you would need to add ":port" to the address entered. e.g. if your public IP address was 1.2.3.4 and you pick port 5555 to listen on externally, you remotely connect to 1.2.3.4:5555 To connect to the client from the INside, you don't need to do anything special as the router isn't involved and you didn't change the default listening port for Remote Desktop on the client.

Yes, and good One and the same - the public IP address obtained by your router is the one displayed when you visit http://ipchicken.com.

And you disabled the "allow remote administration of this router" option in the router config page yes? That is the most important thing to put back to its default (OFF) as you do not want people reconfiguring your router! Okay, the clients have private "non-routable" IP addresses so you can't use them through NAT, any communication IN to your network will use the PUBLIC IP address on the dirty side of the router, and port forwarding takes care of forwarding the packets onto the correct client on the private side. Your clients are not registered anywhere with DNS, so clients outside of your private network will not have any way of reaching it by name - from a remote site you want to use the Remote Desktop Client to connect to the public IP address of your router, the rest is automagically taken care of. You can find out your public IP address through the router status page - it will NOT start with 192, this is the router's internal address (most likely 192.168.0.1).

Yup, while it's not a valid DNS server, don't point anything to it. Heh, shows how many DCs I have set up on Server Core eh?

Have you tried a manual dcpromo, without using the answer file? I would also take out the local IP address from the DNS server list until it's up as a DC - I have seen quirks with the server selection order in the past which fouled up my domain joins for member servers.

If you're logged in as a local user on SKULLCRUSHER-PC then yes, the Domain should say that by default (indicating the local SAM database on that computer).I believe the Home Group concept was created for the multi-PC home environments on Windows 7 to allow the concept of shared, trusted credentials without the need for a Domain Controller, but I've never looked into it personally (I set up a domain in a VM on Hyper-V instead, and made the client machines members of it).

This is the new credentials manager from Vista onwards - it defaults to the realm your logged-on user resides in. If all machines are in a domain and you logon with your domain account, you have no issues as the common security realm (Active Directory). For accessing machines that do not have a common security realm, you need to specify it as Netman66 pointed out. So if you are logged onto ComputerA as local account User1 and want to access a shared resource on ComputerB, you need to specify a user account on (or trusted by) ComputerB (e.g. local account User2). You would then enter as your username ComputerB\User2, along with User2's password in the second field. What you will notice is that as soon as you type the '\' character, the Domain will update with the text before it (ComputerB in this example). Local user accounts cannot be trusted across the network - so ComputerA cannot provide credentials that ComputerB can use, even if the machines both have a User1 account with an identical password (the crude form of impersonation used years ago). Sometimes the opposite occurs, and you are logged on with a domain account so the Active Directory domain becomes the default realm, but you might want to use a local account (e.g. for elevation) - entering '.' as the realm is a shortcut for the local computer. e.g. .\AdminUser

You have just changed the port that the router's own administration is done by, and also allowed external changes to your router (if you have a default or trivial password on your router admin page, it can now be trashed). First, disable the external administration option in your router config, you do NOT want that. Second, restore it to its default port, 8080 (or at least something that is not the port used by RDP). Third, look at port forwarding in the router administration - you should have an option to forwarding incoming connections on the public side of the router on TCP port 3389 to a specific IP address (also on TCP port 3389), this specific IP address wants to be the one on your XP SP3 machine you want to RDP to. You can probably set a DHCP reservation for your XP SP3 machine in the router configuration too, so it always gets the same IP address even though its being acquired "dynamically" - this will make sure the port forward doesn't break in the future if the machine is offline for a while and its DHCP lease expires.

Yup - the CTRL+SCROLL LOCK combination mentioned in the details in cluberti's post - basically you manually trigger a bugcheck (blue screen) in order to produce a memory dump of the system, then we can take a look in there with a debugger to find out where the nonpaged pool memory was being spent. Once you've made the necessary registry changes and rebooted, it's best to test that it works as expected before you need it.

Look at Pool Nonpaged Bytes - it goes up linearly through the log, starting at 66,752,512 bytes (10:20:10) and ending at 1,243,217,920 bytes (18:27:49). Take a look here for cluberti's instructions for creating a memory dump of the entire system: http://www.msfn.org/board/creating-memory-dumps-t130004.html Crash the system when the system performance drops. Zip and upload the MEMORY.DMP somewhere and we can take a look at the pooltags to see what the nonpaged pool memory was being allocated for.

I noticed you have uTorrent running in the background - is this pretty much always the case? And do you transfer large files, or maybe many smaller files at the same time? It might be that the activity of torrent programs will cause file sections to be cached even when only tiny portions have been touched (Windows caches on logical file blocks, not disk blocks) - then if sections are scanned and/or used for seeding, they will remain in the cache. Just a theory, but it might explain why the memory used isn't directly attributed to a process' virtual size.

Ah, sorry I was looking at my Win7 Task Manager and forgot it had the value Vista doesn't show. Your memory is being used for the system file cache, this is normal - Superfetch is only PRE-populating the system cache based on usage patterns, so disabling it doesn't do anything except make load times longer for frequently-used apps following a reboot. Having memory used for cache is a positive thing (I never disable Superfetch except in VMs for test environments). Mark Russinovich wrote about the Vista kernel changes here: http://technet.microsoft.com/en-us/magazin...istakernel.aspx The trend that Superfetch shows is a gradual decrease in "Free" memory over time shortly after the system boots, but even with it disabled the memory manager still populates the system cache with large file copies, etc.

Where exactly are you seeing the evidence of this "leak"? If you look in Task Manager on the Performance tab, under Physical Memory you are interested in the Available (not Free) figure - is this particularly low, caompred to Total?

Right, here's what I would do: 1. Logon with a local administrative user account 2. Delete all profiles through the UI, except the current user and the Default Profile: Right-click Computer, click Properties Click Advanced system settings Click Settings under User Profiles Highlight each profile in turn and click the Delete button 3. Open the Registry Editor and check under the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList There will be keys under here for each profile that has been loaded previously - if you delete the folder from disk manually, these registry keys get orphaned and can cause issues when the user logs on, as the query "does this user have a locally cached profile?" gives different answers depending on where you look. Pay attention to the ProfileImagePath value under each key present under ProfileList * Do not touch S-1-5-18, S-1-5-19 or S-1-5-20 * One of the (longer named) profile keys will be your currently-logged-on user, so don't delete this one - but if there are others then I would export the ProfileList key for safety, then delete the sub-key in which the value is present. e.g. on my system I have: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList S-1-5-18 S-1-5-19 S-1-5-20 S-1-5-21-143999014-727696240-3471678432-1112 (domain, user account: ProfileImagePath==C:\Users\Paul.domain) S-1-5-21-143999014-727696240-3471678432-500 (domain Administrator account: ProfileImagePath==C:\Users\administrator) S-1-5-21-686400301-924511773-2860567096-1001 (local user account: ProfileImagePath==C:\Users\Paul) You can see that profile paths default to just "username" if there is no collision (see the domain administrator path), but the domain is appended if there is (see Paul.domain for the domain user, because Paul already exists as a local account which was logged on previously). (If the name collision occurs in the opposite direction, %computername% is appended to the profile instead.)