/build/static/layout/Breadcrumb_cap_w.png

K1000,scripting and BAT files-listens like a toddler

Hello IT Ninjas-

This issue has been an ongoing situation since we deployed our KACE units a year ago.  Scripting has been the occassional thorn in my department's collective side as it's like the K1000 picks and chooses when to do what it's told, do nothing or what now seems to be do SOME of the things.  Here's the latest example that got me to jump onto the boards:

I needed to deploy a new URL shortcut to everyone in the company's desktop.  However, a certain group of people have access and a separate shortcut to a more "advanced" version of this web site.  This would be no problem-create a batch file that sniffs out the username and if the person who's logged in is on the list, skip to the end of the batch file.  If not, clear out any shortcuts that would confuse the user and then copy in the proper one.  Here's the batch file (with user names changed to protect the innocent with explanation):

@echo off
[here's the user list.  If the name matches the username, go to "end")

IF (%username%)==(fhtehd) goto end
IF (%username%)==(sdfhtjk) goto end
IF (%username%)==(dsfhrtej) goto end
IF (%username%)==(wsdetjsm) goto end
IF (%username%)==(drffhkk) goto end
IF (%username%)==(edhrtejsrtj) goto end
IF (%username%)==(dhjsfky) goto end

[there's more but you get the idea]

del "c:\documents and settings\all users\Desktop\Prod.url"
del "c:\documents and settings\all users\Desktop\Training Manuals.lnk"
del "z:\profiles\all users\Desktop\Prod.url"
del "z:\profiles\all users\Desktop\Training Manuals.lnk"
del "c:\users\public\desktop\Prod.url"
del "c:\users\public\desktop\Training Manuals.lnk"
del "z:\profiles\public\desktop\Prod.url"
del "z:\profiles\public\desktop\Training Manuals.lnk"

[these clear out the shortcuts in different locations and drives as some machines have Data Igloo installed]

copy "s:\Desktop Links\Employee Self Service.url" "c:\documents and settings\all users\Desktop\Employee Self Service.url"
copy "s:\Desktop Links\Employee Self Service.url" "z:\profiles\all users\Desktop\Employee Self Service.url"
copy "s:\Desktop Links\Employee Self Service.url" "c:\users\public\desktop\Employee Self Service.url"
copy "s:\Desktop Links\Employee Self Service.url" "z:\profiles\public\desktop\Employee Self Service.url"

:end

Now if I ran this directly on any PC, it would function just right every single time.  Now I set up an Online Script on the K1000.  It's set to run as User logged in to console, the task Verify is set to "Always Fail" (as I was instructed ages ago to have a "better chance" of things working) and in Remediation I have it launch a bath file from the network (I've stopped creating a batch file within the task as most of the time it never, ever runs).

So when I run the script, it goes to the designated PC, runs and gets as far as the clearing of the old shortcuts but stops dead.  No copying of the new shortcut.  If I rearrange the two chunks of commands so it copies first THEN deletes, the copying happens but not the deleting.  I've tried referencing the actual path of the "s:" drive, changing the "Run As" to from current user to system and then to a domain admin account with no difference.  When I took the copying part out and created a separate batch file to run from a separate Script, THEN it worked.

 

So does anyone know what the deal is?  Why is it when a batch file is run from the Kbox it seems to be a crap shoot if it works?  Is there something I'm missing?  It should just run the batch file as if the user themself ran it but yet it doesn't.  Do I have to offer the Kbox a sucker for it to work?

Any help would be greatly appreciated.  Thanks!


0 Comments   [ + ] Show comments

Answers (3)

Posted by: SMal.tmcc 11 years ago
Red Belt
3

change the copy command to xcopy.  Is the s drive already mapped?

For the script

create an online script, run as all logged in users,

upload your batch file as a dependancy.

for verify just use verify that the directory c:\windows exists.

on success

launch a program

use $(KACE_DEPENDENCY_DIR) as the directory and your batch file as the program

 


Comments:
  • Yes smal is right, use the dependency. Paths are almost always the stumbling block in scripts. Using a dependency helps to eliminate this. - jdornan 11 years ago
  • I tried this but I get an error from the KACE that it couldn't find the file specified. I looked at the path and there was a "\\" after the dependency directory. The Kbox automatically puts another whack after the directory. I extracted the actual path by hovering over the link of the script in the list, put it into the directory path, then ran the script again. Same error but discovered another issue: the Kbox doesn't copy the BAT file to the target PC! The folder is there but no file. - Datamoose 11 years ago
    • What version of kace server and clients are you? - SMal.tmcc 11 years ago
    • should get put in kace\scripts\### where ###= the id=### if you hover your mouse over the script name on the kbox - SMal.tmcc 11 years ago
      • The version is v5.3.53053 for the server and 5.3.53177 for the client. The files get put into (doc and settings\all users or programdata\)dell\kace kbots_cache\packages\###. But in this instance it didn't. - Datamoose 11 years ago
  • Here's another kicker: apparently the "IF" statements I have at the beginning are totally overlooked. In my lab it worked fine and I retested for kicks and it skipped over what it needed to as the username I was using was on the list. Totally weird. - Datamoose 11 years ago
    • There are no parentheses in basic batch scripting; instead use labels and goto statements:
      IF string1==string2 goto label1
      IF string1==string3 goto label2
      also try using the quiet switches on you del and copy commands
      del /q /f filepath\filename
      xcopy source destination /q /y - SMal.tmcc 11 years ago
      • There's not? We've got batch files that have the parenthesis to assign printers when a user first logs into a computer and it works fine. I just created a simple BAT file using both methods and both ways work.

        Now that I type this....I spoke with the other person who also worked on the scripts we set up in the Kbox a year ago and he mentioned that some users are set up with uppercase usernames in Active Directory. My script and what's above didn't take into consideration the case of the string and it never occurred to me in a million years to slap a /I after the IF. For what he ran into, he used Notepad ++ and just uppercased the names.

        I'll have to check that. When you get a call that "tons of users are missing icons", it makes you assume your whole dang script was broken somehow.

        UPDATE: yup, that was the problem. To avoid typing over 80 usernames, I pulled the usernames off of active directory. It didn't click with me that the uppercase usernames would make the IF statement false.

        That's one mystery down so now to find out why it'd only run half of the commands.... - Datamoose 11 years ago
      • Sorry I should have not said no should have said not required. old dos days did not use them. Do not know how the script would handle it but try putting some pause statements in the batch for testing to see what shows - SMal.tmcc 11 years ago
Posted by: dugullett 11 years ago
Red Belt
2

Have you tried creating a seperate task for the other half of the script?


Comments:
  • Yup and that works like a charm. - Datamoose 11 years ago
Posted by: ms01ak 11 years ago
10th Degree Black Belt
2

Quick question do your users have read and write access to the folders specific ie the public folder? Because if they are limited users (non admins) they can't read/write to that directory. You need to be an administrator to delete those files or create new ones. I'd also like to point out that it would be better if you had a log files to check against. 

try this del "c:\documents and settings\all users\Desktop\Prod.url" > C:\logfile\errors.txt  (that way you can see where the problem is with the file.

Hope this helps,


M

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ