Fantastic reference for the DS faithful. Includes port and protocol informaton about everything from routers and switches to PXE and multicast settings.
Prepared By: Development/Sustained Engineering
Contents
Overview
The primary purpose of this document is to provide consolidated information regarding the ports and protocols used by Altiris Deployment Solution version 6.5.
Altiris Deployment Server 6.5 (build 233)
Routers and Switches
Routers should be enabled for multicast for these IP ranges:
- Deployment Agent for Windows (AClient) uses 225.1.2.3.
- RapiDeploy (the disk imaging engine) uses 224.2.0.2 to 224.2.0.20 by default, but this is configurable.
After communications have been established, the server and the clients use a dynamic port to do the file transfers (similar to FTP). Routers will need to be configured much like they would for FTP -- you allow TCP connections as the primary port number 402 and then allow secondary connections on all other dynamic ports (above 1024). Sometimes, you will need to enable both 401 AND 402 bi-directional.
The Altiris Server Service (axengine.exe) uses directed broadcasts. Routers need to allow directed broadcasts through, not general (255.255.255.255) broadcasts.
Ports 1 - 1024 are statically assigned ports for known protocols. We use 401 and 402 for no other reason than they are unassigned. Ports above 1024 are assigned dynamically and the TCP/IP stack will choose any available port.
Client Communication
Deployment Agent for Windows (aclient/Aclntusr.exe)
Deployment Agent for Windows uses a static port (402) to locate the server.
Deployment Agent for Windows is capable of either using multicast or a direct IP connection to find the Altiris Server Service (axengine.exe).
Port 401 is used to wake up the AClient.
Deployment Agent for Dos (bootwork.exe)
Deployment Agent for DOS uses a static port (402) to locate the server.
Deployment Agent for DOS is capable of either using multicast or a direct IP connection to find the Altiris Server Service (axengine.exe).
Deployment Agent for Linux (adlagent)
Deployment Agent for Linux uses a static port (402) to locate the server.
Deployment Agent for Linux is capable of either using multicast or a direct IP connection to find the Altiris Server Service (axengine.exe).
There is no ability currently to push the adlagent to a remote computer.
There is an application (Adlremotetrace.exe) found in the 'express/techsup/windows' directory on the Deployment Server. If this application is running (on the DS) prior to adlagent starting, adlagent will send all debug and IP logs to this application via TCP Port 415. This allows real-time debug/trace of an adlagent pre-boot.
Deployment Agent for Windows Automation (WINPE-aclient.exe)
The Automation (WinPE) Aclient connects to the server in the same way as the Production Aclient. The Port and IP address settings are set in the Aclient.inp file when setting up the Automation environment, but they will need to be the same as in the production environment. During an imaging job, the Aclient severs its connection with the server. The RapidDeploy module communicates with the server at that point.
Remote Client Installer (AClient)
We use WNet functions to access the computer you are pushing to. We remotely access the registry for transferring messages (by RIServerEngine and RIClient), and remotely access the service manager to install and start the aclient service.
Remote control via Console to Deployment Agent for Windows (AClient)
This process has changed since DS 6.1.
In DS 6.1, the process uses an IP address but does not use a specific port. The Windows operating system will choose a free port number. That port number is sent to the client and the client makes another connection back to the console on that port. Remote control uses dynamic ports much the same as file copy. If file copy works, remote control should also work.
With the release of DS 6.5, we now allow the Altiris Administrator to select the primary and an optional secondary port for Remote control sessions. By default they are set to 5001 and 5002.
To change the port, you need to go to Deployment Console > Tools > Options > Global tab.
Wake-On LAN
Wake-On LAN allows you to start up client PCs that have been turned off. This includes clients powered down from Windows, from the console, and with the power switch. Clients enabled for Wake-On LAN have a cable attaching the network card to the motherboard. The network card maintains power even when the computer is shut down or powered off. When the card receives a Wake-On LAN packet from the network, it sends a signal to the motherboard to turn on the power supply and power up the client.
Wake-On LAN packets are sent via UDP on the same port that the Deployment Agent for Windows uses to connect to the Altiris Server Service (default 402).
"Magic Packet" is just another name we use for Wake-On LAN packet.
If the router will not forward magic packets, Deployment Solution for Clients/Servers has the ability to use Wake-On LAN proxies (Deployment Agent for Windows set to be proxies) which will allow it to work.
Set up PCs to use Wake-On LAN
Note: The motherboard and network card must support Intel's Wired for Management specification.
- Enable the available wake-up features in the client computer's BIOS (your BIOS may not list all of these).
| Power Management |
ON/ENABLED |
| Suspend/Wake-up Features |
ON/ENABLED |
| Wake-On LAN |
ON/ENABLED |
| Remote Power Up |
ON/ENABLED |
| Power Switch |
Suspend/Wake Up |
- Some network cards have their own setup utilities. It there is a Wake-On LAN option, enable it.
Deployment Solution for Clients/Servers and PXE
Deployment Solution for clients/servers includes the ability to install a PXE Server to load boot files and the Altiris Deployment Agent for DOS (bootwork.exe) executable into a client computer's RAM without the need for manually inserting a floppy disk at boot up.
Altiris Deployment Solutions for Clients/Server PXE uses the following ports:
- Fixed, not configurable
- UDP 67 & 68 to grab and reply to DHCP (and PXE request) packets
- UDP 4011 for PXE requests when PXE is installed on a machine with a DHCP server
- Configurable ports: Using the PXE Configuration Utility can be changed in the UI and the PXEManager.INI
- TCP 402 to talk with the Altiris Server Service.
- TCP 505 to talk to the Data manager.
- UDP 1758 (Multicast Client) & 1759 (multicast server), for TFPT and MTFTP transfer of PXE image.
- BIS UDPRspnd port UDP 1638.
PXE Config Utility shows the Multicast ranges used by PXE:
- Used by PxeManager and configurable in the RPC.ini
- "PMData class for PXEConfig and PXEManager"
ServerIPPort=405
- "PCSData class for PxeCfgService and PXEManager"
ServerIPPort=406
Understanding PXE
With PXE, client PCs can load and execute a boot image from a server on the network (instead of a local hard disk or boot diskette) prior to booting the OS on the local hard drive. This boot process is "hands off," meaning you don't have to do anything at the PC.
When a PXE-enabled client boots, it obtains an IP address from a DHCP server. It then finds the ProxyDHCP server (in the Altiris Console), which provides the client with a list of boot servers (servers containing client boot image files). The client PC communicates with the appropriate boot server to get the name of the boot image, downloads the image (using TFTP), and boots.
Intel documentation states that the following ports are required for PXE.
- DHCP - Ports 67 & 68
- MTFTP - Port 69
- Extended DHCP PXE request - Port 4011
Deployment Server 6.5 PXE IP Communication Flowchart
Step 1: DHCP request/confirmation and PXE boot menu
There are 2 types of architecture that create different types of IP traffic. First we will show communication with PXE and DHCP on different machines, and then we will show when they are on the same physical machine.
- The client machine sends out from address 0.0.0.0 port 68 over UDP to address 255.255.255.255 port 67. This is a broadcast packet that is attempting to discover a DHCP server. The packet contains the client MAC address, various configurations of what format and what items the client is expecting to receive as part of the DHCP request. The packet also contains in the configuration the option 60 with the string "PXEClient:Arch:00000:UNDI:002001" for a PXE boot as well.
If no response is received right away, the client machine should send this same packet out again with varying timeouts between each retry, for a total of 30 seconds worth of retries. Some PXE clients do not do this correctly, some only retry for 15 seconds and some retry for up to 1 minute.
- The DHCP server sends out a packet from its IP address and port 67 over UDP to a broadcast address of 255.255.255.255 and port 68. The packet contains an available IP address that can be used by the client. It also contains the MAC address of the client machine that the new IP address has been reserved for. The DHCP server will only send this out once for each discovery request that it receives and then wait to hear back from the client. The full DHCP protocol packet exchange of Discovery, Reply, Request, ACK is exchanged between the PXE client and the DHCP server (see steps 4 & 5 below). It is mentioned here because the sequence may vary from machine to machine and network to network, thus it is important to understand the purpose, not merely a specific observed sequence of the packets.
- The PXE server will hear the client DHCP discovery request, and it will send out from its IP address on port 67 a UDP broadcast packet to 255.255.255.255 port 68. This packet is very similar to the DHCP response packet, except that it contains option 60 with the string "PXEClient", and it has option 43 with the MTFTP server IP address as well as 2 ports to use to access the MTFTP server (the port to send from and the port to receive on). Option 43 also contains the PXE boot menu and boot prompt information.
- The client sends out another broadcast packet from 0.0.0.0 port 68 over UDP to address 255.255.255.255 port 67. This packet is a DHCP request instead of the earlier DHCP discovery packet. Basically this is a confirmation packet telling the DHCP server that it has received the offered IP address, and that it is going to be using that IP address.
- The DHCP server broadcasts another packet from port 67 to port 68 containing the MAC address of the client machine as well as the confirmed new IP address. This basically is an acknowledgement to the client machine letting it know that it has successfully reserved the IP address given for that client machine. The packet also can contain DNS server IP addresses, domain name, router, and subnet mask.
Second architecture type: DHCP and PXE reside on the same physical machine (This model will be the case if customer is using the new functionality in 6.5 SP1 where the DHCP server is distributing the prezero.0 and has Option 60 set to "PXEClient")
- The client machine sends out from address 0.0.0.0 port 68 over UDP to address 255.255.255.255 port 67. This is a broadcast packet that is attempting to discover a DHCP server. The packet contains the client MAC address, various configurations of what format and what items the client is expecting to receive as part of the DHCP request. The packet also contains in the configuration the option 60 with the string "PXEClient:Arch:00000:UNDI:002001" for a PXE boot as well.If no response is received right away, the client machine sends this same packet out again (sometimes this packet is sent 2-3 times) (see modifications above).
- The DHCP server sends out a packet from its IP address and port 67 over UDP to a broadcast address of 255.255.255.255 and port 68. The packet contains an available IP address that can be used by the client. It also contains the MAC address of the client machine that the new IP address has been reserved for. This packet also contains option 60 with the string "PXEClient" to let the client know that this response is the PXE response as well as the DHCP response. The DHCP server will only send this out once for each discovery request that it receives and then wait to hear back from the client.
- The client sends out another broadcast packet from 0.0.0.0 port 68 over UDP to address 255.255.255.255 port 67. This packet is a DHCP request instead of the earlier DHCP discovery packet. Basically this is a confirmation packet telling the DHCP server that it has received the offered IP address, and that it is going to be using that IP address. This packet also contains the same option 60 as packet 1, but this option is ignored by the DHCP server at this time.
- The DHCP server broadcasts another packet from port 67 to port 68 containing the MAC address of the client machine as well as the confirmed new IP address. This basically is an acknowledgement to the client machine letting it know that it has successfully reserved the IP address given for that client machine. The packet also can contain DNS server IP addresses, domain name, router, and subnet mask.
- The client machine sends out a unicast packet from its new IP address over port 68 with UDP to the address of the PXE/DHCP server on port 4011. The purpose of this packet is to request from the PXE server the PXE boot menu, along with all of its corresponding information. This packet is nearly identical to the packet sent in step 3, except that this time the PXE server will see the packet and recognize that option 60 is in this packet (as this option was ignored by DHCP in step 3).
- The PXE server will send a unicast UDP packet to the client machine from its IP address on port 4011 to the IP address of the client machine on port 68. This packet is very similar to the DHCP acknowledgement packet in step 4, except that it is unicast and contains option 43 with the MTFTP server IP address as well as 2 ports to use to access the MTFTP server (the port to send from and the port to receive on). Option 43 also contains the PXE boot menu and boot prompt information. (In SP1 if customer uses DHCP to forward clients to the correct PXE server using prezero.0 Option 67 will contain the filename and path of the prezero.0 file. Option 43 will contain static information on where to connect to the real PXE server.
At this point the client machine will do one of a few options. The client might be running the initial deployment boot option, the user might press [F8] and view the full PXE boot menu, there might be a job scheduled for that client, and it automatically chooses a boot option, or there might not be anything scheduled for the client machine and it automatically chooses local boot. Each of these options will be detailed below.
Additional Information about DHCP options 60, 54 and 43
Much of the useful information that is passed between the PXE Server and client is put into these options. The above information only briefly explains these options and does not go into much detail of the format of these options.
Option 60 is referred to in DHCP as "Vendor-Specific Information". It is basically a string saying "PXEClient" in the packet that is sent from both a client machine that is booting off of its NIC card, and it is also in the PXE server's response. The string in that option might have more characters than just "PXEClient", but it must have at least that string in it. If the PXE server and DHCP are on the same machine, this option will be set in the initial DHCP response. If those components are on separate machines the DHCP server response will not have that option, but the PXE server will. The option in the clients DHCP request lets the PXE server know that the client wants to PXE boot as well as get a DHCP server. The option in the PXE servers response lets the client know who the PXE server is, and who to request more information from to continue the PXE boot.
Option 54 is labeled as "Server Identifier". This is an IP address that will be used by the client to request the start of the boot file download from the MTFTP server. Usually this address will be the same as the PXE server, but it can be different if the PXE server and MTFTP server are on different physical machines. The IP address for the MTFTP server in option 43 does not contain the direct IP address, but rather the multicast IP address. This option is needed so that the client can directly address the MTFTP server without sending a multicast/broadcast packet.
Option 43 is only sent from the PXE server to the client. This option contains many values and is broken into various sub options. This option contains all of the data that the client needs to request any PXE boot option. The sub-options (and data contained) in option 43 are as follows: MTFTP server IP address along with ports to send from and to send to, the MTFTP timeout and delay times, the PXE boot control and boot servers, the PXE boot menu and PXE prompt. The PXE boot menu will have the default menu choice item at the top (this menu order is dynamically made for each client based on what jobs are assigned to the client). The boot menu also has in the 3rd byte of the field the menu timeout. If that byte in the menu is 00, the top option will automatically be chosen immediately. If that byte is 03 then it will wait 3 seconds before choosing the top menu item (such is the default case of local boot when no jobs are assigned), and if that byte is FF, the menu will wait indefinitely (this is the default behavior of initial deployment).
Step 2: PXE Boot menu option selection
Local Boot:
If a user is at the client machine while it is booting up and they manually press F8 and select local boot, or if they press escape during the above PXE boot process, no further packets are sent from the client in regards to PXE, and the client machine continues the BIOS boot order (most likely the production hard drive next).
If no user is at the client machine and the boot menu times out (determined by the boot menu in option 43) then the client machine will use the boot item that is first on the boot menu. If that option was local boot, no further communication will be made between the client and the server. The BIOS will just continue to the next boot option after the NIC card (usually the production hard drive).
Automation OS boot part 1(Downloading the .0 file):
- Regardless of the PXE menu choice selected, and how it is selected (whether it was automatically selected because it was at the top of the list, or a user at the machine manually selected one of the options). Once the client knows which menu choice it is going to choose is sends a UDP datagram to the PXE server for more information about that specific menu choice so that it can start to download it. This is a UDP packet sent unicast from port 4011 to the PXE server's port 4011. This packet does not contain any DHCP options (such as 60) because the DHCP process is over at this point. The packet is simply a UDP datagram of 548 bytes that contains the request for boot control from the PXE server in an Altiris proprietary format.
- In response the PXE server sends down a unicast UDP packet from port 67 to the IP of the client machine on port 4011. This packet is almost the same as the previous DHCP acknowledgement except that instead of having no boot file name, the boot file name is in the packet as the file on the MTFTP server to download (the .0 file name). This response also has options 60 and 43, but the data in them is already on the client. The only reason for those other options is so that the client knows that this DHCP response is a direct result of its request for the file name of the .0 file for the selected boot menu item.
- The client machine now knows exactly what file to ask for from the MTFTP server. It also knows the direct IP address of the MTFTP server (this is from option 54 of the PXE/DHCP response). The client machine sends a unicast datagram UDP packet from port 1758 to the direct IP address of the MTFTP server IP address on port 1759 (Ports 1758 & 1759 are the default ports used for MTFTP requests and responses, but these ports can be configured in the PXE configuration tool. For the rest of this tutorial these defaults will be used). The data in this packet is in an Altiris proprietary format, but mainly contains the .0 boot file name, and a request for download.
- The client machine sends another packet right away to the MTFTP multicast address. This is an IGMP membership report packet. There are no source or destination ports in this packet, and in fact it is not received by any other computers on the network. The purpose of this packet is to let the switches (and other level 2 devices) in this network know that this client machine is part of the multicast group for the multicast address that it has sent out. Whenever multicast packets of the reported address are sent from this point on, they will be sent to this client machine.
- The MTFTP server will next start sending the first .0 boot file. The first packet will be sent twice. Once to the direct IP address of the client machine, and the other to the multicast address established by the MTFTP server. These packets will be UDP datagrams going from port 1759 to the client port of 1758.
- The client machine after receiving the packet will respond with a small unicast UDP datagram packet from its IP address on port 1758 to the direct IP address of the MTFTP server on port 1759. This packet is just a confirmation that it received the last packet from the MTFTP server. It also lets the MTFTP server know which of the first 2 packets it received (either the multicast one of the directed one).
- The MTFTP server will send the next UDP datagram packet of the .0 boot file. This packet will be either a multicast packet or a unicast packet depending on the response it received from the client in its previous communication. Once this format is defined it will continue to send the UDP datagram packets in this format until the entire .0 file is sent down.
Steps 6 and 7 are repeated alternatively until the MTFTP server has sent down its last packet containing the end of the .0 file, and the client has sent its final acknowledgement.
Contents and purpose of the .0 file
All automation OS environments have a .0 file. This file was called in DS 6.1 managed.0 or newcomp.0 (for Managed PC and Initial Deployment respectively). In 6.5 these files will be named after what order they appear by default in the PXE boot menu. The first PXE boot file will have a file named MenuOption128.0 and the second one will have a boot file named MenuOption129.0 … etc.
Once this file has been downloaded completely from the MTFTP server, the client will load the file into memory and start to execute the file's code. This file is a bootstrap program that tells the client machines how much memory to allocate for the rest of the pre-boot operating system, and what other files will be included in the pre-boot operating system. The bootstrap program also starts the requests for the other boot files, loads those into memory, and then transfers control over to those other programs (generally those are the actual pre-boot OS). Usually this file is somewhere between 15-25 KB (depending on what the rest of the boot OS is) in size, but never larger than 32KB.
Loading the rest of the OS
At this point the .0 file has control of the rest of the PXE boot process. Each of the environments has a different .0 file and thus a different method for continuing the rest of the pre-boot OS. For example DOS re-establishes a new multicast session with a new multicast IP and then starts downloading a .1 file. Linux stops using multicast and goes to TFTP and starts downloading the pxelinux.cfg file. WinPE also stops using multicast and uses TFTP to start downloading the NTLDR file. There could also be a custom OS that behaved in a completely different manner. Normally after the boot loader program (the .0 file) has finished setting up memory and loaded the rest (or at least some of the other) of the OS files into memory it transfers control to some other program to actually run the pre-boot OS.
The entire PXE process is employed simply to create a virtual boot floppy in the client that loads the Altiris BootWorks program. The BootWorks program functions as a DOS client for Altiris Deployment Server. This program checks for and executes any pending work assigned to the client computer by the Deployment Server management console.
Additional Considerations
- PXE won't work with a DHCP relay or DHCP gateway (like Cisco's DHCP relay). The reason for this is that the RELAY makes the request for the IP address which means it provides the wrong MAC address. The computers will PXE boot but will not be able to automatically detect if there is work for that computer; instead it will default to the Initial Deployment event boot.
- With Cisco switches, sometimes there can be problems with PXE timing out while going through its spanning tree states. If you have a Cisco switch and you have spanning tree configured, the computer requests might time out because the switch will not let any traffic go through the port until the spanning tree negotiation is finished (Cisco Spanning Tree time out is 45-55 Seconds). The work around for this is to use the PortFast command on the Cisco switches which allows you to enable traffic to go through the port before negotiation is finished.
- It may be prudent to configure the routers with statements to forward DHCP discovers to both the DHCP and the Altiris PXE servers.
Imaging
RapiDeploy: Imaging engine
RapiDeploy is the disk imaging product that DS uses to perform disk imaging tasks. RapiDeploy can multicast disk images across a network to decrease the amount of network bandwidth used. The ports and IP multicast address ranges used by RapiDeploy can be configured from within the Deployment Server Console. Go to TOOLS > Options and select the RapiDeploy Tab.
The default IP range is 224.2.0.2 - 224.2.0.20 and can be changed by the end user.The default Port Range is UDP 401 - 401.
Each new disk imaging job will use a new multicast IP address in the default range to make multicasting more efficient. For example, if you start two separate imaging jobs on a single subnet, the imaging tasks will be able to see each other's packets. If a different multicast IP address is used for each job, the the NIC can filter out the packets that are coming from the other imaging job and will therefore not clog up it's IP stack with useless data. If you want to only use one multicast IP address, you can set the start and end IP addresses to be the same address and then put in a range of ports, 401 - 420, for example. This will keep the same IP address for all jobs but will cycle through the port numbers used for each job. This will also help keep packets from imaging jobs simultaneously running on the same subnet from interfering with each other, but will not be quite as efficient as using separate IP addresses since the NIC cannot filter the packets out at the hardware level any more, but the packets must go up the stack before they can be discarded.
Note: If using Gigabit 1000Mb NIC's (includes 10/100/1000 series) on the Deployment Solution computer, you will need to configure the "Offload Transmit TCP Checksum" to "Off". The TCP Checksum offloads are part of the NDIS 5 specifications (if the Deployment Server NIC is not using the NDIS 5 drivers, then this option will not be available). There are known issues with the NDIS 5 driver when connecting to a client running in DOS. Connections in this instance fail when the card is installed on the Deployment Server due to a difference in packet size and will not work correctly with DOS Clients.
In the reverse direction, this is not an issue when these NIC's are used with the client because they still load the DOS driver when booting to PXE or BootWorks.
Integrated components - Package Delivery
RapidInstall (RIPS)
RapidInstall is used for the deployment of RIP's (RapidInstall packages) and MSI's.
RapidInstall does not use any multicast IP ranges, the packages just get copied down with the normal file copy method.
RIPS are deployed to clients using a file transfer protocol (this is not FTP), which are dynamic by default.
The port used by file transfer can be configured to a static port within the Deployment Solution Console. Go to TOOLS > Options and select the Global tab.
User Profile Migration
PCTransplant
PCTransplant allows you to create a Personality package to migrate user profiles and settings.
A Personality Package is a self-extracting executable file created by the PC Transplant Wizard.
Because a Personality Package is a self-contained executable file, you can distribute it just about any way you want: floppy disk, e-mail, network share, CD, Web download, or removable media such as Iomega JazTM, ZipTM, or PeerlessTM drives. Personality Packages can also be deployed using services, such as Windows Task Manager, Microsoft SMS, and Altiris Deployment Server, a total computer management and deployment solution.
Personality Packages are deployed to clients using File Transfer protocols which are dynamic by default.
Real-time Migration
Through a network connection, you can transplant a computer's settings and files directly and in real time to another computer, eliminating the need of creating Personality Packages. Real-time migration includes the following features: user mapping, user properties, user account creation, application installation, and destination computer application information.
PC Transplant Real-time Destination Agent
The PC Transplant Real-Time Destination Agent lets you perform real-time migrations. This agent is run on the computer to which you want to transplant a personality. The PC Transplant Wizard is loaded on the source computer and can communicate with the agent on the destination computer through a network connection. Real-time migrations allow you to select and transfer the same elements of a Personality Package without the need of creating Personality Package files.
PCT has five of its own internal ports that are used during Real Time migration. Two are used to communicate between the source and destination, two are used to broadcast a datagram out to find a real time destination agent, and the other was added to manage connection drops. The ports include 4949, 3829, 4950, 4951, and 4952.
Port 4949 and 3829 are used to communicate between PCTWiz and the RTDestAgent.
Ports 4950 and 4951 are used to search for the RTDestAgent.
Port 4952 is for managing the connection drops.
PCTWeb
PCTWeb uses the HTTP port for storing a package on the Web, and the FTP port for updating setting files from the Altiris site.
Changing Default settings
Included in Deployment Solution is the ability to change the default setting which Deployment Solution uses to communicate with client computers. This includes the ability to set specific multicast ports and IP address ranges for multicasting as well as the client communication port.
You can access the Deployment Server Configuration Settings from the Control Panel and then selecting the Altiris Deployment Server cpl.
The transport settings tab allows you to change a number of settings for Client Communication including if the server service will allow connections from multicast clients or not.
You have the option to:
- Modify the multicast settings such as:
- Multicast Address (default 225.1.2.3)
Managed computers can use the multicast address if they are on the same segment as the Deployment Server and they are not using default PXE boot files.
- Multicast Port (default 402)
Use the default multicast IP address and port number if possible to avoid client connection problems.
- Multicast TTL (default 32)
The TTL field specifies the number of "hops" or hubs that the client can go through to multicast.
- TCP Port (default 402)
The port used by the Altiris Client Service and Altiris Server Service to communicate.
- Disable Multicasting and the Altiris Client Service must then connect to the Altiris Server Service using Direct IP connection.
Note: If you are using TCP to connect the Altiris Client Service to the Altiris Server Service, you must set it to use the same IP address as the Deployment Solution server computer NIC IP address for the VLAN segment you are working in.
Example: if NIC card (1) is using the address 192.168.0.1 and NIC card (2) is using 11.11.11.1 and you are configuring the Altiris Client Service for workstations installed to the network on the second VLAN, then you must set the IP address under Transport Settings in the Altiris Client Service properties to 11.11.11.1. If you are configuring the Altiris Client Service for the workstations installed to the first VLAN, then the IP address must be set to 192.168.0.1.
Note: If you change the settings as above, then you MUST configure the Altiris Client Service accordingly. You configure the Altiris Client Service properties using Altiris Client Services Properties. You can change this at the local computer by double-clicking the Altiris Client Service icon in the systray.).
Alternatively, you can right-click the computer within the Deployment Console and select Change agent settings > Windows/Linux to manage the Altiris Client Service remotely. For new computers go to Tools > Remote Agent Installer select the add button to add the computers you wish to install the Deployment Agent for Windows. All these settings can be defined at installation.
Multicast settings
Multicast Discovery uses UDP Port 402 by default but you can modify this in the previous dialog.
Direct IP connection or TCP connection
Deployment Server Web Console
Deployment Server Web Console 6.5 allows the Altiris Administrator to control multiple Deployment Servers from a single Web Console.
Web Console itself is communicated with through the browser and defaults to the "Default Web Site" which is pre-defined by the OS and IIS as port 80. If you change this, you must reconfigure the shortcut to point to the correct port. Web Console communicates with Console Manager and DataManager through their respective ports
Console Manager uses TCP port 8081.
This is only used on the local IIS server to the Console Manager Service so it is not traveling across the network but could cause conflicts if other applications are using this port on the same server. This can be modified in the registry
DataManager uses TCP/HTTP port 8080 by default and can be changed during installation.
Any communication going from the IIS Server to multiple DataManager's across the network need to have this port open in order to communicate through http to the remote servers.
DBManagement Service (mm.exe) uses port 505, which can be modified through the registry.