6

A Shining Example: Inside all of my task sequences I have a group that installs driver packages conditionally based on computer model:

enter image description here

And of course, this list does nothing but grow. The fact that it grows isn't a big deal, what is a big deal is that every time it changes I have to manually copy and paste those changes across every task sequence I have, which of course leaves huge room for human error. The same goes for other groups of tasks that are common across task sequences.

Looking for a solution where I could centrally manage these tasks, be it link other task sequences to a group within another task sequence, or create a separate task sequence and link to that.

I came across a solution by John Marcum (SCCM MVP) that mentioned this ability, but this was a while ago and I can't find the link to it anymore to see if it's even still being updated/maintained, but I'm looking for more of a free solution, or even using Powershell or the ConfigMgr SDK is fine with me, I'm no stranger to either.

Update

Getting close: http://msdn.microsoft.com/en-us/library/jj217869.aspx

MDMoore313
  • 5,531
  • 6
  • 34
  • 73

2 Answers2

1

I realize this does not directly answer your question but I can't help but feel this might be a better way to accomplish your goal.

I'm assuming you are using this Task Sequence to either do a image build or capture or to deploy a previously capture image. I cannot think of a reason why you would have to install device drivers this way.

We just import the device drivers into the Drivers Catalog, roll them up in Packages and then use the Apply Device Drivers action during the image to handle each particular workstation.

Works just fine for us but maybe there is something in your scenario that I am missing.

task sequence

  • We've (they've now) experienced driver conflicts in the past between Dell models when using the blanket apply device driver ts step, because it behaves the same way as windows update does in re: to detecting drivers, whereas the apply driver package is a little more direct, it'd been a while son I can't remember the details. That was my thought process for doing one package per model, originally I had it setup just like you. Don't quote me yet, but I believe MS recommended this as well, but like I said, it's been a while so I could be wrong – MDMoore313 Dec 16 '14 at 15:00
1

People call me crazy, but I do not create driver packages for different computer models. I only have one driver package that has every driver in it, and I obtain the driver from the device manufacturer's site (where available), and not from the computer maker.

Take Ethernet drivers as an example. We are (mostly) a Dell shop but we do have some Acers and Lenovos scattered here and there. But all of them use either an Intel, Broadcom, or Realtek chipset. Intel's ProSet driver covers every model they make. Broadcom and Realtek have two each. That's 5 ethernet drivers that cover all 4500 computers on our campus. I include that one driver package in my task sequences, and Windows does a good job of selecting the correct driver during deployment. The best part is that when a new model arrives, I rarely have to change anything. I only touch the driver repository maybe once or twice a year, and I haven't even touched my task sequences in over two years.

Video drivers are the same way. I have one ATI/AMD driver, one nVidia driver, and three Intel drivers that cover every computer we have. It does get a little dicey sometimes with audio drivers, and odd little chipset drivers every now and then. But usually, the Dell one works on Acers or vice versa.

Wes Sayeed
  • 1,862
  • 6
  • 27
  • 41
  • See my comment to kce for response to your process. In addition though, I'm sure you must have some overlap of tasks between task sequences, whereby when that step must change, you have to update each ts, no? That was really the driving force behind this question, as I had a *lot* of overlap, and the driver scenario was just the best example. – MDMoore313 Dec 16 '14 at 15:03