Recording OSD Videos and BIOS Screens

I have recorded some end-to-end OSD videos that show a zero touch BIOS to UEFI OS deployment (from a single task sequence without PXE) in order to show that this could be done. I have also captured screen shots from Dell, Lenovo and HP BIOS screens to have when presenting on the BIOS/UEFI topic – it is an easy way to show the settings in the UI. Many of you are probably wondering how I am able to capture these videos and screen shots as it can be tricky to do even with the right equipment.

For the capture device, my good friend Johan Arwidmark (who has expensive tastes in gadgets) talked me in to getting the Epiphan DVI2USB 3.0 USB video frame grabber. It is not cheap, but will get the job done and works much better than the other, cheaper solutions. It captures DVI, HDMI and VGA. It also comes with software that allows you to do video recording or screen shot captures. I do use this from time to time, but you really need to get a different codec otherwise your video file sizes will be huge. There is one called FFdshow that you can down load from Epiphan here. The other thing that I don’t like is that the software will stop recording when the device loses a signal (like a reboot on the device you are capturing). You can configure it to continue recording and it will start recording to another file. Not a show stopper, but a little annoying to me.

I ended up using Camtasia 8 for recording videos. It treats the device as a webcam and it continues to record even if the device loses a signal during a reboot. I recently upgraded to Camtasia 9 (which looks much better on high-res displays like my Surface Book), but they dropped the ability to record only from a webcam. In other words, you need to record part of the screen and the webcam and then delete the screen recording after the fact – almost annoying as the split files. Not happy with this, I started looking for another option.

I use Snagit almost daily for taking screen shots and I remembered that they added the ability to also do screen recordings a few versions back. I figured I would see if it could record the webcam and sure enough it did! Now for the real test, could it do what I wanted it to do – record uninterrupted in a single (reasonable size) file even across reboots?

With the Snagit Capture utility open, click on the Video tab:


Then simply turn the Webcam on and select the capture device:


Click on the Capture button and this will bring up the following menu where you can adjust the screen resolution to the desired size. The following is running on my Surface Book at 3000 x 2000. The device I am capturing at 1920 x 1080 is a Dell Latitude E6430 (getting ready to do a Zero Touch Windows 7 BIOS with 3rd party disk encryption to Windows 10 UEFI with BitLocker recording):


Click record when ready and edit the result in Snagit or Camtasia.

P.S. Snagit also makes animated GIFs. And yes, when going into the BIOS UI it sometimes shows a split screen, but it corrects the image shortly after as you can see below.


Originally posted on

Create multiple partitions on ANY USB Flash Drive

I have seen a few blog posts lately that talk about splitting large WIM files in order to get them to fit on a USB flash drive that is formatted as Fat32. I am not exactly sure why you would want to do that when you don’t have to, as it sounds like extra work to me (but hey, if you like extra work then be my guest).

In my previous post, USB Flash Drives, UEFI and large WIMs, I showed how you can create multiple partitions on certain USB Flash Drives that were either already set as a fixed disk or could have the removable bit flipped using a special utility. Having multiple partitions is useful when you need to boot a UEFI system off the USB Flash Drive and install an operating system. UEFI needs a Fat32 formatted partition in order to boot. The problem with Fat32 is that it has a maximum file size limit of 4GB. Custom images (WIMs) can easily exceed 4GB in size (even the install.wim for Windows Server 2016 is larger than 4GB), which prevents them from being copied to a Fat32 formatted partition. In order to over come this, you would need either need to split the WIM or install it from a file share (provided you have network connectivity) or from another NTFS formatted partition/drive.

Starting in the Windows 10 Insider Preview build 14965, Diskpart now allows you to create multiple partitions on ANY USB Flash Drive – even ones that have the removable bit set.


The following two USB Flash Drives were ones that I could not flip the removable bit nor get multiple partitions on them previously (note that they both still show as Removable):

SanDisk Ultra:




In order to copy files to the second partition, you will need to use the Windows 10 Insider Preview build 14965 (or later). Windows 10 1607 cannot read the second partition (yet), which means that current Windows setup (Server 2016 or Windows 10) might have an issue reading it (in other words I haven’t fully tested that part yet).  Now time to experiment more with this and the new WinPE found in the Windows ADK Insider Preview

Originally posted on

How to Deploy Dell Command | PowerShell Provider with ConfigMgr


Dell provides multiple tools for getting and setting their BIOS/UEFI settings. In previous posts, I have talked about Dell Command | Monitor, which can be used to inventory Dell specific hardware settings using Configuration Manager (see How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 1 and How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 2). I have also showed How to create a Dell Command | Configure Package in ConfigMgr  that can be used in a task sequence to make BIOS/UEFI changes. The Dell Command | Configure utility, also know as CCTK, can be used to get values as well as set values. Dell also has the Dell Command | PowerShell Provider that allows you to get and set BIOS/UEFI settings with (you guessed it) PowerShell. Now you are probably wondering why do I need this PowerShell Provider when I have the CCTK? Good question!

It really comes down to the task at hand and how you plan to create a solution for it. If you simply just need to set a setting or two, then the CCTK might be the best bet. But if you are looking to get information and then execute an action, well then PowerShell is going to be a better tool for the job (think about Configuration Manager Settings Management). The downside is that you need PowerShell version 3.0 or later (for DellBIOSProvider 1.1), which mean that you will need to add PowerShell to your Boot Images if you plan on using it in WinPE (which adds around 100MB to the size).

So lets jump in and see what it takes to get the Dell Command | PowerShell Provider deployed using Configuration Manager. The first thing you want to do is install the latest version (DellBIOSProvider 1.1 is the most current version at the time of this blog). On a Dell test system that has access to the Internet, download the latest version from the PowerShell Gallery (BTW – the download links to the Dell Support site on the Dell Command | PowerShell Provider TechCenter site have not been updated and still point to version 1.0).

  1. On your Dell test system, open PowerShell and run the following command to download the PowerShell Provider from the PowerShell Gallery (it may prompt you to install some additional items first):
    Save-Module -Name DellBIOSProvider -Path c:\temp
    NOTE: You could distribute the commands on the PowerShell Gallery page if you allow all of your computers to connect to the Internet and install modules from the PowerShell gallery. Otherwise, continue reading for how to deploy it with Configuration Manager.
  2. Copy the entire contents to your Application source repository. I have created the following subdirectory structure in my Application source repository: \\ContentSource\Applications\Dell\Command-PowerShell Provider\1.1\x64 and copied the DellBIOSProvider folder into this directory.
  3. Create a file called Install-x64.ps1 in this directory with the following contents:
    #Copy the DellBIOSProvider files into the Windows PowerShell Modules directory
    Copy-Item -Path "$pwd\DellBIOSProvider\" -Destination "$env:ProgramFiles\WindowsPowerShell\Modules\DellBIOSProvider\1.1" -Recurse -Force
    #Import the DellBIOSProvider module into current session only for success/fail testing during deployment
    #Either modify default system profiles or start scripts with the following command
    Import-Module "DellBIOSProvider"
  4. Your Application source directory should now contain the DellBIOSProvider folder and Install-x64.ps1.
  5. In the ConfigMgr Console, create a new Application, select Manually specify the application information and click Next.
  6. On the General Information tab, Fill in Dell Command | PowerShell Provider for the Name, Dell for the Publisher, 1.1 for the Software version, check Allow this application to be installed from the Install Application task sequence action without being deployed and click Next.
  7. On the Application Catalog tab, optionally enter additional information and select an icon (I like to use the icon from the CCTK GUI) and click Next.
  8. On the Deployment Types tab, click the Add button.
  9. On the General tab of the Create Deployment Type Wizard, select Script Installer from the Type drop down and click Next.
  10. On the General Information tab, enter Install-x64 and click Next.
  11. On the Content tab, browse to your Application source repository (I use \\ContentSource\Applications\Dell\Command-PowerShell Provider\1.1\x64). For the Installation program use: powershell.exe -ExecutionPolicy Bypass -file “.\Install-x64.ps1” (NOTE: you depending on how your ConfigMgr PowerShell Client setting is configured you might not need the -ExecutionPolicy Bypass in the command line).
  12. On the Detection Method tab, click Add Clause.
  13. On the Detection Rule window, leave the Setting Type to File System and the Type to File. For the Path enter: %PROGRAMFILES%\WindowsPowerShell\Modules\DellBIOSProvider\1.1 and for the File or folder name enter DellBIOSProvider.dll. Uncheck This file or folder is associated with a 32-bit application on 64-bit systems. Leave the setting This file system setting must exist on the target system to indicate presence of this application and click OK. NOTE: Dell has not increased the version of this DLL to 1.1. It is still listed as The other alternative is to use the timestamp on the file if detecting presence is not good enough for your environment.
  14. Back on the Detection Method tab, verify that the newly created detection method rule shows up and click Next.
  15. On the User Experience tab, change the Installation behavior to Install for System, the Logon requirement to Whether or not a user is logged on, the Installation program visibility to Hidden and click Next.
  16. On the Requirements tab, click Add.
  17. On the Create Requirement, select the 64-bit operating systems that you support in your environment and click OK.
  18. Back on the Requirements tab, add any other requirements that are necessary for your environment and click Next.
  19. On the Dependencies tab, add any dependencies that are required in your environment and click Next. NOTE: the Dell PowerShell Provider does have a dependency on the Visual C++ Runtimes so if these are not deployed in your environment you may need to add them as a dependency. For the exact versions, see the Dell Command | PowerShell Provider documentation.
  20. On the Summary tab, verify the information and click Next.
  21. On the Completion tab, verify the success and click Close.
  22. Back on the Deployment Types tab, click Next. NOTE: use the same process on a 32-bit system if you support 32-bit in your environment.
  23. On the Summary tab, verify the information and click Next.
  24. On the Completion tab, verify the success and click Close.
  25. You will now see the Application with one Deployment Type listed in the console. Now we need to distribute the content to the Distribution Point(s). Right-click and select Distribute Content.
  26. On the General screen of the Distribute Content Wizard, click Next.
  27. On the Content screen, click Next.
  28. On the Content Destination screen, select the desired Distribution Point Group (or Distribution Point) and click Next.
  29. On the Summary screen, confirm the settings and click Next.
  30. On the Completion screen, verify the wizard completed successfully and click Close.
  31. Now we need to create a collection that contains only Dell workstation clients that we can use to deploy the newly created Dell Command | PowerShell Provider Application. See step number 35 on How to Inventory Dell BIOS and UEFI Settings with ConfigMgr Part 1 on how to do this.
  32. Create a test deployment of the Dell Command | PowerShell Provider Application and verify that it is installing correctly. Create a collection called Dell Command | PowerShell Provider 1.1 and limit it to the previously created Dell Workstation Clients collection. Add a few Dell test machines. Back in the Software Library in the ConfigMgr Console, right click on Dell Command | PowerShell Provider Application and select Deploy.
  33. On the General screen of the Deploy Software Wizard, select the Dell Command | PowerShell Provider 1.1 collection and click Next. Note: Be sure to thoroughly test this in a lab first!
  34. On the Content screen, verify that the content has already been distributed to the Distribution Point Group(s)/Distribution Point(s) and click Next.
  35. On the Deployment Settings screen, choose Required for the Purpose and click Next.
  36. On the Scheduling screen, select the desired schedule and click Next.
  37. On the User Experience screen, select the desired settings and click Next.
  38. On the Alerts screen, click Next.
  39. On the Summary screen, verify the settings and click Next.
  40. On the Completion screen, verify the wizard completed successfully and click Close.
  41. Next, verify that it installed successfully by looking in Software Center or browse to C:\Program Files\WindowsPowerShell\Modules on a test system and you should see the DellBIOSProvider directory with all of the files. Open up an elevated PowerShell prompt and run: Import-Module DellBIOSProvider. If this is successful you can run Get-DellBiosSettings and it should list out the BIOS settings for the current system.

Now that Dell Command | PowerShell Provider is deployed, we can run a number of PowerShell commands on Dell systems to both get and set Dell BIOS settings (even some settings that Dell Command | Monitor does not report). In the future I will write more posts on how you can use ConfigMgr to leverage this new PowerShell provider.

Originally posted on

Arizona Systems Management User Group 10-year Anniversary Meeting – A Taste of MMS Recap

img_0731The Arizona Systems Management User Group 10-year Anniversary Meeting – A Taste of MMS has come and gone. It was a fantastic way to celebrate 10 years of AZSMUG with an all-star line up and a surprise special guest, David James – Director of Engineering for Configuration Manager.



Kicking off the meeting, Peter Daalmans started the day presenting Session 1 on How to cope with the rapid release of ConfigMgr.


He then presented the first sponsor session: Parallels Mac Management for our sponsor Parallels.


Next up was Kent Agerlund presenting Session 2 of the day on What’s new & trendy in Microsoft EMS.


Session 3 of the day was presented by Brian Mason – SQL Server 2016 & ConfigMgr – What you need to know.


Lunch was presented by our gold sponsor 1E. The pizzas were so large, user groups in Texas would be jealous.

1E’s Shaun Cassells presented the lunch time sponsor session – Windows 10 Servicing in the Real World.


After lunch we jumped right into Session 4 of the day with the All Speakers (plus David James) Q&A. This turned out being an excellent interactive discussion with great insights on things from David and Michael Niehaus. Everyone was engaged even after those extremely large pizza slices.


We also posted several Twitter polls throughout the day and used these as discussion topics during the Q&A (BTW if you are not on Twitter, get on Twitter!):

Poll 1: What version of ConfigMgr are you using in production?


Poll 2: How many ConfigMgr clients do you manage?


Poll 3: Are you using Microsoft EMS today?


Poll 4: What version of SQL are you using with ConfigMgr?


Poll 5: Do you have ConfigMgr integrated with Intune?


Poll 6: When do you plan on deploying Windows 10?

Michael Niehaus presented Session 5 on What’s new for enterprises in Windows 10 1607.


Finishing out the day with Session 6, Greg Ramsey did a deep dive session on Using PowerShell with ConfigMgr.


The examples that he covered can be download from his blog. Midway through Greg’s session the Midwest Management Summit afternoon cake arrived and it was yummy.


Wrapping up the day for a final speaker picture. Thanks again to all of the speakers for presenting and our sponsors Microsoft, 1E, Coretech, Midwest Management Summit and Parallels for making this event possible. I am already looking forward to the 20-year anniversary meeting!


Originally posted on

USB Flash Drives, UEFI and large WIMs

If you have already started working with UEFI devices, then you have probably figured out a few of the gotchas when it comes to booting these devices. First, you need to boot the device using the native architecture. So, if the device you are attempting to boot is a 64-bit device, then it needs to boot with a 64-bit boot image. Second, if you are using a USB Flash Drive, then you probably have realized that UEFI devices will not boot from a NTFS formatted flash drive. The flash drive needs to be formatted using FAT32 in order to boot UEFI. That is all fine and dandy, but what happens if you have a large WIM file (one that is greater than 4GB, like the Windows Server 2016 install.wim that is 4.38GB) that you need to copy onto the flash drive? The short answer is that you can’t, at least on the FAT32 partition. You can always split the WIM, but what fun is that? Plus, it sounds like extra work to me. Lucky for you, with the right USB flash drive and the information in this blog post, I will show you have you can fit that 4+GB WIM on your flash drive and still boot UEFI (because if you are still using BIOS, stop reading now and switch your system to UEFI).

The trick is to create multiple partitions on your flash drive, just like you do (or like Windows setup does for you) when you install Windows in UEFI mode. The problem is a limitation for creating multiple partitions on removable media. By flipping the ‘removable bit’ on the flash drive, you can then use diskpart to create a bootable FAT32 partition (large enough to fit all of the boot files) and then a second NTFS partition that contains the large WIM file (along with the other setup files that are needed. There are a few utilities out there on the Internet, like BootIT from Lexar (although I could not get it to work on some new Lexar USB flash drives that I just bought), that may or may not do the trick for you (NOTE: this does not work on all USB flash drives and you might toast your flash drive so use at your own risk). There are also some other tools that you might come across if you search long enough (and on some sketchy sites), but once again – use at your own risk. Hopefully one day soon, Windows will allow us to partition removable media since eventually most devices will be class 3 UEFI and WIM files are getting larger, not smaller.

Lucky for me, the SanDisk Ultra 16GB (Model SDCZ45-016G), which I bought at Costco several years ago, already shows up as a basic disk type (in other words, not removable), and allows me to create multiple partitions so that I can make it bootable in a UEFI configured system and still have the ability to copy large WIM files onto it.


It also looks like these are still available on Amazon (although I cannot guarantee that they are like the Costco model apart from the matching characters on the model number).

The process:

  1. Plug in the flash drive and open up an elevated command prompt. Run the following commands:
    list disk
    select disk x (where x is the disk # of your flash drive)
    clean (this is a destructive process, so be sure you have the correct drive and have backed up anything you want to keep)
    create partition primary size=500
    format fs=fat32 quick
    create partition primary (this creates the second partition)
    format fs=ntfs quick
  2. For this example, we will use the Windows Server 2016 ISO (you could also do the same with Configuration Manager OSD Media). Mount the ISO (in this example, it is on drive E:) and copy the subfolders boot and efi and files bootmgr and bootmgr.efi to the fat32 drive that was created above (in this example, it is on drive F:).
  3. On the fat32 drive create a subfolder called sources.
  4. On the Windows Server 2016 ISO drive, navigate to the sources directory. Locate the boot.wim and copy it to the fat32 drive in the sources subfolder.
  5. Copy the entire contents of the Windows Server 2016 ISO drive to the ntfs drive (in this example, it is on drive G:).
  6. Optionally name the partitions on the USB flash drive for easy identification.

Now you should be able to boot right up using the USB flash drive in UEFI mode and in this case proceed to install Windows Server 2016.

Originally posted on

Disable “Check online for updates from Microsoft Update” in Windows 10

windows10bannerIf you are already managing your Windows 10 systems (currently 1607 and below) with System Center Configuration Manager, then chances are you might want to prevent certain users from also being able to “Check online for updates from Microsoft Update.” before you have had a chance to fully test the latest cumulative update or feature update. Unfortunately, when users go into Settings > Update & security they will see a Check for updates button and below that, a Check online for updates from Microsoft Update link.


By clicking that link, it will bypass System Center Configuration Manager and go directly to Microsoft Update to see what the latest updates are available and start installing them once they download. One way that you can prevent this from happing is to enable the Group Policy setting: Do not connect to any Windows Update Internet locations:


If you enable this setting, you will not only disable the ability to check online for updates from Microsoft Update, but you will also disable the ability to install software from the Windows Store. Now if you have not started using the Windows Store yet, then this might not be a problem. Also, this policy is only effective if the Specify intranet Microsoft update service location policy is set (which it should be if you are using System Center Configuration Manager for Software Updates):



Once enabled, the Check online for updates from Microsoft Update link will disappear:


Hopefully we will see an option in the future that will allow for the ability to disable this link without disabling the ability to install apps from the Windows Store.

Originally posted on

Arizona Systems Management User Group 10-year Anniversary Meeting – A Taste of MMS

microsoft-tempeThe history of AZSMUG:

We have been planning this meeting for a long time and I really wanted to make this a special meeting. I got the idea to start the user group from a session that I attended at the Microsoft Management Summit in 2006. A Microsoft MVP by the name of Ed Aldrich gave a session on starting a local user group and I followed up with him afterwards for help on get things started (ironically Ed is now my coworker at 1E – although neither of us worked at 1E when we first met).

I also went through several Microsoft employees trying to find someone (a Microsoft blue badge employee) that would sponsor us so that we could host the meetings at the Microsoft office (back then it was at Central and Thomas). After striking out multiple times, I came across a Microsoft person by the name of Harold Wong (many of you probably know him from the TechNet Events). At the time, Harold was traveling as much, if not more than I was, but he always made time for us  when we wanted to have a meeting (even during his personal time, as most of our meetings were in the evenings). So a huge thanks to Harold for helping out all of these years! (BTW – he still travels a lot)

Our very first meeting was on September 21st, 2006. I think we had about 12 people attend the very first meeting – ironically many of those people still attend the user group today, so another thanks to all of you for sticking with us throughout the years!

Now, I know it would have been epic to have the 10-year meeting on the same exact day this year, but due to logistics October 7th turned out to be the ideal day. I personally am super excited for this meeting and hope to see as many of you there as possible.

So what is a Taste of MMS? The AZSMUG 10-year Anniversary Meeting IS a Taste of MMS. MMS, the Midwest Management Summit, is a systems management conference that provides top quality real-world sessions in a relaxed, setting. There is plenty of time for questions or even talking to speakers and peers.

So what makes this 10-year Anniversary Meeting a Taste of MMS? Every single speaker (Kent Agerlund, Brian Mason, Peter Daalmans, Greg Ramsey, Michael Niehaus and myself) has presented multiple sessions at the previous MMS conferences, which makes this meeting a ‘taste’ of what you get by attending the next MMS.

Registration is filling up fast, so be sure to book your ticket soon.
10 Years of AZSMUG
6 Speakers
4 Microsoft MVPs
1 Day (Friday, October 7th 2016, Tempe, AZ Microsoft Office)

Mike Terrill
AZ Systems Management User Group

Originally posted on