Powershell Tips – Reboot Pending?

I’ve managed Configuration Manager 2007 and 2012 at a few organizations where reboots were suppressed for security patches.  Personally, I think 24-48 hours notice is plenty of time for users to reboot their workstations, however many times the decision is made way above my pay grade.

Pending reboots on a system can cause havoc with subsequent advertisements that go out.  I’ve seen many application failures on a system with a pending reboot.  Since most of our application deployments use a Powershell wrapper, I’ve been searching for a way to take a different path if a reboot is pending.  Some applications work just fine with a pending reboot on the system, others not so much.

The following Powershell command will let you determine in the script if a reboot is pending or not with SCCM.

Invoke-WmiMethod -Namespace root\ccm\clientsdk -Class CCM_ClientUtilities -Name DetermineIfRebootPending

Capture

Capture

 

Once you have this result, you could pipe it into anything with Powershell.  You could have it exit with a special exit code, do another action like write an entry into a log….. anything really.

I will be posting a few examples of this pending reboot check in the future.  Hope this helps.

 

Posted in Application Packaging, Powershell, SCCM 2012 | Tagged , , | Leave a comment

Script to Set Cache Size on SCCM Clients

Here’s a quick and easy way to set or change the cache size on SCCM clients.  If your organization is anything like mine, the 5 GB default is never enough, especially using Nomad.

I also set this in my OSD task sequence for new PC builds.

Just create a package and run the following VBScript – example being a command line — %systemroot%\system32\Wscript.exe SCCMCache.vbs

Dim ClientResource
Set objShell = WScript.CreateObject (“WScript.shell”)
Set ClientResource = CreateObject(“UIResource.UIResourceMgr”)
Set CacheInfo = ClientResource.GetCacheInfo
CacheInfo.TotalSize = 27680 ‘  Change this to your new cache size in MB

Posted in Application Packaging, SCCM 2007, SCCM 2012, Scripts | Leave a comment

Intel Wireless Driver Deployment With SCCM

A large part of any desktop engineers job is to keep drivers in the environment current.  It’s been debatable on the requirement to push driver updates – but in my mind updates are released for a reason.  It usually doesn’t hurt to keep drivers current.  Usually the biggest constraint is time to package, test, and deploy. 

My current client has had intermittent problems with the wireless connection on HP laptops.  We’ve had complaints of connections randomly dropping both in the office and at home (red flag!).  The list of variables that could cause this issue is endless.  Old routers, too many wireless devieces connected at home, signal strength, BIOS, drivers, etc.  Since this issue got some high level visibility we were asked to take at least one variable out of the equation – the wireless drivers.  Again, I was a little skeptical but then again – the drivers on the image were between 2-3 years old. 

Step one almost took the longest.  When I went to HP’s site the packaged drivers were not current.  Navigating Intel’s site can be cumbersome.  I finally found the link for wireless drivers (not the full Proset software).  You can find that here :  Intel Wireless Driver Download for IT Administrators

Intel provides an executable that can be run silently and is fairly quick and painless.  When you download, try running this exe.

iprodifx.exe /silent

I usually write a vb wrapper for all disitributions for logging, prerequisites, etc.  Here’s the command for vbs  (just substitue intInstallIntel and dim, etc)

intInstallIntel = objShell.Run(Chr(34) & strCurrentDir & “\iprodifx.exe” & Chr(34) & ” /silent”,1,True)

I am doing most of my targeting via SCCM collection queries rather than in the vbscript just because its a bit different for each model.

Posted in Application Packaging, SCCM 2007, SCCM 2012 | Leave a comment

VBScript For Finding a File Version

A quick post to show how to find the file version of any file.

For example:

If I want to find the file version of this driver file C:\WINDOWS\system32\drivers\Netwxn00.sys (Intel Wireless Driver) use the follwing

strAppExists =  CreateObject(“Scripting.FileSystemObject”).GetFileVersion(“C:\WINDOWS\system32\drivers\Netwxn00.sys”)

This will basically do the same as right clicking the file, go to version tab, and should the file version.  This is helpful when packaging and scripting to skip the installation of a program if it already exists. 

You can verify it’s working correctly by just echoing the following command

Wscript.Echo strAppExists

May seem a obvious but its always great to double check!

Posted in Application Packaging | Leave a comment

Windows 7 64 bit Uninstall Registry Path for 32 Bit Applications

Here’s a common question I see asked –

Where do I find the uninstall information for Windows 7 64 bit Uninstall Registry Path for 32 Bit Applications?

In XP – it was located here –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

In Windows 7 64 Bit – just add the Wow6432Node after the Software key.  Looks easy now but not if you don’t know what you’re looking for!

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\

Posted in Application Packaging | 1 Comment

Java 1.7 Auto-Update Deployment with SCCM/MDT

10/18/2013 Update – From a comment below.  I haven’t tested this as I’ve given up on Java completely. 

I just wanted to leave a note with how i got this working (there was lots of info in this thread but it was hard to find a clear step by step with success).

– Run the Java exe on a test machine, digg out the MSI + files from the %userprofile%\Appdata\…. area
– Create an MST using ORCA, set the update settings to not update etc.
– Create a blank “deployment.properties” file and have the “deployment.expiration.check.enabled=false” inside it.
– Install the MSI + MST
– Copy the deployment.properties to C:\Windows\Sun\Java\deployment
– Launch IE, browse to http://javatester.org
– Test the version with the button on the site
– Accept the security prompt (in our org. we are leaving this security level HIGH)
– Wait for any pop-up about an out of date version?
– Open up REGEDIT
– Browse to HKCU\Software\AppDataLow\Software\JavaSoft\DeploymentProperties
– You should see “deployment.expiration.check.enabled” REG_SZ false
– Retest by re-loading the Javatester.org website
– Retest by closing / reopening browser and hitting Javatester.org again
– Log off and on as a new user, repeat test to make sure the HKCU is being populated under the new user.
– Package up
– Have a beer

 

**Update 7/25/2013**  Sorry all, haven’t been as active with this as I’d like.  Unfortuntely we had to bite the bullet and get everyone upgraded to the latest and greatest.  It does seem that Oracle FINALLY sees this is massive issue and has released some patched versions for this.  Check all of the comments for the download link.  I personally haven’t even looked at the patches yet, so use at your own risk.  Please also look thru all the comments.  There any many different ways to look at resolving this at least temporarily.

 **Update 6/19/2013**  JAVA 7 UPDATE 25 RELEASED.   It appears a path was released for update 21, nothing that I can see for 25 yet.  From the comments

**Update 5/16/2013 **** PLEASE read all comments before implementing this.  Java has yet again changed the game and made the expiration date unavoidable.  There’s a lot of good info for temporary workarounds in the comments.  Key word … TEMPORARY. 

 

Unfortunately, you need a login on My Oracle Support (MSO). As I don’t have a login I cannot provide you a deep link to this particular patch.

If you have a login, you can sign-in on http://support.oracle.com, click “Patches and Updates”, then search for patch ID 16758419.

BTW: I have applied this interim patch on my PC today and changed the system date to August 10 (which is beyond the expiration date for the official public JRE 1.7.0_21). The infamous update popup did not occur, so the patch seems to work.

Oracle released an interim patch, 16758419, for JRE and JDK 1.7.0_21 (32bit only) with Auto-update Off and Insecure Java Version Message suppressed:

README for 16758419

Patch Details

Bug Number: 16758419

Product Name: Oracle JDK and JRE 1.7.0_21-fcs-b14
with Auto-update Off and Insecure Java Version Message suppressed
– Interim Patch

Platform: Windows-i586

 

some notes from Joe in the comments …

Got some bad news. If you start messing with your system date and set it to 5/16/13, even if you use the suggestions here of baseline.versions folder instead of files, you’ll get prompted. This all appears to be due to the JRE_EXPIRATION_DATE value that is hard coded to that date in 7.17. I tested it with 7.21 which has the variable set to 7/18/13 and it starts prompting you on 7/18 as expected (I mispoke in my post above 7/18 is correct). So I don’t know of any way to beat this.

I’m using this to push anyone with a JRE related app to demand from the vendor to move away from it. What a joke. 3 billion devices and counting … we’ll see about that Oracle.

Java, I do not like you!

 

Well, I am sure almost everyone is aware of the (in)famous Java updating mechanism within Java 1.7. 

Here’s the scenario if you haven’t already witnessed the madness with Java 1.7.x.  At the time of this writing, Java 1.7 update 15 was the latest version.  We package it up just like any other version, disabling auto-updates, and everything looks fine.  Then, we fast forward a few months and update 17 comes out.  No big deal, right?  Our package was set to turn Java auto-update off.  I wish it were so.  Once a user hits a webpage that uses Java, they will most likely see the following prompt.  The scary part – you’d never even know this was a problem until it’s too late.  If you deployed the latest version you wouldn’t see any error messages at all.  It’s only when a new version of Java is released that the messages start arriving. 

Your Java version is insecure.  Click Update to install the recommended secure version.  Click Block to stop Java content in your browser or Later to continue and be reminded again later.

 

error1

 

Unreal.  So let’s go thru the options here. 

Update:  Since 90% of corporate users are not local admins – that won’t work.  Result:  Service Desk Call

Block:  Block the app from running?  That’s why they are at this webpage to start with.  Result:  Service Desk Call

Later:  Well, this one kind of works.  This will at least get rid of the warning but only bring you to another!  Result:  Service Desk Call

Let’s assume a user clicks “later”  They will then see this additional popup message.  

Do you want to run this application?  Your version of Java is insecure and an application from the location below is requesting permission to run. 

 This particular site is just a Java tester site

 

error2

 So here’s our new options.

Run:  This will actually run the Java app.  Result:  No Service Desk Call (hopefully)

Update:  Another attempt to update Java to the latest version (remember, Java auto-update is turned off, right??)  Again, no local admin on most corporate machines.  Result:  Service Desk Call

Cancel:  Stops the app from running.  Result:  Service Desk Call

 

As you can see, sending this to an enterprise-wide distribution is not an option.  This would generate enormous amounts of Service Desk calls and very unhappy users.  This completely blows my mind.  I thought Adobe Flash was bad but now Oracle has topped the list.  I could go on for hours on why Oracle should disable this “feature”.  Until they do, we need a workaround.  Here’s my solution.  Not perfect by any means.  It seems to get rid of *most* of the popups.

You may have to tweak some things depending on your corporate policy/application requirements/etc. 

Remove all older versions of Java (at least 1.7 versions).  My testing with 1.6.x version has been a little strange but I realize application requirement may prevent this from happening. 

  • Verify C:\WINDOWS\sun\java\deployment directory is empty.  If not, have your install script delete this full directory.
  • You need to now create 2 text files, deployment.config and deployment.properties.  These files basically replace the command line switches in the java install.  Here are the contents of deployment.config

deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true

The top line basically tells the system where your deployment.properties file is located.  For simplicity I just stuck it in the default location but could also reside on the network.  The second line tells the system if this is mandatory.  I don’t know much more about this setting.  Just set it to “true”.

Here are the contents to put into deployment.properties

deployment.expiration.decision=NEVER
deployment.expiration.decision.suppression=TRUE
deployment.version=7.0
deployment.security.level=MEDIUM
deployment.security.mixcode=DISABLE
deployment.insecure.jres=ALWAYS
deployment.javaws.autodownload=NEVER

The key settings above are: 

deployment.expiration.decision=NEVER 

deployment.expiration.decision.suppression=TRUE

These settings suppresses the “Later” button so you are never prompted. 

deployment.security.level=MEDIUM

This is a big one also.  Still not 100% on this one yet.  The default in the Java install is “HIGH” so I hate to set this lower.  The MEDIUM setting seems to get rid of most of the popups.  The only setting I could find that completely suppresses all warning popup is “LOW” but I can’t imagine security departments allowing this.  May as well stick with the older versions of Java.

deployment.insecure.jres=ALWAYS

This setting suppresses the second popup that warns about running the Java application.  Set to ALWAYS

These 2 files need to be copied to the C:\WINDOWS\sun\java\deployment directory.  Have your script create the directory after you delete it. 

Update 3/8/2013 – NEW STEP

  • Create the folder C:\Documents and Settings\User\Application Data\Sun\Java\Deployment\security before installing Java
  • Create 2 files – baseline.timestamp and baseline.versions

Contents of baseline.timestamp is just a period ( . )

Contents of baseline.versions shows up like this.  I believe this is telling Java what the current version is for each (1.8, 1.7, 1.6, etc).  I figured out that when you are prompted it creates this file and the registry shown below.  It defaults to 1.7.0_17.  I changed that setting to 1.7.0_13 to trick it into thinking its current.   Another option to get this file is to break it intentionally and go edit this file.  Crossing my fingers…. seems to work! 

baselline.versions

It also shows up in the registy like this.

registrychangesmall

 

To automate this, you’ll need to create a script to walk the directory tree and add this to each users profile.   You can also use group policy which may be a bit easier. 

 

**Make sure these 2 files are present before installing Java. **

  • Install Java 1.7 with only a /qb or /qn switch.  No need to add any other switches since your files are now in the correct place. 
  • TEST TEST TEST!  Again, this is a far from perfect solution and differences will apply between corporations.  I am not a Java expert by any means – so let’s discuss any other options or repercussions! 

Also, a tip on locking the Java settings after deployment from the comments of Rafal below

Just a comment about config and properties file
if you want to prevent users from changing Java control properties you will need to place .locked on property you are changing in the properties mark
therefore
deployment.security.level=MEDIUM
deployment.security.level.locked
will effectivelly lockout/greyout the setting for the user

Hope this helps!

 

**Update 4/24***

Well, I managed to blow up my environment when Update 21 was released.  My group policy workaround for the files was set to update, not replace.  So if the files were already there and Java overwrote them, group policy didn’t care and saw it as compliant.  TONS of calls.  Ugh Java.

Read thru all the comments below as there are some other ideas that may work.  I think I may have thrown the white flag up and may just do some extensive end user training.  Just don’t hit the “update” button!!!

This is obviously a HUGE issue.  The blog has seen 25K hits just on this page since written.  Hopefully we can still figure it out eventually

 

Possible workaround – from Morgan in comments.  Worth trying.  Update 5/17

I created the following until Oracle gets there act together. It’s an AutoIT script that looks for the update window and then selects the ideal combination for the user. You can deploy it in the startup folder for users and there is very little CPU impact. Feel free to use and modify as you like.

http://www.autoitscript.com/site/autoit/

 

CODE HERE—- javafix.txt

 

Posted in Application Packaging, MDT, Patch Management, SCCM 2007, SCCM 2012 | Tagged , , | 220 Comments