Installing as apps/packages during TS deployment? What’s a ballpark deployment time for a developer build with tools like VS or whatever else your typical developer might require?
From: [email protected] [mailto:[email protected]] On Behalf Of Marable, Mike Sent: Monday, March 14, 2016 1:51 PM 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
