Automation has changed significantly since Deployment Solution 6.9 and, though there are elements that are the same, troubleshooting has, of necessity, also changed. What is the new flow of information and what tools do we have to troubleshoot this?
This article will cover the following topics:
1. Process Flow: Sending a client into and out of Automation, including Task and DS communications.
For the purposes of this article, we will begin with the following assumptions about the automation environment:
a) At this point, there is some confusion about reporting. Once the bits are flipped, we are not quite sure if the status of the reboot task is reported or not. Some testing points out that once flipped it reports up successful, which can be confusing if it then fails to restart and/or has another task pending. Other evidence suggests this status isn't returned until restart. More research is necessary to actually pin down what is happening.
a) It should be noted here how the SBS/PXE server knows about the system, partially discussed here: HOWTO21720. The NSiSignal service collects all computers from the NS when it launches and hands this to the Server service. The Interface service though is critical here, because it will be triggered via the same job to be aware of a system booting in it's environment and how to respond. It is interfacing directly with a Web service on the NS and hands this job information off to the SBS Server service. Thus, even a new computer not picked up by NSiSignal becomes "known" to the Server service.
b) As for which PXE servers are notified - this is chosen based on site information, and some research is still needed here. Essentially though, we look at the client task server, and the sites/subnets applied to that task server, which is obviously where the client system is connected, and send this information to all PXE servers in that "area" / site. What has not been tested yet though is what happens if you have PXE servers without Task services. This process was designed with the intention of having PXE services on all Task Server Site Servers, so there'd be a 1:1 match. If you configure it differently, we're confident it will not work correctly.
a) Obviously, if the Network drivers did not load or bind correctly, this will fail. The only symptom you will receive of this is no activity at all, which can be caused by various things. The WinPE session will load, the command prompt minimize, and then it'll just sit there. If you get no activity at all after several minutes, it's time to troubleshoot Network with things like Ping or other tools.
a) If you look at the agent log at this point, you will either see a successful launch of the PECTAgent, or an error launching it. The Agent logs are in the normal place expected, but on the X drive instead of C. Failures of the PECTAgent to launch can be caused by several things, including no network drivers, problems with network drivers, and possibly issues with the agent (that are still being researched).
b) Note: while in automation, all messages sent to log files (i.e. Agent.log and/or PECTAgent.log) are also sent to a port on the wire. There is a RemoteTrace tool (KB?????) that will listen on this port for these messages on the server and capture them in real-time. This same tool also listens for messages from PXE services, and a few other things which we're still researching. This allows the administrator to "see" what is going on at the client without being physically present, BUT, obviously requires functioning network connectivity in WinPE.
a) Normally, because the computer has not been physically "moved" between the shut-down and restart, the client will get the same Task Server list in Automation as it received in production, and thus will attach to the same task server. It is possible that if the system is moved, or if there are too many Task Servers, it could connect to the wrong one. This has not been tested by support and we're not sure what would happen, with some concern that the job for automation might not be present on the "new" task server and thus it would have no scheduled work-to-do.
a) What is not yet known is if it must download or run additional sub-agents. For instance, does it have to download the DTH subagent for imaging, or is this perhaps already in the WinPE image (far more efficient if so)? What about for other types of tasks? Can you send it SWD tasks or will they fail? Default tasks should work because they would be run by the PECTAgent just like the CTA in production. But what about inventory or SWD or other tasks? This has not been tested yet by Support.
b) **NOTE: We've received reports that the PECT agent is checking in every 5 minutes instead of following the default policy of 30 minutes. More research needs to be done on this issue. If you are seeing this symptom, please contact support.
2. Additional Troubleshooting Considerations.
Once in WinPE, there are a few things that can be done. The command prompt left minimized at the bottom of the screen will allow you to browse logs, edit files, restart agents, look at running processes, etc. Here are a few things:
3. Additional Possibilities / Functionality
While in automation, remember this is a fully-fleshed-out WinPE environment, and you can do a lot of things, such as those mentioned in the above section, custom scripts, map drives and execute things remotely, etc. Be creative.
4. Differences to be aware of from DS 6.x
For those upgrading from DS in an earlier version (pre 7.x), here is a short list of some key differences that could cause confusion. Please become familiar with these, and the new process at the top, to help adjust to the new environment: