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.
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
The Hydration process has been tested on Server 2003 R2 SP1/SP2 and Server 2008 R2 SP1.
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
SQL files to extend MDT database and refresh views
PowerShell and CSV for bulk import of ConfigMgr Secondary Site servers
Task Sequence template and CustomSettings.ini template
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
Sources files are required for the following items.
Table 2: Required Source Files
\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
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
5) Input MDT2010 for the Database Name and select Next
7) Select Next
8) Select Finish
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.
Once you are pointed to MDT Database. You can Execute the query.
You should see “Command(s) completed successfully”
Next open the “refresh MDT views.sql” and make sure you are again pointed to correct database.
You should see “Command(s) completed successfully”
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.
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.
The CSV file contains the Description, MacAddress, and ScriptSiteCode values we want to import into the Database.
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.
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.
Edit the PowerShell script to make sure the correct SQLServer and Database are specified.
After running the import, you will see the records in the Database based on the information in the CSV.
The following folders from the Hydration files will need be to created as Packages in ConfigMgr.
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.
NOTE: The ConfigMgr Toolkit can simply be imported as a MSI.
A Task Sequence XML is provided in the \Templates folder in the Hydration files.
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.
A customsetings.ini for use with Task Sequence template has been provided in the \Templates folder.
The SQLServer and Database values will need to be changed to match your environment.
Ensure that the Gather step in the template is pointing to your Settings package.
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"
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"
The sender creation script is coded to the primary site. This will need to be modified to point to your primary site.
primSiteCode = "001"
primSite = "2008-configmgr"
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.
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:
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.
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.
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.
Once extracted, you only need the CAB, so I removed the other files from the folder.
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.
Create a Package that references those source files and distribute it to your Distribution Points.
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.
Select the Package you created earlier called “Windows 7 Hotfixes”.
Name the Task Sequence step appropriately.
Make sure your Task Sequence step is BEFORE the Configure step in the Post Install section.
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.
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.
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.
Kent Agerlund posted a new blog post where Coretech developed a really nice shutdown utility for use with ConfigMgr.
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
Johan Arwidmark has a new post up talking about integrating Dart 7 (beta) into your WinPE images to allow remote connectivity.
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
Michael Murgolo has a new post over on The Deployment Guys Blog.
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
Ben Hunter has a new post over on The Deployment Guys Blog.
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
Johan Arwidmark has a new post discussing the Role and Features action inside MDT.
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
Great post over on The Deployment Guys by Daniel Oxley.
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:
- Create a new Task Sequence Group called "Authorised Computer Verification".
- Add a Gather task (if necessary).
- Add a Run Command Line task, with a command line like the one shown above.
- 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.
Michael Niehaus has a new post on ConfigMgr Driver Management.
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
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.