Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS repeated in the bdd.log

Unanswered Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS repeated in the bdd.log

  • Wednesday, February 17, 2010 2:39 PM
     
     
    We are replacing systems and we have a task sequence we run on the old system to back up the user state to a network share for restore on the new system.  most systems are working fine, but we have a small number that, when we run litetouch.vbs, it just keeps writing the line:
    Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS
    over and over in the BDD.log.  it never goes past that and the wizard never launches.
    Any ideas what might be causing this?

All Replies

  • Wednesday, February 17, 2010 4:50 PM
     
     
    Curious, before you launch the Task Sequence to backup user state are you deleting the MiniNT directory? I would try deleting the MiniNT first, then run your Task Sequence.
    http://deploywindows7.wordpress.com/
  • Thursday, February 18, 2010 5:26 PM
    Moderator
     
     
    By any chance is this using SCCM and a 64 bit image?
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
  • Thursday, February 18, 2010 8:19 PM
     
     
    we have consultants doing the replacements, so once we get another one, we iwll try deleting the Minint folder, but it should not have been there in the first place.
  • Thursday, February 18, 2010 8:24 PM
     
     
    No, it is using straight MDT, running litetouch.vbs from the deployment share.
    The image is inconsequential because this is on the legacy machine that is being replaced.  the task sequence they are truying to select is based on the standard client replace TS, so it is not applying an OS, just backing up the user state.  The issue is that it never even gets to the wizard to select the task sequence, it just keeps filling up the log and the wscript.exe process keeps growing in memory.
    we have replaced over 500 systems to date and have exerienced this on about 10 or so.  It's not a huge issue, but I would like to be able to find a cause/resolution to it.
  • Thursday, February 18, 2010 10:01 PM
    Moderator
     
     
    One thing to check is if there is an existing minint folder on the system.  If there is a left over MININT folder with a left over variables.dat from a previous version of MDt that can cause some pretty nasty issues.
    Tim Mintner Principal Consultant Xtreme Consulting Group http://deployment.xtremeconsulting.com
  • Monday, February 22, 2010 7:39 PM
     
     
    I have deleted the MININT and it still happens.  I had 2 more this morning.  I am having them brought to me so I can dig into it deeper.  I'll post my findings, but if anyone has any ideas I'm open for suggestions.
  • Wednesday, February 24, 2010 3:39 PM
     
     
    thisissue is specific to MDT2010 on my end.  I still have my old MDT2008 deployment share available and I can run the litetouch from there with no issues to back up the user data.
    I am trying to follow the logic of the scripts to see where my error might be, but i'm digging deeper and deeper into a hole.
    On a healthy machine, the first mine of the bdd.log is Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS  followed by Microsoft Deployment Toolkit version: 5.0.1641.0.  On the problem machines, that second line never gets reported, it just keeps repeating the first line.
    I thought it was coming from PrepareEnvironment in ZTIUtility.vbs, but I can't tell for sure.
  • Friday, February 26, 2010 1:23 PM
     
     
    I have been able to come up with nothing to date.  I am temporarily using an MDT 2008 deployment share to do my data backups on these systems because I cannot figure out what is happening on the MDT 2010 share.
  • Friday, August 12, 2011 6:44 PM
     
     

    Can I give this a bump?

    I am only using the MDT, Image deployment is not a problem. In our environment I have configured two deployment shares, 1 for OS deployment that is tied to WDS and one specifically for application deployment so that end users can click a link pre-installed on the machine that fires up litetouch and they can select the applications they want to install (yes I know there are many other ways of doing this that may be better, but I find it is really easy to add a script or executable to the MDT than editing group policy across multiple domains and sites)

    I see the same problem on client machines attempting to run litetouch, the only thing I can add is that I have only seen this so far on bitlockered machines

  • Tuesday, May 29, 2012 3:52 PM
     
     
    another bump on this issue.. now seeing this on MDT 2012 after the machine has rebooted for the first time after the image is applied.  The screen is blank and the script is looping at the Property Get Logpath section of ztiutilty.vbs??  Funny thing is the deployments have been working up to now and I'm not sure what has changed.
  • Tuesday, May 29, 2012 6:38 PM
     
     

    I never did actually find a resolution for this.  It still happens periodically when trying to launch MDT via litetouch.vbs on some systems.  we usually find this when we are trying to replace the system and back up the user data.  sometimes rebuilding/repairing WMI on the system fixes the issue, but sometimes not.

    We have just dealt with it since it is not affecting a large number of systems.

  • Thursday, August 23, 2012 1:07 PM
     
     
    Having the exact same issue as RL69. Did you found a solution on this ? After upgrading to MDT 2012 Update 1, and trying to run a refresh scenario, the system stalls after the first time.
    • Edited by Jarvis_kk Thursday, August 23, 2012 1:07 PM
    •