What is the best way to deploy?

All Replies

• Tuesday, November 20, 2012 12:56 AM

   

   
  

  1

  Firstly, congratulations on your successful PXE booting experience.  You have the hard part down!  Now, regarding the way you are using MDT, I don't think you are using it incorrectly.  What you are seeing is some of the template configurations for a sysprep and capture task sequence.  You have the option of using MDT however you please.  Some people prefer "thick" images with more configurations and apps preinstalled, and others prefer "thin" images with basically a vanilla install of Windows, with applications and configurations placed in the task sequencer after the fact.  I prefer "thin" images, so I can change configurations on-the-fly without recapturing the image over and over again.  With that theory, you should only be recapturing the image when service packs are released.  Does that make sense?

  You are on the right track.  You are correct that recapturing often seems like a lot of work.  You should not have to recapture images that often.  With thick images you would wind up having to do it all the time, and that stinks.

  Welcome to the MDT world, and have fun!

  • Marked As Answer by Dead Cell Tuesday, November 20, 2012 3:13 PM
  •  
  • Reply
  • Quote

   
• Tuesday, November 20, 2012 8:41 AM

   

   
  

  1

  the down side to having such a thin image is if you have to install that image to a lot of computers.
  and they all need updates a lot of deployment time will be spend on just downloading and installing updates for every computer which might not be so long now but wait till there are some more windows updates.
  

  • Marked As Answer by Dead Cell Tuesday, November 20, 2012 3:13 PM
  •  
  • Reply
  • Quote

   
• Tuesday, November 20, 2012 3:51 PM

   

   
  

  0

  Thanks Curtis and Stefan for taking the time to reply to my thread and for your warm welcome. Much appreciated. Bare with me here as I try to make sense and get across my thought's the best I can.

  What you both say makes sense and I'm very pleased to hear that I'm on the right track but understand that capturing an image is not a wrong way, just different.

  I guess theres an argument for both capturing an image via Sysrep and doing a vanilla install including Apps and Drivers etc, I guess it all boils down to the sort of setup and user needs a company has. 

  Stefan, what you explained is exactly the sort of problem we encounter in my firm. After deploying an image to a new machine, we then either have to manually install 130 Windows updates or leave the machine and let our automation maintenance software take care of it (I personally just update it straight away as otherwise some core apps don't work as well without the updates, NetFramework 4 anyone?

  But to get around this, I guess it would mean that the person in charge of this would need to gather the source files for all these updates and then add it to the Deployment Share/Task Sequence? And going forward, would need to maintain this?

  My next question would then be, if I go down the route of putting together an image on a reference machine with all updates, drivers and windows updates etc, use sysrep to capture it, will I then not find myself in the same situation when 6 months down the line, Microsoft have released another 130 updates? I assume I would then need to use the reference machine again to create another image, update windows with the latest and greatest and then capture it before adding to my Deployment Share?

  If so then a clean install without capturing an image sounds like the best method to me.

  Also how would capturing an image on a reference computer work for all the various types of machines we have as far as drivers are concernced? Would I need to capture an image for each type of machine we use in the firm and end up with say 15 captured images and then when hitting F12, select the appropriate one for the machine in question?

  Let's say I continue the way I am (and this is how my firm operates), and put together a Deployment Share which includes OS Files, Drivers for all the machines in my firm, and all the essential apps including custom ones that we use.  Then Six months laters, Service Pack 1 is released for Windows 8.

  Can I not simply get the sources files for Service Pack 1 and add it to the Components folder in Workbench? Will that then simply install Windows 8 including all drivers, apps etc and then also install the Service Pack once Windows gets to the Desktop?

  Apologies if my message seems all over the place and for all the extra questions, but what I'm really trying to do here is find out the pro's and con's of each method.

  Also is this TechNet site the best place to ask future questions regarding Answer Files and making the whole installation process completely unattended (silent install) ?  This really is the next big step for me and I definitely must crack this as soon as possible.

  If you know of any other friendly tech sites that can better deal with questions relating to silent installation, then please do let me know.

  Once again many thanks for your kind help with this.

  Best regards.

  • Edited by Dead Cell Tuesday, November 20, 2012 4:11 PM
  •  
  • Reply
  • Quote

   
• Tuesday, November 20, 2012 9:52 PM

   

   
  

  1

  I can tell you what I've done over the years to keep from having lots of updates installed with each deployment.

  I built a base image of Windows in audit mode. I check for updates until there's nothing left to install (not including drivers). I then capture my audit image (that way I always have a recent base image). I'll then run sysprep to generalize the image and I capture that. That is what I import into MDT for deployment.

  A few months go by, there have been lots of updates to the OS so I load up my "audit" image and update it. Then the same process as above, except this time all I do is overwrite the wim file in "\Operating Systems\" folder, no need to re-import.

  • Reply
  • Quote

   
• Tuesday, November 20, 2012 10:29 PM

   

   
  

  0

  Dan, thanks for your input but lets see if I understand what you are saying:

  You built a base (clean?) image of Windows check for updates and then capture it.

  Once more updates are available you then use that same image you created above but then update it with further windows updates before recapturing the image and overwriting the original one above?

  Or have I misunderstood?

  I'm looking in to what you mean by base image and audit image. Thanks

  PS: I'm now getting all confused with unattend.xml in WSIM and the actual options in MDT Workbench for a silent install!

  Do I need to use WSIM to create an answer file or can all this be done in the Workbench?

  • Reply
  • Quote

   
• Tuesday, November 20, 2012 11:00 PM

   

   
  

  1

  In general you don't need to use WSIM to edit your unattend.xml that MDT uses. I do edit this file for some additional configuration that I want to apply, however this is by no means necessary in order to get an unattended windows installation working.

  Audit mode is a special mode that Windows can run in that allows you to skip past the Windows Welcome/Out of box experience upon first boot when you manually install Windows from dvd. System builders might use this, enterprise users often dont.

  I like to automate my entire build process for example, and for that reason I don't keep multiple images for different purposes. I use a normal mdt task sequence, which also allows you to capture the OS that you deploy with that task sequence. After that image is captured I import it into the workbench and make a new task sequence that points to that newly imported image. That's the task sequence that I would use for actual deployment. The task sequence I used to build the OS, i generally mark it as hidden (properties of the task sequence) untill I need it again to create a new image.

  Images imported in MDT are stored in \Operating Systems\{foldername}. Images captured with MDT are stored in \Captures.

  Lets say I have the original windows setup files from disk. I import these in the folder [Windows 7 Source files]

  I create a default standard client task sequence, that installs Windows, runs Windows updates (if applicable installs applications too) and then captures the image to \Captures\{tasksequenceid}.wim (that's the default name).

  Then I'd import that new .wim file to for example [Windows 7 Reference Image]. Create a new standard client task sequence that deploys that specific image.

  Now if I ever need build a new reference image, I'd execute the first task sequence I created, and move the {tasksquenceid}.wim file to \Operating Systems\Windows 7 Reference Image\ and overwrite the file in there.

  Kind regards,

  Stephan Schwarz

  ---

  If one of these posts answered your question or issue, please click on "Mark as answer".
  
  My Blog | Twitter: @Schwarz_Stephan | MCTS, MCITP, MCSA, MCC-2011.
  How to configure Windows RE/OEM Recovery Partition with MDT
  How to configure Windows RE/OEM Recovery Partition with MDT 2012 Update 1

  
  

  • Edited by Stephan Schwarz Tuesday, November 20, 2012 11:00 PM
  • Marked As Answer by Dead Cell Tuesday, November 20, 2012 11:10 PM
  • Unmarked As Answer by Dead Cell Wednesday, November 21, 2012 12:38 AM
  • Marked As Answer by Dead Cell Wednesday, November 21, 2012 12:53 AM
  •  
  • Reply
  • Quote

   
• Wednesday, November 21, 2012 12:19 AM

   

   
  

  0

  Stephan thanks for the detailed response.

  So I take it you mean to say that WISM isn't needed to make changes to the unattended.xml file and instead this can all be done directly within MDT Workbench? In MDT if I expand Deployment Shares, and then right click on the name of my project, select Properties, in the Rules tab, I have the following:

  [Settings]
  Priority=Default
  Properties=MyCustomProperty
  
  [Default]
  OSInstall=Y
  SkipCapture=NO
  SkipAdminPassword=YES
  SkipProductKey=YES
  SkipComputerBackup=NO
  SkipBitLocker=NO
  EventService=http://SEAN:9800

  Am I right in assuming that I can add more lines to the above and in a way, customise the entire silent install process to my liking?

  This info I believe is gathered from the CustomSettings.ini file but how does this differ from the unattend.xml file?

  Also, if I learn some of the queries (if that's the correct term) that are usually used in an unattend.xml file and add them to the CustomSettings.ini, will it still work?

  These are the windows I'm seeing during deployment which I would like to make auto answered.
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.31.09.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.31.57.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.34.03.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.34.24.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.34.46.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.35.36.png
  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-21%20at%2000.36.11.png

  I must say I'm very interested in how you work and it really appeals to me but I do have a few questions which I hope you can kindly explain for me.
  

  "I use a normal mdt task sequence, which also allows you to capture the OS that you deploy with that task sequence." What is a normal mdt task sequence? And when you say this task sequence allows you to capture the OS, do you mean you have to use a reference machine and use SysPrep to actually capture the image?

  "The task sequence I used to build the OS, i generally mark it as hidden (properties of the task sequence) untill I need it again to create a new image"  This is what you did at the very beginning and it simply contains the wim file of the OS? So when you need to create another image you simply start from this?

  If I understood this correctly then it means each time you want to create a new image, you have to use a reference machine to deploy to, update windows etc and then recapture?

  Or are you saying that you only capture a 'generalised' image once and then always use that and this is the one you keep hidden?

  Thanks

  
  

  
  
  
  

  • Edited by Dead Cell Wednesday, November 21, 2012 12:51 AM
  •  
  • Reply
  • Quote

   
• Wednesday, November 21, 2012 1:03 AM

   

   
  

  1

  You're correct, you can add entries to the customsetting.ini (this is the rules tab of the properties). For example here's a couple of entries I use myself as well.

  The ; character means that it's a comment, and will not be read by the gather script.

  [Default]
  ;Deployment Share Settings
  _SMSTSORGNAME=MDT2012 Deployment Server
  SLShare=%DeployRoot%\Logs\Static
  SLShareDynamicLogging=%DeployRoot%\Logs\Dynamic\%ComputerName%
  FinishAction=Reboot

  PrepareWinRE=NO
  

  JoinDomain=domain.local
  MachineObjectOU=OU=Computers,OU=MyOU,DC=domain,DC=local
  DomainAdmin=DomainJoin
  DomainAdminDomain=domain.local
  DomainAdminPassword=someplaintextpassword

  ; Settings below configure the unattend.xml with Registered Owner, Organization and HomePage (if I want to change this afterwards compared to the settings that I filled in during task sequence creation)

  FullName=Administrator
  OrgName=My Company Name
  Home_Page=http://www.bing.com/?scope=web&setmkt=en-US

  ; Preselect a specific task sequence when I start up the mdt wizard

  TaskSequenceID=TS-001

  SkipAppsOnUpgrade=YES
  SkipCapture=YES
  SkipAdminPassword=YES
  SkipProductKey=YES
  SkipApplications=NO
  SkipBitLocker=YES
  SkipBitLockerDetails=YES
  SkipTaskSequence=NO
  SkipComputerBackup=YES
  SkipComputerName=NO
  SkipDeploymentType=NO
  SkipDomainMembership=NO
  SkipFinalSummary=NO
  SkipLocaleSelection=YES
  SkipPackageDisplay=YES
  SkipSummary=YES
  SkipTimeZone=YES
  ;SkipUserData=YES
  SkipRoles=YES

  KeyboardLocale=en-US
  UILanguage=en-US
  UserLocale=en-US
  TimeZoneName=W. Europe Standard Time
  TimeZone=110

  =======

  The difference between customsettings.ini and unattend.xml is, is that the unattend.xml file actually is more like a template. The mdt scripts will dynamically update the unattend.xml with the appropriate values (for example it sees that I have a specific timezone, and updates the unattend.xml so that when windows is installed, this is automatically configured for me).

  What I mean with a "normal" task sequence. Is the following: MDT provides several different kind of task sequence templates that you can choose from, the one that's normally selected when you create a new TS, is "Standard Client Task Sequence". This task sequence is like an "all-in-one" task sequence template that is capable of deploying an OS, but also to capture it. I always use a virtual platform as my "reference machine" on which I execute the the task sequence which in turn installs Windows and then executes any tasks that I need it to, and then finally automatically syspreps the image and captures it to the deploymentshare\captures folder. The upside of virtual machines is that you do not need to import drivers for windows to work, and you have a very tidy driver-less windows image (this is desired, since the drivers that you will need for the actual deployment to the target machines will get only the drivers that they need).

  The second part you understood it correctly, I personally actually use multiple deployment shares, but I wanted to save you from this configuration untill you're more familiar with MDT. If I were to only have 1 deployment share, that I use to both create my reference image with, but also deploy my reference image with to the target computers. I would not want people to see task sequences they should not execute, hence I would choose to "disable the task sequence"/"hide this task sequence in the deployment wizard" from the task sequence properties. I use at least 2 deployment shares, one that contains my task sequences to build the various reference images for different OS's and another deployment share that will actually be used to deploy the images onto the target machines.

  Anyway, I keep the task sequences to create the reference images. However I do not keep copies of the reference images itself, other then the one that I import into MDT to actually deploy Windows with. Whenever I need a new reference image, since for example I want to add more Windows Updates to the image I will start up the task sequence I use for deploying and capturing the image.

  I do not use a captured image in order for further customization, because this results in undocumented procedures. I rely on the full automation of MDT from start till finish to build me a new reference image, so that I always know exactly what steps have been executed during this process.

  Some tips: I suggest to disable the task sequence step in the [State Restore] section that runs the "Apply local GPO Package". This is a security baseline local gpo defined by Microsoft, however I do not want these kind of settings branded in my reference image, I rather configure these kind of settings when I deploy them to a target machine.

  Don't skip the capture page if you want to use a task sequence to capture an image with. Alternatively you can add a couple of variables to the task sequence you'd use to build your reference image with as following.

  Task sequence properties > task sequence

  At the very top, add 3 "add | general | set task sequence variable" tasks

  TS Variable |                           Value

  DoCapture |                           Yes

  BackupFile  |                           Install.wim

  ComputerBackupLocation  |   %DeployRoot%\Captures 

  This will ensure that an image is captured (sysprep will be executed automatically) even if you configure the SkipCapture=YES

  I hope this all makes sense.

  Kind regards,

  Stephan Schwarz

  ---

  If one of these posts answered your question or issue, please click on "Mark as answer".
  
  My Blog | Twitter: @Schwarz_Stephan | MCTS, MCITP, MCSA, MCC-2011.
  How to configure Windows RE/OEM Recovery Partition with MDT
  How to configure Windows RE/OEM Recovery Partition with MDT 2012 Update 1

  
  
  
  

  • Edited by Stephan Schwarz Wednesday, November 21, 2012 1:06 AM
  • Marked As Answer by Dead Cell Wednesday, November 21, 2012 1:13 AM
  •  
  • Reply
  • Quote

   
• Wednesday, November 21, 2012 1:27 AM

   

   
  

  0

  Stephan you are clearly the guru of MDT it seems and once again I can't thank you enough for your time.

  Most of what you said makes sense but I think it will be better if I start with a fresh pair of eyes tomorrow.

  Can you please tell me if any of the Microsoft certifications cover MDT in good detail or are there any thorough walkthroughs/guides online that will help me further?

  I'll be honest, I think I've bitten off more than I can chew here as I've never really done anything like this before so it would be best for me to actually understand MDT properly. Of course the more time I spend playing around with it the more I will learn, I feel I have already learnt a lot from yourself and the other good chaps.

  So far and as mentioned in my first post, I have a VMware running Server 2008 R2 with ADDS, DNS, WDS and WAIK/MDT 2012 installed and all configured properly. They are all talking to each other and I'm getting no errors in the logs.

  I have added the wim file to the Operating Systems folder in the Workbench, and configured as per the instructions provided in this website here but I didn't follow all of it, I left out the sample files and many other steps which I was told to skip by my colleague. The aim was to be able to F12 a target machine and install Windows 8 via WDS simple as that. I have managed it and now need to automate the whole process so I have a lot of work to do as far as automation is concerned ie learn all the scripts.

  Cheers for all your help :D

  PS: without VMware I think I'd have given up as it's so easy to just run everything on one machine rather than mess around with an actual target machine. 

  • Edited by Dead Cell Wednesday, November 21, 2012 1:30 AM
  •  
  • Reply
  • Quote

   
• Wednesday, November 21, 2012 3:06 PM

   

   
  

  1

  Sure I'll explain further.

  For example with Windows 7, I installed it on a computer that represented the majority of our computers. At the welcome screen I pressed Ctrl + Shift + F3 to put the system in Audit mode. From this point I made sure Windows was up to date and did any little tweaks that I needed ALL our computers to have. At this point I'd shutdown the machine and boot to a Windows PE flash drive. I'd capture the system in this state so that in the future I could make updates, because remember once you run sysprep and generalize the next time it boots it'll act like a new computer going through the welcome screen, etc.

  Putting the Audit image aside, I then boot the computer and open a command prompt (be sure to run as administrator). I run sysprep with /generalize /oobe /shutdown so I can seal the image. The sysprepped image is the one you import into MDT for deployment.

  Let's say a few months go by, you can't load up the image you sealed, that's where saving your image in audit mode comes in handy. You reload the audit mode image and run your updates, possibly make any new tweaks you want all your computers to have. Then of course do the same thing as before and backup this updated image while in audit mode.

  To make the process easy while booted to Windows PE, I made some batch files:

  CAUDIT.BAT:

  @echo off
  diskpart /s capdisk.txt
  net use M: \\SERVER\Share /user:Domain\User
  Dism /Capture-Image /ImageFile:W:\WIN7_64_AUDIT.wim /CaptureDir:W:\ /Name:"Windows 7 Enterprise" /Compress:max
  move W:\WIN7_64_AUDIT.wim m:\

  Here's my capdisk.txt script:

  select disk 0
  select partition=1
  assign letter="R"
  select partition=2
  assign letter="S"
  select partition=3
  assign letter="W"
  exit

  Capturing my sealed image uses the same script, the only difference is a different file name. I then take the .wim file of the sealed image (it would have been the one I imported into MDT for deployment) and replace the WIM file in MDT. It works fine until there's a service pack, then you'll probably need to rebuild the catalog file, but you can do that in MDT by editing the unattend.xml

  I hope this isn't too much information.

  
  

  • Edited by Dan_Vega Wednesday, November 21, 2012 3:07 PM
  •  
  • Reply
  • Quote

   
• Sunday, November 25, 2012 5:03 PM

   

   
  

  0

  Dan thanks very much for explaining in more detail and yes it does make sense.

  In the mean time I need some help explaining these errors that I'm getting after having made some changes to the CustomSettings.ini file via the Rules tab in MDT.

  It installes Windows 8 on a custom VM but at the end if gives the error that can be seen in the first link below.
  It does not install Office 2013.
  It does not add the machine to the domain and so I am unable to see it in AD under Virtual machine.
  Please see the last image for a snapshot of my AD window.

  Please note that I'm not deploying by using a captured image, simply added the Windows 8 WIM, and the Office 2013 Setup files and doing it that way.
  Thanks

  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-22%20at%2001.10.19.png

  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-25%20at%2016.51.12.png

  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-25%20at%2016.50.10.png

  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-25%20at%2016.49.31.png

  http://dl.dropbox.com/u/81568202/Screen%20Shot%202012-11-25%20at%2016.59.03.png
  

  EDIT: Sorry folks, I realised what I've done wrong. I forgot to add the Application GUID in to the CustomSettings.ini

  I'm re-deploying again and will see what happens.

  Thanks

  • Edited by Dead Cell Sunday, November 25, 2012 8:34 PM
  •  
  • Reply
  • Quote

   
• Monday, November 26, 2012 2:50 PM

   

   
  

  1

  Well I can say your switch for office is probably not what you're trying to do. That won't install office, it'll just launch the customization tool, so remove the "/admin" switch. Another thing I can recommend is unless your MDT server's machine name has been registered with your DNS server, replace the machine name with the IP address. Also make sure that the account you are using to join the machine to the domain has the rights to do so.

  Here's an example of my custom settings, with certain info changed for protection:

  [Settings]
  Priority=Default
  Properties=MyCustomProperty

  [Default]
  PrepareWinRE=YES
  _SMSTSOrgName= COMPUTER DUDE <- The name you want to display
  OSInstall=Y
  ScanStateArgs=/v:5 /o /c /ue:*\administrator /localonly
  LoadStateArgs=/v:5 /c /lac /ue:*\administrator
  SkipAppsOnUpgrade=YES
  SkipCapture=YES
  SkipAdminPassword=YES
  SkipProductKey=YES
  SkipBitLocker=YES
  SkipBDDWelcome=NO
  SkipLocaleSelection=YES
  SkipDeploymentType=NO
  SkipSummary=YES
  KeyboardLocale=en-US
  UserLocale=en-US
  UILanguage=en-US
  SkipTimeZone=YES
  TimeZoneName=Central Standard Time
  DeployRoot=\\111.11.11.151\DeploymentShare$
  SkipUserData=NO
  UDShare=\\111.11.11.151\MigData$
  UDDir=%OSDComputerName%
  UserDataLocation=NETWORK
  SkipComputerBackup=YES
  ComputerBackupLocation=NONE
  BackupShare=\\111.11.11.151\Backup$
  BackupDir=%OSDComputerName%
  SLShare=\\111.11.11.151\Logs$
  SLShareDynamicLogging=\\111.11.11.151\Logs$
  UserDomain= DOMAIN
  UserID= Account <- Account with access rights to the deployment share
  SkipDomainMembership
  JoinDomain= DOMAIN NAME <- Domain you joining the machine to
  DomainAdmin= DOMAIN ACCOUNT <- Must have the rights to add computer accounts
  DomainAdminDomain= DOMAIN <- The domain the above account belongs to
  DomainAdminPassword= PASSWORD <- Password for the above account

  The comments with "<-" are for you, don't add that to your custom settings file.

  • Reply
  • Quote

   
• Wednesday, November 28, 2012 8:55 PM

   

   
  

  0

  Originally I just suggested service packs as integrated into an image.  However, my practice is to include .Net frameworks, as well as Windows updates, and any IE upgrades we have undergone.  This really limits the updates that MDT or SCCM have to accomplish.  Like you have already heard from some other members, I would suggest that you don't implement too many updates after-the-fact, and since these are probably across-the-board updates that need to be applied, there is not really any reason not to have them included in the actual image.

  In the case when a service pack is realeased, simply deploy your vanilla image to a virtual machine, run the SP release, then any other updates you want, then recapture.  This is really a good and straight-forward practice once you get the hang of it.

  • Reply
  • Quote