/build/static/layout/Breadcrumb_cap_w.png

Windows 7 batch file won't "write" using KACE1000 scripting

 

I can do this in Windows XP but not Windows 7 using scripting in the KACE1000.   I need help with Windows 7.

The goal is to push out a certain local group policy configuration to out-of-WAN computers using KACE1000 scripting.  This is done simply by overwriting the “Machine” and “User” folders inside the “GroupPolicy” folder at “%systemroot%\system32”.  So, this is basically a process of effectively pushing out folders using the KACE1000. Sounds simple, huh?  It is easy with XP but not Windows 7.

The problem with Windows 7 is that I cannot find a way to run the simple batch file with elevated credentials of administrator.  Please keep in mind I need this to run silently with no user interaction.  You may recall that for Windows 7 to write using a batch file locally, one must first open the command prompt on the machine by right clicking on it and choosing “run as administrator”.   How does one effectively  do that when using KACE1000 scripting?  

I tried changing the user the script itself runs with, since there is such a choice when configuring the script in the KACE1000, but that did not solve the problem.

Here is what I did that worked for Windows XP:  From a computer that had the local group policy configured the way I want, I zipped the “GroupPolicy” folder found at “C:\Windows\System32” and  copied it to a network location my KACE1000 could access.  From the KACE1000 I created a script job, adding a dependency of that zipped folder.  I created a Verification that the “grouppolicy” folder exists on the computer,  then created a batch file that copied that “GroupPolicy” folder from the Kace dependency folder “C:\ProgramData\Dell\KACE\kbots_cache\packages\kbots…” to “C:\Windows\System32\GroupPolicy”.  Like I said it worked like a charm on Windows XP.   But on Windows 7, even though the script ran, it did not actually copy the data to C:\Windows\system32\grouppolicy.  It’s all about access rights. 

To make this work on Windows 7, when LOCALLY run, I can use the exact same batch file but I must first open the command prompt “as administrator” for that batch file to actually copy the folders.  So, I need a way to make the KACE1000 script run that batch file on a client computer, “as administrator”.

Any solutions?  Many thanks

ITMonkeyBoy

 


2 Comments   [ + ] Show comments
  • We are having the same issue.

    We have been using a KACE script to install software on our Windows XP computers. These scripts have been working fine with Windows XP.

    These scripts fail to run on Windows 8.1 due to an error related to permissions.

    Is there a way to make the KACE script run with administrative permissions? - darshahlu 9 years ago
  • I am having same issue unable to write to C:\windows\system32\grouppolicy directory - ggibson 9 years ago

Answers (7)

Posted by: SMal.tmcc 10 years ago
Red Belt
1

What mpace means by using the scripting engine

You should not have to do a xcopy but if you ever need to you do that as a script call instead of a batch this way

 


Comments:
  • Oh. Well I have been using the scripting engine all this time. Below are pictures of what I have used that works on 32-bit OS only. Please take a look at my picutres below and let me know if you think what you are suggesting above is going to succeed in writing to a 64-bit system. After tyring, my pictures will not post in this "comment" box, so i have to "enter a new answer" for it to be visible.
    thanks - ITMonkeyBoy 10 years ago
Posted by: Timi 10 years ago
7th Degree Black Belt
0

Using a script you has a  Run As section as shown here:

 

 


Comments:
  • Thanks for the reply. My paragraph four addresses that; it had no effect in the final outcome. A more detailed description is that I tried the "run as" feature of KACE1000 scripting, using a domain admin level account in the "run as user" and that did not cause the batch file to write the folders to their target location. The default of "run as local system" worked on windows XP but not on Windows 7. Any other ideas? - ITMonkeyBoy 10 years ago
Posted by: dugullett 10 years ago
Red Belt
0

Your Windows 7 is it x64? Do you have UAC enabled?


Comments:
  • Hello. Thanks for the reply. No, UAC is not enabled for any Windows 7 whether x64 or x86. Both Windows 7 x64 and x86 have this issue I descibe in my post, by the way. - ITMonkeyBoy 10 years ago
Posted by: mpace 10 years ago
Red Belt
0

Try writing a batch file and then have the kbox execute it as a script dependency using the "Run as User" option using an account with local admin rights.

Or include the bat in your zip payload. The point is to get the batch to do the work.


Comments:
Posted by: ITMonkeyBoy 10 years ago
Purple Belt
0

 

 

Thanks for the post.

Your suggestion has been attempted as described in my original entry and my response to the post by "Timi". The "run as user" with local admin rights does not work.  Also that is not practical considering I will be deploying this to many computers, many of which are not domain members. There is no user account in common to all those computers, with the exception of the default local administrator account - but to use that one must specify the account with the format of "machine name\user name".  The "Machine name" cannot be used in a scripting process that is being deployed to many computers as there is nothing i see to support that type of entry.  Perhaps you know something here I do not? Please tell if you do.

One thing I did was to rewrite my batch file.  The path I used originally to create the syntax was from a "copy and paste" to create the script commands.  After I removed that command string and retyped the same entry, manually... now the Windows 7 x86 will write the folders, but the windows 7 x64 still will not.  Also, using the entry "$(Kace_Dependency_dir) does not work.  I have to define the path specifically, not generically in order for it to write the folders on Windows XP and Windows 7 32-bit. And it has never worked for 64-bit windows 7 with "$(KACE_DEPENDENCY_DIR)" or the specific path.  Here is the command in the batch file that works in KACE1000 scripting for XP and 32-bit Windows 7 (but not on 64-bit Windows 7):

xcopy "c:\programdata\dell\kace\kbots_cache\packages\kbots\500\group policy config" "c:\windows\system32\grouppolicy" /e /h /y

Any other ideas are appreciated.  Thanks.


Comments:
  • they may need to go to the c:\windows\sysWOW64\grouppolicy for x64 - SMal.tmcc 10 years ago
    • Hello. I tried that new location as you define above. The short story is that it broke group policy on the machine.

      Details: The KACE1000 scripting did write to that location, but the group policy was not applied to the computer, even after a gpupdate /force. I notice that on other test computers, when overwriting the location of C:\windows\system32\grouppolicy, that the location of C:\windows\syswow64\grouppolicy was automatically written to as a result of that. So, it appears that trying to write directly to C:\windows\syswow64\grouppolicy is not the correct approach. After writing directly to C:\windows\syswow64\grouppolicy, it caused the Resultant Set of Policy, when run, to show a red "x" on both the Computer Configuration and User Configuration. Once I manually overwrote the folders inside c:\windows\system32\grouppolicy, then the red "x"'s on rsop.msc were not there any longer, AND the group policy was applied to the computer. But I had to run that last step manually.

      So I am back to "square 1" of Windows 7 64-bit not allowing the KACE1000 scripting to write to C:\windows\system32\grouppolicy. However, I still have yet to try what mpace suggested in his last post. I will take a look at that. - ITMonkeyBoy 10 years ago
  • Sorry, there is a lot of information in your initial post and I hadn't had my coffee yet when I responded. A couple of things:

    $(KACE_DEPENDENCY_DIR) has always worked for me, regardless of Windows version or architecture as it is a K1000 system token variable. You won't be able to use it inside of a batch file but as far as the Scripting UI it should work just fine.

    Have you tried using the K1000 Scripting engine to accomplish the copy? Actually building it out in the Scripting engine might work better since you are trying to access system files and the Agent uses the local computer's service account to carry out these changes which, by default, should have read/write access to directories located in C:\Windows.

    You can use the format localhost\username (replacing 'username' with the computer's local administrator account) to run as a specific account across multiple computers. The usual .\username format should also work for Win Vista and above.

    I believe SMal.tmcc is onto something with his comment about using sysWOW64 so you should try that. - mpace 10 years ago
  • I think I initially misunderstood what you refer to above. So, please explain what youi mean by using the "K1000 Scripting Engine". After first I thought it referred to a scripting wizard, but there is none that I can find. I have been constructing what I am trying to do using the K1000 Scripting module, where from "choose action" I choose "add new item" and build the script from that. Is that what you mean by "K1000 Scripting Engine"? If so, already "been there done that" as the saying goes. - ITMonkeyBoy 10 years ago
    • could not post picture, see my new answer for your answer to this - SMal.tmcc 10 years ago
Posted by: ITMonkeyBoy 10 years ago
Purple Belt
0

Verify

  1. Verify that the directory c:\windows\system32\grouppolicy exists. Verify a directory exists...
    Directory:

On Success

  1. Run the batch file Over write GP folders with params . Run a batch file...
    Script Name:
    Batch file:
      Wait for completion
    Parameters:

     

    The entire command string, that is cut off above is this:

    xcopy "C:\programdata\dell\kace\kbots_cache\packages\kbots\500\group policy config" "c:\windows\system32\grouppolicy" /e /h /y

    For this to work on Windows 7 32-bit I have to choose "run as all logged in users".  This does not work with any other option for "run as..."


Comments:
  • Try to upload just the zipped gpo and use the built in unzip to that directory instead of doing a xcopy, you should be able to run that offline as system even. Try to get away from using uploaded batch files. - SMal.tmcc 10 years ago
  • I may not have nade this clear, but in all my testing I did upload a zipped gpo. I have a question about the directory you mention called "$(KACE_SYS_DIR)". I searched ITninja but did not find a definniton of where that points to on a computer. Is it the "system32" folder, or some other location? And does it's location differ as to folder path on a 32bit system compared to a 64bit system? - ITMonkeyBoy 10 years ago
    • under your k1000 script look for "Policy or Job Rules:" just above the Tasks. There is a little yellow question mark, click on it.

      You do not need to use variables, I am a lazy typist so I use them as well as Env Variables, http://windows7tips.com/environment-variables-windows-vista-7.html - SMal.tmcc 10 years ago
  • Okay, thanks for that. it's helpful. I recreated my scripting job, based on information provided in the "Answer" near the top of the list of entries here in this series of postings. But again nothing wrote to the 64-bit machine even thoiugh the "run now status" was successful . Here is how I set it up.

    -Chose the OS for Microsoft Windows 7 Professional x64
    -Chose "Run as Local System"
    -Renamed my zipped Group Policy folders on the network to "GPO.zip" and uploaded it to the KBOX
    -Under Task 1 I chose "Verify a directory exists" and the path is $(KACE_SYS_DIR)\grouppolicy
    -I chose "On Success Unzip a file" The Directory is $(KACE_DEPENDENCY_DIR). The file name is GPO.zip, and the Target is $(KACE_SYS_DIR)\grouppolicy

    When I ran this it did not write to the client computer. I looked at the Run Now Status log and here is what it showed under Run Success:

    Output Log
    Running as: SYSTEM
    Directory DOES exist: C:\Windows\System32\grouppolicy
    Activity Log
    Checking if directory exists: C:\Windows\System32\grouppolicy
    Unzipping file: C:\ProgramData\Dell\KACE\\kbots_cache\packages\kbots\501\gpo.zip C:\Windows\System32\grouppolicy

    As you can see there are no switches involved in what ran. They are needed (/e /h /y) for this to run, in my test evironment at the local computer done a few days ago before i started using the scripting in the KBOX.

    I failrly new to scripting, so forgive my newbieness please. Any ideas how I can get those switches into the scripting engine job setup? (I still don't understand why my past testing worked for 32bit Windows 7 but not 64-bit windows 7).. I hope you can help shed some light on this. Thank you. - ITMonkeyBoy 10 years ago
    • with 64 bit systems there a usually two of the system programs, one 32 and one 64 bit version. They handle certain default switches differently then their counter part. Looking on my win 7 64 machine, there are 2 xcopy exe's on in the system32 and one in the sysWOW64. the only difference looking at them is the size and time stamp is different. - SMal.tmcc 10 years ago
  • back to your script, you say need the switches that you use with copy. The unzip does not do switches so you would need to do what I did in the picture I gave you.
    verify
    so success
    step 1 unzip a file to the kace dir instead of system by putting $(KACE_DEPENDENCY_DIR\grouppolicy as the target
    step 2 launch a program and use the xcopy picture commands to copy it the kace dir to the system dir - SMal.tmcc 10 years ago
  • I tried this, as your picture showed for xcopy. It did not work. The task did run, but did not write to the target Just like all the other attempts. I did construct it exacly as the "picture" showed. I did not attempt to extrapolate concepts one might use related to the picture. Does that make sense? Was your picture supposed to be used as is? Because when I did that, there was no "xcopy.exe" created as a result of those entries you showed. Perhaps I did not understand what you meant?

    You know I came to a dead end with KACE support on this issue. That's why I'm posting here. KACE support has proven for me, in the great majority of cases, a waste of time. I have opened about 12 or more ( I have lost count) support cases in the last 18 months and only one, from a Mr Gillespie was helpful. That case was escalated to him as a higher level tech. The usual techs there talk concepts only and if you need details they say they cant do that, and if I want that kind of assistance we have to pay $400 per hour consultancy fee. There also is no real training on how to use effectively the KBOX1000 apart from basic training which is not related to my issues here it seems to me. It's frustrating to spend the kind of time I have spent with this KBOX1000 for scripting/managed installs and get the little results I have obtained. When the Kace techs would not help, I plugged along until I found my own solution. And it took a long time in all cases. This unit was sold to us as a "can do anything" solution. They said if you can get a command line to run locally on a system, then KACE can deploy it. That has turned out to not be accurate in some cases. This one in particular. I can run this "all day" on the machine locally and it works. use KACE scripting on 64 bit and it does not work.
    '
    So, I'm glad you have been able to assist, and other posting here. I hope there will be a solution.

    I do not know where to go from here. I can get this to run on 32bit but not 64 bit machines using the KBOX. Perhaps the KBox is using the cmd.exe from the syswow64 folder you mention above. If so, I have not idea how to approach that. When one types in "command" from the Windows search box, you receive only ONE cmd.exe, not two. It is the $windir%\system32\cmd.exe. That evidently is the 32-bit one. This may be the problem for me, that the scripting on the KBOX uses the %windir%\syswow64\cmd.exe . If so, how does one deal with that concerning Kace scripting??? If that is even the problem...

    thanks for trying. If you have more ideas, please do tell. Thank you so much. - ITMonkeyBoy 10 years ago
  • As soon as I wrote that i realized how to test this. Sorry for the frustration communicated. It threw me off my composure, which affected clear thought. Now I'm back to a more harmonious state.

    So, running an xcopy command locally from the command prompt opened from %windir%\syswow64\cmd.exe does write to the computer with all those switches. I used the batch file present on my test machine from an earlier test as the source of the commands. here it is:

    xcopy c:\programdata\dell\kace\kbots_cache\packages\kbots\501\grouppolicy c:\windows\system32\grouppolicy /e /h /y

    This worked locally on either the 32bit or 64bit cmd.exe, opened in normal mode. It does not work using KACE scripting. I'm not sure if this information is helpful but thought i would include that.

    I also found in other testing that I had to adjust my paths to remove all spaces. If one uses quotes around a path in a command prompt, trying to write to a location, one MUST open that command prompt with administrative rights specifically in order for those commands to write to a location. Even if the logged in user is an administrator on that local computer. That is what my testing proved. - ITMonkeyBoy 10 years ago
    • understand your frustration, sometime you need to vent. You said the xcopy from the syswow64 works for you, if that is so change the path for the xcopy command to c:\windows\syswow32 and see if that works - SMal.tmcc 10 years ago
  • I am not sure what you mean by "...change the path for the xcopy command to c:\windows\syswow32..." - ITMonkeyBoy 10 years ago
    • Sorry working on too many things at once.

      that should be syswow64 - SMal.tmcc 10 years ago
Posted by: SMal.tmcc 10 years ago
Red Belt
0

Sorry working on too many things at once.

that should be syswow64

 


Comments:
  • or if you want to keep it in a batch
    c:\windows\syswow64\xcopy c:\programdata\dell\kace\kbots_cache\packages\kbots\501\grouppolicy c:\windows\system32\grouppolicy /e /h /y - SMal.tmcc 10 years ago
  • I tried this using both your suggestions, using all the 'run as' options one by one. All failed to write to the target. I can run the batch file commands locally with success. Somehow the KBOX cannot access something it needs on the target computers to make this work. How can I test the commands from one computer to the Win764 bit computers? I'm thinking this is a remote command access issue for the target computers, not a KACE scripting issue. - ITMonkeyBoy 10 years ago
  • have you ever worked with pstools psexec, that lets you call remote computers to run batch files. http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx
    Sorry about the run on here, but when I want to make a force GPO like change to a non domain systems like you want, I usually just inject the setting thru the registry vs the file system. - SMal.tmcc 10 years ago
  • I had thought about the registry approach, and was saving it as a last resort, which I may need to do here. I have not worked with pstools and psexec, but have heard about them, come to think of it. If I used it, is it necessary to install it on the target machine first so that the machine can execute the commands? - ITMonkeyBoy 10 years ago
    • you only need to have it on your tech station - SMal.tmcc 10 years ago
  • We have one server with psexec on it and works for all our campus's from that server. It works like a RDP style connection, like if you type \\someothermachine\c$ to connect and then uses that connection to do the work. We use a batch file to call multiple machines with it so it works well in a classroom. You can run a batch to do the xcopy from a share also.

    this is a command to run a program called KALCIE on all machines at redfield 100 lab

    psexec @c:\pstools\classroomfiles\rcb-100.txt -i -accepteula -u domain\installer -p Pa$sword -d C:\Windows\W2D\kalcie

    the rcb-100.txt file contains the machine names

    RCB-100-01
    RCB-100-02
    RCB-100-03
    RCB-100-04
    RCB-100-05
    RCB-100-06
    RCB-100-07
    RCB-100-08
    RCB-100-09
    RCB-100-10
    RCB-100-11
    RCB-100-12
    RCB-100-13
    RCB-100-14
    RCB-100-15
    RCB-100-16
    RCB-100-17
    RCB-100-18
    RCB-100-19
    RCB-100-20
    RCB-100-21
    RCB-100-22
    RCB-100-23
    RCB-100-24
    RCB-100-25
    RCB-100-26
    RCB-100-27
    RCB-100-28
    RCB-100-29
    RCB-100-30
    RCB-100-31
    RCB-100-32
    RCB-100-33
    RCB-100-34
    RCB-100-35
    RCB-100-36
    RCB-100-37
    RCB-100-38
    RCB-100-39
    RCB-100-40 - SMal.tmcc 10 years ago
    • I was wondering if you ever got it to work I have same problem - ggibson 9 years ago
 
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