SCCM Application Deployment (Best Practice)

[ID-10-T]

Good morning, folks,

 

I wanted to get an idea how people structure their application shares for deployment via SCCM. This task has recently fallen to me here at our university and I am well under way with regard to packaging and deploying software to faculty, staff and lab environments. I'm relatively new to SCCM (and mass deployments in general) with no training, so it's been a lot of research and trial-and-error to get as far as I have. It's been working well so far, however, in the last few weeks I have hit a couple of hurdles that have me rethinking how I do things.

 

Most annoying is the path length limitation that's sandbagged a few of my applications. Similar to another thread I saw here, I use a path like "$SHARE\XYZ\Vendor\Product\Architecture\Version", where XYZ is a directory for either for default applications or lab-specific software. This works for, probably, 99% of the stuff I deploy but lately I have had at least three (3) applications that fail due to long path/filenames. I should add that I use Powershell Application Deployment Toolkit (PSADT) so that adds an additional subdirectory (Files) beneath the Version directory.

 

So how are others structuring their application paths for SCCM deployment? Do most people use a structure similar to mine or do they dump everything into one share? Is there an actual "best practice" or do folks just go with whatever works?

[mullet_man]

I have

 

SCCM\Apps\Vendor\Title\Version\Architecture

 

But I've never encountered an issue with file path limits.

 

You should create collections for the labs in SCCM and the deploy the apps to collections, that's how I do it anyway.

 

You can create query based collections so anything with TECH in the computer names will get tech apps deployed to them.

 

Am no master at sccm but once you got the basic collections and apps in your good to go and if you reimage anything with the same name the apps just redeploy

[free780]

I usually go \\domain\share\application\version. Mainly due to updates for applications.

However if an application such as Autodesk has issues with long directory structures (and users require read access) I create a new share \\domain\vendor\application_version

I use DFS in case the source folders need moving.

[ID-10-T]

We have collections sorted by lab, department, staff, faculty, etc....a veritable collection of collections. Software, likewise, is organized by essentials (stuff everyone gets), departments and labs. When my money finally gets here from Nigeria, I want my replacement to be able to step in and take over with minimal learning curve. Inside the SCCM Console, everything is neat, tidy and reasonably organized. I'm trying to keep the back-end similarly neat and tidy. For the most part it is but there are a few applications that just don't like my organizational structure...always a rebel somewhere. I can hang things off the root and (probably) solve the problem but that starts to get ugly and out-of-hand with too many exceptions. My take-away from all of this is that I'm doing things pretty much the same as others and I've just been unlucky enough to hit several problem applications in a short time. Creativity is king, so I'll find away to have my cake and eat it too; I'll try repackaging the software and see if that works. Stay tuned for updates. Same bat-time, same bat-channel...