Last week, a fellow SCCM engineer asked to see my MDT task sequence because he was having problems with his capture task sequence. With SCCM, I can export the task sequence. In MDT, there is no export available. Instead, I sent him the ts.xml files for the task sequences he was interested in. These files are located in a folder under the Control directory. The folders are named whatever the task sequence ID is.
I was doing some testing of a new Zero Touch build in my SCCM 2012 SP1 environment. My testing consisted of testing two different scenarios. The first was a standalone task sequence that used the SMP (State Migration Point) to save and restore user data for a side-by-side migration. In my testing, I manually created the computer associations for testing. After completing my side-by-side testing, I was ready to perform an in-place migration using my Zero Touch task sequence. I added the machine to the deployment collection and the build process proceeded. However, when it reached the step to Request State Store it failed. Looking at smsts.log, I could see that it was reporting a failure to create the certificate with a 0x00000057 error code. Using the below query, I could see that my old side-by-side computer association was still in place and created the failure. I removed it using the SCCM console and reran the Zero Touch installation. This time the build did not fail on the Request State Store step and completed successfully.
WHERE MigrationType = 1
I got a request to create a new local account during the build process. The request also asked for the account to be added to the Power Users group and that it be marked as "password does not expire." There are several ways to do this. I decided to create a PowerShell script. By using a script, I gained the flexibility to update existing machines if needed.
I configured the script to create a log file in C:\windows\logs. During the build, the task sequence step used to execute the script will also generate a log file, but I wanted more detailed information on the execution. I also configured the script to catch errors. For example, it will output the exception error message if the password does not meet complexity requirements, if the group the account is being added to does not exist, etc.
To use the script, the account name and password need to be changed. Since the password is in plain text, it is best practice to restrict access. There are several methods on the web for encrypting a password in a PowerShell script.
What is the difference between the Gather only local data (do not process rules) and Gather local data and process rules settings in an SCCM 2007/2012 Gather Step?
When MDT is integrated with SCCM, one of the steps available is Gather. This step allows rules to be processed that can be used during the build process. When the step is added, there are two settings available:
- The first setting is to Gather only local data (do not process rules). This setting will process only the properties in the ZTIGather.xml. This file is located in the scripts folder or %PROGRAMFILES%\Microsoft Deployment Toolkit\Templates\Distribution\Scripts and contains properties that are always processed during a Gather step. Some of these properties are last value wins such as DeployRoot, while others are first value wins such as UserDomain.
- The second setting is to Gather local data and process rules. This setting will also process the properties in ZTIGather.xml. In addition, however, it will process properties in the Rules file specified. For example, I could create a CustomSettings.ini Rules file that sets my JoinDomain property to Lab.com if that is the domain I want my computers to join during the build process.
Microsoft has released an update that frees up space on Windows 7 SP1 machines. It does this by adding a new option to the Disk Cleanup wizard. In my testing, it freed up over 1 GB of space on each machine that I ran it on.
Below is a link to the Microsoft article with more information and the download.
I did some testing of Windows 8.1 Pro this weekend. While examining the control panel, I noticed that there was no option to create a system image backup. Since I do a lot of tweaking on my machines and a system image backup has saved me several times, I was disappointed to now see it was not available. I decided to check out File History. I was pleasantly surprised to see the option to create a system image backup there. After creating an image, I started my testing with confidence that I could revert back if needed.
Microsoft has released CU3 for SCCM 2012 SP1. If you are not installing the cumulative updates, it is worth looking at them for fixes to problems that might be occurring in your environment. Microsoft also includes additional clients for non-Windows operating systems. Below is a link to CU1, CU2, and CU3. Since these are cumulative updates, CU3 is the only update that needs to be installed. CU1 and CU2 are included in CU3.
At work I was given a list of Employee IDs and asked to get the employee name and manager for each ID. To do this, I used the Quest PowerShell Tools for Active Directory. This allowed me to do an LDAP query of Active Directory for the Names and Managers of the Employee ID list. Since EmployeeID is not a standard attribute, I used IncludedProperties to query it. Below are the steps I performed.
- Created a text file called IDs in C:\Temp.
- Copied the Employee IDs into IDs.txt.
- Created a PowerShell to loop through my text file and output the Name, EmployeeID, and Manager of each ID in the list.
I was building an SCCM 2012 SP1 primary on Windows Server 2012 Standard. After successfully configuring the site, I needed to start deployment of software updates. I had previously installed the WSUS role successfully on Windows Server 2012 so I did not expect any problems this time. As expected, the WSUS role installed successfully. However, the post configurations failed to start. I decided to look at the log generated in the temp folder. When I examined it, I saw an error message that the WSUS content could not be located and it was most likely to do with the WSUS role being installed through PowerShell. I found this odd since I did not use PowerShell to install the role. I remembered seeing a blog post from the Scripting Guy about using wsusutil.exe to do the post configuration. This did the trick. I ran the below command and was able to successfully configure WSUS. Once configured, I was able to add my Software Update Point and deploy software updates.
Note - I replaced <<Name of SQL Server>> with the name of the SQL Server that was going to host my WSUS database and <<Location for WSUS Content>> with the location where I wanted WSUS to store its content.
wsusutil.exe postinstall SQL_INSTANCE_NAME=<<Name of SQL Server>> CONTENT_DIR=<<Location for WSUS Content>>
wsusutil.exe postinstall SQL_INSTANCE_NAME=CM12Primary CONTENT_DIR=F:\WSUSFiles
Recently, I needed to move to the latest version of WinPE on my MDT 2012 Update 1 server. Below are the steps I performed to update my MDT:
- Downloaded the Windows 8 ADK.
- Uninstalled the Windows AIK via Add/Remove programs.
- Started the installation for the Windows 8 ADK.
- Installed the Deployment Tools and Windows Preinstallation Environment (Windows PE) features.
- Updated MDT deployment share to ensure latest WinPE version was used.