Purpose of this document is to use Hierarchy and Replication in Deployment Solution effectively.
1. Introduction
Hierarchy reduces the TCO by supplementing the Notification Server system with centralized management capabilities. Hierarchy defines the information flows across multiple Notification Servers in an enterprise. If you have multiple Notification Servers, you can use Hierarchy to define collections of Notification Servers that share common configuration settings and data. Hierarchy can distribute and synchronize any changes that are made to the shared configuration settings and data. This lets you manage your Altiris solutions across multiple Notification Servers from a central location.
Hierarchy uses replication to copy and synchronize shared objects and data between Notification Servers within the same hierarchical structure. At scheduled intervals, each server within a hierarchy synchronizes objects and data with its immediate parent and immediate children.
A Hierarchy topology defines the relationships between Notification Servers, which in turn controls how synchronization occurs between adjacent nodes.
A Hierarchy topology is governed by the following rules:
- Each Notification Server can have zero or one parent.
- Each Notification Server can have zero or more children.
In Hierarchy, objects and data are constrained to replicate in known directions, so synchronization is both predictable and scalable.
As Hierarchy only replicates each object or piece of data in one direction, conflict management is trivial and the source is always given priority.
Following objects that can be synchronized between Notification Servers in Hierarchy.
- Policies, filters, and reports are replicated as read-only items down a hierarchy.
- Configuration and Management Items.
- Security roles, privileges, and permissions are replicated down a hierarchy.
- Security Settings.
- Resource information, such as computers, users, sites, and their associated data classes are replicated up or down a hierarchy.
- Resources Packages that are associated with software resources and the data classes that are associated with the packages are replicated down a hierarchy.
- Packages Event classes, such as software delivery execution, are replicated up or down a hierarchy.
- Events.
2. Hierarchy Requirements
To share or receive common configuration settings and data with multiple Notification Servers, you must first add the Notification Server to a hierarchy. Because Notification Servers can be managed locally, each Notification Server must be added or removed from a hierarchy individually with the appropriate access credentials. Typically, the Altiris Administrator managing the topology design will remotely access Notification Servers in other sites to add them to a hierarchy.
The requirements for configuring hierarchy are as follows:
- Network traffic must be routable between adjoining Notification Servers within the hierarchy.
- HTTP/HTTPS traffic must be permitted between adjoining Notification Servers within the hierarchy.
- Trust relationships must exist between adjoining Notification Servers within the hierarchy, or credentials for privileged accounts that facilitate trust must be known.
- Each Notification Server must be able to resolve the name and network address of any adjoining Notification Servers within the hierarchy.
- There must be sufficient bandwidth between Notification Server sites to support package and data replication. Bandwidth and hardware required is determined by the size of your Hierarchy topology and the data replicated.
Each Notification Server must have a site server that is running the package service available. The package service must be serving the Notification Server.
3. Test Configuration for Hierarchy
4. How to Configure Hierarchy
To set up a hierarchical relationship between two Notification Servers
- In the Symantec Management Console menu, click Settings > Notification Server Management > Hierarchy.
- On the Hierarchy Management page, on the Topology tab, right-click your Notification Server, and then click the appropriate option:
■ Add > Parent
■ Add > Child
- In the Add Hierarchy Node Wizard, on the first page, enter the name and URL of the remote Notification Server, and supply the appropriate access credentials.
- Click Advanced.
- In the Advanced dialog, specify the account that the remote Notification Server will use to communicate with the local Notification Server.
- Click OK to close the Advanced dialog.
- Click Next.
- On the Replication Schedules page, set up the differential and complete replication schedules, and enable those that you want to use on the Notification Server.
- By default only the differential replication schedule is enabled. Complete replication is rarely used because it puts a heavy load on the Notification Server, but you can enable it when necessary.
- Click Next.
- On the Confirm Settings page, verify that the settings are correct, and then click Finish.
The local Notification Server uses the specified information to locate and verify the remote Notification Server and set up the appropriate hierarchical relationship with it.
If the remote Notification Server does not have a package server available within its site, the verification fails and the hierarchical relationship cannot be established.
5. Configuring Replication
When you add a Notification Server to a hierarchy you can specify what to replicate to the parent Notification Server and to any child Notification Servers. By default, everything is replicated.
Hierarchy replication synchronizes all data items by their GUIDs, so anything that was published on a child Notification Server cannot be overwritten by data replicated down from its parent.
Hierarchy replication of resources and events is configured using replication rules. These rules define the data that you want to replicate to other Notification Servers. You need to create all the rules that you require, and then enable those that you want to use. You can disable a replication rule at any time—it is not deleted—and you can enable it again later. You can also manually replicate selected data directly from a Notification Server to its parent and child Notification Servers without including it in a replication rule. Manual replication is a once-off replication that takes place immediately.
To configure hierarchy replication
- In the Symantec Management Console menu, click Settings > Notification Server Management > Hierarchy.
- On the Hierarchy Management page, select the Replication tab.
- Configure hierarchy replication by selecting the appropriate options, and setting up and enabling the appropriate rules.
- To save the configuration settings, click Apply.
If you want to set up custom hierarchy replication for configuration and managements items, make the appropriate settings. Click Apply to confirm the custom hierarchy replication settings.
6. Manually Replicating Selected Data
You can override the replication rules for your Notification Server by performing a manual hierarchy replication of a particular folder or item. This replicates the selected data to the parent and child Notification Servers immediately, regardless of the replication schedules or whether the data is included in the replication rules.
To manually replicate selected data from your Notification Server
- In the Symantec Management Console, in the left pane, right-click the folder or item that you want to replicate. If you select a folder, the replication includes all levels of subfolders and items that it contains. Any parent folders (but not their contents) are also replicated to preserve the folder paths within the structure.
- Click Hierarchy > Replicate Now.
- In the confirmation dialog box, click OK.
7. Replication of DS Data
Following DS items replicate by default when all hierarchy replication options are enabled.
- All plug-in policies, TS handler policies, Automation folder policies, PXE Configuration policy and Pre-boot configuration policy
- All DS tasks
- All DS settings like Initial Deployment, License keys, System Configuration, Predefine Computers.
- DS resources, packages: Image, OS, Copy file
- Bootwiz and DriverDB database
- Deploy.cab packages
- Data Classes: Image Resource Component, OS File Resource Component, Initial Deployment, PXE Image Status, PXE Image List, Agent Plug-in Inventory.
Only below component do not replicate:
- Personality Resource Component.
- Back-up Image resource.
- HTTP Images resource.
8. DS Use Cases f or Testing Hierarchy and Replication
8.1 Create Image on Parent NS and Deploy Image on Child NS
- Run the prepare for image capture task on any client connected Parent NS / Parent RSS.
- Create Ghost or Rdeploy Disk Image of any client connected to Parent NS / Parent RSS once the Image is created make sure the image is replicated to RSS.
- On Parent NS From Settings ->All Settings -> Deployment and Migration select Disk Images Right click on it and select hierarchy -> Replicate Now.
- On Child NS verify that Disk Image captured is replicated to Child NS and child RSS. Verify that disk image is replicated down on Child NS and RSS
- Boot Unknown client on child NS or Child RSS in PXE Image which is replicated from Parent NS
- Run the Differential Replication from Child to Parent NS so that Parent NS knows the newly created clients of child NS
- Verify on Parent NS -> Manage computers shows the entry of newly created unknown client.
- Go to Manage Jobs and tasks of Parent NS and create the deploy image select the same image created on client of parent NS.
- Run the Deploy image task on Unknown client of Child NS. Verify on parent NS that task shows status as “Pass”. On parent the task status show pass immediately as it just replicates the task on child NS. The actual execution status is displayed on child NS
- Verify on Child NS the “Deploy Image” task is created and started on unknown Client.
- Once the deploy image task is successful then run the “Reboot to Product” task from parent to child unknown client.
8.2 Scripted OS Install on Unknown /Predefined Child Client
- Add the Os files (sources for windows vista onwards and 1386 and AMD64 for XP and win2k3) on Parent NS for any OS which you want to install on child Client.
- Add the License for corresponding OS for which you added the files.
- Create the task Install windows OS.
- Create the task for partition disk.
- Run the differential / Manual replication for OS files .Os Licenses and tasks. Verify on child NS that OS files have been replicated and added to \deployment \Task Handler\SOI folders.
- In the child environment create unknown client or predefined client and run the replication from child NS to Parent NS.
- Execute the Partition disk task on child unknown /Predefined Client. Execute the SOI task on child unknown /Predefined Client.
- Verify that Scripted OS install task on child client is executed and completed successfully.
8.3 Apply System Configuration.
- Create the new system configuration from Settings -> All settings.
- Create a new task of apply system configuration using the newly created system configuration.
- Replicate the System configuration and task of “Apply system configuration”.
- Once the replication is successful verify in child NS that system configuration is displayed under settings-> all settings and Task also shows the same values as it is displayed in Parent NS.
- Execute the task either from parent Ns or from child Ns on client connected to Child NS or Child RSS.
- Verify that system configurations are properly applied to client.
8.4 Copy File
- Create a task for copy file , select the appropriate file / folder you wish to copy on the client of child NS or Child RSS save the task.
- Verify on Settings –All Settings -> Deployment and Migration -> Copy file contents the newly added contents are displayed properly.
- Replicate the copy file contents and copy file task to child NS.
- Verify that copy file contents and task are replicated successfully Execute the task on client connected to child NS or Child RSS.
8.5 Initial Deployment
- Create a job containing sequential tasks such as :
Deploy Sysprep ghost Disk Image
Reboot To Production
Apply System Configuration
- Configure the Initial Deployment Settings from settings -> All settings -> Deployment and Migration, Add the above created job and save changes.
- Replicate the Job and Initial Deployment Settings to child NS.
- Boot any unknown client in Child NS or Child NS -> RSS environment.
- Verify that Initial Deployment menu is displayed and job defined in initial deployment is executed successfully.
8.6 Driver Database
- Go to Settings- All Settings -> Deployment and Migration –Driver database Management
- Add the required new drivers either to deploy anywhere /Preboot database.
- Replicate the drivers settings and driver database to child NS.
- Verify that newly added drivers are replicated to child NS and Child RSS.
8.7 Symantec Boot Services (Preboot Configuration and PXE Configuration)
- Go to Settings- All Settings -> Deployment and Migration -> Symantec Boot Services.
- Create Preboot policy for PXE and save the changes. (make sure Symantec boot services are started in services).
- Verify that preboot image has been created under deployment share \\NSParent\Deployment\Task handler\SBS\Images.
- Configure the settings in PXE server configuration for Respond to Predefined Computers and unknown computers.
- Go to Child NS and start the Symantec boot services and click on update of Symantec agent.
- Replicate the Symantec boot Services to child NS.
- Verify on child NS that Bootwiz,exe is started under the task manager and new preboot image with same name as in parent is created under \\childNS\deployment\Task handler\SBS\Images.
- Verify that PXE server configuration settings are also replicated with proper values.
- In Child NS environment try create unknown client and verify that it boots into pxe image which is replicated from Parent NS.
8.8 Sysprep Imaging Configuration
- Go to Settings- All Settings -> Deployment and Migration -> Sysprep Imaging configuration.
- Upload the deply.cab file for Windows XP and windows 2003.
- Replicate the Sysprep Imaging configuration to child NS.
- Verify on child NS that deploy.cab is successfully replicated and is displayed under \\childNS\deployment\Task handler\Sysprep\Deploy_cab.
8.9 Replication from Child NS to Parent NS
You can run the replication from child Ns to Parent NS the Item which gets replicated from child NS are limited to Inventory (computer resources). The focus of Hierarchy is on global Administration that is from Parent to child.
9. References
The information in this document is consolidated by referring various documents such as SMP platform user guide, Test cases, etc.