Skip to main content

Management and Security

Go Search
Microsoft Blogs
Cisco Blogs
  

Other Blogs
There are no items in this list.
BT Lynx Community > Microsoft Blogs > Management and Security
MDT 2010 Beta 2 End to End Lite Touch Deployment

Just a quick note... It works.

Under Beta 1 we couldn't successfully join the domain or process the State Restore phase, this is no longer an issue, the auto logon works just fine and the full task sequence completes.

The only small problem we still have is around deploying applications from the database.

Our bdd.log file shows ZTIGather.log enumerating the location correctly and it adds Applications1... entries for the two apps we want to deploy to all machines at this location. By the time we get to the state restore phase, ZTIApplications.log reports that there's nothing to do. Not sure what's happening here, but for now we can handle all of this in the Task Sequence directly, so it doesn't cause too much of a problem.

Also worth a quick mention on Group Policy Preferences. We're leaning heavily on these for all post-build customisation. They're fantastically powerful... Want to add a shortcut to a web application? Simply create a preference object for it, this way it's centrally managed and you can restrict access to it right there in the GPMC with the preference targeting options. We are using them for start menu configuration, environment variable provision and registry modification to do little things like turn off the Office Privacy Options dialogue at first run. The beauty of them is that all of the configuration is centrally controlled and can be targeted very granularly. Using some of the targeting options we could (if we wanted) only display an object if the machine is running on battery! The possibilities are endless.

So great have Preferences proved to be that we're retro-fitting this stuff into our legacy XP environment via the Group Policy Preference Client Side Extensions for Windows XP (KB943729)

We're now running our first live tests of USMT 4, and so far I can say that it's vastly quicker than USMT 3.0, so much so that at first we thought it had failed!

MDT 2010 Beta 2 DP Update Optimization

More MDT goodies... The Update Deployment Share wizard now has lots of logic to help with optimization of the updating process:

As you can see above, I'd installed a new version of the WAIK in between creating the boot images, the update process detects that there's a new version of PE so it forces re-creation of the boot WIM. If only minor changes are detected (such as new drivers, it just injects these, and if nothing has changed then it does nothing. This is a major boon as the ISO and WIM creation process can take over 10 minutes to run, in a lab setup this feels like an age...

MDT 2010 Beta 2 Installation

MDT 2010 Beta 2 is finally here!

We've been waiting for this for our Windows 7 pilot, so we've installed it hot off the web.

There's a couple of new pre-reqs, which are currently not referenced in the Components tab, so they need to be downloaded manually:

PowerShell 2 CTP and WSMAN

Once this is done we're on our way.

The first thing post-installation is to recreate the deployment point. This has a nice new "upgrade option":

We get some nice progress reporting during the DP and Database upgrade:

 

We got a few errors which I need to take a look into, but another nice bit of System Center-type functionality is the "Show Script" button at the end of the wizard, clicking this pops notepad with the PowerShell script I could have used to do the upgrade:

 

The first obvious difference is that the workbench is much prettier, with ConfigMgr style icons for the various nodes:

I already love that the Out of Box drivers are now nested in Driver Groups. Also the enumeration of this node is 10x quicker than under Beta1...

Advanced Configuration contains some interesting new objects to allow linking of deployment shares across sites and to better handle the creation of Selection Profiles based media sets. Creating a Media Set creates the folder structure, this must then be updated to copy the contents and create the WIMs and ISO files, just as with the old Media deployment point. Again the wizard exposes the PowerShell at the end to allow automation of this process later. Nice stuff!

I'm going to run a build and capture of Windows 7 now and see if the issues we had with domain join and State Restore phase processing are sorted.

So far so good!

 

 

Windows 7 Pilot Deployment – Part 1

Overview

In a fit of perhaps unwarranted optimism we have initiated a live pilot of Windows 7 for a bunch of users in our company environment. There are a number of good reasons for this which we laid out in an invitation flyer to the volunteers/victims, i.e.:

  • Expose internal systems and consultancy teams to the latest Microsoft desktop deployment technologies and operating system.
  • Provide backwards-compatibility with existing in-use OS (Win XP) to allow a single approach for all internal OS imaging tasks.
  • Provide front office staff with exposure to the new Microsoft OS and collect data on the real-world performance.
  • Implement Microsoft Application Virtualization to provide a rapid application provisioning platform.

We are running this as we would for a live customer, so have completed a costed proposal and scoping exercise and are implementing the technologies involved in a structured and managed way. We're taking the opportunity to implement App-V along with the Windows 7 pilot. The logic behind this is:

  1. App-V is great. It's an excellent application provisioning solution and will deliver a real benefit to our support department from day one.
  2. The Windows 7 pilot will result in the building and re-building of PCs throughout the pilot process. If we don't have to worry about the apps (as we'll stream them to AD groups) this makes our rebuild process more efficient and supportable.
  3. We're implementing a new VDi training environment at the same time, App-V is a great solution for this environment too, the apps are the same in both environments, once sequenced the apps will be reusable in both environments.

Deployment Approach

We're using the Microsoft Deployment Toolkit (of course) v. 2010 Beta 1. This is a technology we're very familiar with as we use it for our customers (normally integrated with ConfigMgr). In this environment we're using Lite Touch deployment (ZTI isn't currently supported and we don't have ConfigMgr deployed anyway).

Under MDT 2010 we've been able to create and capture a reference image with our core apps in the usual way, but the deployment of this image does not function correctly under Beta 1 of the MDT. The main problems are that the image build doesn't join the domain or process the State Restore phase of the build, so no apps get deployed. Along with this, as the local administrator is disabled by default in Windows 7 we have to use SIM to add an additional local admin account, otherwise we can't log onto the newly installed image.

Other than these little irritations it works, but isn't yet fully deployable, so we're holding off for MDT 2010 Beta 2 which is due out any time now...

We've currently tested out Lite-Touch New Computer scenarios and the Refresh Computer scenarios which work (above issues aside) well. USMT 4 in particular is a very interesting piece of kit and is going to make a huge difference to our deployment time some of our users have over 100GB local data!!!).

Task Sequence Tips and Tricks

We're taking the opportunity to try out some Gucci little tips and tricks during this build to pretty up the process, things which we don't normally have the time or scope for with customer engagements.

Minimize startnet.cmd

Mainly these are little bits of cosmetics, the first being minimizing the startnet.cmd at runtime using David Clarke's rather marvellous ConsoleSize. To get this in place is slightly arduous, you have to add it to PE and modify startnet.cmd to run it before winpeinit, which involves mounting the WAIK copy of winpe.wim (this is then used by MDT to build our custom PE wim/iso... It works, and means that we can reap the benefit of the next little tweak:

Use Custom Backgrounds to Illuminate the Build Progress

At this year's MMS, The Microsoft Modena Team demonstrated using BGInfo and a number of custom backgrounds to brand up the build process. Essentially this calls BGinfo at the start of critical phases of the build to repaint the wallpaper and tell the engineer/end user where the build is up to. This looked pretty cool, so we've put it in place in our build process.

 

As BGInfo is called, it replaced wallpaper1 with wallpaper2, ..3..4 etc, giving the appearance of the progress list updating.

 

We use BGInfo to provision bits of information about the machine (RAM, IP etc.) on the bottom left also.

 

It's very easy to implement and makes for an attractive build process!

 

Communications

Throughout the pilot we're providing the participants with regular project flyers detailing some of the new features of Windows 7 which they might want to try out that aren't immediately obvious (Aero Shake for example...).

We'll be collecting feedback on these features to get some real-world insight into which features of 7 are delivering benefit to the non-tech users we have.

I'll be adding in further postings as the project progresses, particularly around App-V, USMT and of course Windows 7 itself.

 

USB Boot Disk

We're building a load of laptop kit. Problems with the WAN make PXE booting impossible for now, and the laptops don't have optical drives. Obviously a USB Flash boot disk is the answer. It's worth a quick note as to how to create these:

Insert the USB Stick into a computer running the Vista or Windows 7, then use diskpart:

diskpart

select disk 2*

clean

create partition primary

select partition 1

active

format fs=fat32

assign

exit

Now create Task Sequence media boot ISO. Mount the ISO and copy the contents to the USB stick.


Easy as that!

*NB: The value of disk 2 is the USB Stick's disk ID. You can find this in Disk Manager.

 

Modify Package Source

We're using Kim Oppalfens' rather wonderful approach for migrating to ConfigMgr from a large SMS 2003 implementation. We don't want to take the SMS hardware, but we do want the investment we've made in the development in the console (hundreds of packages, collections and advertisements which would take us a long time to set up again.

Kim's approach implements a new child Primary SMS 2003 server. The package, collection and advertisement content is replicated to the child. We copy the package source across to the new server, detach from the parent and the packages etc become 'owned' by the new SMS site. This site can then be upgraded to ConfigMgr. This is great, one slight fly in the ointment is that on the old server the packages are stored in G:\DIST_Source\Vendor\Appname and on the new server they'll be in D:\packages\Vendor\Appname.

Once the child site has been detached, the package source must be modified. This can be done using Transact-SQL and the most efficient (in terms of code) way of doing this in SQL 2005 is using REPLACE command.

USE SMS_XXX

UPDATE SMSPackages

SET Source = REPLACE(CAST(Source AS NVARCHAR(MAX)),

'G:\DIST_source',

'D:\Packages')

 

Note it's important to cast 'Source' as NAVCHAR as REPLACE won't work on STRING types.

Creating Collections from the Command Line

I've not done much work with the ConfigMgr SDK before, but a project I'm working on at the moment called for a large number of collections to be created for application distribution purposes. This is a direct replacement for ZEN Works, so to try to minimize the impact on the helpdesk we've decided to populate AD security groups with computer accounts to drive the population of the ConfigMgr collections. It's not an approach that I'm particularly in favour of as it introduces latency:

Using AD Security Groups for Collection Population

Using Direct Membership in the ConfigMgr Console

Assuming the worst-case scenario this approach could take:

AD Replication – 15 mins

System group Discovery – 60 mins

Colleval – 60 mins

Computer Client update – 60 mins

Maximum possible latency=3hrs 15 minutes

Assuming the worst case scenario this approach would take:

Computer Client update – 60 mins

   

   

   

Maximum possible latency=60 minutes

   

These issues aside, I decided to have a go at creating my many application based collections using a bit of VBScript from the SDK.

I always like to create a clean collection structure from the outset with a small number of root collections with sub collections. I normally break these down as shown:

This approach keeps the collection structure tidy, but means that creating collections using COLLADD won't work as this script doesn't set the parent collection, creating everything in COLLROOT. If you're going to have to move them all manually later (by linking and then deleting the original) then you may as well create them manually in the first place.

Fortunately the SDK provides great samples on creating objects in the console, and the CreateDynamicCollection function automatically expects the Collection ID of the parent collection.

The script I have used is copied verbatim from the SDK with one minor modification to allow for escaping of the quotes around the AD System group Name:

    Script1

' Setup a connection to the local provider.

Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")

Set swbemconnection= swbemLocator.ConnectServer(".", "root\sms")

Set providerLoc = swbemconnection.InstancesOf("SMS_ProviderLocation")

 

For Each Location In providerLoc

If location.ProviderForLocalSite = True Then

Set swbemconnection = swbemLocator.ConnectServer(Location.Machine, "root\sms\site_" + Location.SiteCode)

Exit For

End If

Next

 

Call CreateDynamicCollection(swbemconnection, "XXX0001B", "App Blueprint", "Members will receive the application", true, "SELECT * from SMS_R_System where SMS_R_System.SystemGroupName = ""MYDOMAIN\\App Blueprint""", "App Blueprint")

'NB As the AD Group Names may have spaces in them it is necessary to escape the quotes. The above query line is wrapped for legibility.

 

Sub CreateDynamicCollection(connection, existingParentCollectionID, newCollectionName, newCollectionComment, ownedByThisSite, queryForRule, ruleName)

 

' Create the collection.

Set newCollection = connection.Get("SMS_Collection").SpawnInstance_

newCollection.Comment = newCollectionComment

newCollection.Name = newCollectionName

newCollection.OwnedByThisSite = ownedByThisSite

 

' Save the new collection and save the collection path for later.

Set collectionPath = newCollection.Put_

 

' Define to what collection the new collection is subordinate.

' IMPORTANT: If you do not specify the relationship, the new collection will not be visible in the console.

Set newSubCollectToSubCollect = connection.Get("SMS_CollectToSubCollect").SpawnInstance_

newSubCollectToSubCollect.parentCollectionID = existingParentCollectionID

newSubCollectToSubCollect.subCollectionID = CStr(collectionPath.Keys("CollectionID"))

 

' Save the subcollection information.

newSubCollectToSubCollect.Put_

 

' Create a new collection rule object for validation.

Set queryRule = connection.Get("SMS_CollectionRuleQuery")

 

' Validate the query (good practice before adding it to the collection).

validQuery = queryRule.ValidateQuery(queryForRule)

 

' Continue with processing, if the query is valid.

If validQuery Then

 

' Create the query rule.

Set newQueryRule = QueryRule.SpawnInstance_

newQueryRule.QueryExpression = queryForRule

newQueryRule.RuleName = ruleName

 

' Add the new query rule to a variable.

Set newCollectionRule = newQueryRule

 

' Get the collection.

Set newCollection = connection.Get(collectionPath.RelPath)

 

' Add the rules to the collection.

newCollection.AddMembershipRule newCollectionRule

 

' Call RequestRefresh to initiate the collection evaluator.

newCollection.RequestRefresh False

 

End If

End Sub

 

When executed the script automatically creates the required collection beneath my "Applications" parent collection (XXX0001B) with the query which enumerates all machines in the "APP Blueprint" AD group.

Package Mapping in the Replace Computer Scenario

The MDT Package Mapping approach is a great bit of OS deployment technology and can help to provide an excellent deployment rate when it comes to large-scale zero touch deployment projects. One limitation that currently exists is that package mapping only works in the refresh computer scenario, i.e. I'm moving from XP to Vista, when I install my Vista image, put back the applications which I used to have.

For the Replace Computer scenario, where we're deploying new hardware, out of the box, package mapping does nothing for us.

In the ConfigMgr Replace Computer scenario we use ConfigMgr Computer Associations to provide the capability to recover the user state (via a state migration point) from the OLDCOMPUTER to the NEWCOMPUTER during the build process. We run the Replace Computer Scenario task sequence on the OLDCOMPUTER, this captures the user state, then the NEWCOMPUTER state restore phase magically recovers this. All good stuff, but it doesn't help us with the apps...

But it can. A small change to the PackageMapping stored procedure can use the same Computer Association record to migrate the applications across machines in the same way as we migrate the user state. It's a shame that this isn't integrated in the ConfigMgr console as elegantly as the Computer Associations are, but it works...

First we need to import the NEWCOMPUTER into ConfigMgr using the Import Computer Information wizard. Select the OLDCOMPUTER as the Source for the NEWCOMPUTER (obviously this can be done on a large-scale by populating a CSV file with these entries).

Next we need to modify the PackageMapping process so that it runs against the MACAddress of the OLDCOMPUTER rather than the NEWCOMPUTER.

In SQL Management Studio, browse to the PackageMapping stored procedure and select to modify it. Replace the entry shown with this text (replace SMS_JON with the name of your SMS database)

set ANSI_NULLS ON

set QUOTED_IDENTIFIER ON

go

ALTER PROCEDURE [dbo].[RetrievePackages] @MacAddress CHAR(17) AS SET NOCOUNT ON /* Select and return all the appropriate records based on OLDCOMPUTER inventory */ SELECT * FROM PackageMapping WHERE ARPName IN ( SELECT ProdID0 FROM SMS_JON.dbo.v_GS_ADD_REMOVE_PROGRAMS a, SMS_JON.dbo.v_GS_NETWORK_ADAPTER n WHERE a.ResourceID = n.ResourceID AND MACAddress0 = (select sourceMACAddresses from SMS_JON.dbo.v_statemigration where restoreMACAddresses=@MacAddress) AND n.ResourceID IN (Select ResourceID from SMS_JON.dbo.v_R_System_Valid))

     

A little explanation of what is happening here:

With a thorough PackageMapping database and thorough User State Migration profile and very good planning in terms of assigning the OLDCOMPUTER and NEWCOMPUTERs through Computer Associations we can achieve a near seamless and very high performance desktop replacement approach.

Package Mapping v2

The MDT Package Mapping functionality (Scenario 5: Dynamic Computer-Specific Application Installation to give it its MDT name) provides for the automatic re-installation of ConfigMgr applications during OS re-imaging. This is done via interrogation of the ADD_REMOVE_PROGRAMS SQL view. The deployment database contains a PackageMapping database. This is used to pair an Add/Remove Program inventory entry (ARP) with a ConfigMgr package and program in this way:

PackageMapping Table

The database supplied with the deployment database does not contain the Comment and ID tables shown above, but I'm finding these are pretty useful. Comments are handy as the database gets larger and the ID field is used as a primary key on the table so that we can update the database from a Microsoft Access front end.

Populating the database with new mapping entries is somewhat error-prone... The ARP entries are often GUIDs, and the Packages entry requires the package ID and exact program name. Any of these entered incorrectly results in a failed build which can be awkward to troubleshoot. The only minor complexity on this is that the ID table should be configured as IsIdentity (AutoNumber) in SQL:

To reduce the risk of incorrect entries being added I have knocked up a quick MS Access form to allow selection of the ARP name and Install Package entry. To build this all we need are a couple of ODBC entries one "PackageMapping" connected to the DEPLOYMENT database and another "ARPData" connected to the ConfigMgr database.

Now we just need some linked tables in Access.

QueryBuilding

The PackageMapping table is from the DEPLOYMENT database.

     

The others are SQL views from ConfigMgr

The field highlighted in red builds the MappingEntry field to
automatically populate the SQL database with the ConfigMgr Package
in the correct format (this prevents the inevitable typos when entering
packageIDs and exact program names).


This structure allows us to select the PackageID from a list of all Packages, but displays the friendly package name.

Some Minor Package Mapping Improvements

The MDT Package Mapping functionality is an excellent way of providing application migration during zero touch OS deployment. Coupled with a decent USMT configuration you can get some really good results to provide a seamless OS refresh.

We're using Package Mapping extensively on a current Zero-Touch project and have come across some minor issues related to obsolete resource records.

For example, machine PC001 has ten applications which are in-scope for package mapping (i.e. the Add/Remove Program (ARP) entries they have are mapped to ConfigMgr packages in the MDT PackageMapping table). PC001 has a problem and is rebuilt using the legacy Ghost approach by IS support. Of the ten applications which were installed previously, only three are actually required by the user, so only these three are replaced.

A couple of months go by... We're finally in a position to deploy our new ZTI image to PC001, the install goes fine, but ten apps are re-installed to the machine when the image is installed. Checking the ARP record in Resource Explorer for the machine previously revealed only three in-scope apps, so what's happened?

Pretty straightforward stuff, the stored procedure used to populate the PackageMapping entries (PACKAGESxxx) in the image installation task sequence does a lookup for the ConfigMgr ResourceID using the host machine's MAC Address; this ResourceID is then used to interrogate the ARP entries table for all apps at last hardware inventory cycle. The problem is that when the query for the ResourceID is executed, it gets two results, the one from before the machine was re-Ghosted and the new record created when the machine re-joined the infrastructure. The old record will ultimately be aged out of the database (after 90 days) but in the mean time it's hanging around, even though the old resource has been removed from the Admin Console.

The consequence of this is that the obsolete ResourceID is used by the PackageMapping process and thus the wrong apps are re-installed to the client. The same problem occurs in the lab when re-imaging test machines; even when the test machine's record is deleted from the admin console, its inventory data remains and will be used by the PackageMapping process.

The fix for this is to modify the MDT RetrievePackages stored procedure to validate the ResourceID against the new ConfigMgr R_System_Valid view.

To do this using SQL Server Management Studio browse to the stored procedure, right click – modify, then add the following to the end of the supplied code:

AND n.ResourceID IN (Select ResourceID from SMS_xxx.dbo.v_R_System_Valid )

Alternatively, replace the provided stored procedure by executing:

use [Deployment]

go

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[RetrievePackages]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)

drop procedure [dbo].[RetrievePackages]

go

CREATE PROCEDURE [dbo].[RetrievePackages]

@MacAddress CHAR(17)

AS

SET NOCOUNT ON

/* Select and return all the appropriate records based on current inventory */

SELECT * FROM PackageMapping

WHERE ARPName IN

(

SELECT ProdID0 FROM SMS_xxx.dbo.v_GS_ADD_REMOVE_PROGRAMS a, SMS_xxx.dbo.v_GS_NETWORK_ADAPTER n

WHERE a.ResourceID = n.ResourceID AND

MACAddress0 = @MacAddress

AND n.ResourceID IN (Select ResourceID from SMS_xxx.dbo.v_R_System_Valid ))

go

Now when Package Mapping is called, only non-obsolete data will be used and everything will function as expected. This has the added advantage in a lab of allowing you to delete the resource record of a test PC from the console and have that machine return no results from Package Mapping.

Thanks to John Nelson for his help with this on MyITForum.

1 - 10 Next

 ‭(Hidden)‬ Admin Links