In MDT 2010 there has been some changes in the scripts. One of these changes was to extract the Classes regarding Data Access (Database, Webservice) into a separate script called "ZITDataAccess.vbs". If you created your own custom scripts which made use of one of these classes you need to update them to reflect this change.

I will show the necessary changes by way of changing my scripts used in "Moving computer in Active Directory using a webservice".

As the MDT Team just moved the code into a separate script file but left the original names it's quite easy to update. Typically all your custom scripts are *.wsf files. In the header of these script files you can reference other scripts you are using. Let's have a look at the header of the current "Z-MoveComputer_StagingOU.wsf" file:

    <job id="Z-MoveComputer-StagingOU">
    <script language="VBScript" src="ZTIUtility.vbs"/>
    <script language="VBScript">
    ' //***************************************************************************
    ' // ***** Script Header *****
    ' //

Here you can see, that it references the "ZTIUtility.vbs" script from MDT. Now you simply add an additional Reference to the new "ZTIDataAccess.vbs" script and we are now able to call the necessary functions again:

    <job id="Z-MoveComputer-StagingOU">
        <script language="VBScript" src="ZTIUtility.vbs"/>
        <script language="VBScript" src="ZTIDataAccess.vbs"/>
        <script language="VBScript">
    ' // ***************************************************************************
    ' // ***** Script Header *****
    ' //

            

There is another change in the Webservice Class you need to be aware of, if you are also processing results from a webservice containing custom Namespaces. MDT has changed the default Selection language for Webservice calls from XSL Patterns to XPath. Due to this you now need to add the Namespace(s) you are searching in if the necessary elements aren't in the default namespace. Again regarding to the example webservice you would receive the following XML from a successful Webservice call when moving computers in Active Directory:

    <?xml version="1.0" encoding="utf-8" ?>
    <boolean xmlns="http://maikkoster.com/Deployment">true</boolean>
     

As you can see, the node with the result ("boolean") has a namespace defined (xmlns="http://maikkoster.com/Deployment"). Lets have a look on an example. This has been taken from the original Z-MoveComputer_StagingOU.wsf:

    ' Make the web service call
    Set oXML = oService.Query
    If oXML Is Nothing Then
        oLogging.CreateEntry "Unable to call MoveComputerToOU web service.", LogTypeWarning
    Else
        sResult = UCase(oXML.SelectSingleNode("boolean").Text)
    End If
        

With MDT 2010 the result (sResult) would now be empty, as the default namespace doesn't contain this node. To be able to "find" the proper Node we simply add this Namespace to the list of available namespaces and use it within the definition of our search. A possible solution could look like:

    ' Make the web service call
    Set oXML = oService.Query
    If oXML Is Nothing Then
        oLogging.CreateEntry "Unable to call MoveComputerToOU web service.", LogTypeWarning
    Else
        oXML.setProperty "SelectionNamespaces", "xmlns:mk='http://maikkoster.com/Deployment'"
        sResult = UCase(oXML.SelectSingleNode("mk:boolean").Text)
    End If

    

I`m pretty sure there are more elegant solutions. If so please contact me so I can update this example ;-)

Find the updated scripts for both MDT 2008 and MDT 2010 on the MDT Customizations page on Codeplex.

UPDATE: There is another change in the ZTIDataAccess I wasn't aware of. Thanks to David Peel who just pointed me to this. So far you had the possibility to make Webservice (and Database) calls, using a different ini file then the default cs.ini. Let`s have a look at the Property IniFile of these Classes:

    Public Property Let IniFile(sIni)
    Dim sFoundIniFile  
    Dim iRetVal
  
    ' Figure out where the CustomSettings.ini file is

    sIniFile = sIni
    If oEnvironment.Item("RulesFile") <> "" then
        sIniFile = oEnvironment.Item("RulesFile")
    Else
        sIniFile = oUtility.Arguments("inifile")
    End if
    If Len(sIniFile) = 0 then
        iRetVal = oUtility.FindFile("CustomSettings.ini", sIniFile)
        If iRetVal <> Success then
            oLogging.CreateEntry "Unable to find CustomSettings.ini, rc = " & iRetVal, LogTypeError
            Exit Property
        End If
        oLogging.CreateEntry "Using DEFAULT VALUE: Ini file = " & sIniFile, LogTypeInfo
    Else
        If not oFSO.FileExists(sIniFile) then
            iRetVal = oUtility.FindFile(sIniFile, sFoundIniFile)
            If iRetVal = Success then
                sIniFile = sFoundIniFile
            End If
        End If
        oLogging.CreateEntry "Using COMMAND LINE ARG: Ini file = " & sIniFile, LogTypeInfo
   End If
   .....

From my understanding (and running some samples to prove it) it seems that no matter what you define within your custom webservice call it all defaults back to either the Property "RulesFile", the Ini File of oUtility or CustomSettings.ini.