Showing results for 
Search instead for 
Did you mean: 

Provisioning error in different LANs

I have some trouble in trying to remotely configure AMT computers.

Our infrastructure and configuration rely on a single RCS server, which does not require OTP nor hello messages (Settings -> Advanced Configuration Options -> None). Such server has been installed on the machine that also hosts our SCCM primary site and we also installed the SCCM addon. Our configuration is also based on mutual TLS authentication.

New AMT administrative BIOS password and "first configuration" are provided by a USB key and setup.bin file, that has been created with the following command:

usbfile -create setup.bin admin NEW_MEBx_ADMIN_PASSWORD -hash rootCA.cer ROOTCA_CERT_DESCR -fqdn SCS_SERVER_FQDN -dhcp 1 -dns DNS_SUFFIX -domname DNS_DOMAIN_NAME -uHash 1

Certificate templates and AMT service account have been properly configured. Latest BIOS and firmware versions have been deployed as a pre-requisite, prior to try the provisioning and the first configuration by USB key.

If we try to remotely configure the AMT device, by deploying the SCCM Task Sequence created by the addon, we have no problems only if the provisioned machine is located in the same LAN in which also the SCS server belongs to. In all other cases, it seems that the remote client tries to configure and use an OTP password to proceed with the enrollment: this evidence has been noticed by looking at the log file and by the network team. In fact, in this case it seems that the machine tries to reach the server on port 9971. Anyway, no other firewall restrictions are in place: all network traffic is open from the remote location and the VLAN which hosts the RCS server.

Is such behavior possible? I mean: the MEBx behaves differently and automatically recognizes if it is in the same LAN as for the provisioning server? In that case, is there a way to avoid this?

To provide a better explaination, I've attached two log files. The "OK" file is related to a properly configured machine (which was located on the same LAN of the RCS server), while the "KO" file is related to a failed provisioning attempt.

The failed attempt log file includes this line:

2018-07-12 16:37:25: Thread:12444(DETAIL) : ACU.dll, Category: GenerateOTP Source: ACUDll.cpp : GenerateOTP Line: 1178: Changing AMT state from IN-provisioning to Pre-Provisioning in order to set AMT OTP

which is never recorded in all provisioned machines that belongs to the same LAN in which the provisioning server is located

Thanks in advance

0 Kudos
0 Replies