For the moment comments are moderated, so if you’d like an account email or IM me and I’ll hook you up. Just ignore that Register link, since I’ll probably be removing it anyway.

Usually Prompted Macros in ZENworks application objects only prompt for values on their first runs. To create one that will prompt for a macro value every time, add the following to a Run after termination script (or append it to the end of your script if you already have one):

RD C:\NALCache\ETREE\.Application-Name.OU.OU.O /S /Q

REG.EXE DELETE HKCU\Software\NetWare\NAL\1.0\Distribute\TREE_NAME\XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /f

REG.EXE DELETE HKLM\SOFTWARE\NetWare\NAL\2.X\Macros\TREE_NAME\XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /f

Script Engine: %*WINSYSDIR%\cmd.exe /c
Script Extension: .bat

Replace .Application-Name.OU.OU.O with the DN of your application object.
Replace TREE_NAME with the name of your eDirectory tree.
Replace XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX with the GUID of the application object.

I was trying to write an AutoIT script to manipulate the Firefox user.js preferences files, which are stored in the users’ Firefox profile folders. Unfortunately with Firefox, the initial user profile is created in a “salted” directory under %appdata%\Mozilla\Firefox\Profiles. The folder name uses a randomly generated 8-character string followed by a dot and the word default, like this: df3etnz3.default. This can make scripting modifications of the user preferences a real pain in the ass, as you can’t be sure what the name of the user profile folder is.

Fortunately, there’s a file named profiles.ini in %appdata%\Mozilla\Firefox that lists the folder name, so we can pull the information from there. The initial profile will be listed on line 7 of the profiles.ini so:

; Find the Firefox user profile
 $file = FileOpen(@AppDataDir & "\Mozilla\Firefox\profiles.ini", 0)

; Extract the raw profile path
 $rawpath = FileReadLine($file, 7)
 FileClose($file)

; Extract the actual Firefox profile directory
 $mozfolder = StringRight($rawpath, 16)

; Create Profile Path variable
 $mozpath = @AppDataDir & "\Mozilla\Firefox\Profiles\" & $mozfolder

Now you can just reference the profile path using $mozpath.

Because I work for a large advertising conglomerate -

BrainStorm, ThinkTank, BrightIdea, WowFactor, BreakThrough, TechSavvy, PopCulture, MediaBlitz, StarPower, FastTrack, ComfortZone, GamePlan, TouchBase, HotConcept, MindSet, NextLevel, DayDream, KnowledgeBase, CriticalMass, RazorsEdge, OldSchool, TeamPlayer, WinWin, TaskForce, MileStone, CoreValue, MasterPlan

Of course, I’ll never get to use these…we’ll wind up giving them some ridiculous set of numbers and letters that no one can remember like NYNWPRPZPSN0104 or something equally inscrutable.

In most situations, when I need to run an installation using Local Administrator rights on a locked down workstation, using ZENworks I can just set the Application Object to Run as unsecure system user and be done with it. This allows the installer to interact with the desktop so I can still give the users progress bars and dialog boxes, but the install runs with administrative rights.

Unfortunately Run as unsecure system user requires an imported workstation object, and while the workstation import service is working flawlessly at many of our sites, it’s not hitting every computer in others and broken in some (thanks in large part to servers being moved around in the tree as part of an ongoing re-engineering project).

Usually this isn’t such a big deal for us. If we need to get something deployed with elevated privileges, we whip up an AutoIT script that drops the setup files into the %temp% directory and then use RunAsSet to install the program as one of our local Administrator accounts. The reason the files need to be dumped down to the local machine is that those local admin accounts are not network accounts and have no rights to the server volumes. As soon as the RunAsSet command takes effect, the script can’t access the source files if their still on the server.

Enter Microsoft Office 2007. The source folders for this monster total well over a gigabyte, which would need to be copied to the local hard drives of hundreds of systems at a time before the installs could even begin (and mind you, it takes a while to install Office as it is). What I really needed was a way to execute the installation from our Netware servers but using a local Windows administrator account’s rights.

This will take two scripts (you might need three if you don’t use ZENworks). In the Installer script, you’ll need a network account that can map a drive to the installation source folder. It should only need Read and File Scan on a Netware network.

First Script: Launcher.au3

; Hide the tray icon
AutoItSetOption(”TrayIconHide”, 1)

; Launch Installer
RunAsSet(”localadmin”, @ComputerName, “password”, 0)
RunWait(@TempDir & “\Installer.exe”)
RunAsSet()

Second Script: Installer.au3

; Hide the tray icon
AutoItSetOption(”TrayIconHide”, 1)

; Define our command line
$cmd = “I:\setup.exe /adminfile I:\Updates\Office2007Install.msp /config I:\Enterprise.WW\config.xml”

; Map a drive to the installation source
DriveMapAdd(”I:”, “\\path\to\installer\files”, 0, “.user.ou.ou.o”, “usrpassword”)

; Run our command line
RunWait($cmd)

Now compile both of the files into executables, create a ZENworks application object that drops them both into into the temp directory and then fires up the Launcher.exe program. Alternatively, you can either write a batch file to do that or use a third AutoIT script:

Optional Script: Starter.au3

; Hide the tray icon
AutoItSetOption(”TrayIconHide”, 1)

; Start the whole process
FileInstall(”C:\SRC\Launcher.exe”, @TempDir & “\Launcher.exe”, 1)
FileInstall(”C:\SRC\Installer.exe”, @TempDir & “\Installer.exe”, 1)
Run(@TempDir & “\Launcher.exe”)

There may be a more elegant way to do this, but so far this is the only method that has worked for me. I’m open to suggestions on ways to improve it and would especially like to know if anyone can come up with a way to get it all into one script. Comments are held for review on my site so don’t expect to see them show up right away, but the new dashboard in Wordpress 2.5 makes them kind of hard to miss so it won’t take long.

שֵׁת ירד

Another server naming scheme, discarded because we have offices in places that actually experience these conditions.

Maelstrom, Typhoon, Hurricane, Tsunami, Vortex, Whirlwind, Cyclone, Tempest, Tornado, Monsoon, Sandstorm