In SCCM 2007 it was very common just to use Driver Packages when managing drivers for computers that are to be used during OS Deployment. In SCCM 2012 that has changed the drivers now must be imported to be able toi be applied during OS deployment even if you use the 'Apply Driver. Automate importing and creating driver packages in SCCM. With drivers and manually creating driver categories and driver packages in Configuration Manager.

Please tell me I'm missing something! I got the CABs from Dell. It isn't possible to offer the entire CAB to SCCM. I must extract it first. Okay whatever.

Extract.exe is no longer in Win 7. There's no longer right click >extract in Win 7 context menu for CAB files.

Okay whatever. Open CAB >extract >'opening these files may be harmful!'

I had to confirm (click 'save') for each file individually and there were hundreds. So I left a little Buddha statue pressing down on the S key and walked away. I got the CAB extracted. (No I'm not installing WinZip or RAR just for this!) SCCM can import individual drivers (no thanks - there are hundreds! Creare Un Keygen For Mac on this page. ) or all drivers in a folder. Ooooh that sounds perfect - I thought.

Driver import wizard requires a UNC path to a share - yes even if the drivers are on a local disk. But okay whatever. Selected the folder where I extracted the CAB. It was full of disk and network drivers. And I ended up with two (2) drivers for AHCI disk controllers imported.

Where are the other ones?! That's because the import wizard, when 'entire folder' option is chosen, only looks at txtsetup.oem and only enumerates what's referenced there. It did not look at the many.inf files in the drivers folder.

So now I'm presented with these two lovely choices: Write my own txtsetup.oem and include references to all these drivers. Or individually import drivers by browsing to their.inf files. Tell me I'm an idiot and there's an easier way to do this. Thanks for that. It makes things easier. I figured out why only two drivers were importing right after I posted. Extracting a CAB with native Win 7 CAB support flattens the folder structure of the CAB.

I used WinRAR and extracted, and had no trouble importing the drivers. The folder structure must remain x86>audio>vendor>Driver Pack Win7 64 Bit. device.

And right away ran into a new problem! Deploying drivers with apply device drivers task in the task sequence does NOT work. Probably a bug. This is supposed to query all drivers on the SCCM server and apply drivers to clients as needed. The clients spend about 5 minutes per device (so easily 15-30 minutes per machine!) 'installing drivers' during the imaging, but upon first boot the devices are missing drivers! Using apply driver package works as advertised.

I was able to push an Optiplex 390 driver package. I had to write WMI queries like this one: Select * from Win32_ComputerSystem where Model like 'Optiplex 390%' New problem today! This one still unresolved. I installed the windows update point and it integrated with local WSUS just fine.

The initial synch just finished. But none of the 5 or 6 SCCM clients I'm using for testing are being pointed to the SCCM update point. (Yes, I have turned off the domain GPO that pointed them at our old WSUS server.) In theory the SCCM client should edit the local group policy settings and point WU to SCCM. That is NOT WORKING. The clients' WU settings are the default MS ones.

They are now pulling updates from MS directly. In Client Settings under software updates I have 'enable software updates' set to TRUE. But it just isn't applying to clients.

Yet again I need to mess with this! After I sort out the WU: I still have USMT stuff to configure, and the 3rd party application deployment. I suspect those will be a bitch too. What a half baked POS. I want to test update deployment. Searching for updates with a 'date released' 'less than or equal to' '2 months' lists updates OLDER than 2 months.

They got the logic reversed. This is reproducible 100%. I wanted to push July and August security updates, and instead I got updates from 2003 to June of this year. Yea I noticed that the logic is flipped a couple weeks ago. There is supposed to be Service Pack/update coming out mid October (I think) that adds some nice things (Apple support). No clue if it is fixed there. Next up app deployment.

Adobe stuff deployed fine, to my great surprise. Yes even the MST transforms applied correctly. In fact, every mandatory app we use here got deployed just fine. Java JVM too. Drumroll please.

O2007 does not support Application type deployment from SCCM. The.msi can't be deployed. Gotta run setup.exe. So I needed to create an SCCM package (suboptimal solution, applications are preferred) and a program.

I followed this to the letter: I'm using a known good Office source install with an MSP. It installs fine on the clients when setup.exe is called manually. But the SCCM package isn't deploying to clients. It isn't failing! It just isn't even trying. I don't know where to begin troubleshooting this. Advertisement parlance was dropped in SCCM 2012.

Now it's package >program >publish >deploy. That method is still available, but been depreciated in favor of deploying applications (MSI application >publish >deploy). Sadly the Office 2007 does not support calling up the.MSI file to deploy. I need to find which log file has the best info to help me unscramble this. SCCM 2012 is log-happy and there are dozens on the server and on the client, logging every minute detail. I can try OSD I suppose. I've got 4 clients I'm testing SCCM with.

Packages do not appear in the application center on the clients. Anyhow, on one of my test clients I can see setup.exe process running. But no progress on the installation. This client had copied the setup files into the local sccm cache.

So it's trying but hanging. The rest of them aren't trying.

All my other apps have deployed fine through Sccm. This same office package - literally same one on the same network share - has been deployed fine in the past to hundreds of machines. Just not with Sccm 2012. I have a lot more testing to do.