Variables such as:

$(KACE_MAC_ADDRESS)
$(KBOX_MACHINE_ID)
$(KACE_HARDWARE_ARCH)

etc?

I'm wanting to prompt at the beginning of an imaging process for the technician at the keyboard to enter some information which I need to store temporarily throughout the imaging process on the temporary (t:) directory, and it will need to be stored in a machine-specific file and/or directory.

If the script I'm using knows the computer's MAC address or something similar, the script can use that info to create a machine-specific file/directory. If there's already a machine-specific directory I can use, that would work also, but I'll need to know how to ascertain what that machine-specific directory is.

Thanks!

--
Kent

3 Comments   [ + ] Show Comments

Comments

  • Kentwest, I am not aware of any k2000 variables...
  • During PE boot a kace script store the MAC address in X:\windows\temp\mac.
    • Ah, this helps. Thanks!
  • I have never had any success using the K1000 Variables in the K2000 Post Task environment.
Please log in to comment

Community Chosen Answer

2
I don't believe that the K2000 has any variables like this, but if you open a command prompt while in the KBE you can see if there are variables set. As it sounds like you will be developing a script to collect data from the user I would recommend using the script's functionality to detect those variables that you need and develop a scheme that will be consistent.

Can you provide some detail on what you are collecting and intending to do with that data? 
Answered 04/12/2017 by: chucksteel
Red Belt

  • Ah, excellent idea!

    Another reader pointed out the stored location of the MAC address, but your suggestion of a Windows environmental variable is even better, as I don't have to bother with reading a text file; I can just use %MAC_ADDRESS%.

    Thanks!

    The info I'm wanting to collect is the name being given to the computer, what group to add it to in Active Directory, what software to be installed, etc. (It'd be MUCH easier if the K2000 allowed us to put the actual script (VBS, etc) in the pre/post-installation task definition itself (like it does with BAT scripts). Or if the Windows ADK 10 made it a simple checkbox to include PowerShell (if MS wants PowerShell to be the future for sysadmins, it really needs to include PS everywhere, including in the ADK), but even with that, the K2 would need to include the scripting window in the K2 itself, instead of off-loading it into a separate file that you have to keep track of separately. Coming from the *nix world where you have every tool you could possibly need, I'm finding the K2 and Windows exceptionally frustrating. How can you sysadmin a system with weak BAT files and non-existent power-script interpreters? Pfft. /End_Rant)

    At any rate, thanks! That's getting me farther down the road, and I appreciate it!
    • Check out Get/Set ComputerName for prompting for the computer name:
      http://www.itninja.com/blog/view/get-set-computername

      For scripts you can also upload them in a zip and add the post-install task as an application. You then call the command to launch the script in the parameters box, or include a batch file and call that.

      As for what software to be installed we handle that with having multiple scripted installations. Each technician copies our standard installation and then modifies it according to their needs.

      The KBE Manipulator will also make it easy to add PowerShell to the KBE: http://www.itninja.com/question/kbe-manipulator
      • I had come across the get-set-computername several times in my searching, but seemingly the only official reference that says it can prompt for a computer name is on the page you referenced, which says, "Major features include ... -dialog prompting". But that page also says that complete instructions are in the README.txt, which doesn't mention dialog prompting in the main portion of the text. Now that you tell me it's there, I looked a little harder and found it in the Appendix and later in the Version Information. I would encourage the writers of that documentation to update it to put the dialog information in the main text itself, along with the other methods for how the app can be used.

        Granted, it's my fault I didn't find that reference, but learning KACE on my own without proper training presents a HUGE learning curve, and digging in appendices for what I would have expected to be in the main text wasn't in my mindset.

        But thank you for making me aware that this app has the possibility to save me some work.

        =====

        Yes, I understand that the scripts can be created/edited elsewhere, and then rolled into a pre/post-install task. But that means I now have to remember how to do all the KACE stuff, as well as the off-board stuff - what scripting language/tool did I use last year to create this? where did I store that work? did I have to move the scripts elsewhere after packaging them? Further, if someone comes behind me to take on my role, they will have no idea of what these hidden scripts do, or where they are, or how to change them, or how to make them apply. None of this is a show-stopper, but it'd be *so* much easier to be able to edit the scripts right there within the K2000 web interface, just as I can edit BAT scripts right there in the K2000 web interface.

        =====

        We *could* do images/scripting the way you do it, copying and modifying the standard image as needed, but that doesn't fit our culture as well as having a standard image with checkboxes at the start of the install to determine what apps get installed. Much of our tech workforce consists of temps who are here at best three or four years, usually two at most, who come and go, and neither need to be bothered with the intricacies nor the responsibility of tinkering in the KACE system with our images.

        =====

        I have tried looking at the KBE Manipulator, but that's just one more thing I have to add to the basic system, and one more thing to learn in order to make this system work. I know I've looked at it several weeks ago, but I could not tell you one single thing about it at this moment, other than I don't remember anything about it except that I couldn't get it to do what I needed at the time for it to do. (I have WAY more responsibilities in my job than making KACE work the way I need it to work.) At this moment, when you suggest it as a solution to putting Powershell into the KBE, and gave me a link, I was more than willing to go see what was involved, but that link doesn't seem to indicate where I need to go next to get Powershell into a VBE, which means I'd be spending another morning doing research instead of doing my job. I'm all for research, and learning how to use the tools that will best serve my purposes, but this morning, like most, I have fires to put out that don't leave me time for fixing a problem that Microsoft should have already had in place, if they really want Powershell to be the de facto tool for sysadmins.

        =====

        I apologize if I sound like I'm whining; I'm just frustrated. I thought the KACE was supposed to make my life easier (and I think eventually it will); it's just not at a mature state where it actually does at the moment.
    • Apparently %MAC_ADDRESS% _IS_ a K2000 variable, not a Windows variable, and it only exists in the pre-installation stage, not the post-installation stage. Nor is the X:(now C:)\Windows\Temp\Mac file available post-install.

      This is the way my KACE experience has gone. I get 95% of the way to my goal, only to hit a roadblock.

      Arg.
Please log in to comment

Answers

0
Yes, I understand that the scripts can be created/edited elsewhere, and then rolled into a pre/post-install task. But that means I now have to remember how to do all the KACE stuff, as well as the off-board stuff - what scripting language/tool did I use last year to create this? where did I store that work? did I have to move the scripts elsewhere after packaging them? Further, if someone comes behind me to take on my role, they will have no idea of what these hidden scripts do, or where they are, or how to change them, or how to make them apply. None of this is a show-stopper, but it'd be *so* much easier to be able to edit the scripts right there within the K2000 web interface, just as I can edit BAT scripts right there in the K2000 web interface.
I store all of the pieces of my scripts in the zip file that I upload to the K2000, this ensures that everyone has access to them. When I need to update any of the tasks, I just download the zip from the post-install task, make the necessary changes, then upload the new zip file. While I agree more scripting options would be nice to have included, this method works very well. There isn't anything hidden about the scripts, either. Everything is stored in its own post-install task and those are all listed clearly when the image is applying or when viewing the image in the web interface.

Also, I recommend voting for on the uservoice.com site for adding PowerShell scripting as a post-install task option:

Answered 04/14/2017 by: chucksteel
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity