locked
Adding custom variables to bootstrap? RRS feed

  • Question

  • Hi Guys,

    Currently I'm working on a solution to create a single task sequence that can act in both zero touch and light touch modes.  Light touch modes would be for my technicians and support staff while zero touch would be for our virtual machine processes.  So far I've only toyed with customsettings.ini variables but I'm not sure if the process to create a Properties=MDTVar in customsettings works in bootstrap.  The idea is that I have one iso with a bootstrap.ini where ZTI=True and one iso with a bootstrap.ini where ZTI=False.  Then I can go through and include or exclude some custom stuff that requires touches based on which boot iso is being used.  Any ideas otherwise would be appreciated as well :)

    Ryan

    Wednesday, October 14, 2015 6:41 PM

All replies

  • What about providing all the settings needed to automate deployment for VMs in CustomSettings using priority?

    [Settings]
    Priority=ByVMType, Default

    [ByVMType]
    Subsection=VM-%IsVM%

    [VM-True]
    SkipTaskSequence=YES
    TaskSequenceID=ZTI_TS
    BDEInstallSuppress=YES

    [Default]


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Wednesday, October 14, 2015 6:51 PM
  • Yeah I had thought about doing it off of Make, Model, IsVM var, but there will still be some light touch use of the image in VMWARE which those would dictate all VM scenarios.  The idea is to create something that can run both scenarios from the same TS and if I can somehow inject something into the boot that says it's a zero touch being launched, then the app installs and interactions can be controlled by statements.  I know of some other ways to do it as well but I'm trying to do it in the confines of MDT first :)

    My next thought would be maybe include a specific marker file in the "include extra directories" setting and only include it on the ZTI boot iso.


    • Edited by MrBrooks Wednesday, October 14, 2015 7:01 PM
    Wednesday, October 14, 2015 7:00 PM
  • So when you say ZTI are you referring to SCCM integrated MDT?

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Wednesday, October 14, 2015 10:23 PM
  • No its just what I'm terming it.  I need to be able to run out an image with some technician interactions, and yet have them suppressed when run from a second boot iso pointed into the same deployment share and task sequence.   My first thought was custom variable but that's only a customsettings thing.  My second thought, but I haven't had time to try it was create an extra boot folder and then create a TS step that sets the variable I want on the condition that it sees that folder/file in X:  The idea is one TS but two scenarios controlled by which boot iso is used.  
    Thursday, October 15, 2015 1:33 AM
  • Second media shouldn't be unnecessary.  You can use the IsVM logic to configure your rules like Dan was talking about above.

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.


    • Edited by Ty Glander Thursday, October 15, 2015 7:42 PM shouldn't not should grr typo
    Thursday, October 15, 2015 5:24 PM
  • The problem with that is then all VM deployments are touchless.  There is still a need to deploy VM with interactions.
    Thursday, October 15, 2015 6:15 PM
  • In that case, why not setup a second deployment share for the VMs that need to be automated. You can still have one boot image but use Location Server to provide a drop down list of the different shares.

    That what I did to setup a deployment share just for classroom computers and an Admin share.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, October 15, 2015 6:46 PM
  • What I was getting at is you can decide how touchless your deployment is.  Using Dan's example from above where ZTI_TS is hidden (so you don't see it when you are doing non VM installs)

    [Settings]
    Priority=ByVMType, Default

    Properties=ByVMType

    [ByVMType]
    Subsection=VM-%IsVM%

    [VM-True]
    SkipTaskSequence=YES
    TaskSequenceID=ZTI_TS
    BDEInstallSuppress=YES

    Other properties set to make this quiet

    [Default]

    SkipTaskSequence=NO

    BDEInstallSuppress=NO

    Other properties set to make this noisy


    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Thursday, October 15, 2015 7:49 PM
  • Yeah unfortunately this isn't a traditional touchless scenario, the noisy pieces are internal applications that request information.  I have them configured as application installs.  The idea I had was to somehow inject a custom variable into the process and create a condition on the applications based on if it sees the custom variable or not.  

    My goals are to have it run from 1 task sequence and yet support those 3 possible deployments, 1 with full ZTI config to VM, 1 with LTI config to VM, 1 with LTI config to Physical.  I figured the easiest way to segregate it was to give the VMWARE guy a customized boot and then have his boot set that variable.  Also it needs to be one TS one DS to keep the process as simple as possible.

    Either way I'm working in my lab now to try adding a folder to the boot iso and using this - https://technet.microsoft.com/en-us/library/bb680637.aspx as the condition to set the custom variable.  I don't see any reason why it wouldn't work but I've never tried it before.  Thanks for the comments guys I'll write something back if it works.

    Friday, October 16, 2015 12:21 AM
  • Everything you want to do is available.  I think the approach is backwards though.  Trying to make 1 TS do everything is a formula for unneeded complexity.  It would be easier to just select different TSs based on your parameters.

    Logs are very important. If you are unsure how to post logs or where to find them then reference https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Also if you have made customizations please mention them when asking for help.

    Friday, October 16, 2015 5:21 PM
  • So I tested it out today and it worked fine.  I know this seems backwards and normally I would say go with multiple TS, but it was requested to be as simple as possible with as few task sequences and as few steps to update and refresh the infrastructure.  With this process I was able to move to one task sequence for now 4 different unique deployments - ZTI, VMLTI, LTI, and Vanilla(exclude application bundle).  All I did was add the option to create a TS variable based on which file it sees in X:\ and added the extra directory under the boot media.  There are way more touches and room for errors in updating multiple task sequences.
    Saturday, October 17, 2015 2:38 AM
  • I am curious though - how else would you create a scenario where you have vmware thats zti and vmware that's lti on the same media? I should note we're doing this only from MDT.  If I were to create a rule on something like %IsVM% that rule would be for all of them.  I tried to think of other things to gather them by than machine type but couldn't come up with much.  What you posted above feels like it would funnel all virtual machines through the same ZTI_TS, when we still need that media to support traditional deployments in test labs and scenarios.

    I could have a selectable menu to another DS but again that's adding complexity for support to handle.  It needs to be super simple low touch to update.

    Saturday, October 17, 2015 2:46 AM
  • Having two deployment shares doesn't need to be complex because you can copy and paste between the two. It makes it easy to duplicate what you need to. My classroom deployment share is 100% automated. I'm basically doing what you want to do but to physical machines instead of VMs.

    I get that you're worried about introducing human error with multiple TS, but that's all the more reason for good documentation and not making changes without documenting it or if multiple people manage MDT, then consult with the other before making changes.

    If you're going to have just one TS to do it all, then make a copy of it and hide it so that if the main one is messed up you can quickly hide the broken TS and unhide the backup


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Monday, October 19, 2015 1:48 PM
  • Yeah for me, the difference between the two TS would have been so minor that having two DS for this would have been a pain for the support team.  The only difference between the ZTI and LTI was that I needed to suppress our internal prompting for domain and user config.  One step in my production TS that affects the VDI machine creation process. 

    Also we're already copying back and forth between 7 deployment shares (+ unique deployment shares for Dell factory process) :) We have 2 unique image scenarios and still provide some backwards support for 32-bit.  2 process for Win7x86, x64, Win8x64, and now bringing Win10x64. Adding a TS/DS for each process to execute touchless would be a lot of stuff for support to manage and alot of room for error.  I should have been more clear about this in the beginning. 

    I think when we get SCCM setup Q1 2016 we can look at automating TS switching based on boot environment or something.

    Monday, October 19, 2015 5:49 PM