Our Dev images are thick, but the total deployment time per machine would be 
upwards of 10-12 hours if it was thin. Our operational teams can’t wait that 
long, they need something more readily available. As long as you have a clean, 
automated B&C, this really isn’t much of an issue. We update our thick images 
once a quarter.

Daniel Ratliff

From: [email protected] [mailto:[email protected]] On 
Behalf Of Murray, Mike
Sent: Monday, March 14, 2016 4:25 PM
To: [email protected]
Subject: [mssms] RE: Thick or THIN image?

Same here. It takes longer, but I don’t have to sit there watching it the whole 
time.  ☺

From: [email protected] [mailto:[email protected]] On 
Behalf Of Marable, Mike
Sent: Monday, March 14, 2016 10:51 AM
To: [email protected]
Subject: [mssms] RE: Thick or THIN image?

We install them at build-time.

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Giroux, Eric J
Sent: Monday, March 14, 2016 1:48 PM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: Thick or THIN image?

How do you deal with things like Visual Studio, SQL server needed on developer 
workstations?  I can’t justify extra hours to install huge apps on top of a 
thin image so my developers have separate “thick” images.

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Murray, Mike
Sent: Tuesday, February 16, 2016 11:40 AM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: Thick or THIN image?

This message originated outside of Unum. Use caution when opening attachments, 
clicking links or responding to requests for information.

Agreed, we had somewhere in between thick and thin, but have since migrated to 
a thin image. Only the OS, Office, and patches. Everything else gets installed 
during the TS. The main reason we went to this method was it’s much easier 
keeping our image up to date – if there’s a new version of an app, we don’t 
have to rebuild our image, just update the app.

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Marable, Mike
Sent: Tuesday, February 16, 2016 4:17 AM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: Thick or THIN image?

It goes without saying, but Michael is spot on.

We started with a thick image years ago with Windows 7 and I regret that all 
the time.

Learn from my mistakes (always better to learn from other folks’ mistakes) and 
keep it as lean as possible.

Mike

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Michael Niehaus
Sent: Monday, February 15, 2016 10:37 PM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] RE: Thick or THIN image?

Start thin, with as little customization as possible, but fully patched.  Only 
make it thicker (by adding apps) if you need to save time during the deployment 
process.  Only customize if absolutely necessary to make the OS immediately 
usable by the end user.  Never add drivers or hardware-specific apps.

And most importantly, automate everything, both in the image creation process 
and deployment process.  If you can’t automate everything, you haven’t tried 
hard enough.

Thanks,
-Michael

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Burke, John
Sent: Monday, February 15, 2016 7:09 PM
To: [email protected]<mailto:[email protected]>
Subject: [mssms] Thick or THIN image?

We go pretty thin here, but are considering going more thick again.

I’d love to know if there are any best practices.  The last time I looked into 
this – it seemed THIN with as little customization (outside of GPO) was the way 
to go.

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of ccollins9
Sent: December-02-15 11:12 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [mssms] Plain image or fully loaded?

We go completely thin. The only thing in the image are OS updates and things 
like .net. We have sccm to manage our software and we update software fairly 
often, so we feel it's best to get the software installed fresh at build time. 
Important and big software gets installed as steps in the task sequence, this 
includes office, lync, vpn client, a/v agent, smartcard middleware, etc. Then 
once built, additional software gets installed by sccm based on collection, 
etc. One reason for this is to keep the image small for sending out to regional 
office distro points. Makes no sense to me to send the ms office software to a 
regional dp AND an image that contains that software, for example. One REALLY 
awesome feature in sccm is the ability to right click and add Windows updates 
into the image automatically, so there is really never a need to update our 
base image very often at all with a deploy/capture job.

On Wednesday, December 2, 2015, Juelich, Adam 
<[email protected]<mailto:[email protected]>> wrote:
Very good responses above.  We currently use a Hybrid approach except for 
certain labs (AutoCAD/Engineering) where I would use a Fat image because of the 
size and scope of applications.  All of that being said, go as Thin as 
possible.  You will thank yourself in the end.


-----------------------------------------------

Adam Juelich

Pulaski Community School District<http://www.pulaskischools.org>

Client Management Specialist

920-822-6075

On Tue, Dec 1, 2015 at 2:16 PM, Niall Brady 
<[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
good advice from the guys above, I'd also suggest you try both approaches (fat 
versus thin image), and only include updates and apps that everyone will use 
that don't change too often,
in fact i cover this in my book, also on amazon - 
http://www.amazon.com/Windows-noob-Guides-Configuration-Manager-2012/dp/9187445166/ref=sr_1_1?s=books&ie=UTF8&qid=1449000925&sr=1-1

On Tue, Dec 1, 2015 at 8:49 PM, 
<[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>>
 wrote:

Bake updates into your reference image. (this will save you the most time per 
machine.)



If every machine gets office, bake that in as well. Plus office updates.



Only put applications that don't change often into the image ( not java, not 
flash player, not adobe reader).



This is called a "hybrid" image, not fully thin, but not thick either.



This way you can update it as often as you want to lower the number of patches 
applying during the imaging process, but you aren't pinned to updating every 
time adobe has a zero day.



If your new to OSD the following books are very useful, heck I reference them 
all the time as well:



http://www.amazon.com/Stealing-Pride-Vol-Customizations-ConfigMgr/dp/9187445034/ref=sr_1_1?ie=UTF8&qid=1448999110&sr=8-1&keywords=stealing+with+pride



http://www.amazon.com/Deployment-Fundamentals-Vol-Real-World-Infrastructure-ebook/dp/B00OI2H47S/ref=dp_kinw_strp_1



Here are some great reference sites:

http://deploymentbunny.com/



http://deploymentresearch.com/





________________________________
From: 
[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>
 
[[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>]
 on behalf of Beardsley, James 
[[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>]
Sent: Tuesday, December 01, 2015 2:26 PM
To: 
[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>
Subject: [mssms] Plain image or fully loaded?
Whats the recommended way of building an image? We’re getting ready to start 
using OSD (previously used standalone MDT) and we’re trying to decide if we go 
with how we’ve done things in the past where we load a ton of apps that 
everyone uses on to the image and then capture it. Or, is it recommended to 
simply capture a plain OS-only image and then build apps into the task sequence 
to install afterwards? I know that everyone probably has their own method of 
building an image but I’d appreciate some insight on which one you use and why…

In our testing (granted this may have been due to the hardware of the OSD 
server vs the MDT server), we’ve found that the time it takes to do a plain 
image and then install updates and apps afterwards via TS were taking an hour 
or more for each computer. On the other hand, when we stuffed a bunch of apps 
on to the image and captured it and deployed it via MDT, we were able to image 
a computer in about 25-30 minutes. That’s quite a big discrepancy so needless 
to say, I’m having trouble convincing some within our group who are responsible 
for imaging machines all day to go with the plain image + subsequent task 
sequence method.

Could anyone provide links for recommendations on how to setup the image for 
OSD and if you have any good general OSD-related links, I’d love to see them.

Thanks,

James Beardsley | Firm Technology Group
Dixon Hughes Goodman LLP

[cid:8644FC49-D5C9-45AE-B387-04FAFC0CC7A5]<http://www.dhgllp.com/>

________________________________

Confidentiality Notice: This e-mail is intended only for the addressee named 
above. It contains information that is privileged, confidential or otherwise 
protected from use and disclosure. If you are not the intended recipient, you 
are hereby notified that any review, disclosure, copying, or dissemination of 
this transmission, or taking of any action in reliance on its contents, or 
other use is strictly prohibited. If you have received this transmission in 
error, please reply to the sender listed above immediately and permanently 
delete this message from your inbox. Thank you for your cooperation.






________________________________
The Pulaski Community School District does not discriminate on the basis of any 
characteristic protected under State or Federal law.





**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be 
used for urgent or sensitive issues




**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be 
used for urgent or sensitive issues



The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Reply via email to