SCCM - Packaging - Java Runtime Environment

Although there are a couple of different ways to package Java Runtime Environment, I have found the following method to be the most reliable and easy to implement:

1] Download the offline installer for either the 64 or 32 bit version of Java Runtime Environment and save it in your C:\temp folder or where ever suits. The url for the download page is, at present, this:

https://www.java.com/en/download/manual.jsp

2] Double click on the installer (should be called something like jre-XuXX-windows-i586.exe). When Welcome to Java window appears do not click on the "Install" button. Instead, navigate to the user Application Data folder. In Windows 7 the JRE app data folder can be found here:

     C:\Users\<user>\AppData\LocalLow\Sun\Java\jre<version_number

Inside you will find a .msi file which should be called something like jre1.X.X_XX.msi. Create a new JRE folder on your SCCM server software share and copy the .msi file into it.

3] Open SCCM and create a new package. Point to the new JRE folder you just created. Distribute the contents to your distribution points.

4] Create a new program with the appropriate switches. For example, the below switches will disable all automatic updates, agree to the EULA, stops Java installing on the start menu, supresses a reboot (if needed) and enables Java for use within browsers with a security level of High:

msiexec /i jre1.8.0_31.msi AUTO_UPDATE=0 EULA=0 NOSTARTMENU=1 REBOOT=0 WEB_JAVA=1 WEB_JAVA_SECURITY_LEVEL=H /qb

Once you've created this, simply advertise it out to the relevant collection.

For more info on the command line switch options for the JRE msi, see the following links:


http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html

http://docs.oracle.com/javase/7/docs/webnotes/install/windows/jre-installer-options.html

http://wpkg.org/Java

If you don't fancy the idea of having a long ole' command line string appended to the .msi file you can always open the file in ORCA, mod the Property tab and generate a transform file


Alternatively you could create a configuration file for deploying JRE:
http://docs.oracle.com/javase/8/docs/technotes/guides/install/config.html#installing_with_config_file

SCCM 2012 R2 - PXE Boot - Could Not Find Boot Image

Issue:

Having created a new Boot Image and imported it into SCCM, you create a new Task Sequence and set it to use your new boot image. When you PXE boot a new machine, however, the pxe boot process simply hangs on Contacting Server....

Also, when you check in the SMSPXE.log file on the SMS PXE point server you see the message "could not find boot image":

Cause:

SCCM cannot find your new boot image and so cannot proceed with the pxe boot.

Fix:

Deploy the boot image out to the PXE distribution points:

SCCM 2012 - Updates - Multiple Automatic Deployment Rules, One Deployment Package

In SCCM 2012 R2 there are a number of possible ways to push out the monthly software updates. There are numerous excellent blogs on the web about the various ways to set up the monthly patching. The basic concept, if using an Automatic Deployment Rule, is as follows:

--> Create the ADR

--> ADR runs 

--> ADR locates the updates it needs by talking to Microsoft Update Site

--> Updates are downloaded into the Deployment Package 

--> Updates are either added to existing Software Update Group or a brand new one is created

--> Software Update Group is deployed to the target collection

             However, if you have multiple Collections set up for monthly patching, this will require the use of multiple ADRs. So does this mean that if each ADR has the same Products/Classificaitons you'll end up downloading the same updates multiple times? 

            Well, that depends on whether each ADR has it's own deployment package or not. If each ADR has its own Deployment Package then you will end up downloading the same updates repeatedly. However, if you create a single Deployment Package and simply point each ADR at it, then this problem will be avoided. 

In the below example, i have two ADRs set up - one for test servers and one for production servers. Both ADRs are set to download the same Products and Classificaitons. Although there are two ADRs, i have only create a single Deployment Package which both ADRs will use. The automatic monthly update process then proceeds in the following way: 

First Rule kicks off:

Config Manager finds two updates which need to be downloaded so it trundles off to the internet and pulls them down into the shared package:

Later that week, the second rule kicks off:

Config Manager again finds two updates which need to be downloaded. Before downloading the two updates it checks in the deployment package and discovers that both updates are already present. Config Manager moves on with the creation of the new SUG:

(the above snips are taken form RuleEngine.log which is the best log to consult when checking on ADRs)

Microsoft Silverlight - Convert exe into msi

In SCCM 2012 it's preferable to deploy software in the guise of Applications rather than as a Package. This means you need to use .msi installer files. Unfortunately not everything comes with a .msi installer file. In the case of Silverlight, it comes as a .exe. In order to turn this .exe into a .msi, follow the below steps:
 
Get hold of a copy of the Silverlight installer (either 32 or 64bit) from the MS site. Save it to c:\temp

Open up a command prompt and switch to the exe's directory (enter cd c:\temp).

Enter Silverlight.exe -x

At this point you should be met with a message box asking where you want to extract the files to. Leave the file path as default and click Ok.

Once the extraction is done, click OK. You should then see a bunch of new files appear in c:\temp.


One of the new files will be called Silverlight.7z. This is a zip file which you need to extract into the c:\temp folder using 7zip or something similar.


Make a quick note of the size of the Silverlight.msi file (should be tiny).

Change back to the command prompt window and enter msiexec /p silverlight.msp /a silverlight.msi which will merge the .msi file with the patch file.

Switch back to c:\temp, check the size of the silverlight.msi file - it should have increased in size. Also there will now be a new folder called PFiles.


You only need the PFiles folder and Silverlight.msi file to create an application in SCCM.