[scrfix]

One of the items I struggled with in Vista was how, when Vista creates two tokens for access; a standard and an administrative token, to access a mapped drive from an elevated command line prompt.

The reason you cannot access the mapped drive from an elevated command prompt is because the mapped drive made in the GUI was made with a standard token and an elevated command prompt has an administrative token.

I utilize a ZB command with robocopy that requires an elevated command prompt.

In Vista, to get around this issue, I could merely create a registry entry called EnableLinkedConnections and set this to 1. This would then allow the administrative token to shared the current standard tokens access thus allowing access to the mapped drive. This was fantastic.

Guess what? It doesn't work on Windows 7.
No longer can I utilize that method.

I have two options here.

1. Find a way to get this to work so that I can still continue to utilize ZB

OR

2. Downgrade the back to Z or B whichever doesn't require elevation (I believe that is Z) and hope that it actually copies and find a way to lower my command prompt back to a regular level (since I start out in an elevated prompt for writing registry entries).

Any ideas?

[Mumbodog]

A few things that come to mind is there was a group policy change from Vista to W7?

or UAC has changed and is interfering with it somehow.

You could possibly solve this by using the hidden adminitstator account instead of a regular user account.


.

[scrfix]

That is a nice idea but what is happening is the user creates a mapped drive. When they create a mapped drive, they are utilizing a standard user token. When they utilize this standard user token, all other users and adminsitrative tokens no longer have access to this resource. Only the user that created it has access to it so if John creates a mapped drive then only John can see that mapped drive. The administrator and other users cannot see that mapped drive, this is why an elevated command prompt cannot see the mapped drive.

Although this is a good idea, it ultimately will not work because of how tokens are utilized. I do appreciate the brain storm however.

I did think of a way that might work. TheOutCaste brought something up to me in one of our brainstorming sessions. He mentioned to me that I could set a scheduled task to run the program however for the application we were speaking of it would take 1 minute from the time I set the task.

In theory, if the task is already there and I would like to run the task, I can merely set up the scheduled task with the user permissions, set it to run with the highest privileges. Once I set it to run with the highest privileges, I should still be able to utilize the zb option for robocopy and it should run immediately. At that point in time, I don't need an elevated command prompt. I merely need a regular command prompt.

I don't know if any of this is making sense or not but I will test it when I get a chance tonight.

[scrfix]

I didnt have a chance to bring the Windows 7 computer home from the shop. I thought of another option that is possible however I will need some assistance in checking something out as I don't have every version of Windows 7 possible. I only have ultimate.

The RunAs command. I am not so familiar with the RunAs command however I was playing around with the /savecred on my Vista system. Now according to the help file, it is supposed to use the credentials that were last saved by the user. Shouldn't that be upon logging into the computer. I know that Vista Home Premium does not have this option. I am wondering if Windows 7 has version that also do not have this option OR if this is even a viable option to consider. Perhaps it will not work because I will still need the password for the user which I will not have.

I did find out however that is how you de-elevate a command prompt from elevation.

runas /noprofile /savecred /user:%computername%\%username% cmd

This will ask for the password for the current account however it will take the account out of elevation as least in Vista.

[scrfix]

I came up with another work-a-round on this subject. Once again, this is only theory until I can actually test it.

Here is what we do know:
We know the drive letter that robocopy will utilize.

Here is what we don't know and need to find out
Where the mapped share is located.

1. We test to see if the drive is there. We find no drive. We do not presume that there really is no drive.

2. We now look for mapped drives. At this point in time, when you utilize a net use command an error is going to come back stating that drive letter "X" is not available. This is because the standard token utilized to map that letter to a network share has utilized that letter.

3. Next to the letter on the very next column (or token if we are talking about a Batch File FOR statement) is the network share. We now know that network share that is being utilized for the mapped network drive.

4. We now map a different drive letter to that same network share and then utilize that drive letter for robocopy. This mapped network share will utilize the administrator token and my zb options and an elevated command prompt will work no problem. We merely unmap the drive when we are completed with robocopy.

Jerry, I am sure you are probably looking at this. What do you think? I think this is a better way to go rather than setting up a scheduled task and then running the task from the command line under the users credentials.

Anyone have any thoughts. I will test it tomorrow night and see if that will work.

[scrfix]

OK.

Test results were successful.

If you are attempting to run something through shared tokens and you find out that enablelinkedconnections is not available on Windows 7 then you can utilize the work-a-round for this.

Set a scheduled task to run your program.
You can utilize the GUI or the command line

Command line parameters
SCHTASKS /CREATE /IT /SC DAILY /TN "%TASKNAME%" /TR "%TASKPATHWAY%" /ST 01:00 /F /RL HIGHEST

The above says:
- Utilize the schtasks program to create a task
- Have it run interactively
- Schedule it to run daily
- Provides a taskname (which currently has a variable in there... change this to whatever you want)
- Provices a task pathway where the program is located (again, currently has a variable in it. Change this to where your program is located)
- Provides a start time of 1am
- Forces the scheduled task to be created even if it is there already (Overwrites whats there if the same name is provided)
- Sets the run level to the highest permissions.

Now just run the scheduled task from the elevated command prompt
schtasks /RUN /TN "%TASKNAME%" /I

The above says:
- Run the scheduled tasked name "Change this to whatever your scheduled task is named"
- Force it to run even with constraints

After careful consideration, this method is not perfect but it is better than detecting the mapped drive and then remapping. There are two many items to keep track of when you attempt the mapped drive scenario.

With the scheduled task scenario if they delete your scheduled task, all you have to do is look for it and put it back in.

[Squashman]

But shouldn't you already know what the UNC path is if you already have it mapped. If that is the case you wouldn't need to know the Driver letter, just use the UNC path instead to copy the files to the network share. Or you can use pushd as I have suggested to you in the past.

[scrfix]

Squashman,

This is in the case that you don't know the mapped drive. If you yourself set the mapped drive then you will know it. If you don't and you are writing a script for someone which I find people requesting now then I will not know their mapped drive.

Update
There is a bug in the method about the scheduled tasks work-a-round.
Somehow, unknown to me at this time, I have made it so that both standard tokens and administrator tokens are shared on this particular username. All of my command prompts come up as elevated. I am not sure what I changed or what happened to make this happen. It is not the LinkedConnections registry entry because that is completely removed and I can still see the mapped drives from an elevated prompt. This is the only reason my scheduled task worked during my testing. The testing failed otherwise because of the /ZB function in robocopy which requires elevation. Since /ZB requires elevation, it automatically opens a new command prompt with an administrator token thus making it impossible to see the mapped drive. However if you remove the /ZB and only utilize /Z it will work. I just like my /ZB there so I will try to figure out what happened and why everything is like that in that username however I am really not sure what I did to get that to happen. I didn't change much. I tried to repeat it on a different username to no avail. If I cannot repeat it I will work on the secondary method however it is very cumbersome and requires watching a lot of items at once to see if any changes are being made to them such as they switch from a mapped drive to a physical drive but don't change the letter correctly, the user switches shares and a ton of other error checking.

[Squashman]

Posted via Mobile Device
I guess I am not following you. Who is to say they don't remap the drive and if you are writing a script for them why not just ask them what the server path will be. I sometimes think you make thins harder on yourself than it has to be.

[scrfix]

Remapping the drive is what my whole point was. If I am writing them a script I don't want them to have to call me everytime they want to remap the drive. I want it to work no matter what they do. If they put a physical drive on the computer, I want it script to work. If they map the drive, I want the script to work.

The problem I am running into is that in Windows 7, when you map the drive, you map it in a standard token and the administrative token that it requires to run the /ZB option in Robocopy doesn't work because the mapped drive cannot be seen.

Since I will not know what their server share is because I am not physically there and I don't want them calling me every single time their IT department decides to make a change to server shares I would like it just to work.

So I amtrying to find a way around this Windows 7 issue. That is the main goal. The only two items I was able to come up with was the task scheduler which failed testing and the discovering what mapped drives they have, remapping them automatically with administrative rights and then copying the data, then unmapping the drive and exiting the script. There are just a lot of areas that need to be watched if I do it that way. I was writing them all down at work if I had to go that route. I am not at the office at this time so I could not remember them all. That may be the way that I have to go however.

[Squashman]

Posted via Mobile Device
what are you writing scripts for a company that already has I.T. If they change the drive letter the network path will probably still be the same. So it is there IT problem not yours.

You do realize that Microsoft is on a slow migration path to moving away from drive letter mappings.

They will be a thing of the past some time in the future.

[scrfix]

I did not know that Microsoft was on a slow migration to moving aware from the drive letter mappings.

Where can I read more about that?
What are they going to?

That is okay, they are not a thing of the past right now.

The owners of the business are friends of mine and their IT department doesn't write code or scripts. They wanted something to automate their backup so I told them I would help them out. They are getting windows 7 computers so I have to get this working on Windows 7 and then all of the problems. I have it working on XP, Vista, 2003 SBS but not Windows 7 with a mapped drive. If it is a physical drive on Windows 7, it works fine just not a mapped drive.

I figure it is not a waste of time because I am going to need it for my systems too. I just didn't realize how involved this was going to get with Windows 7. So much for it being like Vista.

[Squashman]

I wouldn't consider them I.T. people then. Every networking admin knows at some point in time they will need to write some script. That is why you map network shares with batch files and vbscripts. They should be fired. But that is just my opinion. Even after the dot com bust we still have way too many incompetent network admins.

[scrfix]

Ha Ha Ha Ha Ha Ha Ha

[scrfix]

Jerry says he tested this on his Windows 7 Ultimate and it does in fact work. He makes a very good point about the system that I am utilizing to test. It is indeed a beta version and that is probably why it doesn't work and probably why this Administrator Command Prompt comes up automatically instead of a standard command prompt.

My technician has another computer with Windows 7 on it. I am going to have him bring that into the office so I can test that system.