My blog is here to help solve issues I have encountered and solved, publish scripts I have written, and educate others in understanding areas that are not well covered. These blogs cover many different aspects of IT, but are mainly concentrated on software deployments.
Recently, I upgraded to the new MDT 6.3.8450.1000. It was a fresh install of the new MDT product in which I created an entirely new MDT share for our Windows 10 build. I had done an upgrade to the other MDT share that contains the Windows 7 builds, and it busted all of them at which point I had to do a restore.
After creating the new task sequences, applications, drivers, OS, and packages, I went to capture my first Windows 10 image and got the error below.
The third line down was the key to the error. I went in and looked at the ZTIUserState.wsf and saw this line: sScanStateFolder = oEnvironment.Item("DeployRoot") & "\Tools\" & sUSMTArchitecture & "\" & sUSMTVersion
I went to the MDT deployment share and under it to tools\x64\USMT5. There was nothing in that directory. I then looked at tools\x86\USMT5, and there was nothing there either. It was evident that this was the cause. To fix this, I needed to download the latest WADK, which also required uninstalling the current version first. Once it was downloaded, I checked off the User State Migration Tool (USMT) option. Once it completed, I copied over the USMT tool x86 and x64 from
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\x86
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\User State Migration Tool\amd64
to the following directories
Once I did this, the task sequence can now capture an image with no problems.
While recently writing an MSI uninstaller script, I needed to be able to associate the GUID with the applications name. In the process, I was finally able to associate the MSI files inside the Installer folder with the application.
You may wonder why you want to know this. Most of this is probably just for general knowledge, but there are a couple of instances I can think of on why you might want to know. For one, I used it as described above. You may also want to know this if you are checking to see if the MSI is available to do an uninstall or a repair.
The MSI and MSP files inside the %WINDIR%\Installer folder are associated with the installed application or update in the following registry location:
I am working on the Windows 10 image, and part of this project is converting to UEFI. We do have several older systems that are still in production because systems that are used for temporary or loaner aren't as important to keep up-to-date. I use the oldest model system when creating a reference image so I am sure the image will work across all models. I first started with a Dell Optiplex 990 and quickly realized it was not compatible with Windows 10 UEFI because of missing BIOS features. I then moved up to a Dell Optiplex 9010, and it included secure boot. Once I set the BIOS for UEFI and rebooted, there was no more screen. The monitor was blank. The first thing I tried was turning off the machine, unplugging the power cord, holding in on the power button for 15 seconds, removing the battery and holding in on the power button for 30 seconds, and then reinstalling the battery before turning the machine back on. This did not reset the BIOS, and the screen was still blank. The next thing I did was to remove the DVI cable. It was replaced with the VGA cable and was plugged into the built-in motherboard video port. When I powered on the system, I got the following screen to display.
The instructions provided do not work. The video card I experienced this with was the AMD Radeon HD 6350. What I did to resolve this was to completely remove the video card, connect the VGA cable, and then power the system up. After that, I got the following screen.
Once I got this screen, I was able to go into the BIOS. It ended up being two settings in the BIOS. The first was the Enable Legacy Option ROMs. It must be turned off for the secure boot to be enabled. It was this option that actually caused the screen to be blank when using the video card.
The second option is the Secure Boot Enable. To use this, Enable Legacy Option ROMs has to be turned off. Once I set these back to the defaults, the system was then able to be boot up and be displayed on the monitor using the DVI video card. It is not the computer if it is an Optiplex 9010 or higher. It is the video card that cannot support the secure boot in Windows 8 or higher due to the lack of UEFI Option ROM drivers as described by Dell and ZDNet. The solution would be to replace the video cards that can support the UEFI Option ROM drivers.
When I installed the new MDT 6.3.8450.1000 to build the deployment package for Windows 10 1709, I ran into issues with the operating system deployment. In the process of building out the new task sequence, I also decided to convert over to UEFI. The OS was laying down, but it was installed on the wrong drive letter, D: instead of C:. After trying many things, I finally decided to abandon the Format and Partition Disk task sequence provided by Microsoft and create my own using PowerShell.
The first step of this is to create the text configuration file. I could have created the file and had the build point to it, but I would rather PowerShell do this. After researching the failed build from other issues, I found it created the following drives listed below:
Boot (EFI) with the drive letter W:
(MSR) with no designated drive letter
Windows (Primary) with the drive letter C:
Recovery (Recovery) with the drive letter E:
To achieve this, I use two task sequences in MDT as shown below,
The first task sequence consists of the PowerShell one-liner as a Run Command Line shown below. The one-liner creates the DiskpartHDD.txt file on the WinPE bootable drive (X:). The numbers I used for the sizes came from MDT.
This is the PowerShell one-liner within the task sequence:
As often as Java must be updated, I wanted to have an auto installer that would make the update a breeze. The way this installer has been written is it will first determine if the system is x86 or x64. At that point, it will uninstall the old version first and then install the x86 if the system is 32-bit, or it will install the x86 and x64 versions if the system is 64-bit. The parameters are the same for both 32-bit and 64-bit versions so you can define the parameters once.
When a new version is released, all you need to do is swap out the installer executables and update the package in SCCM. The script will find the appropriate executable associated the architecture, as Oracle includes the architecture within the filename.
You can download and view the installer code from my GitHub site.
I recently encountered an application that uses the Inno Setup installer. Part of my process when I deploy an application is to also create an uninstaller. While creating the uninstaller, I decided to make a function for uninstalling Inno Setup installed applications.
The way I have written this function is that you need to use the exact name as displayed in the add/remove programs for the AppName parameter. The function will then query the Add/Remove programs registry entries to get the quiet uninstall string and execute it.
While building out the Windows 10 reference image task sequence, it dawned on me that I should be making sure the latest Dell Application Component Updates are installed. Since this is a reference image, the system drivers being up-to-date is not essential to me because they will be stripped during the Sysprep process.
I devised this one-liner that can be implemented as a command line task sequence to check for the latest application component updates only. To limit this down to just application component updates, you will need to open the Dell Command | Update GUI application to create an XML file to reference from the command line. Once in the GUI app, click on the Settings icon. Click on Update Filter. Under Recommendation Level, I checked everything. Under Update Type, I checked Application Software. Everything else is left unchecked. Configure every other settings tab the way you want. Now click on Import/Export and click Export. Export the XML to the desired UNC path in which the one-liner below can access.
As for the one-liner below, update the <UNC Path> to the location where the Applications.XML file is located. It does not need to be called Applications.XML. That was my choice.
Putting this into MDT or SCCM is easy. Once you have the one-liner customized and tested, copy and paste it into a Run Command Line task sequence as shown below. That is all it takes to implement this.
Recently, Dell released the BIOS updates covering systems starting with the Intel Family 6 Model 42 and later processors. This is the first part of the patching process. The second part is to apply all windows updates, which I also included all optional updates. That was my personal preference. The third step is to apply the appropriate KB4088878 patch.
The first two systems, Dell Optiplex 990s with Windows 7 64-Bit, I did these patches on were successful. GRC's InSpectre tool was executed and returned the following.
The next two failed. These systems were Windows 7 32-Bit installed on Dell Optiplex 990s with 64-Bit processors. The BIOS was patched with the latest A23 version Dell had published. The windows updates were all installed. When the windows6.1-kb4088878-x86_7512ab54d6a6df9d7e3d511d84a387aaeaeef111.msu was applied, the following crash screen appeared when the OS booted back up.
One tactic I tried was to configure the registry to clear out the page file when the system shuts down by changing the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown to a 1. The next thing I did was to boot the system into safe mode to execute the patch. I got the following message.
In conclusion, the only solution is to have the hardware architecture match the OS architecture. If they match then applying the appropriate patch will be successful.
Here is a note on patching. Applying the latest BIOS does not pass the GRC Inspectre test. The Microsoft OS patch must also be applied for the system to pass the test.
Ever since the Spectre and Meltdown issues arose, we have been waiting on patching, at least reliable patching. Microsoft has taken it on itself to patch systems for the vulnerability. ExtremeTech wrote an excellent article on Microsoft's solution which gave me the thought to write a script for telling which systems are compatible. To determine the minimum family and model compatible with the patch, I used the data from this Intel page that associates family and model to the microarchitecture code name. I converted the family and model from hexadecimal to decimal. That is how I came up with the bare minimum being Family 6 Model 42.
NOTE: The ExtremeTech article includes the Haswell processor as also being compatible. We do not have any Haswell processors in my environment, so I am not able to know what the minimum family and model are for Haswell. If you do have Haswell processors in your environment, I would appreciate you running the following PowerShell cmdlet and reply here with the output so that I can include it in the script. Thanks.
The script can be executed using the new Scripts tool in SCCM, which is how this was done in my environment.
While working on the Windows 10 upgrade project, I ran into a situation which I needed the information from an MSU file for the task sequence. Specifically, I needed the KB number. The first thing I did was to try and use the same method used in retrieving info from MSI and MSP files by trying to query the database. That does not work with an MSU file. An MSU is nothing more than a zipped up file of several files. In each MSU file, there is a *Properties.txt file which contains all of the info.
This script contains the function Get-MSUFileInfo which will retrieve all available info on the MSU. I designed it so that it creates an extracted folder in the relative path of the script. The MSU is then extracted to that extracted folder. Next, the script will read all of the contents of the *Properties.txt file into an object. Finally, the extracted folder is deleted.
Here is an example of the script retrieving the info into an object:
You can download the script which contains the function from my GitHub site. I put the function into a full script for easy testing in your environment.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.