Michael Niehaus' Windows and Office deployment ramblings
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.
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:
There are also three templates for ConfigMgr 2007, equivalent to the ones above:
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.)
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.
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, USZipServiceProperties=USZip, City, State, Zip, Area_Code, Time_Zones [Default]USZip=98052 [USZipService]WebService=http://www.webservicex.net/uszip.asmx/GetInfoByZIPParameters=USZip
[Settings]Priority=Default, USZipServiceProperties=USZip, City, State, Zip, Area_Code, Time_Zones
[Default]USZip=98052
[USZipService]WebService=http://www.webservicex.net/uszip.asmx/GetInfoByZIPParameters=USZip
So if you were to execute this, you would see output something like this:
Added new custom property USZIPAdded new custom property CITYAdded new custom property STATEAdded new custom property ZIPAdded new custom property AREA_CODEAdded new custom property TIME_ZONESUsing from [Settings]: Rule Priority = DEFAULT, USZIPSERVICE------ Processing the [DEFAULT] section ------Property USZIP is now = 98052Using from [DEFAULT]: USZIP = 98052------ Processing the [USZIPSERVICE] section ------Using COMMAND LINE ARG: Ini file = CustomSettings.iniCHECKING the [USZIPSERVICE] sectionAbout to execute web service call to http://www.webservicex.net/uszip.asmx/GetInfoByZIP: USZip=98052Response from web service: 200 OKSuccessfully executed the web service.Property CITY is now = RedmondObtained CITY value from web service: CITY = RedmondProperty STATE is now = WAObtained STATE value from web service: STATE = WAProperty ZIP is now = 98052Obtained ZIP value from web service: ZIP = 98052Property AREA_CODE is now = 425Obtained 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:
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.
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.
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:
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.)