I was installing a new Hyper-V host a few days ago and had some issues when I tried to create the virtual networks. I setup the virtual networks via Hyper-V Manager, but then the machine disappeared from the network. Luckily, I had console access. Turns out, the host couldn’t renew its IP addresses for some reason. In my troubleshooting, I decided to try to remove the virtual networks – but how?
Via this script: Continue reading
Here’s the setup: one user’s laptop would not connect to corporate resources at all from outside the corporate network. No other issues with Direct Access. Just this one user’s laptop. I tried the normal stuff: can he ping us from where ever he is? Yes. Does his machine have the correct policies for DA? Yes. I even went so far as to clear his session tickets and reapply the group policy via VPN. No dice.
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?
We’ve been having some weird issues with Direct Access here at the office. For some reason, clients would work fine one minute, not work at all others, and some clients never worked.
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.
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:
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
I use MDT to deploy our servers here at the office and I’m frequently forgetting build steps – namely adding a certain group to the local Administrators group on all the servers I build. I was looking for a way to script it and was pleasantly surprised to find out that it’s just a single command that can be run at the command line.
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.
As we continue to forge ahead in our brazen quest to upgrade our enterprise to Windows 7, we’ve found ourselves reaching the limits of what we can reasonably expect from WDS and MDT. For us, jobsites pose an interesting issue with deployment.
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.
If you use WDS on a regular basis, you know that after PXE booting, WDS loads the Windows Boot Manager to allow you to choose which boot image you’d like to boot with. You’ll also have undoubtedly been a victim of time (which, by default, is 30 seconds) – where you look away for just a second (I swear!) and WDS has chosen the default boot image and begun to boot.
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.
I’d just like you to know that I’ve been pulling my hair out all week. I’m practically bald now. We’ve been using MDT 2010 for quite some time and I’ve been super happy with it. Until this week.
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.
I’ve seen a lot of buzz lately on the release of the App-V 4.6 Public Beta. Of course, I downloaded the new 4.6 clients because the most exciting feature (to me) in it is support for 64-bit App-V clients.
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″/>
In looking for an easy way to deploy operating systems to virtual servers, I started digging around for a way to import a WIM (like what comes on the 2008 installation DVD) into SCVMM’s library. Instead, I found something that might be a bit better (or at least more versatile): the WIM to VHD Converter.
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.
We’re in the middle of checking out App-V from Microsoft’s MDOP. At the moment, the deployment is limited to IT (and a fraction of IT at that). We’ve already figured out a lot of cool things about it, but we’ve also run across a few annoying things. In any case, I’ve run across something those testing might want to keep in mind. I wouldn’t call it a bug – the design is probably purposeful – but it’s something to be aware of.
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).