I have three questions related to SCCM in-band provisioning
1. If for any reason in-band provisioning fails due to a server side error (e.g. something wrong with SCCM configuration) and the SCCM provisioning process gives up after what appears to be 3-retries (as determined by entries in AMTOPMGR.LOG indicating task removed from queue after 3 attempts), what is the cleanest and most timely way to re-initiate the client inband provisioning process without having to physically touch the client once the server side error has been rectified ?
2. The option Enable automatic out of band management controller provisioning which exists in the collection settings. If I have clients that appear in multiple collections, is this option handled by AND'ing the setting in all collections in which the clients appear (i.e. it needs to be checked in all collections to be effective) or is it handled by OR'ing the setting in which the clients appear (i.e. it only need be checked in one collection for the policy to apply to the clients). Apologies for my lack of what is probably basic SCCM knowledge here
3. Recently whilst working on an inband provisioning lab, I encountered a problem where the client side agent generated an error in OOBMGMT.LOG which said something along the lines of 'could not generate a OTP (one time password) and could not retrieve last OTP'. At this point ZTC provisioning appeared to cease. No amount of manually retrieving machine policy resulted in provisioning restarting and even re-installing the client side agent didn't yield success. This got me to thinking about whether there is any way to reset the inband provisioning process and force it to restart just in case of unforseen errors
If anybody can offer any help on the above questions it would be very helpful
I must say I think provisioning with SCCM is actually pretty nice and my experiences with it so far have been very positive
1. I've attempted a "fresh" provisioning a few ways. You may find one works better for you in your environment.
a) Delete the resource record from "All Systems" - obviously, if this is a currently working client, you may not want to do this - but I do if I'm just using the import wizard for my AMT system and don't need to worry (yet) about the client. Then, update the collection membership to ensure no policies exist for that machine, etc. Import the AMT system again using the wizard, and then update the collection membership, and let the hello packets come in. This will kick of provisioning for that system again. If you need to reinitiate hello packets, you can do that by pulling the AC to the computer, then re-powering up the system (assuming the 24 hours hasn't passed). You may be able to locate other methods to re-initiate hello packets besides that method if you can't get to the physical system.
b) If I'm doing in-band, then I'll turn off the collection setting for auto provisioning. Then update collection membership. Then, let the client update its policy with the disabled provisioning setting. You can do this either through the control panel applet (Machine policy retrieval & evaluation action) or by using the PolicySpy tool in the toolkit. Or, you can just wait until the client checks for policy (default is every 60 minutes). Then, once client won't activate provsioning (look at the oobmgmt.log file on the client for this info), then re-enable auto provisioning for your collection. When the client gets the policy for the auto-provisioning, (again, look in oobmgmt.log file), it should send the OTP hash to the server and the out of band service point will once again start provisioning.
2. The setting is OR'd (only one collection is needed)
3. See # 1 for re-starting inband provisioning. But, if you're seeing a failure to set OTP consistently on that machine, make sure the firmware's up to date, and the HECI driver's installed (and up to date) for that computer. We're talking to AMT using the HECI driver, so any issues would be related to the HECI driver or to AMT version itself.
Let us know if you have more questions/issues.