MDT Resources

Dashrender

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.

wrx7m

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

wrx7m

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

Dashrender

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

black3dynamite

I prefer to keep it simple as possible.
FOG and SnapIns + Chocolatey and/or PDQ Deploy.

JaredBusch

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

notverypunny

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.

notverypunny

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

Dashrender

@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

Dashrender

@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

wrx7m

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