A fundamental objective of a design is to balance the need for hardware while easing the load on the customer's network during deployments:
A number of decisions should be made before installing the first ZENworks Primary Server:
Only the functionality that is needed by the customer should be enabled. Start with a simple approach, harden the implementation, and then expand it in the future. For example, if Patch Management, User Sources, and ZENworks Reporting Server are not required by the customer, do not enable or install them.
ZENworks Configuration Management provides the choice of using an external Certificate Authority (CA) or an internal ZENworks CA. If you choose an internal ZENworks CA, it created during the installation of the first ZENworks Primary Server and is used throughout the life of that ZENworks Management Zone. The current lifespan of the internal certificate is 10 years.
When an internal CA is used, its certificate is signed by the CA, as each subsequent Primary Server is installed.
When external CA is used, each Primary Server installation requires a signed certificate to be provided by the Administrator. The first Primary Server also requires the CA's public certificate.
The CA’s certificate is distributed to all managed devices as part of the ZENworks Adaptive Agent installation. This lets each Adaptive Agent connect to any Primary Server because each server’s certificate is signed by the now trusted CA. Each Primary Server's certificate is automatically distributed to every managed device as part of the configuration refresh.
As the expiry period for the Primary Server certificates signed by the internal CA is 10 years, the issue of expiration is something that you do not need to deal in the immediate future. However, the Primary Server certificates from an external CA within 1 or 2 years of the Primary Server certificates. If a Primary Server certificate expires, the agent communication with that Primary Server stops. In order to address this issue, ZENworks can allow the new Primary Server certificates that have been signed by an external CA to be imported into the Zone, and then automatically distributed to all managed devices as part of the standard configuration refresh. To add a new Primary Server certificate, use the following command:
zman server-add-certificate
This command should be used before the existing certificate expires. When the administrator is satisfied that every managed device has received the updated certificates via the configuration refresh, the following command needs to be run at the back end to instruct the Primary Servers to use the new certificate when establishing an SSL connection with a managed device:
novell-zenworks-configure -c SSL -Z
The ZENworks Control Center automatically informs the administrator 90 days before the certificate is going to expire.If the Certificate Authority itself is going to expire, or if new certificates are signed by a new CA, the new CA's certificate needs to be installed into the trusted root store of each managed device. To achieve this, the following steps need to be automated with a ZENworks bundle and be executed on each agent before the CA certificate expires:
Copy the new CA certificate to the device.
Import the new CA certificate by using the following command:
zac cert-info <path to the CA cert file>
With the previous generation of ZENworks, the technology was tied closely to Novell eDirectory. In traditional NetWare or eDirectory file and print environments, ZENworks is structured according to the design of eDirectory and was therefore based on geography. However, geography is no longer a requirement for the structure of folders in the Management Zone. Because devices can connect to any Primary Server, and all Primary Servers should be linked over fast links, the structure of management can be based on other criteria.
Customers might want to base the folder structures for devices on business functions, such as Human Resources, Finance, Sales, and so forth.
Basing the device folder structure on geography is still possible and might be required by many customers. Some customers might want to implement policies and applications site by site, room by room, and so forth.
The choice of a folder structure should also take into account the potential use of dynamic groups. Dynamic groups are groups whose members are automatically decided based on rules. In some environments, departments have a pool of devices for their users, so the standard tools remain static over its life. However, the location of the device can change frequently based on mobility of the user. In this scenario, the departmental structure of the business can be created by using folders, because the folders are fairly static and the geographical locations can be modelled using dynamic groups. This allows for easy definition of standard tool sets and configurations for common-interest groups but still allow for updates to be rolled out on a location-by-location basis.
Traditional ZENworks implementations require file repositories to store application content. Users and devices access this content via mapped network drives or directly via UNC paths defined in the application object. Although this fits well with a traditional file and print model, it has the following drawbacks:
Synchronization: If an application is to be made available to all users, the source content must be copied to all servers. This requires additional products and processes to be introduced to manage the location of content, such as the Tiered Electronic Distribution component of ZENworks Server Management.
Rights: When files are stored in a traditional file and print model, the rights to these locations must be managed carefully. If you roam between sites, you might need access to all application repositories to ensure that applications can be installed and verified at any location. In a traditional model, if you have the read access to an application store, you have the ability to manually install any application that resides there, provided you know where to look.
With ZENworks Configuration Management, bundles can be created to install applications from mapped network drives and UNC paths as before. If you used mapped drives and UNC paths, file synchronization and the rights to those files must be managed outside of ZENworks Configuration Management.
ZENworks Configuration Management also allows for application content to be injected in to the ZENworks Content Repository. By default, the Content Repository is synchronized between all Primary Servers and is downloaded by devices using HTTP. You can, however, specify which of the Primary Servers host content (at least one Primary Server must host the content).
Using the ZENworks Content Repository has the following advantages:
Synchronization: Content is automatically synchronized to other Primary Servers and the defined Satellite devices. This allows devices to download content from the most appropriate location. The synchronization schedule and bandwidth consumption can be tightly controlled to avoid negative impacts on the customer’s network
Rights: Rights to files do not need to be managed. Only devices and users who are assigned to the content via relationships to Bundles and Policies in ZENworks Configuration Management have access to that content. If a user accesses a ZENworks Content Repository, the content files are encrypted and cannot be used.
Content is firewall and location friendly: Files are securely delivered in an encrypted fashion via HTTP protocol. This means that there is no need for the user to have the correct drive mapping with the necessary rights. If the user has been assigned the content, it is downloaded via HTTP from the most suitable location.
Downsides to using the Content Repository include the following:
Disk Space: Additional disk space is required. Many customers have extremely large application repositories distributed over many servers. These repositories must be re-created in ZENworks Configuration Management. If a customer has a 100 GB application repository, ZENworks Configuration Management requires at least 100 GB on each Primary Server with a content role to store applications, in additional to the space needed for other content, such as patches and system updates.
MSI applications cannot be easily changed: After an MSI application is uploaded to the Content Repository, it cannot be changed. To make changes, the original MSI must be updated and then re-injected back into the Content Repository. In this scenario, a master store of all applications must reside outside of ZENworks Configuration Management to allow for edits.
Grouping devices is very important in ZENworks Configuration Management because it allows applications, policies, and system updates to be deployed in a staged manner.
In ZENworks, if a change is made to an application or a policy, everyone receives the change. Controlling the introduction of change is vitally important in maintaining a secure and stable environment.
We recommend that you identify the following groups in your customer environment:
Test devices: Identify test devices that are first to receive updates. Ensure that build versions are represented for each operating system in the field.
IT departments: Identify IT staff that are typically the first users to receive live updates and applications.
Early adopters: Identify early adopters who will test deployment in each business unit and geographical location.
Home workers/VPN users: Identify home workers or users who use a VPN so they can help test deployment via DMZ and VPN connections.
VIP users: Identify important users whose devices require special focus and attention. You might want to transition executive laptops and workstations at the end of deployment.
General population: Create logical groups for the rest of managed devices, based on business function or geography.
Creating these groups or folders is an important factor in releasing new configurations, applications, and updates in a controlled manner to the managed environment.
In situations where an application or policy is already live in an environment, grouping does not help in executing change on this object in a controlled manner. After the bundle or policy has been changed, all users and devices with an association or inheritance receive the change automatically on the next refresh. To provide control in this scenario, ZENworks 11 has introduced change and release management capabilities through the concept of sandboxing for all policies and bundle types in ZENworks.
Sandboxing allows for devices and users to be marked as test devices or users, and when a change is made to a bundle or policy, only the test devices or users will receive the change. This allows selected devices and users in different locations and departments to test and ensure the quality of the change before it is released to the rest of the environment.
In order to calculate what infrastructure is required and where it should be located, you need to plan for the scalability of ZENworks Configuration Management.
NOTE:At the time of writing this document, the SuperLab facility in Provo, Utah has provided metrics and results, as seen in various places in this section, that give you a better understanding about how the individual components scale. These figures will be kept up-to-date as this document continues to grow over time.
Based on the connection information, the number of ZENworks Primary Servers and Satellite devices needed to support thousands of devices can be calculated with the following rules in mind:
Each Primary Server must be connected to every other Primary Server, the database, and the user source by LAN speed or close links. Placing Primary Servers behind strong links allows for content synchronization, credential verification from the user source, and access to the ZENworks Configuration Management Database Server to occur quickly and efficiently. Performance suffers, including response times when you use ZENworks Control Center to perform administrative tasks, if there are any barriers between Primary Servers and the Database Server.
When you configure satellite devices, consider the following:
Currently, Satellite devices are primarily designed to reduce load on the network, not to reduce load on the Primary Servers.
Consider a scenario in which a Primary Server is located at Site1, and 10 managed devices are located at Site2. Site1 is connected to Site2 over a WAN or a slow link. The managed devices are on a LAN or a high-speed link. If you do not choose to configure a Satellite at Site2, then each managed device must traverse the network to get content from the Primary Server. If you choose to configure a Satellite at Site2, then only the Satellite would traverse the network to get content from the Primary Server, and all the managed devices would get the content that is locally available at the Satellite.
Bandwidth calculations are based on ZENworks Configuration Management having access to a known percentage of the total bandwidth for a given link.
Satellite devices should be located at remote sites to provide content local to devices on the local network.
The following scale assumptions can be made when building the design of the infrastructure. These actual scale assumptions might be different, based on the services you are providing and how you break up the services across multiple servers.
ZENworks Primary Server: A single ZENworks Primary Server can provide all ZENworks services (content, collection, and configuration) for as many as 3,000 devices in a ZENworks Management Zone.
This is based on a Primary Server handling approximately 1,000 concurrent connections for all service types (content, configuration, and content).
This is not real-world; see Section 3.2, Scalability of the Primary Server for additional details on how these figures can change, and what you need to consider to ensure that you are scaling to meet the needs of the organization.
Server-grade Satellite device: A single ZENworks Satellite (dedicated server) can provide content services for as many as 1,000 concurrent devices.
This is not real-world; see Section 3.3, Scalability of Satellite Devices for additional details on how these figures can change, and what you need to consider to ensure that you are scaling to meet the needs of the organization.
Workstation-grade Satellite device: A single ZENworks Satellite (dedicated workstation) can provide content services for as many as 250 concurrent devices.
This is not real-world; see Section 3.3, Scalability of Satellite Devices for additional details on how these figures can change, and what you need to consider to ensure that you are scaling to meet the needs of the organization.