Azure Resource Groups -Preventing Accidental Deletion with Resource Locks


Did you know that when you delete an Azure Resource Group, it deletes all the resources in that group?


You have built a Resource Group in Azure that contains your infrastructure resources including:

  • Virtual Network
  • Subnets
  • Network Security Groups (NSG)
  • Storage account to hold diagnostic logging for the NSGs

The subnets may host your IaaS Virtual Machines, maybe define your DMZ and your reverse proxy. So questions around risk need to be asked including:

  • How easy is it to delete a Resource Group?
  • Who can delete a Resource Group?
  • What can be done to protect a Resource Group?

Continue reading


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.

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 = $

    $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


Windows-To-Go creation tool (Wtgcreator.exe) does not recognise WIM file


The Windows-To-Go creator tool (Wtgcreator.exe) is responsible for imaging a Windows-To-Go USB drive with a Windows Image (WIM) file.

This WIM file may be:

  • Taken from a Windows 8.1 original ISO image
  • A customised WIM image created using Configuration Manager or the Microsoft Deployment Toolkit (MDT)

To use the tool you simply:

  • Plug in your certified USB device
  • Start the Windows-To-Go Wizard
  • Highlight your USB key and click Next
  • Click ‘Add Search Location’ and provide a directory where the WIM file lives
  • Select the correct WIM and begin the imaging process

The problem

When running through the Windows-To-Go creator wizard, no custom WIM files (even though they exist) are listed which prevents imaging.


Selecting a stock WIM file from the original ISO however works.

The Workaround

Use the DISM command to mount the WIM image to a temporary directory:

"DISM.exe /Mount-Wim /WimFile:C:\images\myimage.wim /index:1 /MountDir:C:\images\mount"

Close the WIM with the commit flag:

DISM.exe /Unmount-Wim /MountDir:C:\images\mount /commit

I don’t know why this works yet, but it does solve the immediate issue.

One interested thing to note is that the WIM file is now around 10MB larger.


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 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)



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.


Replacing GUIDS in a file using PowerShell

A quick line of PowerShell code that replaces existing GUIDS in a file with completely new randomly generated GUIDS (Should all be on one line):

(get-content .\Input.xml) | 
ForEach-Object {$_ -replace "\{[0-9a-z\-]*\}",
("{" + [guid]::newguid()  + "}")} |
 Set-Content output.xml -Encoding UTF8

The code basically does a find and replace using a regular expression, then outputs the new content to the output.xml file. The encoding output is completely up to you, mine is set to UTF-8 as it matched the input file.


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.