Could there be a problem joining the domain? I know I had a similar problem and it turned out that the account I was using to join computers to the domain did not have the ability to rewrite an entry. It could however, create a new entry. I also noticed that you are using HII in the first task, but not in the second one. I assume you include drivers in the Image? Could it be a SATA driver, or BIOS Setting? Perhaps configuring the BIOS to Compatible instead of AHCI would do the trick.
Besides the fact, it could be indeed a NIC driver issue (check that on the deployed machine with a failed join domain action in device manager),
Are you sure that the computer gets the right DHCP entries. I mean does the NIC get the right DNS values, because if the DNS server is not the DC server, it won't be able to join the domain.
To check that out, just create a new provisioning template with just the Join Domain action (You will gain some time for your tests). But before running this provisioning template against the target machine, check the DHCP entries with ipconfig /all
Hope it will help,
A few things:
1.) I'm assuming you're working with 9.6 patched with SP1, and all available post SP1 patches for your core.
2.) A join domain action should not really be the first action that you perform in the system configuration section. It should be to install the agent.
3.) Also you should configure a "provisioning agent" with bare minimum features, and all the scheduled items turned off. This way the agent doesn't walk on itself during your later actions of sys config. Using a standard agent config could lead to action failures just because the agent decides to do a bunch of other things while you're asking it do the actions that you really want.
4.) If the agent installation is failing it is usually related to how the server name is setup in the WIM file for the win PE environment. It is usually short name. You may need long name instead, or vice versa. You can test this without changing the WIM file though. Try adding both the short name for the core, and the FQDN for the core EACH as "preferred servers". These are essentially fake entries. You can even provide narrow IP ranges on these two fake preferred server entries. like 18.104.22.168 -22.214.171.124 and 126.96.36.199 - 188.8.131.52. You don't need to do any replication stuff with these at all, because they are basically the core, so you would never replicate from itself to itself anyway. The important thing is that you provide both of these preferred server entries with the username and password for READ access that is needed to be able to connect to the core's UNC shares to get the agent installation. What is probably happening now is that is failing because it isn't finding your server. This might be related to your join domain step not working, but again.. agent installation should not be dictated by the success of a join domain step anyway. You can figure this out if you go into your provisioning template and uncheck the box that makes it remove the provisioning folder. This way you can review the logs in this folder to see the errors. The ldprovisioning folder will be in the root of the C Drive. After you run this task again, and it dies again (assuming it does!), then you can check the log files in that folder.
If you read closely, in the agent installation action window, it states that it uses preferred server credentials, so if you enter the server as long and short name in preferred servers, then the provisioning action will be able to succeed.
Thank you very much for all your suggestions and apologies for not replying sooner, its been a busy few days.
I have tried all of the suggestions, but it still fails at the same point.
I then tried changing the image path in the failing template to the image that seems to be working. The template then completed successfully.
This tells me it must be something to do with the image as everything else in the template seems to work fine. I dont understand it though as I have tried several times to recreate the image (which is based on the image which does work!)
Have you looked at your log files on the client to see what the exact error is? Under the options of the provisioning template you can uncheck the option to "remove the client provisioning folder", if you try the task again it should leave a ldprovisioning log and a log for each step in the process.
Did you make sure to sysprep the image again after you added the applications? Depending on your licensing since you made the image off of the original is may be that you don't have enough sysprep rearms. It's far fetched but I have seen it affect others.
Just some thoughts.
1 of 1 people found this helpful
From your screenshot, your Install Agent Action is what is failing (please correct me if you are seeing something else go on). Often times during provisioning we see issues where configured images (applications installed etc) this is done using software distribution to the image, which makes use of an LDMS agent. If your image already has an Agent on it (when you captured it) this can cause conflicts during the install of a new agent (usually results in a 1603 error). If your image has an existing agent on it, you can try using the uninstaller with /forceclean to remove it. This document covers the steps:
It would also be worth while to get the logs from your provisioning attempt so we can see what is actually failing. If your machine is in WinPE, check for them at X:\Ldprovision. If your machine is in Windows (not WinPE), check for the logs at C:\Ldprovision. If this directory does not exist, please open your Provisioning template to edit, click on 'Options' on the left hand column, and uncheck 'Remove client provisioning folder'. Next run the provisioning task again and the ldprovision directory should be created and remain after the test.
Some docs that might be helpful:
Sorry for the delay in getting back to you all. Its been a bit of busy few weeks.
In the end I just ended up building the image from scratch again and it now seems to work.
However, I have a feeling that nick.evans probably had the correct answer and that was that the image had at one point had the Landesk previously installed. I wonder whether it had left something behind and this was causing the problem.