How to publish an alternate server name for an Internet Site Server
Article ID: 191688
Updated On:
Products
Issue/Introduction
1. The customer has a strict requirement of not using its actual Internet site server name (altss02.internaldomain.org) by his CEM computers.
7. Also, they get "Package Server is configured to publish HTTP (s) codebases, but could not access its own website" because the certificate in use in IIS only refers to the external name and not its internal one.
Environment
ITMS 8.1 and later
Note: This suggestion should no longer be needed when Agent and Site Server Communication Profiles are used. With ITMS 8.5 release and later, Site Servers have their own Communication Profile where we can specify what alternate host names we want to use. See under SMP Console>Settings>Agents/Plug-ins>Symantec Management Agent>Symantec Management Agent Communication profiles>Site Server Communication profiles.
Those two keys mentioned below were created in order for a Package Server to publish the codebases to the SMP with alternate FQDN and they still work for this release.
Cause
Since Site Server Communication Profiles affect only clients (they tell a client how to connect to a server, they do not tell server what port or certificate or alternative name to use), it was suggested to use on the site server the "FQDN Replacement", "FQDN Alternate" and "FQDN Keep System" regkeys.
Resolution
Two new registry keys have been added (since 7.5 and still valid in 8.5 and 8.6) which will allow administrators to specify custom FQDN strings which will be used as alternative host-names when generating HTTP & HTTPS codebases on the Package Server (UNC not affected by this change) portion of the Site Server.
The keys should be created manually under the registry hive:
HKLM\Software\Altiris\Altiris Agent\Package Server
- The key "FQDN Alternate" (REG_MULTI_SZ) should contain alternate FQDN strings. Example: servername.corpname.com
- The key "FQDN Keep System" (RED_DWORD) should contain a value in order for the Package Server to keep providing original system based hostname, or 0 (zero) - not to provide codebases with system hostname.
- If no alternate FQDN strings are specified, the Package Server will still provide the original, system based, hostname.
Example:
Note:
The "FQDN Keep System" is a numeric field, so only numbers could be used for that.
If you specify the "FQDN Alternate" and the "FQDN Keep System" is not added or added with zero (0) value, then the codebase with the original system based hostname will not be generated. If you provide both keys and the "FQDN Keep System" has a value of any number greater than "0", then alongside with alternate hostnames, the system one will be generated.
When "FQDN Alternate" has a value and "FQDN Keep System" is zero - only the alternate hostnames from "FQDN Alternate" will be used in codebases.
If we speak about PS self-tests, then if "FQDN Alternate" is specified and "FQDN Keep System" is zero, then the first alternate name is used for self-tests.
Package Server (PS) does not generate codebases based on a site server communication/connection profile.
The SMP server does not generate codebases for PS, it is the PS responsibility to create and send codebases back to SMP when the package is ready.
The PS generates codebases based on own knowledge of the system host name. It is retrieved from Windows sockets with the "gethostbyname" API. So if they want this PS to have only those "sscem.externaldomain.org" codebases in this example, they could change system settings in order WinSock to reflect that.
Also the PS has the functionality of providing "alternate" codebases, which are not reflected anyhow in the system. PS has two registry keys: "FQDN Alternate" and "FQDN Keep System" which are used while codebases generation. Also there is a possibility for this machine to replace its own FQDN in basic inventory. "FQDN Alternate" and "FQDN Keep System" - those override FQDN for hosts when "codebases" are composed for the package.
Task Server
Now, in regards to the Task Server portion in the Site Server, the Task Server (TS) publishes its URL to the Symantec Management Platform (SMP) using the internal Fully Qualified Domain Name (FQDN).
There is no specific code in the TS to send/receive Task Server FQDN. When we create a list of available Task Servers, we get FQDN names for TS's from Inv_AeX_AC_TCPIP database table using the fnTM_GetComputerResourceFQDN function.
To address that (only if the alternate name is just a change between the internal and external domain reference), create a new registry key, which will allow an alternate domain name used in the FQDN strings which will be used in the generation of HTTP & HTTPS codebases by Task Server when Basic Inventory is sent.
The key should be created manually under registry hive:
HKLM\SOFTWARE\Altiris\AltirisAgent\Inventory
- Key name: "FQDN Replacement"
- Key type: REG_MULTI_SZ
- Key format: <system DomainName to replace>:<new DomainName>
- example: "MyDomain.local:MyDomain.com"
Example:
For:
"FQDN Replacement"
Value: internaldomain.org:externaldomain.org
-OR-
Value:
internaldomain.org:externaldomain.org
internaldomain:externaldomain
Multiple lines are supported. The first found match will be used for replacement of Domain name in "AeX AC TCPIP", "AeX AC TCPIPv6" and "AeX AC Identification" dataclasses.
FQDN names for TS servers are taken from Inv_AeX_AC_TCPIP.
The "FQDN Replacement" is replacing only the Domain fields (see list below).
The current logic replaces next fields in the Basic Inventory:
For "AeX AC Identification" it replaces 'c2' field
For "AeX AC TCPIPv6" it replaces 'c8' field
For "AeX AC TCPIPv6" it replaces 'c4' field
Feedback
