Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X
Aside

Configuration Manager–Hydrating Secondary Sites with ConfigMgr

The following solution(s) are provided as-is without any warranty, confers no rights and is not supported by the Author(s). Use at your own risk.

Installing and configuring Configuration Manager Secondary Sites is often a manual and time consuming task. If you have 50 or more sites that can be a significant amount of time spent installing and configuring Secondary Sites. The Hydration approach attempts to resolve that issue by providing an automated way to setup and configure Secondary Sites.

The following Hydration solution can be presented in 2 forms. It can be presented as a Post Operating System Task Sequence that will configure either Server 2003 or Server 2008 R2 systems for being a Secondary Site. The 2nd method is to integrate the steps into a Task Sequence that also deploys a Server 2003 or Server 2008 R2 image along with configuring the server to be a ConfigMgr Secondary Site.

Assumptions

This document assumes the following:

· You have a working and properly configured Configuration Manager 2007 SP2/R3 Primary Site

· You have Microsoft Deployment Toolkit 2010 Update 1 installed

· You have integrated MDT with ConfigMgr

· You have an existing MDT toolkit package

· SQL is configured to allow Named Pipes

· You have already created at least one DeploymentShare in MDT

· You have already created a SQL$ share

· You have the knowledge of how to create the required ConfigMgr packages

Supported Operating Systems

The Hydration process has been tested on Server 2003 R2 SP1/SP2 and Server 2008 R2 SP1.

Hydration Files

The files are contained in a “ConfigMgr_Install.zip” archive. Once these files are extracted, you will need to modify a few of the script files and add the required source files. This section details those required changes.

The following tables details the included file/folder structure.

Table 1: Folder Structure

Folder

Description

\SQL Files

SQL files to extend MDT database and refresh views

\Import_Computer

PowerShell and CSV for bulk import of ConfigMgr Secondary Site servers

\Templates

Task Sequence template and CustomSettings.ini template

\Configure WebDAV

Script to configure WebDAV for Server 2008 R2

\ConfigMgr Server 2003 IIS

Script to configure IIS for Server 2003

\ConfigMgr Create Senders

Script to create Primary site to Child site sender

\ConfigMgr 2007 Toolkit V2

ConfigMgr Toolkit (trace32)

\ConfigMgr 2007 SP2 Secondary

Script and source files for installing ConfigMgr secondary site

\ConfigMgr 2007 R3

Script and source files for installing ConfigMgr R3 and necessary pre-requisite hotfix

Source Files

Sources files are required for the following items.

Table 2: Required Source Files

Folder

Description

\ConfigMgr 2007 R3\Source

R3 installation files

\ConfigMgr 2007 R3\Hotfix

R3 Pre-req hotfix 977384

\ConfigMgr 2007 SP2 Secondary\PreReqs

ConfigMgr downloaded preq-reqs’s

\ConfigMgr 2007 SP2 Secondary\Source

ConfigMgr installation files

\ConfigMgr 2007 Toolkit V2\Source

ConfigMgr Toolkit MSI

\ConfigMgr Server 2003 IIS\i386

I386 directory from 2003 media

Installation

Creating the MDT Database

This Hydration solution relies on a “SCRIPTSITECODE” variable. This solution was developed around this information being populated in the MDT database. It is possible to configure and set this variable through other methods, but this guide will not address those.

1) Open the MDT workbench and expand your DeploymentShare

2) Select Advanced Configuration-Database

3) Right-Click on Database and select New Database

4) Input the name of the SQL server and make sure the Network Library is selected to Named Pipes, then select Next

clip_image002

5) Input MDT2010 for the Database Name and select Next

clip_image004

6) Input SQL$ for the SQL Share, then select Nextclip_image006

7) Select Next

8) Select Finish

Extending the MDT database

Provided with the Hydration files are 2 SQL files for extending the MDT database with the SCRIPTSITECODE value and refreshing the views.

Open the “create scriptsitecode.sql” in SQL Management Studio.

Ensure that you are pointing to the MDT database.

clip_image008

Once you are pointed to MDT Database. You can Execute the query.

You should see “Command(s) completed successfully”

clip_image009

Next open the “refresh MDT views.sql” and make sure you are again pointed to correct database.

clip_image011

You should see “Command(s) completed successfully”

clip_image009[1]

If you open up the MDT workbench, go into Advance Configuration – Database- Computers, you will now see a new property called ScriptSiteCode listed on the Settings tab.

clip_image013

Bulk Importing Records Into The MDT Database

A PowerShell script and CSV file are provided for the bulk import of computers into the MDT database. These computers are the servers we want to configure as Secondary Sites.

CSV

The CSV file contains the Description, MacAddress, and ScriptSiteCode values we want to import into the Database.

clip_image014

We use the MacAddress to identify the server and configure the appropriate SiteCode for the ConfigMgr installation. The SiteCode is stored in the ScriptSiteCode variable. The description is just a friendly name so we can identify the server in the database.

PowerShell Script

The provided PowerShell script will do a bulk import of the CSV file into the MDT database. The PowerShell script imports a MDT Module, connects to the MDT database and imports the information from the CSV file.

Edit the PowerShell script to make sure the paths are correct to the source files.

clip_image016

Edit the PowerShell script to make sure the correct SQLServer and Database are specified.

clip_image018

After running the import, you will see the records in the Database based on the information in the CSV.

clip_image020

clip_image022

Configuration Manager Packages

The following folders from the Hydration files will need be to created as Packages in ConfigMgr.

clip_image023

These packages will be used by the Task Sequence template. No Programs are required for the packages, simply create a Package that references the source files so we can make them available to the Task Sequence.

clip_image024

NOTE: The ConfigMgr Toolkit can simply be imported as a MSI.

Task Sequence Template

A Task Sequence XML is provided in the \Templates folder in the Hydration files.

clip_image025

This template contains all the necessary steps to configure either a 2003 or 2008 R2 server for being a Secondary Site. In addition to the packages containing the Hydration files, we need to use MDT Toolkit Package and a Settings Package.

The required steps in the template need to be configured to point to the ConfigMgr packages you have created.

clip_image024[1]

CustomSettings.ini

A customsetings.ini for use with Task Sequence template has been provided in the \Templates folder.

clip_image026

The SQLServer and Database values will need to be changed to match your environment.

clip_image027

Ensure that the Gather step in the template is pointing to your Settings package.

clip_image028

Required Script Modifications

InstallConfigMgr2007SP2.wsf

There is a section of code in this script that allows you to specify existing source files to use, if we can find those, we will use those to install ConfigMgr, otherwise we’ll use the files from the script source files directory.

The following code would need to be changed in the script to match the location you might have local source files. It is located at line 93 in the script.

sFile = "F:\folderpath\smssetup\bin\i386\setup.exe"

ConfigureSvr2003.wsf

There is also logic in the 2003 IIS script that checks for a local copy of the i386 directory. We look for the i386 directory at the root of the C: drive. If we don’t find it then we copy it down from the source files. In addition we set a few registry keys to let Windows know where the source files are located. If you wanted to change this location, you would need to modify the following lines of code.

Line 57 – Check for local i386

sFile = "C:\i386\setup.ex_"

Lines 70-72 – Update registry to point to C:\i386

oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SourcePath", "C:\", "REG_SZ"

oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath", "C:\", "REG_SZ"

oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SourcePath", "C:\", "REG_SZ"

CreateConfigMgrSenders.wsf

The sender creation script is coded to the primary site. This will need to be modified to point to your primary site.

Lines 51-52

primSiteCode = "001"

primSite = "2008-configmgr"

Using with an OSD Task Sequence

The provided TS template in \templates can also be used with an OSD TS to create a Secondary Site from bare-metal. The template can simply be copied into an existing OSD TS.

clip_image029

 

Download the script files here.

Aside

ConfigMgr–Building A Reference Image-Installing Hotfixes/Updates Offline

If you build your reference image using Microsoft Deployment Toolkit Lite-Touch, it’s fairly easy to incorporate OS level hotfixes and updates offline, some good examples are the following:

A "Set Network Location" dialog box appears when you first log on to a domain-joined Windows 7-based client computer

An update that improves the compatibility of Windows 7 and Windows Server 2008 R2 with Advanced Format Disks is available

These types of updates aren’t available typically from Microsoft Update, so your normal Software Update steps in ConfigMgr don’t do the trick.  When we use Lite-Touch, we have a “Packages” node where we can import these types of hotfixes, updates or Language packs and they will be installed automatically for us by the ZTIPatches script. 

image

image

What I’ve seen most people do in ConfigMgr is they will create an individual package for each hotfix and then install them like an Application in the Task Sequence using a wusa.exe command line. 

image

This works just fine, however, you are installing the hotfixes while in the full OS and you need multiple steps for each update.  I’m sure you could come up with a fancy way to use a single step to install multiple updates via a script, but, MDT already can do that for you, so why reinvent the wheel!

Installing Multiple Hotfixes/Updates Offline Using a MDT Task Sequence

Using a MDT integrated Task Sequence, we can install multiple hotfixes/updates in a single step for multiple architectures using a single package.

First we need to get the CAB files for the hotfixes/updates we want to work with.  You can use your favorite extractor to get the files out of the MSU’s. 7-Zip did the trick for me and allowed me to do multiple files at once.

image

Once extracted, you only need the CAB, so I removed the other files from the folder.

image

Next I created a package source folder called “Windows 7 Hotfixes” and placed the extracted files in that folder. This folder contains both x86 and x64 hotfixes.

image

Create a Package that references those source files and distribute it to your Distribution Points.

image

Next, open up your Build and Capture Task Sequence. We want to add a new action to our Post Install phase, “Install Language Packs Offline”.  This step actually calls ZTIPatches.wsf, so it’ll do what we want, just like in MDT Lite-Touch.

image

Select the Package you created earlier called “Windows 7 Hotfixes”.

image

Name the Task Sequence step appropriately.

image

Make sure your Task Sequence step is BEFORE the Configure step in the Post Install section.

image

Now when you run your Build and Capture Task Sequence, we will install the hotfixes offline and we’ll scan through the package and grab any applicable hotfixes/updates. If we find a x64 update and we are building an x86 OS, we’ll just skip it and only grab the x86 hotfixes that match.

Here we can see them installed on a system I deployed my captured image to.

image

Aside

Known Issue and Workaround: Duplicate Records When You Use Unknown Computer Support with Active Directory Delta-Discovery

Really great post over on the System Center Configuration Manager Team Blog.

Read the full post here.

This post describes how and when you might see duplicate records when you use unknown computer support with Active Directory Delta-Discovery in Configuration Manager 2007 R3, what problems you might see, and some suggested workarounds.

Unknown computer support is an operating system deployment feature that was introduced in Configuration Manager 2007 R2.  It allows you to find unmanaged computers so that you can install an operating system on them, and optionally, install the Configuration Manager client:

http://technet.microsoft.com/en-us/library/cc431374.aspx. Active Directory Delta Discovery is a new feature in Configuration Manager 2007 R3 that enhances the discovery capabilities of the product by discovering only new or changed resources in Active Directory Domain Services instead of performing a full discovery cycle: http://technet.microsoft.com/en-us/library/ff977086.aspx.

If you use these two features at the same time, you might see duplicate records for the unknown computer in Configuration Manager database.  In this scenario, you will see two records in the Configuration Manager console that have the same name of the computer that installed an operating system by using unknown computer support: One record shows that it is a client and assigned; the other record shows that it is not a client and not assigned.

Aside

System Center Configuration Manager Shutdown Utility

Kent Agerlund posted a new blog post where Coretech developed a really nice shutdown utility for use with ConfigMgr. 

Read the full post and download the tool here.

To suppress or not suppress a computer restart when deploying software and software updates that is the question. No matter what you do, you most likely will not win the “best colleague of the Month” award.

If you do not force a computer restart you might face problems like:

  • Non-compliant computers
  • Computers being in reboot pending mode which might prevent them from installing new software and software updates

If you do force a restart you might face problems like:

  • Very unhappy users
  • Scenarios where you restart while the end-user is using the computer for a demo or presentation
  • End-users calling Servicedesk and complaining about a virus that’s shutting down their computer
  • Restarting computers that are already compliant

image_thumb188

Aside

Software Assurance Pays Off – Remote Connection to WinPE during MDT/SCCM deployments

Johan Arwidmark has a new post up talking about integrating Dart 7 (beta) into your WinPE images to allow remote connectivity. 

Read the full post here.

In the new Dart 7 (Beta) release, Microsoft added a remote connection application to WinPE, it allows you to connect to a WinPE system using the new Dart Remote Connection Viewer. This article explains how to add it to either MDT 2010 Lite Touch or ConfigMgr (SCCM) 2007 to monitor your deployments.

Credit goes to Michael Niehaus for letting me know it existed and explaining the inner works, and thank you Process Monitor and Process Explorer for helping me figure out what files where actually needed  🙂

Adding Remote Monitoring to MDT 2010 orConfigMgr 2007 OS Deployments

……

Step 1 – Download Dart 7 (Beta) and create the Dart ISO

…..

Step 2- Extract the files needed for Remote Connection

…..

Configure MDT 2010 Lite Touch to add the files to its boot image (SCCM instructions further down)

…..

Configure ConfigMgr 2007 (MDT 2010 Zero Touch)  to add the files to its boot image

….

Aside

Message Box Script for Lite Touch Task Sequences

Michael Murgolo has a new post over on The Deployment Guys Blog.

Read the full post here.

I recently had the need to pop up a message box duing an LTI task sequence.  I was creating a stand-alone wizard to allow a manually-initiated launch of a task sequence that would install the Service Pack 1 update on Windows Server 2008 R2.  As part of this task sequence, if a certain software package was of a certain version or earlier we had to reinstall this software after the service pack installation.  If this installation was not going to happen because a newer version was already installed, the customer wanted to notify the technician at the end of the process.  Since this was to be a simple notification, a message box was sufficient.  I could have simply created a VBScript that had a static MsgBox function call for this purpose.

However, I decided that I would make it more reusable than that.  Instead I created an MDT script that would take the input arguments for the the MsgBox function as command line parameters.  That way the script could be reused any time a message box was needed.  The script can also optionally use the MsgBox return value as the script exit code and/or use it as the value for a task sequence variable.

……

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services – U.S. East Region

Aside

Language Packs not showing up in your Task Sequence?

Ben Hunter has a new post over on The Deployment Guys Blog. 

Read the original post here.

If you are using MDT Update 1 to deploy Windows 7 SP1 language packs then please pay attention, this post will save you time.

MDT 2010 Update 1 does not address the Enhanced Language Pack handling in Windows 7 SP1.  This means that if you add a Windows 7 SP1 language pack to the workbench it will not appear in the task sequence wizard.

Thankfully the solution is fairly simple. You simply update the language handling function in the DeployWiz_Initialization.vbs script.

For details of the updates on how to make this update please see – http://support.microsoft.com/kb/2547191

This post was contributed by Ben Hunter, an Architect with Microsoft Services

Aside

MDT 2010 – Inside the Install Roles and Features action

Johan Arwidmark has a new post discussing the Role and Features action inside MDT.

Read the full post here.

One of the most powerful features in MDT is the option of having the Task Sequence install all the Roles and Features needed, most often on servers, but also for clients. I use this feature heavily in different kinds of automated datacenter builds and when preparing Proof-Of-Concept or other demo/lab type environments.

How does Install Roles and Feature action work?

….

Explanation of the (Win7), (2008R2) and (Win7,Core) entries

Windows Server 2008 considerations

Troubleshooting

Aside

Back To Basics 5: Restricting Task Sequence Usage

Great post over on The Deployment Guys by Daniel Oxley.

Read the full post here.

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

Often the simplest tips are the best ones, so here is one I have been using pretty much ever since I started working with MDT.

When working as part of a team in the same MDT environment, you can often run into issues when various people are modifying the task sequence, or debugging a process that is part of it. My own method to mitigate this issue is to fork the "official" task sequence, creating my own one, in order to separately realise testing or to simply try something out, before feeding changes back into the main task sequence.

The downside to this method is that, by forking the task sequence, the new forked one also appears in the list of task sequences and thus allows somebody to accidentally run it, possibly causing undesired results to their computer (such as formatting it!). Therefore, in order to prevent this situation, I always introduce some simple validation tasks into the task sequence, typically right at the start. These validation steps perform a simple query to check if a computer is "authorised" to run the task sequence or not. My authorisation method is usually based on the MAC address of the computer, but it really can be any value that you like.

The best thing about this tip is it’s simplicity. As you can see in the screenshot below, it only consists of two tasks (the Gather task is actually only required if you have not already run a previous Gather task), and a Run Command Line task. You’ll notice that the command line is incorrect. This is intentional and not an error, and if MDT attempts to run this command line it will fail the task sequence execution.

Here are the steps I use to implement this:

  1. Create a new Task Sequence Group called "Authorised Computer Verification".
  2. Add a Gather task (if necessary).
  3. Add a Run Command Line task, with a command line like the one shown above.
  4. On this same task, switch to the "Options" Tab. On this screen you can add your own personalised conditions, or use the same MAC address conditions that I have used, as shown below.

Notice that the condition is actually a negative. Consequently, when a computer runs the task sequence, this task will only execute if the MAC address of the computer does not match one that is in the list. And because the command line of the task is erroneous, MDT will fail at this point, thus preventing the unknown, or unauthorised, computer from continuing.

When working with MDT and Configuration Manager, you could restrict use of a task sequence by only advertising it to a collection built using direct membership. However, there might be situations where you can’t or don’t want to use this collection method. This tip works equally well in a ZTI environment if you wish to use it that way, however you might need to add an additional "Use Toolkit Package" task before the Gather step.

Finally, there are other methods to achieve the same result, such as using the CustomSettings.ini file; the reason I do it this way is because its implementation is so quick and simple.

Aside

ConfigMgr 2007 Driver Management Revisited (Again)

Michael Niehaus has a new post on ConfigMgr Driver Management. 

Read the original post here.

After MMS 2010, I had posted a series of blog postings talking about different mechanisms for managing drivers with ConfigMgr 2007.  You can read through that at http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx.

Then a hotfix was released that changed the way ConfigMgr 2007 handled duplicate drivers when importing.  I talked about that in the post at http://blogs.technet.com/b/mniehaus/archive/2010/10/15/configmgr-driver-management-a-new-development.aspx.  One point called out in that posting:  driver categories would be overwritten when a duplicate driver was imported specifying a different category.  That made the “Added Predictability” model described in the first posting very difficult to implement (without using something like the PowerShell script I posted in the first series).

Now, there is a new development:  Another hotfix that affects driver importing:

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server
http://support.microsoft.com/kb/2513499

From the title, you can probably guess what it fixes:  Now, when importing duplicate drivers, if you specify a different category, it will be added to the list of categories instead of overwriting the list that is already there.  As a result, the “Added Predictability” model is fairly simple to implement (without the need for scripting).  Look at this basic scenario:

  • Download all the drivers for a Dell Latitude E6410 and import those, specifying a category of “Latitude E6410”.
  • Download all the drivers for a Dell Latitude E6510 and import those, specifying a category of “Latitude E6510”.

Without the hotfix, all the common drivers would end up with a category of “Latitude E6510”.  With the hotfix, they would have both categories specified.