MDT Tutorial Part 5: Bootstrap.ini

Living Table of Contents

 

Today’s Agenda:

  • Bootstrap.ini Overview
  • Facilitating Authentication
  • Skipping the Welcome Screen
  • Putting it All Together

Recommended Reading

Bootstrap.ini Overview

The BootStrap.ini is similar to the CustomSettings.ini in that the format, structure and processing logic is the same.  The major difference is mainly that the Bootstrap.ini is processed first and once when you boot into WinPE.  The CustomSettings.ini on the other hand is processed after the Welcome screen and at various points during the Task Sequence.

Just like the CustomSettings.ini, the Bootstrap.ini is accessible two ways:

  1. Via the ‘Edit Bootstrap.ini’ button on the ‘Rules’ tab of the Deployment Share properties.
  2. Via the Bootstrap.ini in the Control subdirectory of your Deployment Share, for example:
    1. C:\DeploymentShare\Control
    2. \\MDTServer\DeploymentShare$\Control

Currently your Bootstrap.ini is more bare bones than your CustomSettings.ini:


[Settings]
Priority=Default

[Default]
DeployRoot=\\ITF1MDT01\DeploymentShare$

Unlike the CustomSettings.ini however, when you make changes to your Bootstrap.ini, the changes are not ‘live’ immediately:  Because the Bootstrap.ini is baked into your boot media – hence its ability to be processed when WinPE loads – anytime you update your Bootstrap.ini you must update your Deployment Share to generate new media that contains your updated Bootstrap.ini.  Because of this, you probably want to keep edits to this file to a minimum, adding just the essentials to get you connected to the Deployment Share.

According to the documentation, there are only a handful of properties configured by Bootstrap.ini; so few I’ll include them here for reference:

_SMSTSOrgName Database DBID
DBPwd DeployRoot DestinationDisk
DestinationLogicalDrive DestinationPartition Instance
KeyboardLocale KeyboardLocalePE Location
NetLib Order Parameters
ParameterCondition Port Priority
Properties ResourceRoot Role
SkipBDDWelcome SQLServer SQLShare
StoredProcedure Table UserDomain
UserID UserPassword

However that same document doesn’t state you can use the ‘DefaultGateway’ in the Bootstrap.ini which is a completely valid configuration, so I’ll assume the documentation is dated or it was an oversight.

It’s also been said that you can customize the Bootstrap.ini to nearly the same degree as the CustomSettings.ini.  I personally have not done this so I can’t validate that (e.g.: will User Exit scripts work etc.) but since the documentation is clearly not complete, I also refute it either.  So yes, you can create new sections and custom properties but I will say this: Because edits to the Bootstrap.ini require rebuilding the media each time a change is made, I personally prefer to to keep it simple with the most static information possible.

Facilitating Authentication

The first thing I typically do is rid myself of that dreadful authentication prompt that appears after clicking the ‘Run the Deployment Wizard…’ button:

SBTS-002

And I accomplish that by adding the UserID, UserPassword and UserDomain properties to the Bootstrap.ini:


[Settings]
Priority=Default

[Default]
DeployRoot=\\ITF1MDT01\DeploymentShare$
UserID=Administrator
UserPassword=my sekret 1337 Cyph3r!
UserDomain=ITF1MDT01

The documentation states:

For a completely automated LTI deployment, provide this property in both CustomSettings.ini and BootStrap.ini.  However, note that storing the user credentials in these files stores the credentials in clear text and therefore is not secure.

This is an important thing to remember when setting this up and a documented risk for the security team.  Leading practice would be to use a dedicated MDT account with limited rights (like execute) to the Deployment Share and write access to the ‘Captures’ directory.  I would advise against using a privileged account, be it local to the ‘MDT Server’ or the a domain account.

Skipping the Welcome Screen

If you’re not a big fan of this screen:

SBTS-001

You can suppress it by adding the SkipBDDWelcome property and setting it to YES to the Bootstrap.ini.


[Settings]
Priority=Default

[Default]
DeployRoot=\\ITF1MDT01\DeploymentShare$
UserID=Administrator
UserPassword=my sekret 1337 Cyph3r!
UserDomain=ITF1MDT01
SkipBDDWelcome=YES

To undo, set it to NO or comment the code by placing a semicolon in front of it like ;SkipBDDWelcome=YES.

The documentation states:

For this property to function properly, it must be configured in both CustomSettings.ini and BootStrap.ini. BootStrap.ini is processed before a deployment share (which contains CustomSettings.ini) has been selected.

I’ll tell you that I don’t always add it to my CustomSetting.ini and yet the Welcome screen is been suppressed for every build and build & capture with that configuration.  Again, this could be a change in MDT behavior that wasn’t reflected in the documentation but I always recommend following the documentation.

Putting It All Together

Ok so now you’ve got the hang of it, let’s make some changes common to many environments.  Comments added to emphasize certain elements.


[Settings]
Priority=Init,DefaultGateway,BootStrapSection,Default
Properties=Office,MyBootStrapProperty

[Init]
DeployRoot=\\DFS\Namespace\DeploymentShare$
;SkipBDDWelcome=YES

[DefaultGateway]
; Put your real gateway for HQ
10.0.1.1=HQ
10.10.1.1=DC

[HQ]
; HQ is your current environment so put real information here
Office=HQ
; Point this to the real Deployment Share you setup
DeployRoot=\\ITF1MDT01\DeploymentShare$
; Use real credentials to connect to the above share
UserID=svc_ImagingAccount
UserPassword=Tr0ub4dor&3
UserDomain=ITF1MDT01

[DC]
; This is a fake location for illustration purposes
; But you could be in an environment with multiple Deployment Shares
Office=DC
DeployRoot=\\DCServer\DeploymentShare$
UserID=lclMDTUser
UserPassword=Correct Horse Battery St4pl3!
UserDomain=DCServer
SkipBDDWelcome=NO

[BootStrapSection]
MyBootStrapProperty=THIS IS MY BOOTSTRAP PROPERTY
_SMSTSOrgName=MDT Lab@%Office%

[Default]
SkipBDDWelcome=YES
; This is fake information because I set the real information above
; Again purely for illustration purposes
UserID=MDTAccount
UserPassword=my sekret 1337 Cyph3r!
UserDomain=DOMAIN.FQDN

And here’s how it’s going to be processed:

  1. [Init] Section – This is the ‘Init’ section where I can set some default settings.  This isn’t required and you may or may not need something like this; just know that you can do something like this.
    1. DeployRoot is set to \\DFS\Namespace\DeploymentShare$
      This would be a catch-all default for offices that don’t have a separate Deployment Share.  In this scenario, if someone’s gateway was 10.20.20.1 they would default to this Deployment Share because there’s no rule below for that particular gateway.
      .
    2. SkipBDDWelcome was initially set to YES at some point but commented out because technicians in some offices wanted to use the other options on the Welcome screen.
      SkipBDDWelcome, like most MDT properties, is a write-once property so if we set it to ‘YES’ in [Init] we can’t alter it later.  Better to leave it alone to allow offices to customize it to their liking.
      .
  2. [DefaultGateway] Section
    1. 10.0.1.1 – If the default gateway matches this, it will go to the [HQ] section
      1. [HQ] Section
        1. We set a new property called Office to HQ.
          This could be useful for a variety of things like naming computers based on location
        2. The DeployRoot is set to \\ITF1MDT01\DeploymentShare$.
          DeployRoot is one of 9 properties that are re-writable out of the box so I can set this as many times as I need to.
        3. UserID is the username we’re going to use to connect to the above Deployment Share, in DeployRoot.  We have to do this because they’re smart and not using common username & password like other offices.
        4. UserPassword is the password for the above user
        5. UserDomain is the domain we’re authenticating against, in this case the DCServer.
        6. SkipBDDWelcome is set to NO because this office prefers to see the screen.
          .adsasdasd..
    2. 10.10.1.1 – If the default gateway matches this, it will go to the [DC] section.
      1. [DC] Section
        1. We set a new property called Office to DC.
        2. The DeployRoot is updated to point to a local Deployment Share in that office.
        3. UserID is the username we’re going to use to connect to the above Deployment Share, in DeployRoot.  We have to do this because they’re smart and not using common username & password like other offices.
        4. UserPassword is the password for the above user
        5. UserDomain is the domain we’re authenticating against, in this case the DCServer.
        6. SkipBDDWelcome is set to NO because this office prefers to see the screen.
          .
  3. [BootStrapSection] Section – An arbitrary section I created just because I can
    1. A new property called MyBootStrapProperty is set to ‘THIS IS MY BOOTSTRAP PROPERTY” – again purely to show that it can be done.
    2. The _SMSTSOrgName property is set and it references the Office code set further up.
      .
  4. ​​[Default] Section
    1. SkipBDDWelcome is set to YES because most offices don’t want to see it.
      If it’s not already set, it will get set to YES.
    2. UserID is the username we’re going to use to authenticate to the default Deployment Share, held in property DeployRoot, that we set in the [Init] section.
    3. UserPassword is the password for the above username
    4. UserDomain is the domain we’re authenticating against.

The proof is in the pudding:

  • After making the changes to the Bootstrap.ini, update your Deployment Share to create new media
  • Boot your new media
  • You will no longer see the Welcome screen
  • You will no longer receive an authentication prompt
  • You will be taken directly to the Task Sequence page
  • If you run a Task Sequence (build or build & capture) you’ll see the updated text in the progress bar area:
    • Bootstrap-002

I recommend opening the BDD.log file to review the processing, but this is something we haven’t touched on yet so brace yourself.

While in WinPE – say when you’re looking at the Task Sequence list – press F8 on your keyboard to open a command prompt which is unequivocally indispensable when it comes to troubleshooting!  Please note that on some laptops you may need to press the Function (Fn) key and F8 simultaneously to get this to work.  This isn’t an MDT problem but a hardware specific issue.

Bootstrap-003

In the command window just type notepad hit return and notepad will open.  From there you can go to File > Open & browse to find the BDD.log, which is in one of two locations depending on the state of the hard drive of the machine you’re testing:

  • Drive has NOT been partitioned:
    The BDD.log – and others – can be found in X:\MININT\SMSOSD\OSDLOGS
    .
  • Drive HAS been partitioned:
    The BDD.log – and others can be found in C:\MININT\SMSOSD\OSDLOGS

This slideshow requires JavaScript.

Once you navigate to that location, you won’t see anything because of the default ‘Files of type’ filter in notepad.  Change the drop down from ‘Text documents (*.txt)’ to ‘All Files’ and like magic a bunch of files will appear.  Now open the BDD.log

MDT generated logs are a little difficult to navigate in notepad but this is the kind of thing that really builds character.  In the log, search (CTRL+F) for one of the properties you set, like _SMSTSOrg or ‘MDT Lab@’ and you should find what you’re looking for it pretty quickly.

Below is my marked up version of the BDD.log highlighting the custom properties, the order of operations (Rule Priority) as well as the sections it processed; between each you’ll find log entries for the actions performed, like setting Properties (aka variables) like UserID, MyBootstrapProperty etc.

Bootstrap-001

As you can see, everything was processed accordingly and set correctly.

In Closing

This Bootstrap.ini example is a little complex only because it accounts for possible real world scenarios: Office specific configuration, Multiple Deployment Shares (aka DeployRoot), Different Credentials for each Deployment Share, customizing the progress bar with your branding/corporate information and so on.

For your lab environment, you really just need a bare bones config like this:


[Settings]
Priority=Default

[Default]
; Customize this to your liking
_SMSTSOrgName=My Custom MDT Lab
; Point this to the real Deployment Share you setup
DeployRoot=\\ITF1MDT01\DeploymentShare$
; Use real credentials to connect to the above share
UserID=svc_ImagingAccount
UserPassword=Tr0ub4dor&3
UserDomain=ITF1MDT01
; You might want to skip this but maybe not - your call
SkipBDDWelcome=YES

But at least you know how to handle those scenarios and scale up.

Good Providence to you!

Advertisements

17 comments

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s