TCP/IP stack reset to default value Windows 10

I encountered a strange issue with windows 10 not connecting to wired or wireless networks and based on the description from the user had them send their laptop in for further review.  Each adapter was in an identifying state and I later learned at a 169.245.x.x IP address.  At first, I assumed hardware issues as both the wireless and wired adapter weren’t working (although I guess they would be on separate chips?).  I suppose if I had given it more thought I might have thought what do both share…the TCP/IP stack.  And that was exactly what I needed to do to fix it.  So just in case someone is struggling with this issue follow the below.  I can’t take credit for this fix though as I found the answer at http://www.sysprobs.com/fixed-windows-10-limited-connectivity-not-getting-ip-from-dhcp.

  1. Run command prompt as administrator.
  2. netsh winsock reset catalog
    netsh int ipv4 reset reset.log
  3. Restart PC

MDT UDI Wizard won’t update

Well I finally got a good image of Windows 10 with my custom settings yesterday so now it was on to iron out my deploy task sequence for SCCM integrated with MDT 2013.  I was working on getting my existing UDIWizard_Config.xml files from my MDT 2013 toolkit files for Windows 10 to work with MDT 2013 Update 2.  Why create an entire new file when you can simply reuse my wizard settings as I have a lot of custom settings for OU’s and such.  It seemed that no matter what I did it held onto the old settings and wouldn’t update.  Finally through a mention in a technet forum I discovered that the applications in the install programs page in the wizard caused it to fail and use the old UDIWizard_Config.xml from before.  So I simply deleted all my software in the wizard and re-validated the site settings with configuration manager and then went in and clicked update distribution points.  Eureka, upon pxe booting all my new settings were there. Goes to show what I get for reusing UDI Wizard settings.  So yes you can reuse your UDI wizard settings from previous MDT Versions but proceed with caution.

snip_20160524102205

Windows PE initialization fails with error code 0x80220014

I’ve continued to fight a bunch of issues trying to get imaging to work the way I want it in SCCM 1511/1602.  Well another issue I was running into was when capturing from an SCCM capture disc I would get Windows PE initialization failed with error code 0x80220014.  Well what I discovered is this Microsoft Hotfix fixes the issue and is still an issue in SCCM Current Branch 1602.

 

snip_20160523163222

I have been integrating MDT with SCCM for a long time and followed the below steps from Microsoft to fix the initializing issue when capturing using my MDT boot image. Below are the steps from Microsoft with a few notes and changes on how to do this with an existing MDT Boot image This must be done on a machine with Windows ADK for Windows 10 is installed.

Step 1: Preparation

  1. Extract the contents of the hotfix. For example, extract the contents to the %userprofile%\downloads folder.
  2. Start an elevated “Deployment and Imaging Tools Environment” command prompt.

snip_20160523154044

Step 2: Prepare Windows PE

Create the Windows PE customization working directory, and then mount the image file. To do this, type the following commands, and then press Enter after each command:


dism /mount-wim /wimfile:”E:\Sources\Imaging\OS\MDT Boot images\MDT Boot image W10 64bit SP2\Winpe.wim” /index:1 /mountdir:E:\mount

Note: Point the /wimfile parameter to the winpe.wim you have been using that is having the boot problem.  There will be an second WinPE.packagenumber.wim that SCCM creates from the winpe.wim.  Leave it alone it will get updated when we update the distribution points.  For the /mountdir parameter just create an folder somewhere as the mount directory, here I just created an mount folder at the root of E.

Step 3: Save schema.dat state

Back up the permissions that are applied to the existing schema.dat file before you replace it. To back up the file, type the following command, and then press Enter:

icacls E:\mount\Windows\System32\schema.dat /save “%temp%\AclFile”

 

Step 4: Update the schema.dat file

To replace the schema.dat file that has the updated version, you must take ownership of the file and grant permissions to the local administrators group. To do this, type the following commands, and then press Enter after each command:

takeown /F E:\mount\Windows\System32\schema.dat /A

icacls E:\mount\Windows\System32\schema.dat /grant BUILTIN\Administrators:(F)

xcopy “%userprofile%\Downloads\schema-x64.dat” E:\mount\Windows\System32\schema.dat /Y

Note: the Xcopy is assuming you extracted the hotfix in the downloads folder.

Step 5: Reset permissions and ownership

When the schema.dat file is replaced, the permissions saved in step 5 must be restored by running the following commands:

icacls E:\mount\Windows\System32\schema.dat /setowner “NT SERVICE\TrustedInstaller”

icacls E:\mount\Windows\System32\ /restore “%temp%\AclFile”

 

Step 6: Commit Windows PE changes

Commit the changes to the winpe.wim file. To do this, type the following command, and then press Enter:

dism /unmount-wim /mountdir:E:\mount /Commit

Step 7: Update Distribution points

Click update distribution points on the MDT boot image and then wait for drivers to be injected into your fixed boot image.

snip_20160523155257

Step 8: Recreate capture media

If your doing this like me and using capture media make sure and recreate it so it uses your new boot image.

How Candy Crush can break your Windows 10 image capture

I’ve been struggling to get SCCM 1602 and imaging of windows 10 to play nice and the below is one of the latest issues I’ve encountered.  If your running Windows 10 build 1511 and try to capture you might encounter error code 0x00004005.  One of the possible causes can be all the Appx packages (Candy Crush and Twitter etc.) Microsoft decided to install even in Enterprise edition (that one I don’t understand I could see home even pro but enterprise?).  As was pointed out in this technet article running a Get-AppxPackage -AllUsers | Remove-AppxPackage remedies the issue before capture.