Via this script:

/*
Copyright (c) Microsoft Corporation

Module Name:

    nvspscrub.js

*/

//
// VirtualSwitchManagementService object.  Logical wrapper class for Switch Management Service
//
function
VirtualSwitchManagementService(
    Server,
    User,
    Password
    )
{
    //
    // Define instance fields.
    //
    this.m_VirtualizationNamespace  = null;

    this.m_VirtualSwitchManagementService = null;

    //
    // Instance methods
    //        

    VirtualSwitchManagementService.prototype.DeleteSwitch =
    function(
        VirtualSwitch
        )

    /*++

    Description:

        Deletes a virtual switch

    Arguments:

        VirtualSwitch - Msvm_VirtualSwitch object to delete

    Return Value:

        SWbemMethod.OutParameters object.

    --*/

    {
        var methodName = "DeleteSwitch";

        var inParams = this.m_VirtualSwitchManagementService.Methods_(methodName).inParameters.SpawnInstance_();

        inParams.VirtualSwitch = VirtualSwitch.Path_.Path;

        return this.m_VirtualSwitchManagementService.ExecMethod_(methodName, inParams);
    }

    VirtualSwitchManagementService.prototype.DeleteInternalEthernetPort =
    function(
        InternalEthernetPort
        )

    /*++

    Description:

        Deletes an internal ethernet port

    Arguments:

        InternalEthernetPort - Msvm_InternalEthernetPort to delete

    Return Value:

        SWbemMethod.OutParameters object.

    --*/

    {
        var methodName = "DeleteInternalEthernetPort";

        var inParams = this.m_VirtualSwitchManagementService.Methods_(methodName).inParameters.SpawnInstance_();

        inParams.InternalEthernetPort = InternalEthernetPort.Path_.Path;

        return this.m_VirtualSwitchManagementService.ExecMethod_(methodName, inParams);
    }

    VirtualSwitchManagementService.prototype.UnbindExternalEthernetPort =
    function(
        ExternalEthernetPort
        )

    /*++

    Description:

        Unbinds an external ethernet port from the virtual network subsystem.  Usually this method
         won't be called directly

    Arguments:

        SwitchPort - Msvm_ExternalEthernetPort to unbind.

    Return Value:

        SWbemMethod.OutParameters object.

    --*/

    {
        var methodName = "UnbindExternalEthernetPort";

        var inParams = this.m_VirtualSwitchManagementService.Methods_(methodName).inParameters.SpawnInstance_();

        inParams.ExternalEthernetPort = ExternalEthernetPort.Path_.Path;

        return this.m_VirtualSwitchManagementService.ExecMethod_(methodName, inParams);
    }

    //
    // Utility functions
    //

    VirtualSwitchManagementService.prototype.WaitForNetworkJob =
    function(
        OutParams
        )

    /*++

    Description:

        WMI calls will exit with some type of return result.  Some will require
        a little more processing before they are complete. This handles those
        states after a wmi call.

    Arguments:

        OutParams - the parameters returned by the wmi call.

    Return Value:

        Status code

    --*/

    {
        if (OutParams.ReturnValue == 4096)
        {
            var jobStateStarting        = 3;
            var jobStateRunning         = 4;
            var jobStateCompleted       = 7;

            var networkJob;

            do
            {
                WScript.Sleep(1000);

                networkJob = this.m_VirtualizationNamespace.Get(OutParams.Job);

            } while ((networkJob.JobState == jobStateStarting) ||
                     (networkJob.JobState == jobStateRunning));

            if (networkJob.JobState != jobStateCompleted)
            {
                throw(new Error(networkJob.ErrorCode,
                                networkJob.Description + " failed: " + networkJob.ErrorDescription));
            }

            return networkJob.ErrorCode;
        }

        return OutParams.ReturnValue;
    }

    VirtualSwitchManagementService.prototype.GetSingleObject =
    function(
        SWbemObjectSet
        )

    /*++

    Description:

        Takes a SWbemObjectSet which is expected to have one object and returns the object

    Arguments:

        SWbemObjectSet - The set.

    Return Value:

        The lone member of the set.  Exception thrown if Count does not equal 1.

    --*/

    {
        if (SWbemObjectSet.Count != 1)
        {
            throw(new Error(5, "SWbemObjectSet was expected to have one item but actually had " + SWbemObjectSet.Count));
        }

        return SWbemObjectSet.ItemIndex(0);
    }

    //
    // Aggregate functions
    //
    VirtualSwitchManagementService.prototype.DeleteSwitchAndWait =
    function(
        VirtualSwitch
        )

    /*++

    Description:

        Deletes a switch

    Arguments:

        VirtualSwitch - Msvm_VirtualSwitch to delete

    Return Value:

        None.

    --*/

    {
        var outParams = this.DeleteSwitch(VirtualSwitch);

        var wmiRetValue = this.WaitForNetworkJob(outParams);

        if (wmiRetValue != 0)
        {
            throw(new Error(wmiRetValue, "DeleteSwitch failed"));
        }
    }

    VirtualSwitchManagementService.prototype.DeleteInternalEthernetPortAndWait =
    function(
        InternalEthernetPort
        )
    /*++

    Description:

        Deletes an internal ethernet port

    Arguments:

        InternalEthernetPort - Msvm_InternalEthernetPort to delete

    Return Value:

        SWbemMethod.OutParameters object.

    --*/

    {
        var outParams = this.DeleteInternalEthernetPort(InternalEthernetPort);

        var wmiRetValue = this.WaitForNetworkJob(outParams);

        if (wmiRetValue != 0)
        {
            throw(new Error(wmiRetValue, "DeleteInternalEthernetPortAndWait failed"));
        }
    }

    VirtualSwitchManagementService.prototype.UnbindExternalEthernetPortAndWait =
    function(
        ExternalEthernetPort
        )
    /*++

    Description:

        unbinds an internal ethernet port

    Arguments:

        ExternalEthernetPort - Msvm_ExternalEthernetPort to unbind

    Return Value:

        SWbemMethod.OutParameters object.

    --*/

    {
        var outParams = this.UnbindExternalEthernetPort(ExternalEthernetPort);

        var wmiRetValue = this.WaitForNetworkJob(outParams);

        if (wmiRetValue != 0)
        {
            throw(new Error(wmiRetValue, "UnbindExternalEthernetPortAndWait failed"));
        }
    }

    //
    // Constructor code
    //

    if (Server == null)
    {
        Server = WScript.CreateObject("WScript.Network").ComputerName;
    }

    //
    // Set Namespace fields
    //
    try
    {
        var locator = new ActiveXObject("WbemScripting.SWbemLocator");

        this.m_VirtualizationNamespace = locator.ConnectServer(Server, "root\\virtualization", User, Password);
    }
    catch (e)
    {
        this.m_VirtualizationNamespace = null;

        throw(new Error("Unable to get an instance of Virtualization namespace: " + e.description));
    }

    //
    // Set Msvm_VirtualSwitchManagementService field
    //
    try
    {
        var physicalComputerSystem =
                this.m_VirtualizationNamespace.Get(
                        "Msvm_ComputerSystem.CreationClassName='Msvm_ComputerSystem',Name='" + Server + "'");

        this.m_VirtualSwitchManagementService = this.GetSingleObject(
                                                        physicalComputerSystem.Associators_(
                                                            "Msvm_HostedService",
                                                            "Msvm_VirtualSwitchManagementService",
                                                            "Dependent"));
    }
    catch (e)
    {
        this.m_VirtualSwitchManagementService = null;

        throw(new Error("Unable to get an instance of Msvm_VirtualSwitchManagementService: " + e.description));
    }
}

//
// main
//

var wshShell = WScript.CreateObject("WScript.Shell");

var g_NvspWmi   = null;

Main();

function Main()
{
 WScript.Echo("Looking for nvspwmi...");
 g_NvspWmi   = new VirtualSwitchManagementService();

 WScript.Echo("");
 WScript.Echo("Looking for internal (host) virtual nics...");
 var list = g_NvspWmi.m_VirtualizationNamespace.ExecQuery("SELECT * FROM Msvm_InternalEthernetPort");
 for (i = 0; i < list.Count; i++)
 {
  var next = list.ItemIndex(i);
  WScript.echo(next.DeviceID);
  g_NvspWmi.DeleteInternalEthernetPortAndWait(next);
 }

 WScript.Echo("");
 WScript.Echo("Looking for switches...");
 list = g_NvspWmi.m_VirtualizationNamespace.ExecQuery("SELECT * FROM Msvm_VirtualSwitch");
 for (i = 0; i < list.Count; i++)
 {
  var next = list.ItemIndex(i);
  WScript.echo(next.Name);
  g_NvspWmi.DeleteSwitchAndWait(next);
 }

 WScript.Echo("");
 WScript.Echo("Looking for external nics...");
 list = g_NvspWmi.m_VirtualizationNamespace.ExecQuery("SELECT * FROM Msvm_ExternalEthernetPort WHERE IsBound=TRUE");
 for (i = 0; i < list.Count; i++)
 {
  var next = list.ItemIndex(i);
  WScript.echo(next.DeviceID);
  g_NvspWmi.UnbindExternalEthernetPortAndWait(next);
 }

 WScript.Echo("");
 WScript.Echo("Finished!");
}

Copy the above code into a blank text document and save it with the file extention *.js (eg, nvspscrub.js). Run it on your host, and there you go.

Download it here and change the file extension from txt to js if you’d prefer.

This created an orphaned user.  To fix such a user, enter the following in a new query window:

select ‘sp_change_users_login @Action = ‘ + char(39) + ‘auto_fix’ +
char(39) + ‘, @usernamepattern = ‘ + char(39) + name + char(39) + char(13) + ‘go’
from sysusers
where issqluser = 1 and (sid is not null and sid <> 0×0)
and suser_sname(sid) is null
order by name

The results of this query will be the query code to fix the orphaned user(s).

I’ll try to get some screenshots next time.

The output of a netsh dns show state was such that DA said it was configured, but was disabled:

As you can see, the laptop has determined that it is outside the corporate network, but it is set to never use DA settings.

After much searching, I stumbled upon the answer to my issues.  Here’s what happened:

There is a DWORD buried in the registry that flips between three different values based on where the machine is (inside/outside) and whether or not DA is manually set to use local DNS.  The DWORD is here:

HKLM\Software\Policies\Microsoft\WindowsNT\DNSClient\
EnableDAForAllNetworks

The three possible values are 0, 1, and 2. 

0 tells DA to determine whether it should be enabled or disabled based on its network location.  This is normal setting and allows for normal operation – when you’re inside the corporate network turn off, and when you’re outside turn on.

1 sets DA to always on.  This isn’t useful when you’re inside the network.  Perhaps it’s there for testing purposes.

2 is disabled.  When set to 2, DA doesn’t care where it is, it’s always off.  Consequently, this is what the DWORD’s value is set to when you tell the DA Client to Use local DNS resolution.

So, after an hour’s worth of digging, I found that somehow this particular client had the above registry key set to “2”, which effectively turned DA off.  The weird part here was that the DA client was not set to use local DNS.  The registry entry was stuck.

I ended up manually changing it to “0”.  Go figure, DA started working immediately – no reboot required.  Before I finished, I tested turning the DA client to use local DNS and back.  The registry entry appears to now be unstuck.

Why are you such a pain to troubleshoot, Direct Access?  Why?

After spending some time on the phone with a Microsoft technician, we tracked the problem down.  Here are a couple notes I wanted to keep from the call.

Direct Access on Other Networks

If I take my laptop, which is Direct Access-enabled, into another AD network environment, teredo will disable itself.  That is, if I go to someone else’s office – complete outside of my domain – and my Direct Access client detects a DC outside of its domain, Direct Access will fall back onto IPHTTPS.

This is because teredo is a NAT-bypass mechanism and poses a security risk to other networks.  If you need teredo to work, there is a command that can help:

netsh interface teredo set state type=<CLIENT_TYPE>

Where client type is one of the following:

• disabled – Obviosuly, disables the teredo interface.
• client – This is the default type, and is just a normal client that will adhere to the rule above.
• enterpriseclient – This is a default client, except it will ignore the rule above and build a teredo tunnel, even in the presence of a foreign DC.
• server – This is the type that your UAG server holds.

Purging the System Account’s Kerberos Ticket

One client we were troubleshooting was having a hard time applying the policy.  The Microsoft guy ran the following command to manually expire the system account’s ticket.  This effectively forced the client to reevaluate its group memberships.

klist –li purge

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

In a rare moment of helpfulness, I managed to find some keyboard shortcuts to help.  One of the plus sides here, is that when using the shortcuts below, a window can be docked to the inside of your dual monitor setup (since you can’t do it with the mouse).

Oh, and for those of you that I see using “Ctrl+Alt+Del” and pressing “Enter” to lock your computer, try Win + L.