Bits and Dots

[#1]

Posted by: Brian R. Kneebone
Technology Consultant, Imaging and Printing Group  

HP Web Jetadmin has the ability to reach out to the HP website for several different reasons including downloading the latest firmware updates, getting troubleshooting information for particular devices, etc.  To do so, activate HTTP downloads under the "Tools" -> "Options" menu.  If your organization uses a proxy server, HP Web Jetadmin is compatible with most, but not all.  Also, it requires the entry of a manual proxy address (automatic proxies are not supported at this time).  So what do you do if your organization has an automatic proxy server?

Option 1: download firmware as needed manually from HP.com and import into the firmware repository as required.

I like recommending customers do this anyways since there can be cases where the index for firmware WJA uses takes time to get updated from what's been posted on the web by the product teams.  just go to www.hp.com/go/support and type in the name of your product.  Once you're on the main product portal select "Download drivers and software".  Instead of selecting an operating system, most commercial models have a special section for "Cross operating system (BIOS, Firmware, Diagnostics, etc.)", select this option.  You'll notice 3, sometimes four selectable options which contain the same firmware binary:

• Macintosh: This is sometimes .SIT or .DMG or .ZIP which Stuffit or modern versions of the Mac OS support natively


• Unix / Linux: This is most often a .TAR (Tarball) file which most modern versions of Unix and Linux distributions support natively


• Windows: This is sometimes .EXE (self extracting) or .ZIP file which most modern versions of Windows support natively


• Windows with Easy Firmware Upgrade Utility: This is sometimes .EXE (self extracting) or .ZIP file which most modern versions of Windows support natively.  This is a special version for Windows which was introduced recently for newer products which includes the intellgence to push the file to devices without having to know how to use the other methods described in the readme / release notes for the above options.  Not required or recommended for HP Web Jetadmin users since this just has extra bits you won't require.

All of the above options contain the release notes for the firmware plus the firmware itself (a .RFU file).  the release notes describe options to deploy the code using native tools within the operating system and/or software you can download (e.g. FTP clients) and/or using HP Web Jetadmin.

For customers looking for the latest version of JetDirect code, download the DLD's from www.hp.com/go/wja_firmware.  Note that for these files, since they aren't compressed, right-click and save-as (ensuring you save as "Any Type" otherwise it will download as text and in Windows add the .TXT extension).

Once you have the files, you simply go to the HP Web Jetadmin firmware repository and upload them as needed.  I nice feature that was added in Hp Web Jetadmin a short time ago was the ability to upload firmware and "Qualify" it for use by users with lower privaledges if you're using role-based access to limit unqualified releases.  This works equally as well for firmware you download off the web as it does for firmware WJA can import from the web directly using HTTP downloads.

Option 2: Resolve a manual proxy address from your automatic proxy

This is where a note of caution goes out.  Ensure you follow your internal IT policies and guidelines around using manually defined proxies.  Generally speaking, if manual proxies are not published, it is usually frowned upon by IT to define manual proxies.  this is due to a number of factors including:

• 
  
  Accounting for different browser connection types (e.g. VPN-connected versus locally-connected users)


• 
  
  Accounting for different browser geographies (e.g. north america versus asia-pacific versus europe)


• 
  
  Accounting for different privaledges and auditing policies (e.g. proxies used for certain user groups which are monitored for content)


• 
  
  Accounting for different target URLs the browser requests (e.g. some traffic may route internally to a different proxy for seperate sites)


• 
  
  Accounting for other JavaScript-able objects beyond the items discussed above

As you can see, you want to be careful that you abide by your corporations policies. You have been warned.

And for usability purposes, be cautious about using proxies where IP addresses are returned instead of fully qualified domain names as there`s a higher likelyhood that they may change depending on your organization`s infrastructure.  As general advice, test to see what works below if you know you`re within your IT guidelines and consult with your IT teams for internal best practices.  And where uncertain, approach your IT teams first.

So now that I've scared you, now we can explore how to make the magic happen:

• 
  
  Download the Google "pactester" tool (http://code.google.com/p/pactester/).  This is very handy and I've used it to help resolve several issues related to proxy resolution in the past outside of imaging and printing.  There's versions for Windows and Linux/Unix.  While I haven't tested on the MacOS 10.x versions, I suspect since they're command-line based and something you could theoretically do in the console that things might work.  Let me know if you find results work for you.  I'd love to publish your comments.


• 
  
  Save the .PAC or .DAT file your auto-proxy created to the same directory you extract pactester into.  Hint, for those in a Windows environment where the automatic proxy is declared in IE in the "Tools" -> "Internet Options" -> "LAN Settings" -> "Use automatic configuration script" field: copy and paste the URL into your webbrowser's address bar and save the file as needed with the .PAC or .DAT extension.  Haven't tested on other platforms, but I'd expect the same results since it's plain-text written in JavaScript.


• 
  
  On the Windows operating system which will be running HP Web Jetadmin, open the command line, navigate to the folder where you extracted the pactester files + saved your proxy configuration file and type in the following command (where <pacfile> is replaced with the file name of the proxy script you saved from the above step):
  pactester -p <pacfile> -u http://www.hp.com

You'll typically get one of two types of responses from the above command:

• 
  
  DIRECT: meaning there is no proxy which will be used for the address, so no manual proxy configuration should be required in WJA


• 
  
  List of servers typically in the form of "PROXY <ip/host/fqdn>:<port>" seperated by semicolons if multiple servers

If you get back a list of servers take the first one and use the address (IP address, hostname or fully qualified domain name) and port to enter into HP Web Jetadmin's proxy settings.  Again a reminder.  If you get multiple addresses coming back, you should definitely talk with your IT teams to ensure that you pick the most appropriate one.  Also some proxies may require you to authenticate with a service account.  If you're tempted to put in your own credentials, again a friendly warning that beyond testing you should consult internally with your IT teams to be on the safe side.  It's considered bad form to put in user credentials with interactive logon capabilities into any server-based or service-based software.

Again, a reminder, you'll want to run this command from the server that WJA is (or will be) installed on as well as point to www.hp.com since may echo back different servers and ports depending on how they are written.

Keep in mind that not all authenticated proxies work the same (manual or not).  HP Web Jetadmin is compatible with most manual proxies, but not all.  Only testing in your environment will determine whether or not this will work for your organization.  Just be safe while doing it.

Take care, B.

[#2]

I just installed Web Jetadmin 10.2 and I am still unable to authenticate to an proxy that requires NTLM authentication.  Are there any plans to support NTLM?  I don't understand why it would not be supported as it is a very common authentication requirement.  Am I doing something wrong?

[#3]

Hi Jeff, I've never given it much thought.  I typically haven't had to worry about NTLM authentication with most of my clients, but obviously this question is highly pertinent to this article.  I'm going to do some poking around on this one and find out and respond back here.  Let me see what I can dig up here.