Chapter 19 Creating Server Policies
This chapter discusses each of the various policies available to manage the servers in your environment.
What Is a Server Package?
A server package contains a set of policies associated with agents that run on servers. These policies are expected to give policy information and configuration behavior to these agents and may be associated with the server, a group of servers, or a container.
The agents follow the expected walking of the tree to locate their server package. Namely, they find the search policy and then use the order specified in the search policy, or they use the default. The default is to search for a server package associated with the server, then search the group of servers, and finally search the container. The first policy package is the one that the agents use.
Previous releases of ZENworks introduced a Distributed Server package. The Distributed Server package is unique to the Server Package because of how the package is delivered to the server. The Distributed Server package is delivered to servers via ZENworks Policy and Distribution Services, namely Tiered Electronic Distribution (see Chapter 25, “Setting Up Tiered Electronic Distribution (TED)” for more information).
The Distributed Server package must be included in a Distribution and then sent to the servers that are to apply the policy. Distributions are sent to servers who subscribe to the channel into which they are placed.
To have a server package, you must first create the policy package. To create a server package, do the following:
1. Start ConsoleOne.
2. Browse to the container where you want to have the policy package. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package to many containers in your tree.
3. Create the policy package by right-clicking and choosing New→Policy Package or by selecting the Policy Package icon on the toolbar. This will launch a wizard to help you in the creation of your package.
4. Select the Server Package object and click Next.
5. Enter the desired name of the package in the Policy Package Name field and select the container where you want the package to be located. The Container field is already filled in with the selected container, so you should not have to browse to complete this field. If not, click the browser button next to the field and browse to and select the container where you want the policy object stored. Click Next.
6. Select Define Additional Attributes to go into the properties of your new object and activate some policies. Click Finish.
7. Check and set any policies you want for this server package and click OK.
The following subsections describe each of the fields and property pages available in the server package.
All the policies for servers are activated within the Policies property page. Initially the page is on the General policies. As other platforms are selected, additional policies are displayed. You can select which platform to display by placing the mouse over the small triangle on the right side of the Policies tab. This activates a drop-down menu that enables you to select which platform-specific page you want to display.
The following sections briefly discuss each of the policy pages, and then we cover the specifics of each policy.
When you first go into the properties of the server package you are presented with the Policies property page. The Policies page first displays the General category. All the policies activated in the General category are active for all server platforms supported by ZENworks and associated with the server.
Figure 19.1 shows the initial property page of the server package.
As you can see from Figure 19.1, currently six policies are available to all the platforms supported by ZENworks. They are Dictionary Update policy, Imaging Server policy, Inventory Rollup policy, Workstation Import policy, Workstation Removal policy, and ZENworks Database policy. And if you click the Add button you can include additional Wake on LAN policies. These, as well as all the other policies, are discussed later in this chapter.
To activate a policy you simply need to click on the box to the left of the policy. You can go into the details of the policy and set additional configuration parameters on that specific policy.
Within the Policies tab you can select the Windows page. This page displays the policies available for your Windows servers. These policies include Dictionary Update policy, Workstation Import policy, Workstation Removal policy, and ZENworks Database policy. See Figure 19.2 for a sample of the Windows page.
As you can see in Figure 19.2, when appropriate, the same policies are under both the General and the Windows properties pages. When you select a policy in the Windows page, it supercedes any selections that may have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy will be used instead of the policy set in the General category. Also, only the policies selected in the platform-specific tab are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page, and the Workstation Removal policy is selected in the Windows page, agents on a Windows Servers system use the General Import policy, and the Windows Removal policy is activated.
Within the Policies tab you can select the NetWare page. This page displays the policies available for NetWare servers. These policies include Dictionary Update policy, Inventory RollUp policy, Workstation Import policy, Workstation Removal policy, and ZENworks Database policy. See Figure 19.3 for a sample of the NetWare page.
As you can see in Figure 19.3, when appropriate, the same policies are under both the General page and the NetWare page. When you select a policy in the NetWare page, it supercedes any selections that may have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy is used instead of the policy set in the General category. Also, only the policies selected in the platform-specific page are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page and the Workstation Removal policy is selected in the NetWare page, agents on a NetWare system use the General Import policy, and the NetWare Removal policy is activated.
Within the Policies tab you can select the Linux page. This page displays the policies available for Linux servers. These policies include the Dictionary Update policy, Inventory RollUp policy, Server Down Process, Workstation Import policy, Workstation Removal policy, ZENworks Database policy, and ZENworks Server Management policy. See Figure 19.4 for a sample of the Linux page.
As you can see in Figure 19.4, when appropriate, the same policies are under both the General page and the Linux page. When you select a policy in the Linux page, it supercedes any selections that might have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy is used instead of the policy set in the General category. Also, only the policies selected in the platform-specific page are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page and the Workstation Removal policy is selected in the Linux page, agents on a Linux system use the General Import policy, and the Linux Removal policy is activated.
The Associations page of the server package displays all the locations in the tree (containers) where the policy package has been associated. These associations do not necessarily reflect where the policy package is located in the directory. The agents associated with servers that are in or below those containers have this policy package enforced. Clicking the Add or Remove buttons enable you to add or remove containers in the list associated with this policy.
To create a Distributed Server package, do the following:
1. Start ConsoleOne.
2. Browse to the container where you want to have the policy package. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package to many containers in your tree.
3. Create the policy package by right-clicking and choosing New→Policy Package or by selecting the Policy Package icon on the toolbar. This will launch a wizard to help you in the creation of your package.
4. Select the Distributed Server Package object and click Next.
5. Enter the desired name of the package in the Distributed Policy Package Name field and select the container where you want the package to be located. The Container field is already filled in with the selected container, so you should not have to browse to complete this field. If not, click the browser button next to the field and browse to and select the container where you want the policy object stored. Click Next.
6. Select Define Additional Attributes to go into the properties of your new object and activate some policies. Click Finish.
7. Check and set any policies you want for this server package and click OK.
The following subsections describe each of the fields and property pages available in the server package.
All the policies for servers are activated within the Policies property page. Initially the page is on the General policies. As other platforms are selected, additional policies are displayed. You can select which platform to display by placing the mouse over the small triangle on the right side of the Policies tab. This activates a drop-down menu that enables you to select which platform-specific page you want to display.
The following sections briefly discuss each of the policy pages, and then we cover the specifics of each policy.
When you first go into the properties of the server package you are presented with the Policies property page. The Policies page first displays the General category. All the policies activated in the General category are active for all server platforms supported by ZENworks and associated with the server.
Currently five policies are available to all the platforms supported by ZENworks. They are Server Inventory Policy, SMTP Host, SNMP Trap Targets, ZENworks Database, and ZENworks Server Management. If you click the Add button, you can include additional Copy Files, Prohibited Files, or Text File Changes policies. These, as well as all the other policies, are discussed later in this chapter.
To activate a policy you simply need to click on the box to the left of the policy. You can go into the details of the policy and set additional configuration parameters on that specific policy.
Within the Policies tab you can select the Windows page. This page displays the policies available for your Windows servers. These policies include Server Down Policy, Server Inventory Policy, Server Remote Management Policy, SMTP Host, SNMP Trap Targets, ZENworks Database, and ZENworks Server Management. If you click the Add button, you can include additional Copy Files, Prohibited Files, Scheduled Down, Scheduled Load/Unload, Server Scripts, or Text File Changes policies.
The same policies are under both the General and the Windows properties pages. When you select a policy in the Windows page, it supercedes any selections that might have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy will be used instead of the policy set in the General category. Also, only the policies selected in the platform-specific tab are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page, and the Workstation Removal policy is selected in the Windows page, agents on a Windows Servers system use the General Import policy, and the Windows Removal policy is activated.
Within the Policies tab you can select the NetWare page. This page displays the policies available for NetWare servers. These policies include Server Down Policy, Server Inventory Policy, SMTP Host, SNMP Trap Targets, ZENworks Database, and ZENworks Server Management. If you click the Add button, you can include additional Copy Files, NetWare Set Paramters, Prohibited Files, Scheduled Down, Scheduled Load/Unload, Server Scripts, or Text File Changes policies.
When appropriate, the same policies are under both the General page and the NetWare page. When you select a policy in the NetWare page, it supercedes any selections that might have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy is used instead of the policy set in the General category. Also, only the policies selected in the platform-specific page are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page and the Workstation Removal policy is selected in the NetWare page, agents on a NetWare system use the General Import policy, and the NetWare Removal policy is activated.
Within the Policies tab you can select the Linux page. This page displays the policies available for Linux servers. These policies include Server Down Process, SMTP Host, SNMP Trap Targets, and ZENworks Database, ZENworks Server Management. If you click the Add button, you can include additional Copy Files, Prohibited Files, Scheduled Down, Scheduled Load/Unload, Server Scripts, or Text File Changes policies.
When appropriate, the same policies are under both the General page and the Linux page. When you select a policy in the Linux page, it supercedes any selections that might have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy is used instead of the policy set in the General category. Also, only the policies selected in the platform-specific page are used in place of the General policies. For example, if the Workstation Import policy is selected in the General page and the Workstation Removal policy is selected in the Linux page, agents on a Linux system use the General Import policy, and the Linux Removal policy is activated.
Within the Policies tab you can select the Solaris page. This page displays the policies available for Linux servers. These policies include Server Down Process, SMTP Host, SNMP Trap Targets, ZENworks Database, and ZENworks Server Management. If you click the Add button, you can include additional Copy Files, Prohibited Files, Scheduled Down, Scheduled Load/Unload, Server Scripts, or Text File Changes policies.
When appropriate, the same policies are under both the General page and the Solaris page. When you select a policy in the Solaris page, it supercedes any selections that might have been on the General page for that platform. The policies will not be merged together; only the platform-specific policy is used instead of the policy set in the General category. Also, only the policies selected in the platform-specific page are used in place of the General policies. For example, if the SMTP Host policy is selected in the General page and the ZENworks Database policy is selected in the Solaris page, agents on a Solaris system use the General SMTP Host policy, and the ZENworks Database policy from the Solaris page is activated.
The Copy Files policy is a policy which enables you to configure ZENworks to copy or move files on a server from one location to another. The Copy Files policy can be an extremely powerful tool that you can use for file distribution or synchronization on a server.
The following is a list of parameters which can be configured from the file copy policy:
Source Path—Specifies the full path where the files to be copied are located (you can use the following wildcards in the path: *, ?, ???).
Target Path—Specifies the full path where the copied files are to be placed (you can also use wildcards in the target path).
Include Subfolders—Tells ZENworks to include all files in all subdirectories beginning from the directory that ends the path. If this box is not checked, only the files in the directory at the end of the path are copied.
Maintain Attributes—Tells ZENworks to maintain the file attributes in the target paths file system.
Overwrite Destination Files—Specifies whether you want ZENworks to overwrite files of the same name in the destination directories. If this box is not checked, files of the same name are not replaced.
Maintain Trustees—Tells ZENworks to maintain the file’s trustee attributes. You should plan carefully whether you want ZENworks to maintain the trustees of files, so that users do not gain access to files they should not.
Retry Times—If this box is checked, ZENworks will retry overwriting a locked file the number of times specified.
Kill Connection of Open Files—If this box is checked, ZENworks kills any connection that has the file open so it can be overwritten. You should use caution when setting this option because it can result in users losing data.
Error Processing—Selecting Fail on Error (enabled by default) stops the file copying process when an error is encountered in copying. Selecting Continue on Error causes file copying to continue on with the next file.
Operation—Specifies whether you want ZENworks to copy or move the files identified in the Source Path. Moving has the advantage of freeing up disk space in the source location. However, if you are trying to synchronize or replicate files, you need to use the copy feature.
Make certain that you do not have any read-only files or directories in the copy files locations. ZENworks applies the attributes to the locations prior to copying the files. Therefore, if you set a directory to read-only and ZENworks tries to copy it, ZENworks will create the directory in the destination location, set it to read-only, and then error on every file it tries to copy into that directory.
This policy allows you to specify where the source for the software dictionary list is located. A software dictionary contains a list of files that, when found on the drive, constitute a known software package. The software dictionary is stored on each individual workstation as it performs its scanning process for it to determine the software packages present on the workstation.
Occasionally, you may want to update the dictionary to include additional, internal software package files. This policy tells the workstation agents where to find the source and how often to update their individual dictionary files.
This page allows you to check whether the roll-up server is the source of the dictionary. If the roll-up server has the source, nothing else is needed on this page. If the roll-up server is not the source of the dictionary, you need to configure the remaining components on this page, including
Destination Service Object—The eDirectory object that represents the inventory service running on the target server.
Server IP/DNS Address—Alternatively you may specify the address of the inventory server.
Proxy Server Configuration—ZENworks allows retrieving of the dictionary files through the specified proxy.
This page allows you to specify how often and when the dictionary files should be updated on the workstation.
This page enables you to select when the configuration should be read and applied: Never, Daily, Monthly, Yearly, Interval, or Time.
After you select when you want the configuration applied, you have additional fields to select in the lower portion of the screen. The following sections discuss the various options.
You can alternatively choose that the policies be applied only weekly. In the Weekly screen you choose on which day of the week you want the policy to be applied. When you select a day, any other selected day is unselected. After you have selected the day, you can also select the time range when the policy may be applied.
To keep all workstations from simultaneously accessing the servers, you can select Randomly Dispatch Policy During Time Period. This causes each workstation to choose a random time within the time period when it will retrieve and apply the policy.
When you choose to have the configuration applied to the system daily, you need to also select when the changes will be made.
This schedule requires that you select the days when you want the configuration applied by clicking on the days you want. The selected days appear as depressed buttons.
In addition to the days, you can select the times the configuration is applied. These start and stop times provide a range of time where the configuration will be applied.
You can have the configuration also reapplied within the time frame specified per hour, minute, or second by clicking the Repeat the Action Every field and specifying the time delay.
Under the monthly schedule, you can select which day of the month the configuration should be applied, or you can select Last Day of the Month to handle the last day because all months obviously do not end on the same calendar date (that is, 30 days hath September, April, June, and November; all the rest have 31 except for February...).
After you select the day, you can also select the time range when the configurations are reread and applied.
Select a yearly schedule if you want to apply the configuration only once a year.
On the Yearly screen, you must choose the day that you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take into account leap years in its display. This is because you are choosing a date for each year that will come along in the present and future years.
After you select the date, you can also select the time range when the configuration should be read and applied.
To keep all the distributors from simultaneously accessing eDirectory, you can select Randomly Dispatch Policy During Time Period. This causes each server to choose a random time within the time period when the server will retrieve and apply the configuration.
ZENworks has the capability to image a workstation and to apply that image back to the original or other workstations. See Chapter 22, “Imaging a Workstation,” for more detailed information on the functionality of the ZENworks imaging system.
The placement of an image, associated with an image object in the directory, onto a workstation, may occur five different ways in ZENworks:
Boot the workstation to PXE and have the ZENworks PXE system connect the workstation to the imaging server, bringing down the imaging system and communicating to the imaging agent on the server.
Boot the workstation with the Imaging boot CD that communicates with the imaging server.
Boot the workstation with floppy diskettes that communicate with the imaging agent on the server.
Place a special boot partition on an unregistered workstation that communicates with the imaging agent on the server.
Place a special boot partition on a registered workstation and set the Check for Imaging Work for This Workstation on the Next Boot field in the workstation object. (In this case, the image is determined by an image association or the rules in the Workstation Imaging policy; see Chapter 15, “Setting Up Workstation Policies,” for more details.)
Each of these ways results in the workstation being imaged with the image associated with the workstation or determined by the imaging agent that resides on the server. The way that the workstation finds the imaging server is, when the imaging boot media is created, the administrator can specify either an IP address or a DNS name for the server. Additionally, configuration parameters are placed in the PXE system that knows where the imaging server is located.
The imaging policy becomes effective when the workstation is not associated with a workstation object. Because no image is associated with the specific workstation, the imaging server must determine, based on rules, what image to place on the workstation.
This policy enables the administrator to create a set of rules that can govern when a particular image should be used, based on some basic information from the workstation. The imaging server follows the list of rules in the policy until one of the rules is satisfied. The rule that is satisfied results in an associated image that is applied to the workstation.
The Imaging Partition page allows you to disable the ZENworks imaging partition if it exists. This is useful if you want to disable imaging on the workstation because no active imaging is occurring on the workstation. For example, you have a one-time image applied to a workstation annually in January. You need the partition to remain intact, but you can disable it the rest of the year. Novell now recommends that the imaging partition be done away with in your environment, replaced with PXE.
Now that ZENworks Desktop Management ships with PXE-enabled software you also may set the PXE settings for deploying any images. Novell now recommends that the Linux partition on the workstation be removed and that customers should move to the PXE method of image deployment. On the PXE Settings page you may set whether the PXE menu should appear automatically when PXE is launched, and you may also set the values that appear on the menu.
A PXE menu displays, for example, whether to receive an image or take an image.
The Rules page, selected from the Work To Do tab pull-down menu, enables the administrator to input the rules and associated images that the system uses to determine the image to place on a specific type of workstation. Figure 19.5 shows an example of this page.
You must first click the Add button to add rules to the list. After you have added several rules, you may select a specific rule and change its order in the list, look at its properties, or remove the rule. When you click the Add button, the screen shown in Figure 19.6 appears.
You first click the browse button next to the Use This Image field to browse to an image object in the tree associated with an image file on the image server. After the image object is selected, you may identify the rule associated with this image. You may currently only have six key/value pairs to compare about the workstation to determine what image to use.
In the middle of the dialog box you can see the six potential equations that you can generate to determine whether the image should be used. The equation is made up of a series of True/False statements put together with AND and OR logic. You construct the statement by filling in the drop-down fields. (The resulting statement is displayed in a more English-like view to help you understand the equation.)
The logic for the AND and OR operators is strictly left to right in the equation. In the Rule Description box parentheses are added to the equation to help the administrator understand how the rule is evaluated. You cannot insert the parentheses; they are automatically inserted as part of the explanation of the equation and are not under user control.
You first select the key you want to examine by selecting the key via a drop-down dialog box. The keys that you can choose from are the following:
CPU—Displays the reported processor. An example would be Genuine Intel Mobile Pentium MMX 233 MHZ.
Video—Captures the type of video adapter in the workstation. An example of this would be Trident Cyber9397 (rev 243).
Network—The network adapter for the workstation. An example would be 3Com.
Sound Card—The sound card that has been reported. Often this field results in no sound card being detected. This is because the system sends out a PCI request; if no sound cards respond you get this even though a sound card may be present.
Hard Drive Controller—The type of hard drive in the system. If the hard drive is an IDE device, the value for this field is IDE. If the hard drive is a SCSI device, you get the reported name of the device, such as FUJITSU MHJ2181AT.
MAC Address—The MAC address of the network card. An example of this value would be 00 60 80 03 C2 E7.
IP Address—The assigned IP address of the workstation. This would be reported as the traditional 137.65.237.5.
BIOS Asset Number—Represents the Asset number that may have been placed in the BIOS of the device. Most newer computers have this field in their BIOS that is set by the manufacturer or through a tool.
BIOS Serial Number—Represents the serial number of the device. Most computers now have this field set in their BIOS by the manufacturer.
Hard Drive Size—Reports the disk size in number of megabytes. Therefore, an 8GB hard drive would be reported as 8192MB in this field. The imaging system may not always report the full disk capacity. It is advisable that you use a wide boundary when generating your rules. For example, if you want to look for an 8GB drive, put in the fields so the resulting statement is Hard drive size >= 8000 MB.
RAM—The reported amount of RAM in megabyte units. This would be reported as 64MB. This field also may not always report the exact amount of RAM space that you would expect on your workstation. It is advisable that you use a wide boundary when generating your rules. For example, if you want to look for 16MB RAM, put in the field so the resulting statement is RAM >= 15MB.
When the workstation is booting the imaging system, it is in reality booting up the Linux operating system and running the tools included in the imaging system. The values for the keys described previously are values that the Linux system can report to the software. To discover what a system reports to Linux, you need to boot a sample workstation with the Imaging system boot disk and run the command img information. This displays the information sent to the image server about the workstation. This information is the data values that you put into the key comparison equations for your rules. You can also get this information from an image by opening the image in the ZENworks image editor, right-clicking the image file, and selecting Properties from the menu. See Chapter 22 for more detailed information on the functionality of the ZENworks imaging system.
The next part of the equation is to specify the operator. Two types of operators exist: string and integer. The Hard Drive Size and RAM fields are treated as integers, whereas all the other fields are treated as strings, where a not case-sensitive string compare is done to determine operator results. The string operators are contains, doesn't contain, begins with, and equals. The integer operators are =, <>, >, >=, <, and <=.
These operators perform expected comparisons between the key value supplied by the workstation to the imaging server and the value that you place into the value field of the equation. The following meanings are placed with each operator:
contains—The specified value is a substring anywhere in the reported value.
doesn't contain—The specified value is not equal to or contained in the reported value.
begins with—The specified value is represented in the initial character of the reported value.
equals—The specified value is the same as the reported value.
= equals—The specified value is numerically equivalent to the reported value.
<> not equal—The specified value is not equal to the reported value.
> greater than—The specified value is greater than the reported value.
>= greater than or equal to—The specified value is numerically equal to or greater than the reported value.
< less than—The specified value is less than the reported value.
<= less than or equal to—The specified value is numerically less than or equal to the reported value.
The next field in the operation is where you enter the value that you want to compare. The far right field enables you to extend the operation to additional key/value comparisons. Your choices currently are AND and OR.
The Boolean operators are evaluated strictly from left to right. For example, if the following rules were entered into the policy, the resultant evaluation would be (Hard drive >= 600MB AND RAM < 16MB) OR (RAM > 31MB):
Hard drive size >= 600MB AND
RAM < 16MB OR
RAM > 31MB
This would result in giving the image to any system that has a disk greater than 600MB with less than 16MB RAM. This would also give the image to any system that has more than 31MB RAM regardless of the size of the hard drive.
You can view the precedence of the equation, complete with parentheses, on the bottom half of the screen as you introduce new key/value pairs into your rule.
After your set of key/value pairs has been entered and you have reviewed your equation at the bottom of the screen, click OK to include the rule into the imaging system. You are returned to the original Rules page with the rule that you entered on the screen.
Once again, from this page, after you enter some rules you can specify the order that the rules are evaluated. After selecting a rule, you can move that rule in the order by clicking either the Move Up or the Move Down button. As the imaging server is evaluating the rules, the first rule that results in a TRUE evaluation results in that imaging being supplied to the workstation.
The Multicast page allows you to specify whether the imaging server checks first to see whether the workstation should take part in a multicast session prior to checking the image selection rules within this policy. If the Check the Image Selection Rules in This Policy Before Checking Within Multicast Sessions check box is checked, the imaging server will check the image selection rules prior to checking its multicast sessions.
The Image-Safe Data tab is composed of four pages. These pages represent information and data placed or retrieved from the system regardless of the image used. The following sections depict the pages available by selecting the small triangle drop-down menu on the Image-Safe Data tab.
An agent exists that may be placed on the workstation called the Image-Safe Data agent. This agent has the responsibility of moving data between a special sector on the disk used to store configuration information such as IP address or DHCP configuration along with workgroup information. This information on the disk is not affected by an image taken or placed on the drive.
When the Image-Safe Data agent runs on the workstation, it makes sure that the information in the special sector and the operating system are synchronized properly. For example, following an image placement, the agent moves the data from the disk into the operating system, setting up the DHCP and computer name. On a workstation that has not just been imaged, the agent moves the information from the operating system into the sector on the disk so that the data can be restored should a new image be placed on the drive. Should the agent not run, the workstation would be an exact mirror of the image (with the same IP and computer name configuration).
The Image-Safe Data configuration page enables the imaging server to pass this configuration information to the agent via this disk sector.
The IP Assignment Log page displays the IP addresses that the imaging server has assigned to any imaged or re-imaged workstations. The available IP addresses can be set in the IP Configuration page described in the following section.
The IP Assignment Log page displays the log of the addresses that have been assigned.
This page can also be used to place an IP address back into the pool of available addresses. If you have an address that you want to place back into the pool, select it from the log list and click the Remove button.
NOTE
When you remove a specific IP address it may not be properly represented in the IP Configuration range and therefore will not be reused.
If you specified a range in the IP Configuration page to be the set of IP addresses that you will make available for workstations, when the imaging server uses a portion of the range (at the ends), the range is refreshed on the Configuration page. For example, if the range 123.65.234.1...123.65.234.100 were in the configuration and IP address 123.65.234.1-10 were assigned, the range would be changed to 123.65.234.11...123.65.234.100. Consequently, when you go to the IP Assignment Log page and free up IP address 123.65.234.10, the range is not reconfigured, and the freed IP address is not reassigned. You must manually go to the Configuration page and modify the range to include the addresses that you have freed.
The IP Configuration page enables you to specify whether the workstations imaged by the imaging server will obtain their IP address from a DHCP server or via a static assignment that is done as part of the imaging process.
If you select the DHCP option, when the workstation is imaged, the Windows system is told to get IP addresses from a DHCP server. If, however, you select that you want to specify an IP address, the other fields on the page are activated.
To specify a static IP address, you must first enter the subnet mask and default gateway that you want all your imaged workstations (imaged via the image server using this particular policy) to receive. You must also specify the range of IP addresses used by the imaging server and assigned uniquely to each of the imaged workstations. You specify the set of IP addresses by using the Add and Add Range buttons.
When the imaging server is given a request for an image and after the image has been placed onto the workstation, the IP address information is transmitted and assigned to the workstation. That address is logged in the imaging server and not reused for another workstation.
To remove any address or ranges from the possible set, select the item and click the Remove button. These addresses will no longer be in the pool of available addresses for the imaging server to assign.
In the Windows Networking page you can specify the computer name for the workstation and the workgroup for the system.
The computer name prefix that you enter in the field (maximum of seven characters) is prepended to a randomly generated set of characters and numbers to construct the final 15-character computer name for the workstation.
The Make the Computer a Member of the Following Workgroup field enables you to specify the workgroup that you want for the workstation. You select which you prefer by selecting the field and entering the workgroup name.
The DNS Settings page allows you to specify the DNS suffix and name servers that will be used by this policy. Simply type in the suffix you want to use and click the Add button to bring up an IP address dialog box to specify the addresses of name servers. It is important to use the correct suffix and name servers for the ZENworks imaging engine to process imaging operations on a workstation.
As part of the imaging system the administrator has the ability to request that the workstation have an image taken of itself and placed onto the server. This is done by checking some fields in the workstation object (see Chapter 22 for more details), which causes the workstation to take an image of itself on its next reboot.
When the workstation takes an image of itself, or when an image is taken when a request is made through the Linux boot system, the image is transmitted to the image server. This image server receives the .ZMG file and places it in the path specified. To protect the system from overwriting any files or to prevent users from placing the image files into inappropriate directories, the imaging server takes the information in the security page and restricts the placement of the image files.
When you check Allow Imaging to Overwrite Existing Files When Uploading, you are enabling the system to overwrite any files that may have the same name as the one specified by the user for the name of the image file.
The Only Allow Uploads to the Following Directories check box activates the requirement that all requested uploads must specify one of the directories identified. If the directory portion of the destination path, specified by the user, does not match one of the directories specified in the list on this page, the request to store the uploaded image is refused. To add paths to the list of accepted destinations, click the Add button and enter in the acceptable path.
Paths in the directories may be one of the following formats:
Driveletter:path
Volumepath
NTSharepath
The system does not, for example, take any UNC path. When the user enters the location of the file, including the path, this information transmits to the imaging server. The server compares the directory portion of the path given with all the strings in this list. If a match occurs (that is, the directory is listed), the operation is accepted, and the image is taken and stored. Otherwise, the operation fails, and the image is not taken.
The Inventory Roll-Up policy dictates to the services running on a specific server (such as, inventory server) where they should roll-up or transmit the inventory information that they have received from the various workstations. By doing this, the system receives local inventory information and then moves it up in the tree hierarchy, consolidating inventory information from various remote locations and constructing a more centralized database of inventory information (see Chapter 20, “Using ZENworks Workstation Inventory,” for more detailed information).
When the inventory system is installed into the network, the system creates service objects that govern the behavior of the agents working on each of the inventory servers. These agents also respond to this policy to understand to which service agent they should transmit their inventory information. All service agents associated with this policy transmit their inventory information to the same target agent.
Figure 19.7 shows a sample of this page.
As you can see in Figure 19.7 the policy simply requests the object eDirectory Distinguished Name of the service where the associated agents should transmit their inventory information. The local agents may keep a copy of the inventory data, if they are a designated database gathering location, but they still transmit an additional copy if they are configured to do so.
In this policy you click the Browse button to the right of the Destination Service Object field and browse the tree to select the service object of the inventory agent that you want to receive the information. You may also specify the DNS or IP address of the server running the service.
Additionally, ZENworks provides the ability to roll up the inventory through a proxy by specifying the IP/DNS name and a port number.
The Roll-Up policy is only read by the service manager agent on startup and then every 1,000 minutes (this is not configurable). So if the policy change needs to be immediately effective, the service manager agent on the server must be stopped and restarted.
This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select NetWare Set Parameters for the policy and type a unique policy name.
After you have added the policy, you are guided through a wizard to collect potential parameters. Because the set parameters on NetWare are dynamic and can be enhanced by various sets of NLMs, there is not a known set of set parameters. Consequently, ZENworks Server Management walks you through a wizard that goes to an identified NetWare server (the server must be running the ZENworks Server Management Policy engine) and queries the server for the set of parameters. This list is then transmitted back to the wizard.
After the parameters have been imported into the policy, you are able to edit and modify their values, or remove them from the policy. The parameters that remain in the policy will be set on the target server when applied.
The Prohibited Files policy will cause the ZENworks Server Management system to, at a scheduled time, search the server file system and remove or move any specified files (by wildcarding) from the the server or to a specified directory. For example, if you don’t want MP3 files stored on a specific server, ZENworks can go through the target server and remove all MP3 files from the server with a Prohibited Files policy.
With this policy, you can
Specify one or more volumes/drives or directories to monitor. You have the option to include all subdirectories for monitoring.
Specify which file types to monitor using wildcard combinations.
Specify the action of either Delete or Move to Specified Location for all encountered files.
Specify a schedule for enforcement of the policy.
For this instance of the policy, you can specify the paths to be monitored. These directories are used as the source to determine which files are to be deleted or moved in the target locations. You cannot move files to a directory that is being monitored.
This can be a volume, drive, or directory name. It must be the full path when a directory is given. You can add multiple paths. For each path that you enter, files matching the file types that you define in the File Type field are either deleted or moved according to which Action button you select. Variables are supported in the paths.
Select the check box to specify that all subdirectories be included. If you want only a certain subdirectory, you should create another policy just for that subdirectory by giving its full path in the Path field.
Opens a dialog box where you can enter a path. This field cannot be browsed, so you must know the full path to the files to be moved or deleted.
You can specify the type of files you want to monitor.
Opens a dialog box where you specify a file type. You can include wildcard characters. This field cannot be browsed, so you must enter the correct information to identify the files to be moved or deleted.
You have two options for how to handle the files you have specified in the Directories to Monitor and the File Types fields:
Delete Files—Select the option button to delete the specified files from all of the paths that you have identified.
Move Files To—Select the option button to move the specified files to the path that you specify in this field. This field cannot be browsed, so you must know the full path to where you want the files to be moved.
CAUTION
IMPORTANT: You cannot move files to a directory that is being monitored. If you move files, the full paths of the files are preserved (meaning if the path doesn’t exist at the target, it is created there); files are overwritten if they exist in the same path; file or directory attributes and trustees are not transferred; and file ownership is preserved.
Occasionally, files you might be trying to delete or move might be open. For these files, you can specify one of the following resolutions:
Retry __ Times—Select the check box and enter a number for how many times you want to retry deleting or moving the file before continuing on with the next file. Valid entries are from 1 to 10. The time used by each increment depends on the various hardware and software speeds involved in your system.
Use this field to allow enough time for a temporarily opened file to be closed, such as a file that is only opened long enough for the application to either obtain a copy for editing or write a new copy of the file.
Kill Connection of Open Files (NetWare only)—Select the check box to have the file deleted or moved, even if it is opened by a user at the time. It kills the connection that is holding the file open so the file can be deleted or moved.
This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Scheduled Down for the policy and type a unique policy name. After you do this, you can activate and modify the policy.
This policy allows you to schedule that the server reset, restart, or down at a particular time.
You can select one of the following server options:
Reset server—This downs the server and performs a warm boot of the machine.
Restart server—This downs and then restarts the server.
Down server—This downs the server.
On the Policy Schedule page, you may specify the time frame when you want the server to be reset, restarted, or downed.
This policy is a plural policy, which means you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button on at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Scheduled Load/Unload for the policy and type a unique policy name. After you do this, you can activate and modify the policy. This policy enables you to specify when you want to have a selected set of NLMs or Java processes loaded or unloaded on the server.
In this policy, you click the Add button and select whether you want to load an NLM or Java class, or unload a process by using the drop-down menu to the left of the Add button. After you make your selection, an entry is placed on the left side of the screen. Corresponding to this entry are some parameters that are displayed and edited on the right. By selecting the entry on the left, you can administer the values on the right. You can edit the entries on the left by selecting the entry (like you do in Windows), and this enables you to change the name to something more useful.
In the fields on the right, you enter the name of the NLM or Java class and any parameters that are needed for the process.
When you are loading a process, you can enter the NLM or class name and also specify the parameters that you want passed to these processes. Additionally, you can specify whether you want to wait for the loaded NLM or Java class to terminate before continuing onto the next item in the list. Make sure you check this box only if you are expecting the process to complete and exit on its own; if you are just loading monitor.nlm, the policy will be waiting for a long time to be able to move onto the next item.
When you are unloading a process, you can enter the name of the NLM or the Java class name. Additionally, you can specify if you should wait for the termination to complete before proceeding in the list.
After you have entered several items in the list, you can select an item and move it up and down the list. This is significant because the items are processed in the order specified, from top to bottom. By selecting any item and moving it about in the list, you can order the loads and unloads in a sequence that is necessary for your process.
On the Policy Schedule page, you can specify the time frame when you want the system to perform this policy.
The Server Down Process policy allows you to specify what should happen when the server receives a command to go down. This catches the instances when the user types the down command on the console; this process does not catch any other down request (done programmatically). You can even specify that other servers notify you if the downed server does not come up after a certain amount of time.
The Down Procedure page enables you to specify the procedure that should be followed when the server is downed.
The following options on the page are activated when the check box is checked:
Follow This Procedure When a Down Server Is Triggered—This activates or does not activates the procedure identified on this page. If this check box is not checked, this policy will not be in effect for the associated servers. You can specify, when activated, how many minutes the server must wait before it actually performs the down process.
Disable Login Before Downing—This effectively runs the disable logins command on the server, disallowing anyone to be able to log into the server. You can specify how many minutes before the downing process you want to disallow anyone to log into the server. If the number of minutes specified in this field is greater than that specified in the Follow This Procedure When a Down Server Is Triggered field, the disabling of logins occurs immediately when the down request is given.
Drop Connections Before Downing—This drops all the current connections on the server before downing the server. You can specify the number of minutes before the actual downing of the server when you want the connections dropped. If the number of minutes specified in this field is greater than that specified in the Follow This Procedure When a Down Server is Triggered field, the connections are dropped immediately when the down request is given.
By selecting the small triangle drop-down control on the Down Process page, you can select the Ordered Unload page. This page enables you to specify a set of NLMs and Java processes that you want killed or unloaded and the order in which to kill or unload them before the downing of the server actually begins.
When you select with the Add button either to unload an NLM or kill a process, a dialog box prompts you to enter the name of the NLM or the process. After entering the name of the NLM or process, click the OK button on the dialog box and the NLM or process name appears in the Ordered Unload page. After you have more than one process or NLM in the list, you can select an item in the list and then move it up or down in the list by clicking the up or down arrows, after selecting an item.
Before the server is downed, these systems are unloaded or killed on the server. This is useful if you have such processes or NLMs as databases or other programs that are caching items in memory and need to flush those buffers onto disk. This can be done, usually, by unloading the process or NLM. This can keep your data integrity solid instead of pulling the server out from under these processes, not allowing them to save their data.
The Reporting page is under the Notification tab. The purpose of this page is to identify some companion servers, whose responsibility it is to send notifications if the server that is associated with this policy does not come up after a specified time. When the server is told to go down, it contacts these companion servers and places a scheduled entry to send a notification message. When the server comes back up and the policy engine is restarted, it contacts these servers again and removes the scheduled entry for the notifications. If the server and the policy engine do not come up in the specified time, these companion servers fire the scheduled entry and send the specified notification messages. These companion servers must also be running the policy engine for this to work.
The Send SNMP Alert if Server Is Not up After a Number of Minutes check box turns on or off the monitoring of the server. You can specify the number of minutes that these other “watcher” servers will wait before they send their SNMP alerts notifying you that the server that was downed is not coming back up.
You then must click the Add button and then browse the tree to identify the servers that are to monitor this behavior. After you specify more than one server, you can order the servers to identify which server has first responsibility to monitor the downed server. When the ZENworks Server Management engine recieves the event that signals the down, it attempts to contact the servers in this list (in order) to notify them to watch for when the server comes back up. If the server in the list cannot be contacted, the engine goes to the next server in the list.
The Broadcast Message page can be found under the Notification tab. This page enables you to specify the broadcast messages that are sent to the connected users as the system is being taken down. You can specify if the message should be sent, how many times you want the message sent before the system goes down, the contents of the message, and an additional trailer that tells the users how long before they will be disconnected from the server.
The number of times to send the message is divided evenly into the number of minutes specified in the Down Procedure page before dropping connections or downing the server (if the Dropping Connections check box is not checked). If, for example, you stated that the server should go down 10 minutes after the request and you specify that the connections should be dropped 4 minutes before downing, the number of minutes that a user has left on the server is 6 minutes (10–4). The number of messages are divided into the 6 minutes and spaced evenly across that time.
If you include the line that states the number of minutes left, the “x” in the line is calculated the same way as above, minus a broadcast cycle. You subtract one cycle so that the last message is displayed at the beginning of the last cycle (rather than the end).
The Targeted Messages page enables you to send specific email messages to a selected set of users to notify them of the downing of the server.
The Send Email to Selected Users When Server Is Going Down check box turns off or on this feature. The Email Message box displays the message that is sent to each of the specified users. You are not able to change or customize the message that is sent.
To add users to the list and have them receive the message, you must click the Add button and select whether you want to add an NDS User or Group, or specify an email address explicitly. When you select User, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all of the users in the group are sent the email message and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. It is expected that the attribute you identify contains a valid email address.
If you choose to enter an email address explicitly, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown as the User Name field entry in the table with N/A in the Address Attribute field.
You can place any number (based on the limits of NDS) of users, groups, or email addresses into the page and each of them are sent the email message when the server has been requested to go down. The email users recieve just one message at the very beginning of the downing process. This gives these users the maximum amount of time to connect to the server and stop the downing process should they desire. They can connect to the server and, via the policy engine console or via Remote Web Console, cancel the down process.
This page enables you to specify conditions when the down server request should not be honored.
You must check the Use Conditions in Downing Server? check box to make the conditions effective. Then you can add any number of conditions that you want to identify. If any of these conditions are true, the server does not honor the down server request. Select any of the following choices from the drop-down menu:
File Open—Specify if an identified file is currently open on the server. If that file is open, the system does not allow the down request.
NLM or Java Loaded—Specify if a particular NLM or Java application is currently loaded on the server. The system checks to see if the NLM or Java application is loaded before it performs any unload of NLMs or Java applications that were specified in the Ordered Unload page. So, if you have an NLM or Java application in the Unload page and in the conditions, the down is halted if the NLM or Java application is loaded.
Server Connected—If the identified server is currently connected to the server, the down request is denied.
User Connected—If the identified user has a current connection to the server, the down request is denied.
Number of User Connections—Specify the number of active connections whereby, if exceeded, the down will not be allowed. If, for example, you specify 15 as the number of active connections and there are 16 or more connections, the down request is denied.
These are active connections, which include server and agent connections, not just authenticated user connections.
Workstation Connected—Identify the workstation that, when connected, halts the down request. You cannot specify a group of workstations, but must identify them individually.
This feature functions only when you have ZENworks Desktop Management installed in your system.
This policy is a plural policy, which means you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Server Scripts for the policy and enter a unique policy name. After you have done this, you can activate and modify the policy.
This policy enables you to specify a set of scripts that you want to have run on your server.
You add a script to the policy by clicking the Add button. When you click the Add button, an entry is placed in the left window and you can edit the name of the script. After you have named the script, you can choose on the right the type of script that you will be creating. The choices of script types are currently NCF, NETBASIC, and PERL. After you identify the script type, you are free to type in the script in the provided window. ZENworks provides no syntax checking or validation for the script you enter. You may enter ZENworks Server Management variables into the script and they will be processed prior to the script being executed.
You can add multiple scripts of any of the available types into this one policy. The scripts are executed in the order shown on the administration screen (from top to bottom). If you want to reorder the running of the scripts, you must select a script name from the left pane and click the up or down arrows to move the script into a different order.
When the ZENworks policy engine launches this policy, it creates a temporary script file (in its working directory) that contains the specific script, and then launches the corresponding NLM that works with the identified script, passing the NLM the name of the script to run. Consequently, netbasic.nlm and perl.nlm must already exist on the server where the script is to be run. These are normally installed with the standard NetWare server. Regardless of whether a script fails or succeeds, the engine proceeds on to the next script.
On the Policy Schedule page, you may specify the time frame when you want the system to enforce this policy.
The Server Inventory Policy defines where to locate the ZENworks inventory service that is running, so the server can transmit any inventory information to that service. Additionally, this policy identifies the types of inventory that should be taken and any normalization rules that you want applied.
On the General tab you can specify the following:
Inventory Service Object DN—Browse to and select the DN that represents the Inventory service that is running on a back-end server. This object was created when you installed the Inventory services from the ZENworks Server Management installation.
Server IP Address/DNS Name—Enter the DNS name or the IP address of the server that is hosting the back-end services.
Proxy Server Configuration: IP Address/DNS Name—Enter the DNS name or the IP address of any proxy server that you may have set up to receive inventory.
Proxy Server Configuration: Port—Enter the Port that is receiving the inventory information.
Check the Enable Software Scan check box to enable scanning the file system to search for application software. Select the Custom Editor button to add entries into the database to describe application software that is not known in the software database.
Enter any software rules into the Editor tab. These rules constitute key = value pairs used to normalize the inventory information that is collected through the header data on the software application files. If any of the specified keys are found, they are replaced with the given value. This allows you to normalize your data and represent a particular company, for example, as the same string regardless of the different strings that may have been stored in the executable.
This policy allows you to configure how the Remote Management agent should behave on any assigned Windows servers. From this policy you can specify rights configurations and settings for remote control and remote view processes.
On the General tab you can set the following options:
Enable Session Encryption—This flag allows the configuration as to whether the agent will allow encrypted sessions.
Allow User to Request Remote Session—This configuration will allow users on the remote server to request remote control sessions back to the administrator machine. This is necessary if the remote system is behind a NAT and the administrator machine cannot see the remote system on the network.
Display Remote Management Agent Icon to Users—This will cause the remote management agent icon to be displayed in the system bar.
This tab allows you to describe how the remote control session behaves. The following options are available:
Prompt User for Permission to Remote Control—Configure if the user should be prompted to allow the remote control session to begin.
Give User Audible Signal When Remote Controlled—This will cause a beeping to occur on the target device when it is being remote controlled. The additional entry with this line allows you to specify the frequency that the beeping should occur.
Give User Visible Signal When Remote Controlled—Configure if the name of the administrator performing the remote control should be displayed on the screen in a title box. Optionally you can specify how often to update the entry.
Allow Blanking User’s Screen—This will allow the administrator to blank the target screen. This will keep the user from seeing what is happening on the monitor.
Allow Locking User’s Keyboard and Mouse—This will allow the administrator to lock the user’s keyboard and mouse, keeping them from typing and moving the mouse on the screen.
This tab allows you to describe how the remote view session behaves. The following options are available:
Prompt User for Permission to Remote View—Configure if the user should be prompted to allow the remote view session to begin.
Give User Audible Signal When Remote Viewed—This will cause a beeping to occur on the target device when it is being remote viewed. The additional entry with this line allows you to specify the frequency that the beeping should occur.
Give User Visible Signal When Remote Viewed—Configure if the name of the administrator performing the remote view should be displayed on the screen in a title box. Optionally you can specify how often to update the entry.
Several of the features in ZENworks include the capability to have information and events emailed to identified users. In order to send the email, the agents must contact the SMTP server in your environment and will send the email through that system. This policy allows you to specify the IP address of the SMTP host that the agents associated with this policy (through inheritance) will use.
The SMTP Host page allows the administrator to identify the IP address of the SMTP mail server in their environment.
Just place your cursor in the SMTP Host field and type the IP address of the SMTP mail host. This field saves only the IP address. You can type in the DNS name of the SMTP host, but it will be saved as the IP address. The field queries DNS to resolve the IP address and then saves that address here.
In ZENworks, several agents send an SNMP message to a central server that stores these messages and enables you to print reports on the traps. These traps can identify whether a policy has been successfully applied, whether a distribution was sent successfully, and other potential successes and failures.
The SNMP Trap Targets policy identifies the location of the service that is accepting and recording the SNMP messages from the server agents.
After you bring up the policy page, you may add as many trap targets as you desire. The service on the server sends the SNMP message to all of the specified trap targets. Click the Add button and specify whether the destination can be achieved with an IP address, an IPX address, or a DNS name. After selecting the type, a dialog box appears in which you can type either the address or the DNS name of the target service.
After you have added the trap targets, you need to specify how often that policy should be applied to the SNMP agents on the service location. From the Policy Schedule tab, you simply identify the policy schedule type that you want to apply. When the scheduled time arrives, the system retrieves the SNMP Trap Targets policy and applies it to the agents on the server.
This policy is a plural policy, which means you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Text File Changes for the policy and enter a unique policy name. After you do this, you can activate and modify the policy.
This policy enables you to specify a set of text changes that you want done on ASCII text files on your server.
You enter a requested text file change by clicking the Add button. After clicking the Add button, you are prompted to identify the name of the text file and the name of the change script. You can have multiple change scripts for each file you identify. Make sure you enter the complete filename (including path) for the name of the text file to change. The changes are applied to the specified file in the order shown. Should you want to change the order of the changes or the order of the files, select the item and move it in the list by clicking the up or down arrows.
The first setting to be done is to choose the change mode that corresponds to this change policy. You may choose either Search File, Prepend to File, or Append to File as one of your modes.
When you choose to prepend text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box. Click OK to store this entry. When the policy is applied, the exact strings that you typed are placed as the first lines in the file.
When you choose to append text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box. Click OK to store this entry. When the policy is applied, the exact strings that you typed are placed as the last lines in the file.
Should this change be a Search File change, you need to administer the following additional information to make the change effective:
1. Identify the search type that you need for this change. The search type may be Sub-String, Whole Word, Start of Line, End of Line, or Entire Line. The following describes the meaning of each of these search types.
Sub-String—Search for the search string in any of the text. The text specified may be contained anywhere in the file, even in the middle of a word. If you have the substring of “day,” for example, the following text would all match with this substring: today, day, yesterday, daytime, and so forth.
Whole Word—Search for the string such that it is surrounded by white space or beginning or end of line. If you have the string of “day,” for example, only the word day would be a match. The words today, yesterday, daytime, and so forth do not constitute a match.
Start of Line—This is a successful match if the beginning of a line (first line of file, or characters following a carriage return) starts with the string, regardless of whether the string is a whole word. To continue the example, if you had the string “day,” this type would match only with the following lines: daytime is set, day by day, and so forth.
End of Line—This is a successful match if the end of a line (characters preceding the carriage return or end of file) contains the string, regardless of whether the string is a whole word. With the example, if you had the string “day,” this type would match only with the following lines: the time to act is today, day by day, and so forth.
Entire Line—The entire specified string must consume the entire line of text (from text following a carriage return, or beginning of the file, to the next carriage return, or end of the file), including any white space. It must be an exact match of every character, other than the carriage returns, on the line. If your string were “day,” only a line with the single word day on it will would match.
2. Specify the search string you’re trying to match. Enter this into the Search String field.
3. Identify if you want the search to be case sensitive by selecting the check box to make the search only match if the case matches.
4. Change the Find All Occurrences field if you want to find only the first occurrence of the string in the file. The default is to have this field checked, meaning that all occurrences in the file will have this policy applied to them.
5. Choose a result action that is applied to the string after it is located in the file. The possible actions are Delete All Lines After, Delete All Lines Before, Prepend to File if Not Found, Append to File if not Found, Replace String, Replace Word, Replace Line, and Append Line. The following describes each of these choices and their resulting action:
Delete All Lines After—All lines (characters following the next carriage return) are deleted from the file. The file is basically truncated, ending with the line that held the first matching string. Obviously, searching for all occurrences is not effectual when this is the resulting action, as a match truncates the rest of the file.
Delete All Lines Before—All lines (characters before and including the previous carriage return) are deleted from the file. The file is reset such that it begins with the line that held the first matching string. With this result action, another search continues and if another match is found, all the lines before it are deleted as well.
Prepend to File If Not Found—This action places the replacement text in the file at the very beginning of the file should the search string not be found. This action only adds text; it does not delete or modify text.
Append to File If Not Found—This action places the replacement text at the end of the file should the specified search string not be found. This action only adds text; it does not delete or modify text.
Replace String—This action takes the matching string and removes it from the file, placing the replacement string in the exact location of the deleted string. If the replacement string is of a different length than the search string, the surrounding characters are shifted to the left or right depending on whether less or more room is required. Basically, the new text is inserted in the location were the search string was removed.
Replace Word—This action takes the word where a substring was matched and replaces the whole word (from space or beginning of line to space or end of line) with the replacement text. If the substring were “day,” for example, the following words would be replaced with the replacement text: day, today, daytime, and so forth.
Replace Line—This action takes the line where the match has occurred and removes the complete line from the file. The replacement text is placed in the same location where the removed line was located in the file.
Append Line—This action appends the replacement string to the line that contained the match. The matching string is not removed from the file; the only change is the addition of text to the end of the line.
6. Specify the new string. In the text box that is provided, you need to supply the text that will be applied to the file, based on the action that was specified.
The Wake on LAN policy allows you to manage which managed workstations will be controlled by the Wake on LAN service. The Wake on LAN service allows you to wake up a managed workstation or a set of managed workstations when activity on the LAN is detected. From the Wake on LAN policy page, you can specify objects from the following list of targets:
Containers—All workstations in a country, locality, organization, or organizational unit
Workstation—A specific workstation object
Workstation Group—All workstations associated with a specific workstation group object
A Wake on LAN policy is added to a platform policy by clicking the Add button within a particular server policy list.
In ZENworks a service that now runs on a NetWare or Windows server automatically receives import requests and immediately creates the workstation object. After the object is created it returns the eDirectory Distinguished Name (DN) to the workstation. To perform these actions, the import service must be running on the server and must be accessible using a registry key on the workstation (HKEY_LOCAL_MACHINESoftwareNovellENworkszenwsregImportServer = IP/DNS) or the DNS name of zenwsimport either through the local host file on each workstation or via a DNS service. Additionally, the import service must have rights in the directory to create the workstation objects. The pages in this policy enable the administrator to grant these create rights to the import service, to specify how to name the workstation objects and in which container to place the objects, and to limit the number of requests that can be satisfied (to keep the system from overloading a server).
The import service can also be configured to ignore the first N requests from a workstation before it creates a workstation object. This can be useful if the workstation needs to pass through several hands to get properly configured and tested before it is actually given to the final end-user. This is to help this process settle before the workstation object is actually created.
NOTE
Your desktops do not import automatically if the workstations are finding a ZENworks 2 search policy in the tree. They must see either no search policy or a ZENworks 6.5 search policy to activate the automatic workstation import. See Chapter 3, “Getting ZENworks Desktop Management 7 Working in Your Environment,” for more information.
Sometimes you want to have an import service provide more than one import policy. This can be done by setting the following key on the workstation that requires the nondefault policy:
[HKEY_LOCAL_MACHINESOFTWARENovellENworkszenwsreg]
"PolicyDN"="policyDN.novell"
This allows you to have the import server run various different policies. For example, if you have a single import server, but you want your lab machines to be automatically placed in a different group or have a different naming convention, place this registry key on those images with their policy identified. When the import service runs, it activates the specified policy for the import rules.
The following sections describe each of the pages available with the workstation import process. The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Setting Up a Server Package” section earlier in the chapter.
The Containers page enables the administrator to grant rights to the import service to containers where they must create workstation objects. When you add a container to the list, the system grants rights to the policy object. When the import service needs to perform an import, it logs in as the policy being used, enabling it to obtain rights to create workstation objects in the specified container.
The process of adding and removing containers is familiar. You click the Add button, and you are presented with a dialog that enables you to browse through the tree to select the container you want. When selected, the container is added to the list, and the import service is given a trustee assignment to that container and given the rights to Browse and Create objects.
To remove a container from the list, select the desired container and click the Remove button. This removes the trustee assignment given to the service and deletes it from the displayed list.
The Platforms page enables you to specify the naming of the workstation objects, the location of the object in the tree, and any workstation groups of which you want the workstation objects to be a member. This can be specified for each of the following categories: General, WinNT, Win2000, WinXP, or Win 9x (for example, Windows 98).
Each of the pages within these categories is identical, with the exception that on the nongeneral pages you have the additional field: Enable Platform Settings to Override General Settings. When this field is checked, the platform-specific configuration parameters are used rather than the general. We only discuss the General pages because they apply to all the other platform pages.
Figure 19.8 displays the first General page available.
Each page has three tabs that enable you to configure separate options of the import policy. These tabs are Location, Naming, and Groups. Each of the following subsections discusses these tabs.
The Location tab enables the administrator to identify the container in the tree that should hold the workstation object when it is created during the import process. Figure 19.8 displays this screen.
The Allow Importing of Workstations check box enables or disables the ability to import workstations. When this box is checked, the other fields of the page become usable.
The Create Workstation Objects In drop-down box allows the administrator various options for locating the container in which to place the workstation objects. The options are as follows:
Server Container—This option is new in ZENworks Desktop Management and when selected tells the system to place the workstation objects in the same container as the server running the import process.
User Container—Signals that the container that holds the user object, of the user who logged in to the system when the registration of the workstation occurred, is the container that also holds the workstation object. Remember it is the first user who connects to the system (after the number of ignored connections has passed) that has the association to the workstation. A path may be specified in the Path field that would be considered to be relative to the user’s container. The Path field is constructed by entering a relative path. This relative path is constructed by a series of dots and container names. For each dot in the path, the system moves up one level from the associated object container. For example, the path of .Workstations means for the system to go up two levels and in a container called Workstations at that level. If an alternative user is desired, you must run the unregistration tool zwsreg found in Program FilesNovellENworks with the –unreg option.
Associated Object Container—Signals that the container that has the policy package associated with it is used as the starting container to place the workstation object. If a path is specified, the associated container is used as the base, and the path is considered a relative path. The path field is constructed by entering a relative path. This relative path is constructed by a series of dots and container names. For each dot in the path, the system moves up one level from the associated object container. For example, the path of .Workstations means for the system to go up two levels and enter a container called Workstations at that level.
Selected Container—Identifies that the specified path is an absolute container path in the tree. The Path field is required with this selection and must identify the specific container that will hold the workstation object.
On the Workstation Naming page the administrator can describe how the import process should use the information in the registration to craft the name of the workstation object.
The Workstation Name field displays the final combination of registration information that creates the name. In the previous example, the workstation object name is the computer name followed by the MAC address. This is confirmed by the fact that the Workstation Name field contains Computer+MAC Address. If the computer name was Rtanner and the MAC address of the NIC card were 12345, the workstation object name would be Rtanner12345.
The Add Name Fields and Place Them in Order field displays the various components put together to form the workstation name. Each line displayed in this field represents a value that is part of the name. The order of the lines from top to bottom represents the order that they appear in the name. The options that can be placed in the names are as follows:
<User Defined>—Represents an administrator-defined string. When this field is chosen, the administrator is prompted to enter a string into the dialog box. This string is placed into the name. This can be any combination of standard ASCII visible characters including whitespace characters.
Computer—Represents the computer name given to the computer usually during installation of the operating system.
Container—Represents the name of the container into which the workstation object is placed. This name is included in the workstation name.
CPU—Represents the CPU type of the machine. The possible values are 386, 486, and PENTIUM.
DNS—Represents the DNS (Domain Name Services) name of the computer.
IP Address—Represents the IP address of the machine when it is first registered with the tree. In previous versions of ZENworks Desktop Management this was retrieved through the Network Address request and a preferred protocol set to IP.
MAC Address—Represents the address of the machine when it is first registered with the tree. In previous versions of ZENworks Desktop Management this was referred to as the Network Address.
OS—Represents the operating system type of the machine. The expected values would be WINNT or WIN95, for example.
User—The login name of the user connected to the tree when the registration process first executed.
For example, assume that a workstation had been registered with the following values:
CPU = PENTIUM
DNS = zen.novell.com
MAC address = 00600803c2e7
IP address = 137.65.61.99
OS = WINNT
Server = ZENSERVER
User = rtanner
Computer = RonComputer
Then, if we were to administer the Workstation Import policy with the following naming attributes, the corresponding workstation name would be created, assuming that pieces in quotes are a user-defined string:
UserOS = rtannerWINNT
DNSCPU = zen.novell.comPENTIUM
User" "MAC Address = rtanner 00600803c2e7
Remember that these values are used only at workstation object creation time. After the object is created, its name never changes. So if you replace the NIC card, although the address of the workstation changes, the name of the workstation does not change. If the name includes the NIC address, the workstation retains the name with the old NIC address.
The Workstation Groups page enables you to specify into which groups you want to place the workstation object when it is created. By placing the workstation object into a specific group you can automatically provide policies or rights to the workstation by group associations.
In the Workstation Groups page you may add and remove groups in the list, and the workstation will be made a member of each of the listed groups. The following describes the behavior of each button on the screen:
Add—Adds a group to the list. When the button is clicked a dialog box is presented that enables you to browse the tree to identify the group. You browse the tree in the right pane and select the group in the left pane. After a group is selected, it is added to and displayed in the list.
Remove—Becomes activated when a group in the window is selected. When a group is selected and Remove is clicked, the group is removed from the list.
Remove All—Completely removes all groups from the list and cleans the set from consideration.
Remember that the Workstation Import policy is activated only when a new workstation is imported into the tree. If a workstation created with this policy is associated with a group and you go into the import policy and change the group memberships, the workstations that have already been created retain their group memberships. Only the new workstations created after the change are affected.
On the Limits page the administrator can control when a workstation automatically registers and how the import service on the server behaves. The intention of these fields is to ensure that the performance of the service does not consume a significant amount of processing on the server.
The first portion of the page, the User Login Number field, enables you to configure how many times the workstation must be used (a user logs in to the network via that desktop) before it is registered into the tree. This may be useful if your desktops must pass through several hands (that may connect to the tree) before it gets to its final user destination. Each time the workstation is used and a user is connected to the tree (or the workstation manager agents connects to the tree), the workstation communicates with the workstation import and requests a workstation object. If the number of login times has not been consumed, the service reports that one is not created, and the workstation continues. This repeats until the number of login times has occurred, whereupon the service creates the workstation object and returns the eDirectory Distinguished Name (DN) of the workstation object to the workstation. The desktop records this DN in its registry.
Each time that a user logs in to the workstation, ZENworks updates a count. This count is kept in the workstation registry and is transmitted to the import server, which checks it against the policy. If the count is greater than the policy, the import is performed. This count on the workstation is not reset if the policy changes.
When the Disable History check box is checked, the system will not keep a record of the users who have logged in to this workstation.
Selecting the Limiting the Number of Workstations Imported check box and filling in the Workstations Created Per Hour field enables the administrator to throttle the number of workstations created. This keeps your eDirectory from overloading with a tremendous amount of objects and having to synchronize them around your tree. Imposing this limit forces the service to create only the specified number of workstations in an hour period. As soon as the maximum has been reached within the hour, the workstations are told to proceed without a workstation object. The next time the workstations log in to the network, and the maximum has not been exceeded, the service creates a workstation object for them.
Along with the ability to automatically create workstations in the tree, ZENworks provides an automated way to have expired workstation objects removed from the tree. This is to keep the tree from being cluttered with workstations no longer associated with any physical device.
Each time a workstation is used and has been registered in the tree, a service visits the workstation object and time stamps the last visit into the workstation object, along with refreshing several other pieces of information in the workstation object. This time stamp is what the workstation removal service looks at when it determines whether the workstation should be removed.
The Containers page enables the administrator to grant rights to the removal service to containers where they must remove workstation objects. When you add a container to the list, the system grants rights to the policy object. When the removal service needs to perform and delete a workstation object, it logs in as the policy being used, enabling it to obtain rights to remove workstation objects in the specified container.
These containers are the only ones that the service monitors for stale workstation objects.
The process of adding and removing containers is familiar. Click the Add button, and you are presented with a dialog box that enables you to browse through the tree to select the container you want. When selected, the container is added to the list, and the import service is given a trustee assignment to that container and given the rights to Browse and Delete objects.
To remove a container from the list, select the desired container and click the Remove button. This removes the trustee assignment given to the service and deletes it from the displayed list.
The Limits page enables you to specify how stale a workstation object must be before it is considered for removal. Figure 19.9 shows a sample Limits page.
You can use the up and down spinner controls to specify the number of days the workstation should not be connected with a device before it is considered for deletion. When the time stamp in the workstation object is older than the specified number of days on this page, the removal service deletes the object from the directory.
The Schedule page enables the administrator to identify how often and when the workstation removal service should run on the server.
On this page you may identify the following configuration schedules:
Year—The year to begin the launch of the removal service.
Date—The calendar date within the year specified in the “Year” field when the removal service will be launched.
Start Time—The time of day when the removal service is available to run.
Duration—How long, after the start time, should the removal service run.
Repeat Interval—How often after the initial start date the removal service should rerun and be made available.
Limit Number of Workstations Removed—In the session value, the maximum number of workstations that should be removed while the removal service is available. When this maximum is reached, the service quits removing workstations until the next specified execution time. This is to keep from consuming a significant amount of processing cycles for eDirectory Distinguished Name to refresh the partitions where the removal has occurred.
The service, when started, calculates based on the start date, how often it should come alive (interval), and which day it should work. If today’s the day, the service begins its workstation removal work. This is done so that even if the server needed to be rebooted, the service still would properly calculate the day it should run and not rely on being up the number of days in the interval.
Many of the agents in the system want to record information into the ZENworks database that is installed on your system. The ZENworks agents record logging and other information directly to the database and do not rely on the SNMP system to record events. In order for these agents to discover which database they should place their information in, they look for a ZENworks Database policy.
The Database policy then refers to a ZENworks database object in the directory (that was created at installation time), which in turn contains the DN or the IP address of the server that is supporting the database. The system also uses other information in the database object.
The Database page enables you to browse to the database object in the directory that represents the database that you want to use. All policy engines and distributor agents associated with this policy then log information into this database.
To set the Inventory Management database, you must go to the Inventory Database tab, click the Browse button to the right of the field, and then browse to and select the database object that you wishwant. This places the DN of the database object into the field.
To set the Policy/Distribution Management database, you must go to the Policy/Distribution Management Database tab, click the Browse button to the right of the field, and then browse to and select the database object that you want. This places the DN of the database object into the field.
ZENworks Server Management cannot use the database until a database policy is set and sent to the agents from the distributor.
In a ZENworks Server Management, you can define several configuration items in this policy that are applied to the components in the Policy and Distribution Services system. Using this policy keeps you from having to administer these items in each of the subscribers or distributors that you create in the network.
The Messaging property page is under the General tab. Unless you are having some problems and are diagnosing some issues, it is not recommended to request a message level higher than 4.
For each of the appropriate fields, you may enter one of the following message levels:
Level 6—This level includes all the other levels plus developer trace information.
Level 5—This level includes all Level 4 messages in addition to trace information, which notifies the observer of the modules that are being executed. This level also captures and displays all Java exceptions.
Level 4—This level includes all the Level 3 messages and, in addition, informational messages that identify key points in the system.
Level 3—This level displays any warnings that were encountered in the system in addition to all the Level 2 messages.
Level 2—This level displays the successes that were satisfied by the system and will also include all the Level 1 messages.
Level 1—This level displays only errors that were encountered in the system.
Level 0—This level displays no messages.
You can administer the following configuration parameters on the Message property page:
SNMP Trap—This identifies the level of messages that should be sent as an SNMP trap to the SNMP host. The SNMP Host policy must be defined and active in an effective (for the distributor or subscriber object) Service Location package for traps to be sent.
Log File—This identifies the level of messages that should be stored in the log file. Additionally, you can configure the following about the log file:
Filename—This is the filename of the log file. The default location for a distributor is SYS:TED2DISTDIST.LOG and SYS:TED2SUBSUB.LOG for a subscriber. You should probably change the location of the log file because it can grow. The log file may adversely affect the system because it is located on the SYS volume by default.
Delete Log Entries Older than X days—In this parameter, you identify the number of days (X) worth of log entries that should remain in the log file. The default is 6 days. Therefore, any log entries that are older than 6 days are cleared from the log file. The process of removing the old entries from the log happens once every 24 hours.
Email—With the email option, you can specify the level of messages that are sent in an email to the identified users. The SMTP Host policy in the ZENworks for Servers 3 Service Location policy package must be active and the package must be effective for the distributor or subscriber object in order to enable it to discover the address of the SMTP host to send the email. If this is not specified, the email will not be sent.
In addition to identifying the level of messages, you must also specify who should receive these messages. To add users to the list and have them receive the message, you must select whether you want to add an NDS User or Group, or specify an email address in the drop-down menu. When you select a user, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message, and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. It is expected that the attribute you identify will contain a valid email address.
If you choose to enter an explicit email address, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown as the User Name field in the table with an “N/A” in the Address Attribute field.
Under the ZENworks Server Management tab is the Configuration Page. You can administer the following configuration options on this page:
Working Directory—This is for temporary and backup files. The default directory is sys:zenworkspdssmanagerworking. For NetWare servers, do not use extended or double-byte characters in the path.
Purge Database Entries Older Than X Days—Specify a number for periodic purging of the database file. All Server Management information older than the number of days entered is purged when Server Management is started on the same server where zfslog.db resides.
Under the ZENworks Server Management Port Configuration tab is the Port Configuration Page. This allows you to specify the port that should be used for communications to the services running on the device. The default port is 8089 and can be changed by clicking the up and down arrows.
This chapter discusses all the policies available in the server package and those that are effective for servers in your network. Using these server policies allows you to efficiently configure your ZENworks system and describe the desired actions and behaviors so that ZENworks automatically manages your systems.