Deploying the zenwsimport Hostname for Automatic Workstation Import
Novell Cool Solutions: Feature
By Ted Haeger
Digg This -
Posted: 3 Jan 2001
In order to effectively manage Microsoft Windows workstations, Novell's ZENworks for Desktops 3 (ZfD3) uses the corporate directory to represent workstations as discrete, manageable objects. In fact, many ZfD3 functions?such as lights-out application deployment, workstation disk imaging, enterprise desktop inventory, and remote control?do not work without having workstations represented in the directory. Workstations as directory objects provide an access point for management.
Novell's ZfD3 makes populating the corporate directory with workstation identities easier than ever before through a feature called Automatic Workstation Import (AWI). This server-based process now fully automates a task that was only semi-automated in previous versions of ZENworks for Desktops.
Two components make Automatic Workstation Import work: the client-side Workstation Manager, and the back-end Workstation Import service, which can run on Windows NT or Windows 2000 Server, on NetWare 4, and on NetWare 5. This Cool Solution focuses primarily on the client-side part of deploying Automatic Workstation Import. (For more on working with the service on the server, see this article.)
The ZfD3 Workstation Manager (client-side) component automatically attempts to register the workstation with the back-end import service by contacting an IP host named zenwsimport. This name can be resolved to an IP address using a DNS record in the workstation's local zone, or by finding it in the workstation's HOSTS table. Either way, if your workstations can resolve the hostname zenwsimport to a server running the AWI service, and the server has an associated policy to specify how to process incoming workstation registrations, new workstations will be created as you deploy the new ZfD3 client. So, let's investigate some methods for getting the zenwsimport name known to our workstations.
For most organizations, DNS will be the preferred method for resolving the zenwsimport hostname. The advantage to using DNS is that the hostname entry is managed centrally and can affect entire networks or selected sub-zones. However, using DNS presents a challenge for some environments. Many smaller businesses do not maintain their own DNS services. Some very large organizations use a flat DNS structure that does not represent the topology of their WAN or corporate directory. For such organizations, another method can be used very effectively: update the local HOSTS table files on the workstations.
At first this may sound insane. Updating tens, hundreds, or even thousands of workstations' HOSTS files may seem a task too unreasonable to justify. But remember: ZfD3 provides tools to make updating thousands of machines very easy. Specifically, the Novell Application Launcher (NAL?which I promise will be the last acronym introduced in this article, as it's starting to read like alphabet soup) provides us a way to push down changes and updates to text files.
Here are the basic steps:
- Create a new application object: set the application object to run-once.
- Add the workstations' HOSTS file to the application's Text Files page, using macro variables for the Windows system paths.
- Add an append change to the HOSTS file to add the line for the new zenwsimport record.
- Specify the OS platform you want the application to affect.
- Associate the application as a force run to a set of users whose workstations you want updated.
Ba-da-bing, you have deployed the HOSTS file updates to a group of workstations.
What? You say that's not easy enough? Okay, to make it even easier, get the four zipped AXT files provided with this Cool Solution, and follow the process below. (AXT's are Application object teXt Template files, so indeed I have introduced another acronym despite previous promises not to do so.)
Updating workstation HOSTS files with the Novell Application Launcher
Just for you, I created the application and then exported it to an application object template text file (AXT). (Okay, it actually saves me the trouble of documenting every step?I'm a very lazy writer.) The AXT file can be imported to create multiple application objects, each of which can specify a different zenwsimport host address.
To create your application, start ConsoleOne and create a new application object. Specify the Create with AOT/AXT option and then click Next.
Browse to find the AXT file for the Windows platform to which you want to push the HOSTS update, and then click Next until you get to the create application summary screen.
Open up the newly created application and associate to a test user. Use the Force run association type.
On the Common - Macros tab, change the value for the ZENWSIMPORT macro to the IP Address of your AWI server.
Test the new application, and if it works suitably well, change it to Run Once on the Run Options page, and deploy!
Notes About the Application Object Templates
What makes this application object tick? The element that makes this application work is found on the Distribution Options--Text Files page.
Here we can see that the application seeks to add a line to the HOSTS file by pulling a macro variable %ZENWSIMPORT% (from the Common-Macros page) for an IP address, and resolves it to zenwsimport. The use of %ZENWSIMPORT% as a macro makes it easy to change the address of the AWI server, and also facilitates re-using the AXT several times for different sub-zones or user groups on the network.
Notice also that the path to the HOSTS file does not specify a drive letter or Windows path (such as C:\winnt\system32). Instead, the macro %*WinSysDir% is leveraged so the application can better adapt to systems that use different paths (such as D:\windows\system32).
Windows NT/2000 and Windows 9x use very different paths for their HOSTS files. Therefore, I have provided two different AXTs, one for each major platform group. Also, you will find two additional AXT files that can be used to create an application object to remove the zenwsimport line from your HOSTS files. These may help out in your testing of this method.
Here is a zip file containing all the AXTs mentioned in this article.
By adding conditions, such as existence of a specific registry key or file, you could differentiate between a laptop machine and a desktop machine. By having two instances of the HOSTS file update application, one for each hardware platform, each hardware platform could then target a different AWI server, and thereby be imported to different containers accordingly, or be added to different workstation groups. Perhaps I'll go into that in my next Cool Solution.
Okay, one last acronym: TTFN,
If you have any questions, the Reverend Ted, aka Ted Haeger, can be reached at email@example.com
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com