MDT Naming Trick - Show Machine's Existing Name

MDT Pre-Populate Name Trick

You ever had it when a machine needs to be rebuilt because it's either crashed completely or is suffering issues that you know, deep down in your technical heart, a rebuild will sort it all out.

So what do you do?

You press that magical network boot key, PXE boot that machine and start the MDT process.  Fantastic, you the go through the wizards to eventually get to the "Computer Name" stage where it then prepopulates the name with a MiniNT name and you go.. hmm.. bugger what the name of the machine again?

You look for a sticker, which has obviously fallen off or worn away, you think i'll need to reboot to get to the login screen to find the name there.. which isn't an option if the machine is totally broke.

Wouldn't it be nice to have the machine put in its actual, existing name in place of that MiniNT name, still editable if required, but there for a reference at least.  Well you can, using some minor trickery and awesomeness.

Thanks to Michael Klinteberg from Technet forums, a simple script copied into the Scripts folder in your deploymentshare and two lines added to your customsettings.ini file will give you the desired effect.

Copy the below script into notepad and save it as "UserExit.vbs"

Function UserExit(sType, sWhen, sDetail, bSkip)
 oLogging.CreateEntry "entered UserExit ", LogTypeInfo
 UserExit = Success
End Function

Function GetOfflineComputername()
On Error Goto 0

 If oEnvironment.Item("OSVERSION")="WinPE" Then
  Dim CompName : CompName = ""
  Dim ret, sOldSystem : sOldSystem = ""
  For Each drv In Array("C", "D", "E", "F")
   If ofso.FileExists(drv & ":\windows\system32\config\system") Then
    sOldSystem = drv & ":\windows\system32\config\system"
    Exit For
   End If
  Next
  oLogging.CreateEntry "Mounting Offline registry " & sOldSystem, LogTypeInfo
  ret = oShell.Run ("reg load HKLM\z " & sOldSystem, 0, True)
  If ret = 0 Then
   CompName = oShell.RegRead("HKLM\z\ControlSet001\Services\Tcpip\Parameters\Hostname")
   If CompName <> "" Then
    oLogging.CreateEntry "Found old computername '" & CompName & "'", LogTypeInfo
   Else
    oLogging.CreateEntry "Old computername name could not be found", LogTypeWarning
   End If
  Else
   oLogging.CreateEntry "Could not mount offline registry " & sOldSystem, LogTypeWarning
  End If
  oShell.Run "REG UNLOAD HKLM\Z", 0, True  
 Else
  CompName = oShell.ExpandEnvironmentStrings("%Computername%")
 End If

 GetOfflineComputername = CStr(CompName)
  
End Function

Editing MDT 2012 Lite Touch Wizard Screens

At work we are still deploying Windows XP due to a need for our customers, we have automated the installation to a large extent however the biggest bugbear we have had is the need to select a task sequence and then to click next before giving the computer a name.

Here you can see where we are going from and to

Here is the original Task Sequence selection screen

Followed by the Name your computer screen

Followed by our modified screen which combines both Task Sequence and computer name into one pane.


We are aware that by prestaging machines we could avoid this issue however for our needs this would be overkill and an additional time overhead, what we wanted was the ability to unbox and name machines then walk away.

While poking around I found that the wizard you navigate around when using the Lite Touch Deployment is controlled using a collection of xml and vbs scripts, these are stored in the deploymentshare\scripts folder.

With a bit of copying and pasting between files I have been able to put the boxes for computer name and task sequence selection into a single pane, as we have used the deploymentshare rules settings to skip the other pages it means that we can pxe boot then simply enter a name and pick TS all in one page then walk away.
Apologies for this but this one is going to be a bit wordy

The files you will be modifying are

Deploywiz_Definition_ENU.xml
Deploywiz_SelectTS.xml
Deploywiz_ComputerName.xml

The files are named fairly well by Microsoft, the Definition file is the master file which guides you through the wizard, it calls the required files in turn. We will be making minor changes to this file but as always we should make a backup before we touch anything, just in case. The SelectTS file is the one which lists the task sequences available and allows us to choose one, the ComputerName file is self explanatory, however it also contains possibilities for you to enter domain join values, in our usage scenario we do not use these as the values are provided in the rules for the deploymentshare.

Open the ComputerName file and copy everything between the <body></body> tags, switch to the SelectTS file and paste all of this in just below the <body> tag and before the existing code, return to the ComputerName file and copy the <Initialization> and <Validation> section, again return to the SelectTS file and paste this in along with the existing values. Move to the top of the file and add the following as one line

<CustomScript>DeployWiz_ComputerName.vbs</CustomScript>

into the <global> section.

Change the <Pane id> values to something more appropriate such as

<Pane id="Name_Computer_and_SelectTaskSequence" title="Enter Name and pick a Task Sequence">

Save this file with your initials at the beginning and a more appropriate name, mine is called MHDeployWiz_Name_Computer_SelectTS.xml this will allow the deploymentshare files to be replaced in the future if an upgrade requires it but your files should remain in place.

You have now done the hard work.

Open the Definition file and edit the section 

<Pane id="SelectTaskSequence" reference="DeployWiz_SelectTS.xml">  <Condition><![CDATA[UCASE(Property("SkipTaskSequence"))<>"YES" ]]></Condition> </Pane>

to contain our newly made xml file so it should read 

<Pane id="SelectTaskSequence" reference="MHDeployWiz_Name_Computer_SelectTS.xml">  <Condition><![CDATA[UCASE(Property("SkipTaskSequence"))<>"YES" ]]></Condition> </Pane>

You can then remove completely the following section

<Pane id="ComputerName" reference="DeployWiz_ComputerName.xml">  <Condition><![CDATA[UCase(Property("SkipDomainMembership"))<>"YES" or UCase(Property("SkipComputerName"))<>"YES"]]></Condition>  <Condition><![CDATA[Property("DeploymentType")<>"REPLACE" and Property("DeploymentType")<>"CUSTOM" and Property("DeploymentType") <> "StateRestore" ]]></Condition> </Pane>

If you do not remove this then you will have another screen (which we are trying to remove) asking for the computer name, however its value will have been taken from the previous screen.

Save your file and test your deployment.

I have attached my modified files at the end of this post so you can see some which I have working in my test environment, feel free to play with them for your own use.I have used these modified files to deploy XP, "7 and W8 Consumer Preview,  I am sure that much more can be done with the xml files in MDT so there may be more posts to follow, but for now that’s it.

Good Luck

Reference Script Files

MDT - Missing Intel Network Card Drivers

[SOLVED] MDT Error Driver Missing on DELL Computers, Intel Networking Card.

A Connection to the deployment share (\\Server\DeploymentShare$) could not be made. The following networking device did not have a driver installed. PCI\VEN_8086 ... ..

Now MDT, as we all [should] know, runs within the WinPE environment which means the drivers we download from places like Dell, Samsung, Intel, RM, HP etc.. will not need to just be for their desired operating system but also compatible with the WinPE environment.

So lets think, you've done everything right, you've extracted the drivers on your network somewhere and through the deployment workbench you've imported them to the nicely laid out file structure I hope you have. You've now also updated the deployment share and (because you had the time) you even regenerated the litetouch boot images and re-imported those into WDS.

You've done everything right, then you get the error you see above.

What this means is that some drivers (most probably your Intel HDD or Networking) are not compatible with WinPE. Unfortunately, Intel say that some chipsets/network card drivers are not yet compatible with these drivers and you are told to wait for them to be updated.

Well if you were clever enough to choose Dell Kit, Dell have already done this for you. Enter the following link:

Dell WinPE Driver Compatibility Pack

Direct Link:

http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats?c=us&l=en&s=bsd&cs=04&DriverId=R298040

I'm not going to be completely bias to Dell, but so far they are the only manufacturer to put all the problem drivers in one 33MB download. Not only that they have also given a full compatibility list of which machines are affected by this.

Dell have this system known as KACE and rumour has it they are looking into integrating MDT as their main deployment method, therefore every piece of kit they will sell for the "business to enterprise" level consumer will most likely be checked to see if the components are MDT compliant. This is just an FYI if your main method of deployment is MDT and you are going through procurement.

Give it a go, I have yet to see it fail when I encounter the above error.

If you find that another manufacturer has done the same, please comment below and i'll add the links here. I'm sure there are people out there finding this saying "This is my exact problem, but I have a Samsung" or something like that.

Thanks for reading, Hope this helps,

ITMagician

[EDIT 01-06-2013]

The above links no longer point to a relevant file in Dells site, however by performing a search from the support site you can still obtain the WinPE Driver pack by searching for WinPE, the search currently returns the following WinPE 4.0 Driver pack A01 and has been updated to support WinPE 4.0 and Windows 8 operating systems, the page contains a full list of systems it will work with.

Dell Optiplex 390 fails to apply GPO settings

At work we have been deploying Dell Optiplex 390’s with XP using an MDT task sequence, the build works perfectly however once the machine attempts to apply group policy we have failures, this causes the machine to fail to install allocated msi packages. Obviously not a great situation to be in.
Following some research I have found that the issue appears to occur mostly in situations where a client is using a Gig speed network card and where network connections are teamed. The issue appears to be caused by the network card switching between speeds and full/half duplex to find the mode it can operate at. By adding a registry key we can prevent this checking from happening which will provide a more stable connection during the all important startup process.
This solution has been tested to work in our environment, obviously your mileage may vary and if you choose to make this change you do so at your own risk, playing with the networking settings in Windows may break more than it fixes however in our testing this has been an easy and successful workaround.

The key details are as follows
Key Location : HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Key Name : DisableDHCPMediaSense
Key Type : Reg_Dword
Key Value : 00000001

These settings can either be added using a reg entry or a command line as follows

reg add HKLM\System\CurrentControlSet\Services\Tcpip\Parameters /v DisableDHCPMediaSense /t REG_Dword /d 00000001

In our case we have added a command line near the end of our task sequence which we have filtered using WMI in a way similar to the one we used in a previous post. In this case the WMI filter we used is as follows

Select * from Win32_ComputerSystemProduct WHERE Name LIKE "%Optiplex 390%"

Again we are running this against the root\cimv2 namespace. This query could be repeated in the task sequence options filtering for additional hardware which exhibits this particular issue, thereby allowing you to keep a smaller number of task sequences in your deployment share.

Update : 29-06-2012

We have begun rolling out Samsung N200 laptops, these also exhibit the issue with needing DHCPMediaSense to be set, for ease of use here is the WMI code needed

Select * from Win32_ComputerSystemProduct WHERE Name LIKE "300V3A/300V4A/300V5A/200A4B/200A5B"

Reference:

Technet User Discussion

Serverfault Question

Dell Laptop freefall sensor driver kills MDT Win XP

 

We have been building a large number of Dell Latitude E5410 and E5420 laptops using an MDT task sequence to install Win XP. The task sequence does not use a wim file for xp but is effectively the same as running a RIS style setup process.

We downloaded the driver pack which Dell make available for the E5420, in theory this contains all drivers needed in a single cab file, however we encountered an issue in that during setup the installation WMI either got corrupted or failed to install. Since MDT needs to use WMI in order to run this left us with a partly installed XP machine which fails to complete the task sequence. This issue did not present itself when we ran a test build with Windows 7.

As part of our troubleshooting we manually downloaded the drivers individually and added them to MDT, we missed the ST Microelectronics Freefall sensor as it was wrapped up in an installshield exe file but the task sequence completed succesfully. Helpfully Dell included a readme with the exe file which explained that we could run the setup.exe with the /s switch and this would allow a silent install with no reboot when done.

Using this information we imported the setup file into the MDT Deploymentshare as an application then added it near the end of the task sequence. In order to not need an extra task sequence just for the laptops we edited the options for the application installation step and added the filtering options to only apply if true and used a WMI query to test for the model type. The WMI query used is as follows

WMI Namespace : root\cimv2

WQL Query : Select * from Win32_ComputerSystemProduct WHERE Name LIKE "%Latitude E54%"

 

Query entry dialog box

Completed query entry in task sequence options.

 

Using these settings will allow the installation of Windows to complete leaving you with a fully working WMI installation and all of the drivers to give you a nice clean Device Manager.

Deploying Drivers

Have you ever just finished building a load of PCs, to have someone come up and ask for some dodgy piece of hardware to be installed on all PCs, and the drivers required are unsigned, and aren't pre-packaged in an easily deployable silent package or MSI. Or you've been given some dodgy new hardware (you know the companies I'm talking of), to install.

Well its easier than you think to deploy drivers as either a script or as part of an MSI package. I am assuming that you, the reader, are capable of writing a script and/or creating a suitable MSI, so I will not insult your intelligence by giving you a completed script/msi. If you're anything like me (God help you if you are!) you'll learn better by doing, rather than seeing.

Anyway, by using a small executable provide by Microsoft, DPInst.exe, available as part of the Windows Driver Kit (WDK), Download available here, we can indeed make drivers available on any windows OS system, to be installed as and when needed.

Once you have download and installed the WDK (btw you only need to install the tools part), you can find different architectural/language versions of the DPInst.exe in C:\WinDDK\7600.16385.1\redist\DIFx\dpinst (assuming you install to the default location, and the version number hasn’t changed since writing).

Place the correct version of DPInst.exe in with your driver .inf files. If you were to run the dpinst.exe now, you would be presented with a wizard for installing the drivers onto the system. If you were to step through the wizard, it will complete, but it will only be successfully if the drivers are signed.

However, that’s not what we really want, we need no user interaction at all, and we need to be able to install unsigned driver*. To install any drivers without the end user noticing, call the DPInst.exe with the following commands:

/Q  - This is for quiet install with no user interaction,
/LM – This is for unsigned drivers.

Now the drivers are installed, or technically they are made available to be installed when the hardware is connected. Now if your drivers are signed that is the end of the story, however, if like me, you have been given a host of cheap hardware made in china, with unsigned drivers, you will need to adjust the following 2 Group Policies*:

Computer Configuration>Windows Settings>security Settings>Local Policies>User Rights Assignment:
Policy: “Load and unload device drivers”
Setting: DomainName\Domain Users

User Configuration>Admin Templates>System>Driver Installation:
Policy: “Code signing for device drivers”
Setting: Enabled – ignore

Click here for a full overview of DPInst, and here for a full list of command switches.

* Please note that installing unsigned drivers and/or modifying Group Policy is done at the readers own risk, and the writers of “Thoughts of a Primary School Tech” are in no way responsible/liable for any loss/damage caused to any system(s) by following the instructions provided here. Whilst every effort has been made to ensure this works correctly on any windows system, your milage may vary.

Modifying Deploymentmonitor.hta

In a previous post I mentioned a utility from the Microsoft Deployment Guys which allows you to monitor how your Litetouch build is progressing. In this post I am going to show how you can modify the utility to make it a little more appropriate to your own needs.


The utility itself is a HTA file which can be edited in a text editor, my editor or preference is notepad++ as it supports several different languages and will indent and colour code languages it understands as necessary to make things easier to follow.


Onto the file itself:


Lets start early on at line 7


MINIMIZEBUTTON="NO"


for some reason the Deployment guys didn't feel the need to minimize the app to the taskbar, however in the world of education we are often doing at least three things at once and to keep the screen as uncluttered as possible you can edit the line to


MINIMIZEBUTTON="YES"


and instantly you have the option to put things out of the way.


If you are using this in a fixed location you may want to prepopulate the location for the script to check for log files, this can be done by editing line 278 from

<input id="lblEventShare" type="text" name="lblEventShare" />&nbsp;&nbsp;&nbsp;&nbsp;

to

<input id="lblEventShare" type="text" name="lblEventShare" value="\\servername\Share$" />&nbsp;&nbsp;&nbsp;&nbsp;



To automatically check the autorefresh box when starting the app change line 292 from

<input id="chkAutoRefresh" name="chkAutoRefresh"type="checkbox" /> to <input id="chkAutoRefresh" name="chkAutoRefresh"type="checkbox" checked/> You will still need to click the refresh button once to start the process. To change the frequency that the app automatically checks for updates edit line 203 iTimerID = window.setInterval("Refresh", 120000) You will also want to edit line 292 to reflect the changed time you have set. &nbsp;Auto-refresh every 2 minutes (press &#39;Refresh Display&#39; to start)every 2 minutes (press &#39;Refresh Display&#39; to start) Hopefully these changes will make this great utility more useful in your deployment efforts.

Import drivers into MDT maintaining folder structure

I recently got an email from Johan Arwidmark's mailing list at Truesec, this mail contained a powershell script to import drivers into MDT whilst maintaining the folder structure, this will allow multiple driver imports for a range of hardware without dumping all of the drivers in on huge lump in the 'Out Of Box Drivers' folder.

The Drivers folder layout will follow the format as follows

Drivers\

     |------OS 1\

     |          |--------->Manufacturer1\

     |          |                   |----------->Model1\

     |          |                   |----------->Model2\

     |          |--------->Manufacturer2\

     |                              |----------->Model1\

     |                              |----------->Model2\

     |------OS 2\

                |--------->Manufacturer1\

                |                   |----------->Model1\

                |                   |----------->Model2\

                |--------->Manufacturer2\

                                   |----------->Model1\

                                   |----------->Model2\

     

You will need to edit the first three lines of this script to match your environment, otherwise it should be good to go.

$DriverStore = "C:\Drivers"
$MDTDSRoot = "C:\MDTBuildLab"
$PSDriveName = "DS001"

Add-PSSnapIn Microsoft.BDD.PSSnapIn
New-PSDrive -Name "$PSDriveName" -PSProvider MDTProvider -Root $MDTDSRoot

# Proces each of the operating systems folders

Get-ChildItem "$DriverStore" | foreach {

    # Display the folder we are processing

    Write-Host "Processing $($_.FullName)" -ForeGroundColor green;Write-Host ""

    # Create the operating system folder in the MDT 2010 Deployment Workbench

    new-item -path $PSDriveName":\Out-of-Box Drivers" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose

    # Process each of the vendor folders

    $OSFolder = $_

    Get-ChildItem $_.FullName | foreach {

       

        # Display the folder we are processing

        Write-Host "Processing $($_.FullName)" -ForeGroundColor green;Write-Host "" 

        # Create the vendor folder in the MDT 2010 Deployment Workbench

        new-item -path $PSDriveName":\Out-of-Box Drivers\$OSFolder" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose

       

       # Process each of the model folders

       $VendorFolder = $_

       Get-ChildItem $_.FullName | foreach {

            # Display the folder we are processing

            Write-Host "";Write-Host "Processing $($_.FullName)" -ForeGroundColor green;Write-Host "" 

   

           # Create the model folder in the MDT 2010 Deployment Workbench

           new-item -path $PSDriveName":\Out-of-Box Drivers\$OSFolder\$VendorFolder" -enable "True" -Name "$($_.Name)" -ItemType "folder" -Verbose

           # Import the drivers into MDT 2010 Deployment Workbench

           Import-MDTDriver -Path $PSDriveName":\Out-of-Box Drivers\$OSFolder\$VendorFolder\$($_.Name)" -SourcePath "$($_.FullName)" -Verbose

          }

    } 

}

During testing of this script I encountered errors while creating folders, this error appears to be down to the code using  '-enable "True"' powershell spits this out with some ugly red lettering, I have found that by removing this part of the code the script appears to run perfectly and populate MDT as we hope.

Monitoring MDT Litetouch task sequence

When using MDT to deploy machines in school, we currently have the system set so that we enter a computer name and pick an image type then everything else is automatic, we have the machines put into the computers container in AD, this is due to the fact that we have not set MDT to automatically name and place machines yet.

If the need to rebuild a machine arises we will start off the process and leave the machine running, the task sequence will lock the workstation wherever necessary due to the system being logged on as an admin account, however the difficulty lies in knowing when the build has completed and being able to move the computer to its correct OU.

If we move the machine too soon then other scripts will run which may affect the task sequence such as the installation of antivirus which may quarantine needed files. If we fail to move the machine then it will be built and on the domain but will have no curriculum software,

MDT has a useful feature which can write log files as each stage of the task sequence is completed, using this you can monitor how far along a machine is.

To set this up:

1. Create a share on a server, you can use either an open or hidden share.
2. Edit the Default section in your deployment share customsettings.ini to include the following line.
   
   EventShare=\\Servername_or_IP\Sharename$
   
   
3. Update your deployment share.

Any new builds you start will write log files to the shared folder, initially the log will have a MININT name but as soon as the computer is given a correct name the logs will use this.

To make it easier to monitor what is going on in these logs the Deployment guys have written a utility to display the current info in an easier to read format, this can be downloaded from the original post.

Essentially the utility is a HTA which will monitor a given folder which you set, the optional refresh period of two minutes will allow you to keep a background eye on the build process.

To use the utility, download and extract the zip file from their page to a relevant location, double click on the DeploymentMonitor.hta file. Enter the path to the share you created and click refresh. The utility will return the contents of the folder, if you wish to have the utility update every two minutes tick the checkbox and then click refresh.


This utility will not clear out the folder so you will need to perform some housekeeping from time to time depending on how many builds you perform as the folder will gradually fill up with old info.


Disclaimer::
As with all of the Deployment/Scripting Guys utils they are provided with no warranties or guarantees of any kind, their use is entirely at your own risk.

sparkeh blog: Making Installshield deployments silent

Whilst trawling through edugeek.net this morning I found this post which could be useful for anyone who wants to make an Installshield installation silent. Although I already knew about the /s switch using /r was new to me. Hopefully he will continue to post new information that I don't have the time to find out for myself.

sparkeh blog: Making Installshield deployments silent



I have posted the text below as found on the site:


"Every so often I come across something that I am astounded that I don't already know. This might be a lot of old chips to you but whilst looking for tips on deploying Installshield installers I stumbled across guidance on making the deployment silent.
As you probably know, Installershield deployments usually come as a setup.exe file. This is not always the case but then you can usually grab the setup.exe and other setup files (cab file for example) from a temp folder when you launch the installer.
If you want to make the installation silent you need to use the /s switch, however the installer will look for and answer file called setup.iss. If you are luck then your software vendor will have provided one. Not very often though in my experience.
The good news though, is that you can create one yourself by running the installation with the record switch /r. This dumps a setup.iss file in c:\windows. Move this to the same directory as the installer and you can run the installation silently (with /s) with all the options you chose in the recorded run through. Well almost ;)

There is one sting in the tale to be aware of though. Due to a forked process starting up and completing before the installation is complete, you need to add another switch (/sms) to force the process to wait until the installation is complete.
So in summary, once you have a installer with its setup.iss in place you can run 'setup.exe /s /sms'."