The command:

net localgroup Administrators /add "domain\domain group"

If you want to edit a group other than the local Administrators group, just change “Administrators” above to whatever the appropriate group may be.

Our jobsites are mostly on DSL with some sort of VPN or MPLS connection back to the office.  Some of our jobsites don’t even have internet.  So, the question becomes how do we deploy Windows 7 to these remote and/or unconnected jobsites.  I don’t think it’s fair to expect seven to nine gigabytes of image and task sequence data to traverse the 3 Mbps (and sometimes 1.5!) link these places have with corporate (or a branch office that has a deployment server).  So, what about taking bootable media with us?

We first thought about carrying around hard drives, but decided trying to get through security at airports or otherwise just having a backpack full of drives seemed a bit problematic.  Our images and all their associated data don’t come close to fitting on a DVD (or even two dual layer ones), so we decided to travel down the USB flash drive road for remote deployments.

Here’s how we did it:

I’ll assume you already have a working MDT installation with all your various OSs, applications, task sequences, and the like.

Step 1: Open your Deployment Share, and navigate down to Advanced Configuration and  Media.

Step 2: Right click Media and choose New Media.

Step 3: Fill in a “Media path”.  Make sure this folder exists (or that you create it via the “Browse…” option) or MDT will balk at whatever you put here.  Give it some comments and pick whatever “Selection profile” is necessary for this deployment media.  In my case, I needed a deployment media that contained only x64 related items (so, I created a selection profile that was limited to x64 stuff).  If I tried to put all my deployment data in this media set, I wouldn’t be able to fit it on my meager 32GB flash drive.

Click Next twice.  Then Click Finish.

Step 4:  Navigate back to the Media section of Advanced Configuration.  You’ll see your media listed here in some form of “MEDIA001” and some other information like the media root, which selection profile the media is based on, and your comments.

Step 5: Right click the media you just created and choose Update Media Content.

Step 6: Wait.  MDT is copying all the data and information in your selection profile to the media root.  This may take a while depending on what you’re putting into it.

Once this is done, you’re ready for your USB drive.

Step 7: Navigate to the media root you used back in step 3.  Inside you’ll see A folder called “Content” and an ISO image.  This ISO image is ready to burn to a CD or DVD (depending on the size of it, of course).  Of course, my media folder is almost 17GB:

If you know how I can fit this a DVD, I know how you can make a lot of money.

Now, format your properly sized flash as NTFS with the allocation unit size set to default.

Copy the contents of the “Content” folder to the root of the flash drive.

Put this flash drive into the USB port on a computer, and boot the machine to the USB hard drive or USB disk option.  And voilà!  You’re imaging from a USB drive.

So, I present you with a way to change that: bcdedit.  Microsoft has a TechNet article that gives the necessary commands to run on your WDS server to make changes to this timeout value.

You can view the current BCD Store settings via this command (insert your own value for the bold text):

bcdedit /enum all /store <full path and file name of store>

An example return will be something like this:

C:\>bcdedit /enum all /store e:\RemoteInstall\Boot\x86\default.bcd
Windows Boot Manager
--------------------
identifier              {bootmgr}
inherit                 {dbgsettings}
timeout                 30

Real-mode Application (10400009)
--------------------------------
identifier              {40fe5c41-285e-412b-b4cd-0ce498e470a2}
device                  boot
path                    OSChooser\i386\startrom.n12
description             Remote Installation Services
pxesoftreboot           Yes

Debugger Settings
-----------------
identifier              {dbgsettings}
debugtype               Serial
debugport               1
baudrate                115200

Device options
--------------
identifier              {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdisksdidevice        boot
ramdisksdipath          \Boot\Boot.SDI

You can choose whether to edit your x86 or your x64 store by changing the “bold “x86” above to the appropriate architecture.  Now, we can see here that the timeout is currently set for 30 seconds.

Here are the commands to change that timeout (insert your own values for the bold text):

bcdedit /store <full path and file name of store> /set {bootmgr} timeout <value in seconds>

After you change the timeout value, you need to force the BCD store to regenerate:

sc control wdsserver 129

After this you’ll see an output similar to this:

SERVICE_NAME: wdsserver
TYPE: 20
WIN32_SHARE_PROCESS
STATE: 4  RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0×0)
SERVICE_EXIT_CODE: 0  (0×0)
CHECKPOINT: 0×0 WAIT_HINT: 0×0

And you’re done.

So, I’ve been creating custom images this week and capturing them to my MDT machine.  I got around to the x86 image, customized it, updated it, captured it, imported it, then tested and failed.  I couldn’t figure out why – hence the hair pulling.  And then I found it.  Like a glowing pot of gold hidden under a rock in the deepest part of the forest, I found the problem:

The DVD I got the source files from in the top image was build number 6.1.7600.16385.  Some update that I was running on the image I was customizing was updating this build to 6.1.7600.16481.  So, when I would go back to try to test the customized image, I’d get an error at the start of the task sequence that goes something like this:

Operating System deployment did not complete successfully.

Error: Unable to find SETUP , needed to install the image
\\MDT_Server\DeploymentShare$\Operating Systems\W7x86_CAP_3-4-10\W7x86_CAP_3-4-10.WIM

I tried the Google route, and found a bunch of unrelated stuff.  Turns out, if the build number is the same on a custom image as on an image with the full source files, MDT will not require setup sources for the custom image.  It will take it from the existing sources in another OS.  So, when it was looking for the setup sources for my 16481 build, it couldn’t find it.

There you have it.  Be careful running updates on custom images.  Make sure you have the sources with the same build number or it won’t work.

So, every time you make a change in MDT, you have to update the deployment point, which in most cases will regenerate the boot wims.  When you have four deployment points, this can be a pain just to update a task sequence.  After a bit of Googling, I found this:

You’ve probably gone through this cycle if you are using WDS to PXE boot computers to start bare metal Lite Touch deployments:

• Import new drivers or change bootstrap.ini.
• “Update deployment share” to generate new WIMs.
• Import new WIMs into WDS.

Fortunately, with the new “update” process in MDT 2010 … it’s pretty simple to add a script to automate this process.

So, there’s a script you can create to do this job for you.  For posterity, the procedure is copied below.

First, create a script file – we’ll call it “UpdateExit.vbs” – and save it – we’ll save it in C:\Scripts\ for the purpose of this demonstration.  Paste the following into UpdateExit.vbs:

Option Explicit

Dim oShell, oEnv

Set oShell = CreateObject("WScript.Shell")
Set oEnv = oShell.Environment("PROCESS")

If oEnv("STAGE") = "ISO" then

    Dim sCmd, rc

    sCmd = "WDSUTIL /Replace-Image /Image:""Lite Touch Windows PE (" & oEnv("PLATFORM") & ")"" /ImageType:Boot /Architecture:" & oEnv("PLATFORM") & " /ReplacementImage /ImageFile:""" & oEnv("CONTENT") & "\Sources\Boot.wim"""
    WScript.Echo "About to run command: " & sCmd

    rc = oShell.Run(sCmd, 0, true)
    WScript.Echo "WDSUTIL rc = " & CStr(rc)

    WScript.Quit 1

End if

Now, edit “C:\Program Files\Microsoft Deployment Toolkit\Templates\LiteTouchPE.xml” and change the following (starting around line 90):

<!– Exits –>
<Exits>
  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
</Exits>

to look like this:

<!– Exits –>
<Exits>
  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
  <Exit>cscript.exe "C:\Scripts\UpdateExit.vbs"</Exit>
</Exits>

Instructions are include in the link above if MDT is installed on a different server than WDS.

Credit: Automatically Update MDT 2010 boot images in WDS

Anyway, after another Google session, I found something called Piwik.  Funny name, serious analytics.  Their mission is to create an open source Google Analytics replacement.  I’m not so much concerned with the GA replacement part as I am with the fact that I can host it on my own server – my own database where I can control (and be assured no one is giving up my data).  Now, I’m not saying that Piwik is quite at the level of GA yet, but they are sure on their way.  So much on their way, that I’ve already implemented Piwik on my sites and blogs (they have a WordPress plugin!) to get a good feel for it.  So far, I’m fairly impressed.

Give it a try.  Installation takes about five minutes (and reminds me a lot of installing WordPress), and configuration is as easy as typing in the site’s URL that is to be tracked, and pasting the JavaScript snippet on to your pages.  And, if you’re savvy, they have an open API that can be used to get to your data.

I’ll try to remember to write more later as Piwik gathers more data for me to dig through.

Few people notice this, but for IT groups respect is the currency of the realm. IT pros do not squander this currency. Those whom they do not believe are worthy of their respect might instead be treated to professional courtesy, a friendly demeanor or the acceptance of authority. Gaining respect is not a matter of being the boss and has nothing to do with being likeable or sociable; whether you talk, eat or smell right; or any measure that isn’t directly related to the work. The amount of respect an IT pro pays someone is a measure of how tolerable that person is when it comes to getting things done, including the elegance and practicality of his solutions and suggestions. IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.

Opinion: The unspoken truth about managing geeks

The second most exciting feature (to me) is the support for packages sequenced with 4.5 to be played on 4.6 clients (even the x64 client!).  The problem I had this morning, though, was there are a ton of blogs touting this support, but no one bothered to publish how.  For instance, from The App-V Team Blog:

All your pre-4.6 packages are valid and can continue to be used on the 4.6 client – just modify the OSD file to include the OS values for the 32 and/or 64-bit platform as target, as appropriate.

So, it can be done, but how do I include support for Windows 7 x64 clients in the OSD?  Like this:

Your current OSD files have a section that includes something similar to the following:

<OS VALUE=”WinXP”/>
<OS VALUE=”Win7″/>

This indicates that the package is available for all Windows XP and Windows 7 clients (32-bit of course, because version 4.5 does not support 64-bit).  So, add the following to your OSD file under the last “OS VALUE” entry to enable support for Windows 7 x64:

<OS VALUE=”Win764″/>

And here’s a list of all the available target operating systems:

<OS VALUE=”Win2003TS”/>
<OS VALUE=”Win2003TS64″/>
<OS VALUE=”Win2008R2TS64″/>
<OS VALUE=”Win2008TS”/>
<OS VALUE=”Win2008TS64″/>
<OS VALUE=”Win7″/>
<OS VALUE=”Win764″/>
<OS VALUE=”WinVista”/>
<OS VALUE=”WinVista64″/>
<OS VALUE=”WinXP”/>
<OS VALUE=”WinXP64″/>

The question has always been how best to cable the fiber that keeps all this stuff working properly.  You see, each DS4700 (the controlling enclosure) has two fiber controllers, each with two HBAs for connecting the EXP810 expansion enclosures.  Well, we came across an IBM document that details exactly how they recommend cabling – and here it is.  And here is the recommendation for a DS4700 with its maximum number (six) of expansion EXP810s (click for a larger view):

The Windows(R) Image to Virtual Hard Disk (WIM2VHD) command-line tool allows you to create sysprepped VHD images from any Windows 7 installation source. VHDs created by WIM2VHD will boot directly to the Out Of Box Experience, ready for your first-use customizations. You can also automate the OOBE by supplying your own unattend.xml file, making the possibilities limitless.

It took about ten minutes for WIM2VHD to deploy my WIM source to a usable VHD, which I then copied into the VMM library.  About an hour later (stupid refresh interval), the newly created VHD was available.  When I deployed a new virtual machine with that VHD, it was as if I had just installed Server 2008 with the DVD.  Awesome.