EEPC v7.0 FAQ - Integration with Intel AMT for Out of Band Management

Version 1

    General Questions

     

     

    Q: What does Intel AMT give EEPC?

    Integration with Intel AMT provides EEPC’s pre-boot environment with network connectivity and out of band management when used with McAfee ePO Deep Command.

     

     

    Q: How does the EEPC pre-boot environment communicate with ePO using Intel AMT?

    Intel AMT provides a secure network stack. Going through the process of configuring Intel AMT and deploying McAfee ePO Deep Command establishes trust between your endpoints and your ePO server. EEPC v7 has added a feature which allows it to use this network stack to communicate with ePO.

     

    Administrators can use the Intel AMT network stack to perform out of band management. New actions are available in ePO and when administrators take those actions, EEPC adds them to a work queue in ePO. The EEPC v7 pre-boot environment has been modified so that it always attempts to connect with ePO (if you have enabled the out of band management option in the EEPC policy) every time it boots (and on a 5 minute interval thereafter). Once this connection is established, the EEPC client then processes the work queue. If there is an action waiting for it, then it will find it and then perform the action. An example action is fetching a key that is used to authenticate to the pre-boot environment when no user is present.

     

     

    Q: What are the first EEPC use cases implemented in version 7.0 using Intel AMT technology and McAfee ePO Deep Command?

    The first four use cases implemented in EEPC version 7.0 are:

    1. Reset Password
    2. Contextual Security
    3. Wake and Patch
    4. Remote Remediation

    This FAQ will discuss these use cases in a bit more detail.

     

     

    Q: Where can I view a video demonstrating the Intel AMT functionality?

    You can see a video with the AMT functionality at this URL: https://community.mcafee.com/videos/1420

     

     

    Q: I’m an Administrator, how can I know if I can use the AMT functionality on a particular machine?

    If you view the machine properties in ePO you will be able to see the AMT information for that specific machine. McAfee ePO Deep Command Discovery and Reporting (free) also provides this information for all managed systems in ePO and displays it in a dashboard. In order to be compatible with EEPC, Deep Command must report the AMT status as “post configuration.” Also, EEPC requires AMT to be version 6.0 or above.

     

     

    Q: How does the AMT information about a machine get into ePO?

    Firstly you will have installed the Deep Command extensions, including the Discovery and Reporting extensions, and check in the packages on the ePO server. You will need to deploy the Deep Command Packages to the clients, which will report back if AMT is enabled.  In addition, if the system has actually activated AMT, the client will report back what AMT features are supported.  Deep Command adds a schedule server task to ePO that will automatically tag the machines with ‘AMT’. This task is scheduled to run daily and can be altered.  Please refer to the ePO Deep Command documentation for more information. If the system hasn’t activated AMT, then please refer to the Deep Command Discovery and Reporting Summary Dashboard to obtain AMT support information from a client.

     

     

    Q: What versions of AMT are supported by ePO Deep Command and EEPC?

    AMT version 6.0 and above is supported. The AMT version is part of the information that an administrator can view on a machine that is reported back by ePO Deep Command.

     

     

    Q: When I read information about AMT I see the terms CILA and CIRA. What are they?

    Client Initiated Local Access (CILA) is an AMT request from an internal network address. Client Initiated Remote Access (CIRA) is an AMT request from a remote network address. The definition of what is “local” and “remote” is defined as a part of the AMT provisioning process.

     

     

    Q: Why is CIRA disabled by default?

    In the default policy settings CIRA is disabled by default. This is a conscious decision on behalf of McAfee to protect customers from accidental exposure. CIRA is supported and must explicitly be enabled. By disabling CIRA by default, it means that if a company has an Agent Handler exposed to the Internet, it will not respond to any AMT requests over the Internet.  McAfee believes that customers need to make the decision as to whether they want to enable this functionality or not.

     

     

    Q: I’m told there are two types of AMT actions that can be queued against a single machine. What are they?

    Transient Actions and Permanent Actions.

     

     

    Q: Can you provide an example of a permanent and transient action?

    A transient action is an action that will be executed x number of times and then removed from the action queue.  Below are some examples:

    • Reset User Password
    • Unlock x number of times
    • Unlock from until
    • Emergency Boot
    • Restore EEPC MBR

     

    A permanent action is a an action that will remain in the action queue until it is removed by the administrator:

    • Unlock Schedule
    • Unlock Permanently

     

     

    Q: How many of each action can you assign to a single device/user?

    A maximum of 1 transient and 1permanent action can be assigned to a machine at any time.

     

     

    Q: Why can you only have 1 of each type?

    This was a design decision for this first implementation of integration with AMT.  If additional use cases arise, this can be revisited.  The underlying architecture has been designed to handle more actions if required.

     

     

    Q: When I watch a Wake and Patch, or a Contextual Security unlock, being performed on a client machine, the pre-boot seems to sit there for about 20+ seconds before it proceeds to boot into the Operating System. Is that normal?

    There are many factors involved in a “how long will this take” style of question. The speed of the network and the workload of the ePO server are two possible factors.  A known issue exists in AMT firmware which may lead to a 20 second day before CILA events leave the endpoint.  The effect of this on EEPC is that it may take over 20 seconds for an Out-of-band unlock to occur in a CILA environment.  Intel is investigating.

     

     

    Q: What Deep Command policies and settings are required for EEPC integration?

    The Product will be ePO Deep Command 1. 5.0,  the AMT Policies are required. Ensuring that the following are configured correctly in the policies-

    • Remote Access  = ticked
    • Enable Client Initiated Local Access (CILA) – pick the correct agent handler.
    • Connection type, tick BIOS and OS.
    • If you want Client initiated Remote Access (CIRA), then ensure that you have configured
      • Home Domain Suffix
      • DMZ agent handler
      • Allow User initiated tunnel.

     

     

    Reset Password Use Case

     

     

    Q: What is the Reset Password Use Case?

    This is functionality that will use AMT to send new token data out to a client. In this use case a user has started their machine and has forgotten their password. They can call a helpdesk/administrator and request that their password is reset. The administrator creates a 1-time password that will be pushed out via AMT to the client while in pre-boot. Using AMT is a faster alternative for resetting the password than the long established challenge/response method.

     

     

    Q: What are the high level steps for this use case?

    1. End user starts their machine, fails to log in and calls the helpdesk
    2. End User will go to the Recovery section in pre-boot and inform the Help Desk User of their ePO Username.
    3. Help Desk user finds the machine the user is using in ePO
    4. The Help Desk user uses the AMT functionality to reset their password with a temporary 1-time password.
    5. For the specified machine to receive the new token data, ePO writes the item to the work queue then the pre-boot reads the work queue and fetches the key by using the network stack provided by Intel AMT.
    6. The client will receive the new token data and will automatically leave the recovery screen and go back to the password screen. This is an indication for the end user that the new password has been received. Additionally the end user will hear a beep to also indicate that the new token data has been received.
    7. The End User will then authenticate with their 1-time password and will set a new password.

     

     

    Q: I've got an end user on the phone that needs their password reset. The AMT actions work on machines, rather than users in this case. Is there an easy way for me to work out what machine the user is at right now?

    On the client, in pre-boot, the user can go to the recovery screen and they will be able to view the Machine ID and Machine Name. They can give this information to the administrator/help desk and they can use that to find the machine in ePO.

     

     

    Q: If I can't work out what machine the end user is using right now, can I send the command to all of the machines the user can access?

    Yes you could, but McAfee doesn’t recommend it. Assume the user can access 2 laptops. They start laptop 1 and they’d receive the instruction to change their password. They go through the process and start Windows. They now turn on laptop 2 and it will also receive the request to change the password and their token data is updated to the 1 time password and they are asked to change it again. While this in theory could work in a controlled environment or where the user is aware, there is too large a chance it will cause end user confusion.

     

     

    Q: An administrator has just used the AMT functionality to change the user’s password. How will the end user know that the new password has come through to the client?

    If the end user was sitting on the recovery screen (where they told the Administrator the details of their machine) they will see the recovery screen disappear and be replaced with the logon screen. This is the indication that the new password information has been received.

     

    If the end user left the recovery screen and then waited for the updated password to be received they may see the logon screen disappear and quickly reappear.

     

    Additionally, when the new token data is received the end user will hear a beep.

     

     

    Q: How can an Administrator verify that the change went through successfully, or validate why it doesn't appear to work?

    This information will appear in the AMTService.log. Note that an event won’t be generated in ePO as there is no ePO API to do this from the agent handler.

     

     

    Q: Where can an Administrator find the AMTService.log file?

    It can be found on the ePO server at {epoInstallFolder/AgentHandlerInstallFolder}\DB\Logs\AMTService.log. It will also be collected as part of the server MER.

     

     

    Contextual Security (Location Aware) Use Case

     

     

    Q: What is the Contextual Security Use Case?

    The Contextual Security use case (also known as Location Aware) is a new authentication feature in the EEPC pre-boot environment. It gives systems the ability to authenticate without user intervention. Instead of asking a user for credentials, the pre-boot uses Intel AMT to initiate a network connection to ePO. Then, the pre-boot retrieves a key that it uses to authenticate in the pre-boot and then boots the computer into the operating system. The pre-boot environment and ePO can determine if the system is in the office or connecting via the internet. Contextual security gives administrators the ability to configure devices to authenticate automatically via ePO and AMT while in the office, but when the device is out of the office it shows the pre-boot authentication screen.

     

    Some example use cases where Contextual Security is useful are:

    • Customers who want to not show the pre-boot environment while their end users are in the office, but show it when they are outside the office or if the device is lost/stolen.
    • Customers who want to encrypt a device that is always in the office and not impact the end user with the notions of pre-boot and have them automatically authenticate via ePO and AMT. Also show the pre-boot if the device is stolen from the office.
    • Customers who have a shared device used by many individuals. Think of a meeting room, training room, or laptops and desktops in a hospital environment, etc.
    • Customers who want to remove password synchronization issues by never showing pre-boot, while having it's protection if the device is lost/stolen. Users will first authenticate at Windows even though behind the scenes EEPC has automatically authenticated via ePO and AMT.

     

     

    Q: How does this work?

    When the pre-boot starts it attempts to reach out to ePO and asks for permission to boot. ePO is the master and will decide whether to return the unlock key. If the client cannot reach out to ePO or ePO fails to return the unlock key to the client, the pre-boot environment will be displayed and it will wait for an end user to successfully authenticate. If ePO sends the unlock key, the device is unlocked.   The unlock keys are sent to the client down a secure channel, secured by the AMT hardware.

     

     

    Q: If I understand that correctly, authentication is actually occurring on the client and the necessary information comes from ePO. Is that correct?

    Yes, that is correct.

     

     

    Q: Is this bypassing pre-boot?

    No, the pre-boot environment is always there and always active. Pre-boot still shuts down and boots the Operating System when a successful authentication occurs. In this use case, the authentication comes from ePO.

     

     

    Q: If I were a user standing behind the machine I would see it automatically boot into Windows?

    Correct. Assuming ePO sends back a positive response it will automatically boot the Operating System once the response has been processed.

     

     

    Q: Does SSO work in this use case?

    No. Because the authentication in pre-boot is done against the machine and not a user then the user will be taken directly into Windows. As EEPC does not know which user to log in it can’t replay any captured SSO data.

     

     

    Q: So an end user still only needs to log in once, except now it is at the Windows prompt and not the EEPC pre-boot?

    That is correct. 

     

     

    Q: Does this mean that the user will only ever log in to Windows with their latest Windows password?

    Yes that is correct. This can remove any concern about password synchronization for users who continually use this functionality.

     

     

    Q: That’s great to hear, but what about a mobile user who spends time in and out of the office?

    For these users they will need their credentials to authenticate at pre-boot when they are not in the office.

     

     

    Q: Ok this can be explained to the mobile users, but what happens to password synchronization in this scenario?

    For mobile users it is better to always enforce pre-boot authentication. As technically an end user does not log in at pre-boot in this use case, EEPC is not aware of password updates because it does not know to which pre-boot user to apply any update for passwords.

     

     

    Q: So does this mean that this use case achieves the most value for devices that never or very rarely leave the office?

    That is correct. This is an excellent use case that should only be used for desktop machines or laptops that don’t leave the office network.

     

     

    Q: If a device gets stolen, will it show the pre-boot environment?

    Yes. Because it can’t communicate with ePO it will show the pre-boot environment and wait for a user to authenticate.

     

     

    Q: If I have enabled CIRA, does this mean that a machine that is not on my network can automatically boot?

    No. EEPC makes no decision on whether to display PBA or not. If EEPC “Out of Band” management is enabled then EEPC will try to send a call for help.

    The AMT chip will then check the environment and see if it is plugged in on Remote or Local Network. If it is plugged into the local network it will post a CILA to the ePO server. However, if it detects that it is connected on a Remote network, if a CIRA server was specified it will try to securely connect to it. If any of the calls for help whether CILA or CIRA result in a successful connection with the server and the server decides to send the encryption key then PBA unlocks and goes into windows. Otherwise if no key is received it will remain at PBA.

     

     

    Q: How does an Administrator enable the Contextual Security functionality?

    1. Administrator selects 1 or more machines
    2. Administrator then selects the “Out of Band – Unlock PBA” action
    3. Administrator then specifies the duration of the unlock, either permanently or to a schedule. They can also choose whether the action is actionable for local or local and remote machines.

     

     

    Q: Can this be set permanently or for a specific time period?

    When the administrator enables this functionality they have the option to enable this functionality permanently or for a defined period of time. For the defined period options an administrator can specify:

    • 1 or more reboots
    • From start date/time to end date/time
    • A weekly schedule for blocked or available times

     

     

    Q: What happens if ePO is busy and can’t respond to the device?

    The device will remain in the pre-boot environment and retry every 5 minutes.

     

     

    Q: If the device fails to reach ePO the first time, will it try again?

    Yes, it will attempt to contact ePO every 5 minutes. This is true for CILA (Local) requests. However for CIRA (Remote) requests the device will only reach out to ePO once. If it doesn’t receive a response, the machine will need to be rebooted in order to reach out again.

     

     

    Q: What happens if the ePO server goes down and no device can reach ePO?

    This is the worse case scenario. If users do not know any pre-boot credentials, a possibility if the user has always used this functionality, then they will be stuck in the pre-boot environment. Their only option would be to call the helpdesk and do a machine recovery with the challenge/response process.

     

     

    Q: I have an end user using a desktop machine in the office who's been using this functionality and has never needed to log into pre-boot before. Today they now see the pre-boot. They don’t know their credentials. What can they do? Can they ask pre-boot to reach out to ePO again?

    There are a several choices:

    1. Firstly they could wait 5 minutes for the next attempt to reach out to ePO. This is true because it is a CILA (Local) request.
    2. Secondly they can turn their device off and on again. This will cause the pre-boot to immediately reach out to ePO again when it restarts.
    3. And lastly, they can always authenticate by entering the username/password of another known user who can authenticate at pre-boot. This may not be available in all situations.

     

     

    Q: As an administrator, I'm getting complaints from some users that from time to time this is not working. How can I verify that? Is there anything on the ePO side that will show this?

    This would be seen in the AMTService.log. This file does roll over and has a file size limit (default size limit set by Deep Command).

     

     

    Wake and Patch (Remote Unlock) Use Case

     

     

    Q: What is the Wake and Patch (Remote Unlock) Use Case?

    This use case covers the need to urgently or regularly schedule wake and patch devices. These devices are shutdown and need to be woken so that the patch can be applied to them.

     

    This is very similar to the Contextual Security use cases. The following questions are the same for both use cases:

    1. How does this work?
    2. If I understand that correctly, authentication is actually occurring on the client and the necessary information comes from ePO. Is that correct?
    3. Is this bypassing pre-boot?
    4. If I were a user standing behind the machine I would see it automatically boot into Windows?
    5. Does SSO work in this use case?
    6. What happens if ePO is busy and can’t respond to the device?
    7. If the device fails to reach ePO the first time, will it try again?
    8. How does an Administrator enable this functionality?
    9. Can this be set permanently or for a specific time period?

     

     

    Q: Can I stagger them or the interval where they will reach out to ePO?

    An administrator will need to stagger the Deep Command Power on Command, or their equivalent Wake on LAN request. Systems are powered on when Remediated in the SILA environment, i.e. when the action is Server initiated . In other cases, the machine calls us; therefore we assume it is on as it has called us.

     

     

    Q: What happens if ePO is busy and doesn't respond, what will the machine do?

    If ePO is busy or doesn’t respond after a wake on LAN request then the machine will stay in pre-boot and try again every 5 minutes. This is true for CILA (Local) requests. However for CIRA (Remote) requests the device will only reach out to ePO once. If it doesn’t receive a response, the machine will need to be rebooted in order to reach out again.

     

    To reach a system periodically, it needs to be configured to send CIRA messages periodically using Alarm Clock. Alam Clock switches the machine on at a certain time as specified.

     

     

    Q: Can I see how many of my systems made it into Windows for the patch process?

    An Administrator should be able to see this via the EE:Product Client Event Query with an appropriate filter.  This will rely on the systems having communicated with the ePO server to send the audit information.

     

     

    Q: Can I find out which machines didn't make it past pre-boot?

    No. If the machine doesn’t boot into Windows, there won’t be an entry in the EE:Product Client Event Query. 

     

     

    Remote Remediation Use Case

     

     

    Q: What is the Remote Remediation Use Case?

    This use case offers administrators the ability to perform an Emergency Boot, or replace the EEPC MBR on a client machine via AMT without needing to physically touch the device. This enables an administrator to fix an issue on a machine that is half the world away. Please read below for more information about Remote Remediation and UEFI.

     

     

    Q: How does this work?

    At a high level, a small disk image (the image is 1.44MB but only 300k of it is used) is pushed down via AMT to the client machine. Once received on the client it will be rebooted and boots using boot network from IDE-R. That image will then perform the necessary remediation actions and start the process to boot Windows.

     

     

    Q: So there are two possible actions for remote remediation?

    Correct. The first is to perform an emergency boot and the second is to replace the EEPC MBR. Remote remediation will only work on devices with a BIOS boot process.

     

     

    Q: How does an Administrator use this functionality?

    1. Administrator selects 1 or more machines
    2. Administrator then selects the “Out of Band – Remediation” action
    3. Administrator then specifies “Emergency Boot” or “Restore Endpoint Encryption MBR” and presses Ok.

     

     

    Q: How is the functionality initiated on the client when it is local?

    When the machine is connected to local enterprise network:

    1. User boots the machine and finds that is not working.
    2. User calls administrator and asks for help
    3. Administrator selects the appropriate remediation action and the action will start processing immediately. This can also be referred to as SILA (Server Initiated Local Access).
    4. If the machine is found and connected then Redirection will start and fix the machine automatically. However, if the machine cannot be found in the local network the action will fail and remain as pending in the queue.
      1. This can then only be processed when the machine calls in.
      2. In this case it will not as pre-boot is broken so a similar flow as described on next scenario could also be used.

     

     

    Q: How is this functionality initiated on the client when it is remote?

    When the machine is connected through a public network

    1. User boots the machine and finds that is not working.
    2. User calls administrator and asks for help
    3. Administrator selects the appropriate remediation action and the action will start processing immediately. (In this case the action will fail, as it cannot find the system in the enterprise network).
    4. Administrator asks the user to initiate a “Call for Help” from BIOS.
      1. This varies from one OEM to another but it tends to be under boot options and in some machines you could simply press Ctrl+Alt+F1.
      2. Once this is selected the machine will connect to STunnel (Deep Command Gateway Services) and the Agent handler will detect this and send a message to DeepCommand.
      3. DeepCommand will process the action associated with the system. In this case it will be the remediation action.

     

    NOTE: Remediation over CIRA can take considerably longer than when performing the same action inside the enterprise. In some machines this could potentially take up to 20 minutes depending on networks used during processing.

     

     

    Q: I'm in Santa Clara and I'm trying to run an emergency boot on an end user who is currently in Japan and needs a recovery urgently before an important meeting. Can I use this functionality to achieve this?

    Yes. Using this process requires no end user intervention. They can simply watch you repair their machine. For CILA (Local) this is correct. For CIRA (Remote) it will initially fail but once the machine connects via CIRA it will be acted upon.

     

     

    Q: Do I know how long that would take in this example?

    This is largely dependent on the network speed and how long it takes to get the image down to the machine. Once it has booted onto the image it will take the same amount of time as the Emergency Boot takes today if you’ve done it manually. It actually follows the same process, but in an automated fashion.

     

     

    Q: As an Administrator, will I get any notification of the progress?

    The administrator will only be informed that it has started and when it has finished.  Upon completion they will be told if it was successful or not. The audit will be on the client and will only be sent back to ePO on the next ASCI. The administrator can run a query on the client events to find the clients with an UNLOCK event.

     

     

    Q: As an end user, will I get any notification of the progress?

    There will be a message displayed on the screen once the image has downloaded and the remediation process starts. For the download of the image to the machine via AMT, in some instances you can see a blinking glyph in the top right hand corner of the screen. This is an indication that AMT is receiving network traffic. Again, the duration is largely dependent on network traffic and speed. If the network is fast the end user may just see Windows suddenly boot.

     

     

    Q: I don’t see the blinking glyph, does that mean nothing is happening?

    That is one possibility. That functionality was not included until AMT version 7 so if you have AMT version 6 then you won’t see it.

     

     

    Q: What happens if I run out of time and need to leave my current location? I disconnect the network cable when I leave. Do I need to start the whole process again? And to do that will I need to work with an Administrator again?

    No, the process will start again automatically.  Once the administrator has added the request for remote remediation it will sit in the action queue until it has been completed or deleted by the administrator. This means that it will attempt to perform the remediation each time you boot the machine until it is successful.

     

     

    Q: Ok, the process was successful and the user is back into Windows. They can give their presentation but they don't have a connection to the corporate ePO server right now. Will they need to go through the same process again when they reboot their machine?

    Yes. If the pre-boot were damaged, then machine would have been emergency booted.  This can’t be repaired until the machine can successfully communicate with the ePO server.

     

    On the other use case of replacing the EEPC MBR, then the answer is No.

     

     

    Q: Why would I want to replace the EEPC MBR?

    If a third party product accidentally overwrote the MBR while the machine was encrypted you’d need to do this. Alternatively, if the machine were infected with a MBR virus you’d need to get the machine back into Windows so any other remediation could take place.

     

     

    Q: When selecting a remediation I can select a disk image. Why would I want to do that?

    Automatic is the default option and the one you should use all of the time unless directed otherwise. The automatic option uses the information received from the client to select the correct image.  If this information is not available it will not perform the remediation. 

     

    What this option allows you to do is specify the exact image that is sent down to the machine. There are different images for BIOS boot and Opal and non-Opal remediation.

     

     

    Q: What happens if I select the wrong disk image for the machine?

    If an image is selected manually, the UI will indicate that you could potential damage the disk by using the wrong image.  This option was added for the event when the Encryption provider or BIOS Type is not available.

     

     

    Q: Does the Remote Remediation functionality work in a UEFI environment?

    No. IDE Redirection does not work in UEFI and this functionality is required for remote remediation.

     

     

    Reporting and Error Conditions

     

     

    Q: How can an Administrator know that the AMT action has completed successfully on the client?

    EEPC only has one server side action, which is for remediation.  To determine if it completed, an Administrator should look at the ePO Server Task Log by running a query on the event audit log to see the client events.

     

    All other actions (Unlock/Reset User password) are client initiated.  When the administrator configures these actions there will be an entry in the ePO User Audit log to record that the request has been added to the EE:OOB Action queue.  Then when the client PBA requests help, it will create an audit item on the client. This audit item will be sent to ePO on the next ASCI when it is within Windows.  These will appear in the EE:Product Client events query.

     

     

    Q: How can an Administrator work out what and where it went wrong if it didn't go through successfully?

    The Administrator will need to look at the AMTService.log and the EE:Product Client Event Query.

     

     

    Q: Where can an Administrator see that one (or more) of the AMT actions has been successfully completed on a client (or multiple clients)?

    The EE:Product Client Event Query will show this.

     

     

    Q: Can an administrator create reports on the AMT actions? For example, show me how many systems have automatically booted today using the Remote Unlock functionality?

    This information should be available via the EE:Product Client Event Query with an appropriate filter.  This will rely on the systems having successfully communicated with the ePO server to send the audit information.

     

     

    Troubleshooting

     

    Q: If an administrator has an AMT OOB issue, what are the first steps they should perform?

    The administrator will need to establish whether the issue stems from a CILA task or a CIRA task.

     

     

    Q: In this case it is a CIRA task that was performed. What do they do now?

    Ask the administrator to boot the machine into the BIOS screen or into Windows and use the Intel Management and Security Status to request help. Then they will need to check the ServiceAMT log to see if a request has been received. If it has, then the support call will involve EEPC Tier III. If not, it will involve Deep Command Tier III.

     

     

    Q: What if the AMT OOB issue stemmed from a CILA task?

    Ask the administrator to use the Deep Command action to boot the machine into the BIOS screen. If it succeeds, then the support call will involve EEPC Tier III. If not, it will involve Deep Command Tier III.