Wednesday, April 30, 2014

SCCM 2012 R2 "Machine does not meet OSD capture requirements. Capture cannot continue."

During a "Build and Capture" task sequence you may run into this error. I ran into this error a few times before and I always had to refer back to my older task sequences to figure it out. It's a very simple fix, but I seem to overlook it every time. You will see this in your SMSTS.log:

This means that the computer is a part of a domain. You can't capture a machine if it's part of a domain. My task sequence was like this:

As you can see this is a very simple task sequence. It just captures my built machine and stores it on my distribution point. I don't like the "Build and Capture" style task sequence. This way offers me far more flexibility in my opinion. It's just far less automated.

To fix the issue you need to simply add a 'Join Domain or Workgroup' step before everything else. So your task sequence will look like this:

The next screenshot shows a successful join to the workgoup.

The next screenshot shows the part of the task sequence that failed before. You'll notice the line "Local Machine is not part of a domain." 

All done. A simple fix for a simple problem.

Thursday, April 24, 2014

Configuring WSUS for your clients.

Today I got a call from a friend that was setting up WSUS on Windows Server 2012. He got WSUS setup but the clients were not checking in. After talking on the phone with him for a bit he told me he had not set anything up on the client side yet. 

Here are the steps to setup your clients via GPO taken from

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Specify Intranet Microsoft update service location.
  3. Click Enabled and type the HTTP(S) URL of the same WSUS server in the Set the intranet update service for detecting updates box and in the Set the intranet statistics server box. For example, type http(s)://servername in both boxes.
  4. Click OK.
This is great in most cases, but to my knowledge WSUS in Windows Server 2003 - 2008 R2 use port 80 as the default port for WSUS synchronization. WSUS in Windows Server 2012 the default port is 8530 and 8531 for SSL.

  • On WSUS 3.2 and earlier, port 80 for HTTP and 443 for HTTPS
  • On WSUS 6.2 and later (at least Windows Server 2012), port 8530 for HTTP and 8531 for HTTPS

 So to make the adjustment you must specify the port in the TechNet step 3 to look like this http(s)://servername:port

After this you can perform a wuauclt.exe /detectnow on the client machine to detect the WSUS server and start reporting. The process can take 10 minutes or more. Sometimes a simple reboot on the client will force a detection.

After my friend made the appropriate changes (adding the port number in the GPO) and rebooted the client, the computers started reporting.

Optiplex 380 STOP Error: NMI Parity Check/Memory Parity Error

I received a support ticket today from one of our schools saying they had a strange error coming up. I asked the usual questions like did you reboot, what color is the screen, etc. She said it was the BSOD, but it looked different. After going to take a look at the machine I saw the error and I hard rebooted the machine. I came to see this error:

At first thought I figured this was a memory error, but it was not. After I removed each stick of RAM one-by-one the error persisted. After a bit of Googling I ran across this article.

This says it's a NIC issue and you can fix it by uninstalling the old driver and reinstalling. This, however, was not the case. The NIC was failing at POST, far too soon for a driver to be the issue. I also updated the BIOS to A07. (Was on A01) This did nothing as well.

I resolved the issue by adding a NIC into the machine and completely disabling the onboard NIC.

Tuesday, April 22, 2014

SCCM 2012 / ADK Use Loadstate Manually

In the past posts I have explained how to create a task sequence to update / refresh computers to Windows 7 from Windows XP.  Most of the time this all works fine and I can just sit back and watch as the computers refresh themselves. Sometimes, though, that is not always the case as I will explain.

Sometimes my task sequences will fail at the 'Restore User Files and Settings' group. It usually happens on laptops. From what I have seen it's because the laptops have went into hibernation, powered down, or have lost network connectivity at this step.

What this means is that the State Store has been saved to the State Migration Point, but the data is encrypted and you can't really do anything with it. You have a bare metal Windows 7 install with no user data. I've read a few ways to accomplish retrieving your data from the State Store, and I'll cover them here.

  • Use MigRecover found here. This method did not work for me at all. I tried both versions to no avail.
  • Use Windows 7 Easy Transfer. This method should work, but I kept receiving errors that WET couldn't open the file. (USMT.MIG) this is after I supplied the User state recovery key. 
  • Just launch the USMT.mig file from the State Store. This launches Windows 7 Easy Transfer. This route did not work either.
  • The fourth and final solution is what worked for me. I used the Windows 8 USMT (ADK 8) not Windows 8.1 USMT (ADK 8.1).

  1. I copied the "User State Migration Tool" folder from C:\Program Files (x86)\Windows Kits\<version>\Assessment and Deployment Kit from my SCCM server to the client computer I'm restoring.
  2. I opened a command prompt and navigated to where I copied the folder.
  3. I opened a SCCM console and navigated to Assets and Compliance -> User State Migration.
  4. I found the computer that I am looking to restore, highlighted it, and clicked View Recovery Information on the Home toolbar.
  5. I copied the User state store location to a text file to I could copy/paste later.
  6. I copied the User state recovery key to a separate .txt file so I could import into the command we'll use in a moment.
  7. Copy both text files over to the computer you're restoring. I copied mine into the USMT folder that we copied over in Step 1. This made it easier to reference at the command prompt.
The final step is to use loadstate.exe to import the data to the computer you're restoring. The command to do this is: (from the command prompt you started on  the computer you're restoring in Step 1)

loadstate.exe <storePath> /decrypt /keyfile:<keyfile> /i:miguser.xml /v:5

Your computer will start copying over all the profiles that are stored in the State Store. (controlled by the /i switch)

storePath is the path that you saved in the text file and copied to the restoring machine in Step 7. keyfile is the file that contains the User State Recovery Key. Loadstate will read the key from this file. The /i  switch indicates the .xml configuration file that you'd like to use to load the profiles onto the computer. I used miguser.xml when I saved the state so I used it to restore the state. /v is the verbosity level you want for the output. Use loadstate /?  for more options you may use.

Below is a screen shot of the recovery information window.

Thursday, April 17, 2014

Windows XP Endpoint Protection April 16 2014 Definition update issue

I came in to work today to a plethora of phone calls from people saying that their computers had crashed. After digging a bit into the issue I noticed the only machines that were affected were Windows XP machines. I noticed that the MsMPEng.exe process had crashed on startup and would keep throwing errors. 
I traced this down to System Center Endpoint Protection and did some digging. I found this link:
This shows that the latest Endpoint definition update causes an error that crashes the scanning engine of Endpoint. I disabled the update so further machines wouldn't be affected.  I made the suggested changes that the above article recommended, but on some machines the damage had already been done.
My remedy for the affected machines was to uninstall SCEP, reboot the machine, and reinstall.  Since there is a cached version of SCEP stored on each computer that has the CCM client installed, you can access the installer easily. The path is c:\windows\ccmsetup\scepinstall.exe
Now we wait on a fix from Microsoft. 

Tuesday, April 15, 2014

SCCM 2012 USMT (Request State Store) Max Client Error E_SMPERROR_MAX_CLIENT_LIMIT

I've came across this error a couple of times now. If you're receiving this error you will see it 3-4 times in your SMSTS.log file before your task sequence will fail. Giving you a generic task sequence error. Unless you look in the SMSTS.log you will not see this error. After looking through my settings on my State Migration Point, I noticed that I had only 15 clients with Complete/In-Progress status. Well that should be fine as I have set my client max to 50.

The catch is the days I had set to retain my migration data. This was set to 30 days. This is pretty high , I know. I had it set this high because the is a new rollout and I didn't want to lose anyone's data. I wanted to have plenty of time to recover it if I needed to.

So even though my clients max was set to 50 and the SCCM console was only showing 15 Completed/In-progress. My Migration Point had the meta data for over 100 still stored. This was caused by me just deleting associations out of the console and not deleting the actual data. (Or allowing SCCM to do so) Rookie mistake.

To resolve the error I deleted the oldest 30 or so records from the Migration Point (the actual data, not the associations), and the OSD task sequence took off as intended.

Afterwards I adjusted my retention period to 10 days since I have the task sequence pretty much how I want it for now. Below is a screen shot.

Thursday, April 3, 2014

802.1x explained-- In my words.

A typical wireless network is setup something like this: You have to have a super secret key (or not) to join someone's WIFI network. If you have the key, you have access -- that simple. It's called WEP-PSK or WPA-PSK (pre-shared key). Say you want only the people inside your organization to be able to join the network and do not want to use a PSK. Since they're always leaked to everyone and their distant family. The answer is 802.1x. In this setup you specify which computers/users have access and they have to have an authorized account to join. So if you have a user account you can join any device to the network. Let's take it a bit further and say you want all of your users to have access, but only with equipment that your organization has issued them. The answer is still 802.1x, but with certificates. I give device X a certificate and that computer can join the network. After the join the user authenticates with our servers (not the WIFI). Now some random WIFI enabled client can't jump on our network unless he's part of our organization or I give them a certificate.

The reason why this is important besides security is this: At our high school we have 3 COWs (Computer On Wheels). We've had this problem to where if you're not on the network you cannot login. Well you cannot get on the network without logging in. See the problem here? So if you set it up so the computer authenticates without need for user interaction the user can successfully login without the need to authenticate with the server because the computer authenticates (as itself).

Presto! The computers are joined to the WIFI prior to users logging in. Allowing them to authenticate successfully without having to do anything.

This seems obvious, but it was a problem I've been having for quite sometime and I completely overlooked it.

A future post will be coming to show how I accomplished this.

SCCM 2012 R2 Windows XP refresh to Windows 7 Part 2

Part 2 of my post of how I made our transition to Windows 7 from XP please read my previous post or this one won't make much sense.

So we've created a task sequence and most of the pieces are in place for the successful deployment of Windows 7. However in my case I needed to deploy to laptops that only had WIFI access. In all the forums I read everyone says just don't do it. Well-- I'm going to do it. I have the bandwidth available and I don't want to have to touch every single computer to plug them up and image them.

So my task sequence looks something like this:


The first thing I had to do was to make sure all the content I needed was downloaded to the machine prior to the task sequence starting. This is a simple option to select when you deploy the task sequence under the Distribution page (or tab) select "Download all content locally before starting task sequence" from the drop down menu. This will ensure the image, boot image, driver packages, applications, etc will be downloaded to the cache on the computer before your sequence starts. This was required for as I stated in the previous post that WinPE3.1 did not contain the drivers I needed. I did not want to service WinPE offline to insert each driver individually. This got around that for the time being.

Now that you've selected the option to download the content locally -- depending on the size of the image, applications, and driver packages you'll need to increase the cache size from the default of 5100~mb. I increased mine to 10GB. Here is a script that I invoke to do just that.

On Error Resume Next
' Declare Variables
Dim checkCacheValue
Dim setCacheValue
' Set the Cache Size to check for (less than or equal to)
checkCacheValue = 6500
' If less than or equal to the checkCacheValue
' set the Cache Size to this
setCacheValue= 10000
Dim oUIResourceMgr
Dim oCache
Set oUIResourceMgr = CreateObject("UIResource.UIResourceMgr")
Set oCacheInfo = oUIResourceMgr.GetCacheInfo
' Set it if it's less than or equal to checkCacheValue
if oCacheInfo.TotalSize <= checkCacheValue then
oCacheInfo.TotalSize = setCacheValue
end if
'Return the error so SMS can report it

Copy this into a .vbs script and save it on a server that is accessible from the computer being imaged. I have a share that's readable by 'Everyone' in my domain.

I won't go into how to invoke that (command line step) If needed I will add it later. I will be focusing on required steps and details therein.

The next big one that kept causing my task sequence to fail is the "Set OSDisk Variable" step. This is only required in refreshes not bare metal installs. If you do not set this variable it will fail every time at the "Apply Operating System" step. This is to tell the Task Sequence which volume to apply the image.

So add a step "Task Sequence Variable" -> Name OSDisk -> Value C:

Everything down to the Apply Device Drivers step is default after creating a basic deploy task sequence. Here is where I had to get creative.

Since I wanted to deploy to laptops this step would always fail because it could not contact the MP to get a list of required drivers. So I customized this step to "continue on error" in the options tab. Fair enough. So I added the group: "Driver Install" within this group

 I added the option "Task Sequence Variable" - > Variable: _SMSTSLastActionSucceeded -> Value: False

If the Apply Device Drivers step failed then my custom group would fire applying specific driver packages that I needed. This part was a bit time consuming, but seems to work 100% of the time. I haven't seen a time yet that it has failed. You basically want to create and apply a driver package per model that is detected like so. For each step add a Apple Driver Package command. Name it appropriately and click browse to find the driver package that I hope you created earlier. then goto the options tab:

Add WMI query -> Default Namespace -> WQL Query -> SELECT * FROM Win32_ComputerSystem WHERE Model LIKE '%5400%'

(5400) will be specific to the laptop model you need. Here it's a Dell Latitude E5400. You will want to add a step for each laptop model you need.

Next step is Setup Operating System: This one I learned a few things. First off is the Setup Windows and ConfigMgr step is the step that actually joins the computer to the domain. The 'Apply Network Settings' step actually just adds the settings to the unattend.xml file to be applied here. So my dilemma was that even though the drivers were now installed for the laptop it needed a reboot for them to be applied by Windows. I know the Setup Windows and ConfigMgr step rebooted and applied the drivers, but joining it to the domain would fail 1. Because the drivers aren't applied yet. 2. Because if it's a laptop it's not joined to any networks yet. So I added the Setup Wireless group.

I set this group to only trigger if the computer was a laptop. I do not have MDT integration so the task sequence variable isLaptop is not available (to my knowledge). I had to use another WMI query.

In the default namespace I added this query: SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = '2'

This query is only valid if the system is a laptop. I had to add this option because the next steps would fail on a desktop causing the whole task sequence to fail.

Next step is Add Profile SSID I used a command line step here to apply a wifi profile that I had saved into the image I was applying. (Creating WIFI Profiles is outside the scope of this post, I'll add it later) The command is this:

cmd.exe /C netsh wlan add profile c:\WifiProfiles\WIFI-Profile.xml user=all

This command will add the profile to connect to the SSID that I need. The next step will connect to that network if it hasn't done so already.

cmd.exe /C netsh wlan connect name=<Your SSID>

*NOTE Both of these WILL fail if you do not use the above query to confirm the device is a laptop.

After this I use a simple Join Domain step to join the computer to the domain.

Steps after this are not in the scope of this post so I'll leave it be for another time. Now when a computer running Windows XP is a laptop or desktop they will successfully image whether they're wireless or not.

I hope this helps someone else out. It took me about a week to gather all this data and make it work for me. I learned just because everyone says don't do it doesn't mean it can't be or shouldn't be done.

SCCM 2012 R2 Windows XP refresh to Windows 7

As the deadline for the End of Life of Windows XP approaches I was tasked with the job to make the upgrade to Windows 7  happen in the simplest manner possible. Here is my story.

My first objective was how:

1. You could make two task sequences. One to capture user data and the second to deploy the OS and restore the data. This made no sense to me so I didn't go this route. I mean there had to be a better way.

2. You could make one task sequence that captured the user data deployed the OS and restored the data all in one sequence. This is a completely unattended approach and that's the way I like it.

You need a few things to get started.

1. You need Windows AIK for Windows 7 and the supplement which can be found at the following links.
Windows 7 AIK
Windows 7 AIK Supplement

*Later on you'll need the Windows 8 AIK as well. The links are referenced below.*

This will provide you with the versions of WinPE (Version 3.1) you'll need to complete this process. Installation instructions are on the download page from the links above.

I would follow this link if you would like to customize your WinPE boot image.

Find the boot image you created: C:\WinPE_<archType>\ISO\sources\boot.wim and copy it to your ConfigMgr server.

Open the ConfigMgr console and navigate to Software Library > Operating Systems > Boot Images
Find the boot image's path and proceed to import it, naming it appropriately. Make sure you look in the properties of the boot image and under the Data Source tab you select "Deploy this Boot Image from the PXE-enabled distribution point"

 Step 1 is completed.

Step 2 a lot (if not completely) is borrowed from this page:

Here are the components that you’ll need:
First, prepare the USMT packages.
  1. A package for USMT 8.1 is automatically created when you install or upgrade to System Center 2012 R2 Configuration Manager, as the Windows ADK for Windows 8.1 is a setup prerequisite. (This is specifically for those who have SCCM 2012 R2 installed)
  2. You also need a package for USMT 5, which comes with the Windows ADK for Windows 8. Two versions of the ADK cannot be installed on the same computer so you will need to install this ADK on a separate computer.
  3. Extract the USMT files from the Windows ADK for Windows 8 installation folder, C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\User State Migration Tool (by default), and transfer them to a common location for package source files. (Make sure you choose the correct architecture you need)
  4. Follow the instructions on How to Create a USMT Package, making sure to point the package source to the location of the USMT 5 folder from the previous step.
  5. Finally, ensure that the contents for both USMT packages are properly distributed.
On to the fun part -- creating the task sequence.
  1. Create a task sequence using the option to Create a new custom task sequence. (See How to Create Task Sequences for more information.)
  2. Edit the new custom task sequence and add steps to Request State Store, Capture User State and Release State Store.
  3. On the Capture User State step, select the USMT 5 package you created above. Customize it to use miguser.xml, and to use VSS, as shown below. While not in the sample image below, we also recommend you check Enable verbose logging in this scenario.
After this things get a bit tricky because at the time of the borrowed content above there was a critical flaw in this process that was not mentioned. In order to do an in-place refresh of a Windows XP machine to anything greater than XP you HAVE to use a WinPE 3.1 boot image that we created earlier. To do this Right click on the task sequence -> Properties -> Tick 'Use a boot image' -> Browse and find the WinPE 3.1 image that you created earlier.
Another thing that is not mentioned in those articles that there was a critical flaw in the USMT 4.0 that caused Windows XP computers to fail after mounting the boot image prior to rebooting the computer and refreshing. After I stumbled on this forum post and they recommend crazy file mods for a work around. I didn't like that, and after some more digging I found a hotfix that addressed this very issue. <-- This hotfix must be installed on the server and the client package must be deployed to the computers you're trying to refresh prior to any of this working. I'd recommend pushing this out to all Windows XP machines prior to trying to refresh.

*Update* CU1 for SCCM 2012 R2 also addresses this. Be sure to  push this out to your clients or you could have an unbootable machine as the task fails after modifying your MBR.

This pretty much does it on how to get the basic Task Sequence setup and ready to deploy. On my next post I will tackle the process I had to take to accomplish this on laptops as WinPE 3.1 did not have the drivers I needed.


This blog's sole purpose will be to help out someone else out there that has had the same issues that I have had in the past. There will be some tutorials, FYIs, and just vent sessions. I plan to use this for my own reference as well.

Think of it of somewhat of a knowledge base. Sometimes I solve a problem and I have no where to store the information. I know someone else out there has had the same issue so why not share how I accomplished it in my situation?

You will have to disregard my lack of  'grammatical awareness' as I'm quick to just type my thoughts and get the info out there rather than spend time checking if this is indeed a run-on sentence.

Let's see how this goes, and if I maintain it long enough for anyone to use it.