none
Dirty Environment found

    Question

  • Hello, everybody! I have one question about MDT 2012 beta 2

    I install nvidia drivers version 285.62, i maked apllication and use quite install command setup.exe /s /noeula /nofinish include reboot,and what we are have:

    after reboot install process show this attention ->

    Dirty Environment found

    An existing ins deployment was found but is not in an expected state.would you like to ignore this in progress deployment and start a new one?

    What is is? This is mean what during installation application`s wa are can`t make reboot?right?

    Wednesday, December 07, 2011 3:03 PM

All replies

  • I am also having this issue with every OS I deploy with MDT 2012 beta 2. I have an application bundle with 12 programs that are installed followed by Office 2010. The dirty environment found message comes up between the last program in the application bundle and the start of Office 2010. I have deployed to machines with hard drives that were formatted with DBAN that had the same issue, so I am not sure what is going on here.
    • Proposed as answer by Anthony Ennas Thursday, November 14, 2013 7:18 PM
    Thursday, December 08, 2011 7:55 PM
  • When you reboot, are you booting into the MDT Boot Media (PE), or are you booting into the real, deployed OS?

    I've seen this message appears when you start the LiteTouch wizard from within PE, but there are existing traces of MDT on the hard drive from a previous MDT run that did not complete.

    If you've tried to carry over customizations from MDT 2010, their startup changed a bit to catch this condition.  In the "Real" OS deployment, MDT drops a script at c:\ named LTIBootStrap.vbs; this is the script that's triggered by the AutoAdminLogon or the RunSynchronousCommands entries in the unattended answer files.  It does little more than drop a shortcut into the All User's Startup folder to run LiteTouch.wsf, configure the system for AutoLogon, and clear the DirtyOS flag.

    If you're using MDT 2012 beta 2, you should have a look at the beta forum at connect.microsoft.com (from which you presumably downloaded MDT 2012 beta 2 in the first place) and look through the Feedback postings there to see if this has been identified as a bug.

    I'm not encountering this as a problem on mine, but then I'm not deploying Applications through the beta either.

    I did see in one of the Deployment blogs, about setting up a custom action in the Task Sequence to run between particular applications, to ensure MDT is set to resume after the reboot.  I can't seem to find it at the moment, but hopefully something in this might be helpful.

    Friday, December 09, 2011 5:15 AM
  • Nvidia drivers have been broken for a while... I tried to get in touch with them to no avail.

    More info here: http://social.technet.microsoft.com/Forums/en/mdt/thread/e9c83dac-03e1-47ad-8f6e-4df7b8e83089


    Another Sysadmin Blog: blog.physh.net Please remember to "mark as answer" if you find my contribution useful. Thanks.
    Tuesday, December 13, 2011 5:56 PM
  • I do not think its the Nvidia drivers as I am seeing the same issue. I am running Beta 2 after sysprep it asks me to login and after I do this Dirty Environtment Error is popping up. Any ideas?

    Saturday, January 21, 2012 12:39 AM
  • With MDT 2012 Beta 2 and later, we have logic in MDT to be able to detect when there wasn't a "clean" restart.  So that's what you are seeing - something didn't reboot properly, we detected it and presented the dialog.  If you say to continue, it will try, but all bets are off at that point.

    Task sequence steps can't initiate reboots themselves, as it causes the task sequence to fail in a very "unnatural" way.  Instead, you need to configure the step to suppress the reboot (not sure how to do this with the nVidia installation command line).  If you are using an application to install the nVidia package, you can set that application to reboot after it completes (without rebooting).  If you just have a "run command line" step, you can put a "Restart" step as the next one in the task sequence.

     

     


    Thanks, -Michael Niehaus Senior Program Manager, Microsoft Deployment Toolkit mniehaus@microsoft.com http://blogs.technet.com/mniehaus
    Saturday, January 21, 2012 5:17 AM
  • I'm having this same issue and I've ruled what I know out and I still see the Dirty Environment Popup which I have to click "NO" to. This does not happen when using a Physical Boot Disk.

    I was running the Client.xml sequence to backup, refresh the os, join domain etc.

    I delete this and created a new standard client task sequence and changed the customsettings.ini file to the most basic so I would manually walk through the deployment to rule out issues.

    Now it's only setup to refresh the OS, I manually put it in the workgroup, no backup, no user data, no applications, no command lines, etc.

    I'm manually connecting to the deployment share and running LiteTouch.wsf from the current operating system.

    This issue does NOT happen when using a physical boot disk

    The "Deployment Summary" results at the end are success with 0 errors and 0 warnings.

    As far as the Task Sequence steps doing a reboot I only see what was automatically in place out of the box when I created the NewRefresh Standard Client Task which are below

    -State Capture

    --Refresh only

    ---Restart computer

    and

    -Postinstall

    --Restartcomputer

    Is there something else that I can try here?  Also, is there a way, worst case, to eliminate this popup or auto select "NO" so it does not stop my task sequence and require manual interaction?

    CUSTOMSETTINGS.INI

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    SkipAppsOnUpgrade=YES
    SkipCapture=NO
    SkipAdminPassword=YES
    SkipProductKey=YES

    • Edited by Marshall1234 Wednesday, February 29, 2012 4:17 PM
    Wednesday, February 29, 2012 3:40 PM
  • This happens after Post Install Does a Restart at the end of the Post Install Folder.
    It restarts and comes up into windows logging in as administrator for the first time after I kicked off the LiteTouch.wsf.

    Next in the Task Sequence is State Restore though it does not get there as my first step is a command line to Lock the Computer

    So if I click on NO it immediatly Locks the computer per my cmd task. 

    That being said that is where the message appears.  Where it is being caused though and how I fix is the question.

    Wednesday, February 29, 2012 8:59 PM
  • We have identified an issue in MDT 2012 Beta 2 that can cause the MDT scripts to get into an infinite loop if the computer isn't restarted properly during a task sequence.  That should be addressed in MDT 2012 RC1, which is due very soon.

    -Michael


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

    Wednesday, February 29, 2012 9:02 PM
  • Thanks,

    I'm still having the same issues within a new setup using MDT 2012 RC1. 

    First off is it supported to perform a fully automated refresh deployment if connecting to the deployment share under windows xp and launching LiteTouch.wsf.  I assume so I just get this message once is logs in for the first time after sysprep completes and by selecting no if will finish.

    Below is from A-Z

    I downloaded RC1, installed on Win Svr 2008 Datacenter x64, installed MSXML and AIK.

    Created new deployment Share

    I imported a Hyper V Windows XPSP3 Thin image that I had previouslly captured with only Win Updates on it.

    I imported Intel WinPRO32 into the drivers folder.

    I created a Standard Client Task Sequence, put in product key, no admin password.

    Then deployed it to a physical laptop with an intel network driver.  I could repeat under a Hyper V though I would speculate the results would be the same as I don't see this when using a physical boot disk. 

    My CustomSettings.ini is below

    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    ScanStateArgs=/v:5 /o /c
    LoadStateArgs=/v:5 /c /lac /lae

    SkipAppsOnUpgrade=YES

    SkipCapture=YES

    SkipAdminPassword=YES
    SkipProductKey=YES
    SkipDeploymentType=YES
    DeploymentType=REFRESH
    SkipFinalSummary=YES
    FinishAction=RESTART

    SkipDomainMembership=YES
    JoinDomain=DomainName
    DomainAdmin=Administrator
    DomainAdminDomain=DomainName
    DomainAdminPassword=a_secure_password

    SkipUserData=Yes

    SkipTaskSequence=YES
    TaskSequenceID=Enterprise

    SkipComputerName=YES
    OSDComputerName=%ComputerName%

    SkipPackageDisplay=YES

    SkipLocaleSelection=YES
    UILanguage=en-US
    UserLocale=en-US
    KeyboardLocale=en-US

    SkipTimeZone=YES

    TimeZone=035

    TimeZoneName=Eastern Standard Time

    SkipApplications=YES

    UserID=Administrator
    UserDomain=DomainName
    UserPassword=P@ssw0rd

    _SMSTSORGNAME = Our Organization Name

    My Boot.ini I

    [Settings]

    Priority=Default

    DeployRoot=\\Server\DeploymentShare$

    UserID=domainadminaccount

    UserDomain=our domain

    UserPassword=password

    Friday, March 02, 2012 12:52 AM
  • Is executing LiteTouch.wsf while logged under Windows XP to perform a OS Refresh supported?

    If so what am I missing here?

    Best Regards,

    Saturday, March 03, 2012 12:25 AM
  • Has anyone else been able to do this with XP to XP refresh without receiving the error or received it and found out how to correct it?

    Tuesday, March 06, 2012 2:18 PM
  • Are there any updates for this?

    I get the error when deploying a 64 bit OS, but not 32 bit. I've gone over my Task Sequence, my unattend.xml, etc., and can't find any clues as to the cause.

    As someone else mentioned, it appears even after the built in machine restart during post install.

    Thursday, April 05, 2012 5:46 PM
  • 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

    Thursday, April 05, 2012 5:53 PM
  • I started a deployment to get you the logs and it didn't happen this time - for the first time. Weird.
    Thursday, April 05, 2012 7:32 PM
  • I discovered what the issue is in my case. It doesn't like it when I attempt to yo update MSXML.
    Thursday, April 05, 2012 9:56 PM
  • So this is old though I believe using HideShell=YES in customsettings.ini caused this problem to go away.

    I'm on RC1 and will upgrade to the full release

    Wednesday, April 25, 2012 7:33 PM
  • 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.

    I'm playing around with 2010 U1 generated WIMs and 2012 (released version) generated task sequences/scripts/etc... I too have run into both the "infinite loop" of which you spoke in an xp to 7 x86 refresh, as well as this error ("Dirty Environment Found") in a 7 to 7 x86 refresh.

    Would it be correct to say that all pre-2012 generated media/wims/etc are not compatible with 2012?

    I should add that using 2012 to capture new images and retesting with those got me to the new OS with other minor errors that may or may not have to do with 2012.


    • Edited by mdt_mishap Thursday, May 03, 2012 11:39 PM added
    Thursday, May 03, 2012 11:25 PM
  • This also has now hit my deployments after upgrading to MDT 2012. I've created a new deployment share, created all new .WIM files, stripped down my customsettings.ini file, and only done a bare Task Sequence and I still get the prompt after the Post-Install task. The variables LTIDirty=TRUE and LTIDirtyOS=TRUE are in various sections of my BDD.LOG file.

    This is really a frustrating issue. Can we just turn this new "feature" logic off? Otherwise, until MS acknowledges this is a real issue, we have to go back to MDT 2010.

    Mike

    Friday, May 04, 2012 12:31 PM
  • So I've also ran into this, and haven't been able to figure it out either.  What i've done is gone through the script files and looked for instances of LTIDirty, trying to identify exactly how it determines whether or not it's dirty.  I haven't been able to narrow it down, but I've found the lines in LiteTouch.wsf that check for those variables, and I'm just going to comment them out. 

    		' 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
    Obviously that's not a great solution, but it should work for now.  I'd still like to know what's causing this however.  I'm a big fan of MDT, and I really appreciate the tools Microsoft has created to make my life better, and so the last thing I want to do is neuter it, but until this gets figured out, I've got a job to do.

    Friday, May 04, 2012 4:31 PM
  • I'll have to do this as well, Great Triscut. I created a new MDT 2012 server, new shares, new OS imports, new everything... and I still get the "Dirty Environment Found" dialog boxes. Even if I add HIDESHELL=YES to my customsettings.ini, it still pops up during a deployment. Must be something I'm doing I guess. I sent several log files to Michael N. in hopes he can make some sense of it.

    I'm no closer to a solution, and I do thank MS for this great tool, but like you said, we still have a job to do. I'm re-installing 2010 on a separate box until this can get figured out.

    Friday, May 04, 2012 8:43 PM
  • I get the same message, every time, after upgrading to 2012.  Now my extremely lite touch install has gained one more step of interaction.  :(
    Tuesday, May 08, 2012 3:21 PM
  • Just confirming that commenting those lines out works fine.  Obviously you loose that functionality, but not a big deal overall, at least not for me.
    Tuesday, May 08, 2012 5:11 PM
  • Same thing is happening to me with 2012. It only seems to happen when I use the 32bit boot disk and push out one of my win7 x64 task sequences. If i used the 32bit disk to deploy win7 x86 or 64bit disk to deploy win7 x64 everything works fine.

    This message comes up after a reboot that I set in MDT on my adobe reader application.

    Any word from MS on a fix for this?

    Thursday, May 24, 2012 5:54 PM
  • The "dirty" warning will occur if your application installation initiates a reboot on its own - make sure you suppress that via the command line.

    For how to do that with Acrobat Reader, check the web for articles like http://blog.stealthpuppy.com/deployment/deploying-adobe-reader-x/ that describe how to customize their installer so that it doesn't initiate the reboot on its own.

    So far, we have not identified any scenarios where the "dirty" warning isn't working as designed - it's pointing out issues in your task sequence that accidentally worked before but shouldn't have.


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

    • Proposed as answer by cotton_gin1 Thursday, June 14, 2012 9:25 PM
    Thursday, May 24, 2012 6:21 PM
  • thanks Michael. On my test server I thought i had MDT set to do a reboot after acrobat reader installed. this was not the case. once i set it up for MDT to do the reboot (with the reboot the computer after installing this application selection) it works great.

    Thursday, May 24, 2012 8:41 PM
  • Hello Guys

    I am also in the same situation, I have customized Java, Flash, Citrix Receiver Enterprise and Adobe Reader X as per Adobe Instructions and have suppressed Reboot, however during the time of Application Installation window, I am keep getting Setup needs to restart your system,  It does not matter whether I choose Yes or NO,  it still reboot however after choosing Yes, I gets "Dirty environment Window" whereas If I choose NO I gets Deployment Successful window.

    Wednesday, June 06, 2012 4:43 PM
  • You *need* to find a way of suppressing that reboot otherwise this wont go away without some creative tweaking of the MDT scripts.

    Getting working application source/command lines is definitely the way to go.

    What command line are you using for Adobe Reader? Have you added a /reboot=reallysuppress ?

    You might also want to consider creating this as a new question as it's not directly related to the above questions.

    Wednesday, June 06, 2012 4:51 PM
  • Well I have customized Adobe reader X with "Adobe Customization Wizard X" and have suppressed the Reboot. ( I already have tested and tried to install the setup locally on my machine via running "Setup" file and it did not prompt for the reboot.) and the switch I have used with in MDT 2012 in command line setup /sALL

    Definitely there is something with in MDT scripting which is triggering  a reboot under State Restore-> After Install Applications, however I don't see "Restart System" listed there.

    Wednesday, June 06, 2012 7:53 PM
  • I have encountered this with running refresh scenarios on my new MDT 2012. Worked like a charm yesterday, now today refresh scenarios get stuck after running postinstall and trying to run the state restore task. No, I have not changed anything on the deployment since yesterday. It gets stuck at a blank desktop running about 30% on all cores, looping the logpath in bdd.log. It logs about Dirty enviroment just before, but since I am still using Arwidmarks final config script to clean up all after every new computer scenario, I am at a loss.

    I'm quite sure if there could be an added option for full format of disk in the Refreshscenario, (if you never want to save any sort of data) it would run fine. But that seems to be a quest for the wizard of oz to solve.

    Thursday, June 07, 2012 8:26 AM
  • Would love if you could do a format with the refresh option. Would be very handy for lectern PCs in my University, don’t have SCCM in yet so being able kick off a deployment remotely while in the existing OS would be sweet. Keep getting a dirty environment.

    Thursday, June 07, 2012 10:53 AM
  • Would love if you could do a format with the refresh option. Would be very handy for lectern PCs in my University, don’t have SCCM in yet so being able kick off a deployment remotely while in the existing OS would be sweet. Keep getting a dirty environment.

    We don't use SCCM at all for OS deployment. There are a couple of diffrent reasons, mainly this: easy to maintain just one deploymentpoint - mdt can deploy to multiple domains with ease and we have a LDAP that feeds the MDT sql so we can run it fully ZTI.

    However, as a University we have a few campus sites off the main location, but we have all our VLANs distributed to those points and can run OS deployment over fairly long geographical distances (like 400km :) with little or no performance loss. Being able to kickstart a New Computer scenario like a Refresh scenario, remotly, without having to dig into every script would be a dream. But I think I have a plan for it :]

    • Proposed as answer by non1ckname Monday, June 18, 2012 4:04 AM
    • Unproposed as answer by non1ckname Monday, June 18, 2012 4:04 AM
    Thursday, June 07, 2012 12:21 PM
  • Hi all,

    we had a similar problem, what i did was booted the machine of an XP cd deleted the partition, formatted the drive and restarted the computer, then ran the MDT wizard without this error appearing again. MDT sometimes doesnt seem to format the drive correclty this worked for us.

    thanks

    Monday, June 18, 2012 4:06 AM
  • Hi all.

    Apologies for dragging up a slightly old thread, but I am also having these issues, using MDT 2012 RTM.

    The 'Dirty' prompt ONLY appears when the deployment is started from within Windows, and is not an issue when the deployment is started from PXE. I therefore presume this cannot be down to an application reboot issue, as the same applications and task sequences are run from PXE as from within Windows.

    I hope this provides more info and a possible solution can be found!

    Many thanks.

    James

    Friday, July 13, 2012 9:35 AM
  • Hi all.

    Apologies for dragging up a slightly old thread, but I am also having these issues, using MDT 2012 RTM.

    The 'Dirty' prompt ONLY appears when the deployment is started from within Windows, and is not an issue when the deployment is started from PXE. I therefore presume this cannot be down to an application reboot issue, as the same applications and task sequences are run from PXE as from within Windows.

    I hope this provides more info and a possible solution can be found!

    Many thanks.

    James


    I can confirm that all my tests that have been subject to this issue have been started from within windows and that only reboot that occurs is done by MDT.
    Friday, July 13, 2012 5:47 PM
  • I have the exact same problem for 2 weeks, disabling HIDESHELL=YES solved my issue... such a pity I love this functionnality.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Wednesday, July 18, 2012 9:10 AM
  • Hi all.

    Apologies for dragging up a slightly old thread, but I am also having these issues, using MDT 2012 RTM.

    The 'Dirty' prompt ONLY appears when the deployment is started from within Windows, and is not an issue when the deployment is started from PXE. I therefore presume this cannot be down to an application reboot issue, as the same applications and task sequences are run from PXE as from within Windows.

    I hope this provides more info and a possible solution can be found!

    Many thanks.

    James


    I can confirm that all my tests that have been subject to this issue have been started from within windows and that only reboot that occurs is done by MDT.

    Same for us.
    Thursday, August 02, 2012 12:45 AM
  • Hi Great,

    Above tweak actually worked for me. Now I am not getting this pop up.

    Thanks

    Rakesh


    Rakesh Sahoo

    Friday, September 21, 2012 11:34 AM
  • I had the same issue and tracked it to the citrix client install.  I posted here: http://social.technet.microsoft.com/Forums/en-US/mdt/thread/8ee51ce2-3e19-4f2f-9a1a-0833893d1c9e but noone else ever responded if they have seen the same behaviour.  I have removed HIDESHELL=YES from my CS to prevent this issue.
    Friday, September 21, 2012 2:04 PM
  • Sorry for another ditto on this thread, but removing HIDESHELL=YES fixed this for us.  We're using MDT 2012 Update 1.

    Michael, I can provide before and after logs if it would be useful. 

    • Edited by kobeckman Tuesday, October 09, 2012 2:34 PM
    Tuesday, October 09, 2012 2:32 PM
  • Just to add another piece of information if this helps, we only see this issue when deploying Windows XP. And this is regardless of having HIDESHELL=YES there or not. Windows 7 deploys cleanly.

    And contrary to my earlier post, with HIDESHELL=NO when deploying Windows XP (kicking it off from within Windows) it returns the dirty environment error, but if you select 'No' it completes fine. Deploying Windows 7 from within Windows (be it Windows XP or Windows 7) however works fine. So it seems it only errors if the OS you are deploying is XP. Also with HIDESHELL=YES, Windows XP fails regardless of whether it is started from within Windows or from PXE, and Windows 7 works fine either way.

    James

    Wednesday, October 24, 2012 10:08 AM
  • Is there good log to find out which program is causing my issue?  I can see how a reboot would do this but am having an issue determining which program is causing the out of sync reboot.
    Tuesday, January 08, 2013 9:33 PM
  •  

    HIDESHELL=NO

    Does resolve the issue, but it does not address the cause. I believe that the use of PUSHD and POPD to change the current working directory is what was triggering it in my environment. 

    • Edited by SysEngMattP Friday, February 08, 2013 8:29 PM
    Friday, February 08, 2013 8:23 PM
  • This is the exact same behavior we are seeing (only with Windows XP). Doesn't matter if "HIDESHELL=YES or NO".

    Is there any way to surpress this message? We are using 'PSEXEC' to remotely kickoff re-images and the pain point is when the "Dirty..." message appears it halts the install.

    ZT

    Friday, May 10, 2013 1:07 PM
  • Not to beat a dead horse - but I am running into this still using MDT 2012 U1 (6.1.2373.0). 

    Hitting this issue just after Standard Server Class Refresh Task Sequence initiated reboot just before State Restore Phase. 

    Occurring on both 2008R2 -> 2008R2 and 2012->2012 Refreshes. I'm not doing anything special. I'm using ESX VMWare to perform my tests.

    Monday, June 10, 2013 8:31 PM
  • I tried removing all references to the dirty environment logic in LiteTouch.wsf and LTIApply.wsf and I was able to get past this prompt - however, I now am running into an issue similar to http://social.technet.microsoft.com/Forums/en-US/mdt/thread/79e81687-43b2-48fd-bbaa-f33c49454a94/
    Wednesday, June 12, 2013 8:33 PM
  • We have MDT 2012 (not beta or RC, the real release -Deployment Workbench=v6.1.2373.0) and get these Dirty environment errors installing Citrix Xentools 6.2 for XenServer.  I have their switches as such:  msiexec.exe /i installwizard.msi /quiet /norestart      At the end of their install there is a Restart Now/Restart Later prompt.    I ignore it and then on the Dirty msg, I click to resume running task sequence.  AFAIK, Citrix isn't going to rewrite their installer to get around this.   I don't have HIDESHELL at all in my customsettings.ini, in fact that would seem to be a good thing per this forum post: http://social.technet.microsoft.com/Forums/en-US/8ee51ce2-3e19-4f2f-9a1a-0833893d1c9e/hideshellyes-causes-dirty-environment-found-message-when-windows-boots-for-the-first-time  (but ignore the product, I am NOT dealing with their online plugin)

    So is commenting out the Dirty check logic the only way around this ?



    • Edited by dilbert2013 Thursday, September 26, 2013 3:12 PM
    Thursday, September 26, 2013 3:05 PM
  • Try /qn /reboot=reallysuppress instead of /quiet /norestart.

    My Blog: DeployXP [Under Construction]| Viadeo: Mathieu Ait Azzouzene | Linkedin: Mathieu Ait Azzouzene

    Thursday, September 26, 2013 4:37 PM