Novell is now a part of Micro Focus

Standardizing Network Server Configurations with Server Policies in ZENworks for Servers

Articles and Tips: article

Rick Cox
Product Manager
Novell, Inc.
rcox@novell.com

Jason Werner
Product Marketing
Novell, Inc.
jwerner@novell.com

01 May 2000


The shift of the industrial economy of the past to the information economy of today has fueled exponential growth of not only the global information infrastructure, but also of the information infrastructures of the individual organizations and enterprises that make up today's marketplace. As both traditional and e-businesses become more dependent on vital, up-to-the-second information, these information networks expand, forcing organizations to spend more time and effort on ensuring the continued operation of their networks and key components. In organizations with more than a handful of network servers, network administrators spend inordinate amounts of time configuring and maintaining servers so they will be able to continually deliver the most current information into the hands of employees. In many cases, basic maintenance and configuration operations on such network servers must be performed in person, resulting in time wasted traveling to various branch offices.

Novell's ZENworks for Servers (ZFS) eliminates this waste of time by enabling administrators to manage and configure geographically-disbursed network servers from a central location. It enables organizations to standardize the configuration of their network servers, creating policies that can be automatically applied to servers across the network. ZFS automates the deployment of server applications and services to targeted network servers, facilitating application updates and version consistency. ZFS also enables IT organizations to proactively manage servers in an effort to prevent problems before they impact user productivity and business operations.

As a follow-up to "Improving Information Dissemination with ZENworks for Servers and Tiered Electronic Distribution" in the March 2000 issue, which covered Tiered Electronic Distribution and Server Software Packages, this AppNote describes ZFS Server Policies.

Introduction to ZFS Server Policies

Before launching into a detailed discussion of Server Policies, it might be helpful to briefly review ZENworks for Servers as a whole. ZENworks for Servers is a directory-enabled server management solution that leverages the power and flexibility of Novell Directory Services (NDS) to keep network services running and to effect change without disruption. It consists of three main components:

  • Server Policies

  • Tiered Electronic Distribution (TED)

  • Server Software Packages (SSPs)

Server Policies enable organizations to standardize the configuration of all their network servers. Most organizations acquire their servers in piecemeal fashion, configuring each one individually as they are deployed. As a result, server configurations generally differ from department to department, and from site to site. With ZFS Server Policies, you can create, distribute, and consistently enforce across the network the rules that govern server activity. If someone changes a server configuration, you can schedule ZFS to automatically reset the configuration, guaranteeing that all network servers stay configured according to the established policy.

TED streamlines software delivery by automating the distribution of information. Organizations can schedule when information is to be delivered to their servers. A special feature of ZFS enables organizations to deliver that information with minimum impact on wide area network (WAN) traffic.

SSPs simplify server application distribution and installation. Organizations can assemble an application and its installation instructions so that when the package arrives on a server, it will install itself without further intervention. When a server application (NetWare Loadable Module) needs to be upgraded, organizations can create an SSP with the upgraded application, and then distribute and install it on all of their servers in a single operation. If the upgrade operation fails for some reason, ZFS can notify the appropriate network administrator.

By combining policy-based server management, server-to-server software distribution, and software installation, ZFS provides a three-pronged approach to server management that addresses critical IT needs:

  • It empowers IT departments to implement change control processes that can minimize an organization's down time and delays associated with deploying new hardware, server software, service pack updates, and network services.

  • It increases IT staff efficiency and effectiveness, in spite of continued network growth.

  • It leverages existing directory structure and server platform investment.

  • It reduces redundant network management tasks through automation.

  • It improves end-user productivity through reduction in network disruptions and problems.

With its high degree of scalability and NDS integration, ZFS is a cost-effective way to manage enterprise servers individually or in groups, regardless of their location on the network.

The Need for Server Policies

The growth of today's information economy has led to non-stop expansion in many organizations' internal network infrastructures. As the number of network servers continues to rise within an organization, the ability to efficiently manage those servers grows more complex and difficult. In an effort to avoid potential network problems and to simplify troubleshooting efforts, excessive time and money is spent on standardizing the settings and configurations of all the servers spread throughout a large organization. Simple operations such as bringing a server down for maintenance can have costly repercussions when a network administrator fails to follow standard procedures to ensure that business critical operations are not being performed before downing the server.

As a directory-based management solution, ZFS lets IT managers easily standardize server configurations and enforce server policies across the network enterprise to help keep business services running on the network without disruption. ZFS is a "set it and forget it" server management solution that centralizes and automates information distribution and server configuration throughout an enterprise network. Especially designed for organizations that need to distribute vital data quickly or according to a schedule, ZFS allows for automated data distribution from a central location so that administrators do not need to visit each server individually.

ZFS lets IT managers enforce polices for all the network servers under their responsibility any way that they see fit. ZFS provides IT managers the needed flexibility to enforce policies at the enterprise, branch office, or departmental levels by allowing policies to be associated by server, group of servers, or organization units (OUs). IT managers also have the flexibility of exercising granular control over the entire enterprise's policies, or implementing general polices for the corporation and then allowing local network administrators to set policies specific to their group's particular needs.

Benefits of Server Policies

ZFS enables IT managers to use the power of NDS to standardize the configuration of servers in their NDS tree. Rather than simply hoping IT teams will adhere to established server configuration guidelines, IT managers can simply implement a policy with ZFS and know that it will be automatically carried out enterprise-wide.

ZFS greatly facilitates IT managers' ability to maintain and enforce standard configuration settings for their network servers. Server Policies can also function as proactive measures to help prevent inadvertent network disasters. Bringing a server down for maintenance in the middle of an important slide show being presented to investors by the organization's CEO or while payroll is generating paychecks for the month can have serious repercussions to both the livelihood of the business and to the culpable administrator. ZFS server policies can help avoid such catastrophes by setting a policy to cancel a DOWN command if a particular user is logged on or if a designated process is running.

ZFS polices provide additional capabilities, including being able to ensure that certain procedures take place when a server shuts down, that servers will shut down and restart according to a determined schedule, that a specified custom script will execute on specified servers, or that new configuration parameters will be deployed globally.

Technical Overview

ZFS Server Policies simplify the configuration and management of servers across the network. Server Policies let IT managers and network administrators regulate the configuration properties of servers, as well as dictate how the servers should behave in certain situations. As an NDS-based policy management system for servers, ZFS provides a unifying view of the whole network, leveraging the NDS security scheme and enabling organizations to manage the relationships between their network devices and users. The combination of NDS and ZFS allows IT managers to securely create policies and apply them to servers throughout their information network. Without NDS and ZFS, IT managers would have to maintain several parallel management infrastructures, which would require manual updates to each server whenever a change was made.

ZFS Server Policies are divided into three groups, referred to as policy packages:

  • Server Packages

  • Service Location Packages

  • Container Packages

These policy packages are logically segmented to simplify the process of establishing enterprise-wide network server policies. These packages will be explained in more detail under the "Policy Package Descriptions" heading.

Changes Made to the NDS Schema

When ZFS is installed, the installation program extends the schema of the NDS tree to incorporate support for ZFS's Server Policies. The schema extensions add properties to existing NDS objects and add several new NDS objects:

  • Policy Package Object. This is a container object that holds the Server Package, the Service Location Package, and the Container Package.

  • Server Package Object. This is a container object that holds the Server Down Process, Scheduled Down, NetWare SET Parameters, Scheduled Load/ Unload, Server Scripts, Text File Changes, ZENworks for Servers, and SNMP Trap Target Refresh policies.

  • Service Location Package Object. This is a container object that holds policies for SMTP Host, SNMP Trap Targets, and the ZENworks Database.

  • Container Package Object. This is a container object that holds the Search Policy for ZFS.

  • ZENworks Database Object. This is a leaf object that defines the location of the ZENworks database that ZFS components use for reporting purposes. Multiple Database objects can exist in a tree, but there can only be one per server.

Server Policy Architecture

The ZFS installation program installs a set of policy enforcers on each ZFS- enabled server. Each of these policy enforcers corresponds with each of the policies contained in the Server Policy Package. ZFS relies on a piece of code referred to as the ZFS Facilitator to dynamically find these policy enforcers on servers spread throughout the network and then utilizes a Policy Manager to marry these policy enforcers with the actual policies set in NDS. Basically, the Facilitator finds all the servers' policy enforcers that match enabled policies, and then schedules those policies to run at the appropriate times on those servers (see Figure 1).

Figure 1: The ZFS Facilitator matches NDS policy extensions to ZFS policy enforcers found on network servers.

Policy Features

ZENworks for Servers enables IT managers to set policies that not only increase overall network administration productivity, but minimize network down time. In total, ZFS lets organization take advantage of fifteen different policies, including the following:

  • Server Down Process. This policy specifies what processes will be followed when a server or servers are brought down and what conditions must be met before the server(s) will actually shut down.

  • Scheduled Down. This policy schedules when a server or set of servers should go down, and whether the server(s) should automatically come back up.

  • Text File Changes. This policy automates system-wide changes to server text files (AUTOEXEC.NCF, STARTUP.NCF, and so on).

  • NetWare Set Parameters. This policy maintains standard sets of configuration parameters for an enterprise's network servers.

  • Scheduled Load/Unload. This policy specifies the order in which NLM and Java class processes will load and unload.

  • Server Scripts. This policy automates the execution of custom scripts on network servers distributed throughout the enterprise.

  • SNMP Trap Targets. This policy sets SNMP trap targets for associated NDS objects.

  • ZENworks for Servers. This policy establishes the configuration parameters for ZFS to be used by servers on an individual, group, or OU level.

Policy Associations

ZFS provides IT groups significant flexibility in deploying policies to their network servers. Policies can be associated to individual servers, server groups, or OUs according to the needs or design of the IT organization. This enables IT managers to have one set of polices for database servers, another set for Web servers, one for file and print servers, and so on. If desired, general sets of policies can be created that apply to all servers or a subset of servers. IT managers can determine for themselves the best way to establish and deploy policies for the network servers in their charge.

Policy Schedules

ZFS allows IT managers to schedule when and how they want specific policies to be implemented. This enables ZFS to automatically perform routine server management tasks on a schedule or in response to an event, such as server startup. Policies can be scheduled to run daily, weekly, monthly, yearly, at a specific time, at intervals of time, when certain events occur, immediately, or at a time relative to when that policy is refreshed.

Policy Package Descriptions

Server Policies are applied to servers in the NDS tree through the means of policy packages. Policy packages are groupings of policies that ZFS provides to make it easier for IT managers and administrators to apply and schedule policies.

After ConsoleOne is used to create the Policy Package Object, any of ZFS's three policy packages can be created to implement ZFS Server Policies:

  • The Server Package contains a generic set of policies that can be applied to a set of ZFS-enabled servers.

  • The Service Location Package contains policies specific to running ZFS, such as those that relate to SNMP and database services.

  • The Container Package holds the container search policies, which determine how ZFS manages the policies within NDS.

Multiple policy packages can be created for an NDS tree. Each package can be customized for a specific server or groups of servers. To customize a policy package, an IT manager can enable any or all of the predefined policies contained in the policy package. The IT manager can then set its run schedule (immediately, daily, monthly, yearly, and so on) or rely on the policy's default schedule. Once the policy package is configured, it must be associated with a server, a group of servers, or an NDS container.

Server Package Policies

Policies contained in the Server Package are those that directly affect network server operations and settings.

Server Down Policy. The Server Down Policy establishes the steps a server will take before it shuts down, whether it is being brought down by someone at the console or as a result of a scheduled down. The Server Down policy allows IT managers to enforce specific procedures to automatically occur before a server actually goes down. Implementing this policy can avoid disruptive and often costly effects associated with network servers being shut down improperly.

Some of the features of this policy include the following:

  • Establish time delay before server goes down

  • Disable user login

  • Send customized broadcast to logged in users

  • Send e-mail notification that the server down process has initiated

  • Set time before users will be disconnected from server

  • Cancel server down process under specified conditions (open files, running processes, user connections, and so on)

  • Specify unload order of server processes

  • Assign other servers to monitor server restart and send SNMP alert if restart does not occur

When a DOWN command is issued, the actual shutdown process will be put on hold in accordance with the delay time set within this policy. This can be set to give users ample time to save their data, exit their applications, and log out. To facilitate this process, a customized broadcast message can be sent to all logged in users, giving them notification that the server will be going down in a specified number of minutes. IT managers can also specify in the policy how often this broadcast message should repeat.

Additionally, the policy can be set to automatically notify specific individuals via e-mail that a shutdown command has been issued at that server. If for some reason this server is not actually supposed to shut down, this notification enables IT managers to be contacted in time to stop the process before the server actually goes down. An IT manager can cancel the server down process from a network workstation running ConsoleOne, or from any Web browser that can authenticate to the network.

The policy can also stipulate that the server down process will be cancelled if specified files are open, specific NLMs are running, a certain number of users are logged in, or specified users are logged in. This feature helps ensure that the server will not be brought down if critical operations are in progress, such as check printing for the company payroll or a server backup. This feature can also be useful if you don't want the server to go down while the company CEO or other individuals are logged in.

Other features of this policy include the ability to indicate the unload sequence of applications running on the servers, as well as the ability to disable users from logging in while the server is preparing to go down. Additionally, under this policy other servers can be assigned to watch for the downed server to come back up. If the downed server does not restart in a specified amount of time, an SNMP alert can be generated, notifying administrators that there may be a problem with the server.

Scheduled Down. The Scheduled Down policy enables IT managers to have certain servers automatically shut down, restart, or reset at a specific time. This can be useful in situations such as planned backups, where an administrator wants to make sure that not only all users are logged off, but that the server is in a "clean" state before the backup occurs.

Text File Changes. The Text File Changes policy provides IT managers an enormous amount of power and flexibility in making global changes to their network server settings that happen to be stored in text files such as AUTOEXEC.NCF or STARTUP.NCF. With this policy, the IT manager can edit any text file stored on a network server. For example, if it is determined that additional memory should be allocated to certain network server LAN adapters, this policy can be used to search for a substring in the AUTOEXEC.MCF file that contains the "Load" command followed by the LAN adapter's driver name. Whenever the server finds this instance, it can either replace that line or string with a new command string, or simply append the desired memory attributes to the end of that line.

This policy provides IT managers a wide variety of methods to choose from in implementing these text file changes. Searches can be based on substrings, whole words, an entire line, or the end or beginning of a line. It also lets you prepend a line with a specified string, create new text files, and delete text files. The policy also provides a choice of sixteen different ways to replace the found text, including replacing a string, word, line; appending or prepending lines; adding lines before or after; deleting words, strings, lines; deleting every line before or after the found text, and so on.

NetWare Set Parameters. The Set Parameters policy facilitates the process of standardizing the configuration properties of all servers in an enterprise network. With this policy, IT managers can create a model server to act as a frame of reference for all servers in the network. Once this "golden" server is established, ZFS queries and captures all or part of its server settings. These settings can then serve as a modifiable template that can be used for and automatically deployed to every server, or to a cross-section of servers in the enterprise. To ensure that these settings remain in force, they can be scheduled to run periodically or be refreshed so that if changes are inadvertently made to the server, it can be reset to the correct settings.

Scheduled Load/Unload. ZFS enables NLMs or Java processes to be automatically loaded or unloaded according to a specified time, frequency, or date. This policy can also be used to immediately load or unload these server processes, enabling administrators to free up system resources for certain activities or ensure that a certain process is loaded or unloaded before initiating scheduled server operations.

Server Scripts. Server Scripts provide IT managers with a tremendous amount of power and flexibility in enabling certain server operations to occur system wide according to a specified schedule. The ZFS Server Scripts policy inherently supports Perl, NetBasic, and NetWare (.NCF files) scripts, but it also accommodates other scripting languages by providing support via the "Run" command. This policy provides increased capability when combined with the Scheduled Load/Unload policy, as in the example of unloading any required server processes before running an automated script to back up a server.

Furthermore, Server Scripts give IT organizations virtually unlimited ability to create their own custom policies and server operations, while taking advantage of NDS and ZFS's security, scheduling, administrative, and policy distribution scheme. For example, a script could be written to purge server volumes. Since this script can be scheduled to run on any or all of a network's servers, it becomes, in essence, a new policy for that network. By leveraging Server Scripts in this fashion, IT managers can literally create as many new policies as they want, extending the power of ZFS to fit their unique requirements.

Service Location Package

Server Polices call the policies within the Server Location Package every time an e-mail notification, SNMP alert, or report event needs to be generated.

SMTP Host. The SMTP Host Policy sets the IP address of the relay host that processes outbound Internet e-mail. This policy must be in effect to use e-mail notification options in ZFS's Distributor, Subscriber, Proxy, and Policy objects.

SNMP Trap Targets. The policy for SNMP Trap Targets functions as the name implies. It sets SNMP trap targets for associated NDS objects. Both this policy and the SNMP Trap Target Refresh policy are used to provide support for SNMP management.

ZFS Database. From within the Service Location Package the ZENworks Database policy can be enabled to allow ZFS to log information in a Sybase database. The database policy enables ZFS's reporting capabilities in order to assist IT managers with the task of managing server policies and server-to-server distributions. The information stored in the database is used to generate reports on the success or failure of policy enforcement and software distribution.

ZFS provides the following canned reports for Server Policies:

  • Discovered Policies

  • Down Policies

  • Failed Policies

  • Successful Policies

  • Unenforceable Policies

Container Package (Search Policies)

The Container Package holds ZFS's Search policies. The Search policies allow each ZFS-enabled server to search NDS for its associated policies. The Search policy tells the server where to look in the NDS tree for these policies, as well as to what extent it should keep looking for a policy before it gives up. The Search policy can search a maximum of 25 levels in either direction from the defined originating point.

The Search policy helps ensure that all servers are running the correct and most recently established policies. As new polices are introduced, the Search policy lets the network servers automatically discover the new polices and implement them according to their individual schedules. If no search policy is defined, ZFS uses the default, which is to search from the parent container to the root every hour.

Refresh Interval. The Refresh Interval determines how often a server will search NDS for its associated policies. Configuring a policy, or making changes to a policy's configuration, does not immediately place it in effect. The policy engine must refresh the policies to activate the latest configuration. This is an essential attribute, especially for those instances where a local administrator mistakenly changes a server's settings contrary to the established policies. With the Refresh Interval set appropriately, the policy engine can search for the server's associated polices so the server can refresh or reset back to the correct settings.

Overriding Policies. The search order defined by the Search policy can also determine how policies will override each other. For example, a policy package associated with a server would override a similar policy associated with the server's parent container if the search order required it to search the server object before it searched the container object. This override would occur because the policies associated with the server object would be found before the policies associated with the container. However, if the policies happened to be cumulative rather than singular, both policies would run and no overriding would occur.

Plural Policies

Some policies are plural, meaning that they can exist more than once in a policy package. Plural policies are useful for situations when you need use the same type of policy in different ways and at different times. For example, you might have different Server Scripts that you need to run at different times on your servers. Or you might want to schedule your servers to restart at the end of each month, as well as on specified days such as holidays.

Plural policies include:

  • Set Parameters

  • Scheduled Down

  • Run

  • Server Scripts

  • Scheduled Load/Unload

  • Text File Changes

Plural policies should be assigned unique names such as "Monthly Scheduled Down" and "New Years Scheduled Down."

Cumulative Policies. Cumulative policies are a type of plural policy that allows multiples of the same policy type to be in effect when associated to an object, group, or container. For example, a Text File Changes policy associated with server ADMIN1 could be accumulated with a differently configured Text File Changes policy associated with server group IT. If server ADMIN1 happens to be a member of that server group, all of the text file changes from both policies would be effective for the ADMIN1 server.

Cumulative policies will run at their lowest policy search level, and then rerun at the next level throughout the search path. This means that accumulative policies can be both additive and overriding.

Conclusion

ZENworks for Servers replaces reactive management of individual servers with proactive server-group management. ZFS eliminates time wasted on repetitive administrative tasks, allowing IT managers to focus on more important issues. ZFS's "Set it and forget it" capabilities let IT departments create standard policy sets and then have them automatically deployed to network servers across their entire enterprise. Leveraging the power of the industry's leading directory service, ZFS maximizes user productivity, reduces IT burdens, minimizes downtime, and lowers total cost of ownership.

* Originally published in Novell AppNotes


Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates