Problems with mapped drive

Try3 - If things were simple we'd just copy files and be done with it, but the code won't run on Windows 10 without modifications if it will run at all, that's something yet to be determined. And during this transition, code, installation files and databases are constantly being modified / updated, it's all a moving target and the last thing we want to have happen is to end up with two versions of live date being spread across multiple systems.

In order to test things on Windows 10, we must have the most up to date code, configuration and date database files and trying to constantly update them between the two systems would be impossible due to there shear size and the amount of time it would require to copy them every time we need to run a test.

And I've only touched on a few of the interdependence involved when dealing with duplicate environments split between two separate machines, it can get quite complex to safeguard the integrity of data during a move such as this.


Samuria - I gave that a try but got the same error.

- - - Updated - - -

zebal - I checked the event log and found something but it doesn't make sense to me.

Under the Security log it says:

An attempt was made to query the existence of a blank password for an account.

The account on the XP box isn't blank and I went back and double checked just to make sure the username and password are correct.

Is there a way in Windows 10 to confirm / re-enter the remote username and password?

An attempt was made to query the existence of a blank password for an account.

The account on the XP box isn't blank and I went back and double checked just to make sure the username and password are correct.

There must be more information about the event such as remote host, username attempting to log on etc. without this important info it's a mouse and cat game, we can only guess..

clearing a log and reproducing the problem is first step to get relevant logs.

If you want to share event logs please execute following commands:

1. Right click on Windows button and click on "Windows PowerShell (Admin)"
2. If prompted for password, enter administrator password and click "Yes" to continue

3. Copy all of the code below at once, right click into console to paste and press enter

Code:

ni -ItemType Directory $env:SystemDrive\PSLogs\EventLog\ | Out-Null
Get-EventLog -LogName System -EntryType Error | ? Source -ne DCOM |
select EventID, TimeGenerated, Source, Message | sort TimeGenerated -Descending |
fl > $env:SystemDrive\PSLogs\EventLog\system.log

4. Copy all of the code below at once, right click into console to paste and press enter

Code:

Get-EventLog -LogName Security |
select EventID, TimeGenerated, Source, Message | sort TimeGenerated -Descending |
fl > $env:SystemDrive\PSLogs\EventLog\security.log

5. Copy all of the code below at once, right click into console to paste and press enter

Code:

Get-EventLog -LogName Application -EntryType Error, Warning |
select EventID, TimeGenerated, Source, Message | sort TimeGenerated -Descending |
fl > $env:SystemDrive\PSLogs\EventLog\application.log

6. Copy all of the code below at once, right click into console to paste and press enter

Code:

Compress-Archive -Force -Path $env:SystemDrive\PSLogs -DestinationPath $env:SystemDrive\PSLogs.zip

7. This will create folder named "PSLogs" and zip file named "PSLogs.zip" in your C:\ root drive
8. Attach "PSLogs" zip file to your new reply
9. Feel free to delete "PSLogs" folder and zip file when done

This is only a subset of logs that may have some clues, a portion of the answer may be on XP machine, ex. related events.

zebal - thanks so much for the detailed instructions on how to copy the event log info.

I've been playing around a bit and found even more oddities, sorry but kind of a long post.

I tried copying files to and from a somewhere other then the system disk, and decided to do this because I've had other issues whenever Administrative Privileges are involved.

So there's a non-system disk 'J:' on the Windows 10 box and I tried copying files from the mapped XP disk \\XP07\... to ‘J:’ and it worked. So the Windows 10 File Explorer is in fact capable of copying files to and from the mapped drive eliminating XP, FE and or user accounts as being the culprit, and is starting to put the focus on the use of Administrative Privileges.

I tried running a program that I know needs Administrative Privileges, it's run through an association by clicking on a file with a specific file extension which in turn launches a program. When the associated file is on the mapped drive and clicked it fails stating that it can't find drive 'G:' - basically the same error message as when trying to copy files to the system disk.

Then when moving the same associated file to drive 'J:' and clicking it, everything works just fine bringing me back to believing Administrative Privileges is the culprit.

In trying to get the XP code to work on Windows 10, I noticed that many of our batch files wouldn't work. These batch files have been running for years on XP but all failed on Windows 10. First they were failing because they needed permission so they were run again with Administrative Privileges. They all ended up failing the second time around when using Administrative Privileges but for a different reason, this time is was because they couldn’t access drive ‘G:’ This made absolutely no sense since these batch files were being launched from the very drive Windows said it couldn’t access.

Normally when running batch files the default DOS directory is set to where the file was launched from. Clicking on a batch file in G:\Development should result in the default DOS path being set to G:\Development which is true for XP and Windows 10. Well with one exception, when running the same batch file from the same directory, G:\Development on Windows 10 with Administrative Privileges, the default drive and path are changed to C:\Windows\System32. This causes the batch file to fail because all its paths are now broken and pointing to the wrong place.

This seems to be a significant bug in Windows, no matter how a batch file is launched, the DOS environment should be consistent regardless of the privileges it’s run with. All of the batch files from the XP system that we’ve tried to run have had to be modified to include specific drive letters and file paths which is a horrible solution. With these new changes the batch must now live in the exact same directory for all time, moving them anywhere else would mean they'll all fail again and would have to be edited so there drive letters and paths can be set to there new locations.

And while all of this may sound unrelated or unimportant, it’s the exact same behavior when trying to work with the mapped drive and prompted for Administrative Privileges. I believe what’s happening is that by using Administrative Privileges Windows 10 is loosing the original path of the command being executed and therefore throws an error stating it can’t access the drive.

The only problem with learning all of this is that I don’t know how to fix the problem. At this point I don't believe this has anything to do with usernames or passwords on XP or Window’s 10. It all seems to be an issue with Windows 10 loosing the default drive and path whenever Administrative Privileges are being used in conjunction with a mapped drive.

Well I got one step closer to getting the mapped drive working.

Instead of using Windows 10 File Explorer to map the Network Drive, I do it manually from a Command Prompt run as Administrator:

net use G: \\XP07\XP_Dev

After executing this command I can copy files to and from the mapped drive to the system disk. And while this is a huge step forward there are still other problems with the mapped drive.

Opening a jpg file in Paint by clicking it from File Explorer loads the picture just fine, but I can't save it. When Paint tries to save the file it can't find the mapped drive, it doesn't even show up when browsing for a place to save it.

There are a few links on the web discussing this very issues of not being able to browse a mapped drive from within a program. There is supposed to be a registry fix for this by adding EnableLinkedConnections and settings it's value to 1 but it didn't work.

So the next step after getting File Explorer working is to somehow get programs to see the mapped drive.

Try3 - yes I have access to the batch files but that defeats the purpose of having 'general' purpose batch files.

Once you hard code a drive letter and a path as both have to be set, then its locked into that path from that point forward. If the batch files are ever moved to a new location, (disk or path) in the future then they would all need to be edited again and that that's just not an acceptable solution, there are hundreds of batch files that were purposely written not to include drive letters or paths just to avoid such an issue.

Oh sorry, my bad, I didn't completely understand the cd /d "%~dp0" command.

I'll will give it a try, If it works it would certainly help out with the issues when running batch files as Administrator.

With this fix and the new method of connecting to mapped drives with cmd, I'm getting really close to having a complete solution. Now Just have to get programs to see / recognize the mapped drive.