The following decisions should be made before installing the first ZENworks Primary Server:
Only the functionality that is required by your organization should be enabled. Start with a simple approach, harden the implementation, and then expand it in the future. For example, if Patch Management and User Sources are not required for current requirements, do not enable or install them.
ZENworks provides the choice of using an external Certificate Authority (CA) or an internal ZENworks CA. If you choose an internal ZENworks CA, it 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 10 years.
See the ZENworks Server Installation for further details on the Certificate Authority. It is a good practice to backup the CA and ensure that the backup is stored in a safe place.
For more information on the pros and cons of Internal versus External certificates, see Section 14.0, Design.
With ZENworks 7 or earlier, the technology was tied closely to eDirectory. In traditional NetWare or eDirectory environments, ZENworks infrastructure 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.
You 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. You 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 allows for updates to be rolled out on a location-by-location basis.
Historic 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, bundles can be created to install applications from mapped network drives and UNC paths as before. If you use mapped drives and UNC paths, file synchronization and the rights to those files must be managed outside of ZENworks.
ZENworks also allows for application content to be injected into the ZENworks Content Repository. By default, the Content Repository is synchronized between all Primary Servers and is downloaded by devices using HTTP, although CIFS is also supported. You can, however, specify which of the Primary Servers host content (at least one Primary Server must host the content). You can do the same to specify which Satellite Server to replicate the content to. You can do the same in order to specify to which Satellite Server you need to replicate 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 your organization’s network. ZENworks allow content to be distributed through the normal closest servers hierarchy.
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 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. If a customer has a 100 GB application repository, ZENworks requires at least 100 GB on each Primary Server with a content role to store applications, in addition 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 ZENworks to allow for edits.
Grouping devices is very important in ZENworks 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 environment:
Test Devices: Identify test devices that are the first to receive updates. Ensure that build versions are represented for each operating system in the field.
IT Department: Identify IT staff that are typically the first users to receive live updates and applications.
Early Adopters: Identify early adopters who will test the deployment in each business unit and geographical location.
Home Users/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 Populate: Create logical groups for the rest of the 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 a 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 introduced change and release management capabilities through the concept of sandboxing for all policies and bundle types in ZENworks. This feature of ZENworks can be leveraged after you have identified and designated specific devices to be “test devices”.
Sandboxing enables 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.