Monday, April 27, 2015

Deploy HEC-SSP 2.0 with ConfigMgr

The install of HEC-SSP 2.0 is a simple example of using active setup to take care of a first run prompt that appears for each user. The computer labs where we deploy this software are in part managed by Faronics Deep Freeze, which reverts the computer to its previous state each time it is rebooted. Therefore we do not want the student to have to click through all the first time run prompts every day they use a piece of software. HEC-SSP has a Terms and Conditions for Use prompt that pops up the first time a user runs the program. We are going to use active setup to accept the terms on behalf of the user.

Active Setup

Using a program like RegShot you can easily find the files and registry entries that are modified between two points in time. I found that the registry entry that handles the TCU popup is at [HKEY_CURRENT_USER\Software\JavaSoft\Prefs\hec2\ssp\client\/T/C/U\2.0 ]
"/Read/T/C/U"="1". So I exported this entry into a .reg file.
Here are the contents of the file, you will need to either export your own from Regedit or copy into a file called "hkcu_HEC-SSP.reg"
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\JavaSoft\Prefs\hec2\ssp\client\/T/C/U\2.0 ]

Install Script

Next create your install script, this one is in PowerShell. I also want to remove previous versions of this software as the installer does not replace them itself. So I will search for and remove all versions before installing.
# Uninstall existing installs
$Installs = get-wmiobject -namespace root\cimv2\sms -query "select * from SMS_InstalledSoftware where ProductName like 'HEC-SSP%'"

foreach ($Install in $Installs)
  $software = $Install.softwarecode
  $UninstallArgs = "/x $software /qn Reboot=ReallySuppress"
  start-process msiexec.exe -ArgumentList $UninstallArgs -wait
# Install Current Version
$InstallArgs = "/S /v/qn"
Start-Process .\HEC-SSP_2_Setup.exe -ArgumentList $InstallArgs -Wait

# ActiveSetup to remove first run TCU Prompt.
Copy-Item -Path hkcu_HEC-SSP.reg -Destination "${ENV:ProgramFiles(x86)}\HEC\HEC-SSP\2.0\hkcu_HEC-SSP.reg" -Force
New-Item -Path Registry::'HKLM\Software\Microsoft\Active Setup\Installed Components\HSU-HEC-SSP-2.0' -Force
New-ItemProperty -Path Registry::'HKLM\Software\Microsoft\Active Setup\Installed Components\HSU-HEC-SSP-2.0' -Name StubPath -PropertyType String -Value 'CMD /C REG IMPORT "%ProgramFiles(x86)%\HEC\HEC-SSP\2.0\hkcu_HEC-SSP.reg"' -Force
New-ItemProperty -Path Registry::'HKLM\Software\Microsoft\Active Setup\Installed Components\HSU-HEC-SSP-2.0' -Name Version -PropertyType String -Value '2,0,0,0' -Force

Build Application

Put the reg file, HEC-SSP installer and PowerShell script in your ConfigMgr source.
Create your application, the installation command line I use with PowerShell is
powershell.exe -ExecutionPolicy Unrestricted -File install_HEC-SSP.ps1

Detection Method

The HEC-SSP_2_Setup.exe extracts an msi into C:\Windows\Installer when it is run. You can gather the msi product code from it to use as the detection method.

Thursday, April 23, 2015

Deploy SciLab 5.5.2

The SciLab x64 application deployment is fairly straight forward with the exception that it does not remove old versions when installing a new version. To complicate matters, the uninstall is done by calling an executable called unins000.exe in the Scilab-x.x.x folder in Program Files.

I created my PowerShell install script to search though the folders in Program Files, and if one of them matches Scilab, to go into that folder and run the uninstall command. This should work for future and past versions of Scilab 64-bit as long as the unins000.exe filename does not change. After uninstalling,  the script installs the new version.
# Remove old x64 versions.
$Softwares = Get-ChildItem -Path "$ENV:ProgramFiles" -Directory -Name
ForEach ($Software in $Softwares)
 if ($Software -match "sciLab")
  Start-Process "$ENV:ProgramFiles\$Software\unins000.exe" -ArgumentList "/VERYSILENT" -wait

# Install New Version
Start-Process scilab-5.5.2_x64.exe -ArgumentList $arguments -wait

# Remove Desktop Shortcut for new version
if (Test-Path -Path "$ENV:SYSTEMDRIVE\Users\Public\Desktop\scilab-5.5.2 (64-bit).lnk")
 Remove-Item -Path "$ENV:SYSTEMDRIVE\Users\Public\Desktop\scilab-5.5.2 (64-bit).lnk" -Force -Recurse
Build your ConfigMgr package like normal, for the installation program, I use a command line like "powershell.exe -ExecutionPolicy Unrestricted -File install_scilab.ps1"
For the detection method I check the uninstall location of the registry like so:

 Edit: I forgot to mention, the SciLab installer appears to download two zip files when it is run. You can either just use the executable and the installer script in your source, or you can run the installer, download the two zips and package them in your source as well. If the zip's are already in the source, the executable does not have to go online and download and it speeds up the install. We've had success deploying it both ways. Here is what my source looks like:


Tuesday, April 21, 2015

Deploy Java 1.8 with MSI Enterprise Installers and PowerShell

*Edited 7/22/2015 - I neglected x86 OS's when I added the INSTALLDIR=""${Env:ProgramFiles(x86)}\Java\Jre8"" to the installation command, I've updated the script to check the OS version and install into the appropriate ProgramFiles.

*Edited 6/22/2015 - Our installs of Eclipse would error after Java updates because the eclipse.ini file tells the program where JRE is located. I found that Java installer is not installing Patch-in-Place like what use to be the default. I tried STATIC=0 in the install script and that didn't work either. So I added INSTALLDIR=""${Env:ProgramFiles(x86)}\Java\Jre8"" for x86 and INSTALLDIR=""$Env:ProgramFiles\Java\Jre8"" for x64, to the install command line to specifically tell Java which folder to install to.

*Edited 4/24/2015 - I found at least one case where an uninstall of Java will cause the computer to reboot. Therefore I have added a /norestart to the uninstall arguments, which is probably a good idea to always include.

*Note: As of version 8u40 there still appears to be a bug with the MSI installers which causes the install to fail if parameters are used when the system account installs the application. I have modified my installation to account for this.

With the introduction of Java 8u20, Oracle introduced their supported enterprise MSI installers.
Unfortunately as I noted above, if you use SCCM to deploy the MSI and use parameters in the install command line, the installation will fail. It may be possible to still extract the MSI's from the Java offline installer and deploy that instead of downloading the "Enterprise Installers". I didn't have success with that method any longer, but I haven't tried it since realizing that the MSI does not accept parameters.

First you will need access to MOS (My Oracle Support). My organization has Premier support, so I had to sign up and then add our Support Identifier and Organization Name and request access. This then emailed our "Customer User Administrator", a programmer on staff here who granted me download access.
Now I am free to download the msi enterprise installers as needed. Searching through the support site for "java enterprise msi", I was able to find the download links on a page called "All Java SE Downloads on MOS"

I chose the Oracle JRE 8 Update 40 MSI Enterprise Installer, you will be taken to a download page where you can choose the 32 or 64 bit versions. In this example, I am installing the 32bit version. Once downloaded you can extract the "jre-8u40-windows-i586.msi" from the zip file. There are just minor changes to the logic if you are going to do the 64 bit version.

With Java its better to make sure Internet Explorer is closed when uninstalling older versions. So I created a PowerShell script to check if IE is open, if it is open, it exits with a 1618 error code, which ConfigMgr interprets as a "fast retry". If IE is not open, it searches for and uninstalls older versions of Java except for ones with "(64-bit)" and "Development Kit" in their titles and then installs the new Java.

# Check if IE is open, some versions of Java cannot be removed if IE is open
# if IE is open, return a Fast Retry to SCCM and stop execution of script
if ( get-process iexplore -ErrorAction SilentlyContinue )
            Exit 1618

# Search and attempt removal of old Java's
$javaInstalls = get-wmiobject -namespace root\cimv2\sms -query "select * from SMS_InstalledSoftware where ProductName like 'Java%'"
foreach ($javaInstall in $javaInstalls)
if (($javaInstall.Productname -notmatch "(64-bit)") -and ($javaInstall.Productname -notmatch "Development Kit")) {
$software = $javainstall.softwarecode
$arguments = "/x $software /qn /norestart"
start-process msiexec.exe -ArgumentList $arguments -wait

if ((Get-WmiObject -Class Win32_OperatingSystem).OSArchitecture -eq '64-bit') {
    $InstallPath = ${Env:ProgramFiles(x86)} } 
    else {
    $InstallPath = $ENV:ProgramFiles

Start-Process jre-8u40-windows-i586.msi -ArgumentList "/qn INSTALLDIR=""$InstallPath\Java\JRE8"" /norestart" -Wait

# Remove Start Menu Items aka Parameter NOSTARTMENU="Enable"
if (Test-Path "$Env:ProgramData\Microsoft\Windows\Start Menu\Programs\Java")
    Remove-Item -Path "$Env:ProgramData\Microsoft\Windows\Start Menu\Programs\Java" -Force -Recurse
I call this PowerShell script "install_jre_x86.ps1".
The Fast Retry exit code tells ConfigMgr to retry the installation quicker than it normally would according to your Client Settings. I've seen it retry every 2 hours in the AppEnforce.log, though I heard from a knowledgeable source it could be as fast as 20 minutes. The idea is to have it periodically check if IE is open, and when its closed, to start the install.

You can modify the script if you want to uninstall versions that I am not removing. I remove the 64-bit versions with a 64-bit deployment, I like to treat them as separate applications because that works best in our organization. So for the 64-bit version, you would change the if statement line to match:
if (($javaInstall.Productname -match "(64-bit)") -and ($javaInstall.Productname -notmatch "Development Kit")) {

Create your Java application deployment like normal. I call mine "Oracle JRE 1.8 x86 Silent Install". For the Installation program, I use a command line like "powershell.exe -ExecutionPolicy Unrestricted -File install_jre_x86.ps1"

Using CCTK to configure BIOS settings during Configmgr 2012 OSD, Part3 - Configure BIOS settings

This is part three of a three part post about using CCTK in task sequence deployments. The first post, how to clear BIOS passwords is here. The second, how to set a BIOS password is here.

If you haven't already, you will need to acquire the Dell Command | Configure Software:
Download Dell Command | Configure from the link off the Dell Client Command Suite page.
Install the Update Package on your workstation so you can make configuration files.
You will find a new program called Configuration Wizard with the Dell icon, or you can run it from Program Files (x86)\Dell\Command Configure\cctkgui.exe.

Create the configuration executable:

Run the cctkgui.exe software. We are going to create a Multiplatform Package which we are going to use this to try to set BIOS settings on all Dell systems.
For our settings, I want to set the boot order, enable smart errors, set standbystate to S3, controlwlanradio to enable, wakeonlan to enable, tpm to enable, and tmpactivation to activate.

Set whatever settings you want in your environment. You should always test to make sure the settings are what you are expecting.
Choose Export config to save it as a .cctk config file so later you can open it and view the configurations. Then click Export .exe to create the executable file you will be using to set the bios settings during deployments. If you have a standard bios password you can enter it when you create the executable. I use a password, which I showed you how to set it in part 2. Since this executable has the password in it, I can also use it to deploy to existing machines to set the BIOS of machines that have this password set in the wild. You can of course create the configuration executable without a password and apply it first and then set a BIOS password later in the task sequence if you wish.

Find the executable you created and copy it to your Configmgr source or some other location that the task sequence will have access to during deployment. I stick it in the same source as the Dell Command Configure. In your task sequence create a Run Command Line step and call it "BIOS Config - Dell Configs". Put this step sometime after the Setup Windows and Configuration Manager step. The "BIOS Configs - Dell Configs" step must occur after the task sequence has taken the computer into Windows and out of WinPE.

The Command line is the name of the executable you created earlier. Select the Package you put the executable in.
There you have it, clearing BIOS passwords, Setting a BIOS password, and Configuring the BIOS settings all in a deployment.

Friday, April 17, 2015

Using CCTK to configure BIOS settings during Configmgr 2012 OSD, Part2 - Set a standard BIOS password

This is post two of a three part post. Post one about clearing BIOS passwords is here.

When I set the password, I do it right before the Setup Windows and Configuration Manager step so it still happens in WinPE.
You may want to make sure you do an xopy CCTK and Enable HAPI step again, just in case the computer rebooted since the last time you did those steps. Those steps are described in Part 1 of this post.

The command line for the BIOS Config - Set Password is
x:\CCTK\X86_64\CCTK.exe --setuppwd=password
where password is the standard password you want to set your BIOS's too.