Unanswered MDT 2012 With Pin to restrict deploy list?

  • Thursday, December 13, 2012 11:19 PM
     
     

    Hello All,

    We just upgraded from MDT 2010 --> 2012 and I previously had a PIN set-up to restrict certain departments and their imaging.  I followed something similar to this guide below in order to do this.

    http://deploymentbunny.com/2011/01/26/password-or-pin-code-protect-mdt-2010-litetouch/

    Since upgrading I am having some Wierd issues.  The Pin appears to work, but with some models we are imaging (dells) we enter the PIN and our installed immediately reboots.  Other machines are just fine and cause no issues.  Any ideas as to what could be going on??

    Joe

All Replies

  • Friday, December 14, 2012 12:29 AM
     
     

    It could be that the rebooting models are not catered for by the deployment.

    For example, one Model is targeted by the wizard and customsettings.ini so it gets task sequence A. But another model has no task sequence assigned so the wizard has no work to do (and ends with a reboot).


    Blog: http://scriptimus.wordpress.com

  • Friday, December 14, 2012 12:56 PM
     
     

    Andrew,

    I guess that is possible, but in our set-up, when you enter your pin you are then presented with what tasks you can perform.  There is normally a default one that allows users to install Windows 7 64-bit which they are not even being prompted for, it just reboots.

    I guess I am wondering if there is a better way to manage this other than the pin example I saw for MDT 2010.  Right now since I didn't set up MDT 2010 (I just did the upgrade) I am inclined to remove the PIN, even if that means that different departments will have access to all images.  It isn't ideal but I am not sure where else to start looking at this point.

    Joe

  • Friday, December 14, 2012 5:55 PM
     
     

    I suggest making a copy of the DeploymentShare to troubleshoot this. You wont need to copy all your OS apps and drivers as you're only testing the wizard. Just to see if you get to the deployment. In that non-production share, remove the pin pane and test it on a couple machines.

    Please post the exact scenarios where it fails so we can use some logic to reason it out.


    Blog: http://scriptimus.wordpress.com

  • Friday, December 14, 2012 6:27 PM
     
     

    Andrew,

    Thanks for the reply.  I am wondering how I go about copying the deployement share?  Am I doing this from within the deployment workbench, or are you talking the physical directories?

    Joe 

  • Friday, December 14, 2012 6:53 PM
     
     

    You can just do a file copy. Once there, you can share the folder and open it with deployment workbench.

    You will then need to update the bootstrap.ini and the path. Do this by right clicking the deployment share in deployment workbench and update the network unc and local paths.

    Finally, update the share to create new boot wims.

    You can do this on the same server or elsewhere,  whatever suits you.

    /Andrew


    Blog: http://scriptimus.wordpress.com

  • Friday, December 14, 2012 8:00 PM
     
     

    Andrew,

    We are a VMware shop so I just built another server for testing and installed MDT 2012.  I copied the share (about 30GB) and followed the steps you outlined to set-up the new server.  I see in my "RULES"  (by the bootstrap.ini setting) list a whole bunch of references to SQL and I know there is a DB associated with the installation.  I assume I need to clone my Prod DB and change all references like the one listed below to my new database instance?  Anything else that you would suggest before I start diving in and making changes?

    Joe

    [CSettings]
    SQLServer=server.domain.edu  *CHANGE THIS REFERENCE IN ALL OTHER TABLES*
    Database=wds
    DBID=username
    DBPWD=password
    Netlib=DBMSSOCN
    Table=ComputerSettings
    Parameters=UUID, AssetTag, SerialNumber, MacAddress
    ParameterCondition=OR


    • Edited by JoeUww Friday, December 14, 2012 8:02 PM
    •  
  • Saturday, December 15, 2012 10:59 AM
     
     

    I wasn't aware you were using the DB. This creates a little more work. I'm also starting to think that the problem could lie there.

    For the purpose of testing the wizard, try clearing out the DB and testing the wizard without it. This will (Dis/)proove that the issue is wizard related.


    Blog: http://scriptimus.wordpress.com

  • Monday, December 17, 2012 10:41 PM
     
     

    Andrew,

    Here is where I stand as of Monday 12/17.  I removed the PIN and the DB from my DEV server and tested, I still get the reboot after requesting the PIN.  Next I went and formatted the HD of the machine I was trying to image, then booted from my WDS server with MDT and SUCCESS, it imaged.  

    In looking a bit more at the forums, it seems this is an issue with the system recognizing and OS already on the HD and then refusing to install.  How can I get my workflow to ignore the existing OS and run the installation?

    Joe