So I previously asked about .EXE support for the INJECT SCRIPTS part of provisioning...
...I'm now unable to get .REG (registry entry) files to work. Just like with .EXE, I am able to add the file to the list of scripts, however the file that provisioning injects doesn't work.
My current task is pretty simple:
I have a very minimal .REG file that I have added to the list of available provisioning scripts. I want to inject that .REG file using provisioning and then use the REPLACE TEXT action to update the .REG file with some local variables. Then I want to add the .REG entries to the system's registry. Upon injecting the .REG file using provisioning I notice that some funny characters get added to the header of the file. I think this extra junk is messing up my task. It seems to me that LDMS is altering my .REG file at the time it gets added to the database of available provisioning scripts.
Previously I have added .XML, .BAT, and .TXT files and used the INJECT SCRIPT successfully with those file types. I don't see how .REG is any different yet I am clearly getting some extra garbage added to whatever I inject with provisioning.
Does anyone know of a list published by LANDESK of what file types are supported with PROVISIONING SCRIPTS?
-anyone have any other personal experience they would like to share on this topic?
From what I have read, it looks like the inject script is more for scripts needed for imaging like .inf, .xml, .txt files for example. What are you trying to accomplish with the .exe file or .reg file?
You should just be able to use the execute file action or copy file action and then execute file
First off, let me say that I am trying my best to accomplish most of my management tasks using provisioning. I'm new to LDMS as of last year and although I am aware of most of the general aspects of this product, such as OSD/Provisioning/SWD/PatchCompliance/etc, it is my feeling that provisioning is the easist and most straightforward tool for me to use. Because of this reason I am building provisioning tasks to take care of 90% of the management tasks I have to perform.
Okay, so there are a number of things that I like about provisioning, but one of the things that I really don't like is that almost is nothing is done for you; as an author of provisioning tasks, if you want to do something then you have be explicit about every single stinkin' step or else your task is going to fail. The one part of provisioning that helps simplify this are the provisioning scripts.
I make use of all sorts of 'helper' files in my provisioning tasks. Most noteably are the three that are part of my windows 7 deployment tasks: FixUnattend.bat, FixWindows.bat, Unattend.xml. These files are very much necessary but once they are working then I should not have to make any changes to them and I certainly don't want to lose them. Without making use of PROVISIONING SCRIPTS, if I want to use these three files in a provisioning task I must place them somewhere on the network and then explicitly map to this location and copy each one of them down to my target computers. This is a little extra work, sure, but I'm more concerned about what might happen to these files if the get changed/deleted/moved/etc from that network location...
Installing Provisioning scripts into the mystery location LDMS console puts them is a really great way for me to store these three files. I can get them working, install them as scripts, then it is very easy for me to include them in a provisioning task because I simply choose INJECT SCRIPT and select the one I want from a list. Moreover, those scripts are protected in the LDMS console to a degree that I really don't have to give them any thought-once they are put into the console they remain there for use going into the future. If I want to make changes to one of these files I can do so and reinstall them as an updated version. At that point I can begin including the new versions in subsequent tasks but I know that the old versions still work and remain available for use.
in summary, provisioning scripts are a really handy solution for storing and using helper files for some of the more complicated provisioning tasks.
Expanding upon the previous example, I'm wanting to add other helper FILES to the list of provisioning scripts because once I get them working I want them to be in the console list of available scripts and I want to forget about them. I've got a number of .REG files that I want to add to this list as well as a host of other .ini files and a few .EXE files I built using AutoIT.
Sure I can put the files that don't work onto a share and try to leave them alone, but then I always have to explicitly include a drive mapping in my tasks if I want to use them. But right now I don't have a list to know what file types are SUPPORTED by this feature of LDMS so I can't really start shuffling the helper files around without wasting a bunch of time testing to see which ones work and which don't.
I dont think Inject Script was made for that use. Sure you may be able to add different types of files but like you have seen, they don't all work. I still think your best bet is to use execute file action and you don't necessarily need to map a drive if the share is somewhat open. You could even put the files in the ldlogon directory on the core since that share is pretty open. You can also just create a template that includes all your "helper" file and add that to other templates, chaining them together that way you only have to update the "helper" files template if needed.
Thanks for the input but landesk provisioning can't use FILE EXECUTE against something on a network share without having first mapped to that share with valid credentials. Provisioning uses the local system account which doesn't have permission beyond the local computer, so that account isn't going very far in terms of retreiving remotely stored helper files. Also, using landesk shares as a place to store files is bad idea in the sense that it is difficult to keep track of all the added files. On the latter point, recently I had to rebuild my server and I ended up losing a number of helper files which were stored in a similar manner...all of my provisioning scripts were saved, however.
Moreover, FILE EXECUTE doesn't really work for the bulk of my helper files as they are not all .exe files. The majority of these are files which have to be placed onto the computer and modified somehow before being used in a secondary process. They must be put onto the machine and the provisioning scripts feature is the most logical way to get them there.
I've thought about building 'helper' provisioning INCLUDES, but doing so doesn't really address any of the problems I initially pointed out and doesn't come close to replicating the benefits realized by using the provisioning scripts.
So I'm back to my question:
What file types will INJECT SCRIPT allow?
Have you verified that using "execute file" action needs to have a mapped drive? From the choices given, it doesn't seem like you do.
Also, putting your question in bold or larger font multiple times isn't going to make the answer easier for you to get. Think about where you are given this "install scripts" choice, Operating system deployment. This most likely means that it is intended for sysprep files or answer files for OSD. You are trying to use a LANDesk function for somthing it was not intended for. No, I don't have a list of file types so I can't help with the list but its pretty obvious that you may be going about this the wrong way.
Here is a section from the Help which still doesn't answer your question but it's a start. You may have read this already though.
"Use Install scripts to create a template out of one or more scripts. Install scripts makes installation scripts available for use in creating scripted installation actions in templates. Provisioning supports batch file scripts, shell scripts, and many other scripts. The Deploy image, Scripted install, and Inject script actions use scripts like sysprep.inf or unattend.txt. Install scripts can also insert variables into your scripts; for example, a device name can be inserted into a sysprep.inf file."
You can also create a Distribution package for your helper files and then use a Distribute software action. That might actually work out better, just depends on how you want to go about it.
I'm only rentering my original question in a larger font for those who skim this thread to let them know that my question remains unanswered. Its not a poke at you.
Thanks again for your help,
however the file execute provisioning action won't really apply here because, like I said, file execute won't work for a non-exe helper file, of which I have many.
Additionally, you reference Operating System Deployment and OSD in one of your replies. The Operating System Deployment 'tab' of this product does contain OSD scripts (old school) and Provisioning (new school), and yes it is under the Provisioning side of this tab where I find provisioning scripts. I was told by my landesk-employed trainer that Provisioning IS NOT to be confused with what has traditionally been referred to as OSD. Going further, I'm told by this same individual that provisioning is supposed to be an end-to-end aparatus for performing all of the tasks a person needs to in order to setup a system for use in a production capacity. What I take away from this statement is that I'm not limited to using Provisioning for simply deploying an operating system, rather I can deploy an O/S with it and configure that O/S using the same aparatus.
...the things that I am trying to accomplish with provisioning scripts are very much oriented towards configuring the O/S that I've just laid down earlier in the same task. So, it may be obvious to you that I'm going about this the wrong way, but it seems to me that I'm using the tool as my instructor suggested. My one real problem here is that provisioning scripts were mentioned but more or less glossed over in my class and I can't find any documentation about what file types it supports.
The idea of using a distribution package does have some merit as it integrates with provisioning, however it is a lot of work to setup and use a distribution package for a simple helper file. I think that I'd rather stick with mapped drives and file copy actions to accomplish this rather than SWD...still I'll have a look.
again, thanks for your suggested work arounds.
It's all good . Provisioning is supposed to be the one stop shop when it comes to setting up a machine but I still think it has its limits. Yeah there is a lot that can be done, don't get me wrong. I also think that the documentation is not all there.
I would give the copy and execute method a try and see how that works out for you unless someone has another method besides those I alreay pointed out. Good luck.
I like the creative thinking you are putting into figuring out different ways to use the Provisioning actions.
If you look within the LANDesk database, you may be able to figure out the answer to your question.
The contents of all scripts that are injected into LANDesk are stored in the PROV_BLOB_DEF table's BLOB_DATA column. The BLOB_DATA column is of data type 'image', which means the data is stored as 'variable-length binary data from 0 through 2^31-1 (2,147,483,647) bytes.'
Most scripts that you inject will be plain txt (ini, inf, xml, bat, vbs, etc.), and yet will be stored as binary data within this database table.
I don't KNOW this, but it would be logical to assume that there is some sort of conversion process that takes place, to enable the plain txt data to be stored as binary data within the database. What happens when this conversion process takes the binary data from an executable and converts it to binary again for storage in the database?
This is by no means an official answer, but my personal suggestion would be to stick to plain text files for injection into the database. Any file format that is already in a binary format should be accessed by using the 'Copy File', 'Download File', 'Execute File' or 'Unzip File' actions.
I personally maintain a specific path into which I place all LANDesk "utility" files that I plan on downloading. This allows for a single location that should be backed up, or ported to another server, etc. If you are concerned that a plain text file might be casually or accidently (or maliciously!) modified, you can always add it to a zip archive. Provisioning can Unzip those files as needed, and the zip archive will keep the files from being casually or accidently modified. You could also use a utility like 7zip, and archive the files with a password to prevent malicious modification. You could then use a combination of 'Download File' (or 'Copy File') and 'Execute File' to extract the files during the provisioning process using a command line that passes along the correct password. Even better, that password can be setup as a 'Sensitive Data' variable, and your provisioning template can use that variable instead of exposing your password as plain text within it.
I merely throw out those suggestions as possible ways to accomplish what you are trying to accomplish without butting your head against the "binary wall" associated with the 'Inject Script' action. I'm not going to tell you how you "should" or "should not" use an action, but there are programattic constraints in place that will limit what you can do.
Best of luck with your provisioning tasks!
I'm following you on the binary vs text concept as a potential limiting factor in this context; though my trials leave me to doubt that this is the only thing in play.
The last few days I was testing .REG files, which I believe to be as much of a text file as .bat .ini. vbs, etc. Upon using INJECT SCRIPT to place these .REG files on a target PC I've noticed that junk characters were being added to the file and I was suspecting this was the cause of the provisioning failures I saw associated with trying to merge those files with my target registry.
This experience led me to believe that supported file types were not simply all files containing text only; hence I wanted to reach out here and see what others' experiences yielded or if there was a list of supported types available.
Well... it turns out that .reg files are NOT plain text! Well... sort of.
So, I did a test... I exported a .reg file, and imported it as a script into LANDesk. I then exported the injected script, and when I opened it up, there were ASCII characters in front of the first line of the original contents of the .reg file.
I then opened up the original .reg file and selected all text, copied it, and pasted it into a new notepad window, then saved it as a new .reg file. I repeated the inject/export steps, and this time the exported file was exactly what it should have been, with no ASCII characters. This new .reg file was imported successfully into the registry, as well, so there was nothing lost in the translation.
My suggestion would be to walk through this procedure for the .reg file you are wanting to setup as a script within LANDesk. Apparently an exported .reg file contains some header information that is not visible in notepad, and when LANDesk imports the .reg files, that header information is translated into ASCII characters that get inserted into the injected script.