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
I was moving a database from a production SQL server to a SQL Express instance. Per usual, I created a backup of the database on the production server and restored it to the Express instance.
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.
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 was working on my wife’s WordPress site tonight after she told me her contact form wasn’t working. I had been using the SMTP settings in php.ini to handle email across all the websites I support. But, I decided to stop using that because all emails were be coming from the same account, regardless of domain.
So, I started digging around and there is a plugin for WordPress called, aptly enough, WP Mail SMTP. This plugin is great because it allows me to set SMTP settings for individual sites, and it intercepts wp_mail() calls and sends them with the SMTP settings you give it.
This turned out to be my problem. The theme my wife uses has a built-in contact form, which was hard-coded to use mail() to send from the form. This no longer worked for me after I removed the SMTP settings from php.ini – even with the WP Mail SMTP plugin.
I started looking around at what exactly wp_mail() required to function. Here’s what the WordPress Codex says about what to pass it:
wp_mail($to, $subject, $message, $headers, $attachments);
Looks oddly like what the PHP Manual says about mail():
mail($to , $subject , $message, $additional_headers, $additional_parameters);
I tried changing the hard-coded mail() to wp_mail(), and there you go.
For those of you that prefer Firefox over IE, here’s a little gem to ease the troubles you undoubtedly have with SharePoint:
You can enable NTLM credential pass-through by doing the following:
Voilà! Now your SharePoint site is a “trusted site” in Firefox.
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.