Launch the Executable file you just downloaded and when the Welcome to Java screen appears, browse to the following location so we can extract the MSI file:

C:\Users\UserName\AppData\LocalLow\Oracle\Java\jre1.8.0_65

Copy the MSI file from this directory in to your SCCM Source directory for your Applications. I like to keep things organised to make it easier in the future when you are adding newer version, For example my folder structure will be similar to this: \\SCCM\Sources\Applications\Java\8.0_65\

Click Next on the Content screen as you have already distributed the application.

Select the option to Required or Available for the Application.

Available: Will Allow the user to choose to install the application. If this is being deployed to a Device Collection, the application will be visible in the Software Center. Applications which are deployed to User Collections can be viewed from the Application Catalogue, they are only shown in the Software Center once the user has requested the Application.

Required: This will force the application on to the workstation within a given time period.

You can choose to make this application available after a specific date/time period. Click Next to leave as default.

The User Experience can be configured to display all notifications to the user or only show notifications for required restarts. I prefer to select Display in Software Center and show all notifications.

Select the required Alert level and click Next to complete.

The Java Runtime Environment application will now be made available to the ConfigMgr client. You can force the client to check in with SCCM and pick up new policies instead of waiting for the next Application Evaluation Cycle.

Launch Control Panel on the Users workstation and select Configuration Manager. Click the Actions tab and select Application Deployment Evaluation Cycle and click Run Now.

The application will now be listed in the Software Center (or the Application Catalogue if you deployed to a User Collection)

There are a number of different approaches you can take with managing drivers and deploying those drivers to your workstations. These are Auto Apply Drivers and Apply Driver Packages.

Auto Apply Drivers

The most common approach is to add drivers in to the central repository and using the Auto Apply Drivers task. This uses the Plug and Play (PnP) detection to scan the hardware during an Operating System Deployment (OSD) and sends this to the management point, the management point responds with all available drivers on the distribution point and the drivers are downloaded for Windows to install.

We can build on the previous process by filtering out certain drivers using Categories. When we import drivers in to the central driver repository we can apply categories to the drivers, this allows us to customise the Apply Drivers task based on device make and model by adding a Query WMI condition to the Apply Drivers task. The benefit of this approach is we can reduce the amount of drivers the management point needs to retrieve from the distribution point.

The above two approaches share the following disadvantages:

Driver Versions: if all drivers are added to a central repository and this includes different version of the same driver you do not have any control of which drivers are applied to which device – this can result in the wrong driver version being applied to a device because they are considered a better match while that driver may in fact cause instability or blue screening.

Missing Drivers: During an OSD you may find some device drivers are missing for example Bluetooth drivers, while on the next deployment that particular driver installs successfully. This can occur if the device is not detected when a Plug and Play scan is carried out during an Operating System Deployment – This could be caused due to the devices being switched off (e.g. bluetooth switch is off). If the device cannot be detected during this short period of operating system deployment then this will not be installed.

Driver Packages

I have found the most effective approach to be using Driver Packages for each models of devices, while this can take longer initially, it will prove easier to manage in the long term. Driver Packages does not use plug and play detection to install drivers during an OSD, instead all drivers included in a Driver Package are installed on the device regardless of the device being present.

Despite the initial administrative effort it provides the SCCM admin with greater control on what drivers are deployed regardless of the device being present on the workstation – for example we can install drivers for a USB Bluetooth Device which is not present during an OSD.

I have documented the full procedure to correctly get the driver management process configured using driver packages.

Create Driver Repository

The first step is to create a central source store for both your drivers and driver packages, this can be your existing source folders for your distribution point. For this example I have created a shared folder on my SCCM server with the path E:\Sources and shared as \\SCCM\Sources.

Add drivers to the Central Repository:

From the Laptop, launch Command Prompt and type the following command:

wmic computersystem get manufacturer

and then

wmic computersystem get model

Make a note of the manufacturer and model of the machines (its important you note the information listed in command prompt rather than what is on the laptop sticker).

Browse to the location of your SCCM software repository: \\SCCM\Sources\DriverSources\Windows7\ and create the folder for the manufacturer you noted earlier

Create a new folder and name it the model number you retrieved earlier.

You will not need to add the driver to Boot image unless you are creating an updated boot image with new Network/Display drivers. Click Next and complete the Wizard

The Final step after closing the wizard is to deploy the package to the distribution point. This can be done by going to SCCM, Software Library, Operating Systems, Driver Packages and select the newly created Driver Package.

After selecting the driver package, click the Distribute Content button from the ribbon along the top, this will launch the Distribute Content Wizard.

Click Next and click Add and select Distribution Point

Select your distribution point checkbox and click OK.

Click Next and then Finish to close the wizard. Wait a few moments while the package is distribution to your distribution point. This can be monitored using the information view along the bottom of the SCCM Console when you click on the package. Clicking the Refresh button from ribbon along the top will let you view if the package has successfully been targeted to a distribution point.

Adding New Drivers to Task Sequence for Client Builds

From the SCCM Console, Click Task Sequences, right click the task sequence you use to deploy the image and click Edit.

Click Apply Drivers folder, if a folder for your manufacturer is not listed under Apply Drivers, then click Add dropdown menu and select New Group. Enter the Name for your manufacturer and click the Options tab.

Click Add Condition and select Query WMI, under WQL Query enter the following string and edit the manufacturer:

SELECT * FROM Win32_ComputerSystem WHERE Manufacturer LIKE '%TOSHIBA%'

This script will significantly decrease the length of time taken to create device collections in SCCM. I created this script for a college where I deployed SCCM 2012, it allowed the college to mass create the device collections required for their environment.

First of all we will need to import the SCCM Powershell Module as shown below.
Note the SMSSITECODE variable will be your 3 letter SCCM Site Code and the location of the Module will need to match the installation path of SCCM.

There are two parts to this script, the first is the command to create the new device collection (New-CMDeviceCollection) with its given parameters. The second is to add a query membership rule which will specify how the collection is populated (Add-CMDeviceCollectionQueryMembershipRule)

The RefreshType parameter in the example has been set to ‘Both’, this ensures the device collection is populated on the schedule which has been specified and it also uses the Incremental Updates setting of SCCM 2012 to ensure newly added devices in between the schedule are also added. The alternative options for this are ‘ConstantUpdate’, ‘Periodic’ or ‘Manual’.

When building golden image for your SCCM Workstation, theres a couple of changes you will need to make to the antivirus client before you deploy the image. The following steps can be incorporated in to the Build Task Sequence or alternatively while building your VDI base image.

Its important this step is done right at the end of your build image, if this is for your sccm image then ensure your image is captured straight after this. If your building your VDI base image ensure this is the last step prior to shutting down the virtual machine for your snapshot.