anyweb

no, as that will happen too late in the process, ie it will have already failed at that point, so we have to do it this way

Introduction I've been thinking about doing something with this issue for some time now and finally got around to implementing it, however credit where credit is due I've based this on a method developed by a colleague of mine (Magnus Mourujärvi) to work with a 3rd party's custom boot wims. Basically that method is a registry hack which takes place in the boot wim. Problem We've all seen this happening, you get new hardware, you PXE boot, it pulls down the boot wim but as you don't have network drivers in your boot wim the task sequence won't run, or worse it just reboots without telling you why. checking the SMSTSLog will give you clues as to the problem... Troubleshooting it further would involve doing some clever use of wbemtest to find out what the network card pnp device id is in order to identify what the right driver is to be added into your boot wim. It was this process that I wanted to simplify, making it easy to identify the problem and the helping the user identify the Network card in question. Solution Add two files to your boot wim, update them to the distribution points and sit back and watch the show. Well ok, not quite that easy, there are some steps to do, documented below. Step 1. Get the script Note: there is a newer version of the script here which also checks for SATA connections (storage) Download the CheckForNetwork.vbs script here. Yeah it's a vbs, if I get time I'll convert it to PowerShell. CheckForNetwork.zip Extract it to C:\Temp In the script locate the ServersToPing array and edit it to match one or more servers you want to ping in your address, and save the script. Step 2. Copy a file from the MDT 2013 Toolkit Locate your MDT Toolkit files package and browse to the folder matching the architecture of the boot image you intend to edit, for example if you plan on editing the x64 boot wim then use a path similar to below: \\sccm\d$\sources\os\MDT 2013\Toolkit\Tools\x64 Locate a file called windowhide.exe and copy it to C:\Temp Step 3. Create some temp folders On the C:\ of your chosen server, create the following folder structure C:\Mount C:\WinPEMount\ C:\WinPEMount\X64 C:\WinPEMount\X86 Step 4. Make a copy of your boot wim Identify your target boot wim in the Configuration Manager console as shown below, this will be the boot wim we are going to make changes to... Right click the boot wim and select the data source folder, make a note of the Image Path Make a backup copy of the boot wim (ctrl+c and then ctrl+v) and then copy the boot.wim file (or WinPE.wim if it's a MDT created boot wim) to C:\Mount as shown below. Step 5. Mount the boot wim and make some changes Using Run as Administrator, start the Deployment Imaging and Tools Environment cmd prompt as shown below In the CMD Prompt that opens, mount the boot wim by issuing the following command: dism /mount-wim /wimfile:c:\mount\boot.wim /index:1 /mountdir:c:\winpemount\x64 Tip: In the above command i'm mounting a Configuration Manager boot image called boot.wim, if this was a MDT Created boot image it would be named WinPE.wim. Now that the boot image is mounted, we can make our modifications. First we will edit a registry key but to do that, we need to mount it. Using REG.exe mount the SYSTEM hive of the mounted boot wim REG.EXE load HKEY_LOCAL_MACHINE\Mount\ "C:\WinPEMount\X64\Windows\System32\Config\SYSTEM" Once done, change the current value for CmdLine in the mounted registry hive to run our script instead reg add "HKEY_LOCAL_MACHINE\Mount\Setup" /v CmdLine /t REG_SZ /d "cscript.exe CheckForNetwork.vbs" /f Next we commit those changes to the mounted registry REG.EXE unload HKEY_LOCAL_MACHINE\Mount and now we copy two files from C:\Temp to C:\WinPEMount\X64\Windows\System32 (assuming you are editing the x64 boot image) copy c:\temp\CheckForNetwork.vbs c:\WinPEMount\x64\Windows\System32 copy c:\temp\windowhide.exe c:\WinPEMount\x64\Windows\System32 Now that we've made our changes, we want to commit them to the boot wim (write the changes) dism /unmount-wim /mountdir:c:\WinpeMount\X64 /commit as shown below Step 6. Copy the modified boot wim back to the Image Path in Step 4. Now that we've made the changes we need, copy the modified boot wim from C:\Mount back to it's original location Step 7. Update your boot image to the distribution points In the Configuration Manager console, locate your boot image, right click and update it to the distribution points as shown below Once done you are ready to test the new functionality in the boot image. Step 8. Review the changes If the network works ok in WinPE, the task sequence will load as normal and you won't see any popup, or notice anything other than an additional 12 seconds added to your boot time. However, in the event that you have no network and cannot ping any server in the array of server IP's listed in the script, you will see the following warning popup after WinPE starts (before the PXE password and before a task sequence is selected). Note: The script try's to hide Wireless nics from being displayed in the results as we don't use wireless nics for OSD, yet. As you can see from the message it provides the following info a reason for the popup (no network connectivity) lists the detected Network Card lists the PNP Device ID identifies the Computer model and gives the user some options click YES to retry (for example if the network cable was not connected) click CANCEL to open a CMD prompt if further troubleshooting is needed click OK to reboot. Below you can see what happens when the user clicks on Cancel well that's it ! have fun :-) cheers niall

well if you are getting iis 500 errors in the webservice then make sure web.config is allowed to POST and that UUID = correct value and you were...

correct, however you'll want to customize it sooner or later (think security, updates...)

the mulitlanguage step is suitable for cases where you are enabling bitlocker via a script as the supplied script from microsoft crashes if the language is not english.

glad you got it working, what was the issue then seeing as others may also have that issue, the UEFI version handles refreshes to UEFI as well as legacy hardware, so it's more future resiliant, plus it has the new HTA design..

the idea is that you use this process to make changes to the standard wim, by introducing updates for example or installing apps, so the end result (the captured wim) contains not only the original operating system, but all the latest windows updates and a few key applications like office 2013 or similar...

Gabe Aul tweeted the following today those updates I've linked below:- https://support.microsoft.com/kb/3039066 http://support.microsoft.com/kb/3044132 http://support.microsoft.com/kb/3032359 http://support.microsoft.com/kb/890830 so at least Microsoft is still securing Windows 10 build 9926 and hopefully this in preparation for the new build we are all waiting for, although in addition to the above, he referred to the Windows blog here which goes into detail about the cadence of Windows Builds (or to you and me, why we aren't seeing a new build just yet...) here's a snip about announcing the date (or not...) If we announce a date, we’ll want to have a very high confidence of hitting it. It’s frustrating for you to hear a date and be let down if we miss it, and it’s frustrating and distracting for us too. Not only that, but it slows down our engineering since many of the same people who are scrambling after a missed date would otherwise have been making more forward progress on the product. Because we’d want that very high confidence we’d pick a date that was further out than if we were living on the edge. We’d give ourselves some time to deal with bugs and re-spin builds if we needed to. If we have a great build in hand, as often happens, leading up to the date we would hold on that build rather than ship it. We call this putting the build in ‘escrow’. Why not just ship it early? Well, some people get upset about the surprise, but also it sets expectations that sometimes we really mean a date and sometimes we don’t. We want people to know that when we say a date they can count on that date. In the worst case, if we’re chasing down a tough bug and run out of time, we may miss the date. This is of course way worse than being early. We’d have let down people who were counting on us to deliver on the date we said we would. so, let's keep waiting and updating until then ! cheers niall

did you update your boot wim to the dp's AFTER you added the optional components ?

the nic drivers need to be added to your x64 boot wim and then updated to WDS, examine the powershell script I wrote and you'll see how it's done, or manually do it yourself. did you update the deployment share and replace the x64 boot wim in WDS with the new one ? you can find the PowerShell script here. http://www.windows-noob.com/forums/index.php?/forum/74-mdt/

look for anything like computername in the js (validation.js)

great ! for the benefit of others finding this post perhaps you'd care to share what you went with

well if you truly want zero touch the first thing you'll want to do is create some collections to deploy the required task sequences to, as only one required (mandatory) task sequence can be deployed to a collection at a time secondly, only add computers to those collections if you are absolutely sure they will be reimaged as designed as there's no going back once they receive the policy, for the different scenarios listed above, one will need usmt capture/restore steps, the other will not, in other words, two separate task sequences to cover the different scenarios

it should, what name are you entering in that field ? can you share your smsts.log files so I can take a look

open a cmd prompt at the HTA and cd to the folder where the scripts for contacting the webserver are located then, execute the cmdline to run the ChangeComputerName.wsf script to do the computernaming, the first time you try it don't include any parameters, what output do you see ? next time you run it include the parameters it expects, what output do you see ? to add more logging in cmtrace (make sure it's open with the ChangeComputerName.log in view) then execute the script in debug mode like so ChangeComputerName.wsf /debug:true this should reveal the source of your issues but for a pointer, from you error above it's not finding the prefix as you are either calling the wrong URL or the parameters speficied are not correct, which could be true as the webservice you show in your screenshot has different parameter names to the one in your customsettings.ini

yes it's normal two places and only if needed in the boot wim in the winpe portion of the OS start windows deployment services (the gui) and see if the service is started or not and where it refers to

you could try disabling the install language pack sections and see what happens, to add an ou selection you'll have to code something yourself, it's not that hard and others have asked about that already here diffuser is depreceated in Windows 8 and onwards, see my previous HTA releases for the steps to add it back, good luck

nope this takes care of it all

can you explain what you mean here.... do you mean that was the time displayed in Windows ? are you set to sync with internet time or do you have ntp servers configured ?

well i think you should call microsoft and alert them to this, I haven't heard of others with the same exact issue, and can you confirm that you are only seeing the issue when there is NO battery power left.

were all three bought at the same time ? have you contacted Microsoft about the issue ? it sounds to me like the battery is running out of power and that it's reverting the date/time to when the device was manufactured

ok well the next time you have this issue do as follows, PXE boot or USB boot the device and press f8, type date and verify the date, do the same for time, what date/time does it revert to on all 3 devices ? is it the same or is it way off,

definetly a weird issue and from my time looking at it i couldn't figure it out, the logs look ok, the status looks ok, so perhaps you are missing a hotfix, have you tried applying cu4 yet ?

and have you verified that the machine built is using the actual updated wim and not the previous un-updated wim ?

glad to hear it's working the way it should Alan !