I have in some situations seen a problem where I suddenly is unable to start a vbscript in an SCCM 2012 OSD task sequence with another account specified.
When the situation occurs I can see this error in the smsts.log:
CScript Error: Can't find script engine "VBScript" for script
The problem appears to be caused by a changed registry value HKEY_LOCAL_MACHINE\Software\Microsoft\COM3\REGDBVersion
When REGDBVersion has the value hex:01,00,00 then vbscript's works as expected.
Until now I have seen that VMware tools and Citrix XenApp can change the value breaking the possibility to start vbscript's with another account in the task sequence.
REGDBVersion value after XenApp 6.5 installation hex:f8,01,00,00,00,00,00,00
REGDBVersion value after VMware Tools installation 06,00,00,00,00,00,00,00
One way around the problem is to call the script before installing software that changes this value.
If this is not possible this can be used as a workaround.
Save the existing registry values under the COM3 key, and then change the value of REGDBVersion to the working value.
Now the script can run and afterwards you can restore the saved keys.
Backup:
REG EXPORT HKLM\Software\Microsoft\COM3 %temp%\com.reg /y
Set Working value
REG ADD HKLM\Software\Microsoft\COM3 /v REGDBVersion /t REG_BINARY /d 010000 /f
Call your script (example)
Restore values:
REG IMPORT %temp%\com.reg
Thanks heaps Lars! This is just what I needed. I was using a Vbscript in my SCCM OSD task sequence to move computers to the right OU and it would just fail to execute or just ignore it.
ReplyDeleteI also noted that the deployments guys blog talks about .Net Framework creating this issue and I install this as part of my hardware tools for Lenovo laptops.
Thanks again :)
Ash
Lars! You solved my issue with this post. Thx for sharing
ReplyDeleteThanks for sharing !!! Had exactly the same problem
ReplyDeleteThank you, this solved my problem.
ReplyDeleteWhen I run the backup step it errors out with "Unable to write to the file". If I try another key (for example HKLM\Software\Dell) the same step completes succesfully.
ReplyDeleteThanks Heaps brother.. this solved my problem
ReplyDeleteThanks Heaps brother. I had the same problem and this resolved the issue.
ReplyDeleteImpressive troubleshooting this solved the issue for me however the vmware tools hex value for me started with 07 instead of 06. Thank you!
ReplyDeleteThank you, Lars! You saved me with this tip! Much appreciated!
ReplyDeleteThanks a lot this worked perfect. I dont know how you got to this fix, would love to find out the troubleshooting process you followed to figure this one out.
ReplyDeleteVery much appreciated!
ReplyDeleteThis is still valid in SCCM 1802 and has just fixed a problem which we've being try to fix for 2 weeks! Thank you!
ReplyDeleteThanks! this solution worked for me.
ReplyDeleteThanks! this solution worked for me.
ReplyDelete