For years HP has been adding expiration dates to some inkjet printer cartridges so they can’t be indefinitely refilled. There was even a lawsuit contending every HP inkjet printer since 2001 was affected by the expiration. The problem generally only affects printer users who refill their cartridges, but I’ve run into it a few times in dealing with clients who stockpiled print cartridges on much older models. In those cases, after several years on the shelf, the cartridges are still new when inserted into the printer but aren’t recognized and can never be used.

So far there seem to be three types of solutions to solving the expiring cartridge problem. The fourth “fix” is 100% guaranteed to work: find an HP model that doesn’t use chipped cartridges:

• Use Microsoft printer drivers instead of HP drivers: The Microsoft-written printer drivers that are included with Windows XP and Vista don’t check for the expiration date like HP-written drivers do. This isn’t a fix for newer printer models, which only have HP-written drivers on the market.
• Edit the HP driver’s .INI file to NOT check for the expiration date: I wouldn’t recommend this if you’re not already comfortable editting the registry or writing windows scripts. This is more relevant to newer printers and cartridges, as they don’t have an expiration date until they’re first used. Older printers with very old cartridges that have a built-in expiration date set at the factory can’t be helped by this fix. (And, remember to make a backup of the .INI file before editting it.)
  

  Start with a new cartridge. Do not install the cartridge until you do the following.

  There is an *.ini file (hpSomethingOrOther.ini) stored in the system directory (WINNT in NT and 2000) that has a name probably associated with the driver version.

  Search for hp*.ini and edit the ones with the latest dates. If you configure the printer driver first, see below, the file date should read today.

  There are two files, one will list the one you need to change, change the other one, I think it is the smaller one.

  In it there is a parameter something like pencheck. It is set to 0100. I think this is a boolean because I tried other values without effect. Set it to 0000 in the file and save the file and REBOOT.

  You can check the value in the driver configuration dialog box (found through the Help for the HP tool box, open the last entry, I think, and click on configure).

  If the grayed out box for ink check or cartridge check or something like that is unchecked, you are in business. Cancel this dialog. Do NOT click on default or the expiration check will be reinstated and when you print with your new cartridge you will get an expiration date burned into it.

  I wouldn’t trust making any changes to this dialog box without rechecking that the parameter stays unchecked. After making sure this value is unchecked, install your new virgin cartridge(s) and the expiration date(s) will read “UNKNOWN”.

  Link to full .INI-editting article.

• Remove the printer’s internal battery to reset the memory chip in the cartridges: Removing the battery with the ink cartridge installed erases the expiration date stored on cartridges not set at the factory. Battery location and ease-of-access varies greatly by printer model. Here’s a descriptin of the problem and instructions for the d125xi printer and a Fixyourownprinter.com forum thread with details on many models of printers.

[Photo credit: liewcf]

The Recovery Console is an incredibly powerful tool at times when a Windows system boots straight into a blue screen (of death) error or viruses/spyware have even made the system unusable in safe mode. Unfortuantely it’s hard to use for several reasons. Firstky, Microsoft doesn’t, to my knowledge, provide complete documentation for the Recovery Console anywhere. Also, the Recovery Console is a command-line-only interface that’s unfamiliar to most Windows users and even many non-Linux IT staff. Finally, the commands available in this environment are fewer and slightly different from those in a typical Windows shell environment.

This site, Command Windows, provides a complete list of the available commands with a description of each. Also included is documentation on some preventative measures (as usual, registry edits) that can be taken before Windows crashes to remove some of the restrictions on the Recovery Console later on. The restrictions that can be removed include disallowing Recovery Console from writing to a floppy disk, blocked access to some system folders, and not being able to use wildcards on the command line.

Have you implemented software restriction policies in Active Directory only to find that they stop working a few months later? Initial investigation may show the executable to still be blocked in the Group Policy - while the same executable now runs just fine on user desktops. This is because Microsoft’s software restriction policies are usually specific to the version of the .EXE file. I’ve heard all sorts of explanations for this, usually related to not wanting to block the function of service packs and other vital updates due to “overly restrictive software policies”… The truth is that Microsoft was smart enough to block program .EXE’s based on a hash value generated when the program was compiled from the prgrammers’ code - which means that changing the filename will not circumvent a software restriction policy.

This article is based on a recent, real-life scenario using the Internet Explorer executable, “iexplore.exe”, as the blocked program. The recent release of the IE 7.0 beta software and some freetime playing around by one of my client’s employees provided a chance for plenty of hours watching ESPN and YouTube videos on a warehouse floor and even slowdowns in getting and filling order downloads because of the use of all WAN bandwidth.

To troubleshoot failed software restriction policies I prefer to start on the client machine. To determine both whether a policy is applied correctly and the version of an executable blocked by software restriction:

• Open regedit
• Open the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Inside that key will be one or more numbered branches related to the software restriction policies applied to that machine. To see what program each policy covers, open the numbered branch, then open the Hashes branch and click on each GUID.
• Inside each GUID key will be a string value with the data “program.exe (#.#.####.#) … and so on”. The numeric value #.#.####.# describes the program version. In my case the policy applied to “iexplore.exe (6.0.2900.2180)”
• Then, go check the version of the same executable that’s now installed on the system. In this case, I right-clicked on the iexplore.exe file and selected “Properties” and then the “Version” tab. Right at the top was the file version: 7.0.5335.5.

In this case, that was the answer - the IE 7.0, iexplore.exe was blocked with a new policy and everything was back to normal. In case the solution isn’t that simple, the best thing to do is to gether more data. Enable software restriction policies advanced logging by reopening the registry and:

• Navigate to the following key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\
• Create a new string value named LogFileName
• Enter the full path and filename of a text file that can be used for logging, ie: C:\sres_log.txt

Now, every executable run on the system will be logged to the file with a reason for wy it was or wasn’t allowed to run. Details include the executable name, PID number, GUID, path name, and an allowed/disallowed/unrestricted comment with a short reason why. Since EVERY program is logged each time it is run, the log can get quite long. To keep it from getting out of control, either disable advanced logging by deleting the key or add a batch script that will truncate the log file periodically.

The newest Microsoft security fix MS06-015: titled “Vulnerability in Windows Explorer Could Lead to Remote Code Execution” breaks “My Documents” access and features in IE, Office, Explorer, nVidia, Roxio, and several other 3rd-party applications. The official hotfix for the security fix is Microsoft KB article #918165 and lists the symptoms below as indicating you will need to install it:

• Unable to access special folders like “My Documents” or “My Pictures”.
• Microsoft Office applications may stop responding when you attempt to save or open Office files in the “My Documents” folder.
• Office files in the “My Documents” folder are not able to open in Microsoft Office.
• Opening a file through an application’s File / Open menu causes the program to stop responding.
• Typing an address into Internet Explorer’s address bar has no effect.
• Right-clicking on a file and selecting Send To has no effect.
• Clicking on the plus (+) sign beside a folder in Windows Explorer has no effect.
• Some third-party applications stop responding when opening or saving data in the “My Documents” folder

Unfortunately Microsoft neglected to mention several of the third-party apps that are also broken by this hotfix. These include, but probably aren’t limited to: nVidia drivers with shell extensions, Roxio DragToDisc or Adaptec DirectCD, Hewlett Packard’s Share-to-Web software, Kerio Personal Firewall, and SolidWorkds 3D CAD products. Thankfully someone else has spent the time on the phone with Microsoft tech support to resolve these issues and posted the registry fixes not included in KB #918165.

Running low on drive letters on the Windows server? Tired of splitting tons of semi-related data between separate drives or of having to deal with folder-by-folder permissions? Of reinstalling the OS when the primary partition gets full?

…think like a UNIX admin and use Windows mounted drives to create a heirachical tree of drives. It’s simple, no more drive letters to remember or map in a startup script. Just create one lettered drive and then map each type of data, NAS device, or however else you want to segment it, to a folder in that one drive. No need for expensive LUN-aggregation software, just use the Disk Management tools in Windows. It’s even possible to migrate all the data in C:\Program Files\ to a NAS device and then use a mounted drive to make the Windows-OS see the NAS as that “Program Files” folder. Having some performance issues with Exchange or SQL Server? You can use move or add a mounted drive to a separate NAS device to separate the log and database files for both server systems.

1. Open the Computer Management control panel, then the Disk Management sub-panel.
2. Right-click the volume you want to mount and choose “Change Drive Letter and Paths”
3. Click Add, select Mount in the following empty NTFS folder and then choose one of the following options:
   • Already have a folder created: type the path to an empty folder in an NTFS-formatted volume or Browse to it
   • No empty folder created yet: click Browse and find where you’d like to place the new folder, then click New Folder and create away

Drive Number Limits: Technically you can have an unlimited number of drives when they’re mapped to folder names instead of drive letters. In reality, approaching 100 separate mounted drives can start to bog down most stock 1U or 2U servers. More RAM and a faster OS-drive (C: drive) are needed to optimize support many more mounted drives.

Article tagged: Windows, Server, NAS, SAN, drive+letters, mapped, mounted, drives, extend, add, migrate, data, compress+drive, SQL+Server, Exchange, separate, database, log, files, performance

From Windows 95 to Windows XP & Vista the “Unhandled Exception 0×80040707″ error message, pictured below, typically occurs during the installation or update of PC software. The error code is typically associated with the installation program InstallShield, which software vendors wrap around their own software packages so they can install to Windows without interferring with existing software. The error was typically associated with the paths to Shell folders in Windows (ie: the Desktop, Programs, and Startup Menu folders in a user’s or the “All Users” profiles) - there is a detailed description of changing or recreating these paths at InstallShield’s site.

The 0×80040707 error code has become more common recently, as the Data Execution Prevention (DEP) controls (screenshot link) installed by Windows XP SP2 also interfere with InstallShield’s operations and can block its access to the Windows shell folders mentioned earlier. If your shell folder paths are all correct, the likely culprit of the error is Windows’ DEP and these steps should resolve the issue:

1. Find the primary installation file for the program you were installing. If it’s not a single-file installer it’s usually “setup.exe” on a CD, but you can either check the AUTORUN.INF file to see what program it’s calling or dig through the folders on the CD (/bin/, /eng/, and /driver/ are common folders where the true installer program is nested when the setup.exe is just a fancy GUI program).
2. Right-click the installation program and select “Run As…”. If it doesn’t show up the then file may not be an executable > start over at step #1 and look for other files.
3. Uncheck the “Protect My Computer And Data From Unauthorized Activity” box, this deactivates DEP for this executable and its child processes, and click the “OK” button.

A new security exploit for Windows, attached to .WMF files, is floating around the ‘net, Security Focus currently has limited details on this zero-day expoit, ID’d as BID 16074. The bug is capable of remote code execution - which means it can be used to install any virus, trojan, rootkit, or program that the “publisher” sees fit to point it at. The exploit code can infect a machine by viewing a web site with an infected image, opening a folder containing infected files with Windows Explorer, or even when Google Desktop indexes an infected file (thanks to the F-Secure blog for this info). I’m guessing that the exploit code in contained in the WMF file’s headers, since it’s not necessary to open the WMF file to infect a system.

This WMF-exploit can install on fully-patched XP machines, although it appears that McAfee - Exploit-WMF, Symantec - Bloodhound.Exploit.56, TrendMicro - TROJ_WMFIOO.A, and F-Secure - W32/PFV-Exploit have already issued updates for their antivirus programs that will detect the exploit (though most of the attached viruses were already detected).

Since this is a zero-day exploit, there is no patch for the problem available for Windows systems. Vulnerable Windows versions are currently all flavors of Windows XP, that includes Home, Pro, Tablet and Media Center versions. I imagine that Windows 2000 is vulnerable and Windows Vista is probably vulnerable, especially if it has Firefox <1.5 or Opera browsers installed (since both browsers attempt to use “Windows Picture and Fax Viewer” to open WMF files).

I recommend all Network Admins block the following domains at the firewall (obfuscated so hotlinks aren’t auto-created by browser tools or desktop search engines, thanks to F-Secure for the URLs):

• unionseek (dot) com
• crackz (dot) ws
• tfcco (dot) com
• iframeurl (dot) biz
• beehappyy (dot) biz

Article tagged: windows, security, wmf, media, exploit, list, block, blocked, sites