jump to navigation

It’s GUID To See You CMD er…. August 28, 2012

Posted by Micah Rowland in Uncategorized.
1 comment so far

It’s been far too long as always. New projects, new pits, but every now and then you realize how much you take some things for granted have to improvise from scratch.

I was tasked with modifying an old cmd script to add an event log entry at the beginning of the scripts run and an event log entry when it completed. To avoid cluttering the Application event log or one of the other default event logs that I lovingly refer to as event junk drawers, I created my own log with the New-EventLog cmdlet in PowerShell. After that, I added calls at the beginning and end of the cmd script that ran powershell.exe using the -Command argument and passed a short block of powershell commands.

What I did not forsee was the possibility of the cmd script running concurrently with an already running instance of the script, thus jumbling the logs and making it impossible to match a start log with its correct end log entry. I needed some way to uniquely identify each set of logs. That’s when I came up with my guid idea! (get it? good idea = guid idea… forgive the pun, I promise it will be the last)

That’s right, if I generated a guid in the cmd script and stamped that same guid in the start and end event log entries, I could match them up later. If this was a pure PowerShell script, I could simply call the [System.GUID]::NewGUID() .Net function and walk away. Unfortunately, cmd scripting leaves a little to be desired in terms of flexibility, so I broke out my old command scripting references, fired up Bing and went to work.

A GUID is a random string made up of 32 hexadecimal digits grouped in a {8-4-4-4-12} format. My first step was to get a random number in a cmd script. Enter the %random% variable. When evaluated by the command interpreter, %random% returns a (pseudo)random number between 0 and 32768. Applying a modular operator gave me my pseudo-random hexadecimal digit in decimal format.

set /a tempdec=16*%random%/32768
echo %tempdec%

Pass that decimal number through a set of cmd if statements and out pops a proper pseudo-random hexadecimal digit. I present the hex-o-matic pseudo-random number generator:

set /a tempdec=16*%random%/32768
if %tempdec% equ 0 (set digit=0)
if %tempdec% equ 1 (set digit=1)
if %tempdec% equ 2 (set digit=2)
if %tempdec% equ 3 (set digit=3)
if %tempdec% equ 4 (set digit=4)
if %tempdec% equ 5 (set digit=5)
if %tempdec% equ 6 (set digit=6)
if %tempdec% equ 7 (set digit=7)
if %tempdec% equ 8 (set digit=8)
if %tempdec% equ 9 (set digit=9)
if %tempdec% equ 10 (set digit=A)
if %tempdec% equ 11 (set digit=B)
if %tempdec% equ 12 (set digit=C)
if %tempdec% equ 13 (set digit=D)
if %tempdec% equ 14 (set digit=E)
if %tempdec% equ 15 (set digit=F)
echo %digit%

Now I just need 31 more. My first instinct was to drop my pseudo-random hex-o-matic code inside of the cmd script version of a iterative for loop

FOR /L %a (1,1,32) do ACTION

and call it a day. Unfortunately, that was too easy. %random% uses the current time as its seed, and when the FOR command is run, it gets the time at launch and provides that time value to the code in its care every time it is requested. That means that %random% uses the same time value and generates the same pseudo-random number every time it is called in the FOR command.

There was only one thing to be done, 32 successive hex-o-matic blocks stacked end to end, each adding one hexadecimal digit to the guid.

set /a tempdec=16*%random%/32768
if %tempdec% equ 0 (set guid=0)
if %tempdec% equ 1 (set guid=1)
if %tempdec% equ 2 (set guid=2)
if %tempdec% equ 3 (set guid=3)
if %tempdec% equ 4 (set guid=4)
if %tempdec% equ 5 (set guid=5)
if %tempdec% equ 6 (set guid=6)
if %tempdec% equ 7 (set guid=7)
if %tempdec% equ 8 (set guid=8)
if %tempdec% equ 9 (set guid=9)
if %tempdec% equ 10 (set guid=A)
if %tempdec% equ 11 (set guid=B)
if %tempdec% equ 12 (set guid=C)
if %tempdec% equ 13 (set guid=D)
if %tempdec% equ 14 (set guid=E)
if %tempdec% equ 15 (set guid=F)

set /a tempdec=16*%random%/32768
if %tempdec% equ 0 (set guid=%guid%0)
if %tempdec% equ 1 (set guid=%guid%1)
if %tempdec% equ 2 (set guid=%guid%2)
if %tempdec% equ 3 (set guid=%guid%3)
if %tempdec% equ 4 (set guid=%guid%4)
if %tempdec% equ 5 (set guid=%guid%5)
if %tempdec% equ 6 (set guid=%guid%6)
if %tempdec% equ 7 (set guid=%guid%7)
if %tempdec% equ 8 (set guid=%guid%8)
if %tempdec% equ 9 (set guid=%guid%9)
if %tempdec% equ 10 (set guid=%guid%A)
if %tempdec% equ 11 (set guid=%guid%B)
if %tempdec% equ 12 (set guid=%guid%C)
if %tempdec% equ 13 (set guid=%guid%D)
if %tempdec% equ 14 (set guid=%guid%E)
if %tempdec% equ 15 (set guid=%guid%F)

... (30 more of the above block)

Now I had a wonderful string of 32 hex digits in a row. Enter the cmd script substring syntax: %VARIABLE:~[STARTINDEX],[NUMBEROFCHARS]%

So we take our %GUID% string and…

set GUIDF={%GUID:~0,8%-%GUID:~8,4%-%GUID:~12,4%-%GUID:~16,4%-%GUID:~20,12%}

VOILA! Out pops

{329674F9-97A7-CC6C-A0DA-DB21ED8EA0D3}

 

So the next time you whine about how PowerShell should include a Get-GUID cmdlet, just remember, it used to take 577 lines of cmd script to accomplish what $GUID = [System.GUID]::NewGUID() does in one. Ain’t the future grand?

Advertisements

Deploying Silverlight Applications (XAP) February 17, 2012

Posted by Micah Rowland in Uncategorized.
add a comment

It has been far too long since I last wrote and I thought I’d address a new type of application to deploy: Out-of-Browser Silverlight applications.

The Quest

A customer recently decided to spruce up its tablet/slate fleet by including some simple third-party Silverlight applications. These applications are normally downloaded and installed using a web browser. So the question was raised, “Can we install this programatically as part of the imaging process?” My interest was piqued and I embarked on my foray into Silverlight deployment.

We’ll use the Fandango Windows Slate located (for now) at http://images.fandango.com/mobile/slate/ as our example.

Upon navigating to the above web address, the site checks to see if the application has already been installed. If not, the user is prompted to Tap to Install, a simple feat to accomplish if you have fingers.  After tapping the prompt, a security warning dialog box appears and after a short countdown allows the installation by clicking/tapping the Install button.

Breaking out Sysinternals Process Monitor and filtering the data reveals the Silverlight.Configuration.exe, a prime suspect. A quick right-click Properties action and a tap on the Process tab gives us a place to start. The command-line being executed is:

“C:\Program Files (x86)\Microsoft Silverlight\4.0.60831.0\Silverlight.Configuration.exe” -installtrustedApp 3835182041.images.fandango.com 231aa8

The next step was to see if this command alone would install the application. Uninstall, cmd, paste, enter. No error message… but no program in the start menu and nothing in Programs and Features. A dead end? What could I be missing?

Time to break out Sysinternals Process Explorer. Let’s watch the install happen real-time and see what other related parent and/or child processes may be involved. Processes launch and close relatively quickly in Process Explorer, so to give myself the extra time I may need, I accessed the Difference Highlighting Duration dialog from the Options menu. Unfortunately this value is limited from 0-9 so 9 will have to work. Uninstall, then, side by side, reinstall the app and watch.

Internet Explore launches a Silverlight.Configuration.exe child process, which launches a second Silverlight.Configuration.exe child process, which launches a sllauncher.exe child proces, which launches a second sllauncher.exe child process. A new suspect! Inspecting the properties of the child process reveals this command-line:

“C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe” 3835182041.images.fandango.com

Very similar to the above Silverlight.Configuration.exe command-line. Let’s search for this sllauncher.exe and see if it has some command line arguments we can use. A quick search reveals the perfect article: How to Install a Silverlight Out-of-Browser Applications (XAP) Silently

JACKPOT? A quick read reveals a sample scenario involving deploying your own in-house developed XAP… Not quite what we have in mind but it’s a great start. The sample command-line they use is:

“C:\Program Files\Microsoft Silverlight\sllauncher.exe” /install:”C:\MySilverlightApps\Silverlight4.OOB.ChromelessWindow.Demo.xap” /origin:http://www.kunal-chowdhury.com/private/apps/ClientBin/Silverlight4.OOB.ChromelessWindow.Demo.xap /shortcut:desktop+startmenu /overwrite

Not a bad start, but not perfect for our needs. We don’t have the xap file that the website is using nor do we know the origin of the file. Now what? Let’s pop back open Sysinternals Process Monitor and take a look at the file changes during install, maybe we can find a locally stored copy?  Pause and clear the capture, set the filters back to default, add a filter to include only sllauncher.exe processes, uninstall the app, start capture, install the app. Now filter only file operations and… nothing. Let’s try Silverlight.Configuration.exe… nope. Let’s try path contains xap… BINGO! An application.xap file in the folder 3835182041.images.fandango.com. We’ve seen that path before. The full path to that xap is:

C:\Users\Micah\AppData\Local\Microsoft\Silverlight\OutOfBrowser\3835182041.images.fandango.com

Ok, what have we got? Let’s see, we have an icon, a png of the icon, the application.xap file, an index.html file and 3 un-extensioned files: installstate, metadata, and state. Well it’s a good bet that the application.xap file is the source we need… what about the origin parameter? The installstate and state files are empty (probably flag files), but the metadata is the jackpot we’ve been waiting for:

ShortcutName=Fandango Slate Application
LaunchPath=C:\Users\Micah\AppData\Local\Microsoft\Silverlight\OutOfBrowser\3835182041.images.fandango.com\index.html
CustomIcon=1
TrimmedSourceDomain=images.fandango.com
TrimmedTitle=Fandango Slate Application
TrimmedName=Fandango Slate Application
ElevatedPermissions=2147483647
XapLastModified=Tue, 02 Aug 2011 23:16:17 GMT
EnableGPUAcceleration=True
WindowStartupLocation=0
WindowTop=0
WindowLeft=0
WindowWidth=1367
WindowStyle=1
WindowHeight=767
SourceDomain=images.fandango.com
OriginalSourceUri=http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap
FinalAppUri=http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap
RuntimeVersion=4.0.50826.0
AppID=3835182041.images.fandango.com
Description=Fandango Slate Application on your desktop; at home, at work or on the go.
Title=Fandango Slate Application
Name=Fandango Slate Application

OriginalSourceUri looks PERFECT. Just to make sure we really have the original XAP file, let’s download that XAP, maybe the xap file changes when downloaded and installed (ok maybe not, but we can’t be too safe). Copy pasting that address into IE gives us a downloaded copy!

As far as the remaining two parameters, shortcut and overwrite: The overwrite parameter is not needed for MDT deployments or if you are sure the app has never been deployed before. Adding overwrite prevents an error from being thrown if the application already is installed. The shortcut parameter can be left out or set to one of the following:

  1. desktop
  2. startmenu
  3. desktop+startmenu

Let’s roll it all together: Place the xap file in a folder and our local command-line is as follows:

“C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe” /install:“Fandango.Slate.xap” /origin:http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap /shortcut:startmenu /overwrite

Caveats

Silverlight 5 was released on December 9, 2011 and has a 64-bit installer. This means that if you are installing Silverlight 5, the path to sllauncher will always be C:\Program Files, regardless of the OS architecture, making our job simpler, one command-line for all 🙂

These applications are installed on a per-user basis, so for MDT deployment, make sure copyprofile=true.

Some Out-of-Browser Silverlight apps may require Native Extensions For Microsoft Silverlight which you can find here as an msi download. Install the extensions before deploying the apps to avoid dependency issues.

Summary

So, to summarize:

  1. On a test machine, download and install the desired Silverlight Out-of-Browser application
  2. Navigate to %LOCALAPPDATA%\Microsoft\Silverlight\OutOfBrowser and open the appropriate application folder.
  3. Open the metadata file in notepad and copy the OriginalSourceUri path.
  4. Paste the path the address bar of your browser and download the XAP file.
  5. If using MDT, copy the XAP to a folder and import.
  6. Use the command-line syntax as follows:
    • 64-bit OS: “%ProgramFiles(x86)%\Microsoft Silverlight\sllauncher.exe” /install:[XAP FILE] /origin:[ORIGINALSOURCEURI PATH] /shortcut:[DESIRED SETTING] /overwrite
    • 32-bit OS: “%ProgramFiles%\Microsoft Silverlight\sllauncher.exe” /install:[XAP FILE] /origin:[ORIGINALSOURCEURI PATH] /shortcut:[DESIRED SETTING] /overwrite

Credit: I ran across a great article on Tim Heuer’s blog while proofing this draft that I failed to locate when it was originally started and would be remiss not to mention. It’s a great echo of what I’ve covered here but doesn’t cover third-party apps.

New Tool: Advanced Format Drives April 29, 2011

Posted by keithga in Troubleshooting, Uncategorized, Windows 7.
3 comments

Been slacking lately (Working on MDT 2012).

Advanced format drives are coming!

http://en.wikipedia.org/wiki/Advanced_Format

This hasn’t been much of a problem until recently, now that most of the major hard drive manufacturers have started to switch over to full Advanced Format.

When you have an Advanced format drive, you should format with an operating system that can format the drive aligned on the advanced 4k sectors rather than the 512 byte sectors found on older drives.

If  you do not format an “Advanced Format” disk aligned on the 4k sectors, then you may experience performance degradation. Windows 7 SP1 has been updated to address Advanced Format Drives, and WinPE 3.1, contained in WAIK 3.1 has been updated as well.

But how do you know if you need WinPE 3.1?

I have just written a new tool: IsAdvancedFormat.exe, that can detect if there are *any* advanced format drives present on the local machine. It will return errorlevel 0 if there are no advanced format drives, and errorlevel 42 if there *are* advanced format drives.

Source code is included.

Sample Output!

C:\> IsAdvancedFormat.exe
Enumerate all detect all Advanced Format Drives.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: WDC WD10EADS-11M2B2
  Emulated sector size is 512 bytes.
  Physical sector size is 4096 bytes.
C:\> @echo %ErrorLevel%
42

Location!

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/IsAdvancedFormat.zip

Update! (7/24/2011)

It appears that Dell has taken this tool and enhanced it! Their new tool can detect if an Advanced Format drive was partitioned/formatted incorrectly.  Cool Stuff.

Since Dell’s tool is now a superset of my tool, I would recomend theirs first:  http://del.ly/afhdd 

I will continue to provide my tool here as a reference.

Thanks Dell! (and thanks Warren Byle)

Combining WIM files December 16, 2010

Posted by keithga in Uncategorized.
7 comments

I was at a customer site during the past few weeks, and the customer asked about merging WIM files. This company was a Lenovo shop, and they had three main platforms in their inventory, the Thinkpad T410, T410s, and the X201.

For technical reasons that I won’t get into here, we decided to create several Model Specific Fat images that could be deployed using SCCM as-is without loading additional Drivers. Unfortunately, when done we had about 8 images, including two base images that contained their common application suite, but did not contain any extra drivers.

When done we had the following x64 images:

  • WIN7ENTX64.base.wim
  • WIN7ENTX64.t410.wim
  • WIN7ENTX64.t410s.wim
  • WIN7ENTX64.x201.wim

Each wim was about 4-6 GB in size, all totaled about 21GB for x64.

WIM files

WIM files are containers that store other files, similar to the way that a *.zip file or a *.cab file stores other files. Microsoft Windows also provides the ability to “mount” Wim files into an existing File Folder, allowing one to Add/Delete/Modify files in the wim.  This causes problems since modifications of the WIM file can cause fragmentation, just like *.vhd files. Windows gets around this by supplying the imagex.exe /export command. This command will allow the administrator to move the content from one WIM file to another WIM file, and in doing so the new wim file will be de-fragmented!

We can use this imagex.exe /export command to move the contents of one Wim file *into* an existing wim file, the cool thing for us is that ImageX.exe will also check to see if the file already exists in the wim file, and will not add the file in order to save space!

Example

In the example case above with the three Lenovo machines and a base image, I decided to start with the base image, and to inject the three other platforms into the base *.wim image:

Imagex.exe /export WIN7ENTX64.t410.wim *   WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410”

Imagex.exe /export WIN7ENTX64.t410s.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410s”

Imagex.exe /export WIN7ENTX64.x201.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.x201”

When I was finished the Base.wim file had increased in size by only 1.5GB, much better than trying to distribute 4 separate *.wim files totalling 20GB

-Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

New Tool: USB Boot Tool October 28, 2010

Posted by keithga in MDT 2010, Uncategorized, VBscript.
comments closed

Overview:

The purpose of the tool is to add/remove WinPE Boot.wim file(s) to a USB Flash Drive using a wizard. 

It is designed to integrate with the Microsoft Deployment Toolkit 2010.

Description:

It should be smart enough to find USB flash drives, find any local  MDT 2010 Litetouch.wim files, automatically mark the drive/partition active (if not already set), and it can add/remove multiple *.wim files to a single USB Flash drive if there is enough space.

This is ideal if you want multiple Litetouch WIMs, For example x86 *and* x64 litetouch.wim files on the same USB stick, or Litetouch WIMs from multiple Deployment shares (One production server, one test server)..

USBootTool.hta is a standalone *.hta file, and requires no other components/libraries.

Installation/Operation:

· Just copy this script to your %deploymentshare%\Boot\ directory.

· When the script starts up it will display the Litetouch.wim files present on that directory. If not present it will enumerate through the Deployment shares mounted in the MDT console.

Screen Shots:

clip_image001

· Note the tool found my Flash Drive, parsed the BCD file and found three entries.

· I click “add” to add a *.wim file.

clip_image002

· Note that the tool found several *.wim files in my deployment share.

· I can modify the description if required.

clip_image003

· The script will copy all the necessary files to the Flash Drive.

· It will also place the *.wim file in a separate folder. The folder name is a GUID to prevent conflicts.

· I can repeat the process to add other *.wim files to my USB flash drive

 Source

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/USBBootTool.zip

-k

User Tiles in the Domain October 8, 2010

Posted by Micah Rowland in Uncategorized.
3 comments

In a previous post, I described a solution for handling user account tiles for local accounts. A reader recently emailed me inquiring about user tiles for domain users and I realized that I had failed to cover how Windows 7 handles this and how an IT department could leverage this functionality.

For those of you who have read the previous post, you’ll remember that Windows 7 (and Vista) stores the usertile picture that is displayed on login and on the start menu in the registry buried in the SAM hive. This article assumes you have read the previous one and will only briefly reiterate key points as necessary.

For domain accounts, the story is slightly different. Domain account usertiles are not in fact stored in the registry but in a much more accessible location, C:\ProgramData\Microsoft\User Account Pictures\ . If only local accounts were so easy. But don’t worry, we’ll still have a fun time. The usertile files for each user are saved as DOMAIN+username.dat. For example, John Doe at Contoso would be stored as CONTOSO+jdoe.dat. The contents of this dat file will look very familiar to any of you who have looked at local usertiles in the registry. In fact, the hex data stored in this file is EXACTLY the same as how it would be stored in the registry.

So lets get our plan of attack:

  1. Login to a domain account. Any will do.
  2. Set our usertile the old fashioned way.
  3. Retrieve the generated dat file.
  4. Use it!

WAY SIMPLER THAN LOCAL ACCOUNTS!

Let’s take the following scenario posed by one reader. Contoso would like users in each of 5 departments to have a department specific usertile. First we login using a domain account (for our example John Doe will do) and set its usertile to the first department’s desired tile. We then copy the C:\ProgramData\Microsoft\User Account Pictures\CONTOSO+jdoe.dat file to a holding area and rename it to departmentname.dat. We then repeat for the remaining 4 departments. Now that we have the proper dat files we can leverage them in a few different ways. Most users will go the route of the logon script: Check for group membership to ascertain the department of the user (or read an Active Directory attribute) and copy the proper department dat file into the local computer’s User Account Picture directory. We could also preload our OS deployment with a set of all user files for all members of the domain (probably only a good idea in an organization with a small number of users). Using a logon script will ensure that the proper department icon is used, even if a user changes it, though placing a complementing logoff script would be prudent to prevent any non-compliance.

Whatever way you cut it, it’s pretty much up to you at this point. Bon Appétit!

Introduction June 23, 2010

Posted by Micah Rowland in Uncategorized.
3 comments

My name is Micah Rowland and I have been added to the Xtreme Deployment consulting group as an expert in automation and reverse engineering. As we all know, some of the tasks that customers ask of us to accomplish during the MDT process are very simple to do manually, but in the background, are tricky to nail down when we go to automate the same processes.  In my posts, I hope to reveal undocumented aspects to the Windows operating system and show how to develop automation around these processes. Let’s get started!

Assign Drivers to Computer Makes and Models March 11, 2010

Posted by keithga in Uncategorized.
9 comments

Speaking of Make and Models… one of the things I’ve been experimenting with lately is mixing driver management styles (grouping by Make+Model vs PnPID).

 

 

Make/Model Match

Historically, if you had different hardware platforms, and you wanted to install drivers on each type, you would create separate packages for each Make and Model. Then you could query the Make and Model information from the BIOS to determine which package to install.

 

 

For example here are four Make+Model examples:

Make Model
Dell D630
Dell D830
HP DC7800
HP DC7900

The disadvantage of this method is that you have to update the driver packages when new Models come along, and it’s also possible that you might keep multiple instances of the same driver package across many Make and Model repositories. 

 

 

 

PnP-ID Match

With MDT, ZTIDrivers.wsf was designed to do things in a different manner. Instead of downloading drivers and grouping them based on Make/Model, you would import the driver directly into MDT, MDT would parse the driver package, and MDT would install the driver package on the machine if the Plug and Play ID matched.

 

 

For example, Windows might search for Plug and Play ID’s that look like:

 

PCI\VEN_1099&DEV_0242&SUBSYS_02429005&REV_01
PCI\VEN_1099&DEV_0242&SUBSYS_02429005
PCI\VEN_1099&DEV_0242&CC_010401
PCI\VEN_1099&DEV_0242&CC_0104
PCI\VEN_1099&DEV_0242&REV_01
PCI\VEN_1099&DEV_0242
PCI\VEN_1099&CC_010401
PCI\VEN_1099&CC_0104
PCI\VEN_1099
PCI\CC_010401
PCI\CC_0104

 

 

 

Generally this system works better than copying based on Make and Model except for a few points:

  • You must import the drivers in a correct fashion so MDT can parse the INF files, and so each driver package is a seperate entry (more on importing drivers later…)
  • Some PC Makers only certify (support?) a subset of driver versions, so it is possible that MDT may give Windows the latest non-certified version of a driver.
  • There also may be compatibility problems with specific drivers. When placed on some other platforms. (However IMHO, if a driver *can* be installed on a machine, but crashes the machine, then that is a bug of the driver).

 

Hybrid Make-Model + PnPID Match Solution

For my MDT environments, I don’t want to place all drivers into Make/Model groupings by default, since I loose the advantages of ZTIDrivers.wsf where it copy by PnPID. For example, I have the drivers for my Dell D620 integrated now, but it’s good to know that I probably have good coverage for any D820’s out there since they share mostly the same components.

 

I’ve seen some MDT implementations that totally throw away the ZTIDrivers.wsf PnPID style in favor of maintaining a manual mapping of drivers to Make+Model. However, I do concede, that there are some drivers out there that “… do not play nicely with others…”, and need to be quarantined somehow, and according to a make+model works well.

 

Create a Folder Structure in MDT Workbench:

Common

    Audio

    Networking

        Intel

        Marvel

    Storage

    Video

Dell

    Common

        Audio

        Networking

        Storage

    D620

Hewlett-Packard

    Common

    DC7800

        Audio

        Networking

        Storage

WinPE

 

 

 

Then in your CustomSettings.ini file, you can add the following: 

DriverGroups001=Common

DriverGroups002=%Make%\Common

DriverGroups003=%Make%\%Model%

DriverSelectionProfile=Nothing

(Note that DriverSelectionProfile=nothing is required if using DriverGroups).

%Make% and %Model% will be auto-expanded in the customsettings.ini file with the Make and Model values from the system BIOS.

  • If you have a driver that will work for all Makes and Models, then place it under \Common.
  • If you have a driver that is only supported for a single Manufacturer, then place it under \%Make%\Common.
  • If you have a driver that only works on a specific Make and Model, then place it under \%Make%\%Model%.

This should allow you to use generic drivers by default, moving drivers to specific makes and models when required.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Water Water everywhere… January 7, 2010

Posted by keithga in Uncategorized.
comments closed

I was walking in through the Lobby of Microsoft building 18 yesterday, and someone came in to tell the receptionist that there was a burst water main leaking in the building. Unfortunately, this is a normal occurrence in Microsoft Building 18. And has happened every year since 2007, and typically localized arround the Microsoft Deployment Toolkit team members.

Luckily, this year, we found most Team Members, and we were disconnecting machines from power before the flood waters came. And were also able to get critical machines out before the moving crews came to cart the equipment out to an undisclosed location during repairs.

For example, here is what the office of Mike Niehaus looked like yesterday.

IMG_1625

His entire office is now completely bare, and cleaning crews are doing their thing.

It’s been a crazy start to 2010! Hopefully things will calm down and I’ll start posting more soon.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

How to Know You are Using Scripts from MDT 2010 November 17, 2009

Posted by tmintner in Uncategorized.
add a comment

We’ve had a few emails over the last few weeks where certain variables or actions in the task sequence in MDT 2010 were either not functioning at all or were not behaving as expected.  After looking at the log files, it was pretty clear that a mixture of MDT 2008 boot images were being used with MDT 2010.  So how can you tell if you are using a MDT 2010 boot image?  The easiest way to tell is to look in the bdd.log file.  IN MDT 2010 we added a version line to each of the scripts that are run so if in the first 15 or so lines of the BDD.LOG you do not see this: Microsoft Deployment Toolkit version: 5.0.1641.0 , then your boot images are probably running scripts from MDT 2008.

 

To fix this you would, right click on the DeploymentShare and choose Update.  Then you would choose Completely regenerate the boot images as shown below:

image

 

Now that your boot images are updated you will either need to burn new CDs or re-import the boot images into WDS

 

– Tim Mintner