What is the best way to view or capture the communication processes involved with Axengine, AClient, or PXE for troubleshooting?

Deployment Solution 8.x

What to capture:

To troubleshoot any Axengine, PXE, and AClient issues, the following logs are very useful, though all may not be necessary for any particular issue.  Most of these are not enabled by default, or if they are, may need adjustment. 

• Axengine.log (Engine or eXpress.exe)
• Server side AClient Agent log
• AClient.log
• TCPView
• PXE logs
• Wireshark trace

As a good place to start, the Engine and AClient logs are very basic ones we use often in support and should be capture per the instructions below.  Each circumstance is different though, and depending on your issue, you may need more than that.

When to capture:

It is best to capture your logs and traces at the same time so that comparisons may be made.  For instance, client communications may "look" OK on the client-side, but be broken on the server, or vise-versa.

Also, it is very useful to start with a clean set of logs, and to get these to include the startup of the services themselves.  Windows Services should some or all of the following services (they will have all in a full DS installation, but some may be moved off-box):

• Altiris Deployment Server Console Manager
• Altiris Deployment Server Data Manager
• Altiris Deployment Server DB Management
• Altiris eXpress Server
• Altiris PXE Config Helper
• Altiris PXE Manager
• Altiris PXE MTFTP
• Altiris PXE Server

Depending on what you are troubleshooting, you should stop the related services, delete any previously created log files, and then restart those services.  For instance, you may want to stop all PXE services if your clients are having troubles getting the preboot environment.  You may want to also stop the engine (eXpress server) if they don't get menu's.  If you are unsure, stopping all the services and capturing all these logs may be the wisest option, or getting assistance from Support.

Configuring Logging and/or Trace

Engine Logs (eXpress service) and server-side AClient/DAgent logs

The axengine.log and server-side located in eXpress share, AClient agent logs are enabled and adjusted in file size in the same location on the Deployment Server. Within the Windows Control Panel you will see the Altiris Deployment Server Configuration. Double-click on the icon. Click on the Options button and then select the Debug tab.  Change the level from 1 to level 5 logging and increase by adding two zeroes at the end of the File log size for the Axengine. It should read "Max File Size: 204800" after you have added the two zeroes at the end.

The Agent server side client log will be named after the client ID and placed into the location specified, which is located in the express share > Temp > MSGS > CompID.log by default.  We only need the CompID.log associated with the Computer ID in question.  Right click on the Computer Icon in the Deployment Server console> Select 'Properties' the Computer ID is 'ID' = 5000xxx.  Locate the 5000xxx.log in express share > Temp> MSGS> 5000xxx.log

Client side Aclient logs

The AClient.log will be enabled from the AClient Admin Properties. You can enable the AClient log from the Deployment Server console. Right-click on the computer icon, select Change Agent settings > Production agent, and then select the Log File tab. Check box should be on  Log errors, Log information, Log Debugging information.

The location for the log files will be, by default:

• AClient: %programfiles%\Altiris\Aclient\Aclient.log
• DAgent: %systemroot%\temp\dagent.log

TCPView log

TCPView is used to watch open ports and activity ON the actual server or workstation.  This can be very useful in capturing communication problems.  For instance, AClient opens port 402 with the engine when it starts, and this port should stay open.  TCPView will show this port being opened, and if it's being closed, will show when, and by whom.

TCPView can be downloaded from here. It should be extracted on either the server, or client, or both, depending on the symptoms being seen and then configured to capture port 402 (or other ports if necessary) TCP communication.

Wireshark Trace:

Wireshark is a free tool to watch network traffic.  It is often very useful when troubleshooting PXE and other imaging related issues.  It can be downloaded for free from Microsft Technet.

Once downloaded, it should generally be run from the Deployment Solution server, and should be configured to watch all traffic on the local segment.  A filter that is VERY useful though, to capture all PXE and automation environment processes is:

bootp || tftp || udp.port == 4011

This would be placed on the Filter line, so that you only see the relevant traffic.  Removing that filter would immediately expose the rest of the traffic though, which may be useful.  Once captured, this trace can be saved, zipped, and set to support if necessary.

For wake on lan, we have another KB: How to use Wireshark network traces to troubleshoot Wake on LAN issues

Other tools from Technet that could be helpful is Regmon, and Filemon, to troubleshoot further.

PXE Logging:

Any PXE Server side logs should only be turned on when Support needs these logs. These logs are located in Deployment Server Console > Tools > PXE Configuration utility. The log files do not have a file max size and will increase, potentially filling the drive.  Additionally, some of the logs, such as MTFTP logging, can significantly slow performance.

The logs are very specific to certain functionality and should be enabled accordingly.  When in doubt, set all (except MTFPT) the logs to capture "All" and enable them.  MTFTP logging should only be enabled when you are confident you need this log.

Others:

DStraffic.log tells us why a job assigned does not execute.

If a SQL Profiler is needed in troubleshooting follow the article 22953 to enable the SQL profiler.

What to do with your logs?

Enable the logs, restart the services, and then duplicate your problem.  Capture the logs created, and, along with a well documented set of steps you followed, send both to Support. 

We do need to know WHAT you did, not just what errors you received.  The process, even configuration items you may feel are un-related, may be very important to your issue.  Whatever you customized, or performed should be captured and given to support as well.