[scrfix]

Without knowing the drive letter, how do I accomplish the following scenario?

1. An unpartitioned drive gets put into the computer via a USB cable.
2. I would like to partition that drive automatically and assign it a letter. I understand that I can utilize diskpart for this. I can probably utilize net use * to assign the letter I am presuming.
3. I would like to copy files over to that partition in the same batch file. For this, I need to know what letter was utilized for the drive, correct? How else would that be accomplished without knowing the drive letter?

My thoughts here are: Great I can utilize net use * which by the way, I must be utilizing incorrectly because it doesn't do anything for me, but how do I start copying over to that same drive letter?

When I go into the help for net use all it tells me is that I can utilize net use *. It doesn't give me any examples or anything. I have not had time to search Google or Microsoft yet.

[Squashman]

Posted via Mobile Device
you are trying to do two totally unrelated things at once.
partitioning is done locally on a computer. net use is used to map to a remote share.
you wouldn't be doing this all on one computer.
I think you are confused on what you are trying to do.

[TheOutcaste]

wmic logicaldisk get DeviceID

This lists all used drive letters, so you can determine which are free.

From within Diskpart, List Volume will also list all used drive letters. It won't work from the command line, so you would have to create a Diskpart script, run it and capture the output.
You'd have to do the same to determine which disk has unpartitioned space as well, so you know which disk to select to create the partition on.

Then create a Diskpart script to create the partition and assign a drive letter using the Assign command.

Then you can exit Diskpart and format the drive.

While you can use Net Use to map to a share that exists on the same PC, you can't use Net Use for this situation, as you would first have to create a share to map to, which requires knowing the drive letter so you can specify the path using Net Share.

As for the drive mapping routine, glad you asked. Going though it again I found a few of bugs, and an unneeded variable (it would always be null at that point so wasn't needed).

If no username or password are passed, the variables will not be initialized, so the routine could use a pre-existing value for the _User and _Pass variables which could cause an error.
There was no way to prompt for the password and specify using the current user by using the * rather than typing the full user name.
The loop that checks the length should start with 4, not 5. Might be able to end the loop on 25 instead of 26, but I didn't test that.

This version clears some variables first, then checks to see if a user (and password) were passed. If %4 is null, then neither were passed, so it now jumps over the check for the fifth parameter.

As the usage section shows, there are three variables that must be passed to the routine:

1. the path to be mapped
2. the names of two variables, one to return the drive letter, and a flag variable:
   0 if the map already existed, 1 if a new map was created

The 4th and 5th values are optional.
The Username will be Parameter 4 (%4), and the Password parameter 5 (%5)
So we first check to see if the username was supplied (%4). If a username is supplied, it creates the /user: switch to be used latter. It then checks to see if a password was supplied.

Specifying * for the username means you will use the currently logged on user, and you can now specify * for the password so you will be prompted for the password. This could be useful in a work setting if the system is left unlocked, preventing anyone from running a script that uses this routine unless they know the password of the current user.

Specifying * for the password means you will be prompted for the password.

The Net Use command output is 4 columns: Status, Drive Letter, Remote Path, and Network Type. The Remote Path column is 25 characters wide, followed by a space, then Microsoft Windows Network. Paths shorter than 25 characters are padded with spaces. If the Remote path is 26 characters or longer, the Network Type column is put on the next line. The Remote Path will still have one space added to the end though.

So we check the position of the last character of the share name we are looking for. The loop starts with 4 because the shortest share name is 5 characters (\\A\B). Remember that the first character is Position 0. If the last character is Position 24 or less (length of 25 or less), the name gets padded with spaces, then the first 25 characters are extracted.
We then add a single space and a period, then the period is removed. The period is used just to make it easier to see that a space is being added, and to make sure the space doesn't get eliminated in a copy/paste.

We then do a Net Use command, pipe it to find to eliminate any shares that do not conatin the name we are looking for, then remove the Microsoft Windows Network from the end if present.
The If statement then checks to see if we have an exact match.
This is needed because the name we are looking for could be a parent folder to an existing share. Example, if we want to map to \\Computer1\Backups and also have maps to these:
\\Computer1\Backups\Monday
\\Computer1\Backups\Tuesday
Find will find them, so we need to do a check for the exact name.
If a match is found, _PDrv is set to the Drive letter.
If _Pdrv has a value after the loop completes, the routine is exited, setting the 2nd parameter to the drive letter and the 3rd parameter to the Flag value which is 0
If _PDrv does not have a value, then _Flag is set to 1, and a Net Use command is executed to map the share to the next available letter.

If this completes without an error, we jump back to the For loop to find the Drive Letter that was assigned. You could also capture the output of the Net Use command using a For loop and parse the output for the Drive X: is now connected to... part to get the Drive letter, but this wouldn't let you return the Errorlevel to the caller if there was an error without adding a bunch of extra checking.
If there is an error, it simply returns. The Errorlevel can then be checked to see if an error occured. For example, Errorlevel will be 2 if the Path can't be found (System Error 67).

[scrfix]

Originally Posted by Squashman

Posted via Mobile Device
I think you are confused on what you are trying to do.

Not confused as to what I want to do. Just ignorant on how to accomplish it.

Jerry,

I think I actually have something but I am having some issues with it.
I found out that if I utilize a schtasks script in combination with a JT script (I have to include the JT.exe in the compiler however it works). The password is not 1234. I am simply utilizing that because even though I have limitblankpassworduse set to 0 it still within the command line will not let me put a NULL password. You can download JT.exe from here: ftp://ftp.microsoft.com/reskit/win2000/jt.zip (I understand that it says Win2000. I am not utilizing it for anything other than the RunOnlyIfLoggedOn property. I am not utilizing it for anything else other than that and the RunOnlyIfLoggedOn feature works.

schtasks /create /RU %username% /RP "1234" /SC Daily /TN "My Task" /ST 01:00:00 /TR "%userprofile%\Desktop\acb.exe"

and then utilize the following command in JT

jt /lj "%systemroot%\Tasks\My Task.job" /sj RunOnlyIfLoggedOn=1

I end up with an error. (This is not my question. I know how to fix the error).
It will not run because in the run portion of the schedule task there is no quotes and there are spaces. Also, in the Start In portion it only has C: (The C: in Start In doesn't make a big difference in running or not).

The Run only if logged on is checked.

Now in order to repair it, I have to go to the task properties and manually add the quotes. I don't even touch the Start In. I right click on it and run and it runs perfectly.

However, If I attempt to add quotes within the command line, it fails. Here is the code I am utilizing to add the quotes.

schtasks /create /RU %username% /RP "1234" /SC Daily /TN "My Task" /ST 01:00:00 /TR "\"%userprofile%\Desktop\acb.exe\""

and then utilize the following command in JT.

jt /lj "%systemroot%\Tasks\My Task.job" /sj RunOnlyIfLoggedOn=1

Now, when I include the escaped quotes, the Start In portion is actually correct and the quotes are around the Run portion. If I don't run the jt command and I manually select the Run Only If Logged On checkbox then the program runs with no problem. If I utilize the JT command, it checks the box but doesn't run.

I have not attempted sending username and same password with JT yet. I will be trying that as soon as I am done here. I also have not attempted to strictly make the scheduled job with just JT. I know how to load but have not gotten through the 15 pages of documentation to see how or if you can create.

I know that there is some way to get this to work because Google does it. I have attached an image to demonstrate this. I know I didn't check the run only if user is logged on and set it up as Kammi for the username.

[scrfix]

Okay,

I had yet another idea. I have not been able to test this but will test later.

1. If I reset the person password to say 1234 or whatever.
2. If I then set the task with the JT scheduler and not the schtasks command and set the run only if logged on with that.
3. I then remove the persons password.

Now this would require the user to have to re set up their password but I don't see any way around this, do any of you?

This also would not work if the end user was on a domain but I am not programming for that. I am merely programming for the majority of our computers which are stand alone pc's.

What do you think? Pros/Cons? Good Idea, Bad Idea? There is a different way Wayne, do this instead it is more effecient?, etc etc etc.

The ultimate goal is to get my bat to run automatically without the necessity to worry about the change of a password.

[TheOutcaste]

JT seems to work fine for me.
XP Pro SP2
Logged into the Administrator account.
Created a task using a folder with spaces:

schtasks /create /RU Jerry /RP jerry /SC Minute /mo 2 /TN "My Task" /ST 00:30:00 /TR "C:\Script Folder\test.cmd"

It runs every 2 minutes
test.cmd just creates a file with the date and time as the name:

@Echo Off
Set _File=%date:/=-%-%time::=-%.txt
>"%_File%" Echo.Time=%time%
>>"%_File%" Echo.Username=%Username%

File is created every 2 minutes.
Ran this command:

jt /lj "%systemroot%\Tasks\My Task.job" /sj RunOnlyIfLoggedOn=1

Waited 10 minutes, task never ran (as expected)
Logged onto Jerry account and task runs every 2 minutes.

Don't know why it's not working for you. Have you checked the Task Scheduler's log to see if it has any errors? (Open Scheduled Tasks, Advanced | View Log)
I didn't try setting it to not require a password. Changing the password causes the task to fail to start as you would expect, and changing it back allows it to start.

Looks like they fixed this for Vista and Win2k3, you can use the /it switch with schtasks to specify Run only if logged on.

You're best bet is to use the System account, which needs no password, or create a separate account just for scheduled tasks. Or use the Administrator account and have them use a batch file to change the password if they need to. The batch file would then enable changing the password, change it using Net User, disable password changing, then change the password on all of the scheduled tasks.

Be aware that using Net User to change a password for any account but the one you are logged into is the same as reseting the password from the User Accounts applet. The user will lose access to any encrypted files and will have to import their key to regain access, or have a password reset disk to change their password to gain access to the encrypted files.
They will also lose any stored passwords for Web sites or network shares.

Changing the password back will not fix this, you have to have a password reset disk or the exported certificate and key.

[scrfix]

Hi Jerry,

I too can get it to work if I know the original password. On a lot of these machines, I will not know what the password is.

Try utilizing it without the /RP or with an incorrect /RP. The set the run only if logged on.

This should work because it is supposed to no longer care what the password is but it doesn't. The box will be checked but if you attempt to right click and run the scheduled task, it will come up unable to run.

I am on a Windows 7 machine right now. I will head back to my XP machine when I get a chance and take screen shots and post them.

Updated 09-05-09 1:03pm EST
I cannot utilize a system account because it will not run interactively. I need it to run interactively.

Thanks for the tip on the EFS. Forgot about that. Okay changing via net user is out of the question.

I run into a lot of computers that are using the administrator account on Windows XP Professional as their current login. If I reset the password utilizing the Administrator account, I run the same risk with EFS.

I will post the log entry as soon as I get over to that computer again.

[TheOutcaste]

Got a little tunnel vision, was focusing on getting Run only if logged on checked rather than how to run if the user changes their password.

Run only if logged on has nothing to do with the password. It's purpose is to indicate that the task is interactive and should only run when the user is logged on so they can interact with the task. It doesn't let the task run without checking the password. If the Run only if logged on box is checked it doesn't ask for a User name/password because it knows to use the current user's credentials, not because a password isn't needed.

Otherwise, anyone could create a scheduled task and use it to access a user's files, including encrypted files, by simply knowing their user name.
And if set to allow blank passwords that doesn't mean no password. A blank password is still a password (length of 0), and must match.

If the task needs to interact with a user, you have to know that user's password for the task to run, or schedule it using AT with the /interactive switch, which as you know no longer works on Vista. One problem with AT; if there are two or more user accounts logged on at the same time, I'm not sure how it determines which one to interact with.
It seems to pick the account that created the task if it's logged in, or picks the account alphabetically if the creator account is not logged on, but I haven't done enough testing to confirm that. It may pick the account that has been logged on the longest.

[scrfix]

The AT command doesn't work across a network at all so I ran into a problem with that one when working with a mapped drive.

The run only if logged on option I know doesn't have any play on the password with the exception that it utilizes the credentials that are already utilized at logon.

Now, Google does this with no problem (see my attached pictures in one of the above posts). They have the run only if logged on checked and they set the scheduled task. There must be a way to accomplish this. They don't know my password. How do they accomplish it?

[TheOutcaste]

OK, I think I'm on the same page now. Could have sworn I'd created a task and checked the Run only if logged on box and the task would fail if I changed the password. Now it seems to work just fine, but won't work if using jt.exe to set that flag.

The header info from the jt.exe file indicates it's actually from the WinNT resource kit from 1998, so I'm guessing it just doesn't set things correctly for XP. It also doesn't set the Log on as a batch job User Right that is set by schtasks.exe or the GUI.

From what I can find, on XP the only way to do it is using C/C++ and use the COM+ API functions, or check the box using the GUI.

Some links to info:
http://msdn.microsoft.com/en-us/library/aa381276(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa381283(VS.85).aspx

And code examples:

http://msdn.microsoft.com/en-us/library/aa383579(VS.85).aspx

[scrfix]

Jerry,

I did not see that you posted. Thank you for that. I will look into that. I am getting into season now so I will be busy until April when I will hit this again. I will in my spare time look into programming it in C++. I can program command line C++ but never attempted GUI and it has been a little while for it. Time to brush up on my C++. I have no clue how you found that. I looked everywhere.

Thanks,

[scrfix]

Jerry,

As far as not setting the Log on as a batch job User Right that is set by schtasks.exe or the GUI, is there a way to manually set this? Perhaps this is the problem?

Where do I check that at if I want to test?

Try this.

1. Set the task as described above with JT. You will see it doesn't set the log on as batch job user right as you described.

2. Now, open the task manager job, manually browse to that same file in the same location as what was set, then click OK. Now the program works. Is the log on as batch job user right set now?

Updated 9:58am
October 19th, 2009
I found a NSIS installer creator program that calls on the task scheduler itaskscheduler COM and sets the run only if logged on and the same thing happens as the JT.exe. It creates it no problem, it checks the box and nothing else happens.

http://nsis.sourceforge.net/Download: Download the software
http://nsis.sourceforge.net/Category:Tutorials: Basic Tutorials
http://nsis.sourceforge.net/Scheduled_Tasks: The code for scheduled tasks

I have attached my code for testing a bat file.
I have already included the code for checking the box.
I have already changed the code to work with the folder and the test.bat file I have enclosed.

Install NSIS
Place the testbats folder in your root C drive.
Load the task-scheduler-test.nsi file into NSIS
It will spit out an exe file
Run the exe

The exe will have the box checked but will not run until you manually browse to the location of the file and then click OK. What is the difference? Perhaps that user right you mentioned?

[scrfix]

Well,

I have not been able to resolve the issue but I did create a work-a-round for it. I also ran into yet another snag. Windows XP Home edition does not natively have schtasks. I just found that out when I create a batch to create the scheduled task and had to run it on XP Home. It wouldn't run... ahhhhhhh Back to the drawing board.

Be advised to whomever is reading this that this work-a-round is a dirty work-a-round but it works and after months of deliberation, short of contacting MS themselves, it is the best I could come up with.

So I am now back to where I began. Here is what I did. I created a Macro utilizing the Jitbit Macro Recorder.

You can always copy the schtasks from XP Pro to XP Home but that would violate the MS copyright. Not wanting to take on the big dogs I found a different way.

So now I know that I cannot utilize schtasks for this task because of XP Home so I will have to attempt to make JT.exe work.

1. JT.exe is a freely downloaded task scheduling program that can be redistrubited to computers with the EULA agreement in tact. I think there is a copy of it in one of these posts. If not, MS has it available for download. Just search Google.

Example for utilizing JT.exe. The below example will schedule a task named My Scheduled Task Name to start at 1am today and run daily. It provides the pathway to the file and the working directory to the file. It tells it to start even if it is on batteries. It provides a MAX Runtime in milliseconds and most important It does NOT check the run only if logged on box. This cannot be checked yet UNLESS you know the persons username and password. It also does not autostart the job immediately.

jt /SAJ "My Scheduled Task Name.job" /CTJ StartTime=01:00 StartDate=TODAY type=Daily typearguments=1 /sj ApplicationName="C:\PATHWAY TO MY FILE I WANT TO RUN\MYFILE.exe" WorkingDirectory="C:\PATHWAY TO MY FILE I WANT TO RUN" DontStartIfOnBatteries=0 MaxRunTime=259200000 RunOnlyIfLoggedOn=0 /sc "%userdomain%\%username%" PASSWORDHERE /SM ""

2. I created a Macro with the jitbit Macro recorder utilizing only keys to get to the scheduled tasks, open up the correct scheduled task and then manually check the Run Only If Logged On box. JitBit compiles to an EXE and will run on any machine. I now run the macro and it checks the run only box and now the scheduled task will run properly even if you do not know the users credentials.

You can access the scheduled tasks easily by utilizing
Press and Release Windows Key+R (This will bring up the Windows Run Dialogue Box)
Type control schedtasks (Then press ENTER. This will bring up the scheduled tasks window and automatically close the Run Dialogue box)
Type out the name of your scheduled task (Then press ENTER. This will ensure that you are on your scheduled task and then open the properties window for you)
Press and Release ALT+L (This will check the box then press ENTER to save that change and close the Window.)

Jitbit has options to wait for a Window to open before proceeding and to close windows. It is a rather nice program.

I am sure there is another way because Symantec and Google both seem to be able to check that box without having to go through this and without needing my credentials but I will be damned if I can find it. I have consulted with tons of people for months and months searching for an answer.

[Squashman]

There is an API for scheduling Tasks. Which is how Google and Symantec do it. So you would actually have to learn a C++ or some other language that can communicate with the API.

[scrfix]

Squashman,

If you look at my above post prior to that one you will see that I have been down that road. NSIS utilizes the API call. It does the same thing as the JT.exe.

1. It creates the task no problem.
2. It checks the run only box with no problem.
3. The task doesn't run. I can only presume it is because of what Jerry mentioned before about the logon as batch user right not being set. I don't know how to check that so I could not verify and I did not hear back from him when I asked above.