A fundamental objective of a design is to balance the need for hardware while easing the load on the customer's network during deployments.
The following sections contain more information:
A number of decisions should be made before installing the first ZENworks Primary Server.
The following sections contain more information:
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 BOE Reporting 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. The ZENworks CA is 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 ten years.
As each subsequent Primary Server is installed, its certificate is signed by the CA. The 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 trusted CA.
Currently, there is no easy automated method for changing the CA. To change it, each server's certificate must be re-minted and the certificate of the new CA must be delivered to all managed devices. For this reason, the decision to use an external CA must be considered very carefully. Certificates provided by VeriSign usually expire after one or two years. If you use these certificates, ZENworks Configuration Management loses all functionality on the expiration date because ZENworks Adaptive Agents cannot check into the ZENworks Management Zone.
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.
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 users roam between sites, they might need access to all application repositories to ensure that applications can be installed and verified at any location.
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 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 Satellite devices. This allows devices to download content from the most appropriate location.
Rights: Rights to files do not need to be managed. Only device and users who are assigned to the content 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. In a traditional model, a user with read access to an application store has the ability to manually install any application that resides there.
Content is firewall and location friendly: Files are delivered encrypted over HTTP. 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 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 fashion.
We recommend that the following groups are identified 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.
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 using ZENworks Control Center to perform administrative tasks, if there are any barriers between Primary Servers and the Database Server,.
When configuring 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 slow link. The managed devices are on a LAN or 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 should 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.