Task Sequences Fail After Upgrading to MDT 2013 U1

Update – Michael Niehaus took an interest in my problem and was able to reproduce it in one specific scenario.
Here is his email explaining how he was able to reproduce the problem:

---

I tried it and it worked fine. But I didn’t give up like most auto mechanics do J
So I was able to reproduce the error in one specific scenario:
· Create a task sequence through the MDT wizard, specifying an admin password (saved as plaintext in the Unattend.xml).
· Edit the Unattend.xml and save it (you don’t need to change anything, just save).
· Deploy with either the admin password wizard pane enabled (SkipAdminPassword=NO) or a non-blank AdminPassword variable value (specified in CustomSettings.ini, database, etc.).

In this particular case, MDT injects the value of AdminPassword into the Unattend.xml but doesn’t reset the plaintext value. Definitely a bug.

Thanks,
-Michael

---

In this case I had done exactly that.  I had set an admin password when I created the task sequence through the wizard.  I also edited the unattained.xml file.  And finally, I had an admin password specified in the [Default] section of my CustomSettings.ini.  So, I managed to find the one way to shoot myself in the foot with this.

---

---

Stumbled onto an issue yesterday after upgrading my MDT 2013 deployment share to MDT 2013 Update 1.  My existing task sequences would fail during OOBE.

Windows could not parse or process unattend answer file [C:\windows\Panther\unattent.xml] for pass [oobeSystem]. The settings specified in the answer file cannot be applied. The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup].

If I created a brand new task sequence and modified nothing it would work perfectly.

So I compared my original Unattend.xml with the factory default one to look for differences in oobeSystem.  The only difference was that in my original XML the passwords for the Administrator account and the autologin account were not in plain text while the factory XML was.

My original XML is on the left while the factory default is on the right.

I used the Windows System Image Manager, triggered by editing the XML through the MDT console, to modify the “ProtectYourPC” setting and turn off auto updates.  That was the only setting I modified and never touched the passwords.  My guess is that WSIM set the passwords to be encrypted by default.

[Updated]
I took my original XML and using Notepad replaced the password sections and left the ProtectYourPC setting untouched.  Ran a test build with it and it completed successfully.

Advertisement

Windows 10 Build 10041 Upgrade Failures

[Updated:  After enabling Client Hyper-V on 10041 the machine blue screens on boot up!]

[Update 2: After much trial an error I have narrowed my upgrade problem to Hyper-V.  If that is enabled on 9926 then the upgrade to 10041 fails for me.  So what ever changed with Hyper-V between 9926 and 10041 is the root of the problem.]

I have had quite a difficult time moving from Windows 10 Build 9926 to Build 10041. Prior build updates didn’t give me this much grief.

My system was a pretty simple setup. Hardware-wise it’s an older AMD A8 with 24GB of memory. I have a single 120GB SSD as the boot drive, a pair of 240GB SSDs in a Storage Spaces pool and a single 1TB HDD. On the software side it’s just Windows 10 (9926), Office 2013 and Client Hyper-V.

I had my machine in the Fast Ring so back on 18 March I ran the upgrade to 10041 and it failed.

Video Driver Problem?

Some searching lead to people getting this error when upgrading from Windows 8 to 8.1 and it being caused by Nvidia video card drivers. I do have an Nvidia video card, but it was using the built-in driver from build 9926. But I thought I would give it a shot and upgrade the drivers to the latest direct from Nvidia.

No luck. Still failed with the same error.

Moving to Slow Ring

I rebuilt my system with 9926 and switched to the Slow Ring. I wanted to buy some time to see about finding anything on the errors before attempting to upgrade again.

This time I only had Client Hyper-V and the Storage Spaces pool. I was focused on spinning up some VMs to test the upgrade.

Then on 25 March Build 10041 went out to the Slow Ring and my system ran the upgrade.

And failed with the exact same error.

Starting All Over

At this point I thought I would start over with a clean slate. So I rebuilt my system with 9926. This time I didn’t install Office and Hyper-V, nor did I configure the Storage Spaces. So all I had was a basic install of 9926 and nothing else.

The time the upgrade worked.

So, what was the culprit?

I don’t know. Client Hyper-V? Storage Spaces? I honestly could not say. I may try to rebuild back with 9926 and try the upgrade with one or the other.  Maybe I can narrow it down to a single thing that did me in.

Regardless, it doesn’t bode well if a Windows upgrade could not handle features that are native to Windows.

Learn from my Mistakes – SCCM 2012: Importing Computers and Limiting Collections

This is probably one of those “Duh” moments that we all have but I thought I’d share it anyway.

I was getting frustrated when I was importing the MAC address of a new, out of the box computer into SCCM 2012 to be used to test my latest development build.  I had a testing collection used solely for testing this new build.  I’d import the computer and have the wizard place it into my testing collection, but it would never show up.  I’d search All Systems and it would be there, so I know the import worked.  I tried importing using a CSV.  I tried adding the resource manually.  I tried adding the object to the collection using a query.  Nothing worked.  No mater what I tried the imported computer would not appear in my test collection.

Then I noticed that my test collection was limited to a custom collection we have set up for only Windows 7 computers.  I could only chuckle and laugh at myself for missing that in the first place.

So, what happened?

When you import a computer into SCCM it is added to the All Systems collection.  That’s why when I searched All Systems I could find my imported machine.  If, while going through the Import Computer wizard you specify a collection to add it to SCCM will create a direct membership rule for your newly imported computer account.

Where things went off the tracks for me was that my test collection was limited to that Windows 7 custom collection.  That collection was, for the record, built using a query that looks at the OS info returned from Hardware Inventory.  Since my imported computer had never reported inventory the query to scoop it up would pass right over it.  So it only sat in All Systems, and since my test collection was not looking at All Systems it would never find it.  No matter what I wanted.

Morale of the story?

If you’re going to be using a test collection for something like build testing, be sure that it is limited to the All Systems collection if you’re going to be importing new, out of the box computers for testing.