You can use variables. I am curious though, are you using a variable for the image name? If I do that I get the same error you are seeing. My question would be, how are you using variables that it is beneficial to leverage a varialbe for the image name?
\\%coreserver%\%myfolder%\test.tbi works fine where %myfolder% is a template variable.
Thanks for the confirmation, Eric.
The way I am using variables here is as follows:
all of my templates which involve imaging contain TEMPLATE VARIABLES; one of these variables is always the image name. For example:
I have a PUBLIC VARIABLE for the location of the image share: %ImageShare% and then within any given template I have a TEMPLATE VARIABLE for the actual image file: %imagefile%.
This might look like %ImageShare%\%imagefile% and shake out as: \\technology\images\HPlaptop\currentimage.tbi
I find it to be a good practice to use variables as much as possible, and in this case it is quick and easy for me to change the source image for a task by changing a single variable within the template variables section of the provisioning template. Most of my image files have multiple partitions and so they get referenced at least twice in a given template; I'm also using the image file name as part of computer branding later in the provisioning process.
Rather than open revisions up to errors by having to make multiple changes I only change the variable once. I also don't like how many times I have to click the mouse in the LDMS console and it is fewer clicks to get to the variable than it is to mine down to the specific references within the action items of the template.
Does this clarify my useage for you?
Do you agree that this is a bug in so far as the reference to the source image file?
That is what I assumed, but I wanted to clarify. Limitation/Bug...maybe.
1 of 1 people found this helpful
I have no problem with provisioning template in 9.5 and I am using like you a variable for the image name (the only difference is that I am using a .WIM extension). Check log file deployimagehandler.log (or something like this) on X:\ldprovision folder, here you find command line run during provisioning.
One of my issue was double extension on command line (i.e. imagex.exe /.... imagefile.wim.wim), I solve removing extension from value on variable (i.e. imagefile instead of imagefile.wim).
So this morning I rebuilt the provisioning task and attempted the variables again. What I've discovered is that the new 9.5 dialog box for the DEPLOY IMAGE action expects to see the image file extension listed explicitly rather than included in a variable.
I took the reference to "imagefile.wim.wim" above and took that to mean that I should pull the extension from the variable and put it in the dialog box. Having done so I was able to get the dialog box to take the variable without getting upset.
My issue now is that the deploy image action item isn't working in a provisioning task despite the fact that it tests out okay when manually executed on the client in the same WinPE space...but this is for another post.
@ Eric, so this behavior in the 9.5 product which has now been exposed is a departure from that in 9.0. Call it a bug or a limitation, but please make sure someone takes note. Its little stuff like this that so consistently causes this user to waste time with this product.
Did you configure a PPS with the path to the image source? If not, configure it and rerun the Provisioning
No I did not; I never really had a need for one and I still don't see why this is something that I need.
I have a NAS setup which houses all of the images/packages/etc that my clients need and they all have access to the various shares. In all of my provisioning tasks I point to the shares using UNC and that has been enough.
I have no need to content replication nor any wish to get into restricting access to certain IP ranges. It seems to me, still, that I have to configure this stuff if I wish to designate a preferred server-since I don't need it then I don't want to bother with it.
In your provisioning task For map to imaging tool and map to image file did you choose under Map/Unmap a drive, Connect a resource?
Thats what we use and we don't use preferred servers.
YES, we are connecting to resource...now anyway.
We were mapping drive letters under 9.0 and that worked fine. Under 9.5 the first thing that failed with provisioning were the drive mappings with letters; these bombed out immediately. I tested the CONNECT RESOURCE and it worked and so I'm using it right now as I try to get the rest of our provisioning templates to work. I don't really need drive letters so I don't mind the switch but it is still too bad that we're having to change several parts of what were functional templates now that we've moved over to 9.5.
We had to go over every template and change it after moving to 9.5