OK, for anyone else who might be following this thread - it's the accepted wisdom that Windows 7 and Windows 8 unattend.xml files are the same... this might be true on some levels, but you'll probably find that if you used the unattend.xml file from these forums for your Windows 7 build and you just try and replace your Windows 7 product key with a Windows 8 one in the file, the build will work but Windows won't be activated.
If you use the Windows System Image Manager to try to edit a sample file and get the correct format, the Product Key part occurs in the WinPE pass of the file, which isn't present in the LANDesk style version from the BKM document.
So, what you need to do is put the Product Key part into the 'specialize' section at the end. I have attached a working XML file for Windows 8.1, I can't say that it's got everything you might need in there but it allows you to build a machine and get it activated so it's a place to begin - I'm still working on our image so there may be future changes needed for particular custom items or settings. There is no personal info in the file to change, it's all done by variables so you should just be able to import it as is.
To use it, you'll need to create the following LANDesk variables in OSD:
LocalAdminPass (Sensitive Data) - the local administrator pass you used in the initial image
RegisteredOwner (String) - the username to put as registered owner, for example 'IT Department'
RegisteredOrganisation (String) - the organisation to register to, i.e. 'My Company' - note I spelled this with an s as I'm English, change it in the XML if you prefer z
ldHostname (Database value) - this may be a default one, but if not mine is set to "Computer"."Display Name" (including the double quotes)
Win81ProdKey (String) - the product key, in the format XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
I've also attached a working provisioning template (basic) which uses this file, to use it you'll need the following variables (or replace with text):
imagetool (String) - UNC path to image tool (i.e \\servername\ldmain\osd\imagew 2)
adminuser (String) - admin username (i.e.domain\username - should have permission to join machines to AD)
adminpass (Sensitive Data) - admin user password
imageshare (String) - UNC path to image share (i.e. \\servername\images$)
Domain - domain name to join machine to (i.e. domain.whatever.com) - note mine has capital D, may or may not matter, not checked
There is a subfolder mentioned in the template too, so our images live on M:\Build\Live\IMAGE.TBI - edit this part to reflect your environment or duplicate the structure - note you need to change the command-line parameters manually, don't click 'Validate'.
At the moment, it boots to the Start Screen and some of the provisioning tasks are working in the background so you need to click on 'View Desktop' to see the GUI, there is a registry key for booting straight to Desktop but it's in HKCU so not got around to looking at that part yet - if you want to play it's:
- Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\
- Value: OpenAtLogon
- Value Type: Reg_DWORD
- Value Data: “0” Boots to the Desktop
- Value Data: “1” Boots to the Start Screen
Hope this helps someone, if you improve it or have any comments then please let me know!
Oh, and one more thing - don't put an agent install with AV into the template or it will just fail, AV is not supported yet - make another agent and untick the LANDesk AV box and it'll install fine.
1 of 1 people found this helpful
Thanks for the information. We are running LDMS 9.5 SP1. I've been testing 8.1 deployment with a copy of my Win7 unattend.xml file and so far that is working. I changed my Win8 master image to automatically boot to the desktop as well. We use KMS activation, so I am not providing a product key at all. So far, so good. Activations are working.
The problem that I have is that no Windows 8.1 drivers are being injected, even though I've added them to the driver database just like I did with Win7 drivers. I know that I will need to define a few .exe driver packages, but NONE of the .inf drivers are getting injected... very odd!
We are running HII in WinPE and after reboot into Windows... no joy. All other software deployments, agent config, etc. work with no problems. HII shows success as well.
Ah, not looked at the drivers yet - that's the next job! I will let you know if I come up with anything, if you beat me to it then please update this thread.
Just to confirm, we use volume license keys and we have MAK keys on this particular build so as slingblade says, KMS might work OK with the other xml.
How did you change the image to boot to desktop, just alter the default profile? Haven't had chance to dig on that one yet.
Yes, to boot directly to the desktop, I modify my administrator profile. Then, I use the copy profile entry in my unattend.xml file to copy my adminstrator profile as the default profile. So far, this works pretty well. This is the entry that I use in the last section <settings pass="specialize">
I'll keep you posted on my progress, I just don't want to hijack your thread.
For your basic deployment (ie, getting a Windows image down and injecting the unattend) there should be no difference between Windows 8.1 and any previous version. For HII I would suggest looking at this document:
Basically when the patch for 9.5 SP1 is released HII should then work with Windows 8.1. Until then you're right; HII is totally unaware that 8.1 even exists. Once it's released there should be nothing extra you need to do to make it work.
That article also points out that AV is not working in 8.1, as was mentioned in this discussion.
One other thing to note is that as of LDMS 9.5 there should be no reason to map a network drive to the image tool or the image share. Deploy image action will automatically do that for you using preferred server credentials. Your deployment template listed above should work just as well without those two steps.
Last thing is that unlike OSD the provisioning tool does not need you to log into Windows. My recommendation is that you don't do any autologin and just let provisioning run in the background without the machine being logged in. If you need it logged in for your process then that's great and you should do it. If the only reason you're doing it is because that's how it worked in OSD then I think there's no reason to do it and a lot of reasons not to.
Let me know if this helps clear anything up!
Thanks Mach6 - couple of bits though!
Firstly, the patch is already out and I have it installed, HII does have an option for Win 8.1 on my core. However, it doesn't actually work!
I think the reason it doesn't work properly is because my preferred server config isn't working, and I think that ties in with your last point - for me, that DIDN'T work and I had to map drives manually, but at the time I did not know that it was supposed to do it for you using preferred server config. I have another thread open regarding this, but I'm assuming that if preferred servers are broken, then auto drive mapping is broken, and HII is probably broken too.
Lastly, on the provisioning front - we like to have our provisioning to be visible because we only ever do it on the bench before giving machines to users, that way our techies can see when it has finished. Get your point though, in the real world it'd be neater not to do it that way.
Sounds like you are right. If you have preferred servers working then the rest of this should just work out automatically. One effect of preferred servers is that it gives us a credential store that we can go utilize to map network drives and things of that nature. By using that technology you can save a lot of time and effort on your provisioning templates.
If preferred servers aren't working then out deploy image action won't be able to auto-connect to the share and HII won't work.
Out of curiosity, if you put the same credentials you use in your template into the preferred server dialog does that work? You should just need to put in credentials that would allow you to map a drive, and apparently that one does it.
No, I still get 'UNC Authentication Failed' if I use the credentials from the provisioning template - I still get that error if I use a domain admin account too, so something else is definitely causing problems somewhere. As you said, HII isn't working but neither is package deployment in the provisioning template, so I'm a bit stuck.
I'm sharing some issues I had during our migration to 9.50 SP1 provisioing - Hope they help
** Short version first **
1) We were on 9.0 SP3 and provisioned at 4 regional locations using OSP via preferred servers at each regional location. Win 7 and XP worked
2) We upgraded to 9.50 everything worked, however the "Deploy" task in OS provisioning failed to work so I had to use a "execute File" task to launch Imagew.exe, applying the parameters in the appropriate space below the command.
3) We upgraded (IN PLACE - which I will never do again) to SP1 and everything quit.
We had a number of things that we had to fix - Ignoring XP issues which we did correct and get working
a) We had issues in the image file down in the registry (this caused CTOS to fail) - FIXED
b) I had to delete the Drivers.db3 file and recreate it - something was amiss there
c) We had to DELETE all drivers that we added to PE and use the default drivers.
d) We had switched the unattend and had a 32 bit script instead of a 64 bit one (this had caused CTOS to fail) FIXED
Even after it was all fixed and working all I could deploy was the image file. If there were ANY SD tasks in the build it failed on all but one unit. If you ran one unit at a time it would work sometimes, but not every time.
After speaking to our TAM (BTW - GET A TAM!) we discovered others are having a problem with SD if they upgraded to 9.50 SP1. Engineering is working diligently to address this. We have to give them some time. Sadly for us we are in the midst of a Workstation refresh and prepping for an IPM (in place migration) of Win7 at some 200 plus branches...
(This is where having the TAM pays off - Our TAM is monitoring progress daily with the dev guys)
We continue to develop the basis of provisioning, but until this is addressed - OH we also had a problem that required a patch after SP1 - we feel it best to wait for our friends in Dev to give us the nod (and any patch/fix they come up with) before proceeding.
I managed to work out what was causing the 'UNC Authentication Failed' message - I was using a fully qualified domain name for the preferred server 'server name' field, and it didn't like this. If I change it to just 'servername' then it the tests pass. I will report back on whether I can get any further with HII.
I have had this be a problem, however we found it necessary toi use FQDN in our environment. That said we found that all worked out if the following took place:
1) CORENAME.TXT has FQDN for the core name
2) ALL.REG has FQDN for the core name
3) ALL.REG has an entry to add the DNS hosts to the PE
4) There is an entry for the core in the preferred server (under Content Replication)
5) The core preferred server is named using FQDN
6) All OS provisioning hosts (PXE Reps) are named as FQDN
7) The core preferred server has an IP entry of some address that you do not support (like 126.96.36.199)
Holler (Indiana speak for reply) back if you need info on what we did. This made a significant difference in our deployment success to all of our remote centers across the enterprise.