Posts Tagged ‘ZCM’

A Wrinkle with a Bundled Wireless Driver and DPInst32…

February 21st, 2013 by Jacob Elert | No Comments | Filed in Application Packaging, Wireless, Workstation Management

Fellow Coreteker Scott DeLand and I were recently working on a “QC” for some bundled wireless drivers, for which the customer used DPInst32.exe to install the drivers.  After the wireless driver folder has been installed to C:\ExamplePath, DPInst is launched to install that driver.  Here’s what the launch action originally looked like in ZENworks Configuration Manager (ZCM):

Command:
${WinDisk}\ExamplePath\Company\Wireless Driver\DPInst32.exe

Command Line Parameters:
/s /PATH ${WinDisk}\ExamplePath\Company\Wireless Driver

Working Directory:
${WinDisk}\ExamplePath\Company\Wireless Driver

There were a few problems with this, though.  For one, all of the installed driver folders had spaces in them.  When spaces are present in the command line parameters for some executables, they will fail without special care… and DPInst is included in this list. 

The other problem was that the install wasn’t creating an OEM file in C:\Windows\inf.  When a new driver is installed, it should create a new OEM file with an incremental counter… so if the last OEM file was OEM94.inf, the next driver install will create an OEM file called OEM95.inf.  Scott pointed out that the drivers weren’t creating a new OEM file… were they really working? 

We tested with the command line and found that if we didn’t use quotes around the /PATH parameter and the parameter contained spaces, DPInst would not work.  Now the Command Line Parameters looked like this:

/s /PATH "${WinDisk}\ExamplePath\Company\Wireless Driver"

But there was still another problem:  On some machines, this action would fail with an exit code of 768 — and on some bundles, a new OEM file wouldn’t be generated.  Exit code 768 occurs when there is already a wireless driver on the machine, which we discovered previously.  We solved the new issue by adding code 768 as a success return code in the launch action, allowing the process to complete.  The other thing that was discovered was that if the driver was of the same type as another already installed driver, it wouldn’t create a new OEM file.

I thought I’d pass this along to see if it might help others!

 

Did you like this? Share it:

Tags: , , , , ,

Remotely Reboot a Bunch of XP Workstations…

April 5th, 2012 by Jeremy Pavlov | 2 Comments | Filed in Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

I got an interesting question from a co-worker today (we’ll call him “Ray” to protect his identity).  Ray wanted to know if it’s possible for his customer to reboot a bunch of workstations at once, in a way other than the customer’s workstation management system. 

The customer is in the midst of a major migration from XP to Windows 7, and simultaneously from Novell ZENworks 7 to Novell ZCM 11.  Ray’s team has put together an amazing set of automatic deployment steps that take the ZENworks-controlled XP machine all the way to a completely-deployed, domain-managed, ZCM-controlled Win 7 machine with all needed applications installed, via a method called “Zero Touch Deployment”.   And it all kicks off with a reboot — but the only problem is that the bundled reboot in the old ZENworks is not always reliable.

Note: This particular customer’s machines are XP, all in one domain, all are resolvable (either via WINS or DNS), and can all be managed by a single set of credentials; allowing remote administrative execution and permitting the following to work.

So when Ray asked the question, I said, “Absolutely!”  I can do that, and not even break out PowerShell (or bash, for that matter).  Ray had nothing more than a list of computer names, but that is all we need.  Let’s do it old-school, with a DOS batch “for” loop.  Man, I love my job… 

First, the input file; it is just a single list of computer names or IP addresses, one-per-line, in a TXT file.  We put them in a file called C:\TEMP\RemoteRebooter-Input.txt, and here’s a varied example of how it might look:

pc1
10.2.1.3
wks22.domain.local
192.168.33.44
amyscomputer

The script is a bit on the simple side, but does the job.  I call this RemoteRebooter.bat, and notice that it calls the other input file by name:

@ECHO OFF
@Echo Process RemoteRebooter...
@For /F "tokens=*" %%Q in (c:\temp\RemoteRebooter-Input.txt) Do @(
1>&2 ECHO Rebooting: %%Q
shutdown -m \\%%Q -r -f -t 20 -c "Rebooting in 20 seconds via %0 -- please save your work quickly."
)
1>&2 type nul
@ECHO Complete!

If you need details on the shutdown flags, type shutdown /? into a command prompt.  And I’m not sure if I should mention it here, but if you want this to work on Windows 7, you have to change the syntax a bit, flipping hyphens (-) to slashes (/).  And of course, this is only one way of doing it, and I know you all have others. 

Make sure to drop a comment and tell us how *you* do it!

 

 

 

Did you like this? Share it:

Tags: , , , , , , , , , , ,