Server Management allows you to solve geographic, workload, and redundancy issues for applications distributed by Novell Application Launcher™ that might otherwise require much of your time in manual configuration work in Desktop Management. Review the following sections to see how Server Management can help you to automate much of your desktop application work.
In Desktop Management, you can create Application objects so that users or workstations can receive their applications through Novell Application Launcher. An Application object contains pointers to the files belonging to the application, and also contains configuration parameters for how the application is to installed and configured on the desktop.
In Desktop Management, the files belonging to an application can exist on any server, and the related Application object can exist anywhere in the tree. Therefore, for a workstation to receive an application through Novell Application Launcher, the application’s files are copied from a server and installed on the workstation.
However, problems can arise for the Desktop Management administrator, such as:
Network traffic: Many users or workstations can create heavy network traffic (especially across slower WAN links) to obtain their applications
To address the geographic issue of heavy network traffic, if you use only Desktop Management, you would need to do a lot of manual work. You would have to re-create and custom-configure the Application objects multiple times and copy their files to the various servers that would locally service their workstations.
Local application access: Users need local access to their applications no matter where they connect to their network
You must manually create duplicate Application objects and create a site list in each copy of the Application object.
For more information on site lists, see Setting Up Site Lists
in the Novell ZENworks 7 Desktop Management Administration Guide.
Server overload: A server loaded with various application files can be over-worked to service all of its workstations
If you use only Desktop Management, you can configure Load Balancing (sharing the distribution workload between servers) in an Application object to address a server overload condition by having multiple servers being able to perform the same service. However, you would need to do a lot of manual work to use this feature.
Server redundancy: If a server loaded with various application files goes down, its workstations cannot receive those applications
If you use only Desktop Management, you can configure Fault Tolerance (server redundancy) in an Application object to address the situation where a server goes down by having multiple backup servers listed in the Application object. However, you would need to do a lot of manual work to use this feature.
Server Management provides solutions to resolve these geographic and manual work issues. To see how, continue with Distributed Applications in Server Management.
Server Management provides a Desktop Application Distribution that allows you to minimize your network traffic, local application access, server bandwidth, and redundancy issues with less effort on your part.
For example:
Network traffic: Create a Desktop Application Distribution that contains your applications, then the Subscribers in each of your geographic areas create local copies of these applications. There, Novell Application Launcher can use these local applications to service the Subscriber server’s users and workstations.
Local application access: After creating and sending a Desktop Application Distribution, link up site lists so that users who travel between geographic locations can have local access to their applications.
For information on how Server Management sets up site lists, see Step 13.
Server overload: Through the Load Balancing feature, you can utilize multiple servers to service a large number of users or workstations via Novell Application Launcher. Simply use a common working context for each of the servers receiving the Desktop Application Distribution. Then, you have multiple servers available for load balancing.
IMPORTANT:Load balancing is concerned with access to the source paths on Subscriber servers, not with access to the distributed Application objects.
Server redundancy: Through the Fault Tolerance feature, you can have redundancy when servers go down by having other servers equally able to service your users and workstations via Novell Application Launcher. Simply use a common working context for each of the servers receiving the Desktop Application Distribution. Then, you have multiple servers available for fault tolerance.
IMPORTANT:Fault tolerance is concerned with access to the source paths on Subscriber servers, not with access to the distributed Application objects.
To do these things, you simply need to:
Create one Desktop Application Distribution for an application, or group of applications.
Send the Distribution to multiple servers.
Server Management automatically configures the application according to each server’s environment.
Manually assign the necessary users or workstations to the groups that are associated with the new Application objects.
Click one button to link up the site lists.
Each server then has:
Its own copy of an application’s files on its file system
Access to the Application object pointing to those files
The Application object is used to install the application on the workstations through Novell Application Launcher.
The Distribution process automatically does the multiple Application object creation, custom configuration, and file-copying work.
To further understand how Server Management can resolve these issues, continue with Section 6.1.2, Distributed Application Issues.
When sending a Desktop Application Distribution, some content in an Application object is kept, some is not kept, and some is modified. The following sections explain this:
When you create a Desktop Application Distribution, you select an application object to be distributed. In Server Management, this is known as the “golden” Application object. All of the Application objects that are created by the Distribution are referred to as the “distributed” Application objects.
As an administrator, you should keep track of which objects are golden Application objects for the Distributions, because Application objects themselves do not have any visual designation in ConsoleOne® to identify them as such.
Because normal Desktop Management activity associated with Application objects can cause the object’s internal revision number to change, unnecessary deltas of a Distribution could be triggered and sent. For example, a Distribution rebuild could be triggered by a simple change in a User Group object that is associated with an application contained within the Distribution, which information is not even transferred to the distributed applications. Therefore, your golden Applications should not be used by users or workstations.
We recommend that you keep your golden Application objects in a unique Novell eDirectory™ context and associate users and workstations to only the distributed Application objects. For more information, see Section 6.4, Rebuilding Desktop Application Distributions.
When a Distribution is rebuilt and resent, all distributed Application objects are synchronized with the golden Application object. In other words, if you make important changes in a distributed Application object, but not the golden Application object, then you rebuild and send the Distribution again, you could lose your changes, because the Distribution only uses the content in the golden Application object to update the distributed objects. Therefore, the golden Application objects are the only objects that you should modify when you want to re-send the Distribution.
However, you can make changes to distributed Application objects that will not be overwritten, if those changes are in the attributes that are not normally overwritten by a re-sent Distribution. This is explained in the next section.
Continue with Maintaining a Golden Application’s Attributes.
Server Management distributes most attributes that exist in a golden Application object, but not all of them. Therefore, various outcomes can occur for the attributes contained in distributed Application objects any time a Distribution is rebuilt.
The following sections provide information on when attributes are or are not distributed:
If they can be modified in ConsoleOne, all attributes not listed in the following three sections are distributed as they exist in the golden Application object. These attributes are read from the golden Application object when building the Distribution and are sent every time Server Management creates or updates the distributed Application object.
All attributes contained in a golden Application object, not just the updated attributes, are updated in the distributed Application objects when a Distribution is rebuilt, sent, and extracted. This means that all distributed Application objects are kept in sync with their golden applications, except as noted in the next three sections.
The attributes (listed by eDirectory attribute name in Table 6-1) are never read by the Distribution building process, and are not populated by Server Management in the distributed Application object:
Table 6-1 Location of Properties for Attributes Not Distributed
This list includes only those attributes that you can modify in ConsoleOne.
The attribute (listed by eDirectory attribute name in Table 6-2) is sent only once to provide an initial contact list:
Table 6-2 Location of Properties for Attributes Sent Only Once
|
Attribute Name |
Location in the Application Object’s Properties |
|---|---|
|
App:Contacts |
Identification tab > Contacts subtab. |
This attribute is not updated by any subsequent Distribution updates. This prevents changes to this attribute in the distributed Application object from being overwritten by an original or updated contacts list in the golden Application object.
This attribute can be modified in ConsoleOne.
The attributes (listed by eDirectory attribute name in Table 6-3) are read from the golden Application object when the Distribution is built, but are modified to fit the Application object’s new environment when the distributed Application object is created in the target server’s working context:
Table 6-3 Location of Properties for Attributes Modified
|
Attribute Name |
Location in the Application Object’s Properties |
|---|---|
|
ACL |
NDS Rights tab > Trustees of This Object subtab. |
|
App:Alt Back Link |
Fault Tolerance tab > Remote Alternate App subtab. |
|
App:Associations |
Associations tab. |
|
App:Back Link |
Run Options tab > Application Dependencies subtab > Show Chain button. |
|
App:Fault Tolerance |
Fault Tolerance tab > Fault Tolerance subtab. |
|
App:Load Balancing |
Fault Tolerance tab > Load Balancing subtab. |
|
App:Site List |
Distribution tab > Link Up Site List button (which only displays if the Server Management snap-ins are installed in ConsoleOne). For how and why to use this button, see Step 13. |
|
Application GUID |
Distribution Options tab > Options subtab > GUID field. |
|
creatorsName |
Listed on the Other tab (you must click Show Read Only to view). |
|
modifiersName |
Other tab (you must click Show Read Only to view). |
|
Object Class |
Listed on the Other tab. |
|
Revision |
Listed on the Other tab (you must click Show Read Only to view). |
|
Used By |
Listed on the Other tab (you must click Show Read Only to view). |
This list includes only those attributes that you can modify in ConsoleOne, and they are only displayed in an Application object when needed to define the application.
Continue with Maintaining Associations When Distributing Objects.
When configuring a Desktop Application Distribution, you can specify to maintain associations. This means that you want attribute associations set in the golden Application object to be maintained in the distributed Application object that is created by the Distribution.
The Desktop Application Distribution requires some manual processes, such as adding the applicable users or workstations to the distributed Application object, which is empty of this information in Desktop Application Distribution object. This is because users and workstations can be different for each server receiving a distributed application.
If you select the Maintain Associations option, then attribute associations are handled in the following way:
Maintained: User Group, Workstation Group, Organization, and Organizational Unit objects.
These are trusted groups and containers (within the source root container). They are maintained in the following manner:
Created new: Group and container objects, if they do not exist.
You need to manually populate them with the users and workstations who need the distributed applications.
Not overwritten: Group and container objects, if they already exist.
If group and container objects already exist and have been assigned to the distributed Application object, those settings are not overwritten, because they could already be populated with the users and workstations that need to use the distributed applications. If you want to add other users or workstations to existing groups or containers, you must add them manually.
Not created: User and Workstation objects.
You can add the applicable users and workstations to the distributed Application objects after the Distribution has been extracted.
The Maintain Associations option is required when you distribute chained application information and folders. This is explained under Chained Applications in Distributions.
Continue with Maintaining Application File Rights.
File rights that you set in a golden Application object are not passed to the distributed Application objects, because file locations vary from server to server and cannot be anticipated.
The Desktop Application Distribution requires some manual processes, such as adding additional rights for file access. These processes are in addition to the minimums set by ZENworks when creating a distributed Application object. (The minimum rights might be enough for most applications.)
Review the following sections to understand how file rights are handled in Desktop Application Distributions:
File rights that are explicitly assigned in the Application object using the Rights to Files and Folders tab are not transferred, but are reset to the minimum necessary (Read and File Scan) for users to use the distributed applications. They are set when the distributed Application object is both created and then associated to a container or group.
File rights assigned in the Common > File Rights tab in the Application object are also not distributed.
You can later grant additional rights on these tabs in the distributed Application object and ZENworks does not remove or replace them.
If a user or workstation is a member of a group that is distributed in the Desktop Application Distribution, then individual file rights for the user or workstation do not need to be set. The user or workstation obtains its rights to the application by virtue of its membership in the group.
If a chained application is used, all applications in the chain that require rights to a directory must be associated to a user or workstation group or a container in the golden Application’s tree structure, because individual user or workstation objects’ rights are not maintained in distributed Application objects.
To provide the Read and Write access rights to the files belonging to the chained application, in the Rights to Files and Folders tab in the User or Workstation Group object, assign the file rights.
Server Management does not set individual rights on files for NetWare-only trustees are set on the directories that contain the files, and rights are always Read and File Scan. Therefore, on NetWare servers you should grant users Read rights to the directory where the application’s files are distributed. For example, if you have the files copied to the \apps directory, users would need Read rights to the \apps directory in order to use the application whose files were copied there.
Server Management also does not set file rights in Windows. Therefore, you should set up individual shares for users to have access to the application’s distributed files.
Continue with Subscriber Working Context Conflicts.
Whether your Subscribers all use the same working context or a unique working context depends on your application distribution design needs. You might have all of the Subscribers who receive a Desktop Application Distribution use the same working context if you want load balancing or fault tolerance to be used. For more information, see Section 6.1.1, The Purpose of Desktop Application Distributions.
Where there are multiple Subscribers using the same working context, an eDirectory collision is possible. In other words, multiple Subscribers cannot extract their copies of the same Desktop Application Distribution at the same time to the same working context in the tree.
For example, if two Subscribers extract an application at the same moment and create an Application object in two different eDirectory replicas, this causes a problem in eDirectory synchronization. When eDirectory finds the two different objects, but with the same name and the same timestamp in the two different replicas, eDirectory resolves this by renaming one of the objects by appending a number to the collision object’s name (for details, see TID 10062001 in the Novell Support Knowledgebase).
If you use the same working context for a group of Subscribers, then you must make sure that each Subscriber’s Extract schedule fires at a different time, allowing enough time between these schedules for extraction to be completed by a Subscriber before the next Subscriber begins extracting.
If you have each Subscriber use a unique working context, all Subscribers can then extract their copies of the same Desktop Application Distribution at the same time, and no eDirectory collisions occur.
If a Distribution is set to extract immediately, the same scenario can exist.
Continue with Maintaining Source Paths.
Many applications require supporting files, and the paths to those source files must be established in the Application objects in Desktop Management. This is known as the “source path.”
This section applies to Desktop Application Distributions containing Application objects that use source paths. For applications that require only an executable file (such as notepad.exe), source paths are not required in their Application objects.
Review the following sections to understand how source paths are used in Desktop Application Distributions:
To show what happens with the attribute between the golden and distributed Application objects during the Desktop Application Distribution process, Table 6-4 lists where you can find and configure source paths in ConsoleOne, their purposes, how these locations are populated, and their distribution status.
Table 6-4 Source Path Usage Information
1 A “macro” in Desktop Management has the same functionality as a “variable” in Server Management.
The SOURCE_PATH macro defines the source path in an Application object to where its application’s files reside on the Distributor server’s file system. This is where the Distributor accesses the application files for building the Desktop Application Distribution.
The SOURCE_PATH macro’s value is used to create the location on the Subscriber server’s file system where those application files are to be placed by the Subscriber when it creates the distributed Application object.
The information in the value of the SOURCE_PATH macro includes:
Server identification (the Distributor server) in either the server name, IP address, or full DNS name
Volume or drive on the Distributor server
User-defined path information (if provided in the wizard)
Application path information (selected in the wizard)
Some examples:
server1.novell.com\sys\apps\acrobat
server1.novell.com\n\apps\acrobat
This is resolved to a valid UNC path, such as:
\\server1\sys\apps\acrobat
If you include a macro (or variable) within the value of the SOURCE_PATH macro, Server Management does not resolve that embedded information. Server Management only resolves the SOURCE_PATH macro’s value to a valid UNC path.
Mapped drive letters can also be used if a global policy variable is defined.
Tiered Electronic Distribution searches variables to find a match with the golden Application object’s source path. For example, if the source path in the golden Application object is n:\apps\acrobat, the following order is searched to find a match:
n:\ N:\ n: N: n N
However, if the golden Application object’s source path is N:\apps\acrobat, the following order is searched to find a match:
N:\ n:\ N: n: N n
The .mst files can be entered (on the MSI > Transforms tab) without specifying the file’s full path, because Server Management uses the source path defined for the Application object to find these files when building the Desktop Application Distribution. However, this is only true when the .mst files are in the same directory as the MSI file.
Historically, mapped drives have been embedded into an Application object as a means of launching that application from a mapped drive on the desktop. Server Management uses variables to distribute applications that use drive mappings.
Because volume names and mapped drives for the Distributor and all of the Subscribers receiving the Distribution can be different, variables allow you to identify these locations with a value that is interpreted by the Distributor and each Subscriber.
You can define variables globally and individually:
Globally using the Tiered Electronic Distribution policy
Variables defined in the Tiered Electronic Distribution policy (Service Location Package) are available to all Subscriber objects associated with the policy, such as associating the policy package to the parent containers of the Subscriber objects. For the policy to be in effect for each Subscriber, make sure on the Variables property page that the Include Policy check box is selected.
The policy package must also be associated with the parent container of the Distributor object. The variable definition in the policy ensures that the Distributor knows where to gather the application files from.
If both the Distributor and Subscribers use the same variable value, then only one Tiered Electronic Distribution policy is needed, and you can associate its Service Location Package to the parent containers of both the Distributor and the Subscribers.
For example, the mapped drive source path for a golden Application object is n:\applications\acrobat and you want n: to represent the sys:\public directory on the Distributor server. To create the variable, in the Tiered Electronic Distribution policy select the Variables tab, then enter the n: for the variable and sys:\public for its value. Then, the Distributor can find the \applications\acrobat directory on its sys: volume when it needs to build the Distribution.
For more information on this policy, see Tiered Electronic Distribution.
Individually in each target Subscriber’s properties
You can define a variable for any Subscriber object. This definition overrides the same variable if it is defined in a Tiered Electronic Distribution policy that the Subscriber is associated with.
This is useful for when the Subscriber server’s volume name or mapped drive is different than the Distributor server’s (so they can’t use the same Tiered Electronic Distribution policy), or you have a variety in volume names or mapped drives among the Subscribers receiving the Distribution.
For information on how to define variables on Subscribers, see Section 9.3, Defining a Variable.
If a golden Application object uses mapped drives, enable the Keep the Same Source Paths for the Replicated Objects option when running the Desktop Application Distribution Wizard. Enabling this option causes the Distribution to retain golden application source paths for when a mapped drive designation must be used by the application that is distributed. The value of the mapped drive determines where the application files are copied.
If the golden application source paths are mapped drives, but you want the distributed applications to use a UNC path according to the extraction directory, then you do not need to select this option, but you must define the Tiered Electronic Distribution policy in the Service Location Package with variables defined for the mapped drives. This package must be associated to the Distributor with the variable defined in order for the Distribution build to work. It should also be associated with containers for the Subscriber objects, or any container above them, if they have the same drive mappings.
Key points about this option:
If a golden Application object’s Package Source List box contains a mapped drive, you must enable the Keep the Same Source Paths for the Replicated Objects option. The mapped drive letter is treated like a variable that needs to be resolved on both the Distributor and Subscriber to complete the valid UNC path.
If a golden Application object’s Package Source List box contains a drive mapping that is local to a server other than the Distributor server, no application files can be gathered or distributed, because all files to be included in the Distribution must be contained on the Distributor server’s file system.
Enabling this option affects all Application objects in the Distribution, including chained applications. Therefore, all mapped drive properties for each of the Application objects included in the Distribution are distributed to keep their golden application source paths, and each application and chained application must have mapped drives for the source path.
If you select this option, only the Application object’s Default Directory Path is used, because the Application Destination Directory Path field in the next wizard page is disabled. Therefore, you cannot change the path.
When you select this option, or if you leave it unselected, that choice becomes the permanent use of this option for the Distribution. This is done to prevent problems that can occur from alternating between using and not using an Application object’s mapped drives.
For chained applications, source paths are treated the same for all chained applications as they are for the first application that the others are chained to.
Dependencies and requirements can be confusing with regard to the distribution of attributes:
Dependency: An application dependency, such as a chained application, is updated in a distributed Application object when the Distribution is rebuilt, sent, and extracted.
To view application dependencies: in the properties of an Application object, click Run Options > Application Dependencies.
System requirement: A system requirement, such as an operating system for the application to run on, is updated in a distributed Application object when the Distribution is rebuilt, sent, and extracted.
To view system requirements: in the properties of an Application object, click Availability > Distribution Rules.
One exception is that an application requirement is not updated in a distributed Application object when the Distribution is rebuilt, sent, and extracted. Instead, we recommend using application dependencies.
If multiple applications contain the same chained application, the application’s files are only contained once in the Distribution. This reduces the Distribution’s file size.
For example, if you distribute several icons (each its own Application object) that each require an office software suite, that suite software is only included once in the Distribution.
If your Desktop Application Distribution has chained applications, you must enable the Maintain Associations option when configuring the Distribution.
Chained applications in Distributions are only available in ZENworks for Desktops 4.x and later.
For more information on understanding and setting up chained applications, see Advanced Distribution: Configuring Application Dependencies and Chains
in the Novell ZENworks 7 Desktop Management Administration Guide.
If extended characters (such as ê, ë, ì, or í) exist in the path to the .fil files for an AOT Application object, you must define a code page variable for both the Distributor and its Subscribers.
The code page variable is necessary for the Distributor so that it can gather the applications files from its file system when it builds the Distribution, and it is necessary for the Subscribers so that they can successfully copy the application files from the Distribution to their file systems. In other words, the code pages used by the Distributor and Subscribers must contain the extended characters used in the paths contained in the Distribution.
To create the code page variable:
Determine the code page used by ConsoleOne for the international characters to be used in the Distribution.
The code page must come from the workstation used to create the golden Application objects that have extended characters in the paths to their AOT files.
You can use the encoding.cmd utility included in the \codepageutility directory on the ZENworks 7 with Support Pack 1 Companion 2 CD to determine the necessary code page. Instructions on how to use this utility are contained in the readme.doc file included in the \codepageutility directory.
In ConsoleOne, create a Service Location Package and access its properties.
Click the policy to enable it, then click .
Add the following variable in the policy: CODE_PAGE.
Enter the desired code page as the variable’s value.
For example, Cp1252.
Code page values are case sensitive.
Click to save the policy.
Associate the policy package to the container of the Distributor object.
To provide Subscribers access to the code page, do one of the following:
Associate the policy package to the container of the Subscriber objects receiving the Distribution.
This causes the variable to be available for use by the Subscribers, providing access to the code page.
Define the same code page variable (as in Step 4 and Step 5) in each Subscriber object’s properties.
This provides Subscribers access to the code page.
Rebuild the Distribution, if it has already been created.
You can send Desktop Application Distributions to other trees. However, ZENworks 7 Distributions cannot be sent to ZENworks for Servers 3.0.2 Subscribers because of new schema extensions for ZENworks 7 and later.
ZENworks 7 Server Management does not use a Site Distribution object. Previous versions of ZENworks might have used Site Distribution objects with this Distribution type.