Maik Koster at myITforum.com

MDT Wizard Studio beta released

maikkoster — Sun, 13 Jan 2013 16:34:00 GMT

The MDT Wizard Editor is probably one of the most useful tool if it comes to editing the Lite Touch Wizard files. It especially simplifies the pretty tedious part of editing the xml files and the embedded HTML content of each wizard pane.

However the current version of it dates back to October 2009 and with this didn’t support any of the changes, that came with MDT 2012 and MDT 2012 Update 1. One of the major changes between 2010 and 2012 has been, that in contrast to MDT 2010, all wizard panes are now stored in individual files and only referenced in the wizard definition file. While it eases the handling and testing of individual wizard panes, it also made it necessary to always tweak the wizard definition file by hand.

To ease this job, I’ve started updating the freely available source of the MDT Wizard Editor to work with MDT 2012/MDT 2012 Update1. And also added some features, that I was always missing while using the original MDT Wizard Editor.

Due to some administrative reasons, we have decided to publish this as a separate, community driven project.

So I’m proud to announce the first public release of the new MDT Wizard Studio.

Features and Enhancements

The following features and enhancements are available in the current beta release:

- Full support for MDT 2012 / MDT 2012 Update 1

- Open MDT Wizard definition files

- Create a new MDT Wizard definition file

- Add a new pane to an existing definition file (still supports Copy&Paste)

- Import an existing pane

- Reorder panes by Drag&Drop

- Rename pane and referenced file

- Change title of pane

- Convert old (MDT 2010 and older) wizard definition file into new MDT 2012 format

- simple Syntax highlighting of VBScript and HTML code elements

- Edit referenced scripts directly in the wizard

- Option to hide the navigation bar

- Resize the Wizard

- Highlight updated variables during test of wizard

- copies all referenced files (scripts, images, etc.) on import and testing

some screenshots:

As mentioned, it’s currently a Beta version, so be careful when editing your production wizard definitions. So far it has been tested on all MDT 2012 Update 1 Wizard definitions.

The MDT Wizard Studio has been published as a ClickOnce release, so the “installation” literally takes you one click. Get the most recent version at. https://mdtwizardstudio.codeplex.com/releases.

As always, the MDT Wizard Studio is provided “AS IS” without any express or implied warranty of any kind. Be sure to properly test it before using it within your environments. Especially as it’s still a Beta version.

However feel free to give it a try and I would really appreciate your feedback.

2012 Microsoft® MVP Award – Setup & Deployment

maikkoster — Mon, 01 Oct 2012 16:23:44 GMT

Just received the following email:

Dear Maik Koster,

Congratulations! We are pleased to present you with the 2012 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Setup & Deployment technical communities during the past year.

Thanks to Microsoft for re-awarding me. I really appreciate being part of this community that gives so much.

Or to say this with Johan Arwidmark: “Contributing is Everything!”

Compare Active Directory computer accounts with Configuration Manager resources

maikkoster — Fri, 28 Sep 2012 13:21:17 GMT

Despite all discovery methods, Health scripts and other cleanup efforts it might be helpful from time to time to simply compare all the computer account objects that we have in Active Directory with our resources in ConfigMgr.

There are a couple posts available, that demonstrate how to integrate information from Active Directory into SQL reports. See e.g. “How to add AD data to ConfigMgr reporting” from Garth Jones. As you can see, in his post, Garth shows already how to compare AD accounts with ConfigMgr, so why this post?

Well, they mainly use the ADSI provider as a linked server and the OPENQUERY SQL command to query AD. However most of them suffer from a limitation, that comes from Active Directory itself and will actually hurt most people in a even slightly larger environments. The ADSI provider will only return 1000 rows per query. And there is not way to tell the “OPENQUERY” command to return more rows.

There are a couple ways around this problem:

Increase the limit in Active Directory

Naaaaah. If you don’t know exactly what your are doing, don’t do this, as it has effect on all queries against AD! Also this is not a long term fix, as the company might grow, which would require to increase the limit again.

Call OPENQUERY in batches

Works, but is pretty complicated.

You would need to create a T-SQL script that selects only a subset of accounts, e.g. based on the first character of the name. Every time it reaches the limit of 1000 objects in this subset it would need to divide it again, by e.g taking also the next character of the name into consideration and so on.

If you would like to give this a try, you will find some samples on the internet. I don’t supply a link, as none of them has really fulfilled my needs so far.

Adding a CLR procedure to query AD

See this post from Igor Kovalenko for more information. He basically uses a pre-compiled dll that you have to register in your SQL Server. Again, this will work, but I’m not a big fan of registering some custom dll’s in my sql server. Especially if it is for such a crucial system like ConfigMgr.

Using LogParser to fill a temporary table

LogParser?

YES!

If you don’t know LogParser, you might want to have a look on some IIS query examples that give you a pretty good idea on its capabilities. It’s been initially created to parse IIS log files and haven’t been updated since quite some time (the current download still dates back to 2005), but it’s still some of the most powerful and underestimated tools around. Download it here.

LogParser uses a SQL like syntax to query from IIS logs (of course), text/XML files, Event logs, the File System, Registry and Active Directory (that’s what we need here). It can even parse network captures from Netmon or Windows trace logs. It writes the output to text/xml files, but can also write directly into SQL tables (what we will use in this post).

Most importantly, it’s command line based, so pretty easy to automate. However, there is a GUI called Log Parser Lizzard GUI available for free, in case you struggle with the syntax.

After we installed logparser, we can use something like the following to have it crawl through our AD and return a list of computer with some common attributes we might need (line breaks just added for readability):

logparser.exe "SELECT cn, 
                      objectpath, 
                      operatingSystem, 
                      operatingSystemServicePack, 
                      LastLogonTimestamp, 
                      pwdLastSet 
               FROM 'LDAP://yourdomain.com'" 
               -objClass:computer

Logparser will now write a list of computers in bunches of 10 entries to the default output. In our case the command line window.

As you can see, we selected the LastLogonTimestamp and PwdLastSet attributes. These attributes give a quite good indication if a computer is still active. But these are Active Directory timestamps so not really handy if we want to upload them to a SQL table for some further investigation, as SQL uses a different date/time format. Now Logparser can also help us here. It doesn’t have a native function for the conversion, but if we know, that Active Directory stores date/time values as a number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 in GMT, we can use some logparser native functions to do the conversion for us. So to convert the LastLogonTimestamp, we could use the following:

TO_TIMESTAMP(ADD(DIV(TO_REAL(LastLogonTimestamp), 10000000.0), TO_REAL(TIMESTAMP('1601','yyyy'))))

Now we add this to the original query and execute this (line breaks just added for readability):

logparser.exe "SELECT cn, 
                      operatingSystem, 
                      operatingSystemServicePack, 
                      TO_TIMESTAMP(ADD(DIV(TO_REAL(LastLogonTimestamp), 10000000.0), 
                          TO_REAL(TIMESTAMP('1601','yyyy')))) AS [LastLogon], 
                      TO_TIMESTAMP(ADD(DIV(TO_REAL(pwdLastSet), 10000000.0), 
                          TO_REAL(TIMESTAMP('1601','yyyy')))) AS [PwdLastSet] 
               FROM 'LDAP://yourdomain.com'" 
               -objClass:computer

and we get a nicely formatted output.

Now it’s time to export this information directly into a SQL table. So we need to specify the SQL Server, the Database and the table. We can optionally specify a username and password. We also tell it to create the table if it doesn’t exist and to empty it first, before adding new values, in case it already exists (as we might want to execute this regularly (line breaks just added for readability):

logparser.exe "SELECT cn, 
                      operatingSystem, 
                      operatingSystemServicePack, 
                      TO_TIMESTAMP(ADD(DIV(TO_REAL(LastLogonTimestamp), 10000000.0), 
                          TO_REAL(TIMESTAMP('1601','yyyy')))) AS [LastLogon], 
                      TO_TIMESTAMP(ADD(DIV(TO_REAL(pwdLastSet), 10000000.0), 
                          TO_REAL(TIMESTAMP('1601','yyyy')))) AS [PwdLastSet]
               INTO tmp_ADComputers  
               FROM 'LDAP://yourdomain.com'" 
               -objClass:computer
               -o:SQL 
               -server:YourSQLServer
               -database:Tempdb 
               -createTable:ON
               -clearTable:ON

After we executed logparser, we can open the SQL Management Studio and check our TempDB Database and will find a new table, filled with all computer accounts from AD.

Compare with ConfigMgr

Now we can add a view to our ConfigMgr Database, that correlates the information from this temporary table with the ConfigMgr resources. The view could look like:

SELECT [cn] AS 'Computer Name'
      ,[ObjectPath] AS 'Path'
      ,[operatingSystem] AS 'OS'
      ,[operatingSystemServicePack] AS 'SP'
      ,[LastLogon] 
      ,DATEDIFF(dd, [LastLogon], getdate()) AS 'days LastLogon'
      ,[PwdLastSet]
      ,DATEDIFF(dd, [PwdLastSet], getdate()) AS 'days PwdLastSet'
FROM [tempdb].[dbo].[tmp_ADComputers] 
WHERE cn NOT IN (SELECT name0 FROM v_GS_Computer_System) 
ORDER BY LastLogon

Which will give you a list of computers that are in AD but not in ConfigMgr, ordered by their last logon timestamp.

Feel free to take this as a starting point to implement your own, way more advanced queries

Automating the process

So far, this has been a one-time effort and only reflects the AD information from the time we executed the query against AD. Now you probably want to keep this information up to date, which makes it necessary to automate this process.

There are several ways to automate it. We could run this as a scheduled task. Just wrap the above command in a batch file and execute it on schedule. Easy. Done.

Instead of using the scheduled tasks of the operating system, we could also make use of the SQL Server itself and have the SQL Agent run a job regularly. For demonstration purposes, we make use of another feature of logparser, and that is its capability to be scripted. During the installation it also registers a couple COM components, that we can use from any script language (VBScript, PowerShell, etc). And as we can natively execute scripts in a SQL Agent Job. we have a perfect fit. You need to make sure, that logparser is also installed on the SQL Server.

So let’s create a new Job in SQL Management Studio

and give it a proper name

Then we add a new step and select ActiveX Script

To make it as easy as possible for you and keep this post a bit shorter, you can download a prepared script from CodePlex (Download from here), that contains all necessary steps to call logparser from VBScript.

Click on “Open” and point it to the supplied script (WriteADComputerInfoToSQL.vbs) and the content will pop up in the script window. Now all you need is to adjust some values in the script like giving it the proper domain name, sqlserver name etc.

Define a schedule that fits to your needs and from then the view you have created before is always up to date.

That’s it.

As you have seen, this was just a basic scenario. I would be happy to hear/read from your solutions.

MDT Database version history

maikkoster — Thu, 23 Aug 2012 15:09:22 GMT

As you might know, there is a whole bunch of settings/properties in MDT that drive the processing of MDT. And with every new version of MDT, the amount of settings typically just grows, but sometimes, they also drop the usage of some of them.

Most of these settings are also available in the Database, that comes with MDT, and most of the new settings will also be published to the database, as soon as you upgrade it. However, sometimes, they also get rid of deprecated ones and you typically won’t recognize it on upgrades as the MDT luckily never actively removes an existing column from the database. But if you create a new database, you suddenly might experience, that something is missing and some custom scripts, stored procedures etc. don’t work anymore.

This just happened to Oddvar Håland Moe, who tried to implement a Stored Procedure into a new MDT 2012 Update 1 environment. This Stored Procedure, created by Johan Arwidmark, generates computer names based on some values in the database. However, he had do recognize, that it failed (see the full blog post here).

As there is no publicly available documentation on what exactly has been added and removed during each update, and I have to keep track on it anyway for the MDT Web FrontEnd, I thought it might be helpful for at least some of you, to publish this list:

Find the complete Version History starting at MDT 2008 Update 1 (Not many changes before) on CodePlex at: MDT Database Version history

I will keep it up to date on future versions as well.

For your convenience, I’ve also added links for each setting to the corresponding documentation of MDT. I find it quite interesting from time to time to just snoop through them and get surprised on what else you can configure on MDT. As there is no updated MDT Documentation from Microsoft available online, I had to refer you mostly to the site of the Russian System Center User group. If one of the link fails, please get back to me and I will update it.

@MDTTeam could you please make an up-to-date MDT Documentation available online?

MDT Monitoring Deep Dive IV – Sending more information

maikkoster — Tue, 21 Aug 2012 12:57:02 GMT

In my post MDT Monitoring Deep Dive II – Consuming the data yourself, I showed you how you can write your own web service, that consumes the MDT monitoring information. The next thing we will cover is, how we can send even more information from MDT and also make use of a pretty hidden feature in this monitoring option I blogged about in the last post.

Send additional information

As we have seen in the last couple of posts, MDT will automatically send some information about the current deployment status to a web service. Which it then uses to monitor the deployment. It covers some basic information like the current step and step name, any errors or warnings, current IP address, etc. But what if we would like to receive more information like ServiceTag/AssetTag for some custom identification, the Task Sequence ID it’s currently running, the deployment method or probably some custom property.

Now as we have created a custom web service, it should be a piece of cake. Just add a new parameter to the “PostSettings” method in the web service, and then add this parameter to the web service call in the ZTIUtility.vbs script.

Well, that works, but you would have to redo this, whenever you want to add a new parameter and also whenever you upgrade or install MDT. While it’s generally a bad idea to change the original MDT files, a single change might be worth the effort, but ending up with multiple versions could create some headache. What I’m going to demonstrate now is a more generic way of adding new properties to our Monitoring.

Let’s start with the MDT part first. The idea here is to create a new MDT List property, that holds a list of all additional properties, that shall be included in the web service call. We can then add them on the fly, even dynamically based on other values. On each web service call, MDT just loops through this list and adds an entry for each property.

For reason of simplicity, I call the list “MonitorProperties”. To define them for our deployment, we just add it to our customsettings.ini:

[Settings]
Priority=Init,....,Default
Properties=MonitorProperties(*)

the “(*)” tells MDT, that this custom property shall be treated as a list. Now we can add a couple properties to this new list

[Init]
MonitorProperties001=ServiceTag
MonitorProperties002=SerialNumber
MonitorProperties003=TaskSequenceID
MonitorProperties004=Model
...

So far nothing really fancy. However, we need to make a small change to the ZTIUtility.vbs, otherwise no additional information will be send. In the ZTIUtility.vbs file, we search for the function called “CreateEvent”. In the second part of the function, it’s preparing the web service call (see This post for details). Just after MDT has prepared all its original information but right before it’s sending them, we add the following lines (in MDT 2012 and MDT 2012 Update 1 insert it at line 404)

' Add additional parameters specified in MonitorProperties
Dim sMonProp  
For Each sMonProp In oEnvironment.ListItem("MonitorProperties").Keys
    sLine = sLine & "&" & sMonProp & "=" & oEnvironment.Item(sMonProp)
Next

It should be pretty self-explaining. It just loops through the list of additional properties and for each property, it just adds the name and the configured value to the URL, which is sent to the web service. With this approach, we can influence what is being sent even during runtime, and it doesn’t have any negative side-effect. If nothing is configured, no changes will be applied.

Updating the web service

Well, this was the MDT side of things. Now we need to consume those additional information. To keep things simple, we make use of the Request.QueryString object. It contains the query string from the requested URL and by this gives us a list of all keys and values that have been sent. Now we create two lists, one with the original MDT properties and one that holds the custom ones. In your own solution, you most probably going to have just one, but for demonstration purposes, it’s a nice way of collecting them.

So all I do is I define a new class that contains all the original MDT properties

Public Class MDTDefaultMonitoringModel
    Public Property uniqueID As String
    Public Property computerName As String
    Public Property messageId As String
    Public Property severity As String
    Public Property stepName As String
    Public Property currentStep As Short?
    Public Property totalSteps As Short?
    Public Property id As String
    Public Property message As String
    Public Property dartIP As String
    Public Property dartPort As String
    Public Property dartTicket As String
    Public Property vmHost As String
    Public Property vmName As String
End Class

Then I can use this class as the parameter of my function, making use of a feature of ASP.Net MVC that maps each key from the query string to a corresponding property. Giving us a single object to work with.

Function PostEvent(DefaultProps As MDTDefaultMonitoringModel) As ActionResult

    ...

End Function

If we use only the default properties, we are done now. To add our custom properties, we could either simply extend the above shown class, or we also make it a bit more generic and keep them in a list. As we need to assemble all parameters for our forwarded call to the original MDT Web service anyway, let’s use it to fill a list with all default properties.

Private _DefaultProperties As New Dictionary(Of String, String)

...

    Dim param As String = String.Empty

    ' Prepare parameter string
    For Each prop As PropertyDescriptor In TypeDescriptor.GetProperties(DefaultProps)
        ' Fill a dictionary with all default MDT properties for performance reasons
        _DefaultProperties.Add(prop.Name, prop.GetValue(DefaultProps))
        param &= String.Format("&{0}={1}", prop.Name, HttpUtility.UrlEncode(_DefaultProperties(prop.Name)))
    Next

Then we just take the rest and add them to an additional list, that contains our custom properties.

    ' Get additional custom properties
    For Each prop In Request.QueryString.Keys
        If Not _DefaultProperties.ContainsKey(prop) Then
            _CustomProperties.Add(prop, Request.QueryString(prop))
        End If
    Next

Looks like an ugly way of doing this, but as mentioned before, this is only for demonstration purposes. So the main target is, to just get it working.

Now we would need to store or use this information somehow. In the next post, we will create a small database, that stores this information for further usage and also gives us the same information like the workbench in a web page.

Returning Settings back to the Client

To finalize this post, we want to add the “GetSettings” function to our demo web service. As mentioned in my last post, it’s being queried by the gather process as soon as you switch on the monitoring feature. So without this function, you will regularly see some errors in your logs.

As we did with the the former function, we could also just pass this information to the original MDT web service and send the result back to the client. But as I found this feature pretty hard to use and configure with the default MDT implementation, let’s preserve this for future usage and just return a sample string for now, to prove that it’s working. For demonstration purposes I return a “HelloWorld” for a custom property called “MonitorResult”

Function GetSettings(uniqueID As String) As ActionResult

    Return New XmlResult(New GetSettingsResultModel With {.MonitorResult = "HelloWorld"})
End Function

Looking at the log you can see, the gather process is now querying our custom Monitoring web service (which runs here on a different port than the MDT web service) and stores the result in the custom “MonitorResult” property.

Find the download with the compiled web service and the updated ZTIUtility.vbs file on CodePlex. The source files can also be found on CodePlex in the “Source Code” section. You might want to use a source control client like TortoiseSVN and point it to https://mdtcustomizations.svn.codeplex.com/svn/Demo/MDT_MonitoringService/Current.

In the next post, we will build upon what we have covered so far and move towards a more useful web service that stores and displays the information.

MDT Monitoring Deep Dive III – Returning settings to a Computer

maikkoster — Tue, 21 Aug 2012 09:13:20 GMT

If you enable the MDT Monitoring, you also enable kind of a “hidden” feature, that will give you just another way of setting properties on computers that are being deployed.

One of the most important tasks in MDT is the gather process. It collects information locally on the client computer like hardware info etc. It evaluates the rules configured in the customsettings.ini and can also query databases and web services or run additional scripts for this evaluation. Now, since MDT 2012, if you enabled the monitoring, it will also query the MDT Monitoring web service, if it has some additional settings for the client.

It calls a function called “GetSettings” on the same web service path as it sends the monitoring data to. As a side note, if you create your own web service, as demoed in the previous post, make sure you also implement this function, otherwise you will see some errors in the Gather log. For the demo monitoring web service, we will fix this in the next post.

Let’s have a quick look in the logs from a very simple gather with debugging enabled (otherwise those web service calls will be “silent”)

As we can see, it’s calling the “PostEvent” function first to get the unique ID for this deployment. This normally happens before the gather steps runs the first time and is just due to the fact that I started only gather. Then it’s calling the “GetSettings” function with this unique ID, but we don’t get any information back as we haven’t stored any yet.

One important thing to note here is, that the web service call happens after(!) the gather process has finished processing the customsettings.ini file. This is important to know due to the “First value wins” behavior of most MDT properties.

Now, how can we store a setting, so that it can be retrieved from the computer?

Well, there is a PowerShell cmdlet called “Set-MDTMonitorData”, that we can use for this. And this cmdlet has a parameter called “Setting” that takes a hashtable. Please see the first post of this series for some general information on how to use PowerShell cmdlets to handle monitoring data.

Now for demonstration purposes, I want to set the OSDComputerName to “HelloWorld” and the SkipWizard to “YES”. For this I use the following PowerShell command:

Set-MDTMonitorData -path MDT: -MacAddress "00:11:22:33:44:55" -Setting @{"OSDComputerName"="HelloWorld";"SkipWizard"="YES"}

where MacAddress is the MacAddress of the Client computer. Now, if we run gather again, we will see, it is now obtaining those values from the web service, giving us just another way to influence our deployments.

In the next post, we will implement this function in our custom web service.

MDT Deployment Wizard goes JQuery – Combining VBScript and JavaScript

maikkoster — Thu, 26 Jul 2012 17:54:03 GMT

As you are well aware, JavaScript is, what drives our current online world, make it more dynamic then ever. In opposite to this, VBScript is, what drives almost everything in MDT, giving us full flexibility in our deployments, no matter which version of Windows we are using it on. But what most aren’t aware of is, that those languages easily talk to each other.

“Why would I care?” you might ask.

Well, let’s think about the MDT Wizard or hta FrontEnds in general. Pretty often you write them based on VBScript, just because all the referenced files are using VBScript as well. Which is great for some easy dialogs, type in some information, choose from a short list, etc. and then go ahead. But as soon as you get more dynamic, let’s say manipulating the objects like adding Drag&Drop capabilities, fading in new elements to get a better user experience, etc. it gets a lot more difficult. Even worse, if you start doing any asynchronous operations, working with web services etc. On web sites, your are doing this the whole day. You are used to elements, that load and update in the background, without blocking your page. Reading a blog post while you see current information from twitter etc.

Now if your wizard/frontend queries a database or a web service to e.g. show a list of Task Sequences or applications/packages etc., they need to do exactly the same. And yes, this is all possible in VBScript, but you have to put a lot of effort into it, to code this yourself. When using JavaScript, we have all those existing Frameworks and libraries, we can make use of like Prototype, JQuery, etc. That do this type of things out of the box.

What I want to show in this post is, how we can leverage these features from JavaScript in our VBScript based hta. And I use the MDT Wizard as a sample. At the end of this post, we will have a working wizard, that shows us some twitter feeds.

Calling VBScript from JavaScript and vice versa

Let’s first start with some easy samples to demonstrate, that we can actually really call VBScript functions from JavaScript and also the other way round. Let’s have a look on this extremely simplified hta:

So if we click the button, it will call the function “GetInput”, which is written in JavaScript. This function takes the value of the textbox and pass it to a function called “WriteOutput”, which is written in VBScript, and this one just writes this text to a label. Not really rocket science but it shows how easy it is to combine different scripting languages.

Now, let’s get a bit more advanced. We reference the ZTIUtility.vbs from MDT and the JQuery library and have access to two different pretty complex libraries.

In this sample (I will upload it to CodePlex as always so no need to type it down from this screenshots ), I make use of some JQuery specific features. After the document has finished loading, we dynamically bind the click event of the button and execute an anonymous function. In this function, we get the value of the text field, use a MDT function to obfuscate the value (I recently blogged about this and other functions from MDT) slowly fade out an existing value, set a new value and slowly fade it in again.

As you can see, JQuery is using a much simpler syntax to reference objects in our DOM and allows us to implement some event handling on the fly. And if you ever tried to create some animations like this fading out and it using VBScript, you well, don’t even try it .

Extending the MDT Wizard

OK, this was a small, simple hta. How about something more complex? Let’s extend the MDT Wizard and let it make use of this functionality. What I would like to achieve is having a wizard pane, that allows me to display tweets from Twitter.

Another advantage of JQuery is its PlugIn architecture. So even if something is missing in JQuery, you can be sure there is a plugin available, that does exactly what you are missing. So for our example, I use a Twitter PlugIn from SeaOfClouds called Tweet.

After downloading JQuery and Tweet, we open the wizard.hta from MDT and reference this two scripts, plus the stylesheet that comes with Tweet to make it look a bit more pretty. Depending on the version of mshta, we also might need to add the JSON2 javascript, to have JSON support.

Now we need to create a new wizard pane. This pane contains just a textbox to type in some search string, a button to start the search and a div that will be used to store the tweets. In the XY part we tell it to execute a function called “getTweets()”.

<Wizard>

  <Pane id="Twitter" title="MDT JQuery sample">

    <Body>
      <![CDATA[
      <h1>How To use JQuery for an interactive Deployment Wizard</h1>

      <div id="tweets">
        <div>
          <input type="text" id="txtsearch" />
          <input type="button" id="search" value="Search" onClick="getTweets()"/>
        </div>
        <br/>
        <div id="query" class="query"></div>
      </div>

        ]]>
    </Body>
    <Initialization>getTweets()</Initialization>
  </Pane>

</Wizard>

In the wizard.hta, I add a new JavaScript part to define this “getTweets()” function. The function binds the Tweets plugin to the div we have specified in the wizard pane. Each time it is called, it will get the value from the textbox, replace it with some default text if nothing has been entered and then call Twitter to get some Tweeds.

    <script type='text/javascript'>
        $(function () {

            $.support.cors = true;
        });

        function getTweets() {

            var searchstring;
            searchstring = $('#txtsearch').val();

            if (searchstring == "") {
                searchstring = "Maik Koster";
                $('#txtsearch').val(searchstring);
            }

            $("#query").tweet({
                avatar_size: 32,
                count: 4,
                query: searchstring,
                refresh_interval: 60,
                loading_text: "searching twitter..."
            });

        };

The line with “$.support.cors = true;” is used to solve a small problem we might experience when calling an external URL. As with most scripting languages used within a browser, JavaScript has the “Same Origin Policy”. As we start the hta locally on the computer, it might not really “want” to talk to Twitter as it’s not “local”. But JQuery can also help us here and this one-liner gets around this problem.

If everything went well, we now can start the MDT wizard with the following line

mshta.exe wizard.hta "{PathToWizard}\wizard.hta" /definition:MDTWizard_Twitter.xml

and then should see some Tweets

And now you can use the text box to search in Twitter

You can download this demo project from CodePlex. It’s not really a production ready sample, but hopefully gives you some new ideas. I will soon post an interesting solution that is based on this idea. If you have any feedback, please get back to me.

MDT Monitoring – Deep Dive II – Consuming the data yourself

maikkoster — Wed, 25 Jul 2012 14:34:15 GMT

As mentioned in my last post, MDT 2012 comes with an interesting monitoring option. It installs a web service, where events are being posted to and which the workbench queries to get the current status of all running and recently finished deployments.

But as we also got aware, it’s posting a lot more information as visible in the workbench. So if you would like to see all the stuff that’s going on there and would like to do some more advanced processing/reporting on this stuff, you are reading the correct blog post

How does MDT post the events to the web service?

First we need to know exactly, what MDT does, when it’s posting the events, so that we are able to consume and process them properly. To get this information, we open the ZTIUtility.vbs (the MDT core library) and search for a function called “CreateEvent”

The first half of this function contains the logic that implements the EventShare property. Let’s skip this for now.

The second half is the more interesting part. It creates a web service object, builds a list of parameters to supply, calls the web service and stores the unique ID for further usage during this deployment. Let’s have a look on the latter three.

Building the parameters (originally only three lines of code, just made it a bit more readable):

sID = oEnvironment.Item("UUID") & "," & Join(oEnvironment.ListItem("MacAddress").Keys, ",")

sLine = "uniqueID=" & oEnvironment.Item("LTIGUID") 
sLine = sLine & "&computerName=" & oUtility.ComputerName 
sLine = sLine & "&messageID=" & CStr(iEventID)
sLine = sLine & "&severity=" & CStr(iType) 
sLine = sLine & "&stepName=" & oEnvironment.Item("_SMSTSCurrentActionName") 
sLine = sLine & "&currentStep=" & sCurrentStep 
sLine = sLine & "&totalSteps=" & sTotalSteps 
sLine = sLine & "&id=" & sID 
sLine = sLine & "&message=" & sMessage 
sLine = sLine & "&dartIP=" & oEnvironment.Item("DartIP001")
sLine = sLine & "&dartPort=" & oEnvironment.Item("DartPort001") 
sLine = sLine & "&dartTicket=" & oEnvironment.Item("DartTicket") 
sLine = sLine & "&vmHost=" & oEnvironment.Item("VMHost") 
sLine = sLine & "&vmName=" & oEnvironment.Item("VMName")

Which gives us a list of all the values that are being posted.

Now it calls the web service and stores the result

' Call the web service

oService.WebService = oEnvironment.Item("EventService") & "/MDTMonitorEvent/PostEvent?" & sLine
oService.Method = "GET"
oService.Quiet = true
Set oResult = oService.Query

This tells us, that it adds “MDTMonitorEvent” to the path of our EventService property and that it assumes a function called PostEvent. It’s using the HTTP Get method. And executes this web service quietly. As this is hard-coded and we don’t want to implement any changes in the MDT scripts, we should remember this when create out own web service.

Finally, it takes the GUID, contained in the result and stores it in the property LTIGUID, which will then be used in any future web service call for this deployment.

' Remember the returned GUID value

If oEnvironment.Item("LTIGUID") <> oResult.DocumentElement.Text then
    oEnvironment.Item("LTIGUID") = oResult.DocumentElement.Text
End if

Nothing fancy so far. So let’s create our own web service.

Create a web service

I’ve published already a couple samples on how to create a custom web service. E.g. in “Easily access information from any database and publish it via a web service – Part 2 – The Web Service”.

Using Visual Studio 2010 (Express edition should also work), we create a new, empty ASP.Net MVC 3 project. For web services I typically prefer the “old-style” asmx based web services, but as the web service call is hardcoded in MDT, pointing to a fixed URL, it would become a bit more complicated with re-routing etc. so I use something, that supports this out of the box. We could also use plain ASP.Net or WCF projects, or whatever you prefer. I chose MVC 3 as it’s pretty easy to implement and we can also use it easily to add some reporting to it.

Now, as MDT uses MDTMonitorEvent in the URL, we keep it simple and use the same. So let’s add a new Controller to our MVC 3 project, called “MDTMonitorEventController” (be sure to have the "Controller” at the end of the name as MVC is driven by certain conventions).

The function MDT is using is called “PostEvent”. So we add a new function to our controller and call it “PostEvent” as well. And also add all the parameters, that we have seen above while evaluating the ZTIUtility.vbs. This way, we can make use of the default routing in MVC, so “/MDTMonitorEvent/PostEvent” will point to the controller and our action we have just created and consume all the information MDT is sending to us.

Function PostEvent(uniqueID As String,
                   computerName As String,
                   messageId As String,
                   severity As String,
                   stepName As String,
                   currentStep As Short?,
                   totalSteps As Short?,
                   id As String,
                   message As String,
                   dartIP As String,
                   dartPort As String,
                   dartTicket As String,
                   vmHost As String,
                   vmName As String) As ActionResult

    ' Make sure we have a unique ID for this deployment
    If String.IsNullOrEmpty(uniqueID) Then
        uniqueID = Guid.NewGuid.ToString
    End If


    Return New XmlResult(uniqueID)

End Function

So far, it’s not really doing much. It’s just creating a new GUID if there isn’t a uniqueID supplied and then returning this uniqueID wrapped in XML, as MDT expects it this way. In case you’ve used MVC 3 before and wonder about this ActionResult, the XMLResult has been taken from the MVCContrib project. It just converts a given object into XML and returns it. I’ll supply the whole project for download on CodePlex at the end of this post. So no need to worry.

That’s actually already enough to run the project in Visual Studio (or deploy it to a test directory in IIS) and open the path to our MDTMonitorEvent/PostEvent function. If we do this, we should see, that it returns a GUID (remember, we create a new one, if we don’t supply one?)

Now every time we refresh the page, we get a new GUID. For verification, we supply a GUID as parameter “uniqueID” and should see, that the function returns the same GUID:

Get the MDT Workbench monitoring part working again

We are now ready to get the information from MDT. And are able to do whatever we want with it. Store it in a database, write it to a log file, do some evaluation, etc. But if our deployments post to this function instead of the MDT built-in one, the workbench won’t show anything. Which is ok, if we have our own monitoring solution. But it would also be nice, if we just seamlessly integrate our solution and everything else still works as before.

There are a couple options to achieve this.

We could write a second web service, that returns the data to the workbench. But that means, we would need to re-invent something, that is already being done by the MDT web service. And it’s actually pretty tough to tell the workbench to get the information from a different place or in a slightly different way as a lot of it is hardcoded.

So how about just passing this information back to the original MDT web service?

This way we can consume the data we want, while not really touching anything that comes out of the box and the monitoring tab in the Workbench will still work.

As this is just a Proof-Of-Concept, it’s not pretty and more like a hack, but it’s working. So we just add the following lines to our “PostEvent” function that will just prepare all the information we received, and forward it to the MDT Web service:

' Forward information to original MDT service
Try
    Dim param As String

    ' Prepare parameters
    param = "uniqueID=" & HttpUtility.UrlEncode(uniqueID)
    param &= "&computerName=" & HttpUtility.UrlEncode(computerName)
    param &= "&messageID=" & HttpUtility.UrlEncode(messageId)
    param &= "&severity=" & HttpUtility.UrlEncode(severity)
    param &= "&stepName=" & HttpUtility.UrlEncode(stepName)
    param &= "&currentStep=" & HttpUtility.UrlEncode(currentStep)
    param &= "&totalSteps=" & HttpUtility.UrlEncode(totalSteps)
    param &= "&id=" & HttpUtility.UrlEncode(id)
    param &= "&message=" & HttpUtility.UrlEncode(message)
    param &= "&dartIP=" & HttpUtility.UrlEncode(dartIP)
    param &= "&dartPort=" & HttpUtility.UrlEncode(dartPort)
    param &= "&dartTicket=" & HttpUtility.UrlEncode(dartTicket)
    param &= "&vmHost=" & HttpUtility.UrlEncode(vmHost)
    param &= "&vmName=" & HttpUtility.UrlEncode(vmName)

    ' Create URL
    Dim BaseURL As String = WebConfigurationManager.AppSettings("MDTMonitoringURL") & "/MDTMonitorEvent/PostEvent?"
    Dim URL As New Uri(BaseURL & param)

    ' Send data 
    Dim client As WebClient = New WebClient()
    Dim data As Stream = client.OpenRead(URL)

    ' Read uniqueID from MDT
    Dim reader As StreamReader = New StreamReader(data)
    Dim MDTXMLResult As XmlDocument = New XmlDocument

    Dim xmlString As String = reader.ReadToEnd
    reader.Close()
    MDTXMLResult.LoadXml(xmlString)
    If MDTXMLResult.ChildNodes.Count > 0 Then
        uniqueID = MDTXMLResult.ChildNodes(0).InnerText
    End If


Catch exc As Exception
    Trace.WriteLine("Exception: " & exc.Message)
End Try

To keep it a little bit easier to configure, we store the information about the original MDT Monitoring web service in the web.config in an application setting (MDTURL).

    <appSettings>
        <add key="MDTURL" value="http://localhost:9800"/>
    </appSettings>

Just use the same URL, that MDT is using in the EventService property (stored in your customsettings.ini):

In this sample, it’s installed on the same computer, so I can use “Localhost” instead.

Now if we run our project again and open the URL as shown before and supply a couple more parameters, it should pass this information to our workbench. And Voila!

Process the information

OK, so far, we don’t do anything with the information we now can get from MDT beside forwarding it to MDT again. This is, ehm, well, not optimal. It works for a demonstration, but let’s at least save this information to a file, so we can see what event are being sent during a deployment. Then we can extend our solution later.

To keep this easy, I use my preferred logging solution NLog, that I posted already about in “Add logging to your applications. NLog for beginners.”. Adding this to the project is now easier than ever before, as it is available via Nuget and so can be added to your project from within Visual Studio. Just install Nuget if you haven’t already. Then right click in your project and choose “Manage NuGet Packages …” and search for NLog. I recommend installing NLog and also the NLog Schema for IntelliSense. This will make it easier to create the NLog config file.

After the installation has been finished, you will see a new “NLog.config” file in your project root. Open it and define a new File target and a new rule to write all Info messages to this file. E.G. similar to this:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <!-- 
  See http://nlog-project.org/wiki/Configuration_file 
  for information on customizing logging rules and outputs.
   -->
  <targets>
    <target xsi:type="File" name="Info" fileName="${basedir}/logs/Info_${shortdate}.log" 
            layout="${longdate}: ${message}"/>
  </targets>

  <rules>
    <logger name="*" level="Info" writeTo="Info" />
  </rules>
</nlog>

The installation of NLog also adds a snippet to Visual Studio that eases the creation of log entries. So if we now open our MDTMonitorEventController class and type “nlogger” followed by a double tab, it will be expanded to the following line

Private logger As NLog.Logger = NLog.LogManager.GetCurrentClassLogger()

And now you can use this object to write log entries. As mentioned, we just want to log some information about each event. So we simply add the following lines to the end of our “PostEvent” function, that will log some information like computername or the current step. Again, this is a Demo, so please be kind with me

' Log the information for demonstration purposes
logger.Info("{0} - {1} ({2}/{3}) - {4} ({5}) - {6}", computerName, stepName, currentStep, totalSteps, message, messageId, uniqueID)

If we test this again as described before, we should now see those entries in the files created in the logs folder.

and also the latest entry in the workbench

Configure MDT to use a different web service

Now as we can theoretically (and hopefully practically) consume the data that comes from MDT, we need to know, how we can configure MDT to talk to our own web service. Which is actually pretty easy.

First, we need to deploy our web project to IIS or you download the sample project from CodePlex and add it as a new application to IIS (only tested on Server 2008 R2).

Above you have seen the “EventService” property in the customsettings.ini. All we need to do is changing this to the path to our own web service like “http://YourWebServer/YourWebDirectory”.

Now when you start a new deployment, you should see it in the workbench as before and also should be able to see each individual event in the log file. In the screenshots below, I was running a Deployment of a Domain Controller based on Johan Arwidmarks Hydration Kit for ConfigMgr 2012.

From the workbench before the Task Sequence starts

Choosing a Task Sequence

And then some time into the process

The workbench just shows the current status

But as you can see in the log, a lot more has happened already

After the deployment has finished, we have something like 70 entries in the log file, so enough information to work with.

I’ve published the compiled files to CodePlex (download here) again, and in one of the next posts, we are going to extend this solution, so we actually do more with it then just logging each step. I will also publish the source code soon. As always, this solution is provided AS IS. As it’s currently just a demonstration project, it’s only meant for testing. Please get back to me if you have any questions or feedback.

MDT Monitoring – Deep Dive I

maikkoster — Mon, 16 Jul 2012 13:35:27 GMT

The new monitoring feature is probably one of the most interesting and underestimated features of MDT 2012. In this version, its just some “initial” implementation, but it has great potential and in contrast to other custom extensions that have been available before, it’s tightly integrated and working out-of-the-box with support from Microsoft.

What I won’t cover in this post is how to set it up and troubleshoot. As there has been some great posts already that cover all this in every detail. Please check

Introduction into MDT 2012 Monitoring

and

Troubleshooting MDT 2012 Monitoring

from the Mr. MDT Michael Niehaus himself.

Reasons to monitor your deployments

Automating deployments, doing this as zero-touch as possible has some huge advantages. But with this automation arise some requirements. One of the main reasons to automate such processes is to get rid of manual work. But this also means, that there isn’t necessarily someone in front of the computer, being able to react on problems or errors. Also, even if MDT is pretty easy to set up and use, the whole solution can be pretty complex at certain areas. And if something happens it can require some advanced skills to get a problem fixed. This means, it becomes a requirement, to keep track on deployments. Track problems and errors during deployments, to be able to fix them either immediately so this computer can be deployed as requested. But also get aware on smaller issues or problems, that might become a problem in future or in large scale deployments. We might want to know common problems, to have solutions available for the tech support. We might want track how long it takes on different machines, maybe even track the time of individual time consuming steps, to improve the overall time it takes but also to get aware, if the time on the whole deployment or individual steps increases over time, which might indicate a problem. Maybe to many updates, that should be integrated in the Reference image now. Better to get aware of this, before we reach the expected SLAs.

So lets have a deeper look on what MDT Monitoring does in the current version, where it supports us and where it still lacks some capabilities.

Monitoring options

First, there has always (well, not always, but since quite some time) been some kind of “central” logging/monitoring options within MDT.

We have the possibility to have the logs copied to a central share at the end of the deployment, using the MDT SLShare property. Or we can use the SLShareDynamicLogging, which writes all the logs at runtime to this share. Having the logs available is great, but also requires you to parse those logs for errors, warning, problems, etc. and if used in larger deployments, its becoming even more difficult to keep track.

There is also the “EventShare” property available. Its basically the predecessor of the current MDT Monitoring. We can specify a central network share and certain events are written to this share, where they can be picked up by a central monitoring solution. This could be a solution like SCOM, but Daniel Oxley, one of the Deployment Guys, wrote a small hta, that can monitor this share and give us some information. Please see Simple deployment monitoring for more information.

MDT 2012 Monitoring

With MDT 2012, there is now another option we can use, which is built into the Deployment Workbench (Please see links at the beginning on how to install and configure it). The MDT team actually extended their already existing function, that writes events to the EventShare, to write the same events also to a web service (There was someone before, that said web services are cool ), that comes with the workbench. This web service gets a lot more information then we had available before using the EventShare. On every event, it sends the following information to the web service

- ID(s) of the computer – a comma separated list of the UUID and all Mac Addresses

- a unique ID, that identifies each individual deployment

- The current computer name

- the Message ID, severity and the message text

- The current Task Sequence step Nr, step name and the total amount of steps

- DaRT information (IP Address, Port and Ticket)

- Virtual Machine information (Host name and VM name)

The web service, installed by the Workbench consumes this information, does some processing like calculating the current progress, the processing time, etc. and makes this information available in the Workbench. On certain events, it will also log this information into the event log of the computer running the monitoring web service, which we could use to bind some tasks to those events.

In the workbench, we can now see the progress of each running or recently finished/failed deployment. Additionally it will also allow us to connect to the remote computer, using Remote Desktop, VM Connection or DaRT Remote Control, depending on the supplied information and current phase. Very helpful if you experience any issues, that require you to get a hand on the remote computer.

Event logging

As mentioned, the web service will write certain events to the event log. Those events are:

- a Deployment has started (EventID 41016)

- a Deployment completed successfully (EventID 41015)

- a Deployment failed (EventID 41014)

- an error occurred (EventID 3)

- a warning occurred (EventID 2)

So we could create tasks that run on those events, coming from “MDT_Monitor”, e.g. send an email, if a deployment completed.

More events

But those are just a few of the events, that are being posted the web service. On any step that has been processed, an event will be posted. On long running steps, also the heartbeat (typically 5 min), so one can see if it’s still running. Now one would think, that those events would be ideal for e.g. the time monitoring. But this information isn’t available out of the box. The web service stores only the very last event as the workbench is mainly used to show the current status. It’s not meant for any advanced reporting, so there is also no need to store any historical information. But we will get to the additional events in a later post.

Get the current Monitoring information

Now let’s have a look on the information that is available. The easiest way is using the MDT Workbench in the “Monitoring” node and as shown by Michael Niehaus in the posts I’ve linked at the beginning.

However, there are two additional ways to read this information.

As it is a web service, you can read the information using your favorite browser and point it to http://localhost:9801/MDTMonitorData/ (replace localhost with the name to your MDT server) and you will get an ODATA feed as response, where you could then dig deeper into the different entities like

http://localhost:9801/MDTMonitorData/Computers/

http://localhost:9801/MDTMonitorData/ComputerIdentities/

The response you see seems a bit freaky, but it’s pretty easy to read and handle, when you need to write some custom code.

If you look closely, you will see, that the above screenshot shows, that some information is missing, that is being posted to the web service, namely the message id, severity and the message itself. Instead it contains some calculated values like “PercentComplete” or Start and Endtime.

However, as MDT is completely based on PowerShell, you can also use it to show this information. To do so, we just add the MDT cmdlet

Add-PSSnapin 'Microsoft.BDD.PSSNAPIN'

Then we attach the Deployment Share as new drive

New-PSDrive -Name MDT -Root 'C:\DeploymentShare' -PSProvider MDTPROVIDER

Now we can use the Get-MDTMonitorData function to read the information

Get-MDTMonitorData -Path MDT:

Basically the same information we have seen before. There is also a function called Set-MDTMonitorData, which one could think, that it can be used to add information to the web service, but this is just for testing purposes.

Processing the events

So, what can we do, if we want to make use of this information for other purposes? Or better to say, what about using all the information that is being posted and not just the ones, that MDT is storing for us?

It’s using a web service. So how about writing our own solution, that consumes this events? I’ll guide you through the details on how to do that in the next post.

New features in MDT 2012 – Download files from the internet

maikkoster — Wed, 11 Jul 2012 18:55:53 GMT

Sometimes it would be nice to be able to download some files from the internet or intranet during deployments. Maybe to get some updated tools like bginfo.exe or store some configuration or wizard files outside of your boot image etc.

This is quite easy to achieve for files that are located on a network share, as MDT has some built-in support for this since quite some time already and I’ve recently blogged about the available functions for File-handling (see Extending the MDT Documentation - Some goodies from ZTIUtility.vbs – String and File handling for more information). There are also a couple scripts available, that can do this for you and take away the need to script this yourself. One sample would be the ZTICustomConfiguration script, that I published recently.

However all of them only cover typical file/folder operations on the same computer or from a network share. None of them support you to download something via http or ftp from the internet. But with MDT 2012 it finally also got some (basic) support for this scenario as well.

In the Utility class, which is globally available using “oUtility”, you can find a new function called “InternetFileDownload”. This function takes two parameters. First is the path to the file to download (e.g. “http://live.sysinternals.com/Bginfo.exe”) and the path to the target location, where the file shall be placed. Just be aware, that it requires the full path including the filename. So to download the mentioned BGInfo and store them e.g. in the temp directory locally on the computer you can call the following line within one of your scripts:

oUtility.InternetFileDownload "http://live.sysinternals.com/Bginfo.exe", "%TEMP%\Bginfo.exe"

As this is just some basic implementation, it’s a bit limited. It doesn’t support username and password, like the web service calls do. It requires you to specify the path and filename for the target, so it doesn’t re-use the original file name from the download if only the folder is specified. There is not much error handling, so if something fails, it will just tell you that it failed, but not really why. And finally, you have to implement this function in your own script.

For your convenience, I’ve published a simple wrapper file to CodePlex (Download ZTIDownloadInternetFile.wsf) that will allow you to call this function from within your task sequence. It takes the same parameters as described above. It will also have the same limitations as described, as I didn’t wanted to rewrite this core function, just give you easier access to it. But I’m pretty sure, that the MDT team will continue to work on this functionality and give us some more features.

So to download the same file as shown above, you could now simply add a new “Run Command Line” step to your Task Sequence (after you dropped the ZTIDownloadInternetFile.wsf script in your MDT Scripts folder) that executes the following command:

cscript.exe "%ScriptRoot%\ZTIDownloadInternetFile.wsf" "http://live.sysinternals.com/Bginfo.exe" "%Temp%\Bginfo.exe"

It doesn’t really support more complex scenarios, but works quite well to quickly get one or a few files from the internet or a local web server.

Handling lists in MDT web service calls – Adding Computers / Users to Active Directory groups

maikkoster — Thu, 05 Jul 2012 08:08:35 GMT

A common question if it comes to deployments is, how to add a computer (or user) to one or several Active Directory groups. As you probably know, I generally prefer using web services for any Active Directory related task, as this avoids a lot of typical issues like permission problems, adding ADSI to the WinPE etc. Luckily the Deployment Web Service, which is freely available on CodePlex, has some appropriate functions that allow us to fulfill this task.

Adding a computer (or user) to a single group is pretty easy and can be done with a simple/single web service call. But how about adding the computer to a list of groups? Especially if we don’t know the amount of groups in advance? Which leads to the more generic question, how can I execute a web service function, if I have a bunch of similar values to supply and I actually would need to call the web service once per value? Do I need a huge amount of more or less redundant/equal steps in my Task Sequence?

Adding a computer / user to one AD group

Let’s start with the easy task and add the computer to one AD group only. It’s pretty straight forward and pretty similar to other web service calls, that I’ve demonstrated already on this blog. What we need is a custom property that stores our AD Group and the definition on how to call the web service. So these are the necessary entries in the customsettings.ini to make this work

[Settings]
Priority=Init,Default
Properties=ADGroup


[Init]
ADGroup=MySecureADGroup


[Default]


[AddComputerToADGroup]
WebService=http://YourWebServer/YourWebDirectory/AD.asmx/AddComputerToGroup
Parameters=ADGroup,OSDComputerName
ADGroup=Groupname
OSDComputerName=Computername

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

As you can see, we create a custom property called “ADGroup”. During the gather step, this will be filled with the value “MySecureADGroup” (while it’s processing the Init section). The section “AddComputerToADGroup” contains the definition on how to call the web service. We don’t add it to the “Priority” line, as we don’t want to execute this web service function during the gather step, as the computer account most likely doesn’t exists at that step.

So what we need is a script, that reads this definition and executes the web service function. As you (hopefully) know, I’ve supplied a generic script for this purpose, that can be executed from a “Run Command Line” step in the task sequence. It’s called “ZTI_ExecuteWebservice.wsf” and also available on CodePlex. Please see this Blog Post, for a more detailed description on what it can do.

After we dropped this script in our MDT Scripts folder (or the Scripts folder in our ConfigMgr MDT Package) and updated the customsettings.ini, all we need is to add another “Run Command Line” step to our Task Sequence. I would recommend to add this pretty late in the Task Sequence. At least after we have joined the domain

The command line should execute the following command:

cscript.exe "%ScriptRoot%\ZTI_ExecuteWebservice.wsf" /wsSection:AddComputerToADGroup

We just call the script and tell it in which section it finds the necessary information. That’s actually all you need to add the computer to the specified AD Group. And as with all properties in MDT, you can get this information either static or based on some dynamic rules, even from a database or another web service.

Adding a computer / user to multiple AD groups

Now, as that was pretty simple, let’s tackle the problem on how to add it to multiple groups. MDT allows you to define List properties, that can be filled with values. Some built-in examples would be “Applications”, “Packages” or “Role”. Now you can also define one of those List properties as a parameter for the web service call. A pretty common scenario for this is the MacAddress property which can also store several values and is pretty often used in Web service and Database calls. On default, MDT uses only the first value of the list. So if we create a custom list that stores our AD Groups, we would only be able to add it to the first one.

That means, we need to find a way to iterate through a list and execute the web service for each single entry. To solve this problem, I’ve updated the mentioned script (so be sure to download the most recent version, if you used it already). It now has an additional argument, that can be supplied either directly via command line or via customsettings.ini. It’s called “wsProcessLists”. If it’s not set at all or set to “False” or “No”, everything will behave like before. Only the first value would be used. If you set it to “True” or “Yes”, it will iterate over the list (if there is any) and execute the configured web service function for each entry.

So assume the following customsettings.ini

[Settings]
Priority=Init,Default
Properties=ADGroup(*)


[Init]
ADGroup001=MySecureADGroup1
ADGroup002=MySecureADGroup2
ADGroup003=MySecureADGroup3


[Default]


[AddComputerToADGroup]
WebService=http://YourWebServer/YourWebDirectory/AD.asmx/AddComputerToGroup
Parameters=ADGroup,OSDComputerName
ADGroup=Groupname
OSDComputerName=Computername

Only slightly different to the one I showed before. The property is now a list property ( defined by this (*) ) and we add a couple more values to it. Nothing else has changed. Now all we need to change in the command line is adding the mentioned argument:

cscript.exe "%ScriptRoot%\ZTI_ExecuteWebservice.wsf" /wsSection:AddComputerToADGroup /wsProcessLists:True

If we now execute the task sequence, the new computer account will be a member of all configured AD groups. We can use the same functionality to add it to several ConfigMgr collections, etc. Each web service call will be logged, and the script will also write some additional information for better troubleshooting if you enable the debugging in MDT.

Here two screenshots from the BDD.log (I enabled debugging, so we can see a bit more). It’s using the customsettings.ini just shown. In the first screenshot, it’s using the default MDT behavior. As you can see, only one call is executed and the computer is only added to the first group we have added to the list:

Now in the second screenshot, we have called the script with “/wsProcessLists:True”, and we see that the web service is called three times:

That should be simple enough, shouldn’t it?

However, there are two small limitations on that functionality

1. It’s processing only the first list property it finds in the list of parameters. So if you have several of them, be sure to order them appropriately in the web service definition.

2. The list must have a different name, than the corresponding web service parameter. The script is mapping each value directly to this parameter, which doesn’t work, if they have the same name.

Also, if you would like to process the results, be aware that these are independent calls, so only the value from the last execution would be stored (or from the first run, if you told the script to not overwrite any existing values).

Happy testing and as always, this script and information is provided AS IS. Be sure to test it thoroughly and whatever happens, it will be your fault alone .

If you found this script helpful, please get back to CodePlex and give it a proper rating. If you found an issue with it or would like to have some more functionality implemented, just start a discussion. I’m happy about any feedback.

Offline Domain Join with MDT

maikkoster — Mon, 25 Jun 2012 07:54:35 GMT

Windows 7 and Windows Server 2008 R2 come with a new feature called “Offline Domain Join”. With this, you get the possibility to join a computer or member server to the domain, even if that computer/server currently isn’t connected to the domain. Why would I need that, you might ask. Well, think about remote workers or remote technicians, that might only have a VPN connection to your network. Or you have (or are) an external company (OEM, etc.), preparing the new computers at a remote location and you want to have them read to go, without anyone locally doing the domain join afterwards or some script that runs automatically after the first restart.

For this, Windows 7 and Windows Server 2008 R2 come with a small tool called “DJoin.exe”. It must be called with elevated privileges. DJoin allows you to either provision a new computer account and store this information in a textfile (or a Base 64 encoded blob), or use this textfile to prepare the current computer to join the domain using the specified textfile on next reboot (e.g. after it has been delivered).

Provision a new computer

To provision a new computer account, you can specify the Domain to join, the name of the new computer account and optionally the OU where the computer account shall be created.

Lets create a Demo computer:

If you don’t have DC with Server 2008 R2 available, you need to specify the parameter “/DOWNLEVEL”. However after DJoin.exe has finished successfully, we will have a small text file, that contains the Offline domain join information, that are necessary to join a computer with this name to the domain. If you look at the file, you will see some Base 64 encoded information. As this is pretty sensitive information, you should keep this file protected.

Offline Domain Join – manually

Now we can use this text file and the DJoin.exe on another computer, to join it to the domain.

On next reboot, the computer will be joined to the domain. So you could run this as last step of your preparation, before the computer is being sent to its target location. And if it boots there, its already a member of the domain.

Offline Domain Join – automatically using DJoin.exe

So far, nothing really fancy. OK, the offline domain join itself is pretty cool, but still requires some manual steps. And as a frequent reader of this blog, you most probably want to have this automated.

Let’s first automate the domain join via the text file that’s being created. Automating the creation of the text files is pretty easy. All you need is a list of computers names, and then just parse this list with e.g. PowerShell and call djoin.exe for each entry as show above. Then we need a small script, that is called from our Task Sequence and executes DJoin.exe appropriately. Find the script on CodePlex. It expects the file to be named with the computer name and will find it at any “default” location, e.g. in the Tools or Servicing folder. After next reboot (typically after the Task Sequence has completed) the computer will be a domain member.

Offline Domain Join – Automatically using Unattend.xml

That works, but still requires some manual work. However, there is a second way to do this, which doesn’t require the text file itself. As actually all we need is the Base 64 encoded Blob. How could we get this blob without the file? Well, one way could be to store this blob in a custom property in the database. Now this database just needs to be available from everyone, that does the deployment. Or imagine you have a publicly available web service (with proper authentication and authorization ) that takes a computer name and spits out the required blob. Then this web service could be called from the OEM during the preparation of the computer and we have all the information we need to join this computer to the domain.

Now that blob needs to be added to the Unattend.xml file. MDT is already updating the Unattend.xml file with all your settings. So one would think it shouldn’t be to hard to get this done. Sadly, it’s not working out of the box as MDT doesn’t know about how to add this information. We would need to update the original ZTIConfigure.xml file with the necessary mapping information. But I really hate to change the original files as I would have to redo it on every update, it could interfere with other scripts, etc. Luckily, I just published a script, that is, beside other helpful tasks, also able to update xml files (see ZTICustomConfiguration.wsf – a script to solve common tasks in MDT Deployments for more information and samples). We just need to download it from CodePlex and drop it in the MDT scripts folder.

We update the ZTICustomConfiguration.xml file with a section that will update the Unattend.xml file as required for our offline domain join. It will only be processed, if we are in the PREINSTALL Phase and if the OfflineDomainJoinBlob has a value.

  <configurationset id="ODJ">
    <operations>
      <!-- Updates the unattend.xml file for an offline domain join-->
      <file source="%OSDAnswerFilePath%" operation="update" type="xml">
        <rules>
          <include condition="All">
            <rule property="PHASE" operation="equals" value="PREINSTALL" />
            <rule property="OfflineDomainJoinBlob" operator="notempty" />
          </include>>
        </rules>
        <node operation="delete">
          <xpath><![CDATA[//settings[@pass="specialize"]/component[@name="Microsoft-Windows-UnattendedJoin"]/Identification]]></xpath>
        </node>
        <node operation="create">
          <xpath><![CDATA[//settings[@pass="specialize"]/component[@name="Microsoft-Windows-UnattendedJoin"]]]></xpath>
          <node position="child">
            <Identification>
              <Provisioning>
                <AccountData>%OfflineDomainJoinBlob%</AccountData>
              </Provisioning>
            </Identification>
          </node>
        </node>
      </file>
    </operations>
  </configurationset>

Now we need to update our CustomSettings.ini. We create a new custom property called OfflineDomainJoinBlob (Used in the xml seen above). And also configure it to reach out to our web service that returns this blob and store the value in this property. But this could also be a database call or a script that reads the text file and extracts the blob etc. As always, there isn’t only one way of doing things.

[Settings]
Priority=Init,GetODJBlob,Default
Properties=ConfigurationSet(*),OfflineDomainJoinBlob


[Init]
ConfigurationSet001=ODJ


[Default]


[GetODJBlob]
WebService=http://YourWebServer/DeploymentWebService/AD.asmx/GetOfflineDomainJoinBlob
Parameters=OSDComputerName,MachineObjectOU
OSDComputerName=ComputerName
MachineObjectOU=OUPath
OfflineDomainJoinBlob=string

Then we add a new step to our Task Sequence, just right after the “Configure” step, that calls our ZTICustomConfiguration.wsf script.

What will happen during the deployment is the following.

1. At the very beginning, MDT will run the Gather and evaluate our customsettings.ini. It will create the custom properties we have specified, it will set the values we have specified and it will also call the web service and store the blob in the property OfflineDomainJoinBlob

2. ZTICustomConfiguration.wsf will be called just after the Configure step has already updated the Unattend.xml file. If the OfflineDomainJobBlob property has a value assigned, it will remove all information about an online domain join and replace it with the offline domain join information.

3. After the first reboot, Windows setup will evaluate the Unattend.xml file and by this automagically join the domain that isn’t available yet.

As always, all scripts and files can be found on CodePlex (Download here). But you don’t get everything for free this time. The updated web service that is used during this sample will be published, after the next 20 reviews of the MDT Customizations project on CodePlex. Interested to see how long that takes.

Extending the MDT Documentation - Some goodies from ZTIUtility.vbs – String and File handling

maikkoster — Sun, 24 Jun 2012 16:05:39 GMT

The Microsoft Deployment Toolkit comes with a pretty extensive and almost complete documentation, which is even more remarkable, as it’s a free tool.

But even this almost complete documentation, it’s lacking some information that might be helpful for some of you. I’ll start with two things that are available in the ZTIGather.vbs. Why should you care? Well, ZTIGather.vbs is more or less THE core script, that is referenced by almost any other scripts. It holds all the publicly available classes for Logging, environment handling etc. But it also contains two classes, that are only mentioned with one sentence each in the documentation. But can be really helpful if you need to do some advanced things in the customsettings.ini (as you probably know, you can use all available vbscript functions during the gather process, so these will be available too as ZTIUtility.vbs is referenced during that step) or if you write your own scripts, that most probably also reference the ZTIUtility.vbs.

String Handling

The “Strings” class, which is globally available using the object “oStrings” has the following helpful functions:

- isNullOrEmpty (Value) –> Returns True, if the supplied value is either Null or an empty string. False, if not.

- AddToList (List, Item, Delimiter) –> Adds a new item to a delimited list of items. E.G. AddToList (“One,Two,Three”, “Four”, “,”) will return “One,Two,Three,Four”.

- HexWidth (Value, length) –> Returns the supplied value as hex value of the specified length. E.G. HexWidth (2748, 8) returns 00000ABC

- HexWidthByte (Value, Length) –> Returns the first byte of the supplied value as hex value of the specified length. E.G. HexWidthByte (A, 8) returns 00000041

- IsWhiteSpace (Char) –> Returns True, if the supplied Character can be interpreted as a “Whitespace”, so a real space, Tab, VerticalTab, LineFeed, FormFeed or CariageReturn.

- TrimAllWS (String) –> Removes all Whitespaces from the supplied string. E.G. TrimAllWS (“Contributing is everything …”) returns “Contributingiseverything…”

- RightAlign (String, Length) –> Returns a string of the given length, with the supplied string aligned to the right. If Length is lower than the total length of the supplied string, only a substring counted from right will be returned.

- LeftAlign (String, Length) –> Returns a string of the given length with the supplied string. Is the length is lower than the total length of the supplied string, only a substring counted from left will be returned. If it’s larger, Spaces will be appended to the supplied string.

- ForceAsString (Value) –> Returns the supplied value as a string. If the supplied value can’t be interpreted as a string, an empty string will be returned. Arrays will be converted into a space delimited list of items.

- ForceAsArray (Value, Delimiter) –> Returns the supplied value as an array. If the supplied value is a string of delimited items (like from AddToList or ForceAsString), it will split this string at each delimiter into array items.

- GenerateRandomGUID –> Returns a new GUID. Very helpful if you need a unique value.

- base64Encode (Value) –> Returns the supplied value as Base64 encoded string. That’s how e.g. the values of all MDT properties are stored in the Variables.dat to survive a reboot.

- base64Decode (Value) –> Returns the original (decoded) value of the supplied Base64 encoded string.

So if you need a unique string of 6 characters for a computer name, all you need to do is adding the following to your customsettings.ini

[Settings]
Priority=Init,...,Default

[Init]


[Default]
OSDComputerName=XYZ-#Mid(oStrings.GenerateRandomGUID,2,6)#

Which will then create something similar to XYZ-855CDD during the Gather step.

File Handling

ZTIUtility.vbs also comes with a publicly available class, that does some common file and folder handling. The following functions are available using the object “oFileHandling”. All Functions will log their activity in the log file.

- RemoveFolder (Path) –> Removes the folder specified by the path. It will also remove all files and subfolders. Call RemoveFolderEx (Path, False) to disable the logging.

- DeleteFile (Filepath) –> Deletes the specified File. Call DeleteFileEx (FilePath, False) to disable logging.

- MoveFile (FilePath, DestinationPath) –> Moves the specified file to the specified new Destination. Call MoveFileEx (FilePath, DestinationPath, False) to disable logging.

- CopyFile (FilePath, DestinationPath, Overwrite) –> Copies the specified to the specified location. If Overwrite is set to True, an existing file will be overwritten, if set to False, not. Use CopyFileEx (FilePath, DestinationPath, Overwrite, False) to disable logging.

- CopyFolder (FolderPath, DestinationPath, Overwrite) –> Copies the specified folder to the specified Path. If Overwrite is set to True, an existing folder will be overwritten, if set to False not. Use CopyFolder (FolderPath, DestinationPath, Overwrite, False) to disable logging.

- MoveFolder (FolderPath, DestinationPath) –> Moves the specified Folder to the specified path. User MoveFolder (FolderPath, DestinationPath, False) to disable logging.

- NormalizePath (Path) –> Returns the “complete” path of the supplied path. If you e.g. specify only a file name, the complete path including drive will be returned.

- GetTempFile –> Returns the path to a temporary file at the current temporary folder that could be used. It does not create the temporary file, just returns a unique name that can be used to create one. Use GetTempFileEx (Extension) to return a new temporary file name with the specified extension. On default it will be “tmp”.

- GetTempFolder –> Returns the path to the current Temporay folder.

- GetWindowsFolder –> Returns the path to the current Windows Folder. Should be identical to %WinDir%.

- CheckFileVersion (FileName, MinVersion) –> Returns True if the specified File has at least the specified version or greater. Returns False if less or if the File can’t be found.

Publishing ZTICustomConfiguration.wsf – a script to solve some common tasks in MDT Deployments

maikkoster — Mon, 18 Jun 2012 13:28:00 GMT

There are a couple things, that are quite common in most deployments. Very often you need to delete a couple files, copy some folders, remove or update some registry keys, maybe update a XML or INI file etc. What a lot of people typically do is to write some kind of cleanup-script that runs at the end of their task sequence and removes unnecessary shortcuts, updates the registry to disable some auto-update features or whatever. Group Policy Preferences or Group Policies would probably often be a better choice for most of the scenarios, but lets skip them for a moment.

What I would like to publish today is a generic script, that covers all these common tasks, and allows you to configure them in a simple to use xml file. It ties nicely into MDT with all their logging and error handling etc. Lets have a quick run-through on what it can do, and then look at some samples on how to use it.

What can it do?

- Create, copy, move and delete files and folders

- Create, update, delete and read(!) registry settings including mounting of offline hives

- Create, update, delete and read XML, INI and simple text files

- Use MDT properties, environment variables and even VBScript functions as values, for path or file names, etc.

- restrict execution based on rules

How to use it?

- Download the script and xml file from CodePlex

- Drop them in the MDT scripts folder, or add them to your MDT scripts package source folder in ConfigMgr

- Update the ZTICustomConfiguration.xml file according to your specific needs (see samples section in the file or this blog post for more information)

- Test your changes (will publish a blog post about how to test this script without a full deployment pretty soon)

- Optionally create a new list property within MDT and add all configuration sets, that you would like to have processed (see sample customsettings.ini in the download)

- Add a “Run command line” step to your Task Sequence and have it execute “cscript.exe %ScriptRoot%\ZTICustomConfiguration.wsf”

- Refresh the Deployment Share / Update the ConfigMgr package

- Execute the Task Sequence

The configuration file

The execution of this script is driven by a xml file called “ZTICustomConfiguration.xml”. It should be placed in the MDT scripts folder, together with the script file ZTICustomConfiguration.wsf. This xml file can contain several so called “configuration sets”. And you can tell the script what set(s) shall be processed and in which order. So you could have one common configuration file for all your Task Sequences, but just process some of these configurations depending on the Task Sequence or other prereqs. There is one “Default” configuration set, that will be processed if nothing else is configured.

The Rules

All actions at any level, from the whole configuration set down to an individual action, can be bound to rules. However, there is no necessity to specify rules, in this case everything will just be processed. Rules can be used to either include and/or exclude computers from processing something. And by combining those include and exclude rules, you will be able to cover even pretty complex scenarios. All rules rely on the evaluation of MDT properties. So mainly, if they contain a specific value, if they are empty, etc. We will see some samples in a minute. It might sound a bit limiting, but there are a couple hundred predefined MDT properties, ready to use and you can still define your own. And as the script allows you to read e.g. keys/values from the registry or a file into a MDT property, actually almost any information from a computer can be used for the evaluation.

As a sample, to e.g. run a certain set of actions only for Win 7 64 Bit, you could specify the following Rules:

    <rules>
        <include condition="all">
            <rule property="OSVersion" operator="equals" value="Win7Client" />
            <rule property="Architecture" operator="equals" value="X64" />
        </include>
    </rules>

We could write the same by excluding the x86 architecture

    <rules>
        <include condition="any">
            <rule property="OSVersion" operator="equals" value="Win7Client" />
        </include>
        <exclude condition="any">
            <rule property="Architecture" operator="equals" value="X86" />
        </exclude>
    </rules>

I guess you get the point.

Currently the script supports the following operators (see the ZTICustomConfiguration.xml file for complete Syntax)

- equals

- startswith

- endswith

- contains

- notcontains

- empty

- notempty

Registry operations

Let’s start with some often used necessity and update the registry. As you might be aware, on default, a normal User, even a PowerUser can’t install Printer drivers on Windows 7 64 Bit. Yes, there is a GroupPolicy, but hence, we want to fix this permanently during our deployment. This is a sample on what we would need to configure, to get this done:

      <!-- Allow users to install drivers for the printers/scanners on Windows 7 64 Bit -->
      <registry>
        <rules>
          <include condition="all">
            <rule property="OSVersion" operator="equals" value="Win7Client" />
            <rule property="Architecture" operator="equals" value="X64" />
          </include>
        </rules>
        <!-- Allow Devices Classes-->
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses" operation="update" type="REG_DWORD">00000001</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\1" operation="update" type="REG_SZ">{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\2" operation="update" type="REG_SZ">{48721B56-6795-11D2-B1A8-0080C72E74A2}</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\3" operation="update" type="REG_SZ">{49CE6AC8-6F86-11D2-B1E5-0080C72E74A2}</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\4" operation="update" type="REG_SZ">{4658EE7E-F050-11D1-B6BD-00C04FA372A7}</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\5" operation="update" type="REG_SZ">{4D36E971-E325-11CE-BFC1-08002BE10318}</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DriverInstall\Restrictions\AllowUserDeviceClasses\6" operation="update" type="REG_SZ">{4D36E979-E325-11CE-BFC1-08002BE10318}</key>

        <!-- Switch off PointAndPrint restriction -->
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\Restricted" operation="update" type="REG_DWORD">00000000</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\InForest" operation="update" type="REG_DWORD">00000000</key>
        <key path="HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint\TrustedServers" operation="update" type="REG_DWORD">00000000</key>
      </registry>

The same way, we created/updated a registry key or value, we can also delete one. But how about reading a value and storing it in a MDT property so it can be used later? Le’s say we want to read the BIOSVersion from the registry into a custom MDT property called “MyBIOSVersion”.

      <registry>
        <key path="HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation\BIOSVersion" operation="read" property="MyBIOSVersion" />
      </registry>

That’s it. Now we could use this value to process some other rules etc. But the values and names we use, don’t need to be static. At almost any place we can make use of environment variables, MDT properties, even vbscript functions if we want to. Let’s tattoo some deployment info to the registry:

      <registry>
        <rules>
          <exclude condition="any">
            <!-- tattoo only in the full OS -->
            <rule property="OSVersion" operator="equals" value="WinPE" />
          </exclude>
        </rules>
        <key path="HKLM\Software\Microsoft\Deployment 4\Deployment Method" operation="update" type="REG_SZ">%DeploymentMethod%</key>
        <key path="HKLM\Software\Microsoft\Deployment 4\Deployment Type" operation="update" type="REG_SZ">%DeploymentType%</key>
        <key path="HKLM\Software\Microsoft\Deployment 4\Task Sequence ID" operation="update" type="REG_SZ">%TaskSequenceID%</key>
        <key path="HKLM\Software\Microsoft\Deployment 4\Task Sequence Name" operation="update" type="REG_SZ">%TaskSequenceName%</key>
        <key path="HKLM\Software\Microsoft\Deployment 4\Task Sequence Version" operation="update" type="REG_SZ">%TaskSequenceVersion%</key>
        <key path="HKLM\Software\Microsoft\Deployment 4\Demo" operation="update" type="REG_SZ">#Left("%OSVersion%",3)#</key>
      </registry>

As you can see, we use a couple MDT properties and store their values in the Registry. In the last key, we store just the first three characters from the “OSVersion” property in the registry. Again, I guess you can imagine, that there will be a lot more advanced functions, that can be used with. This is not limited to values, you can use them in the path also.

The final thing I want to show on registry operations, is the possibility to mount a hive first, before updating it. That’s a pretty common task if you want to make some changes on the default profile. Let’s see how we can load the default user registry and disable Desktop Cleanup

      <!-- Disable Desktop Cleanup in default User profile -->
      <registry>
        <hive source="%USERPROFILE%\..\Default User\NTUSER.DAT">
          <key path="Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\CleanupWiz\NoRun" operation="update" type="REG_DWORD">1</key>
        </hive>
      </registry>

The script will take care about loading and unloading the hive and redirecting the keys.

File and Folder operations

The next pretty common thing is executing some file and/or folder operation like moving a folder from a network share to the local computer, copying some files to the default/administrator profile, removing some unwanted shortcuts. etc. Let’s create, copy, move and delete some files and folders

      <folder source="%Temp%\CustomConfigurationDemo" operation="create" />
      <folder source="%Temp%\CustomConfigurationDemo\FolderCopyTest" operation="create" />
      <folder source="%Temp%\CustomConfigurationDemo\FolderCopyTest" target="%Temp%\CustomConfigurationDemo\FolderMoveTest" operation="copy" />
      <folder source="%Temp%\CustomConfigurationDemo\FolderMoveTest" target="%Temp%\CustomConfigurationDemo\FolderDeleteTest" operation="move" />
      <folder source="%Temp%\CustomConfigurationDemo\FolderDeleteTest" operation="delete" />
      <file source="%Temp%\CustomConfigurationDemo\FileCopyTest.txt" operation="create" />
      <file source="%Temp%\CustomConfigurationDemo\FileCopyTest.txt" target="%Temp%\CustomConfigurationDemo\FileMoveTest.txt" operation="copy" />
      <file source="%Temp%\CustomConfigurationDemo\FileMoveTest.txt" target="%Temp%\CustomConfigurationDemo\FileDeleteTest.txt" operation="move" />
      <file source="%Temp%\CustomConfigurationDemo\FileDeleteTest.txt" operation="delete" />

As you can see, it’s pretty easy to define what to do and again, you can make use of all Environment variables and MDT properties.

Now to something more fancy. We can also create and edit files. Most easy thing is a simple text file.

      <file source="%Temp%\CustomConfigurationDemo\FiletxtTest.txt" operation="update" type="txt" overwrite="true">
        <writeline>First Line</writeline>
        <writeline>Second Line</writeline>
      </file>

      <file source="%Temp%\CustomConfigurationDemo\FiletxtTest.txt" operation="update" type="txt" overwrite="false">
        <writeline>Third Line</writeline>
        <writeline>Current User: %Username%</writeline>
        <writeline>SystemRoot: %SystemRoot%</writeline>
      </file>

This will create a new textfile (overwrite=”true” will overwrite any existing file) and write a couple lines of text to it. Then we append a couple more lines with some dynamic content (overwrite=”false” will append the lines if the file exists already).

INI files

OK, that wasn’t really that fancy. How about ini files?

      <file source="%Temp%\CustomConfigurationDemo\FileIniTest.ini" operation="create" type="ini"/>
      <file source="%Temp%\CustomConfigurationDemo\FileIniTest.ini" type="ini" operation="update">
        <section name="EnvironmentVariables">
          <key name="Username">%Username%</key>
          <key name="SystemRoot">%SystemRoot%</key>
          <key name="Temp">#Left("%Temp%",5)#</key>
          <key name="Architecture">
            64 Bit
            <rules>
              <exclude condition="any">
                <rule property="ProgramFiles(x86)" operator="empty" />
              </exclude>
            </rules>
          </key>
          <key name="Architecture">
            32 Bit
            <rules>
              <exclude condition="any">
                <rule property="ProgramFiles(x86)" operator="notempty" />
              </exclude>
            </rules>
          </key>
        </section>
        <section name="DeleteSection">
          <key name="TestKey1" operation="update">TestValue</key>
          <key name="TestKey2" operation="update">TestValue2</key>
          <key name="TestKey1" operation="read" property="MDTDemoPropertyINI1" overwrite="false" />
          <key name="TestKey2" operation="read" property="MDTDemoPropertyINI2" overwrite="false" />
        </section>
      </file>
      <file source="%Temp%\CustomConfigurationDemo\FileIniTest.ini" type="ini" operation="update">
        <section name="DeleteSection" operation="delete" />
      </file>

This looks a bit more complicated. So what does it do? Well, first it creates a new ini file. Then it updates this file with two new sections. A section called “EnvironmentVariables” and one called “DeleteSection”. It writes a couple values to both sections. For demonstration purposes I even added a rule when we write the key “Architecture”. So rules can really be applied at any level. In the part that creates the “DeleteSection” you will also see to entries, that read the value of a particular key and store it in a MDT property. The overwrite=”false” simulates the MDT default behaviour, that MT properties will only be set, if there isn’t already a value. But you can always overrule this by setting overwrite=”true”. Finally, the DeleteSection will be deleted again.

So just ask Johan Arwidmark about changing the customsettings.ini at runtime

The code that does the modification of INI files originally comes from Michael Murgolo, a Microsoft consultant, and has been cannibalized a bit to fit into this script. But he has done all the heavy lifting. See the original Blog Post and script file at: Reading and Modifying INI Files with Scripts.

XML Files

Finally, we can also make changes to an XML file. But not only changes, as shown before, we can also read from an XML file:

      <file source="%Temp%\CustomConfigurationDemo\FileXMLTest.xml" operation="create" type="xml" overwrite="true">
          <DemoRoot></DemoRoot>
      </file>

      <file source="%Temp%\CustomConfigurationDemo\FileXMLTest.xml" operation="update" type="xml">
        <node operation="create">
          <xpath><![CDATA[/DemoRoot]]></xpath>
          <node>
            <Demo1>Hello World</Demo1>
            <Demo2></Demo2>
            <Demo3></Demo3>
          </node>
        </node>
        <node operation="delete" occurence="all">
          <xpath><![CDATA[//Demo1]]></xpath>
        </node>
        <node operation="update">
          <xpath><![CDATA[//Demo2]]></xpath>
          <value>110</value>
          <attribute name="operation" operation="update">Test</attribute>
          <attribute name="TestAttribute">Test2</attribute>
          <attribute name="TestAttribute2">Test3</attribute>
          <attribute name="TestAttribute2" operation="delete" />
        </node>
        <node operation="read">
          <xpath><![CDATA[//Demo2]]></xpath>
          <value property="MDTDemoPropertyXML1" overwrite="false"/>
          <attribute name="TestAttribute" property="MDTDemoPropertyXML2" overwrite="true" />
        </node>
        <node operation="update">
          <xpath><![CDATA[//Demo2]]></xpath>
          <attribute name="MDTDemoPropertyXML2">#Left("%MDTDemoPropertyXML2%",4)#</attribute>
        </node>
        <node operation="delete">
          <xpath><![CDATA[//Demo3]]></xpath>
        </node>
        <node operation="create">
          <xpath><![CDATA[//DemoRoot]]></xpath>
          <node position="child">
            <Demo3>
              <WithChild>
                <AndSome attributes="HelloWorld"></AndSome>
              </WithChild>
            </Demo3>
          </node>
          <node position="firstchild">
            <Demo1>Blablabla</Demo1>
          </node>
        </node>
      </file>

Woah, that’s a lot to read. Let’s go through it step by step. First we create a new xml file with a “DemoRoot” root element.

      <file source="%Temp%\CustomConfigurationDemo\FileXMLTest.xml" operation="create" type="xml" overwrite="true">
          <DemoRoot></DemoRoot>
      </file>

The file will now look like this

Next we update this file we just created and want to add a new node to is. The xpath defines where to create the new node. On default it will be created as a new child to the node defined by the xpath. Optionally we can specify “position” attribute, to create it as “firstchild” or “append” or “prepend” it to that node.

      <file source="%Temp%\CustomConfigurationDemo\FileXMLTest.xml" operation="update" type="xml">
        <node operation="create">
          <xpath><![CDATA[/DemoRoot]]></xpath>
          <node>
            <Demo1>Hello World</Demo1>
            <Demo2></Demo2>
            <Demo3></Demo3>
          </node>
        </node>

Now the XML file will look like

OK, now we delete the “Demo1” node and update the “Demo2” node with a new value and some attributes

        <node operation="delete" occurence="all">
          <xpath><![CDATA[//Demo1]]></xpath>
        </node>
        
        <node operation="update">
          <xpath><![CDATA[//Demo2]]></xpath>
          <value>110</value>
          <attribute name="operation" operation="update">Test</attribute>
          <attribute name="TestAttribute">Test2</attribute>
          <attribute name="TestAttribute2">Test3</attribute>
          <attribute name="TestAttribute2" operation="delete" />
        </node>

The xml file now looks like

Where is the “TestAttribute2” that we just added? Well, we immediately deleted it again. Does that make sense at all? Not really, but it’s fun

Let’s read a value now and re-use it

        <node operation="read">
          <xpath><![CDATA[//Demo2]]></xpath>
          <value property="MDTDemoPropertyXML1" overwrite="false"/>
          <attribute name="TestAttribute" property="MDTDemoPropertyXML2" overwrite="true" />
        </node>
        
        <node operation="update">
          <xpath><![CDATA[//Demo2]]></xpath>
          <attribute name="MyAttribute">#Left("%MDTDemoPropertyXML2%",4)#</attribute>
        </node>

Here we store the value of the Node (110) in the MDT property “MDTDemoPropertyXML1” (what a stupid name). And the value of the attribute “TestAttribute” (Test2) into the MDT property “MDTDemoPropertyXML2” (not getting better). Finally, we create a new attribute called “MyAttribute” and add the first 4 characters of the MDT Property “MDTDemoPropertyXML2” in it (Test). Sounds confusing? Naaaah, let’s have a look on the xml:

And a couple more steps that create, update, and delete some nodes.

While that’s not really a good real-life example, it demonstrates the possibilities. A real-life sample could be to update the unattend.xml file to support an offline domain join (a detailed blog post about it will be published soon), which currently isn’t something that’s supported by MDT out of the box. So that’s the configuration that could be used for this:

      <!-- Updates the unattend.xml file for an offline domain join-->
      <file source="{TODO:Path_to_Unattend.xml}\unattend.xml" operation="update" type="xml">
        <rules>
          <include>
            <rule property="OfflineDomainJoinBlob" operator="notempty" />
          </include>>
        </rules>
        <node operation="delete">
          <xpath><![CDATA[//settings[@pass="specialize"]/component[@name="Microsoft-Windows-UnattendedJoin"]/Identification]]></xpath>
        </node>
        <node operation="create">
          <xpath><![CDATA[//settings[@pass="specialize"]/component[@name="Microsoft-Windows-UnattendedJoin"]]]></xpath>
          <node position="child">
            <Identification>
              <Provisioning>
                <AccountData>%OfflineDomainJoinBlob%</AccountData>
              </Provisioning>
            </Identification>
          </node>
        </node>
      </file>

If the “OfflineDomainJoinBlob” property has a value it will remove all the other domain/workgorup information and add some new nodes to the unattend.xml file, which will allow the computer to be joined to the domain, while not being connected to the network. As said, that’s something I will publish pretty soon.

Integrating in MDT

Normally all you need to execute this script is putting the script and the XML file in the MDT scripts folder (MDT scripts package in ConfigMgr). And then add a “Run Command Line” step to your task sequence, that executes “cscript.exe %ScriptRoot%\ZTICustomConfiguration.wsf”. Where you add the step, depends on the actions, that are being executed. If it’s some kind of clean-up script, it’s probably best to put it somewhere at the end. If it updates the unattend.xml, it should probably be somehwere before the “Configure” step, etc. Due to the Rules, you can also call it several times during the Task Sequence. You would then just make sure, that your steps only run at the appropriate phase.

Optionally, you can specify what configuration sets shall be processed. To do this, you need to add a new list property to MDT. You do this by adding the following to your customsettings.ini

    [Settings]
    Priority=Init,...
    Properties=ConfigurationSet(*)

    [Init]
    ConfigurationSet001=Demo

Configuration(*) creates a new MDT list property. And then you simply add all the configuration sets you would like to have processed. If you don’t specify one, the Configuration Set “Default” will be processed if available.

The script will also accept these additional properties:

- CCSkipFolder –> Set to “YES” to skip all folder jobs

- CCSkipFile –> Set to “YES” to skip all file jobs

- CCSkipRegistry –> Set to “YES” to skip all registry jobs

-- CCSkipLoadHive –> Set to “YES” to skip loading of additional registry hives

What about a FrontEnd?

Why do I need to fiddle around with an XML file? Why isn’t there a nifty frontend for this?

Good question, as I simply haven’t found the time yet to create one and it would probably look awful. So if there is anyone interested in tackling this task, he/she would get my full support on it. So feel free to contact me or just get used to XMLNotepad, Notepad++ or any other nice text-editor with XML capabilities.

I still consider this script Beta, even if I use it already since quite some time. So please go to CodePlex and download the files. Have a look on the supplied xml file, which is used as some initial documentation as well. Implement and test your changes. And give it a try. If something doesn’t work as expected or you have some good ideas on how to extend this solution or make it a bit more comfortable, just get back to me. The next blog post will be about testing and troubleshooting this script and the xml file.

Searching for Drivers in MDT

maikkoster — Tue, 05 Jun 2012 14:40:12 GMT

Today I had an interesting question. Someone wanted to be able to see all the PnP IDs of the imported drivers so he could easily check if a specific device was already supported. While this information is available in the properties of each driver, its not shown in a column of the workbench. And even if it would be available as a column, it wouldn’t be easy to read as a single driver typically supports a whole bunch of PNP IDs.

Now as everything in MDT is available via PowerShell, it should be possible to get this information. Let’s dig through this a bit.

First we open a PowerShell prompt, load the MTD Module and mount the Deployment Share

Add-PSSnapIn Microsoft.BDD.PSSnapIn 
New-PSDrive -Name "MDT" -PSProvider MDTProvider -Root "C:\MyDeploymentShare"

The Drivers are found in the “Out-of-Box Drivers” folder on the deployment share. Let’s just list them for now. The Recurse parameter will just give us all drivers in all subfolders as well.

Get-ChildItem -path "MDT:\Out-of-Box Drivers" –Recurse

as you can see, I’ve only imported a few drivers into the deployment share for demonstration purposes. The result, is also not really helpful, as it returns a list of Driver Names with version and also all Folder names. To get rid of the folders and only list the Drivers, we could add a filter that removes them like

Get-ChildItem -path "MDT:\Out-of-Box Drivers" –Recurse | where {!$_.PSIsContainer}

But we want it functional for now, not pretty . A single driver might cover different models or maybe MDT picked the wrong name etc. Let’s have a look on the properties of one of the Driver

Get-ItemProperty "MDT:\Out-of-Box Drivers\Intel Net E1K5132.INF 11.6.92.0"

OK, that’s a bit better. We see properties like “Manufacturer”, “Version”, “Platform”, “Class”, “OSVersion” and “PNPId”. Most of them are also shown in the Workbench, but not all. Now back to the first query and return the result as a table with some more properties (Yeah, still with folders, ignore them for now)

Get-ChildItem -Path "MDT:\Out-of-Box Drivers" -Recurse | Format-Table -Property Manufacturer, Name, Version, PNPId

Hm, getting better, but still not good. Let’s filter for all Intel Network Drivers and remove a couple columns

Get-ChildItem -Path "MDT:\Out-of-Box Drivers" -Recurse | Where {$_.Class -eq "Net" -and $_.Manufacturer -like "*Intel*"} | Format-Table -Property Name, PNPId

OK, and the same way, we can now filter for a specific device. Let’s say an Intel 82567LM-3 Gigabit Adapter with Device ID “PCI\VEN_8086&DEV_10DE&SUBSYS_10DE8086”.

Get-ChildItem -Path "MDT:\Out-of-Box Drivers" -Recurse | where {$_.PNPId -like "*PCI\VEN_8086&DEV_10DE&SUBSYS_10DE8086"*} | ft -Property Name, Platform, OSVersion

And as we see, we already have a couple drivers imported that will support this device on different Platforms and OS Versions.

There is still some room for improvement. We could encapsulate this in a custom function, maybe also optionally supply a selection profile etc. But that has to wait until I find some sparetime (or a PowerShell magician who probably codes this in a few minutes). Now back to some coding on the Web FrontEnd, the next release is more than overdue but the monitoring grew a bit more than expected.