Question regarding the Task Sequence Variables.

Apr 21, 2010 at 7:42 PM

Thanks Maik for all you help so far.

My question, is do i still need to place some variables within the SCCM TS to make it pick up and install the packages assigned to a MDT role?

I ask because i go through a deployment, everything appears to be fine, but the packages are never install.

I have my customsettings.ini updated accordingly, and in the right locations, and i can see the packages listed in ztigather.log, as well as the roles listed in the ztigather.log, but i don't see where my role, when selected from the HTA, is recorded. At the end of the frontend.wsf, i've noticed this:

Property OSDCOMPUTERNAME is now =  Frontend 4/21/2010 12:32:37 PM 0 (0x0000)
Property COLLECTIONID is now =  Frontend 4/21/2010 12:32:37 PM 0 (0x0000)
Property ROLE001 is now =  Frontend 4/21/2010 12:32:37 PM 0 (0x0000)
Property COMPUTERDESCRIPTION is now =  Frontend 4/21/2010 12:32:37 PM 0 (0x0000)
Property MACHINEOBJECTOU is now =  Frontend 4/21/2010 12:32:37 PM 0 (0x0000)

Is this expected? Is there something simple i over looked?

Apr 21, 2010 at 9:33 PM
Edited Apr 21, 2010 at 9:46 PM

Update...well, i added a task to the SCCM TS, Install Software, and specified PACKAGES, but it installs all the packages from all the roles, not the package from the role i selected.

I have noticed in the variables.dat when testing that it lists all the packages, as well as in the ztigather.log, PACKAGES001, PACKAGES002 and so on...

I know i am close, hints please....:)

Apr 22, 2010 at 10:55 AM

The idea of the frontend is to take the selected values and write them back to the database to have them available for the gather step. In case of the Roles it will first remove all formerly configured Roles from the computer and then add all the roles back you have selected. Have a look in the bdd.log and you should see a couple webservice calls like "SetSetting ..." or "AddRoleToComputer ...". At the end, the FrontEnd clears out all these properties locally to not have any junk left on the computer.

If the Task Sequence starts, the gather step should take care about "gathering" this information again in combination with all the other configured sections. So you need to have at least a ComputerSettings and ComputerRoles sections plus sections that are getting information about the configured roles. So a minimum cs.ini for the TaskSequence could look like the following example taken from Johans original documentation:

Priority=CSettings, CRoles, RPackages, Default



Parameters=UUID, AssetTag, SerialNumber, MacAddress

Parameters=UUID, AssetTag, SerialNumber, MacAddress



If you still have issues you can also send me your bdd.log after running the wizard and the ztigather.log when the task sequence has started to Maik DOT Koster AT gmx DOT de


Apr 22, 2010 at 2:04 PM

Thanks. I am off today, but will verify this Friday. I know I am missing ComputerRoles section. Thanks again.


Apr 22, 2010 at 2:22 PM

Maik, just to clarify there is no additional step in the SCCM TS required? 

Sorry if i am asking the obvious, but when do the packages specified in the MDT roles get installed when executing the SCCM TS?

Apr 23, 2010 at 2:52 PM

The problem as i see it then is the the selected values are not being written back to the database, at least on the inital run.

if i run it a second time the selections are written back.

On the first run i see entries like this in the BDD.log:

AddRoleToObject: MDTID=00&Type=Computer&Role=Finance

When i run it a second time i see this:

AddRoleToObject: MDTID=40&Type=Computer&Role=Finance

I'll keep digging...:)





Apr 23, 2010 at 7:26 PM

First, yes, you need to have a step in the SCCM TS to install the packages you gathered from the Database. But there should be a valid step for this if you created the Task Sequence based on the MDT Template in SCCM.

Second according to what you wrote and to the logs you have sent me, there are a couple issues.

  • The FrontEnd is executing a couple webservice functions to get different information from the MDT Database. It is, as mentioned already, using a couple Stored procedures for this. One of the first functions is "GetComputerID". According to your logs, it is returning 0. Which is ok on the first call if the computer is not in the database. It should return the real ID if the computer has been added to the database already. You can also call all these functiony by opening http://yourwebserver/yourwebservicedirectory/mdt.asmx (or sccm.asm/ad.asmx) and executing each function directly from a webbrowser. If they don't return the data they should, you would need to digg a bit deeper and see for more tracing information.  If the computer is known already it would also try to query for the Computer Description, the OSDComputername and a list of assigned Roles. But only if known so it's quite ok that no values are returned on the first call. So make sure the webservice is returning the correct values.
  • You have mixed up the customsettings.ini used by the FrontEnd. The sections I've posted above are for the customsettings.ini used by your Task Sequences. So it should be in the Settings package used by your TS. If the Task Sequence starts, it first runs the Gather step. The Gather step is driven by the cs.ini so you would need to have sections in there as shown above to get the computersettings, the ComputerRoles, Rolespackages etc. Don't add them to the cs.ini of the FrontEnd, they are not needed. Also don't call the "GetRoleList" and "GetOSDCollections" sections yourself. They just contain the webservice definition and are called by the FrontEnd.wsf file. As you are calling e.g. the GetRoleList yourself, the gather step of the FrontEnd is adding each role that is returned to the list of selected Roles. That's why you have them all selected. So for the first tests, just leave the cs.ini as you got it from the download and only update the necessary values in the "Initialize" and "Default" section.
  • There was a bug in the version 1.0. I just published an update that is fixing the problem that it wouldn't save the changes the first time as you just mentioned. This was caused due to a missing line in the function, updating the computer information in the MDT Database. Just download the new version. It would actually be enough to replace the FrontEnd.wsf file from the download as I've only implemented some changes in there. Sure you also need to uncomment the lines again to use the GetSCCMAssignedSiteBySLP Function.