Wednesday, February 25, 2015

Prevent Windows 7 from Automatically Rebooting After Windows Update Patching

By default, Windows 7 wants to automatically reboot the PC after it finishes applying security patches that need a reboot to finish their installation.  This can be very annoying if you go away and leave applications running overnight, or have some other need to keep the system online.  Fortunately, it's also an easy fix.

Go to the Start Menu and enter "regedit" in the search box.  When you see the Regedit program appear in the list, right-click it and choose "Run as Administrator".

In Regedit, navigate to HKEY_LOCAL_MACHINE, then to SOFTWARE, Policies, Microsoft, Windows.

If there is a key there named "WindowsUpdate", continue on.  If not, right-click that "Windows" key and select New, Key.  Create the WindowsUpdate key.

If there is no "AU" key under WindowsUpdate, create that key as well.

Under the "AU" key, create a new 32-bit DWORD value named NoAutoRebootWithLoggedOnUsers.

Set the value of this key to "1".

Close Regedit.

Windows 7 should no longer automatically reboot after patching.

Friday, January 16, 2015

You have to know why (and how) things work...

Say what you will about the original Star Trek series, but it's long been one of my favorites.  William Shatner, Leonard Nimoy, DeForest Kelley, and the rest taught me many things.  For example, one moment in Star Trek II: The Wrath of Khan defines much of my career.  In that movie, Khan has captured the U.S.S. Reliant and used it to nearly destroy the Enterprise.

At about 7 minutes and 45 seconds into the clip above, you'll see Kirk and Spock working to enact their plan to shut down the Reliant's shields using the command console on the Enterprise.  Saavik says that she doesn't understand what they're doing.  Kirk tells her "You have to understand why things work on a starship."  His (and Spock's) knowledge of how starships work gave them an advantage over Khan and allowed them to turn the tide of the battle.

The point is that in any field of endeavor, most people will learn enough to be able to do the task.  A few will learn a bit more, usually as a result of making a mistake or having experienced some kind of problem (like an equipment failure).  Those rare few who invest the time learning as much as they can of the "how" and the "why" of the thing will excel.  When others around them throw up their hands in frustration, these few walk in, calmly assess the situation, diagnose the problem, and fix it.  That's the position you want to be in.

The best way to develop this knowledge is to always be asking "how" and "why" when you work with the tools and technologies you use.  How does a PC start up when you press the power button?  What happens when Windows begins loading?  What does an application do when it starts up?  What happens when you reboot?  And so on.  Sometimes these questions will lead you to an innovation, a way to do something better than it's been done before.

Focus on these activities and you'll find yourself with Mr. Scott's reputation as a "miracle worker"...

Tuesday, December 9, 2014

Lessons and Warnings from the Sony Breach

On or around November 24, 2014, Sony Pictures Entertainment found itself the victim of a massive computer security breach.  Employees arrived at the office to find their computers booted up to an ominous warning screen implying that all their "secrets and top secrets" were stolen and would be published online.  Computers displaying this warning had been wiped clean.  A group calling itself "Guardians of Peace" took credit for the act.

There hasn't been an official report detailing everything that's known about the breach, but there has been a fair amount reported unofficially:

  • Attackers allegedly stole as much as 100TB of information from Sony systems.  This included email messages, confidential agreements, health care information, unreleased movies, computer source code, security audit reports, and more.
  • Information leaked on the Internet by the attackers included celebrity phone numbers, scans of celebrity passports, and information about employees of other companies that worked with Sony.  The leaked information could easily be used for identity theft and other crimes.
  • The breach may have been in place as long as a year before it was discovered, which explains how the hackers got so much information.
  • There are implications that insiders helped the attackers.  A quote from someone claiming to be with the Guardians of Peace group said "we worked with other staff with similar interests to get in" and one article mentions that "the attackers knew the internal network from Sony since the malware samples contain hard-coded names of servers inside Sony's network and even credentials/usernames and passwords."
  • The malware spread across their LAN via Windows Management Instrumentation and other system administration features.
  • Systems within Sony were down for several days, reportedly, and some may still not be up.
  • Indications are that the malware that wiped the computers didn't "phone home" to its creators until it had already wiped the systems.
  • Some have hinted that the North Koreans may have been behind the attack or assisted with it, though the North Koreans have denied this.
In just about every sense, this attack was a disaster for Sony.  It took critical business systems offline, exposed confidential company secrets, exposed employees and non-employees to identity theft, and increased the potential for losses on some unreleased movies due to piracy.  Information was stolen from Sony employees at every level of the organization, and across many divisions, according to reports.

There are lessons here for any company that thinks its security is "good enough".  One article I read quoted a Sony security chief as saying it wasn't worth spending $10 million on security to prevent a $1 million loss.  On the one hand, I don't think anyone would advocate over-spending on security solutions - but what Sony has lost here is far more than $1 million.  They've lost goodwill with their employees and suppliers.  They've damaged relationships with celebrity talent.  They've exposed their employees to potential identity theft.  And they've lost revenue on as-yet-unreleased movies.  You can't put a monetary value on all this, but even the parts you can put a value on would be significant.

Since the exact details of how the Sony breach was carried out are unknown, it's only possible at this point to speculate what might have occurred and what security controls could have prevented such problems.  It seems that at least these controls must have been missing in the Sony environment, or perhaps were bypassed by the insiders who helped the Guardians of Peace group:

  • Privilege Management Software:  This software allows you to reduce the number of administrator accounts in your environment, audits how those accounts are used, and can downgrade a potentially harmful process from elevated-to-administrator to "restricted user".  It's possible that Sony gave all its employees administrator permission to their systems.  If so, this would have made it much easier to infect a system and spread to other machines.
  • Application Control Software:  This software intercepts an attempt to launch an application (or malware program) and compares the software to "known good" or "trusted" applications.  If there's no match, the software is prevented from running.  If the insiders allegedly assisting in the attack did so by bringing in software from the attackers and running it on their PCs, application control software would have flagged this software as unauthorized or unrecognized and prevented it from running - stopping the infection.
  • Data Loss Prevention (DLP):  Most companies have confidential information that would be damaging to have leaked on the Internet, whether that's price lists, contract details, customer credit card numbers, etc.  DLP software provides a way to identify potentially sensitive data flowing out through the network or being copied to removable media.  If Sony had DLP software in place, this might have prevented the terabytes of data from escaping.
  • Password Management: Several articles suggest that the leaked Sony files include passwords stored in unencrypted files with names like "password".  The use of password management software might have prevented the leakage of these passwords by storing them in encrypted and secured locations.  Other articles suggest that staff were allowed to set blank passwords, passwords that matched the account name (like your account "fred" having the password "fred").  Better management of passwords might have helped here.  

Even if Sony did have all of these in place, they might have been negated by a sufficiently knowledgeable and empowered employee working with the hackers.  However, bypassing systems like these might have tipped Sony IT Security staff off to a problem before it spread very far.

If someday an official report on what happened at Sony is published, it will be interesting to see how the attackers accomplished what they did, who helped them, and what that help entailed.  There will likely be lessons for all of us in there.

Monday, December 8, 2014

Solving the 1603 Java Installation Error

As with anything you find on the Internet… Use this at YOUR OWN RISK.  I am not responsible if you follow the instructions below, or fail to follow them correctly, and screw up your PC or someone else’s.  If you don’t understand what you’re doing in the instructions below, you’d be better off not following them. Consider yourself fully warned.

Fixing the 1603 Error

First, it’s important to understand what a 1603 error is.  It’s a somewhat generic error that can perhaps be best explained as “Some action I tried to take during the installation of this software went horribly wrong, or gave me a result I wasn’t expecting, so I decided to stop.  It was something so unexpected that I don’t have error-handling code for it to tell you what went wrong.”  This tells you a lot, and also tells you nothing.

There are multiple things that could cause this error (including but not limited to):
  • An older (or newer) version of Java was active and running during the installation, which conflicts with the version being installed

    Launch the Windows Task Manager and look for processes named java.exe, javaw.exe, javaws.exe, javacpl.exe, jp2launcher.exe, or ssvagent.exe.  If these are running, terminate them so that they don’t interfere.  Try the installation again.  If that doesn’t work, move on to the next bullet.
  • A previous version of Java that is installed is causing a problem.

    Look in your Programs and Features (or Add/Remove Programs) Control Panel for any Java versions that might be installed.  Uninstall all of these and reboot.  Then try the installation again. (The point of rebooting is to ensure that Windows is able to remove all of the older version.)
  • Your antivirus software might be preventing the installation from working.

    I’ve seen reports that YAC and some other antivirus products will prevent the Java installer from working properly.  If you’re very careful, you could try closing all the programs running on your PC, temporarily disabling your antivirus software (most antivirus tools have an option to do this), running the installation, and then re-enabling the antivirus software.  Just be VERY CAREFUL about this because while the antivirus software is disabled you have an extreme risk of malware infection.  As noted above, I’m not responsible if you follow this step and find your PC infected with something nasty.
  • Apply the latest Windows Updates.

    A previous Windows Update applied a fix to the Windows Installer service that caused a number of installers to stop functioning.  This was fixed in a later update, so making sure you have the latest Windows updates may resolve the issue (and is generally a good idea to do anyway, for the security improvement).
  • Java environment variables that are causing a mismatch in versions that are running (e.g., an environment variable that points to JRE 6u31 when you’re trying to install JRE 8u25)

    Open the System Control Panel, go to Advanced System Settings, then click the “Environment Variables” button.  Look for User Variables or System Variables that are named “_JAVA_OPTIONS” or “IBM_JAVA_OPTIONS”.  If these are present, look in the values to see if they reference any file paths.  If so, these are probably interfering with the Java installer.  Copy their values to a safe location (like a Notepad file) and delete them.  Try running the JRE installer again.  If it works, restore the _JAVA_OPTIONS and/or IBM_JAVA_OPTIONS variables’ values from the Notepad file.
  • A system PATH variable that is causing a different JRE to launch instead of the version that the installer is using.

    Open the System Control Panel, go to Advanced System Settings, then click the “Environment Variables” button.  Look under System Variables for a variable named “PATH”.  Open it and look at the value.  If it is pointing to a directory that contains a Java installation, that is most likely your problem.  When the installer is trying to run its own Java modules, it’s finding the ones in this PATH variable first.  Make a copy of the value of the PATH environment variable somewhere safe.  Remove ONLY the reference to the Java path(s) from the environment variable.  DO NOT delete the contents of this variable or Very Bad Things will happen later!
  • A user PATH variable is causing a different JRE to launch instead of the version that the installer is using.

    Open the System Control Panel, go to Advanced System Settings, then click the “Environment Variables” button.  Look under User Variables for a variable named “PATH”.  Open it and look at the value.  If it is pointing to a directory that contains a Java installation, that is most likely your problem.  When the installer is trying to run its own Java modules, it’s finding the ones in this PATH variable first.  Make a copy of the value of the PATH environment variable somewhere safe.  Remove ONLY the reference to the Java path(s) from the environment variable.  DO NOT delete the contents of this variable or Very Bad Things will happen later!
  • If you’re using Windows 2000 or XP, check the Microsoft KB article.

    Microsoft has suggestions for dealing with a 1603 error on XP and 2000.  This probably does not apply to Windows Vista, 7, 8, 8.1, or later.
  • Remnants of a previous Java version are causing a problem.

    I built a script that removes every trace of every version of Java ever used at my employer.  I did this by using a repackaging tool (such as the free AppDeploy Repackager, the now-defunct Wise Package Studio, or Flexera AdminStudio) to identify every file, folder, and registry change made by the installers.  Then my script deletes all the registry keys and files associated with it.  Because there are many risks inherent with sharing such a script, I will not do so.

    A similar tool that might help you is JavaRa.  NOTE: I’ve not actually used this tool and cannot vouch for whether it will work, or benefit you at all.  Use at your own risk!
  • Corruption of Windows, especially the registry

    In this case, or that of the previous bullet, rebuilding the system from scratch might be the only viable option.  That will be your call to make.  Just make sure you have the appropriate installers for Windows, the drivers your hardware needs, the applications you use, and all relevant license keys.

Hopefully these suggestions will help you resolve your 1603 problem with the Java installer.

If not, best of luck to you in your search for answers.

If you find another solution that works, please post a comment.

Tuesday, June 4, 2013

Enable F12 in Internet Explorer for Dell iDRAC

By default, pressing the F12 key in Internet Explorer displays the developer tools bar at the bottom of the Internet Explorer window. If the user is an administrator who needs to access the Integrated Dell Remote Access Controller (iDRAC) to work with physical servers, this can be a problem as the BIOS on the servers is configured to use F12 to select boot options during power-up. In Internet Explorer, pressing F12 displays the Developer Tools bar instead of the server’s boot options.

This can be corrected on an individual PC basis by setting the following registry key for any user who needs access to the iDRAC:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools\Disabled

This key should be created as a DWORD with the value of 1.

To block the Developer Tools for all users on a PC, the following keys can be set:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\IEDevTools]

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\IEDevTools]

Note that these keys can be set on a per-user basis, configured in the default system image, or pushed out through Group Policy preferences, set by a script, etc. – whatever makes sense in your organization.

Tuesday, January 29, 2013

How to Fix iPod Touch Update Errors

While updating my fourth-generation iPod Touch to iOS 6.1, I encountered a problem. The iTunes software generated an error that prevented the update from happening. The iPod was left in the “Connect to iTunes” mode.

I tried restarting the PC and reconnecting the iPod, but iTunes still did not recognize it.  After a number of false starts, I finally managed to get it updated and restored.

The following instructions are based on those found in multiple pages on Apple’s web site:

  • Disconnect the iPod Touch’s USB cable.
  • Hold down the home button and the power button until either the “power off” slider appears or the iPod turns itself off.
  • Hold down the home button while plugging the USB cable back into the iPod. It should now power back on and go into the same “Connect to iTunes” display. 

  • Several seconds later, iTunes will indicate that it sees the device: 

  • Click OK.
  • Back in iTunes you’ll see a button labeled “Restore iPod”. 

(Your iTunes window might look a little different from this, or contain a different date. That is OK.)

  • Click the “Restore iPod..” button.
  • iTunes will begin attempting to update the iPod to the current iOS version and restore the backup to it. If you’re lucky, this will be the end of it and your iPod will be back to normal. If so, stop here. If your iPod still didn’t restore, continue to the next step.  (In my case, I got an "unknown error" code.)
  • Verify that your iTunes software is the most current version. On Windows, launch the Apple Software Update software to see if an update is available. If so, install it. On Mac OS X, use Software Update.  (This was not the issue I had.)
  • On Windows, make sure you have the latest Windows Updates installed. Use the Windows Update control panel or the Windows Update web site.  (This also was not my issue.)
  • Disconnect all the USB devices from the computer except for the keyboard, mouse, and iPod. Try Restoring the iPod again. If this works, reconnect all the devices.  (This allowed the process to get further on my system, but it still received an error code 9.)
  • Temporarily disable your antivirus software and try restoring the iPod again. Some antivirus software can conflict with iTunes updating the iPod.  (Did not help in my case.)
  • Temporarily disable your firewall software and try the update again. Firewall software can in some cases prevent the update. (Did not help in my case.)
  • If you’re getting an error message during synchronization, look up that error number here:
    The above page provides detailed descriptions and troubleshooting steps for many different error numbers reported by iTunes.

My answer turned out to be a variation on the last bullet above.  The third-party cable I was using to do the synchronization was apparently dropping its connection to the PC every so often causing the update and restore to fail.  Swapping the USB cable out with an Apple-manufactured one solved my issue (probably in combination with disconnecting all non-essential USB devices).


The following pages provided information used to produce this article.

Sunday, December 2, 2012

VBScript: Delete a Folder if it’s Empty

It is unfortunately common that software installers will leave behind an empty folder when they are finished.  If you want to keep your system clean, you’ll need to add code to your deployment script to remove a folder from the PC if the folder is empty.

The following subroutine will, when passed the path to a folder (e.g., “C:\Test1\Test2”) will delete that folder (in the example, “Test2” but not “Test1”) if that folder is empty (i.e., contains no other files or folders).

For example, let’s say you have the following files and folders on a PC:

    • D:\Temp\Test\
    • D:\Temp\Test2\
    • D:\Temp\Test2\myfile.txt
    • D:\Temp\Test3\subfolder\

If you execute the following lines of code:




The following things will happen:

  • Since there are no files under the D:\Temp\Test directory, the Test directory will be deleted.
  • Since there is a file (myfile.txt) under D:\Temp\Test2, that directory will not be deleted.
  • Since there is a subfolder under D:\Temp\Test3, that directory will not be deleted.

Feel free to use this code as you see fit.

Sub DeleteFolderIfEmpty(folderPath)

    Dim theFso, theFolder
    set theFso = CreateObject("Scripting.FileSystemObject")
    If thefso.folderExists(folderPath)=False Then
       Wscript.echo "Folder '" & folderPath & "' does not exist."
       Exit Sub
    End If
    Set theFolder = thefso.getfolder(folderPath)
    If thefolder.files.count > 0 Then
       Wscript.echo "Folder contains " & theFolder.files.count & " file(s)."
       Exit Sub
       Wscript.echo "Folder contains no files."
    End If
    If theFolder.subfolders.count > 0 Then
       Wscript.echo "Folder contains " & theFolder.subfolders.count & _
" subfolder(s)."
       Exit Sub
       Wscript.echo "Folder contains no subfolders."
    End if
    Set theFolder = Nothing
    Wscript.echo "Deleting: " & folderPath
    thefso.DeleteFolder folderPath,True

End Sub