Successfully added DaRT to boot image….or did it?

, , , , , , , , ,
Successfully added DaRT to boot image….or did it? Here is how to identify the problem and  a link to fix it!
I was recently onsite with a customer where the proposed design document included MDOP DaRT integration into the boot images. DaRT is a great tool to have because it gives the engineer the ability to remotely connect to the machine while within the WinPe environment. This particular customer is undergoing a massive and understaffed windows 10 migration where every bit of efficiency really makes a difference on deployment nights.
First a quick review on installing MDOP DaRT, Enabling Monitoring, and creating the boot image.
  1.  Install MDOP DaRT on primary site server
  2.  Copy the Toolsx86/64 cab files into proper directories into the MDT deployment share
  3.  Enable Monitoring on deployment share
Deployment share \SERVERD$DeploymentShare
Ports: 9800 (Event port) 9801 (Data port)

Connect to deployment share > Right click on “Monitoring” > Navigate to Monitoring Tab and fill the check box

Once this is filled you will start to see systems as they image from this view. 
DaRT
If you are in an environment that is not really using the MDT deployment share you would still open up the MDT toolkit and modify the CustomSettings.INI. This customer is heavily utilizing the MDT Deployment Share with all the settings applied we can access the “Rules” tab and see the setting is automatically applied after we enabled monitoring. The great part about using the deployment share in this scenario is that we can make constant on demand changes and not have to worry about hash mismatch errors like if were working within the MDT toolkit package.
DaRT
 We are now able to make our DaRT integrated boot image from the console on our primary site server. Begin by selecting “Create Boot Image using MDT” Make sure to select the following optional components “MDAC/ADO Support, and DaRTT”
 
DaRT
From this point we distributed the enabled the boot image for PXE deployment, added drivers, and attach it to a task sequence. In the screenshot below you will notice we are missing something? We do not have the “DaRT Remote Control” option that we should have.

 

DaRT
NOTE: Sometimes when the boot image is “Successfully” created it does not add the “DaRT” tool. I am able to verify this to be a LIE by looking into the PEMananger.LOG located in my temp folder.

C:Users%UserNameAppDataLocalTemp5PEManager.12520PEManager.log

DaRT
When we look at the command that was ran by accessing the “RunCMD.CMD” we see that only the WinPE-MDAD_EN-US.CAB is the only package even attempted to be added.
DaRT
You can investigate further by opening up DISM GUI and searching for any trace of DaRT on the boot image. As you can see DaRT did not even attempt to be installed into the wim.
Manually modify boot image to include Dart functionality by using the script below.
HOW TO FIX IT: Johan Arwidmark has a script available online that I have used to inject the Dart into a newly created WIM.

 

Once we ran the script created by Johan and injected the drivers I was able to start using DaRT tools.
After the USMT toolkit is called and the Gather step starts to run a box on the bottom left will appear  on the system being imaged but minimized. This is your indicator to let you know that you can now use DaRT functionality.

 

DaRT
From the Monitoring Node in the deployment workbench right click the computer we are trying to troubleshoot > Select Properties > Select DaRT Remote Control
DaRT
DaRT
TL;DR
Do not always take the console UI at face value and always verify with log files. Some occasions the console indicates something was done correctly but you need to check the logs. If this happens then you need to go old school and use the tried/true methods. If you run into a problem always do a quick search b/c the Deployment Research guys might already have a work-around.
To vote for this to be fixed from SCCM team please visit the link below.
 https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/32344414-dart-bug
 

USMT Estimation Report

, , , , , ,

USMT Estimation Report

USMT Estimation Report – One of the deliverable items at a customers site was to identify the amount of data each machine would would have to backup. This is important data to capture to help plan your estimated migration times as well as identify systems that will not be able to successfully perform a backup. This data is not something that SCCM will automatically absorb, but Jason Sandy already has a solution for that. We used his script here with a few mods for our environment we were able to capture this information.

let me point out that if you look inside of the MDT Toolkit for ZTIUserState.wsf you will see that it is estimated to need 1.1 times the size of the data you are trying to catpure. This is something that was pointed out from a co-worker.
USMT Estimation Report
OLD Report Visuals
USMT Estimation Report

New Report Visuals

 

USMT Estimation ReportUSMT Estimation Report

 

The new report allows you to look up specific computers, interactive sorting, better visuals, graphs, and more efficient SQL logic.

you will have to modify the CASE WHEN statements to fit your own environment. Please do some testing and then modify for the “USMT Only Time Estimate” column. Several factors go into consideration for determining this value. These are things such as server specs, amount of systems running the task concurrently, bandwidth, etc.

THE RDL: https://gallery.technet.microsoft.com/USMT-Space-Estimator-2c5d728b

SCCM Power Plan SQL Queries

, , , ,

SCCM Power Plan SQL Queries

In one of my customers environments there was a request for a quick review of ConfigMgr SCCM Power Plan settings. This turned out to show us that there were over 20+ power plans in the environment and needed to be reduced. Below is the quick query I came up with for the customer.

— individual systems with power plans and collection they belong to
select
SMS_R_System.Name0 AS [System Name],
V_Collection.Name AS [Collection Name],
__R_MANAGEMENT_CONFIGURATION0.NonPeakPowerPlanName00 AS ‘Non Peak Power Plan Name’,
__R_MANAGEMENT_CONFIGURATION0.PeakPowerPlanName00,
__R_MANAGEMENT_CONFIGURATION0.PowerConfigID00 AS [Collection Power setting Source] from
vSMS_R_System AS SMS_R_System
INNER JOIN POWER_MANAGEMENT_CONFIGURATION_DATA AS __R_MANAGEMENT_CONFIGURATION0 ON __R_MANAGEMENT_CONFIGURATION0.MachineID = SMS_R_System.ItemKey
Inner JOIN V_Collection on V_Collection.CollectionID = __R_MANAGEMENT_CONFIGURATION0.PowerConfigID00
Order by
SMS_R_System.Name0

 

SCCM Power Plan

— collections with count of systems with power plans
select
V_Collection.Name AS [Collection Name],
__R_MANAGEMENT_CONFIGURATION0.PowerConfigID00 AS [Collection Power setting Source],
count (V_Collection.Name) AS Count,
__R_MANAGEMENT_CONFIGURATION0.NonPeakPowerPlanName00 AS ‘Non Peak Power Plan Name’,
__R_MANAGEMENT_CONFIGURATION0.PeakPowerPlanName00
from
vSMS_R_System AS SMS_R_System
INNER JOIN POWER_MANAGEMENT_CONFIGURATION_DATA AS __R_MANAGEMENT_CONFIGURATION0 ON __R_MANAGEMENT_CONFIGURATION0.MachineID = SMS_R_System.ItemKey
Inner JOIN V_Collection on V_Collection.CollectionID = __R_MANAGEMENT_CONFIGURATION0.PowerConfigID00
Group by
v_Collection.Name,
__R_MANAGEMENT_CONFIGURATION0.NonPeakPowerPlanName00,
__R_MANAGEMENT_CONFIGURATION0.PeakPowerPlanName00,
__R_MANAGEMENT_CONFIGURATION0.PowerConfigID00

 

SCCM Power Plan

In a future blog post I’ll drop a massive amount of sql queries you should find helpful in any environment.