AlexSemi's Blog https://docs.microsoft.com/archive/blogs/alex_semi/feed.xml Alexey Semibratov's Blog on OSD/SCCM/MDT Mon, 19 Dec 2016 18:28:42 GMT en-US hourly 1 New version of drivers harvester copies all OEM drivers to separate folder https://docs.microsoft.com/archive/blogs/alex_semi/1066 Mon, 19 Dec 2016 18:20:23 GMT https://blogs.msdn.microsoft.com/alex_semi/?p=1066 Drivers Harvester I've updated Drivers Harvester Tool with a new version. Now it takes a parameter "-d" with directory following after space where you can save your drivers to. But the biggest change is that the tools now creates two subfolders: LoadedOEMDrivers - all drivers, that where loaded into memory OtherOEMDrivers - the rest of OEM drivers. Can be drivers that not loaded into memory plus older versions of drivers   The tool does not capture all drivers sometimes, so you end up re-imaging your machine to find that missing driver. This happens because the driver was not loaded into memory, but it's still an OEM driver and causing a "bang" in device manager. So now it copies all OEM drivers regardless if they are loaded into memory or not to OtherOEMDrivers, so you can easily identify the missing one.  ]]> Drivers harvester now ignores PNF files! https://docs.microsoft.com/archive/blogs/alex_semi/drivers-harvester-now-ignores-pnf-files Tue, 01 Sep 2015 11:40:28 GMT https://blogs.msdn.microsoft.com/alex_semi/2015/09/01/drivers-harvester-now-ignores-pnf-files/ I updated Drivers Harvester tool addressing the issue with PNF files I described here

Enjoy!

]]> Harvesting drivers from C:WindowsSystem32DriverStoreFileRepository and PNF files https://docs.microsoft.com/archive/blogs/alex_semi/harvesting-drivers-from-cwindowssystem32driverstorefilerepository-and-pnf-files Tue, 11 Aug 2015 13:41:58 GMT https://blogs.msdn.microsoft.com/alex_semi/2015/08/11/harvesting-drivers-from-cwindowssystem32driverstorefilerepository-and-pnf-files/  

In my blog article with harvesting drivers tool here I described how to harvest drivers from the repository. I've being used that process on a different projects, and I noticed, that exactly the same driver with an exception of one file gets imported creating a duplicate.

After a little bit of digging, we've found the culprit - the PNF files. Here is a quick description:

Windows Precompiled INF File

The .pnf file extension is also used to represent a Windows Precompiled Setup Information File. Windows creates a PNF file for each INF file to ensure efficient processing. Typically, PNF files are stored in the %windir% or %windir%\Inf folder.

 

So, basically, that file gets created by P&P manager on every machine and unique on every machine! That, effectively, makes our content unique and you keep creating duplicates of your drivers.

So here is what you need to do - Delete all PNF files from captured drivers before importing them to SCCM or MDT!

Give it a shot. Delete all PNF files from your repository and re-import. Check how many duplicates you got rid off.

 

You are welcome :)

 

]]> Compare two ZTIWindowsUpdate logs with this script to see which patches added and removed https://docs.microsoft.com/archive/blogs/alex_semi/compare-two-ztiwindowsupdate-logs-with-this-script-to-see-which-patches-added-and-removed Mon, 10 Aug 2015 09:57:41 GMT https://blogs.msdn.microsoft.com/alex_semi/2015/08/10/compare-two-ztiwindowsupdate-logs-with-this-script-to-see-which-patches-added-and-removed/ The standard MDT step called "Install Windows Updates" calls ZTIWindowsUpdate.wsf script that essentially installs all updates from Microsoft Updates site. I, personally, recommend this method when building your golden images.

Now, when somebody asks you, what has changed, the answer "the image was updated with latest patches" may not be sufficient. The attached script will compare two ZTIWindowsUpdate.logs - the one you have from previous build and the new one and gives you two lists - the list of patches that were added and the list of patches that have been removed. Now you are in control what gets in your images and what gets removed.

 

Usage: cscript ZTIWindowsUpdateLogCompare.wsf /OldLog:<Old Log File> /NewLog:<New Log File>

Thank you for using my work.

 

 

ZTIWindowsUpdateLogCompare.zip

]]> Back to blogging! https://docs.microsoft.com/archive/blogs/alex_semi/back-to-blogging Fri, 07 Aug 2015 12:21:19 GMT https://blogs.msdn.microsoft.com/alex_semi/2015/08/07/back-to-blogging/ I have not written any new blogs due to some technical difficulties and being extremely busy in last 8 months. Now the technical issues have been fixed, and I will share everything I was working on lately.

It's going to be about OSD, SCCM, MDT, Windows Client and more. Stay tuned :)

]]> Bullet-proof version of ZTIWindowsUpdate.wsf https://docs.microsoft.com/archive/blogs/alex_semi/bullet-proof-version-of-ztiwindowsupdate-wsf Fri, 07 Aug 2015 12:21:00 GMT https://blogs.msdn.microsoft.com/alex_semi/2015/08/07/bullet-proof-version-of-ztiwindowsupdate-wsf/  

I'm removing this page soon, since the new ZTIWindowsUpdate.wsf from MDT 2013 U1 works just fine.

 

Many of you use ZTIWindowsUpdate.wsf script that is a part of MDT to build your golden images. So do I. I came across two issues, that I fixed and I would like to share the modified version of this script.

  1. On Windows 7 and Office 2010, there is a patch, that becomes applicable again, and does not get re-installed because ZTIWindowsUpdate.wsf remembers everything it installed and skips it. Now, if the script finds something that was already installed, it does not skip it, it re-installs it, saying "REINSTALLING - " and then patch name and GUID
  2. Sometimes, when it can't connect to Windows update, it just fails. I replaced this logic with reboot and retry

 

Just replace the standard copy of ZTIWindowsUpdate.wsf with the one attached here and try to build your golden images.

 

Enjoy!

]]> Mask all important passwords in all MDT logs https://docs.microsoft.com/archive/blogs/alex_semi/mask-all-important-passwords-in-all-mdt-logs Thu, 13 Nov 2014 15:58:00 GMT https://blogs.msdn.microsoft.com/alex_semi/2014/11/13/mask-all-important-passwords-in-all-mdt-logs/ By default, MDT logging routine masks the entire line if it sees the word "password".

I came across the problem with UDI, when using ZTIUserSatat.wsf, the encryption key is exposed in clear text in the logs with command line when ScanState.exe or LoadState.exe is called because there is no word “password” in the logging line.

Regardless, you don’t want to hide the whole line for troubleshooting purposes, only the value of that variable that gets exposed.

So, I modified ZTIUtility.vbs adding logic to hide those variables. Here is what was added to CreateEntry function


 
Public Function CreateEntry(sLogMsg, iType)
Dim sTime, sDate, sTempMsg, oLog, bConsole, sMaskedVar


' Each of the operations below has the potential to cause a runtime error.
' However, we must not stop operation if there is a failure, so allways continue.

On Error Resume Next


' Special Handling for Debug vs. Non-Debug messages

If not Debug then

If iType = LogTypeVerbose Then
Exit Function ' Verbose Messages are only displayed when Debug = True
Elseif iType = LogTypeDeprecated Then
iType = LogTypeInfo ' Deprecated messages are normally Info messages
End if

' Suppress messages containing password

If Instr(1, sLogMsg, "password", 1) > 0 then
sLogMsg = "<Message containing password has been suppressed>"
End if

' Mask variables containing passwords
For Each sMaskedVar in Split(oEnvironment.Item("MaskedVariables"),",")
sLogMsg = Replace(sLogMsg, Trim(oEnvironment.Item(sMaskedVar)), "<password has been suppressed>")
Next

Else ' Debug = True

 

Make changes in your CustomSettings.INI by adding a new property

[Settings]
...

Properties=MaskedVariables

....

 

[Default]

...


MaskedVariables=_SMSTSReserved2,OSDUserStateKeyPassword

...

 

 

Enjoy!

]]> StartMBAMEncryption script updated! https://docs.microsoft.com/archive/blogs/alex_semi/startmbamencryption-script-updated Wed, 23 Jul 2014 17:14:40 GMT https://blogs.msdn.microsoft.com/alex_semi/2014/07/23/startmbamencryption-script-updated/ In my previous blog post here: https://blogs.msdn.com/b/alex_semi/archive/2013/08/12/start-mbam-encryption-on-bitlocker-pre-provisioned-and-windows-to-go-drives.aspx?CommentPosted=true#commentmessage

I talk about starting MBAM encryption as a part of SCCM Task Sequence, saving the key to MBAM database. Apparently, the script did not work on Surface Pro or pretty much any other tablet - it needs one more registry key under Policy\FVE - OSEnablePrebootInputProtectorsOnSlates

I added this key and it fixed the problem. The version was updated.

 

Thank you.

 

]]> Dart Remote recovery starts too late in your OSD MDT Deployment? Here is the fix. https://docs.microsoft.com/archive/blogs/alex_semi/dart-remote-recovery-starts-too-late-in-your-osd-mdt-deployment-here-is-the-fix Mon, 07 Jul 2014 13:18:54 GMT https://blogs.msdn.microsoft.com/alex_semi/2014/07/07/dart-remote-recovery-starts-too-late-in-your-osd-mdt-deployment-here-is-the-fix/ I hope everybody leverages DART Remote Recovery remote agent in their OSD task sequences with MDT integration.

It works in conjunction with MDT Monitoring, and it starts when first "Use MDT Package" step runs in PE. This step is calling ZTISCCM.WSF script. The problem is, that there are lots of other errors, related to drive formatting, selection of the task sequence and so on that may happen the way before ZTISCCM.wsf runs.

So, how do we launch RemoteRecovery.exe passing all parameters to MDT monitoring? One of the ways to do that is by using the pre-execution hook. I created a custom script, which is essentially a stripped-down version of ZTISCCM.wsf script that you can run in your pre-exec hook and your computers will show up in Monitoring almost immediately after you click "next" in firs OSD window.

Here is what you're going to need:

  1. SCCM 2012 SP1 or later
  2. MDT package files
  3. I assume that the standard method already working in your environment, if not - here is a great article by Johan that explains how to get it to work: https://www.deploymentresearch.com/Research/tabid/62/EntryId/78/Using-DaRT-8-and-MDT-2012-Update-1-Monitoring-with-ConfigMgr-2012-SP1-Beta.aspx
  4. AutoIt 3. You don't have to use it, I use it to suppress the "dos box" with script running by providing TS engine the EXE file instead of WSF. TS Engine always runs VB Scripts with CSCRIPT.EXE causing a big "dos" box with script running. Our users should not see it. Download it from here: https://www.autoitscript.com/site/autoit/

Here is how to implement earlier appearance of computers with Dart Remote Recovery console in MDT monitoring.

  1. Download two attached scripts
  2. Copy the to some location on the server, I'll call it \\server\Packages\PreExecHook here
  3. Copy the following files from C:\Program Files\Microsoft Deployment Toolkit\Templates\Distribution\Scripts to this folder:
    1. ZTIDataAccess.vbs
    2. ZTIUtility.vbs
    3. ztiRunCommandHidden.wsf
    4. ZTIGather.wsf
    5. ZTIDiskUtility.vbs
  4. Using Aut2exe.exe tool from AutoIt compile PreExecHook.au3 to x86PreExecHook.exe and AMD64PreExecHook.exe checking "64 bit" flag
  5. Go to properties of your Boot Image and go to "Customization"
  6. Check "Enable prestart command" and type in "X:\SMS\PKG\SMS10000\x86PreExecHook.exe" without quotes for x86 boot image and "X:\SMS\PKG\SMS10000\AMD64PreExecHook.exe" for x64 boot image
  7. Check "Include Files for the prestart command" and use the path where you copied all the files to - i.e. \\server\Packages\PreExecHook 
  8. After clicking "OK" it will ask you to update Distribution Points. Go ahead and do it.

That's it! Now it will have your Remote Recovery Running earlier, like on this picture below - even before the task sequence selection!



 

EnableDart.zip

]]> Prevent "half-baked" computers in your environment with special handling of failing steps in State Restore phase https://docs.microsoft.com/archive/blogs/alex_semi/prevent-half-baked-computers-in-your-environment-with-special-handling-of-failing-steps-in-state-restore-phase Tue, 17 Jun 2014 12:03:37 GMT https://blogs.msdn.microsoft.com/alex_semi/2014/06/17/prevent-half-baked-computers-in-your-environment-with-special-handling-of-failing-steps-in-state-restore-phase/ I bet you've seen technicians, imaging computers, ignore failed task sequences when in Live OS already and giving those computers to the users. They make a judgment that computer was imaged "good enough" and it's a hassle to escalate it and have some SCCM admin to look at it, investigating what happened.

This simple script will "sabotage" boot on non-UEFI machine, making it sort of unusable (but this can be easily fixed, though). Here is how to implement it:

 

1. Copy attached script to your MDT package Scripts\Custom folder. Update your MDT package.

2. Add a new "Run Command line" step to the last, "Gather Logs and StateStore on Failure" group right under first "Gather" step:

 

MakePartitionInactiveOnFailure.zip

]]>