Registration Web Server

  • 3277197
  • 12-Oct-2007
  • 27-Apr-2012

Environment

Novell ZENworks 10 Configuration Management

Situation

Information and troubleshooting the ZCM Registration Process - Registration Web Server.

Resolution

Registration Web Service

Overview
The Registration Web Service (RWS) provides the registration mechanism for managed devices. Before a device can be managed, it must be represented within the ZCM data-store. The RWS is responsible for the creation of an appropriate object within ZCM data-store (containment), uniquely naming the object (naming), and adding the object to the desired groups (group membership).
RWS also stores and maintains pertinent managed device attribute information within the data-store such as: Global Unique ID (GUID), last contact, IP addresses, site, department, location, cpu, operating system, dns name, device type, language, etc. In addition to registration and update services, the RWS also provides to ability to remove or retire a device object in the Pulsar data-store.

The RWS functionality is exposed through a standard HTTP/SOAP request. When a device makes the request for registration, it will provide both required and optional attributes including an optional registration key. In addition to providing a key-based registration model, ZCM will also retain the ability for registration to take place based on a set of attribute-driven rules.

How It Works
A managed device is known only by its 32byte unique Global Unique ID (GUID). The GUID is determined by the managed device.

Registration of a managed device can occur in three ways:

  1. Migration -> Deployment -> Registration
  2. Discovery ->Deployment -> Registration
  3. Manual Installation -> Registration
  4. Manual Registration -> Manual Installation -> Reconciliation

Migration:
During migration, the preexisting GUID is preserved so that preexisting assignments and policies can be maintained. The GUID is preserved by the migration utility and placed on the managed device so that when the managed device registers, it used the preexisting GUID.

Deployment:
After the Deployment task pushes the client to the managed device, the managed device will reboot and attempt to register with a Primary Server. If the registration is successful, the RWS will mark the Deployment as Complete.

Manual Registration:
If an administrator desires to incorporate a managed device into the management zone before the device has physically been connected, they do it through manual registration which requires only three pieces of information:

  1. Hostname
  2. Serial Number
  3. Registration Key Name

The managed device is now represented within the management zone, however no policies, or actions can be applied to the device until it is physically connected to the management zone. When the administrator deploys the client to the managed device, the serial number is used to reconcile the managed device to the existing managed device representation in the management zone.

Two Registration Types:
The Registration Web Service provides two registration mechanisms:

  1. Key-based Registration (Preferred)
  2. Rule-based Registration

Both registration mechanisms are controlled by the configuration tab in ZCC where an administrator can define both registration rules and registration keys. In addition to defining rules and keys, the administrator can use ZCC to set global registration settings such as the Registration Naming Template, and Rule-based Registration settings.

Initial registration determines the device name based on the naming template associated with the location where the device is to be created, the device location, group membership, and device attributes like IP address, DNS name, Hostname, etc. Subsequent registrations associated with the device refresh will never update the device location.

ZCC allows the following registration related settings:

  1. Global Naming Template (This template can be overridden at different locations)
  2. Dynamic Rename (If any of the information used to name device changed, the name changes)
  3. Enable/Disable Rule-based registration.
  4. Enable/Disable Default Rule (Default Location, Default Name, No Groups)
Duplicate hostnames
If, for some reason, the managed device uses a new GUID to register, you may see a device name that looks like this:
Devicename-GUID (example: devicename.novell.com-457e23a891b9c367ccb2a6777121f53d)
This means that when the managed device registered, it was seen as a new device (because of the new GUID), but the hostname was already taken. To insure uniqueness in the device name, the GUID is tacked on the end. This means that the managed device devicename.novell.com will likely become a lost device.
Incompatible Registration Rule
Sometimes an administrator will define a registration key or rule such that the location is not compatible with the device type. The registration attempt will fail in this case.

Log Files
The Registration Web Service writes its debug messages into the services-messages.log file located in the following directories:

Windows:://Novell/ZENWorks/logs/service-messages.log
Linux: /var/opt/Novell/logs/zenworks/service-messages.log

Disable first time Registrations
To turn off first time registrations on a Primary Server that is outside the firewall, edit the following file:

Windows: ZENWorks/share/tomcat/Troubleshooting/zenworks-registration/WEB-INF/config.xml
Linux: /opt/novell/zenworks/share/tomcat/webapps/zenworks-registration/WEB-INF/config.xml

and set the tag to false. This will reject all new registrations from outside the firewall.
Connectivity Test
To test if the Registration Web Service and the ZCM server are working, you can ping the Registration Web Service by typing the following in your browser:

PrimaryServerAddress/zenworks-registration/registration

This should display the Web Service menu for the Registration Web Service. Select the "Test Service” link and then select the third "ping” method. Then click the Invoke button and you should see the following message:

Result Pong: You pinged from [your ip address]
Registration Rule Ordering
Always place the most restrictive rules first because they are evaluated from the top down. If you place the most general rule first, the more descriptive rule will be missed.