Cant get my batch file to run...
-
2012年6月20日 下午 06:25
So I found a cool application that you run from a CMD window that lets you set how much idle time before you logoff a user. I decided to make it into a logon script in the GPO. The batch file resides at \\Server\Netlogon. when I try to run the file manually from this point I get the error...
"CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory."
My very SIMPLE batch file is as follows...
@echo off
cd C:\Windows
RISALO.exe 14400 logoffWhen I run the batch file from the local machine it works fine...Is it not working because its trying to run the application which is stored on each local machine? Im really just guessing at this point...I am not a scripting guy but silly easy stuff like this has never been an issue for me before. Any ideas?
The application I am using is called "Idle Logoff" and can be found at http://www.intelliadmin.com/index.php/downloads
所有回覆
-
2012年6月20日 下午 06:37
Ignoring the technical issue for a moment: What will you do or say when this utility logs off the chief accountant's session late at night when he interrupts working on the annual budget in order to have a little snack. You might be looking for a new job ...
Automatic logoff programs sound like a great idea but can have unexpected consequences.
-
2012年6月20日 下午 06:51
Are you sure this is not a trojan?
I'm with Obie - Why? Sounds dangerous.
The correct method to protect a workstation is to set the screen saver to "lock" the workstation after a period of idle time. This can be configured through Group Policy.
If you nave amaintenenace that must be performed then you need to get a buy-in form users as to when this can and will occur. Once they users are alerted then you can logoff/shutdown or reboot any system remotely. Ther eis never a need for a utility like this.
¯\_(ツ)_/¯
- 已編輯 jrvMicrosoft Community Contributor 2012年6月20日 下午 06:54
-
2012年6月20日 下午 06:55
Hi,
You have to map \\server\netlogon to a network drive
NET USE P: \\server\netlogon
Then execute your script from P:
Finally, I assume you made all necessary checks about this EXE safety.
Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu
-
2012年6月20日 下午 06:58
First of all im not a moron...I have scanned the file and havent found anything as of yet...
Second...I am only using in a TEST environment at the moment...
Third...Aside from getting the batch file to work through the GPO running it manually from the workstation works perfectly.
Lastly...Its me and my Boss supporting a ridiculous amount of users and what we say pretty much goes, besides that they would be hard pressed to find a replacement for either of us...(we are giving users 4 hours of inactivity before it actually logs them off)
So...Back to the issue...and not my well being...does anyone know how to make this work...? Thanks in advance for all your support!
-
2012年6月20日 下午 07:00As I said, map your UNC path to a network drive (P:, W: or whatever) then launch your .BAT from there
Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu
-
2012年6月20日 下午 07:06
I took a few minutes to type my last post I didnt see it until after I posted...Thanks..I will give that a shot!
-
2012年6月20日 下午 07:48
@JRV
I wont go into too much detail but yes...there are needs for a utility like this...
We already have a screensaver lock enforced after 10 minutes of idle time which is configured through the GPO. Our purpose for enforcing the logoff policy is not in any way, shape or form related to our security needs.
We constantly have users staying logged in after the end of there shift which will cause delays for certain things...I wasnt aware it was a requirement to explain everything I do to get one answer. Like I said before, there are only two of us here and automating things like this frees up a lot of time.
Right now we are wasting too much time sending emails out to every single person that ends up staying logged in after they leave for the day...This is merely just to save time.
- 已編輯 Maurice Moss 2012年6月20日 下午 08:02 Becuase
-
2012年6月20日 下午 08:10
As I said, map your UNC path to a network drive (P:, W: or whatever) then launch your .BAT from there
Sebastian Sajaroff Senior DBA Pharmacies Jean Coutu
That has absolutely nothing to do with this. A share can execute a bitch just as easily as a drive. All logon scripts are delived via UNC paths.
¯\_(ツ)_/¯
-
2012年6月20日 下午 08:14
You will have to go to the vendor for support. The issues you are having cannot be esily figured out for a third parties custom applications.
Running any aplpication from a logon script requires that you have certain specific things understaood about GP and its interaction with you applicaiton. This is scripting forum is not equipped to deal with custoimm one-off applications.
¯\_(ツ)_/¯
-
2012年6月20日 下午 08:28
My question was about the script not the application...
The GPO launches the script from \\server\netlogon
which points to C:\Windows on the local machine where we put the executable.
I just wanted to make sure there was nothing wrong with the way i did the script since I was getting...
"CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory."
-
2012年6月20日 下午 09:06
This would qualify as cruelty against animals . . .A share can execute a bitch . . .
¯\_(ツ)_/¯
-
2012年6月20日 下午 09:10
This would qualify as cruelty against animals . . .A share can execute a bitch . . .
¯\_(ツ)_/¯
Same thing. They are all of that - the files. Maybe it is an insult towards femal dogs but I assure you I only intended to insult bAtch files.
¯\_(ツ)_/¯
-
2012年6月20日 下午 09:23
My question was about the script not the application...
The GPO launches the script from \\server\netlogon
which points to C:\Windows on the local machine where we put the executable.
I just wanted to make sure there was nothing wrong with the way i did the script since I was getting...
"CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory."
Ther ius no UNC involved in this. The GPO launxhesd the script form the GPO and ther eis nothing you can do to cahnge that.
Your batch file has no indiacations of any UNC. The error message is coming from some other locataion. or the file is C;\windows is NOT trusted.
Microsoft released guidelines about two years ago now. We are not supposed to install files into the Windows folders. They are reserved for the OS. You should place your EXE into a folder in the appropriate Program Files folder for the architecture of the program. (x86 or 64 bit) .
It might be easier to create your batch to look like this as it will eliminate having to send a low level user to the C:\windows folder which is off limits in Vista and later.
Leave the current directory as is always in a logon script or you can get into trouble.
proposed batch
@echo off
c:\"program files"\Risalo\RISALO.exe 14400 logoffThis will leave the current folder in a user writable location. Many of these free knock-off utilities assume the file is run in a writable folder.
You may also have an issue with an older API that cannot be run when the batch call9ng it is on a network share because it attempts to use the batches file path as its how, This is a sign of a very badly designed program.
Microsoft makes a tool called the Application Compatibility Toolkit which will not only discover these issues but will generate "shim" code to adjust the behavior of badly written and older API apps.
¯\_(ツ)_/¯
- 已標示為解答 Maurice Moss 2012年6月21日 下午 02:33
-
2012年6月21日 下午 02:33
Awesome!
After we put the executable under Program Files it actually works! Thanks for all the help JRV!
-
2012年6月21日 下午 04:13
Awesome!
After we put the executable under Program Files it actually works! Thanks for all the help JRV!
Great - I wan to stress this for a;ll who may ebd up here. Since Windows Vista Mocrosft has notified all internal departments and vendos/partners that teh WIndows folder is off limits. It is for use by the Microsoft OS people only except for certain controlled items such as the GAC. Th4e story I read was that the Microsoft Office team had made some changes to a shared DLL in teh WIndows folders and had caused som pain for may customers due to the negative impact. I beleive that ther is at least some truth to this story because MIcrosoft has documented in BPs that applications and users should not place files into the system folders or make changes to files in the system folders directly.
In Vista and later we see that browsing and other things are disabled by default for the system folders. Programs that are built as free or standalone utilites do not usually take time to be careful where they may be placing temporary files. They usually create temp files and logs in the folder from which they run.
This issue is may be that issue however if the code was not changed and the file only moved then I suspect that some other issue was causing the problem because a standard user cannot write into 'Program Files" unless the security of the folder was altered. This would be a very bad thing to do so I hope that my code was used a path was specifed for the EXE rather than changing the current folders is what actually fixed the issue.
¯\_(ツ)_/¯
.png)
