In the last post I showed you how you can create custom Groups of settings, making it possible to give different Users a different amount of available and changeable information. In this post, I will show you some more advanced features of the MDT Web FrontEnd as it is able to handle custom settings the same way as handling the MDT built-in settings.
MDT gives us a lot of possibilities right out of the box. But often you reach a point in your Deployment, where the built-in methods, scripts and properties aren’t enough to do the job. While creating and adding custom scripts isn’t to difficult (have a look on Tim Minters Post about writing custom scripts with mdt 2010 as a reference) handling custom settings can become difficult. But when do you need a custom setting? At least in all cases where you need to store something (other than the default information) that shall be used later during your Deployment. It might be used as a necessary value in your scripts, it might be to specify if a certain task shall run etc.
So how can we create custom settings?
The easiest way is simply defining them in the customsettings.ini. Have a look at this sample:
[Settings]
Priority=ComputerSpecificSettings,ComputerSpecificRoles, RoleSpecificPackages,Default
Properties=MyCustomSetting,MyCustomList*
As you know already, the “Priority” tells the Gather process what sections and in what order to parse. The “Properties” line tells the Gather process what custom settings/properties shall be used (Settings and Properties are identical. They are called “Settings” in the database, that’s why I use this synonym in this post). So in this example we created a “MyCustomSetting” which can take almost any single value. And using the “*” at the end we created a List “MyCustomList” that can store a couple different values (like the built-in “Applications” or “Packages” lists).
That’s actually enough to be able to use those new settings in your Task Sequence. You can assign values by something like MyCustomSetting=ABC-%SerialNumber% and use them in your scripts using something like “oProperties(“MyCustomSetting”)…”. Assigning the proper value to your custom setting using different sections is quite easy. But what happens if you have a setting that can have a multitude of different values? What if you don’t want to extend your customsettings.ini even further as it is already hard to read? The next best option is to store this setting in the MDT Deployment Database you probably have configured already. If not I highly recommend setting this up, even in simpler environments. It takes only a couple of minutes to set up but will save you a lot of time as soon as you have changes in the configuration of your Deployment. Please see Tim Minters Post about Understanding the MDT configuration database for a better introduction on why to use it and how to set it up.
Let’s start with the bad things. The MDT 2008 Deployment workbench isn’t able to handle custom settings at all (without changes to the code). MDT 2010 is able to handle custom settings but they need to exist in the database already, meaning you need to configure the setting by hand and it will just add this setting at the very end of the long list of 215+ settings. Could be more user-friendly.
Now to the good things. The MDT Web FrontEnd will help you with this. You can add(!) new custom settings using the FrontEnd and you can add those settings into any of your custom Groups (have a look in the last post about How To configure what a User can see and edit for more information) making them look like and usable as all built-in settings. And this for MDT 2008 and MDT 2010 Databases. But what is a How To without an example?
An Example
As a frequent reader of this Blog you probably have seen already a couple posts about a “Custom Boot Wizard” which will allow you to boot any known and unknown computer and let you choose from a couple of Task Sequences. But what if you want to pre-stage this information about the TaskSequence for certain computers? Exactly, we need a custom setting to store this information. To keep it simple we just want to store the CollectionID of the target collection in this setting. Saying this, how about calling it “CollectionID”? Open the Web FrontEnd and click on Settings. On the first tab that opens click on the “Add Custom Setting” Button:
Type “CollectionID” and click on “Create”
This new custom setting is now available to be used for our deployments. But we now need to give our Users the possibility to enter values. It will not(!) automatically be added to the CustomSettings section as in the Deployment Workbench. But making this available for your Users will take just a couple clicks and keep your views in a state you want to have them. We now just extend the custom Group we have created in the last post. As explained already, we need to add settings to an existing or new Category. In the last example, we created only one Category, so again to keep it simple, we will just add our “CollectionID” to this Category. This will enable all our Helpdesk Users to pre-stage this information per computer. OK, to do this, click on the Categories Tab and then on the Edit Icon of our “Helpdesk Settings”
In the list of available settings you should now be able to choose the new custom setting “CollectionID”. Give it a proper name like “Target Collection ID” and a meaningful Description. Keep the Type as “Text”. Save your changes.
If necessary, re-arrange the settings. Now if a Helpdesk User opens the Settings of an existing or new computer, he will see the following:
These are the settings of the same computer shown already. But now the Helpdesk User would be able to enter a (valid) CollectionID. OK, it would be nicer to show him a list of available ID’s but I need to keep some room for improvement ;-)
So as you can see, handling custom settings with the MDT Web FrontEnd is quite easy.
Integrate it into the Custom Boot Wizard
To finish this post, let’s see how we can integrate this “CollectionID” into the Custom Boot Wizard. Currently if a Computer PXE Boots, a script (ZTIMediaHook.wsf) will check, if there is already a valid OSD Advertisement available for the current computer. If so, it will simply handover to the Task Sequence execution engine. If not, it will show the wizard and let the User sitting in front of the computer choose a Collection to put the computer into. Now we want it to first check if there is an Advertisement available. Then it shall read the “CollectionID” setting for this computer. If it contains a value it shall try to add the computer to this collection. If successful, wait for the advertisement to come available and hand over, if not show the wizard.
OK, first thing we need is the CollectionID. How do we get this? We could use the Gather process to query the View “ComputerSettings” based on the local MAC/UUID, etc. But this might cause problems as the Task Sequence which shall run later has a different priority for the Gather process. It might even be possible that it doesn’t query this computer specific view at all. And most built-in Properties are defined in the “First value wins” way meaning as soon as a property has a value assigned, it won’t be overwritten.
Based on this, we need to be able to query a single setting. Roughly a year ago, I posted something about Set or Get a single Setting from the MDT Database. The mentioned Stored Procedure and Webservice Function is part of the Deployment Webservice so let’s make use of it. We just need to add a couple lines to your SCCM_Bootstrap.ini file to get the necessary values:
[Settings]
Priority=Default,UpdateComputer,GetCollectionID
Properties=AssignedSite,MDTID,Type,Setting,CollectionID
[Default]
SkipWizard=NO
AssignedSite=XXX
Type=C
Setting=CollectionID
…
[UpdateComputer]
WebService=http://YourWebserver/YourWebserviceDir/MDT.asmx/UpdateComputer
Parameters=SerialNumber,AssetTag,MacAddress,UUID,Description
SerialNumber=SerialNumber
AssetTag=AssetTag
MACAddress=macAddress
UUID=UUID
ComputerName=Description
MDTID=int
[GetCollectionID]
WebService=http://YourWebserver/YourWebserviceDir/MDT.asmx/GetSetting
Parameters=MDTID,Type,Setting
CollectionID=string
And a minor change in the ZTIMediaHook.wsf file is necessary as we want to skip the wizard if a CollectionID has been pre-staged. Replace
If Not HasOSDAdvertisement Then
sCmd = "MSHTA.exe """ & oUtility.ScriptDir & "\Wizard.hta"" /definition:CustomBootWizard.xml"
RunAndLog sCmd, true
If oEnvironment.Item("WizardComplete") <> "Y" Then
oLogging.CreateEntry "User has canceled the wizard. Exiting!", LogTypeInfo
Exit Function
End If
Else
oLogging.CreateEntry "Computer has already an Advertisement. Skipping Wizard.", LogTypeInfo
Exit Function
End If
with the following snippet:
If Not HasOSDAdvertisement Then
If oEnvironment.Item("CollectionID") = "" Then
sCmd = "MSHTA.exe """ & oUtility.ScriptDir & "\Wizard.hta"" /definition:CustomBootWizard.xml"
RunAndLog sCmd, true
If oEnvironment.Item("WizardComplete") <> "Y" Then
oLogging.CreateEntry "User has canceled the wizard. Exiting!", LogTypeInfo
Exit Function
End If
Else
oLogging.CreateEntry "CollectionID has been pre-staged. Skipping Wizard", LogTypeInfo
End If
Else
oLogging.CreateEntry "Computer has already an Advertisement. Skipping Wizard.", LogTypeInfo
Exit Function
End If
The example files for the Custom Boot Wizard have been updated with these changes. They just lack the bold “,UpdateComputer,GetCollectionID” part, as it requires that the webservice is working and that you added this custom setting to the database. So on default it will ignore this. To enable this, just add the bold part to the SCCM_Bootstrap.ini.
OK, great. We were able to create a custom Setting and immediately use it in our Custom Boot Wizard. If that isn’t a good start into the new week. Feel free to to contact me with your feedback and comments. Also be sure to get back to this Blog. There are more things coming.
Note: There is a small bug in the current Beta of the MDT Web FrontEnd when adding the mentioned Custom Settings. It will add the custom setting to the Database, but it will not update all Views like “ComputerSettings” (It’s actually an odd behavior of the SQL Server not updating SELECT * …” views and not really a bug in the FrontEnd but we have to deal with it ;-) ). The example showed in this post will work anyway. Find an update for the current Beta Release of the Web FrontEnd on the Download page. It’s basically an Update for an existing Stored Procedure.
The following How Tos have been published so far:
- How To restrict access to the Deployment Database
- How To configure what a User can see and edit
- How To handle Custom Settings
- How To create custom Lists to select pre-defined values for a setting
- How To handle MDT Applications in the FrontEnd
- How To handle SCCM packages