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.

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 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.

Generally, the App-V Client refreshes the applications published to a user at log on.  This, of course, means valuable seconds/minutes are wasted waiting for the machine to log off and back on.  So, of course, there is a way to manually refresh the published applications via the App-V Client Console.

As any good administrator does (yeah, right), they do not set themselves as a local administrator for the machine they are using.  In order to access some of the “administrative-y” features of the App-V Client Console (such as the option to delete an application from the client), one must “Run as Administrator” – assuming they aren’t a local administrator.

Here’s the kicker: if you’ve opened the console as an administrator (using “Run as…”) and refresh the published applications, you’ll be updating it based on the user’s credentials you’ve provided.  If you’re running the console under the logged in user’s credentials, you’ll be updating the applications based on the applications published to that user.

I’ll admit this does sound like an obvious conclusion, but for those of us who choose not to be local administrators it seems a bit confusing.  Just remember: the console updates based on user – not machine (because the applications are published based on a user and not a computer account).

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.

Remote Server Administration Tools for Windows 7 Release Candidate (RC)

Remote Server Administration Tools for Windows® 7 RC enables IT administrators to manage roles and features that are installed on computers that are running Windows Server® 2008 R2, Windows Server® 2008, or Windows Server® 2003, from a remote computer that is running Windows 7 RC.

Today, I added the third node to the Hyper-V R2 cluster we’re currently testing.  When I did, VMM freaked out and all of the guests on the other two nodes went into a warning state.  The error they displayed:

Warning (13921)

Highly available virtual machine <INSERT NAME> is not supported by VMM because one or more of its network adapters is not configured correctly.

Recommended Action

Ensure that all of the virtual network adapters are either disconnected or connected to highly available virtual networks.

So, how do we fix this issue?  You use Google, of course.  A quick Google-ing gave the following information (edited for grammar):

For a VN [Virtual Network] to be marked as HA, the location and tag of the VN in all nodes must be the same.  For each VN in the cluster[, be sure that]:

• The NICs to which the VN is attached in each node have the same location.
• The Tag in the VN in each node is the same.
• The VN Name is the same.
• After you commit changes, refresh the cluster so ensure that the VN is detected as HA.

Our problem, specifically, was related to the network tagging.  To fix the tag, do the following:

1. Open VMM, and navigate to the “Hosts” view.
2. Right click on one of the hosts and select “Properties.”
3. Navigate to the “Networking” tab.
   
4. Once, there, you’ll need to click each network (in this case, we have two) and add text to the “Network tag:” field.  Keep in mind that these tags will need to be the same across all your hosts in order to make them highly available.
   
5. Rinse and repeat for the rest of your hosts.
6. Once you finish tagging, you’ll need to refresh the cluster node in VMM.
   

That fixed our problem.  Maybe it will help you.

More information here in the “Troubleshoot ‘Unsupported Cluster Configuration’ Status for a Highly Available Virtual Machine” section.