/build/static/layout/Breadcrumb_cap_w.png

K2000 "Breadcrumbs" From a Pre-Install Task to a Post-Install Task

I am working up some really cool scripting for custom post install tasks.  So that I can choose what tasks I want to run for each job without logging into the K2000 and dragging the tasks off/on each and every time.

The only minor issue is currently my GUI used to pick the tasks to run is running as a Post Install task, it saves the breadcrumbs as registry values to the new image, then later when each install job gets run by the K2000 its checking if those registry values exist and running/not running based on the value.

The reason that is an issue is simply I cant pick my options as soon as I kick off the deployment, I have to babysit the image until the first post-install task runs that launches my GUI.

If I try to run it as a pre-install task, its running in the PBE thus the changes are not made to the new system.

I wondered however if maybe I can use the PBE as a go between, I think the PBE has the Y: as its disk or is it X: ?
If I re-do my GUI to say save a .INI file to the root of the PBE would that file still exist when I get to my post install tasks?

I just sort of need to verify the environment a bit so I know where to write the files, and if they are still present when coming back to the post install tasks.

There is usually a reboot somewhere in there, and I imagine that will cause loss of anything stored in the PBE, but maybe if my first Post-Install task is to read my PBE placeholder and then write that to the Registry of the new machine I can complete the chain of events.

Edit: Created myself a task to launch a cmd window at each phase of the install (Pre, Mid, Post) I can see X: is the PBE and Y: is the K2000
Looks like the K2000 can not be written to, access denied.

So I put a file in the X: home directory and will see if it is persistent, if not anybody have any ideas?

Edit2: Deployment I can see a T: and a C: - Looks like I can most likely save the file to the C: but not sure it may get over-written by the image there is no registry yet since windows is not installed and initialized, but there is access to the drive.

Now I wonder where this mysterious T: goes? 

1 Comment   [ + ] Show comment
  • Interesting work, I hope you will share it when complete. - chucksteel 7 years ago

Answers (2)

Answer Summary:
Posted by: ViciousXUSMC 7 years ago
Senior Yellow Belt
1
Ok guys, answered my own question.
Looks like the solution is the T:
Its a temporary directory from the K2000 mostly for logs, it will work perfect for what I need I just need to figure out how to implement it.

T: points to K2000\PeTemp and you can reach it via Samba Share to clean it out (Hidden Folder)

I'll just save my .INI file there with the name being the machines mac address so that multiple computers will not try to use the same file if running more than one image at a time.

Comments:
  • Newer laptops don't have ethernet ports anymore. So using usb dongles; would duplicate mac's be a problem in your scenario? - five. 7 years ago
    • No, you can pull the mac from another adapter like the wireless card or bluetooth. Even if you use the MAC of the adapter it would be persistent to that machine and only one machine would use the adapter at a given time so it will still remain unique and identifying. - ViciousXUSMC 7 years ago
      • Very cool. Thanks for taking the time to reply. - five. 7 years ago
      • No problem @five. and if you are curious. This is what I ended up doing with this little project.

        http://www.itninja.com/blog/view/k2000-kustom-post-installation-tasks

        In the end I found a way to use the C: and not need the share. But its a good plan B. - ViciousXUSMC 7 years ago
Posted by: Desktop Jockey 7 years ago
Second Degree Green Belt
1

Top Answer

Using The T drive is a sticky situation as it is different for every RSA and does not reattach after reboot. An easier way is to use the X drive.
I have built an HTA that has all of our Software installers (On K1000), computer name,and Domain / OU choices. This dumps to a text file on the X drive (Ramdisk). Then as a mid task, Transfer the file or its contents to the C: drive. This way everything stays local.

Something like this:
Your Pretask dumps the file to "X:\Software.txt"
Then Midtask: copy "X:\Software.txt" "C:\Temp\" /Y


Comments:
  • Hmm I did not think of X: because its RAM and lost in reboot, but I going from RAM to disk in the mid task is smart because the reboot has not happened and all the imaging steps can be completed to ensure the disk is not overwritten.

    I had no issues using the T: however, my script included a net use command to get access without persistence and it worked well for me.

    If/When I redo that I think I will for sure use your method.

    Currently I send the file to disk as my last pre-install task and that works based on the image deployment method I am using.

    BTW as a side note, what did you mean your HTA has your K1000 installers, are you using a smart label or something and having the K1000 do the legwork? Or is there some magic way to push K1000 jobs via K2000? - ViciousXUSMC 7 years ago
    • So here is normally the problem with the T drive... If you have machines like.. Precision 5510 or 20, they come with a USB C ethernet dongle that has its own MAC. Once the reboot occurs, the MAC changes to the internal NIC MAC address...
      Also, The T Drive is specific to the RSA you are working from. So people with multiple locations will have a fun time scripting that.

      I am guessing you are using Scripted installations instead of images... is that correct?

      One of these days I will publish a full how-to on my site. - Desktop Jockey 7 years ago
      • No we use images. I would love to see your how to. I just put mine up today. If you take a look you can see the deployment and how I can safely send the file directly to the C: after I create my partitions.

        http://www.itninja.com/blog/view/k2000-kustom-post-installation-tasks - ViciousXUSMC 7 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