Executive Summary—Migrating a Notification Server to a New Domain

This document provides a basic outline of the steps necessary for Altiris customers to migrate Notification Servers from an existing domain to a new domain.

• The notification server NS1 in Mydomain.com would be migrated to MyNewDomain.com. The resulting new server name becomes NS1.MyNewDomain.com.

This document is not intended to be a step-by-step procedure, but provides a suggested list of items to be considered, events that can be expected to occur prior to and during this type of procedure, areas to be aware of, and an outline of suggested procedure. Adaptation is required to individual environments.

Assumptions and Expectations

To perform this migration, it is necessary to make some assumptions and have a few expectations for things to be ready, prior to the migration. The primary areas of concern are:

• Client Communication: Communication to the correct NS through the duration of this process is critical. How can this be assured?
• Package Delivery: How is the consistent, reliable delivery of packages to be maintained during this process?
• NS to NS Communication: How will Inventory Forwarding and other items function during the migration?
• SQL Server: Is the SQL Server on the NS, or off computer?

With those things in mind, the following should be able to be safely assumed and expected:

1. A domain migration of more than 5000 computers will not be able to be completed in a single day. The timing and process must accommodate management of the computers that will be in a different domain (the Notification Server (NS) domain), as this activity could last between a day and several weeks. Therefore, the following must still be functional:
   • NS in old domain, all managed computers in old domain (starting point)
   • NS in old domain, some computers in old domain, some computers in new domain
   • NS in new domain, some computers in old domain, some computers in new domain
   • NS in new domain, all managed computers in new domain (ending point)
2. DNS will be setup to resolve for both the old domain and the new domain.

A trust relationship between the old and new domain will make package service disruptions far less likely to occur. This is strongly recommended. If the old domain and new domain are not in a trust relationship, then the recommended procedure would be to remove all old domain groups and accounts out of the roles prior to starting the process. This will avoid potential UI issues with deleting role members that can't be resolved from their SIDs.

Other Items to be Aware Of

1. User and group accounts: How are they being moved? If they are being moved, what is the procedure to verify what they were before the move, and what they look like as a result of the move? This information will be valuable and will be important in re-creating the security inside the NS.
2. DNS will be set up to resolve for both the old domain and the new domain.
3. If SQL is installed on the Notification Server, are the access credentials a domain account, or a SQL account? If using a domain account, temporary plans should be to set up a local SQL account for the NS to use during the migration, especially if existing domain accounts are not part of the overall domain migration plan.

Suggested Migration Process

Prerequisites:

1. Disable the rules that would normally run in step 6 of Procedure, below, and ensure that they are not going to run during migration. This will allow the migration of all of the Notification Servers in any order.
2. Make sure that Duplicate Diagnostics are disabled as well.
3. To accommodate package downloads, it's important to consider that some package download requests will be coming from a domain that differs from the one registered on the agent's workstation. It will be critical to set up Agent Connectivity Credentials with a local (non-domain) account on all Package Servers or an account that is trusted by both domains, or install IIS on the Package Servers. Alternately, settings can be changed to download all packages from the NS, but make sure that the additional CPU load and network traffic that this configuration can create are appropriately considered.
4. Establish a trust relationship between the old and new domain. This will allow services to continue and specifically reduce the potential for package service disruption.
5. If SQL is on the same computer as the NS, make sure the access accounts to SQL are accounts that are in both domains, or use a SQL account, such as SA. If SQL is remote, make sure that a domain account is not used to access SQL. Temporarily convert to mixed authentication mode and configure the NS to use a native SQL login before starting the process.
6. If the old domain and new domain are not in a trust relationship, then it will be important to remove all old domain groups and accounts from their respective NS security roles prior to migration.

Procedure:

1. Move the Notification Server from old domain (MyDomain.com) to new domain (MyNewDomain.com)
2. Create the APP ID account and ensure that the account used is a local admin account of the NS. It can be a new domain account (Administrator.MyNewDomain.com), but this account must have local administrative rights on the NS.
3. Run AEXConfig /APPID to reset Notification Server to use the new application Identity.
4. Create a DNS alias (old server DNS name) for the clients to point to the NS's current IP address.
5. Create DNS alias for ACNS devices.
6. The new agents will have to be given instructions to begin communication with the new server. This can be accomplished in one of two ways:
   • Setup a new Software Delivery task, which runs AEXAGENTUTIL.exe /Server:servername.dom1.com for all of the clients or,
   • On the Advanced Settings tab of the Altiris Agent Configuration page, you can configure the Agent to communicate with a new server, using the Alternate URL for Accessing NS option. Simply check the box, enter the new name of the server, and click OK.
   

   Click to view.
7. With the trust relationship established, all membership to NS security roles will need to be verified and re-defined as the user accounts migrate over. Essentially, role members will have to be re-added to the correct groups. If the old domain and new domain are not in a trust relationship, then it will be very important to remove all old domain groups and accounts from their respective NS security roles prior to starting the process. This will occur near step 5 of Prerequisites. Taking this step will avoid many potential user interface issues associated with deleting role members that can't be resolved from their respective SIDs.
8. All existing policies will need to be reviewed for domain changes that can affect:
   1. Active Directory Import
   2. Network Discovery
   3. Proxy Configuration
   4. Inventory. Forwarding
   5. Connector for Microsoft SMS
   6. Connector Solution connections
9. If using user accounts are not on the local system, the following areas should be reviewed for any changes necessary:
   1. Package Delivery
   2. Distribution point Credential
   3. Agent Connectivity Credential (ACC)
   4. Proxy Authentication accounts
   5. Active Directory Import
   6. Network Discovery
   7. Proxy Configuration
   8. Inventory Forwarding
   9. Connector for Microsoft SMS
   10. Connector Solution connections

Diagram of Suggested Migration Flow

Click to view.

Other Considerations

This process has potential to cause some very serious problems in your client management environment. Domain name changes can affect duplicate diagnostics; some machines may not check back in, user accounts may not be recognized correctly, etc. This document cannot address all possible issues that might arise, and care should be taken in the planning, and implementation of a domain change of this nature.

This document is designed to provide a basic overview and provide concepts to consider and an outline of the procedure to accomplish this in each individual environment. Please make sure that individual environmental processes and procedures are considered and included as appropriate.