jump to navigation

Example application exported by MDTAppExport November 6, 2009

Posted by keithga in MDT 2010, PowerShell.
add a comment

Wanted to include at least one example of what a MDTAppExport.exe powershell script looks like.

So for your review, I have included a sample for 7-zip.

Link

7-zip.MDT.ps1

About 7-zip

7-zip is a popular file archiver that supports numerous file formats, and is available for free over the internet.

What also makes 7-zip a great example, is that you can download the *.msi package directly over the internet.

The command line MSI installer, msiexec.exe, supports the ability to install packages over http://, so there is no need to download the package first. Note that this could cause problems if you try to install 7-zip on a machine that does not have full internet access.

Typically, in real world MDT Deployment Shares, I would download the packages first, but this makes for a fine example.

Persistent Drives

For MDT 2010, the concept of the “Deployment Share” ( Distribution Share, or Distribution Point) has been abstracted even further than that in MDT 2008. A ‘”Deployment Share” can be a Network Share, a Local folder, and it doesn’t even have to be on the same machine as the MDT 2010 Workbench Console is currently running on.

It’s also possible to keep track of multiple “Deployment Shares” within a running MDT 2010 Workbench console. The “Deployment Shares” that are added to the MDT 2010 Workbench Console are called “Persistent-Drives” because they are persisted across Workbench sessions.

Behind the scenes, you can see the settings by looking at the configuration file:

“%appdata%\Microsoft\Microsoft Deployment Toolkit\user.config”

Which Drive to use

I wanted to develop a script that you could run as-is and have the contents instantly added to your MDT Deployment Share.

However, since a machine can have multiple Deployment Shares, or none at all, the question became:

How do we find the default MDT Deployment Share, if any exists?

The best way I figured was to use the Persistent Drives defined in the MDT 2010 Workbench. The Persistent Drive meta-data could be easily read using the powershell cmdlet: “Get-MDTPersistentDrve”.

If more than one drive was defined in the MDT 2010 Workbench, then we just select the first one. Typically defined as “DS001:”

Header

With all powershell scripts we start off with a list of parameters:

#  MDT 2010 Exported Application
#  By Keith S. Garner (KeithGa.com)
#  7-Zip File Archiver 4.65   
param(
 [string]$Folder = "Applications\Common", 
 [string]$DPDrive = "DS001",
 [string]$DPShare = "\\$env:ComputerName\DS$",
 [switch]$Confirm,
 [switch] $Verbose,
 [switch] $WhatIf )

Here the Administrator is given the ability to override several defaults:

  • Folder – This is the folder where the Application will be placed in the workbench, and displayed in the Deployment Wizard.
  • DPDrive – This is the name of the Deployment Drive used in Powershell. Unless defined as something non-standard by the Administrator, it should be DS001:
  • DPShare – This is the UNC path to the Deployment Share, typically a Networking Share. It’s only needed if there are no persistent drives defined.
  • Confirm, Verbose, WhatIf – For more information look here.

Restore

Once started, the script will need to load the MDT 2010 environment into powershell, and restore everything:

if (!(test-path "$($DPDrive)`:\"))
{
 Add-PSSnapin Microsoft.BDD.PSSnapIn […]
 restore-MDTPErsistentDrive […]    
 if ((!(test-path "$($DPDrive)`:\"))
     -band (test-path $DPShare)) {
   New-PSDrive -Name $DPDrive -PSProvider `
       MDTProvider -Root $DPShare […]
 }
 if (!(test-path "$($DPDrive)`:\")) {
   throw "$DPDrive not Mounted/Persisted."
 }
}

First of all, we don’t do anything if the DPDrive is already visible to Powershell. This means that a calling “wrapper” script can perform the restoration of the Persistent drives once, and we won’t need to perform it each time for every application being imported.

Otherwise, we add the Powershell Snapin, and restore any MDT 2010 Persistent Drive(s).

We then test for DPDrive, if there is still nothing there, then we mount a new DPDrive to the Deployment Share given.

We test for DPDrive again, if there is *still* nothing there, then we fail.

Folders

If we are importing the application into an Application Folder that does not exist, we must first create the folder.

foreach($NewPath in "$($DPDrive)`:\$Folder")
{
  if(!(test-path $NewPath))
  {
    new-item -type directory $NewPath –[…]
  }
}

Import Application

Finally, we import the application using the settings gleamed from the application meta-data in MDT 2010.

$7zipx86 = import-MDTApplication
-path '$($DPDrive)`:\$Folder'
-ShortName '7zipx86' […] 
-Name '7-Zip File Archiver 4.65 – x86'
-CommandLine 'msiexec.exe /qb- […] /i http://[…]'
-UninstallKey '{23170F69-40C1-2701-0462-000001000000}'
-enable 'True' -hide 'True'
-SupportedPlatform @(
   'All x86 Pre-Vista',
   'All x86 Vista and Newer'
)

More to come

I hope this will be the first of many Application Examples from MDT 2010.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Export & share MDT Applications (New Tool) November 6, 2009

Posted by keithga in Uncategorized.
comments closed

New for MDT 2010

Presented here is the MDT Application Export Tool (MDTAppExport.exe). This tool will export the settings for a selected Application in MDT 2010 into a Powershell *.ps1 script file. This portable powershell script file can be used to import the Application settings into another instance of MDT 2010.

One of the coolest new features of MDT 2010 is the new Powershell Programming interface. This interface makes it possible for 3rd party programs to Read, Manipulate, and Create settings in your MDT 2010 environment.

Still, Powershell is a relatively new programming language. And many IT Pros may still be unfamiliar with it. Which makes this tool so cool, you can create powershell scripts without knowing powershell.

Advantages

Exporting to Powershell provides a good way to share Application metadata between MDT 2010 Shares:

  • Upgrade your existing MDT 2008 Deployment Share to MDT 2010, and extract out all of your applications for archival.
  • Move individual applications between test and production environments without copying other items still in test.
  • Use Powershell scripts as a way to document/store the settings for each application in your environment.
  • Share your solutions to difficult/complex application installations to IT Community Forums (please don’t share software files you don’t have the rights to redistribute :^) ).

Notes

While running the Application Script Export Tool Wizard, Simply select one of the Deployment Shares already present in the Microsoft Deployment Toolkit 2010 Workbench. Then Select the Applications you wish to export, and the Target location they should be exported to.

Most applications should export without trouble 97-98% of the time. However it is generally a good idea to review the settings created by the tool to ensure that everything is correct.

This script will create one Powershell *.ps1 script file for each item selected in the wizard. If an Application has dependencies defined in the MDT 2010 Workbench, then the dependencies will also be included in the same *.ps1 file.

All Source Files imported into the Deployment Workbench when the Application was created will be copied to the Target Location.

Limitations

  • You must have MDT 2010 installed on the same machine this tool is running on.
  • You must have your Deployment Share visible in the MDT 2010 Deployment workbench.
  • This tool will create one *.ps1 for each application Selected, and all dependent applications will be imported to the same *.ps1 file.
  • If you have hidden and or non-enabled applications defined, they will also be Displayed in the Application Script Export Tool Wizard.
  • This tool will create scripts with the –hidden and –enabled settings as defined in the workbench.
  • This tool will *not* export the Language Field. Language Field is not used in ZTIApplications.wsf
  • If you are exporting Sources, the files must be located in the Deployment Share, meaning that you can’t have a %ResourceRoot% at a different location from the %DeployRoot%.
  • If there were any errors in copying the Sources to the Target, there should be an
    “# ERROR – <something>”
    line present in the source.
  • Please ensure that all application items imported into MDT are placed in their own directory. Installing more than one Application Item from the same directory may result in duplicate files in the MDT system.

Links

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/MDTApplicationExport.zip

Further

This tool has tremendous potential. Beyond just coping application settings between MDT 2010 Servers.

We are already using this tool here at Xtreme Consulting Services to create “repositories” of applications that can be used to quickly build out MDT 2010 deployments for our customers. A fullly functional MDT 2010 Litetouch Deployment System setup on site in Hours, not Days, or Weeks.

It could also be the start of a public repository of Applications for MDT Administrators. Although I have not yet figured out a great hosting site for this kind of community/forum. Have some ideas, drop me a line.

Update: 11/13/09 – I updated the tool to generate scripts that support Powershell v1.0 better, and to fix a problem with applications with spaces in the shortname.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group