Win XP Pro to Win XP Pro network share

[Guest]

Hi,

I was setting up a new computer for a client yesterday (going back today to
finish a few things), and normally I would just take the HD out and put it in
the new computer, to transfer the data. In this case, he has IDE drives in
the old computer, and only S-ATA connections in the new. I opted to copy the
data via Ethernet (cross-over cable) instead, but ran into a connection
problem that I haven't seen before: "The requested resource is in use." I
did a Google search on this, and noted a lot of "ASP" solutions, but this is
a simple network connection (two Win XP Pro machines), not involving a web
server.

Here's what I tried:

1. On the old computer, shared the root of the drive (C with network
users, and allowed them to make changes. Also, unchecked "Make this folder
private" for My Documents.

2. Set the IP address of the old computer to 192.168.1.2

3. Set the IP address of the new computer to 192.168.1.1

4. Enabled the Guest account on the old computer (via the "User Accounts"
control panel applet)

5. Both computers run NIS (the old one running 2006, the new running 2008),
so I tried disabling both, then I tried enbling both and allowing the IPs to
be "trusted", then I tried uninstalling NIS 2006 and Windows Defender on the
old computer (the HD is going to be wiped anyways after the data transfer).

I can ping the old computer (no problems) by IP address from the new
computer. I get the above error message when going to Run > \\192.168.1.2
from the new computer. I also tried going to Run > \\192.168.1.2\c$, and I
get the logon box, trying to connect to <computername>\Guest.

Any suggestions? I'm going to verify that the old computer has all the
latest patches (the new one does), and put it into a "clean boot" (to try to
rule out background processes interfering). If I can't resolve this fairly
quickly this morning (I'll be there in about 3 hours from now), we'll just
get an external HD and copy the data over (which my client was thinking to
get anyways, to facilitate backups).

Thanks,
Kurosh

 

[zuben3]

Hi,

I was setting up a new computer for a client yesterday (going back today to
finish a few things), and normally I would just take the HD out and put it in
the new computer, to transfer the data. In this case, he has IDE drives in
the old computer, and only S-ATA connections in the new. I opted to copy the
data via Ethernet (cross-over cable) instead, but ran into a connection
problem that I haven't seen before: "The requested resource is in use." I
did a Google search on this, and noted a lot of "ASP" solutions, but this is
a simple network connection (two Win XP Pro machines), not involving a web
server.

Here's what I tried:

1. On the old computer, shared the root of the drive (C with network
users, and allowed them to make changes. Also, unchecked "Make this folder
private" for My Documents.

2. Set the IP address of the old computer to 192.168.1.2

3. Set the IP address of the new computer to 192.168.1.1

4. Enabled the Guest account on the old computer (via the "User Accounts"
control panel applet)

5. Both computers run NIS (the old one running 2006, the new running 2008),
so I tried disabling both, then I tried enbling both and allowing the IPs to
be "trusted", then I tried uninstalling NIS 2006 and Windows Defender on the
old computer (the HD is going to be wiped anyways after the data transfer).

I can ping the old computer (no problems) by IP address from the new
computer. I get the above error message when going to Run > \\192.168.1.2
from the new computer. I also tried going to Run > \\192.168.1.2\c$, and I
get the logon box, trying to connect to <computername>\Guest.

Any suggestions? I'm going to verify that the old computer has all the
latest patches (the new one does), and put it into a "clean boot" (to try to
rule out background processes interfering). If I can't resolve this fairly
quickly this morning (I'll be there in about 3 hours from now), we'll just
get an external HD and copy the data over (which my client was thinking to
get anyways, to facilitate backups).

Thanks,
Kurosh

- Make sure they're both part of the same workgroup.

- Permissions set to the root (C:\ in your case) aren't all inherited
by the profiles in Docs&Settings, if that's where your target data
lives (most likely so).

- You can try creating a profile called "Transfer" or something just
for this temporary task on both computers. Use the same username and
password and make sure it's part of the administrators group and
remove it from the users (limited) group.

- Don't use the Guest profile--it's limitations are substantial. Kill
it for security reasons even still.

- If that doesn't work, try setting specific shares and add Transfer
(or whatever profile you're using) to the ACL with Full Control.

- Check ownership of the problem directory on source computer.

- Make sure files/dirs aren't locked or set to private.

- Reboot both machines for good measure.

- Ensure source machine doesn't have any program or process using the
file(s) you're trying to copy. You can't copy the profile the source
machine is logged on with. The temporary profile you create will get
around this.

- Do both computers show up on both network browsers? Do all their
shares?

- Can you type in a UNC like \\SourceComp\C$ instead of the IP? How
about after setting the specific share with proper permissions? Like: \
\SourceComp\SomeDirectory\SomeChildDir\TargetShare You shouldn't need
to if they're both XP Pro since the network browser will reveal all
the shares for that computer you setup. Then it's just a matter of
access permissions.

Good luck!

 

[Guest]

Hi,

Thanks, I was able to get this working properly... please see below.

- Make sure they're both part of the same workgroup.

Yes, they were. Forgot to mention this in my last post.

- Permissions set to the root (C:\ in your case) aren't all inherited
by the profiles in Docs&Settings, if that's where your target data
lives (most likely so).

Right. Most of the data was in the old profile, but I wanted to have full
access to the drive, to look around. As you mentioned, this didn't allow
browsing to the old profile (using the temp. transfer profile), so I got
around that by sharing that profile as well. ("Simple File Sharing" was
enabled, and this was the easiest way to handle it, rather than booting into
Safe Mode and changing permissions there)

- You can try creating a profile called "Transfer" or something just
for this temporary task on both computers. Use the same username and
password and make sure it's part of the administrators group and
remove it from the users (limited) group.

This is what resolved the problem. I guess the problem was due to not
verifying that the username / password on both computers was the same --
although the same username was being used, there was a "hidden" password on
the old account (as I had set this up about three years back, and haven't
visited this client since, I forgot about this), so that it could run
scheduled backups using Task Scheduler. I guess this was causing a
credentials problem. I used your method, creating a new Administrator
profile on both computers, and that connected just fine. I didn't bother to
check / remove them from the "Users" group, since (in my understanding) that
would only be restrictive where Administrator priviledges had not been
assigned. The only issue I had with this was getting into the old profile,
which I bypassed by sharing it (as above).

I guess the best solution to this problem would be to ensure the new profile
and old profile username / password match on both computers, which would
allow access to the old profile.

- Don't use the Guest profile--it's limitations are substantial. Kill
it for security reasons even still.

Yes, agreed. I didn't think this through fully, when connecting. By
default, it isn't enabled (so that's fine for the new computer), and as I
mentioned, the old HD was to be wiped anyways, so that wasn't an issue.

- Ensure source machine doesn't have any program or process using the
file(s) you're trying to copy. You can't copy the profile the source
machine is logged on with. The temporary profile you create will get
around this.

This is true only for the "ntuser" (profile) file, but the rest of the data
(i.e. My Documents) would certainly be able to be copied. I prefer starting
fresh in these cases, in case there's corruption in the old profile.

I didn't test this, but if the files are being accessed remotely (i.e. over
the network), would the profile be necessarily logged in on the source
machine? I imagine not, so even this wouldn't be an issue. I'm guessing the
profile on the source machine can be logged off, and the files can still be
accessed.

Best Wishes,
Kurosh

 

[zuben3]

Hi,

Thanks, I was able to get this working properly... please see below.



Yes, they were. Forgot to mention this in my last post.


Right. Most of the data was in the old profile, but I wanted to have full
access to the drive, to look around. As you mentioned, this didn't allow
browsing to the old profile (using the temp. transfer profile), so I got
around that by sharing that profile as well. ("Simple File Sharing" was
enabled, and this was the easiest way to handle it, rather than booting into
Safe Mode and changing permissions there)


This is what resolved the problem. I guess the problem was due to not
verifying that the username / password on both computers was the same --
although the same username was being used, there was a "hidden" password on
the old account (as I had set this up about three years back, and haven't
visited this client since, I forgot about this), so that it could run
scheduled backups using Task Scheduler. I guess this was causing a
credentials problem. I used your method, creating a new Administrator
profile on both computers, and that connected just fine. I didn't bother to
check / remove them from the "Users" group, since (in my understanding) that
would only be restrictive where Administrator priviledges had not been
assigned. The only issue I had with this was getting into the old profile,
which I bypassed by sharing it (as above).

I guess the best solution to this problem would be to ensure the new profile
and old profile username / password match on both computers, which would
allow access to the old profile.


Yes, agreed. I didn't think this through fully, when connecting. By
default, it isn't enabled (so that's fine for the new computer), and as I
mentioned, the old HD was to be wiped anyways, so that wasn't an issue.


This is true only for the "ntuser" (profile) file, but the rest of the data
(i.e. My Documents) would certainly be able to be copied. I prefer starting
fresh in these cases, in case there's corruption in the old profile.

I didn't test this, but if the files are being accessed remotely (i.e. over
the network), would the profile be necessarily logged in on the source
machine? I imagine not, so even this wouldn't be an issue. I'm guessing the
profile on the source machine can be logged off, and the files can still be
accessed.

Best Wishes,
Kurosh

right on. the "ntuser.dat" is the wrench in the copying gears while
logged in whith its associated profile.

always annoying how windows can't resume copying when a file name is
too long and six directories deep in a two hour backup and the client
calls and says "the backup failed and i don't what was transferred and
what wasn't!"

then you have to go through each directory and child, several layers
deep and copy files by hand until you find the culprit(s).

know any way around this? i use batch scripts for scheduled backups to
external drives.

 

[Guest]

always annoying how windows can't resume copying when a file name is
too long and six directories deep in a two hour backup and the client
calls and says "the backup failed and i don't what was transferred and
what wasn't!"

then you have to go through each directory and child, several layers
deep and copy files by hand until you find the culprit(s).

know any way around this? i use batch scripts for scheduled backups to
external drives.

I used this same method many moons ago, but have since come to realise that
it's not very reliable, and backups (for the most part) should be reliable.
Using a backup program (such as Backup MyPC or some ghosting program) or
device (such as Mirra) for smaller clients is the best way to go about it. A
larger client's needs are more critical, and this batch file method shouldn't
even be considered.

If the copy failed, then the target directory wouldn't have the file that
you were trying to copy (or it wouldn't be the same file size), would it?
All you would need to do is compare the directories for anomolies. (there
are programs that make this much faster, including doing an hash verification
of both file structures, which would clearly point out which files need to be
backed up) Probably an easier way to handle this would be to have the batch
file output the results to a file, rather than the default (to the screen).
Wherever it crashes would be the last line of the process, and you'd have to
continue from there.

Best Wishes,
Kurosh