List Applications that run in user context (Install for User)


When deploying applications sometimes they are created to install within the active users context.
This means that the actual installation requires the users to have the needed permissions to the filesystem, registry and etc.
In some cases local administrative rights are needed to perform the application installation, this is not a good practice.

As applications mature for the modern design of the Windows Operating System or we choose to remove the users administrative rights due to security reasons, we may need to list and change the behavior of existing Applications.

This script was created to list applications that is configured to run with Installation behavior: Install for User

The actual output will end up in the export csv file

Script Download Get_Application_USER_Context_List

Today with the modern management tools and applications, the users should not have local administrative rights on a permanent basis.
Most, if not all applications can be repackaged to deploy without the need for administrative rights.

Useful links:

PowerShell Application Deployment Toolkit:
Advanced Installer:
Access Director Enterprise:

Cleaning up shortcuts

So the issue at hand;
I was replacing a Office application on Windows systems, where i noticed that shortcuts created by the users, was not upgraded/removed when the new office version was installed.

The issue seems to be related to users creating custom shortcuts, directly to exe files.
I some cases the shortcut name was clear, but in other cases the users had chosen something they found fit.

The following PowerShell script was created to remove shortcuts (lnk files) based on the executable. This means you can specific the exe or use a wildcard if there is multiple executable files releated to an application.

$ShortcutLocations = Get-ChildItem -Recurse (“C:\Users”,”C:\ProgramData\Microsoft\Windows\Start Menu”) -Include *.lnk -Force -ErrorAction SilentlyContinue

# This script searches for all *.lnk files to "C:\Program files (x86)\App\My Application.exe" or "C:\Program Files\App\My Application.exe"
# It searches in C:\users\* profiles paths, including Users Desktops, %AppData%\Microsoft\Internet Explorer\Quick Launch and in ProgramData...StartMenu
# The name of the link file can have many different names, therefore we must find each shortcut based on path to target exectuable and not on lnk name.
# Then the lnk file must be deleted.
# The script should be run with admin rights, otherwise shortcuts will only be deleted for the user running the script.

### Specify shortcut's target executable here.
$AppExecutable = "C:\Program files*\Microsoft Office\Office15\*.exe"
# * Due to mask it contains "Program files" and "Program files (x86)" paths both.

### Paths to browse and search for shortcuts.
$ShortcutLocations = Get-ChildItem -Recurse ("C:\Users","C:\ProgramData\Microsoft\Windows\Start Menu") -Include *.lnk -Force -ErrorAction SilentlyContinue
# * -Recurse = Includes all subdirectories.

### Get properties for shortcuts in the locations

Function Get-ShortcutsProperties {
$Shell = New-Object -ComObject WScript.Shell 
Foreach ($Shortcut in $ShortcutLocations)
$Properties = @{
ShortcutName = $Shortcut.Name;
ShortcutFullName = $Shortcut.FullName;
ShortcutLocation = $shortcut.DirectoryName
ShortcutTarget = $Shell.CreateShortcut($Shortcut).targetpath
New-Object PSObject -Property $Properties
[Runtime.InteropServices.Marshal]::ReleaseComObject($Shell) | Out-Null

$ShortcutsList = Get-ShortcutsProperties

### Compare shortcut's target path with $AppExecutable and delete it in case of corresponding one
Foreach ($item in $ShortcutsList) {

if ($item.ShortcutTarget -like $AppExecutable) {

Remove-Item -Path $item.ShortcutFullName -Force -ErrorAction SilentlyContinue
######## End of the script

Download the PowersShell Script here: DeleteApplicationShortcuts

MSiX – Remote machine conversions

The MSiX Packaging Tool (1.2019.226.0) Preview now has the ability to connect to a remote machine, where you can run the conversion.
This is great news, and solves the normal issue with contamination on “non-sanitised” machines.

I have always preferred to do my packaging and re-packaging on Hyper-V Virtual Machines
This gives a total control and clean enviroment, with easy ability to get back to a controlled point of reference, using checkpoints.

Getting started with remote machine conversions? Fear not! It is quite simple to get started.

– PowerShell remoting must be enabled for secure access to the remote machine.
– You must be logged on with administrative privileges on the machine.

To enable PowersShell remoting on the machine, run the following command in an elevated PowerShell prompt: Enable-PSRemoting -Force -SkipNetworkProfileCheck

If network/firewall restrictions are in place, remember to allow inbound traffic on port 1599 (MSiX Packaging Tool default port, it can be changed with the settings tab)

If you are connecting using a non-domain joined machine, you must use a certificate to connect over https.
To enable PowerShell remoting and allowing WinRM over https run the following commands in an elevated PowerShell prompt

Enable-PSRemoting -Force -SkipNetworkProfileCheck

New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP

To generate a self-signed certificate, configure WinRM secure configuration and export the certificate, you can run this script: (or download: GenerateSelfsignedWinRMHTTPS)

$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My -KeyExportPolicy NonExportable).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername"";CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command
Export-Certificate -Cert Cert:\LocalMachine\My\$thumbprint -FilePath <path_to_cer_file>

On your locale Machine, copy the exported certificate and install it into the Trusted Root Store.
It can be imported with the following command: Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root

Unified Extensible Firmware Interface (UEFI)

Unified Extensible Firmware Interface

For many years BIOS has been the industry standard for booting a PC. BIOS has served us well, but it is time to replace it with something better. UEFI is the replacement for BIOS, so it is important to understand the differences between BIOS and UEFI. In this section, you learn the major differences between the two and how they affect operating system deployment.

Introduction to UEFI

BIOS has been in use for approximately 30 years. Even though it clearly has proven to work, it has some limitations, including:

  • 16-bit code
  • 1 MB address space
  • Poor performance on ROM initialization
  • MBR maximum bootable disk size of 2.2 TB

As the replacement to BIOS, UEFI has many features that Windows can and will use.

With UEFI, you can benefit from:

  • Support for large disks. UEFI requires a GUID Partition Table (GPT) based disk, which means a limitation of roughly 16.8 million TB in disk size and more than 100 primary disks.
  • Faster boot time. UEFI does not use INT 13, and that improves boot time, especially when it comes to resuming from hibernate.
  • Multicast deployment. UEFI firmware can use multicast directly when it boots up. In WDS, MDT, and Configuration Manager scenarios, you need to first boot up a normal Windows PE in unicast and then switch into multicast. With UEFI, you can run multicast from the start.
  • Compatibility with earlier BIOS. Most of the UEFI implementations include a compatibility support module (CSM) that emulates BIOS.
  • CPU-independent architecture. Even if BIOS can run both 32- and 64-bit versions of firmware, all firmware device drivers on BIOS systems must also be 16-bit, and this affects performance. One of the reasons is the limitation in addressable memory, which is only 64 KB with BIOS.
  • CPU-independent drivers. On BIOS systems, PCI add-on cards must include a ROM that contains a separate driver for all supported CPU architectures. That is not needed for UEFI because UEFI has the ability to use EFI Byte Code (EBC) images, which allow for a processor-independent device driver environment.
  • Flexible pre-operating system environment. UEFI can perform many functions for you. You just need an UEFI application, and you can perform diagnostics and automatic repairs, and call home to report errors.
  • Secure boot. Windows 8 and later can use the UEFI firmware validation process, called secure boot, which is defined in UEFI 2.3.1. Using this process, you can ensure that UEFI launches only a verified operating system loader and that malware cannot switch the boot loader.


UEFI Version 2.3.1B is the version required for Windows 8 and later logo compliance. Later versions have been released to address issues; a small number of machines may need to upgrade their firmware to fully support the UEFI implementation in Windows 8 and later.

Hardware support for UEFI

In regard to UEFI, hardware is divided into four device classes:

  • Class 0 devices. This is the UEFI definition for a BIOS, or non-UEFI, device.
  • Class 1 devices. These devices behave like a standard BIOS machine, but they run EFI internally. They should be treated as normal BIOS-based machines. Class 1 devices use a CSM to emulate BIOS. These older devices are no longer manufactured.
  • Class 2 devices. These devices have the capability to behave as a BIOS- or a UEFI-based machine, and the boot process or the configuration in the firmware/BIOS determines the mode. Class 2 devices use a CSM to emulate BIOS. These are the most common type of devices currently available.
  • Class 3 devices. These are UEFI-only devices, which means you must run an operating system that supports only UEFI. Those operating systems include Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. Windows 7 is not supported on these class 3 devices. Class 3 devices do not have a CSM to emulate BIOS.

Windows support for UEFI

Microsoft started with support for EFI 1.10 on servers and then added support for UEFI on both clients and servers.

With UEFI 2.3.1, there are both x86 and x64 versions of UEFI. Windows 10 supports both. However, UEFI does not support cross-platform boot. This means that a computer that has UEFI x64 can run only a 64-bit operating system, and a computer that has UEFI x86 can run only a 32-bit operating system.

How UEFI is changing operating system deployment

There are many things that affect operating system deployment as soon as you run on UEFI/EFI-based hardware. Here are considerations to keep in mind when working with UEFI devices:

  • Switching from BIOS to UEFI in the hardware is easy, but you also need to reinstall the operating system because you need to switch from MBR/NTFS to GPT/FAT32 and NTFS.
  • When you deploy to a Class 2 device, make sure the boot option you select matches the setting you want to have. It is common for old machines to have several boot options for BIOS but only a few for UEFI, or vice versa.
  • When deploying from media, remember the media has to be FAT32 for UEFI, and FAT32 has a file-size limitation of 4GB.
  • UEFI does not support cross-platform booting; therefore, you need to have the correct boot media (32- or 64-bit).

Automating Windows 10 Enterprise Technical Preview with MDT 2013 Update 1 Preview

To follow-up on my earlier post “Deploying Windows 10 Enterprise Technical Preview with MDT 2012 Update 1 Preview” Let’s try to do a little automation to make the deployment experience a little smoother.

We just need to do a little configuration within the Microsoft Deployment Toolkit 2013 Update 1 Preview.

The first thing that comes to mind is, when we PXE/media boot our client.
We are shown the Microsoft Deployment Toolkit Welcome Wizard. We need to click Run the Deployment Wizard to install a new Operating System.

Note that in this picture is also the option to set Default Keyboard layout for Windows PE as well as a Static IP. I’m going to assume that we always have DHCP in place and accessible for our clients.

To skip the Welcome Wizard:

  1. Right Click your Deployment Share
  2. Click Properties
  3. Click Rules
  4. Click Edit Bootstrap.ini
    1. The bootstrap.ini contains configuration needed before we connect to our Deployment Share.
    2. Keep in mind that all changes here will not be reflected until a new media has been generated.
  5. in the [Default] section right under that path to your DeployRoot add: SkipBDDWelcome=YES
  6. Close the editor
  7. Click Ok to close Deployment Share Properties
  8. Right click your Deployment Share
  9. Click Update your deployment share
  10. Click Next
  11. Click Next
  12. Click Finish
  13. The ISO and WIM image within the Boot folder of your Deployment Share has now been updated – attached ISO media to VM or update WIM file on your Windows Deployment Server. I’m going to copy the Wim to my Hyper-V Host and mount it in my test VM.
  14. Boot your client to verify the changes

Next up – User Credentials Prompt

MDT User Credentials Wizard

Specify credentials for connecting to network shares

This is where need to type in the credentials for the Deployment Share. This is the last prompt before we start processing data from the Deployment Share – so we need to edit bootstrap.ini again

  1. Right Click your Deployment Share
  2. Click Properties
  3. Click Rules
  4. Click Edit Bootstrap.ini
  5. in the [Default] section right under that path to your SkipBDDWelcome add: UserID=<someusername>
    UserDomain=<domain or servername>

    1. The UserID can we a local account on the server hosting our Deployment Share.
    2. UserDomain must reflect if the account is Domain based or local on our Deployment Share server
    3. We only need NTFS read rights (and of course read share permissions) for the Deployment Share
  6. Close the editor
  7. Click Ok to close Deployment Share Properties
  8. Right click your Deployment Share
  9. Click Update your Deployment Share
  10. Click Next
  11. Click Next
  12. Click Finish
  13. Update your ISO or PXE Media
  14. Boot your client to verify the changes

We are now taken directly to the Task Sequence wizard

MDT Task Sequence list

Select a task sequence to execute on this computer

Let suppose that we only have and need one task sequence job – lets automate this step as well

Changes will be a bit easier this time, hence we don’t need to update the ISO or PXE media each time – we are now working with CustomSettings.ini

  1. Right Click your Deployment Share
  2. Click Properties
  3. Click Rules
  4. in the [Default] section right under the last line (In my case its SkipBitLocker=Yes) add:
    1. SkipTaskSequence=Yes
    2.  TaskSequenceID=IW10ETPX64
      1. The Task Sequence ID can be found in Task Sequences tab under the Deployment Share
  5. MDT Task Sequence list

    List of Task Sequences within your Deployment Share

  6. Click Ok
  7. Boot your client to verify the changes

You should now be brought directly to the Computer Details page

Domain or workgroup information

Domain or workgroup information

I’m going to keep this window visible for the computer naming part, but it can of course be skipped. It will require two skip options:

  • SkipComputerName=Yes
  • SkipDomainMembership=Yes

You could also just prepopulate the fields in CustomSettings.ini for either Domain or Group


  • MachineObjectOU=OU=Staging,DC=CLientgeeks,DC=com


  • JoinWorkgroup=SomeWorkGroup

It will automatically use the account used to connect the network share, you can for obviously reasons use a different account

  • JoinDomain=ClientGeeks.local
  • DomainAdmin=DomainJoinAccount
  • DomainAdminPassword=Pa$$w0rd1

The great part of working with CustomSettings.ini is that there is no need to rebuild boot media – changes are effective immediately – go ahead and give it a try

When you boot your client again with the latests additions, we have arrived at Move Data and Settings:

move user data and settings

Move data and settings from a previous version of Windows

The default option for this step is: Do not move user data and settings, If we where to just skip this step, the outcome would be no data and settings backup

  • SkipUserData=YES

Some other configuration options are:

  • USMTOfflineMigration=True
  • DoNotFormatAndPartition=Yes
  • OSDStateStorePath=\\MDT01\StateStore$

Configure CustomSettings.ini and boot the client again – you could also just click next, BUT we know that testing is good, and more testing is better! 😉

Next up is the Locale and Time Zone selection

Specify locale and time preferences

Specify locale and time preferences

The valid skip options:

  • SkipLocaleSelection=Yes
  • SkipTimeZone=Yes

I’m going to configure the optional options just as default

  • KeyboardLocale=0409:00000409
  • UserLocale=0409:00000409
  • UILanguage=en-us
  • TimeZone=004
  • TimeZoneName=Pacific Standard Time

If you ready and retry – you should now only be prompted with a “Ready to begin” and a blank details section, don’t see any need for this page, so let’s just skip this as well

Ready to begin

Ready to begin

This can be skipped with the follwing option:

  • SkipSummary=Yes

Let try it out! 🙂

Hopefully you have achieved an automated installation progress now

Installation Progress

Installation Progress

The IT Organization and Running Package name can also we changed, here is an example that includes the current date and tasksequence ID using a variable – can of course just be static text.

  • #day(date) & “-” & month(date) & “-” & year(date)#
  • _SMSTSPackageName=%TaskSequenceID%

Customized Installation Progress Window

Customized Installation Progress Window

Here is a snip of my CusomSettings.ini and Bootstrap.ini – yours should look similar to this








TimeZoneName=Pacific Standard Time

SkipSummary=Yes #day(date) & “-” & month(date) & “-” & year(date)#






Have fun deploying! 🙂

Deploying Windows 10 Enterprise Technical Preview with MDT 2013 Update 1 Preview

Start the Microsoft Deployment Toolkit Workbench

  1. Open Deployment Workbench
  2. Right Click Deployment Shares
  3. Click New Deployment Share
  4. Change Deployment Share Path to match your environment – in my case I change to D:\DeploymentShare
  5. Click Next
  6. Change the share name or leave as is
  7. Click Next
  8. Change Deployment share description or leave as is
  9. Click Next
  10. Remove all the checks – we will configure these at a later point (CustomSettings.ini)
  11. Click Next
  12. Review details
  13. Click Next
  14. Click Close

Now we have the a deployment share to work from – Now we need some data

Let’s start by importing Windows 10 Enterprise Technical Preview

If you haven’t already downloaded the iso – get it though the Windows Insider Program (

  1. Expand Deployment Shares
  2. Expand the newly created MDT Deployment Share
  3. Right click Operating Systems
  4. Click Import Operating System
  5. Mark Full set of source Files
  6. Click Next
  7. Browse to the content of the ISO downloaded from the Windows Insider Program – I mounted the ISO onto my MDT VM, you could also just extract the content and move it to a reachable location UNC or otherwise.
  8. Click Next
  9. Destination Name will show up as Windows 8.1 Enterprise x64 – change this to Windows 10 Enterprise Technical Preview x64
  10. Click Next
  11. Review the details
  12. Click Next
  13. Click Finish
    1. The imported operating system will name appear in Operating Systems with the name Windows 8.1 Enterprise in Windows 10 Enterprise Technical Preview x64 Install.wim

Now let’s go ahead and create Task Sequence to install this nice vanilla version of Windows 10 Enterprise Technical Preview

  1. Right Click Task Sequences
  2. Click New Task Sequence
  3. Type in an ID for your new install task sequence – I will Type IW10ETPX64, could be anything
  4. Type Task sequence name – I will type Install Windows 10 Enterprise Technical Preview x64
  5. Maybe we even type a comment – I will type todays date, this field is not mandatory
  6. Click Next
  7. Choose Standard Client Task Sequence
  8. Click Next
  9. Choose the newly import Windows 10 Enterprise Technical Preview x64 Install.wim
  10. Click Next
  11. We could specify the MAK Key that we got from the Windows Insider Program, but it’s not required
  12. Click Next
  13. Type in Full Name, Organization Name and homepage
  14. Click Next
  15. Type a local administrator password
  16. Click Next
  17. Review the details
  18. Click Next
  19. Click Finish

So now we got the task sequence ready – so what’s next?

Let’s start the creation of the needed boot images (or either ISO or PXE boot)

  1. Right click the Deployment Share
  2. Click Update Deployment Share
  3. Click Next
  4. Click Next
  5. Click Finish

Browse to your Deployment Share in Windows Explorer

Locate the boot folder – We now have the newly generated boot files. Wim files if we want to PXE boot using Windows Deployment Services, or ISO if we want to use a Boot CD.

I’m going to copy the LiteTouchPE_x64.iso to my Hyper-V host, so I can test boot a VM.
Let’s boot and see what happens

  1. Insert the boot media into your VM or test computer (keep in mind we still haven’t added any drivers
  2. Boot on the media

We are now being presented with the Deployment Wizard Welcome screen

If we to automate or just plain and simple skip this window

    • Add SkipBDDWelcome=Yes to bootstrap.ini
  1. Click Run the Deployment Wizard to install a new Operating System
  2. We are now being prompted for Network credentials to access the share
    1. Type in valid user credentials
    2. This can be automated or skipped with
      1. UserID, UserDomain and UserPassword in Bootstrap.ini
  3. Click OK

Now we are connect to the deployment share – all changes needed from heron out is done within the task sequecen, CustomSettings.ini or within the Deployment Share

  1. Choose your Task Sequence – Install Windows 10 Enterprise Technical Preview x64
    1. This can be automated with the SkipTaskSequence=Yes & TaskSeuqneceID=IW10ETPX64 (ID of your task seuqecen) – the changes is needed in CustomSettings.ini
  2. Click Next
  3. Type in a computer name
    1. Of course we can automate this as well… – CustomSettings.ini
  4. Type in Domain or Workgroup information
  5. Click Next
  6. Choose whether or not to move data and settings from previous versions of Windows
  7. Click Next
  8. Choose to restore user data – we don’t in this case
  9. Click Next
  10. Choose your locale and time preferences
    1. Again – we ca automate this in…… CustomS……s.ini
  11. Click Next
  12. Review the details
  13. Click Begin

The computer is now being installed with the Windows 10 Enterprise Technical Preview

Automating the process will be covered in another post, as well as adding applications and customizing J

Windows 10 – Windows Updates troubleshooting

If you experience problems with Windows Updates and need to debug on the actual process, WindowsUpdates.log has always been a good place to start……… but not on Windows 10

According to Microsoft these steps are relevant only for the January Tech Preview of Windows 10.

Windows Update uses Event Tracing for Windows (ETW) to generate diagnostic logs. This method improves performance and reduces disk space usage. However, the logs are not immediately readable as written. To decode the resulting ETL files and create a log that you can read, follow these steps.

  1. Download the public symbols by following the directions here. Install these symbols to a directory such as C:\symbols.
  2. Download the Tracefmt.exe tool by following the instructions here.
  3. Open a command prompt with administrative rights.
  4. Create a temporary folder, such as %systemdrive%\WULogs.
  5. Locate the directory that contains Tracefmt.exe, as downloaded and installed in step 2. Then, copy Tracefmt.exe to %systemdrive%\WULogs.
  6. Run the following commands at a command prompt, in the order presented:
    • cd /d %systemdrive%\WULogs
    • copy %windir%\Logs\WindowsUpdate\* %systemdrive%\WULogs\
    • tracefmt.exe -o windowsupate.log <each windows update log delimited by space> -r c:\Symbols

For example, the last line might resemble the following:

tracefmt.exe -o windowsupate.log Windowsupdate.103937.1.etl Windowsupdate.103937.10.etl -r c:\Symbols

Lucky for us, we don’t always need to dig deep – there is a deprecated logfile we can use for now (January Tech Preview) WindowsUpdate_AU_deprecated.log