A WordPress.com site dedicated to System Center and Cloud Management

Posts tagged ‘SCCM (Configuration Manager)’

Using WDS to Deploy SCCM Images without PXE-Enabled DPs


I ran into this scenario recently while at a client’s site, working with SCCM to create a server build task sequence.

Let’s say you have SCCM installed, including a CAS, multiple Primary Sites and Secondary Sites, and many Distribution / Management Points. However, despite having Distribution Points in your environment, you do not have them PXE-enabled. Instead, you are using a standalone Windows Deployment Services (WDS) server to handle/manage the PXE-boot process.

Now, the second part of the scenario. In SCCM, we have MDT installed and integrated. Therefore, we are using not the “normal” Boot Images created by the installation of SCCM, but rather the MDT Boot Image.

So, to sum up: SCCM Distribution Points without PXE enabled, using the MDT Boot Image, and using WDS standalone.

So, here’s the issue. IF you take the MDT Boot Image from SCCM, and upload it into WDS as a Boot Image, you encounter an issue. When you system PXE Boots, everything seems to be OK, and the boot image starts to load. First it will show “Initializing hardware devices…”, then it will show “Windows is starting up…”. Finally, it will show “Preparing network connections…”, and then BAM! Nothing! And the system will restart, just to repeat the same process over again.

If you enable Command Line support in the Boot Image, you can press F8 and be able to check the Log files to see what’s going on. So, if you press F8, and navigate to X:\SMSTSLog\, you will see a .Log file called “SMSTS.log”. Open it in Notepad (by typing “notepad” in the command line, since we don’t have the CMTrace.exe utility available to us). In the Log file, scroll to the bottom, and you should see a entry that says: “Failed to download PXE variable file. Code(0x00000001).”

SMSTS

Now, if you search online for a solution, most posts will mention checking drivers (usually NIC drivers). But in my case my VM was getting an IP Address, therefore it’s not a NIC driver issue.

Well, thanks to some of my co-workers, they pointed me to the following website: http://www.deployvista.com/Blog/JohanArwidmark/tabid/78/EntryID/54/Default.aspx. This article refers to an older version of SCCM, but is still applicable with SCCM 2012. Additionally, for applicability/clarity, the information taken from the above listed article has been re-written/worded, and includes screenshots.

Background Information

When you add the Distribution Point (DP) role to a system managed by SCCM, and enable the “PXE support for client’s” option, SCCM will install (if not already installed as a Role/Feature) the Windows Deployment Services (WDS) server role. This makes is difficult to co-exist with other Boot Images, like the MDT Lite Touch boot image, on independent/standalone WDS servers.

With SCCM, you can generate WinPE Boot Images for Operating System Deployment (OSD). However, the issue is using a standalone WDS system which is not managed by SCCM to provide the PXE boot option on the network, with an SCCM DP server where the OSD content exists (and where the boot image refers to).

SCCM Boot Media Information

When an SCCM generated Boot Media is used, there are additional configuration files contained within the ISO, most importantly the TSMBootStrp.ini and Variables.dat files. These files are present within the SCCM generated boot media, but not actually contained within the .WIM file itself. The issue is further complicated due to the fact that you cannot add an ISO boot media file into WDS, but rather, require a .WIM file.

The solution is to extract the contents of the SCCM generated boot media ISO file, and add the missing configuration files into the Boot Image .WIM file. After these files have been added into the Boot Image, this .WIM file can be added into WDS, and thus made available to PXE boot.

Modifying a WinPE Boot Image (WIM) File to Include SCCM Boot Media Files for Standalone WDS

This section provides step-by-step instructions on how to extract SCCM Boot Media content, and insert/inject it into a Boot Image .WIM file.

Create SCCM Boot Media

Launch the SCCM Console, and navigate to Software Library > Operating Systems > Task Sequences.

Build TS - 01 - Task Sequences

Right-click on the Task Sequences section heading, and choose Create Task Sequence Media.

SCCM Boot Media - 02 - Create Task Sequence Media

On the Select Media Type page, choose Bootable Media, then click Next.

SCCM Boot Media - 03 - Select Media Type

On the Media Management page, choose Dynamic Media, then click Next.

SCCM Boot Media - 04 - Media Management

On the Media Type page, choose CD/DVD Set, provide a location and filename, then click Next.

Note: The path does not need to be a UNC patch, and can be a local drive (i.e. C:\). Also, the Filename provided must end with the “.ISO”.

SCCM Boot Media - 05 - Media Type

On the Security page, select the ‘Enable Unknown Computer Support’ option. You can also choose to password protect the media, but this is not required. Accept all other default selections as-is, then click Next.

SCCM Boot Media - 06 - Security

On the Boot Image page, click Browse and select the appropriate Boot Image, and Distribution Point. Then click Add and select an available Management Point. Once all 3 fields have been entered, click Next.

SCCM Boot Media - 07 - Boot Image

On the Customization page, accept the defaults, and click Next.

SCCM Boot Media - 08 - Customization

On the Summary page, review the selections made, and then click Next.

SCCM Boot Media - 09 - Summary

On the Completion page, click Close.

SCCM Boot Media - 10 - Completion

You should now have an .ISO file at the location you specified during step 5.

Extract SCCM Boot Media ISO Contents

At the location of your ISO file, use a ZIP program (i.e. 7zip), and extract the contents of the .ISO file. This should create a folder, with the same name of your ISO file, containing all the files (i.e. C:\SCCMBootMedia\).

Note: Ensure that you make note of where the ISO extracted folder contents is located, as this will be needed in the next section.

SCCMBootMediaExtract

Mount Boot Image WIM File and Inject SCCM Boot Media Files

To be able to complete this step of the process, you must have the Windows Automated Installation Kit (AIK) installed. It is important to note that this tool is not compatible with Windows XP, and therefore must be installed/used on a newer Operating System (i.e. Windows 7/8.x). This document will not detail on how to install the AIK, as this is a straightforward process.

Note: For Windows 8.x, the AIK has been changed/re-named to the “Windows Assessment and Deployment Kit (ADK)”.

Important: For simplicity, it is recommended to copy your Boot Image (.WIM) file to the same location that you extracted the SCCM Boot Media (.ISO) to.

Start this part of the process by launching the Deployment and Imaging Tools Environment.

Launch Deployment and Imaging Tools Environment

Within the command prompt, type the following command:

ImageX /MountRW <index#>

Example: ImageX /MountRW C:\BootImage.WIM 1 C:\BootImageMountLocation

This will now allow you to explore (and thus add) the content contained within the Boot Image WIM file, from the Mount Location you specified, via File Explorer.

MountBootImage

Navigate to the location that you extracted the SCCM Boot Media ISO file, and copy the \SMS\Data folder into the WIM Mount Location.

Example: C:\SCCMBootMedia\SMS\Data to C:\BootImageMountLocation\SMS\

SCCMBootMediaExtract

MountedBootImage(Pre)

MountedBootImage(Post)

Return to the Deployment and Imaging Tools Environment command prompt, and type the following command to unmounts the image (WIM) file, and commit the changes applied (i.e. the files copied into the directory).

ImageX /UnMount /Commit

Example: ImageX /UnMount /Commit C:\BootImageMountLocation

UnMountBootImage

Copy the updated Boot Image .WIM file (which should now have an updated timestamp) to the WDS server, launch the Windows Deployment Services console, select the Boot Images folder, and click Action > Add Boot Image.

WDS - Add Boot Image

On the Image File page, click Browse, and navigate to the modified .WIM file that was copied to the server, then click Next.

WDS - Add Boot Image - File Location

On the Image Metadata page, provide an Image Name and Image Description, then click Next.

WDS - Add Boot Image - Image Metadata

On the Summary page, review the information presented, then click Next.

WDS - Add Boot Image - Summary

On the Task Progress page, once the operation has completed, click Finish.

WDS - Add Boot Image - Task Progress

Back in the WDS console, under Boot Images, you will now see your Boot Image listed which will be used for PXE booting.

WDS - Add Boot Image (POST)

Now when you PXE boot your system, and boot into WinPE, your system will be able to communicate with SCCM, and continue the rest of the process (running Task Sequences).

 

As always, if this post helped you in any way, and you would like to show your appreciation, please rate it and comment on it. Also, feel free to contact me (via the About Me page) with requests for future articles.

Advertisements

My Experience With The PowerShell Deployment Toolkit (PDT) – Part 3 (Installer.ps1)


In our last post, we used the PDT’s VMCreator.ps1 script to create all the VMs that are required to setup all System Center components.

Now, we are going to use the Installer.ps1 script to finish the installation.

Installer.PS1 SCRIPT

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the Installer.ps1 script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Before running the script to execute the installation, it is best to run the validation option first, to ensure everything is in place. To do this, run the Installer.ps1 script with the “-ValidateOnly” parameter, like this: PS C:\Users\Administrator\Downloads\PDT2.5.2509> .\Installer.ps1 -ValidateOnly. This will initiate the validation, which checks things like the VMs, dependencies, SQL Server installations, and media for installation.

As you can see in my lab example, the Media validation has failed.

PDTInstallerScript-MediaValidationFailed

You will notice that the Installer.ps1 script is looking for the media in the C:\Temp directory. But wait, didn’t we download all of the required files by running the Donwloader.ps1 script? Yes we did. Then why is this validation failing?

Simply, the Downloader.ps1 script downloaded all the required files, but rather than placing them into the C:\Temp directory, it put them in C:\Installer\Prerequisites. If you look at the Variable.xml file, specifically lines #7 and 8, you will see the following:

<Variable Name=”SourcePath” Value=”$SystemDrive\Temp” />
<Variable Name=”Download” Value=”C:\Installer” />

These lines tell the scripts where path to the source files are, and where (originally) to download those files.

So at this point, we have 2 choices. Either we can move all of the files into C:\Temp, or we can change the “SourcePath” directory to match where the files are downloaded to (namely C:\Installer\Prerequisites).

In my case, I’ll just move the files. But if you want, you could modify the SourcePath variable.

Re-run the Installer.ps1 script with the “-ValidateOnly” parameter. The validation for the Media should pass now. However, as you can see in my lab example, I am now getting validation failures on the Service Accounts.

PDTInstallerScript-ServiceAccountValidationFailed

So, how do we fix this? Well, first, I should mention that I am running the PowerShell scripts on my HOST machine; which is NOT a part of the domain. This is why the validation of the Service Accounts fails.

So you have 2 choices, either join your HOST to the domain, or copy the Installer.ps1 script and C:\Installer directory to the Domain Controller. Since I like to re-build my lab over and over, I don’t prefer to add my HOST to the domain. So, in my lab example I opted to copy the files to my Domain Controller VM, and re-run the Installer.ps1 script with the “-ValidateOnly” parameter.

Now, when I did this, I am STILL getting validation errors, but this time with the Server and Access validation.

PDTInstallerScript-ServersAndAccessValidationFailed

Why is this? Honestly, I don’t know. But I do recall reading/hearing somewhere about possibly having to run these scripts from an Administrator’s workstation, and NOT from any of the systems that the scripts are designed to work with. Since I was originally running the scripts on my HOST system that was NOT connected to the domain, that was one issue. Then I ran the scripts from the Domain Controller, which resolved the Account validation.

So, I thought that I would try one last thing. I decided to create an Administrator workstation and run the scripts from there. Now, of course I ran the Installer.ps1 script with the “-ValidateOnly” parameter just to see if everything passed prior to actually running the script to perform the installation. And guess what! Everything passed!

So, now that we know everything is green and we won’t end up with a partial/incomplete installation, we are now ready to run the Installer.ps1 script, and complete the final part of our installation.

Run the Installer.ps1 script, and the validation will be completed again (as designed), then the installation will be initiated.

PDTInstallerScript-InstallationStarted

Just like the VMMCreator.ps1 script, the display will turn green when each item is completed. Eventually, it will complete all pieces.

PDTInstallerScript-InstallationCompleted

Congratulations, you have now successfully used the PowerShell Deployment Toolkit (PDT) to automatically install and configure an entire System Center environment!

One final note. You may not have noticed, but all of the System Center consoles were actually installed onto server RD01. Why is that? It’s not the Administrator’s workstation. The answer is because that server is the System Center Orchestrator Runbook Designer server, which requires all of the consoles for the interoperability/connectivity to create runbooks, and thus System Center automation.

SystemCenterConsoles

So, if you are looking for the console for a specific System Center component (i.e. SCOM, SCCM, etc.), you will need to log into the RD01 server and launch it from there. Alternatively, since we had to setup an Administrator workstation, you could install each console on the workstation as well.

I hope this post series on the PowerShell Deployment Toolkit has been helpful. Happy lab-ing.

My Experience With The PowerShell Deployment Toolkit (PDT) – Part 2 (VMCreator.ps1)


In our last post, we used the PDT’s Downloader.ps1 script to download all the files, pre-requisites, etc. that are required to setup all System Center components.

Now, we are going to use the VMCreator.ps1 script to create all the VMs we need.

For more information about the VMCreator.ps1, see the following: http://blogs.technet.com/b/privatecloud/archive/2013/02/18/deployment-the-pdt-vm-creator.aspx

IMPORTANT: This script only support creating of VM’s on Microsoft Windows Server Hyper-V.

Variable.xml File

The PDT2.5.2509 directory contains 2 important files, called Variable.xml, and VariableAD.xml. This is the file that tells the script what to label the VMs, etc.

NOTE: The file “Variable.xml” will create all VMs created for System Center, but requires the existing of Active Directory first. The file “VariableAD.xml” will create all the VMs including a Domain Controller with Active Directory. This is the best option to use if you want to re-build your lab environment completely automated. This is the file that I will be using.

Let’s first take a look at this file, so that I can point out the area(s) you may want to customize.

Start by editing the VariableAD.xml file.

VariableADXML

There are a few things to note.

First, you should take note that the domain used is “CONTOSO”. If you want to customize your setup to have a specific domain name, you will need to Find and Replace all entries of “CONTOSO” with your domain.

In my lab example, I am going to change it to “SC.LAB”. However, there are 2 different types of entries that contain the word “CONTOSO”. One for Service Accounts, using the ‘Domain\UserName’ pattern (44 entries), and another that uses ‘Domain.com’ (46 entries) for the database server references.

VariableADXML-ChangeDomain

Therefore, to make it easier to use Find and Replace, I have found that replacing the ‘Domain.com’ references first is best. In my case I will use Find and Replace and replace the existing “Contoso.com” with “SC.LAB”. If your domain uses the “.com” ending, then you can just simply replace all entries of “CONTOSO” with your domain name.

Once you have the domain modified, save the file as “Variable.xml” replacing the existing one, or you can name it something specific like “VariableADCustom.xml”.

VMCreator.ps1 Script

Now that we have a customized Variable.xml file, we are ready to make a few minor modifications to the VMCreator script and then run it.

If you have re-named the Variable.xml to something different, you will need to edit the VMCreator script first (because by default it looks for Variable.xml). I have not attempted this yet, so re-name your XML file to be “Variable.xml”. Once I have attempted with a re-named file, I will post an update to this section.

Now, before we can run the VMCreator script, we need to create a sysprep’d VHD file for each OS required (namely Windows Server 2008 R2, and Windows Server 2012 R2). To make this easy, you can use the Convert-WindowsImage.ps1 script (found here: http://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f).

Convert-WindowsImage.ps1 Script

Using this command-line tool allows you to rapidly create sysprepped VHDX and VHDX images from setup media for Windows 7/Server 2008 R2, Windows 8/8.1/Server 2012/R2.

This script actually has a GUI to make it easier to work with, which I will walk though here.

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the Convert-WindowsImage script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Now call the script, and include the “-ShowUI” parameter, like this: Convert-WindowsImage.ps1 -ShowUI. This will cause the GUI to appear.

ConvertWindowsImage-UI

From this UI, choose 1). the Source (which is the ISO of your Operating System), 2). the SKU (like Standard, Enterprise, Datacenter, etc.), 3). specify the file format (I choose VHDX for 2nd Generation VMs running Windows Server 2012), Dynamic, and the size (I left mine at the default of 40 GB).

Leave the Working Directory as is, since that’s where the script is running from. Provide a name for the VHD file.

NOTE: If you do choose to provide a name, you MUST enter the file extension or else you will encounter an error as follows (i.e. W2012R2.vhdx).

INFO : Launching UI…
INFO : Opening ISO en_windows_server_2008_r2_with_sp1_vl_build_x64_dvd_617403.iso…
INFO : Looking for F:\sources\install.wim…
INFO : Scanning WIM metadata…
ERROR : There is a mismatch between the VHDPath file extension (), and the VHDFormat (.VHDX). Please ensure that these
match and try again.
INFO : Log folder is C:\Users\Adin\AppData\Local\Temp\Convert-WindowsImage\fe5ad446-cd0a-4e4d-b72b-f5916feb7d9e
INFO : Done.

ConvertWindowsImage-UI_ErrorOutput

When you are ready, click the Make My VHD button.

Windows(R) Image to Virtual Hard Disk Converter for Windows(R) 8
Copyright (C) Microsoft Corporation. All rights reserved.
Version 6.3.9600.3.amd64fre.fbl_core1_hyp_dev(mikekol).131226-2000 Release to Web

INFO : Launching UI…
INFO : Opening ISO en_windows_server_2012_r2_x64_dvd_2707946.iso…
INFO : Looking for D:\sources\install.wim…
INFO : Scanning WIM metadata…
INFO : Image 2 selected (ServerStandard)…
INFO : Creating sparse disk…
INFO : Attaching VHDX…
INFO : Disk initialized with MBR…
INFO : Disk partitioned…
INFO : Volume formatted…
INFO : Access path (F:\) has been assigned…
INFO : Applying image to VHDX. This could take a while…
INFO : Signing disk…
INFO : Image applied. Making image bootable…
INFO : Opening F:\boot\bcd for configuration…
INFO : BCD configuration complete. Moving on…
INFO : Drive is bootable. Cleaning up…
INFO : Generating name for VHDX…
INFO : Closing VHDX…
INFO : Closing Windows image…
INFO : Done.

The script will show in the PowerShell command prompt what it is doing.

ConvertWindowsImage-UI_Output

You will need to create 2 VHDs, one for Windows Server 2012 R2, and another for Windows 2008 R2. This is required because the System Center Service Manager portal runs on SharePoint 2010, which is only supported on Windows Server 2008 R2.

Variable.xml File (VHD Files)

Now that we have the sysprep’d VHD files ready, we can now use the VMCreator.ps1 script to create all the Virtual Machines (VMs) for all the System Center components automatically.

By default, the VMCreator.ps1 script uses the Variable.xml file to generate the VMs. Therefore, by default it will check for the VHD file in the following location: C:\VHD\WS12R2D.vhdx.

This means that you will have to either move/re-name your sysprep’d VHD file, or change the XML file to point to the correct location. In my example, I will change the XML file accordingly, as follows.

At line # 235 the section begins. Within there, there is a reference to which is the sysprep’d VHD file that we created (specifically the Windows Server 2012 R2 disk). Change this entry to meet the location and name of the VHD file you created with the Convert-WindowsImage.ps1 script.

<OSDisk>
<Parent>C:\VHD\WS12R2D.vhdx</Parent>
<Type>Differencing</Type>
</OSDisk>

At line # 399 the  section begins. Within there, there is a reference to which is the sysprep’d VHD file that we created (specifically the Windows Server 2008 R2 disk). Change this entry to meet the location and name of the VHD file you created with the Convert-WindowsImage.ps1 script.

<OSDisk>
<Parent>C:\VHD\WS08R2E-SP1.vhdx</Parent>
<Type>Differencing</Type>
</OSDisk>

Variable.xml File (Virtual Switch)

Before you run the script, you also need to ensure that the Hyper-V Virtual Switch is already created.

In the Variable.xml file, at line # 222 the section begins. Change this entry to match whatever Virtual Switch you have created in Hyper-V, or create a Virtual Switch labelled the same “CorpNet01”.

<VirtualSwitch>CorpNet01</VirtualSwitch>

In my lab example, I created an Internal Virtual Switch, and labelled it “Internal Lab Virtual Switch”.

 

Variable.xml File (VHD Location)

One more minor note. In the Variable.xml file, at line # 208 and 209, there is a and reference. On your Hyper-V host, if you have a different drive that you want your VM files to be stored on, you need to change this reference. In my lab example, I have a dedicated SSD drive labelled as Y:\ for my VMs.

<VMFolder>C:\VMs</VMFolder>
<VHDFolder>C:\VMs</VHDFolder>

Now we are finally ready to run the VMCreator.ps1 script and watch it create all the VM’s for us!

VMCreator.ps1 Script (Continued)

Start by running PowerShell command prompt as Administrator. Right-click on PowerShell and choose ‘Run As Administrator’.

Administrative PowerShell Prompt

In the PowerShell command prompt, change the working directory to where the VMCreator.ps1 script is located (in my example, in the Downloads folder); for example: cd “C:\Users\Adin\Downloads”.

Now run the script: VMCreator.ps1. The command line will show you its progress. First it will validate everything, and then start creating the VMs. You will notice that it first creates the Active Directory Domain Controller, and waits for that to be up and running (with Domain Services installed), and then create the other VMs. This is because all other VMs are joined to the domain.

VMCreator-AD

VMCreator-AllVMs

Once all the Virtual Machines are up and running the script will appear to be completed, as follows.

VMCreator-VMsCompleted

However, if you connect to the Domain Controller, you will see that another script is running to install all the components for each System Center product.

VMCreator-DC-ComponentInstall

Eventually, you will notice that some lines will turn yellow. This is because some elements are dependant on others, so it needs to wait for those to complete. For example, SQL Server needs to be installed before Management Servers, Management Servers need to be up and running before Consoles are installed, etc.

PDT Installations Pending

When an element is complete, the line will turn green.

PDT Installations Completed

This entire process will take some time, and is dependant on your hardware. In Microsoft’s MMS demo, it took them just less than an hour. With my lab hardware (described here), it took approx. 1 and a half hours.

In the last post in this series, we will go onto using the next script, Installer.ps1.

Tag Cloud

%d bloggers like this: