Scripting the Migration of Applications from MDT to Configuration Manager 2012

The need to migrate applications from the Microsoft Deployment Toolkit 2013 (MDT) to Configuration Manager (ConfigMgr) 2012 without MDT integration is not uncommon. Companies use MDT as a stand alone proving ground, then decide to migrate the task sequence and applications to a production ConfigMgr system.

Manually migrating the packages however is a time consuming task. It involves:

  • Creating a Package (Including Data Source, Name, Version etc.)
  • Creating a Programme (Including command line, run time parameters etc.)

Enter Powershell.

Two scripts are used in this example:

  • Script one: Exports the application information from MDT.
  • Script two: Creates packages in ConfigMgr based on this information, complete with install command lines.

After this simply copy the application source from the Application folder of the MDT deployment share, to the location you are planning to store package source in for ConfigMgr.

Script 1 : Export the list of applications from MDT to a CSV file

Note: Update variables for:

  • Location of MDT Deployment Share.
  • CSV file location (The file containing application information exported from MDT.
$MDTDeploymentShare = "C:\DeploymentShare"
$ExportPath = "c:\temp\MDTApplication.csv"

Add-PSSnapin Microsoft.BDD.PSSnapIn New-PSDrive -Name MDT -PSProvider mdtprovider -Root $MDTDeploymentShare
Get-ChildItem "mdt:\applications" | selectName,Version,Publisher,source,Commandline | Export-Csv -Path $exportPath 

Script 2:  Create new application packages based on the exported CSV file

Note: Update variables for:

  • Location of the ConfigMgr Powershell Module.
  •  CSV file location (The file created by the first script).
  • Your site code (Mine is called ABC).
  • Location of the new directory you wish to store the application source in.
$ConfigMgrModulePath = "c:\Program Files\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1"
$ImportPath = "c:\temp\MDTApplication.csv"
$NewSorcePathLocation = "\\ServerName\Sources$\Applications\"

Import-Module $ConfigMgrModulePath

Set-Location ABC:

$csv = Import-Csv $ImportPath

ForEach ($line in $csv){

    $name = $line.name

    $version = $line.version

    $manufacturer = $line.Publisher

    $path = $line.Source -replace ".\\Applications\\", $NewSorcePathLocation

    $command = $line.CommandLine

    New-CMPackage-Name $name -Version $version -Manufacturer $manufacturer -Path $path

    New-CMProgram-Package -Name $name -StandardProgramName "Install" -CommandLine $command -RunType Normal -ProgramRunType WhetherOrNotUserIsLoggedOn -RunMode RunWithAdministrativeRights -DriveMode RenameWithUnc -Duration 120

}
Advertisements

Office 365 App-V click-to-run package prompts to re-install on first use

The Problem

One of my clients is in the process of migrating to Windows 8.1 with Office 365.

To deploy Office 365, it was decided to use the ‘Office Deployment Tool for Click-to-Run” tool (See http://technet.microsoft.com/en-us/library/jj219422.aspx) for more information.

Once packaged as an app-v package, we started to see some very strange behavior. When first logging on to 365 through Word, the end user was informed that:

a)      They were entitled to Microsoft Office 365 ProPlus (Screenshot 1)

b)      The product was not installed! (Screenshot 2)

Image

Image

What we discovered

Both I and a colleague packaged this product with different results. I have summarized it in this table:

OS Architecture Size of O365ProPlusRetail_en-us-x86.appv
Windows 7 32-bit 894,010 KB
Windows 8 64-bit 943,701 KB

As you can see, the size difference is rather large considering that the download source is identical.

The Solution

It turns out that if Office 365 is ‘packaged’ on a 32-bit Windows OS machine, the package does not function correctly on Windows 8 64-bit. I haven’t tested if the reverse is true yet.

The moral of the story is that you must run the “setup.exe / packager” on the correct architecture for target operating system.

Richard

Error: 2147942487 applying hotfix to SCCM 2007 Primary server

Attempting to apply a hotfix to my SCCM 2007 R3Primary server, I recieved an error 2147942487  (The parameter is incorrect). Googling this showed all kinds of non relevant pages!

My error: When the hotfix prompted me to specify a name for the client patch, I appended the purpose of the patch to the name.

The Issue: SCCM has a maximum allowable  length for the package name which the Hotfix had allowed me to exceed.

The Solution: Keep the suggested name, then change it later on in the SCCM console.

Silent install of the WAIK fails with error – “Please insert the disk: Windows Automation Installation Kit CD”

This error message only seems to occur when the 64-bit version of the WAIK is installed off read-only media (such as an ISO image).

It appears that this is caused by an entry in the Media table of the wAIKAMD64.msi file. The MSI is looking for a embedded cab file that is actually external.

There are three ways to ‘fix this’;

  1. Copy the source onto a writable hard disk and then run the MSI.
  2. Make sure that your CD ISO image is called ‘KB3AIK_EN’. This is the volume name the MSI is looking for.
  3. Create an MST file that alters the ‘Media’ table. Change the line for the ‘WinPE.Cab’ cabinet so that the ‘VolumeLabel’ field is set to “DEFAULT” instead of “KB3AIK_EN”. This is my preferred option.

Hope this helps.

Windows 7 Redirected Folders with Offline Files caching failing to reconnect after Laptop hibernation

A big thanks to the support guys at Microsoft for resolving this one!

The scenario;

Windows 7 clients with folder redirection enabled via Group Policy to a remote file and print server. Offline folders have been enabled.

A common file share has been employed to form the base of the user folder structure. The share NTFS permissions are set to disallow end users to browse the other end user folders.

A provisioning script was written that does the following;

  1. Create the folder structure for the end user.
  2. Set the end user as the owner of each folder.
  3. Set permissions to the folder structure so that only the end user and the helpdesk has access to the folder structure.

Continue reading