Hi All, Scratching my head a bit on this one, TS works OK, and utilising variables work OK earlier in the build, but near the end I want to write out some TS variables to the registry and do a few other post build tasks. It runs a WSH that that uses the ZTIUtility script that allows the script to read the variables, but they are all blank. I have tested this in MDT and it works a treat, just not SCCM As the TS is an MDT integrated one, is there somewhere or somehow this TS is dropping the variables? There are other Gather local tasks in the TS and I tried adding the Toolkit files, then gather both local and using Customsettings.ini and still no variables. Any help appreciated B

Hello - Have you seen the below thread (the script)? http://social.technet.microsoft.com/Forums/en-US/configmgrosd/thread/6ad4db58-27b3-4e6c-af08-0d44b0248c54Anoop C Nair - This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi An00p, no I had not seen the script, I think because my ZTIUtility enbedded script worked OK in MDT, it is for some reason not workng in SCCM. Do I now need to leverage the SCCM variables as shown in the other script I wonder, though stangely enough it must be reading some part as it is not creating a REG entry on Desktops if ISVM = TRUE, snippet below. If oEnvironment.Item("ISVM") = "True" Then strVMDisablePWD = "SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" dwValueName = "DisablePasswordChange" dwValue = "1" objRegistry.SetDwordValue HKEY_LOCAL_MACHINE,strVMDisablePWD,dwValueName,dwValue oLogging.CreateEntry "Created "&dwValueName&" "&dwValue , LogTypeInfo End If And it is creating and writing the log file, though I also noticed that the log is in the MININT diectory that hasn't been removed post build and also there is a VARIABLES.DAT that is empty, so I think I'm missing something in the process, just can't nail it down just now. Will look to use the other vriable methos on Monday, I'm out until then, thanks for your reply B

hi bazza, create the following file dumpvar.wsf and place a step in your task sequence to dump your variables to a text file, that way you can see where and when they are getting set (or not set) pressing F8 and running the script mid task sequence will help you to troubleshoot, if you want to be debugging like a programmer, then simply place an alert of some sort (heres an example) as a step before and after your special step in the task sequence, that way you effectively pause the ts between steps so you can capture/monitor data (or in your case check the variables) good luck :) (p.s. i do this type of thing regularly so i know it works) lastly, are you deploying X64 windows ? could be the reg keys are in syswow64.... My step by step SCCM Guides I'm on Twitter > ncbrady

Hi Niall, thanks for your input, yes I am running x64 but I disabled the x64 redirection (got caugh out with that in the Lab!) I will do as you mentioned and dump my VARS out, I'm off until Monday so won't get a chance to check until then :( I will return my findings, BTW I have a Powershell script as well that is leveraging the Variables and it also came out blank, though that was writing extened attributes to the Machine object in AD so didn't expect that to work :D B

ok well also dont forget to add the pauses to the TS to verify whats happening, and do you have a use toolkit package prior to trying to set the variables ? My step by step SCCM Guides I'm on Twitter > ncbrady

Hi Niall, Sorry for the delay, dumped the vars out and there were a couple that weren't the correct value, now I haven't tested in my full TS yet, just created a test one to verify the process. I removed the VB script embedding and I am calling the TS Environment, below is a snippet. Set objTSEnv = CreateObject("Microsoft.SMS.TSEnvironment") Const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv") strValueName = "ComputerName" strValue = objTSEnv("OSDComputerName") objRegistry.SetStringValue HKEY_LOCAL_MACHINE,strCBKeyPath,strValueName,strValue objLogFile.WriteLine "Created "&strValueName&" "&strValue Now this works OK as long as I don't Disable 64-bit file redirection! So obviously the keys get populated in the SysWOW node which I do not want as I have a couple of post build fixes in there such as disabling IP v6. No idea why it is exhibiting this behaviour, command works and it does run as I have another dunp vars task after the VB script. I did toy with moving the registry enteries in to PowerShell but got stuck on adding the DWORD value for disabling IP v6, PowerShell did not like the value :/ Set-ItemProperty -path HKLM:\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters -name "DisabledComponents" -value 'FFFFFFFF' -propertyType DWORD And I get a NamedParameterNotFound error which I think is the propertytype switch, only problem is you remove it and PS changes it to a string which is no use :/ Barry EDIT: I have some regfixes that must be in the non redirected location. I have also tried pointing to c:\windows\system32\cscript.exe and enabled the Disable x64 file redirection and that makes no difference.

Argh, OK revisited the Powershell script. works a treat after I realised I needed to create the key (doh), apart from my DWORD issue, UNTIL I select do not use x64 file redirection. Why of why?? Leave that unchecked and I get all my OSD variables but in the SYSWOW64 area, enable it and I get all the entries and NO values in the proper location. I need to get this working without the redirection to SYSWOW64. B Update: looks like the Policies keys are linked in both hive locations so may have to leave the hive location in SYSWOW though I would rather not Update2: got the DWORD value working for anyone interested the value is 0xffffffff no quotes, it is just this x64 redirection that is the last man standing so to speak

Argh, OK revisited the Powershell script. works a treat after I realised I needed to create the key (doh), apart from my DWORD issue, UNTIL I select do not use x64 file redirection. Why of why?? Leave that unchecked and I get all my OSD variables but in the SYSWOW64 area, enable it and I get all the entries and NO values in the proper location. I need to get this working without the redirection to SYSWOW64. B