Updated on :  10/08/2014
Relevant to:   SCCM 2007 and SCCM 2012 (including R2 and R3 versions)

---

 

 

So after quite a while of doing AD/Exchange/Lync/TMG work for quite a few clients – I’m back into SCCM (as was always going to happen) – and I’m 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 I’ve seen over the years….

 

Packages vs. applications

As a general rule, applications are more flexible than packages, and in my opinion, should be used in preference to SCCM 2007 style packages where possible.

Some of the reasons applications are superior are:

• Applications contain the files and information necessary to deploy software packages to computers or mobile devices, and can contain multiple deployment ‘types’, such as a local installation, a virtual application package, or a mobile device version installation.
• Requirement rules and Global conditions define how (and if) and application is deployed to client devices.
• Deployments are used to distribute (and remove) applications, deployments of applications can be considered state based compared to traditional packages.
• Configuration Manager can use detection methods to determine if a deployment type has already been installed on a device by using product information or a script
• The status of an application deployment can be monitored directly in the Configuration Manager console
• Applications can have their versions tracked over time, and can be reverted to previous versions if required

 

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 in case. 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.

This is slightly less relevant in SCCM 2012 days, as an additional deployment type can be created with an operating system requirement.

Spaces….. fucking spaces!

I simply cannot believe after all this time that people are still putting spaces in their directory names…. I mean, c’mon! 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 of course – 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

\ServernameSource$AutoDeskAutoCAD.Design.Suite.2011Devx861 …… and then the actual path started! So for stuff like autocad – it got over 255 characters very quickly! Then there were multiple versions 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 don’t 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…. what’s a tier 1 app? One that’s only deployed in OS build TS’s? One that everyone uses? It doesn’t mean anything to anyone but you…. so what happens when you leave ?

Un-necessary folder depth

Another bafflingly popular practice seems to be making folders to store applications or packages in which are 3 or 4 levels deep.

Personally I do have a top level folder structure of APP, OSD etc…. but even that is something that I’m happy to put in or take out based on what the client wants – some places however seem to go for the “tier1\MicrosoftOffice”, then proceed to place all office applications within that folder. Repeat for every other product.

With the search function, I just don’t understand the need to create such folder structures, especially given that the “search all sub nodes” menu option is not intuitive for SCCM newbies to see.

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 of course SCCM’s fault!>

Scripts written to set the SCCM client cache size…. when you could just use the install property <SMSCACHESIZE>. Don’t 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 minutes plus for the install.