MDT Resources
-
Does anyone know of any resources that explain the inner-workings of MDT? I'm just about at my wit's end trying to tweak our build and deploy process.
Basically here are the elements that I'm trying to get to work together:
- MDT BUILD W10 IMAGE - Settings
-- MDT to install W10 with updates as authorized by our in-house WSUS
-- MDT to install certain free software and (VLC, foxit reader, citrix plugins)
-- Basic settings for domain join set in unattend.xml via the MDT console / SIM - MDT BUILD W10 IMAGE - RUN BUILD
-- Boot VM to MDT using iso
-- Launch task sequence
-- Select option to "Prepare to capture the machine" (this puts MDT generated unattend.xml files in both %windir%\Panther and %windir%\System32\Sysprep)
-- Finalize / sysprep image by going into c:\windows\system32\sysprep and executing
--- sysprep.exe /oobe /generalize /shutdown /unattend:unattend.xml - CAPTURE IMAGE TO FOG
--Nothing to explain here.... - DEPLOY IMAGE FROM FOG (with custom scripting)
-- Based on instructions and examples
--- https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog
--- https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
--- I'm setting timezone and ou based on our naming convention so that we can still image stuff for other sites here at the main office
When trying to deploy I keep getting errors about LTIBootstrap.vbs
If I take the references to LTIBootstrap out of the unattend file then the build process doesn't work
With almost everything working (deploy with auto-rename and auto domain-join) , MDT's auto admin logon settings don't get removed like they're supposed to...Does anyone know what purposes are of the 2 different unattend.xml (panther vs sysprep)?
My apologies if this is rambling.... any help is appreciated
- MDT BUILD W10 IMAGE - Settings
-
Have you read through the source material yet?
-
For what it's worth, when I used fog at the last place, I simply sysprep'd the image once I had it how I wanted it with the OOBE enabled, and would then upload that to the fog server. I could then deploy that out to different pieces of hardware without issue.
The only addition I had to make was adding a path for an additional drivers directory to search for the different systems we had.
Also that is nearing 4 years old so it might be worth asking george if he can create an updated guide.
-
I'm curious - if you're using FOG to deploy it - why are you bothering with MDT at all?
I mean MDT can make a "more uniform" base image - and go through the WSUS updates for you, sure... but meh...
I also found out with 1803 (if not earlier) I couldn't apply Windows Updates while in Admin mode - creating an image with Sysprep after applying Windows update caused my deployed images to fail. who knows.. perhaps they have fixed that.. I should give it a try.
-
@Dashrender said in MDT Resources:
I'm curious - if you're using FOG to deploy it - why are you bothering with MDT at all?
Also curious about this.
Related to the Windows updates, I just do that after the MDT deployment, using GPO to specify the WSUS group and server and then use PSWindowsUpdate powershell module to check for updates.
-
@notverypunny said in MDT Resources:
-- MDT to install certain free software and (VLC, foxit reader, citrix plugins)
For this you could use something like Chocolatey, Ninite or PDQ Deploy. Again, after the fact.
-
@wrx7m said in MDT Resources:
@notverypunny said in MDT Resources:
-- MDT to install certain free software and (VLC, foxit reader, citrix plugins)
For this you could use something like Chocolatey, Ninite or PDQ Deploy. Again, after the fact.
I skip MDT altogether.
Just install Windows 10 into a VM, use Chocolatey to install my apps, plus Office, AV and Dymo by hand, run Sysprep, take an image.
insert your scripts for joining the Domain, etc here or right before sysprep.
as mentioned - WSUS will push updates after deployment.
-
I prefer to keep it simple as possible.
FOG and SnapIns + Chocolatey and/or PDQ Deploy. -
@Dashrender said in MDT Resources:
I also found out with 1803 (if not earlier) I couldn't apply Windows Updates while in Admin mode - creating an image with Sysprep after applying Windows update caused my deployed images to fail. who knows.. perhaps they have fixed that.. I should give it a try.
I've not had this problem. I alwyas make the VM, run updates, run choco installs, sysprep it down with OOBE.
Make image with Clonezilla, and then deploy image.
-
So to answer the central "why this way" question:
- I want the image to be as clean as possible, so running windows updates on the same image every month will eventually clutter things up with superseded updates as general M$ cruft, no?
- Consistency: if it's rolled into the task sequence it should be built the exact same each and every time
- Running updates post imaging is not an option, like most IT depts we are constantly expected to work miracles. So giving a user a machine but having it run updates shortly thereafter would result in much wailing and gnashing of teeth.
We'd been dealing with setting the hostname and joining to domain manually until now, but I'd been hoping to automate that part of things as we have a few remote offices where it can be a struggle to get help in a timely manner.
-
So if anyone else jumps down this particular rabbit hole, my hacky workaround is to add this to my auto-join cases:
sed -i -e "s#<LogonCount>999</LogonCount>#<LogonCount>1</LogonCount>#gi" $unattendfile -
@JaredBusch said in MDT Resources:
@Dashrender said in MDT Resources:
I also found out with 1803 (if not earlier) I couldn't apply Windows Updates while in Admin mode - creating an image with Sysprep after applying Windows update caused my deployed images to fail. who knows.. perhaps they have fixed that.. I should give it a try.
I've not had this problem. I alwyas make the VM, run updates, run choco installs, sysprep it down with OOBE.
Make image with Clonezilla, and then deploy image.
That's awesome - I definitely had this issue, and not installing updates during admin mode solved it at the time.. and I never went back - now I will.
Thanks
-
@notverypunny said in MDT Resources:
So to answer the central "why this way" question:
- I want the image to be as clean as possible, so running windows updates on the same image every month will eventually clutter things up with superseded updates as general M$ cruft, no?
- Consistency: if it's rolled into the task sequence it should be built the exact same each and every time
- Running updates post imaging is not an option, like most IT depts we are constantly expected to work miracles. So giving a user a machine but having it run updates shortly thereafter would result in much wailing and gnashing of teeth.
We'd been dealing with setting the hostname and joining to domain manually until now, but I'd been hoping to automate that part of things as we have a few remote offices where it can be a struggle to get help in a timely manner.
- Wait - so you're making a new image each and every time you roll out a machine - that seems like a waste of time.
I make an image once per major update from MS, so twice a year - roll out that image, install the latest Cumulative Update, install the Office updates - choco upgrade all -y, and basically done. Of course any other software on the machine that has to be updated manually, take care of it as well.
- OK
- see #1
-
@Dashrender said in MDT Resources:
I make an image once per major update from MS, so twice a year - roll out that image, install the latest Cumulative Update
I also just do that - I just import the stock WIM from the MS iso and use that. Everything else is GPO, PS and PDQ Deploy.
