As a test, I would run your template using the default unattend landesk includes. Make sure you can apply an unattend without error. If that works, then you can start modifying it and adding in the specifics you need for your implementation.
Some gotchas are to make sure your image does not already contain an unattend.xml. Also, make sure when your image was originally sysprepped that you did not specify an unattend at taht time. I recommend simply using generalize and OOBE when you sysprep.
Out of curiousity, what actions do you want your unattend to accomplish? Many functions such as joining the domain can be done with template actions and don't need to be done in the unattend.xml.
jaysmith thanks for the reply.
I just finished testing the deployment with the default unattend script from LANDesk and the unattend.xml script with the only change being the registered owner and company, did apply appropriately. In my tests I have captured the image two ways - with generalize and oobe and Audit generalize. Before I captured the image, I checked the c:\windows\panther folder and it looks like there are some files in there and one is an unattend.xml. Upon opening it, it has some what looks to be default values (not entirely sure where this came from or if it is even suppose to be there).
The primary items I'd like to do is set the local admin account password, bypass the eula and time settings, set the current network as work, and bypass the remaining system setup information that appears upon the oobe. Correct me if I am wrong, but isn't the xml file for Windows 10 Enterprise substantially different than the xml for Windows 7/8?
Below is the screen shot of my deploy template if you would like to see the outline.
There are some changes, several new items and some deprecated items as well. This article is my go-to to understand the changes:
When determining whether to apply any given unattend.xml file, the OS checks specific locations in order and applies the first unattend it finds. This doc explains the locations in order:
Considering you do already have an unattend in your image, I suggest adding a delete file action to your template to delete the existing unattend. This can go just prior to your inject script action. You may also want to add a wait action after your inject script action so you can open a cmd window and view the injected unattend.xml. You can make sure any public variables were successfully injected etc.
Thank you for the suggestions. Ends up, it didn't matter if I deleted the unattend.xml that was there or not- actually, according to the link you posted, Microsoft explicitly says don't mess with it. I have everything on the unattend.xml working except for setting the network location. Apparently with Windows 10, that part has been deprecated. Not entirely sure why but I guess I will need to whip up some powershell or other wizardry. Any suggestions? Once the network selection is made manually, the LD Agent fails to install immediately (both the standalone package via unc and http, and the package selection drop down menu), as if it doesn't even attempt. The logs were no help and I know it isn't related to the topic here, just thought I'd through it out there.
1 of 1 people found this helpful
I found out that if I leave the network location and discovery dialogue up, it will continue and I corrected a path issue for the agent install. All is working now. Thank you for your help! I will open up another thread for help with the task failing after a reboot action occurs.