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