none
Dirty Environment (no Apps, No HIDESHELL)

    Question

  • I'm trying to deploy a Windows7 WIM using MDT2012. The WIM itself was originally built from a MDT2010 deployment.

    After the reboot I'm getting the "Dirty Environment" error. If I click "No", the deployment continues and completes with "0 errors, 0 warnings" but when I log onto the machine I get the error "C:\LTIBootstrap.vbs was not found". Otherwise, the deployment appears to complete successfully and the workstations appears to be fine.

    There are no other custom tasks (using standard template) other than the driver injection (using a modified version using WMI query of this). I have no applications being installed and I'm not using the HIDESHELL command at all. I don't see a MININT or drivers folder in the WIM. There's a \windows\temp\deploymentlogs\ folder with files dated more recently than the original deployment but older than the most recent build of the current deployment.

    So the question I guess is, what all do I need to do/cleanup to remove the "Dirty Environment"? Rebuilding the WIM from scratch is not an option for me.


    CustomSettings.ini:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    
    [Default]
    OSInstall=Y
    SkipCapture=NO
    SkipAdminPassword=NO
    SkipProductKey=YES
    SkipComputerBackup=NO
    SkipBitLocker=NO
    EventService=http://server:port


    • Edited by Ian.Fuller Friday, April 19, 2013 4:14 PM Formatting
    Friday, April 19, 2013 4:08 PM

All replies

  • At which restart do you see the message? Is it after the wim is applied and it reboots into the OS? If so, mount the wim and see if the MININT and SMSTaskSequence folders are still there.

    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. ”

    Sunday, April 21, 2013 12:14 AM
  • Yes, the "inject operating system" task completes successfully and the machine reboots to the "Setup is applying system settings" then "Setup will continue after restarting your computer" and reboots again ("starting windows", "Setup is preparing your computer for first use") before the message is displayed.

    I've tested with CD-ROM media in VMWare Player but it also occurs booting from PXE (WDS) or bootable USB on physical machines (Dell OptiPlex 780, Latitude E6420)

    If I click Yes, I get this:

    If I click OK here it drops me to the CTRL+ALT+DEL logon screen and after logging on I get "Can not find script file "C:\LTIBootstrap.vbs"." (or similar).

    If I click "No" at the dirty environment, I get a wizard complete with "0 warnings, 0 errors" and then it drops me at the logon screen after which I get the same "Can not find script file "C:\LTIBootstrap.vbs"."

    There's no evidence of a MININT or SMSTASKSEQUENCE folder in the WIM:

    Tuesday, April 23, 2013 2:54 PM
  • I'm going to try running the deployment without joining the domain to make sure it's not a GPO causing the issue.

    Any other suggestions would be extremely helpful however. I've found no documentation in MDT regarding the "Dirty Environment" error or logic. It would behoove Microsoft to document the cause and solution to these kinds of error messages. Which script is responsible for this logic anyhow? Maybe I can look through and see how it is determining that the dirty environment exists to get a clue as to what's triggering the error.

    Wednesday, April 24, 2013 12:48 PM
  • Nope, it's not the domain GPOs, I ran the deployment without the domain join and still got the error. Going to try the deployment with an alternate WIM now to make sure it's not the deployment itself.
    Wednesday, April 24, 2013 5:58 PM
  • I can see in the VARIABLES.DAT the following variables:

    LTIDirty=FALSE
    OSDTARGETDRIVECACHE=DIRTY
    LTIDIRTYOS=TRUE

    PHASE=STATERESTORE
    DEPLOYMENTTYPE=NEWCOMPUTER

    "Property LTIDirtyOS is now = TRUE" occurs in the BDD.log immediately after applying the WIM.

    • Edited by Ian.Fuller Wednesday, April 24, 2013 6:33 PM details
    Wednesday, April 24, 2013 6:28 PM
  • Ian, sorry for the late reply. I don't necessarily think its your deployment that is causing the error but the captured WIM itself, and here is why:

    The Dirty Environment message is not necessarily an error message, but more of built-in intelligence to know that it was in the middle of a deployment and was interrupted suddenly. MDT uses a lot of variables and makes some system changes that it cleans after the final task is completed, and if it did not clean it correctly, it will notice. The problem with MDT 2010 was that it determined a dirty environment just by the MININT folder existing, but in MDT 2012 it uses a little more intelligence. So when people created an image using MDT 2010 that did not clean correctly, they would just delete the MININT folder and capture the image not realizing that there are changes MDT made to know it has stopped suddenly, but when you use MDT 2012 to apply the same image, it will see that it did not clean correctly, and prompt you. That is why I asked if you only see the message when the WIM is applied.

    To test this, use a different WIM in the same task sequence and see if you get the error. There is no customsetting.ini option, GPO, unattended.xml setting that would cause this issue.


    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. ”

    Wednesday, April 24, 2013 10:42 PM
  • Frank, thanks for the answer, late is better than never and I definitely still need the help.

    I tried swapping the WIM in my new MDT2012 deployment (let's call it "Custom") for the WIM that came from the original MDT2010 deployment (Let's call it "baseline") and unfortunately the result is the same. I still get the "Dirty Environment" error at the STATERESTORE phase with logs confirming that the Baseline WIM was applied vs the Custom WIM.

    So this indicates one of two things for me:

    A) The original WIM from the Baseline deployment is already "dirty".
    or
    B) It's not [just] the WIM.

    Given that the original deployment completes successfully (Note that I have not tried to rebuild it in MDT2012, I'm using the original build from MDT2010) I'm hesitant to believe that the original WIM is dirty. On the other hand I saw a comment by Michael Niehaus which suggests that by simply capturing the image with MDT2010 can cause it to be "dirty": Dirty Environment

    We have not been able to reproduce this.  We know it could happen if a step in the task sequence forces an unexpected reboot.  In other cases, rebuilding the image (especially if it was captured by something earlier than MDT 2012 RC1) solves the problem.

    Feel free to attach the log files (primarily BDD.LOG) to the thread too, or e-mail them to me, and we'll see if anything appears out of the ordinary.


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus

    This confuses me since I've just been capturing the WIM by running sysprep from the live reference machine, booting into a WinPE image (yes it was built from a MDT2010 deployment) and running imagex.  Is there a difference in the version of imagex embedded in the WinPEs that could cause this issue? I'll try testing tomorrow if a MDT2012 "Sysprep and Capture" task sequence runs any differently than the method I've been using to capture the WIM.

    If the WIM is the issue however and simply deleting the MININT and _SMSTASKSEQUENCE folders isn't the resolution, and recapturing with a MDT2012 WinPE doesn't change anything, what other steps can I take other than rebuilding the WIM from scratch? You can guess by the names Baseline and Custom that we've taken an already heavily customized 'baseline' image from an external source and then further customized it. Rebuilding the WIM from scratch would be extremely labor intensive and frankly I don't consider to be a valid option.

    You also indicate that "Dirty Environment" isn't an error message but "Can not find script file "C:\LTIBootstrap.vbs"." definitely is. Are these two separate issues? I've been assuming they are related and that the dirty environment is causing the latter.

    Wednesday, April 24, 2013 11:49 PM
  • i know i used to encounter this problem while testing at the start of MDT 2012 because MDT 2012 changed how to start/restart the task sequence in the unattended.xml compared to MDT 2010.

    don't know if this is the same problem but you can try to make a new task sequence with your image and try it out.

    what you can also try is make a new image with MDT 2012 to see if that solves your problems.

    Thursday, April 25, 2013 8:35 AM
  • Stefan\Frank,

    I'm no longer getting the dirty environment error after recapturing but it appears the task sequence is no longer completing successfully

    My Steps:
    1) Load reference computer and update products (windows updates, java, etc)
    2) Shut down computer without sysprepping
    3) Boot Reference Computer with ISO created from deployment Media. I was unable to get the Sysprep&Capture sequence to run due to a network driver failure (will work on that later) but I was able to capture a new WIM with imagex /capture /compress maximum d: f:\WIM\Custom.WIM "Blah2" "Blah2"
    4) After putting the WIM into the deployment and trying again, the computer no longer displays the "Dirty Environment" error after boot up but the Screen Resolution is no longer getting set at the Ctrl+Alt+Del screen. After logging on, I'm prompted with 'You must restart to complete the changes'. After a reboot, the resolution is correct but after logging on I never get the "Wizard completed" screen and c:\MININT and _SMSTASKSEQUENCE folders are still there will all the files indicating an incomplete task sequence.

    I'm assuming part of this is the fact that I did not run Sysprep prior to shutting down the reference computer (I assumed the Sysprep&Capture task sequence would do that). Do I need to use the Sysprep&Capture sequence to properly capture a WIM or can I just Sysprep /OOBE the machine and imagex /capture?

    Tuesday, April 30, 2013 2:17 PM
  • I retried the process with a sysprep /oobe prior to creating the WIM and I'm back at square one with the Dirty Environment.

    I need someone to definitively tell me what the Dirty Environment logic is looking for.

    Tuesday, April 30, 2013 7:23 PM
  • I'm getting this same "dirty environment" error.  On the first boot into Windows it throws the error, if I say No it finishes fine.  I'd like to see some resolution too.

    Marshal Anson

    Tuesday, April 30, 2013 8:23 PM
  • So I found the following in LiteTouch.wsf

    		' Are we dirty?
    		If oEnvironment.Item("LTIDirty") = "TRUE" or (oEnvironment.Item("LTIDirtyOS") = "TRUE" and (not oUtility.Arguments.Exists("start"))) then
    			i = oShell.Popup("An existing in-progress deployment was found but is not in an expected state.  Would you like to ignore this in-progress deployment and start a new one?", 0, "Dirty Environment Found", 4+48)
    			If i = 6 then
    				QuickCleanup
    				oLogging.CreateEntry "Cleaned up a dirty deployment.", LogTypeInfo
    			Else
    				oLogging.CreateEntry "User chose to continue a dirty deployment.", LogTypeInfo
    			End if
    		End if

    There's a couple places in LiteTouch.wsf and LTIApply.wsf that set the LTIDirty and LTIDirtOs flags. It seems like they are set to TRUE as a default step in several places of the logic and then cleared back to FALSE when oUtility.Arguments.Exists("start") evaluates TRUE.

            If oUtility.Arguments.Exists("start") then
                ' Remove the LTIDirtyOS flag as we're getting into the new OS exactly how we expected
                oEnvironment.Item("LTIDirtyOS") = "FALSE"
    Or if a reboot is successful:
    ' Reboot if requested
    If (iRetVal = -2147021886) then
    	oEnvironment.Item("LTIDirty") = "FALSE"
    The latter occurs and LTIDirty gets cleared in my variables.DAT but LTIDirtyOS remains TRUE. I'm not finding any additional places in the scripts that clear that flag so obviously oUtility.Arguments.Exists("start") is still evaluating to FALSE for some reason.
    Tuesday, April 30, 2013 8:44 PM
  • I'm getting this same "dirty environment" error.  On the first boot into Windows it throws the error, if I say No it finishes fine.  I'd like to see some resolution too.

    Marshal Anson

    Marshal, Do you have any applications, packages, or drivers being installed as executables? Those seem to be the most common reasons for the Dirty Environment, as they cause an unexpected reboot of the computer during deployment. Here's a good thread with details, Dirty Environment found

    My case doesn't involve any of those...

    • Edited by Ian.Fuller Tuesday, April 30, 2013 9:05 PM added link to other thread
    Tuesday, April 30, 2013 9:02 PM
  • so obviously oUtility.Arguments.Exists("start") is still evaluating to FALSE for some reason.
    I still cannot figure out how this is evaluated or what it even means. Any help?
    Tuesday, April 30, 2013 9:05 PM
  • I'm getting this same "dirty environment" error.  On the first boot into Windows it throws the error, if I say No it finishes fine.  I'd like to see some resolution too.


    Marshal Anson


    Marshal, Do you have any applications, packages, or drivers being installed as executables? Those seem to be the most common reasons for the Dirty Environment, as they cause an unexpected reboot of the computer during deployment. My case doesn't involve any of those...
    I do, but I get the error at the first boot after the OS is installed, so no applications have installed yet.  I'm using MDT at four locations, all using the same task sequences and applications, but I'm only having the dirty environment in one location.

    Marshal Anson

    Tuesday, April 30, 2013 9:05 PM
  • I do, but I get the error at the first boot after the OS is installed, so no applications have installed yet.  I'm using MDT at four locations, all using the same task sequences and applications, but I'm only having the dirty environment in one location.

    Marshal Anson

    You mean to say you have 4 physical (or logical) locations each with their own deployment server running identical deployments to the local site?

    Is the destination hardware (ie, maybe different drivers being deployed) or application list different for that site compared to the others? Verify that the deployment at that site is identical to the other sites (use md5checksum on the files if you have to) to ensure no copying errors. Check the server and network configurations at those sites for possible differences. If you're deploying to identical hardware all from a single deployment server and only failing at one site, my guess is that you've got a network issue.

    Tuesday, April 30, 2013 9:14 PM
  • We have four locations each with their own physical server.  The hardware at each site is the same and so are the drivers.  The applications vary slightly, but again, the error shows before any apps are installed.

    The boot wim's have been updated separately when new drivers were added so the MD5 checksum fails.  The drivers that were added have all been the exact same drivers though.


    Marshal Anson

    Wednesday, May 01, 2013 1:00 PM
  • Try copying one of the working deployment shares to the site with the issue and see if you can get it to deploy there.

    Out of curiosity for my own issue though, how did you build and capture the WIM for the deployment with the issue?

    Wednesday, May 01, 2013 1:42 PM
  • I'll give that copy a try.  Thanks.

    Oh man, it's been awhile since I created the wim, if I remember right, I just unpacked a Win7 iso into a folder and added it as an OS then updated the deployment share to create the wim.  Otherwise, I installed Win7 on a pc then created a capture sequence on MDT and grabbed that image.  I honestly can't remember which of the two I did.


    Marshal Anson

    Wednesday, May 01, 2013 1:50 PM