Gleanings from Johan at TechEd 2014

I attended a few of the OSD deployment sessions with Johan Arwidmark at both the main TechEd conference, and also at TechEd Day 5 put on my HASMUG.   Here are some of the things I thought were good to remember.  I appologize for the text wall, but its all good info.


SMSTS.log has a 1mb size, and 1 rollover file by default.  The problem is there is usually more like 4 or 5mb of data written to this log during a deployment.  To change this behavior, you will need to create a text file called SMSTS.ini with the following suggested values:


That will give us a max log size of 10mb instead of 1mb.  You can change the logging levels or add other values if you need them.  Next you will have to inject them into your boot image.  Jump down to the section called “Injecting the SMSTS.ini file into the Boot Image” on this page:


Next thing was that installing DaRT from the MDOP is well worth it.  This allows you to remotely see what is happening in your TS while you are deploying without sitting at the machine.  Unfortunately, this only applies while running the boot image, but its still a nice tool to have in your pocket.  The bonus is that when you turn on monitoring in the MDT console, you can now see what is happening in your OSD TS’s.  Johan has some instructions on his website:


For OSD troubleshooting, finding the right log sometimes is a pain.  Here is a refresher on the logs in the order they are used.
1. x:\windows\temp\smstslog
2. c:\_smstasksequence\logs
3. c:\windows\ccm\logs


CMTrace is actually included in the MDT boot image.  Its located at x:\sms\bin\x64


In your boot image properties, make sure you enable it for PXE (it isn’t enabled by default, and a lot of times you just forget).


This one surprised me.  But offline servicing of your install images isn’t recommended.  Things like frameworks cant be injected, but sometimes try to anyways.  That breaks your image.  Its better to just have a build and capture and rerun it as needed.


Inside the ztisccm.wsf file, you will find this line: wscript.sleep 30000.  This was in there for a specific hardware model from like 6 years ago (confirmed by the guy who actually wrote the script).  It is safe to change the value down to like 5000.


How many times have you been trying to fix a problem during your TS and missed the 15 minute reboot on failure window?  Here is how to fix it:  At the beginning of your TS, add a new Task Sequence Variable.  Set the variable to be SMSTSErrorDialogTimeout and the value to be 86400.  This will give you 24 hours to come back and figure out what is going on before it reboots.


There was a bunch more, but those were the top ones for me.  I wouldnt hesitate to watch his sessions.  Also, make sure you check out his website:

Filed under: Microsoft, SCCM | Posted on May 21st, 2014 by CharlieMaurice

Leave a Reply

RSS Feed





Copyright © 2023 Charlie's Tech Ramblings. All rights reserved.

Tech Blue designed by Hive Designs • Ported by Free WordPress Themes