Windows 10 (64-bit) upgrade error: Something happened…

Spoiler: It’s down to Windows Driver signature verification.

Something Happened

I’ve seen this error message twice:

  • Trying to upgrade Windows 8.1 64-bit to the last Windows 10 Insider Build
  • Trying to upgrade the Insider Build to the full release of Windows 10 64-bit

The Setupact.log file (Found under C:\$Windows.~BT\Sources\Panther), showed errors when attempting to mount C:\$Windows.~BT\Sources\SafeOS\WINRE.WIM.

Attempting to mount this WIM file manually using DISM, presented another error:

Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

As a test I disabled ‘Driver Signature Verification’ using bcdedit from an elevated command prompt:

bcdedit /set testsigning on

After rebooting I tested mounting the WINRE.WIM file again – Success!

And the Windows 10 upgrade? – Worked perfectly.

Don’t forget to run: “bcdedit /set testsigning off” after the upgrade has completed.

Advertisements

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

}

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