So after quite a while of doing AD/Exchange/Lync/TMG work for quite a few clients – im back into SCCM (as was always going to happen) – and im currently doing some fix ups, for what is, quite frankly, a bit of a mess of a job that another consultant did…. this got me thinking about good and bad practices that ive seen over the years….
Packages should be able to be run either when locally downloaded or when run from the DP
Generally, when your creating a package, make sure you path everything correctly, so you can use it in either mode. While you may always use one or the other, its just good practice – just incase. For us, we will mostly (read: not always) make most deployment packages “download and install” where-as our task sequences will be set to run from the DP.
How do you achieve this…. well, good scripting/packaging techniques! 
If your using dos batch files for whatever reason, utilise %~DP0 to set your current path… if your using vbscript, use a quick “current path” function…. if its a simple one liner msi, you wont need to bother….
Allow for x64
If you have packages that will be run on both arch’s – its not hard to put some arch detection in your scripts or batch files and run the regedits in the appropriate hive. just look up the PROCESSOR_ARCHITECTURE system variable and do different stuff if it says x86 or AMD64.
Spaces….. fucking spaces!
I simply cannot believe after all this time that people are still putting spaces in their directory names…. i mean, cmon! Why give yourself the extra heartache and hassle? Sure, its easy to get around…. but why even do it? is a . or a _ really that hard if your really want to delimit ?
Naming conventions and package locations
Make your packages easy to find…. we generally have our package source in one location and have a naming standard such as APP.Office.2010, OSD.CustomSettings etc…. and the name of the package matches the directory name… there are other ways of doing it ofcourse – and they’re all good – as long as they have some type of standard! Its incredibly frustrating to have a client with 5000 packages, none of which have matching package/directory names… and are all non-standard…. eg. Office 2007, Microsoft Office 2010, MS visio 2003…. <all of which have totally different directory names> fucking pick one!
Excessive complexity for standards
An ex-client loved their standards…. which is a good thing… but went a little to far (IMO)
<Software company><Name of software><type of storage><arch><Version>
example actual path
\\Servername\Source$\AutoDesk\AutoCAD.Design.Suite.2011\Dev\x86\1\ …… and then the actual path started! So for stuff like autocad – it got over 255 characters very quickly! Then there were mulitple versioins in not only the version area, but the dev/test/prod area…. so getting to autoCAD 0.2 meant 60GB was used…. just be realistic… standards are great… but dont use them to your own detriment.
Tier x – WTF?
Something that seems to be quite popular – for a reason that still baffles me is the Tier1, Tier 2 etc applications…. When a place has 100 packages, breaking them up like that just adds confusion…. OSD, APP, DRV, SU prefixes actually mean something to most people immediately…. whats a tier 1 app? One thats only deployed in OS build TS’s? One that everyone uses? It doesnt mean anything to anyone but you…. so what happens when you leave ?
Boot wims
Generally you only need two boot wims…. one for x86 and one for x64…. every now and again, you will run into a situation where you need another, but its reasonably rare…. this is far cry from a customer who had 20-odd… and wondered why WDS was taking so long to start.
On boot wims – remember that the only drivers you will ever need to import are either network or mass storage drivers… and that the driver version must match the winPE version… i.e. windows 7 drivers should be imported for WinPE3.x versions.
General Reference/Production build silliness
“My builds are slow…. ” – “ok, so see how you have Win7 and office 2010 in your reference build and everything else in your prod build…. what do you expect ? <another pearler here was a client who had machines on the other side of a router with a 100mb interface…. this was ofcourse SCCM’s fault!>
Scripts written to set the SCCM client cache size…. when you could just use the install property <SMSCACHESIZE>. Dont create work for yourself when built in SCCM or MDT scripts already have the ability to do what your after.
Reference builds without windows updates applied – followed by complaints that updates take a long time to install post production build.
As a general rule – most things should go in your reference build if you want everyone to have the program. The biggest exception here is antivirus, which we generally leave in the prod build as its a hassle causer. A great example here is the Adobe CS suite…. sure, its massive… but if you have a site license (like many schools) – you can either have a production build which blows out to 30-35 minutes because of the extra size of the captured reference with it included…. or you can actually install it in your prod build and wait 90 minuites plus for the install.
