The VBScript Network and Systems Administrator's Cafe:

Microsoft Windows

Sep 2 2008   3:44PM GMT

Google’s new browser, Chrome scheduled for release today



Posted by: Jerry Lees
Google Chrome, tech news

Well, the blogosphere is currently in a frenzied state about the new Google Chrome browser– and there still isn’t a download page for it. It’s gotten to such a point that even searching Google won’t bring up a link for the browser from google itself– which is actually kind of funny if you think about it.

I’ll be posting information to this article as it becomes available throughout the day, so check back often or bookmark the page to get the latest information on thenew Google Chrome Browser.

 It appears that for a time there was a download page, tons of sites link to it but the page simply redirects you to the google home page at this time. I’ve seen some speculation that the response was overwhelming Google’s servers… I doubt that seriously. I’m betting it is simply sheer marketing, generate a frenzy and release it later. The official google blog has a posting yesterday claiming the release to the public was an accident… oops.

 At any rate, while the browser isn’t available to download yet, I did manage to find some Chrome screenshots that were not hosted on google’s site– and are still available to view over at pcworld.

There’s more to come as information becomes available. For now, the best information I’ve seen is that the download is supposed to be available at 2pm EST and will be available at the  Google Chrome Page. but while you wait, you can read the comic they put out that supposedly explains how it works.

Mar 7 2008   10:22PM GMT

Eventlog search tool — Find quick help with windows event log entries



Posted by: Jerry Lees
DataCenter, Exchange, Networking, Security, Administration tools

While not VBScript related, I found this Microsoft Eventlog and Error Message Search a few days ago as I stumbled around looking for tools that I thought network administrators would need on my site that I’ve been toying with– I had to share the tool with you as well!

 The tool itself is an awesome resource, similar to EventID.net– except it’s FREE and it comes from Microsoft themselves providing links to Microosft content about the event entry or error message.

 You can search for any combination of the following:

Microsoft Product|
Version
Message ID
Event Source
File Name
Language

When you do it takes you to a search result page that lists the available results for your specific search, each seem to have not only an example of the message, but also an explanation of what the event means…. and the best part a section entitled User Action that gives a possible solution for the problem!

 Enjoy the tip!


Mar 4 2008   1:57AM GMT

Determining properties and methods used in a WMI object for use in a vbscript.



Posted by: Jerry Lees
VBScript, DataCenter, Development, WMI, Windows Management Interface

In this entry we’ll take a look at the microsoft documentation for win32_printerdriver and determine how we can determine what values to use to get data once we’ve created a script to get set of data back from a WMI object into a collection object. Most of the previous discussion can be read, in order in my blog but here are links in order, if your just tuning in:

Finding HP Printers using PCL6 Drivers with WMI
Using error control in a vbscript to recover from odd errors
Using Set, GetObject, ExecQuery, and For Next in VBSCRIPT to use WMI objects

Microsoft has a great deal of documentation here on the win32 WMI classes.  However, here is an excerpt from their win32_Printer class. Most of their documentation is written for c/c++ programmers it seems– don’t let that scare you off, you don’t need this code in yours nor do you need c/c++ experience to use them.

Below you see the first line creates a “class” called Win32_PrinterDriver that is of a type called CIM_Service. Essentially, a class contains data and tools you can use in your programs. CIM_Service is just the name of the data type the class is created as– you’ll see references to CIM all over the place with WMI. It stands for Common Information Model, check out the preceding link for more information.

After that, the items in curly braces ( {} ) are the actual names of the properties and what types of data they contain. Again, as long as you are using the data in strictly Vbscript code you don’t even need to know what the type is– VBSCRIPT takes care of that for you. However, on ocassion you’ll see a “type mismacth” error in your code. This is simply referring to the fact that you have put a value in a variable of one type (a string for example) into a variable that is meant to have another type (an integer for example), typically this happens when you use a external component that was written in another language that is more strict about the data types than vbscript, like c, c++, or others. (Which is almost all of them outside of the Visual BASIC family)

class Win32_PrinterDriver : CIM_Service
{
  string Caption;
  string ConfigFile;
  string CreationClassName;
  string DataFile;
  string DefaultDataType;
  string DependentFiles[];
  string Description;
  string DriverPath;

};

In the code I wrote for this series I used Wscript.echo to print the data to the screen inside the For Each/Next loop, like so:

Wscript.Echo “DriverPath: ” & objItem.DriverPath

Remember, objitem was a collection of printer driver information objects?
Notice the last part of that line, .DriverPath?
Notice the last line I gave you from the microsoft documentation?

Yeap, they are both DriverPath! There’s a reason… they are the same thing! Essentially, ANY of the items listed in the Win32 classes can de used in conjuction with a collection object– providing you have collected the same type of object with a WMI object before hand! So this documentation is like GOLD for a systems administrator! So, if you didn’t take a hour or 50 before when I gave you the link check it out here again.

For example, I didn’t use the property Version in my original code. If you needed this information in the program you could add another line in the For Each/Next loop to gather that information as well! Like so:

WScript.Echo “Version: ” & objItem.Version

You can do that with any of the properties and methods in the win32_printerdriver class, and it expands beyond that to all of WMI.

One thing to keep in mind with much of WMI is that it is dependent on the driver or hardware manufacturer to provide the information– not all manufacturers provide that information 100% reliably, so you’ll have to play and tweak what your hardware vendor does give you. My bet is even if it’s not 100% of all the information available, it will be more than you had to start with without hours of digging.

So, here is the original code again. Take a few minutes to play around with the code and the win32_printer driver documentation and see what interesting pieces of information you can pull out of WMI.


On Error Resume Next
strComputer = “.”
Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
For Each objItem in colItems
Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
Wscript.Echo “DataFile: ” & objItem.DataFile
Wscript.Echo “DriverPath: ” & objItem.DriverPath
Wscript.Echo “Name: ” & objItem.Name
Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
WScript.Echo “_________________” & vbcrlf
Next

That concludes this series!

 Extra Credit: Can you modify the code above to pull actual printer hardware/software data from Win32_Printer? Hint: stay clear of the properties with a [] after them for now, they will potentially trip you up. And also, remember just because it pulled back one value that was blank doesn’t mean you did something wrong– some items aren’t populated by hardware vendors to WMI unfortunately.


Feb 29 2008   10:30PM GMT

Using error control in a vbscript to recover from odd errors



Posted by: Jerry Lees
Development, VBScript, Error control, Windows Management Interface

In my last installment, Finding HP Printers using PCL6 Drivers with WMI, I gave you a handy script snippet that showed you how to pull the names of the printer drivers for your printers shared on a print server. In the script I used a few pieces of code that may not be familiar to everyone. In the next few installments we’ll explain better what the script does and how it does it—so hopefully you can begin applying the knowledge elsewhere…

The script was basically (line numbers included as a reference):

1. On Error Resume Next
2. 
strComputer = “.”
3. Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
4.
Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
5.
For Each objItem in colItems
6. 
    Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
7. 
    Wscript.Echo “DataFile: ” & objItem.DataFile
8. 
    Wscript.Echo “DriverPath: ” & objItem.DriverPath
9.
     Wscript.Echo “Name: ” & objItem.Name
10.
   Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
11.
   WScript.Echo “_________________” & vbcrlf
12.
Next

In line 1, the statement On Error Resume Next may be new to you. This statement basically keeps your script from breaking completely and not completing due to a minor error. The down side of this is that if your code isn’t tightly checking for errors it will continue to run with potentially bad logic and cause quite a bit of havoc on your network. IMHO, you should try to avoid it where ever possible. In this case it wasn’t possible because there were to many unknowns.

As an FYI, The brother to On Error Resume Next is On Error Goto 0, basically this turns error checking back on. So, if you need to use it in an area where you’re not certain a piece of code may or may not encounter an error from time to time it’s best to turn error checking back on after that piece of code completes its work.

Consider this example code that has errors:

Wscript.echo “Stepping through ‘Y’ from 1 to “ & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
Wscript.echo “Did this line print?”

Of course, if you run this it won’t complete, it will display something similar to:

Stepping through ‘Y’ from 1 to
C:\www.websystemsadministration.com\errorcontrol.vbs(2, 1) Microsoft VBScript runtime error: Object doesn’t support this property or method: ‘Wscript.echoo’
 

This tells us there is an error in line 2 of the script… and gives us a slight hint (sometimes) of what the error is. In this case, we’ve user a function of the Wscript object that does not exist, echoo. Of course we want to know about that. But suppose we didn’t? Well, this would stop vbscript from complaining:

Wscript.echo “Stepping through ‘Y’ from 1 to “ & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
Wscript.echo “Did this line print?”

Now it displays:

Stepping through ‘Y’ from 1 to
Did this line print?
 

Notice it skipped the line with an error and went to the next line? To turn error checking back on we just adjust the script this way—but we add a final line with an error to see if it breaks on an error:

Wscript.echo “Stepping through ‘Y’ from 1 to ” & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
On Error Goto 0
Wscript.echo “Did this line print?”
Wscript.echoo “What about this new line?!?!”
 

Still the same output, but now you see an error… because we turned error checking back on!

Next installment, I’ll  Explain the Set and the Getobject section of the code.

Extra credit: There is a “soft error” in the script that would never cause the script to break, but cause you TONS of debugging time. Did you find it in the code … or the output? Post a comment and I’ll let you know what I think it is in the comments section in a few days!


Feb 29 2008   2:45AM GMT

Finding HP Printers using PCL6 Drivers with WMI



Posted by: Jerry Lees
Development, Networking, VBScript, Printer Administration, Printers, Error control, Windows Management Interface

Recently, at my work we had a situation where users were reporting the printer was not printing their documents and/or it was printing very slowly. After digging into the problem, I found:

1. the documents were spooling just fine to the printer

2. the documents were not hanging in the printer

3. Sometimes there were documents printing correctly when the user printed

4. on occasion the documents “didn’t print”

Of course, the nearest printer doing it was on the floor below me… I hate stairs. ;-) After digging into it, wasting a ton of paper– and burning untold amounts of Mountain Dew and Dorito calories; I found that the print jobs were always producing printouts! Sometimes it was the document I printed and sometimes it was a single page with the following message in the documents place:

error:

Subsystem:  KERNELError:  IllegalStreamHeaderOperator:  0×0

Position: 0

 The operator and position line held various values, but was always the same first 3 lines. What I found after extensive digging was that this issue was a PCL6 error message. Some people were saying it was a network error and others were saying it was a server print driver error– Don’t they always say it’s one of these, regardless of the problem?

Those who were saying it was a network error were advising that I pulled out a sniffer, like wireshark because packets were being corrupted. I didn’t think this was good advice. First, pulling a sniffer out to troubleshoot printing was like pulling a blowtorch out to light a campfire… sure it will work, but it’s a lot of extra work! Also, I knew that Microsoft printing is done like most things Microsoft– over TCP ports 138,139, and 445 (I believe)– most importantly TCP, since TCP has error correction built in via a checksum.

The others who were saying it was a server issue were recommending that I upgrade ALL the printer drivers on the server. This was quite an undertaking since there were 40 or so printers on the server of various models– most of them made by HP. Knowing HP, the drivers were bundled together into one package and upgrading the drivers for one printer would likely change a bunch of printers. To much risk! 

I did find a few needles in the google hay stack, that were saying the problem was typical for PCL6 and to simply switch the driver back to PCL5. Since both driver types were installed when I installed the printer drivers (always a good idea) I thought I’d give it a shot. Tah Dah! It worked like a charm, with no changes in the documents printer that I could see.

Now that I had one printer fixed, but had to point and clickety click to find the other’s using PCL6 drivers. To much work! So I wrote a quick script to get the bulk of the printer drivers that were being used by the print server so I could focus on the ones needing changing.

Here is the script source, copy it to a .vbs and either; run it from the print server as is or change the second line between the quotes from a period to the name of the print server: (Note: I recommend you run this from the command line with cscript scriptname so you don’t get bombarded by popups)

On Error Resume Next

strComputer = “.”
Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
For Each objItem in colItems
    Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
    Wscript.Echo “DataFile: ” & objItem.DataFile
    Wscript.Echo “DriverPath: ” & objItem.DriverPath
    Wscript.Echo “Name: ” & objItem.Name
    Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
    WScript.Echo “_________________” & vbcrlf
Next

That’s the end of the script! You’ll want to look at the “Name:” lines for the string PCL6. Not all drivers have PCL6 in the name, but a good majority do so it should save you some time!

Take a bit of that time to leave me a comment letting me know if this was helpful!

 Good luck!