The Deployment Bunny

OS Deployment, Virtualization, Microsoft based Infrastructure…

  • Archives

  • Meta

Nice to Know–Application or Packages works great when deployed after OSD, but some fail during OSD

Posted by Mikael Nystrom on August 16, 2018

There are many reasons for this, but I recently worked with a customer (you know who you are) that deployed 3-15 apps during OSD, some of the where Adobe CS apps and they are larger then Notepad++, just a bit. In this case the error was shown in the smsts.log file as “Install Dynamic application action failed to install application: ‘APPNAME’ Code 0x80004005” and Download Fail, hmm, running the same apps in a custom task sequence or directly to a collection works great of course.

Checking the cas.log shows that the Cache size is set to 5g (default) and going trough the log it turns out that after a few apps the cache is full and the cache cannot be cleared. Therefore the apps/packages cannot be installed, since files are missing.

(Note: There are are other settings that you should set in a Task Sequence as well, check out  Peter Lofgrens blogpost

The Fix

That’s easy and not something new, just change the client cache size during OSD by making it a bit larger

Cache size OSD has changed to 20GB.

Verify settings in the cas.log

In the cas.log you should now see.

Cas.log confirms the new size.

We did not need 20GB, but we did need 10.27 GB for sure.


Posted in ConfigMgr, OSD | Tagged: , | Leave a Comment »

I’m Speaking at IT/Dev Connections October 15 – 18, 2018

Posted by Mikael Nystrom on June 19, 2018

I happy to announce that I will be attending IT/Dev Connections as a speaker. Currently I have one session, and what a session that is. Infrastructure as Code – PowerShell in the real world, I will showcase they way we deploy, manage and control enterprise and fabric based infrastructures using PowerShell. That will be a full session of fun. If you have not signed up, here is the link:



Posted in Speaking | Tagged: | Leave a Comment »

Nice to Know – A very important update to Windows Server SAC and LTSC

Posted by Mikael Nystrom on March 30, 2018


LTSC is for Legacy workload and Infrastructure, SAC is for Apps

When Windows Server 2016 was released Microsoft explained that the Desktop Edition and Core edition was about to be LTSC (released every 2-3 years) and Core and NANO was to be SAC (released every 18 months). The purpose was to give customers a faster “cadence”. The use case for Desktop Edition was to run legacy software that needs the UI, core was targeted for legacy software the could run without the UI and NANO was containers and modern infrastructure, like Hyper-V, Storage Spaces Direct, Network Controllers and such.

The first change to this was that in the 1709 release, NANO was now “containers” only, and what they told was from the beginning was now incorrect, NANO was no longer a choice for modern infrastructure, that was a big change and I did have customers that shifted from “happy face” to “sad face”, but ok, we can now run Core, much bigger, but fine, core will be released both as LTCS and SAC and we can use that for both legacy (in that case the LTCS edition) and for modern infrastructure (in that case SAC).

I’m happy/sorry to say that is not true anymore. The SAC release will not support anything like infrastructure roles, so, no, you cant use it in a modern datacenter, you can use it for one thing only, containers. So developers can either use NAO or Core to build applications, but if you are into infrastructure, you can run the LTCS version, and then you can either pick Desktop Edition or Core.

There are reasons for this, some of them are understandable, some of them not, but it does not matter what I think, this is happening and you need to adjust “back” to the old days.

To summarize:

IT Pro/Admin/Infrastructure:

You will use the LTCS version of Windows Server, current version is 2016 (aka 1607) and the next will be Windows Server 2019, you will upgrade every 2-5 years. You will use either Core or Desktop Edition.


You can runt whatever you want, if you like new features, go for SAC, upgrade/reinstall/redeploy every 18 months or less, or do old style, go for LTCS

You can read the “official” statement here.


Posted in Windows Server | Tagged: | 3 Comments »

Nice to Know – Fix High DPI resolution issues in Windows 10

Posted by Mikael Nystrom on January 19, 2018

Working at a customer, we had major issues with an application. It does not handle the new “Improving the high-DPI experience in GDI based Desktop Apps”.


Using the AppCompat mode by disable the built in functions work:

But, that does not fly for 1500 machines. Using ACT would work, but…

This one is easy…

REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /V "C:\Program Files(x86)\folder\app.exe" /T REG_SZ /D "~ DPIUNAWARE" /F

More info:

"~ HIGHDPIAWARE" = Override high DPI scaling behavior (Application)

"~ DPIUNAWARE" = Override high DPI scaling behavior (System)

"~ GDIDPISCALING DPIUNAWARE" = Override high DPI scaling behavior (System Enhanced)


Posted in ACT, OSD, Windows 10 | Tagged: , , | Leave a Comment »

Nice to Know – What does my home lab looks like?

Posted by Mikael Nystrom on January 11, 2018

I often get the question

– What kind of stuff do you have to runt labs, tests and play with?

I have a understanding wife and a very generous CEO, so here it is…

In my back pack:

1 x HP Studio G3 with 32 GB ram and 2 x 1TB NVME drives

1 x Microsoft Surface Pro 4

The Surface works as my “office” machine, it also runs Insider Preview (fast) and the HP Studio is my LAB/Demo/Dev machine. It runs Windows Server 2016 and contains about 100-150 VM’s

At Home:


I have one full rack and one half rack, the half rack contains 6 HP Micro Server Gen 8, used as test/dev machines, the full rack runs 2 HP ML 350 Gen 8, they run Azure Stack as well Azure Pack in a full Fabric based on HCI and the entire System Center stack

The Case:

I also have a Pelican Case (Yellow) that runs a bunch of Intel NUC’s devices

Posted in Fun | Tagged: | Leave a Comment »

Nice to Know – You need to do a site reset after OS upgrade on your ConfigMgr site server

Posted by Mikael Nystrom on January 11, 2018

Working at a customer, doing an in place upgrade from Windows Server 2008 R2 server with ConfigMgr 1606 to Windows Server 2016.

After the upgrade a connection to the ConfigMgr cannot be made using the console, investigating it and we found out that the Root\SMS namespace has gone, (even running as system it was not to find)

Asking around, no one have seen this, but my friend Johan Arwidmark sent an email to the product team, and the reply was easy to understand (yet, undocumented)


You do need to do a site reset after an OS upgrade, and after that, it all works like a charm

Here is some guidance to doing such upgrade, just don’t forget to run a site reset.


Posted in ConfigMgr | Tagged: | Leave a Comment »

PowerShell is King – Test-NetConnection is annoying, gives me warnings, I don’t want that

Posted by Mikael Nystrom on December 7, 2017

During a conversation someone told me that Test-NetConnection is kind of annoying when scanning for systems and some of them are not online, or missing from DNS or something like that. And that is true, it doesn’t matter if you sending the result down the pipeline, but it does show up in the warning stream.

The annoying way

In the first sample we run Test-NetConnection using the following

$Computers = "SRVDC01","SRVDC02","SRVDC03","SRVHOST301"
$result = foreach($Computer in $Computers){
    Test-NetConnection -ComputerName $Computer -CommonTCPPort SMB

And here is the output, note the warning stream that shows up


The non annoying way

In the second sample we run Test-NetConnection using the following

$Computers = "SRVDC01","SRVDC02","SRVDC03","SRVHOST301"
$result = foreach($Computer in $Computers){
    Test-NetConnection -ComputerName $Computer -CommonTCPPort SMB -ErrorAction SilentlyContinue -WarningAction SilentlyContinue

And here is the output



Posted in Uncategorized | Leave a Comment »

Nice to Know – Mass upgrading Windows 10 Using PowerShell

Posted by Mikael Nystrom on December 5, 2017

Someone asked med a while back

– Is it possible to upgrade our Windows 7,8,8.1 and unsupported Windows 10 machines to a supported version of Windows 10 without a deployment solution?


– You mean without running around to all machines?


– Yes, it is possible

Before explaining how that can be done, let’s be clear, if you have ConfigMgr or Microsoft Deployment Toolkit, that is far better then doing it this way, but you could be in a situation when that is not an option but you still need to achieve the same goal, upgrade to a supported version of Windows 10. (I’ll write another post on how to combine the scripts here with MDT)


Assuming you have a licensed version of Windows 10, the Windows 10 Media, a network and access to all the computers over the network it will be possible to push out an upgrade. This method also works if you are running an older version of Windows 10 and would like to upgrade to a never version of Windows 10. The way to do this is rather easy, we basically need to perform the following steps:

– Enable remote access for PowerShell

– Copy the media down to the computer

– Run a compatibility scan to verify that we can upgrade

– Upgrade

Create a CSV file for computers that should be upgraded:

First of all we need to create a .CSV file with the computers that should be upgraded, the file contains the 3 servers I would like to upgrade to Windows 10.

Content of computers.txt

Store the file in your computer, in my case I stored it in D:\Upgrade2w10\Computers.txt

Enable remote access for PowerShell:

We need to access the computers using Remote PowerShell and therefor we need to enable that. This can be done using various method and one easy/weird/fun way to to that is to use WMI. The script below will connect using WMI and execute two commands on each server:

The following PowerShell script enables WinRM (Remote Access) and Remote PowerShell.

Content of Invoke-ComputerPrep.ps1

The result after running the script is this:


Copy the media down to the computer:

Now when we have access to all the machine, we can copy the media down to each machine and we will do that in a reversed way. We will create a scheduled task on each Windows 7 machine and the scheduled task will then download the content to the local hard drive. You need to edit the settings in this file to match your environment.

Content of Invoke-ImageDownload.ps1

Here is how it looks when you run the script:


Run a compatibility scan to verify that we can upgrade:

Ok, so we have the Windows 10 image in the C:\Source folder of each computer, now lets run the Compat Scan.

The script will connect to each computer, create a plain vanilla .BAT file and then we will remotely execute that:


And here is the result, as you can see all, none of the machines had any issues.



Ok, so the final step. The only thing we need to do is fire up the install program, and for that we use PsExec, it’s old but works for this kind of work.

The script will connect to each machine, create a .BAT file and then we let PSExec execute it.

Content of Invoke-ComputerUpgrade.ps1

Here is the result of running that, as you can see all (you can only see Win-01) of the machines is returning a success (return code 0)


Ok, so, what next, well, since the return code was 0, lets restart them…


The scripts can be downloaded here:


Posted in OS Deployment, OSD, Windows 10 | Tagged: , , | Leave a Comment »

The October 2017 Update – “Inaccessible Boot Device”

Posted by Mikael Nystrom on October 11, 2017

Also known as:

KB4041676 -

KB4041691 –


Affected systems:

This only affects systems that are managed trough WSUS and the patches was approved at the same time as the “delta” updates also was approved. Those updates was never intended to show up in WSUS, they should be deleted/Declined. You should NEVER have Delta updates in WSUS. It was a “woops” somewhere. But if they were approved, and distributed, and download, and installed at the SAME time as the full patch, then you are affected

These should be declined, and they should be gone at the next sync.


After installing the update and reboot, the pc will not boot, instead it gives you ”Inaccessible Boot Device”

Official Solution:

Currently the official solution is to contact Microsoft Support, but it is possible to use DISM.exe or PowerShell to remove the updates or reverse back a folder name.

read about the issue here (from Microsoft)

Information regarding the Delta’s from Microsoft in a forum.

The Quick fix Solution:

A very nice MVP manage to figure out how to remove all the updates using DISM, and yes, it does work like a charm!

(update: If this is a VM, you might need to add more memory. We have found that you need at least 3GB of RAM for WinPE to use larger scratch space.)

Other ways to fix it is:

The idea is to rename the WindowsApps folder and that seems to work for some



Posted in Windows 10, Windows Server 2016 | Tagged: , | 29 Comments »

OSD – Adding Description to the WIM file during Build and Capture

Posted by Mikael Nystrom on October 10, 2017

The default capture function in MDT does not add any description. It is not needed, but can be added by modifying ZTIBackup.wsf. In this case I added the Task Sequence Name, but you can add other things as will, like Task Sequence Description or Task Sequence version. I did this at a demo at Microsoft Ignite last week but I did not post it at that time, so here it is.

The Session from Ignite is here if you would like to see it:

The how:

Modifying the Script

Take a copy of ZTIBackup.wsf, open it in your favorite VBscript editor and look for this section:


At line 436 you will see this:

sCmd = " /Capture-Image /CaptureDir:" & oDrive.Path & "  /ImageFile:""" & sBackupPath & """  /Name:""" & sPrefix & Left(oDrive.Path, 1) & "Drive"" /Compress:MAX /ConfigFile:""" & sWimScriptPath & """ /ScratchDir:""" & oUtility.LocalRootPath & "\Scratch"""

Change that to:

sCmd = " /Capture-Image /Description:""" & oEnvironment.Item("TaskSequenceName") & """ /CaptureDir:" & oDrive.Path & "  /ImageFile:""" & sBackupPath & """  /Name:""" & sPrefix & Left(oDrive.Path, 1) & "Drive"" /Compress:MAX /ConfigFile:""" & sWimScriptPath & """ /ScratchDir:""" & oUtility.LocalRootPath & "\Scratch"""

(The yellow text shows the modification)

The result:

Using Get-WindowsImage will show you that the description is now set to the Task Sequence name:


If you import the WIM file into ConfigMgr you will also see the description set as well as the Comment:



Posted in ConfigMgr, Ignite, MDT, OS Deployment, OSD | Tagged: , , , , | 1 Comment »