September, 2007

For Lite Touch deployments, we can now create multiple partitions, or even prepare multiple disks. 

Note that this uses some interesting math, the same as System Center Configuration Manager.  Looking at the example above, with the first partition specifying to use 50% of the free space and the second partition saying to use 100% of the free space, what would you expect the result to be?  It will create two identical partitions, each one taking up half of the disk, since the free space calculation is based on the *remaining* free space.

For SMS 2003 we still use the original partitioning script at this point, mainly because there's no location to write a Diskpart script file.  We are still looking at ways to do this.

BDD has always supported rules processing via CustomSettings.ini, where values from the local machine, typically retrieved via WMI, could be used to make decisions on what needs to be done on each machine during a deployment.  It could also make SQL queries and stored procedure calls to retrieve additional information from external databases.  There were always challenges with that though, especially around making secure SQL connections.

To help with that problem, we have added the capability in Deployment 4 to make web service calls based on simple rules defined in CustomSettings.ini.  These web service requests don't require any special security context and can use whatever TCP/IP port is needed, to simplify firewall configurations.

Here's a sample showing how to configure CustomSettings.ini to call a particular web service.  In this case, the web service is just one picked at random from an internet search.  It takes a Zip code as input and returns the city, state, area code, and time zone (as a letter, strangely enough) for the specified Zip code.

[Settings]
Priority=Default, USZipService
Properties=USZip, City, State, Zip, Area_Code, Time_Zones

[Default]
USZip=98052

[USZipService]
WebService=http://www.webservicex.net/uszip.asmx/GetInfoByZIP
Parameters=USZip

So if you were to execute this, you would see output something like this:

Added new custom property USZIP
Added new custom property CITY
Added new custom property STATE
Added new custom property ZIP
Added new custom property AREA_CODE
Added new custom property TIME_ZONES
Using from [Settings]: Rule Priority = DEFAULT, USZIPSERVICE
------ Processing the [DEFAULT] section ------
Property USZIP is now = 98052
Using from [DEFAULT]: USZIP = 98052
------ Processing the [USZIPSERVICE] section ------
Using COMMAND LINE ARG: Ini file = CustomSettings.ini
CHECKING the [USZIPSERVICE] section
About to execute web service call to http://www.webservicex.net/uszip.asmx/GetInfoByZIP: USZip=98052
Response from web service: 200 OK
Successfully executed the web service.
Property CITY is now = Redmond
Obtained CITY value from web service:  CITY = Redmond
Property STATE is now = WA
Obtained STATE value from web service:  STATE = WA
Property ZIP is now = 98052
Obtained ZIP value from web service:  ZIP = 98052
Property AREA_CODE is now = 425
Obtained AREA_CODE value from web service:  AREA_CODE = 425
------ Done processing CustomSettings.ini ------

There are a few minor complications to watch out for when doing this:

• We don't do anything special with proxy servers.  If there is an anonymous proxy present we will use it, but authenticating proxies will cause issues.  But in most cases, I wouldn't expect you to really be calling an internet web service.
• The XML returned as a result of the web service call is searched for any property defined via CustomSettings.ini or ZTIGather.xml (just like with a database query or other rule).  However, the XML search is case-sensitive.  Fortunately the web service above returns all upper case property names, which is what ZTIGather expects.  It is possible to remap lower or mixed-case entries to get around this.
• We always perform a POST request to the web service, so it needs to support a POST.

With any luck, we'll provide some real sample web services as we get closer to the release of Deployment 4.  If you come up with any creative samples that you would be willing to share, let me know.

First, let me mention a design change:  In Deployment 4, there are no longer any "builds" in the Deployment Workbench.  Instead of creating a build, you will create a task sequence.  This is more in line with the System Center Configuration Manager way of doing things.  Behind the scenes, much of the same configuration exists; it's just presented differently.

Next, we now support multiple task sequence templates.  Right now, we have provided three templates for Lite Touch and SMS 2003 deployments:

• Client.xml.  This is the closest to the original template provided in BDD 2007: it performs all the steps necessary to deploy an OS (any version, any scenario, with optional capture).
• Server.xml.  This is a new template designed to deploy a server operating system, either Windows Server 2003 or Windows Server 2008 (still in beta).  The main different between this one and the client.xml: there are no user state migration steps in the server template since USMT doesn't support servers.
• ClientReplace.xml.  This task sequence gathers the user state from a computer being replaced and stores it on a server; from there it can be loaded on a new server.  There are a few optional steps in this task sequence too: it can back up the existing OS (just in case), and it can also wipe the hard drive so that the computer is ready to be boxed up and disposed of.  (Note that this may not work yet for SMS 2003's "old computer" advertisement.)

There are also three templates for ConfigMgr 2007, equivalent to the ones above:

• SCCM_Client.xml.
• SCCM_Server.xml.
• SCCM_ClientReplace.xml.

If you wanted, you could also create your own templates.  Just drop them into the \Program Files\Deployment 4\Templates directory (for Lite Touch or SMS 2003) or the \Program Files\Deployment 4\SCCM directory (for ConfigMgr 2007) and we'll automatically find them.  (Be sure to change the description in the file so you can tell which one is which.)

Another new script has been added into the Lite Touch and SMS 2003 task sequence templates.  This script, ZTIWindowsUpdate.wsf, originally built for Microsoft IT, is designed to run in the new operating system, automatically downloading and installing all updates available on Windows Update.

Note that this script requires access to the Internet to download needed updates, and we haven't yet tested using this with an internal WSUS server.  Try it out and let us know what you think.

A new script has been added to the standard client task sequence template in Deployment 4 Beta 3.  This script helps with the USMT data migration process by scanning the existing OS to see what file types are registered to applications installed on the machine, then generates a new USMT XML file to tell USMT to grab all files of those types.  While this doesn't do anything to help with the migration of settings associated with those applications, it at least does make sure that data files are captured and restored.

Check out the ZTIAppXmlGen.wsf script to see how this works.  Right now, this will only work for Lite Touch and SMS 2003 deployments.

I know it's kind of old news by now, but if you've missed the various blog entries, e-mails, and other assorted announcements, we have released a new beta 3 of Deployment 4 (the codename for the next version of BDD 2007 - the "official" name is still being determined) on the http://connect.microsoft.com site.  To access this web site, you need to follow these steps:

1. Visit the Microsoft Connect Web site (http://connect.microsoft.com).
2. Click Invitations on the Connect menu.
3. You will need to sign in using a valid Windows Live ID before you can continue to the Invitations page.
4. If asked, enter your Invitation ID in the box. Your invitation ID is: DITF-WB9Y-3M4R
5. Click Go.
6. If you have not previously registered with Microsoft Connect, you might be required to register before you continue with the invitation process.

Please download it and give it a try.  This new beta can be installed on the same computer as BDD 2007, so you can try it out side-by-side.  (Just don't point both versions to the same distribution directory as that would probably confuse BDD 2007.)