The answer is yes for AMT 3.2. However, If the AMT machines are 2.x, it may fail.
What you should do are:
1) Create a provision certificate for one domain. FQDN of provision certificate is like: SCCM.Contoso.com, SCCM.Site1.Contoso.com, etc
2) youonly need to install one Site server with one OOB SP. Import the provision certificate in that site server. Make sure that the provision certificate's FQDN matches the domain suffix of the OOB SP role. For example: if the OOBSP is installed in the Site1.Contoso.com domain, the provision certificate's FQDN should be like SCCM.Site1.Contoso.com
3) DHCP option 15 return the correct Domain suffix. For example: the AMT machines in Site2.Contoso.com should get the domain suffix of Site2.Contoso.com
4) When you choose the AD Container in Component configuration, they shall make sure each domain has that container. For example: if they install the Site server in Site1.Contoso.com domain. And they choose AMTOU as their container. you shall also create AMTOU container in Site2.Contoso.com & Site3.Contoso.com domain if you want to manage AMT machines in these domains.
5) Make sure the site server machine account has the permission to access these containers.
Thanks Lexhu for reply
Just one point of confirmation. Presumably the VPRO 3.2 system is then inherently trusting any child domains of CONTOSO.COM ?
Is this firmware behaviour restricted to just .COM and .NET top level domains. Would it work if my example scenario was moved out of the .COM domain into say the .CO.AU domain and my names became CONTOSO.CO.AU, SITE1.CONTOSO.CO.AU, SITE2.CONTOSO.CO.AU
The reason I ask is that I recall reading something in the Intel Setup and Configuration Service (SCS) manual indicating that when performing a check on the validity of the domain of the AMT Provisioning Certificate, the AMT firmware gives special consideration to .COM and .NET domains
Yes It works! This works exactly the way Lex Hu suggested here. Thanks Lex Hu!
You need to have only one single SCCM Site server and OOB SP installed on that server for all the domains.
All clients from all domains will be discovered by this single site server and get provisioned accordingly if you carefully follow what Lex Hu suggested.
I tested it provisioning a client from child domain with site server & OOBSP in the parent domain. I could also test the other scenario to provision a client from parent domain with a site server & OOBSP in the child domain when I get a chance and update here.
Below is the message that I posted earlier and I misinterpreted Lex Hu's response and created one site server for each of the domains. If you have dedicated site servers for each domain servicing the clients in that domain then you need to have a separate OOB SP for each of those domains on that site server. This could be useful scenario's so I am leaving my original post intact.
I was very interested in being able to provision a client in child domain from an OOB SP installed in parent domain by following this suggestion mentioned here. So I built four different VM and to the contrary what is suggested here, and was not able to provision with single OOB SP in the parent domain.
The only way I could provision clients in child domain was to install a separate OOB SP on the child domain and use a separate provisioning cert for that domain.
What I have done to prove:
Parent domain: vprodemo.com
Prov cert: verisign cert issued to vprodemo.com
Primary Site server: MSSCCMSP1 with OOB SP installed with the above cert.
DHCP server & DNS server
Child domain: Chld20.vprodemo.com
Primary Site Server: CHLDSP1 with no OOB SP installed but I was trying to use the OOB SP from Parent
Separate DHCP Server with DNS server same as Parent domain
If I discover clients in child domain, auto provision policy is disabled since there is no OOB SP installed here. I have no way to enable auto provision for this collection - this box is grayed out.
If I discover these clients in parent domain, the TLS connection fails made between the OOB SP and the client and the client does not go into provision mode. I believe the TLS connection is refused since the provision cert with a prefix vprodemo.com does not match the client prefix from the AMT self-signed cert "chld20.vprodemo.com"
I was able to install separate OOB SP on chld20.vprodemo.com and was able to provision with internally generated provision cert for this domain using the CA installed on vprodemo.com
Does anyone have further insight into this? It appears that you need to have a separate OOB SP installed for every domain whether it is a child or a separate domain tree in the forest unless I am missing something. Appreciate any pointers.
I've had zero experience with provisioning clients in multiple domains, but wouldn't a UCC SSL certificate theoretically work?
Tim Duncan has written a great white paper to address these specific questions; types of certificates that can be used in different domain environments with various AMT firmware versions. There are lots of variables to consider when looking at what type of certificate can be used for remote configuration. This is a great doc to get an understanding ofall of these variables. Feedback is always welcome to improve this doc.
It appears that SCCM OOB SP takes only simple SSL certs. I created a wild card cert *.vprodemo.com and it checked the CN name and since it did not match it did not push the cert to memory for provisioning. Does anyone know how to create UCC certs or second level domain certs using Microsoft CA?
Unified Communication certificates (UCC) are accepted by SCCM OOB service point as long as the domain in the subject common name (CN) matches the domain of the SCCM OOB SP. As you indicated, wildcards are not accepted
Here is a little more food for thought
1. Provisioning support in child domains only happens if you are in .NET and .COM domains because of the special treatment that AMT 3.2.1 and AMT 2.6 firmware gives to these top level domains. If you tried provisioning in child domains which are based on a .CO.UK or .DE domain for instance, I think you'll find that by default Intel AMT will not trust certificates from the primary site server located in some parent domain. I guess you need one of those UCC certificates in this scenario or you can set the MEBX PKI domain suffix to override DHCP option 15 and persuade clients to trust certificates from a higher level domain
2. In a slight twist to the 'single site server, multiple domain' approach, I recently built a 'multiple domain multiple site server' configuration to check clients can be managed correctly using collection initiated operations from servers located further up the hierarchy (or even the central site server). For me, the collection initiated operations were important - the SCCM OOB Console always works across trusted domains because it uses Kerberos authentication - the question was would collection initiated operations work - and they do - albeit somewhat slowly - clients assigned to a primary site server located further down in the hierarchy can be power controlled successfully from SCCM collections located further up in the hierarchy. The only requirement appears to be the OOB SP needs to be installed on all primary sites responsible for managing (and provisioning) clients
I have been using AMT 4.0 clients to test multiple domain single site server scenario and every thing seemed to work fine. I extended my test to AMT 2.6 using PKI provision and ws-man translator and I would like to document my findings here for community benefit.•AMT 4.0 clients from parent domain to site server in child domain and vice versa and managed using webui as well as OOB Console•AMT 2.6 client from parent domain to site server in parent domain and managed using webui as well as OOB Console•AMT 2.6 client from child domain to site server in parent domain––Provisioning works (as indicated in the logs), webui works– -Sccm console identifies the AMT client as detected. i.e. OOB Console can not be launched
Interesting that SCCM OOB Console does not launch when trying to manage AMT 2.6 client in child domain
Thinking aloud here
1. What do log files for the SCCM OOB console look like ?
2. If you turn on logging for Intel WS-MAN Translator, what do these log files look like ?
3. Does SCCM OOB console really not even come up - or does it just not connect to the client ?
Be interested in any or all of the above