Windows DHCP Server – MMC Console Icons Reference

The DHCP Server MMC Snap-in annoyingly doesn’t have a legend for what the icons mean. Every time I debug a DHCP Server-related issue I’ve forgotten what the icons mean from the last time I’ve done it.

Here are the references up on TechNet:

DHCP console icons reference - Windows Server 2003, 2008

DHCP console icons reference - updated for Win2008 R2

Emulating %LOGONSERVER% For Computer Startup Scripts

%LOGONSERVER% is a useful environment variable to use in logon scripts to see which DC has serviced your request and can be handy to reference if you want to access additional files/shares on the DC. Unfortunately this environment variable is only accessible after logon and isn’t useful for computer startup scripts.

When I need to access the DC that’s providing me with GPOs during a computer startup script I emulate %LOGONSERVER% with the following code:

for /f "tokens=1 delims=\" %%i in ('@echo %0') do set DOMCTLR=\\%%i

%DOMCTLR% can now be used in the same way that
%LOGONSERVER% is used.

Workarounds For When “Add Virtual Hard Disk Wizard” Fails (Which Seems To Be All The Time…)

Adding new fixed sized VHDs using the Add Virtual Hard Disk Wizard in the Hyper-V console for some reason has stopped working for me on just about all my installs, with no errors logged. The VHD is created, but the progress slider bar never progresses and it will sit there, forever. It’s got to the point where I don’t use it and haven’t the time to debug the underlying cause.

A GUI-friendly way to work around this problem is to point Computer Management at the Hyper-V host and use Disk Management to Create the VHD.

Another way of doing this quickly is by using VHD Tool – although this doesn’t zero out the VHD and can leak information from the Hyper-V host and previous virtual machine’s disks into the newly created VHD. It is a great tool for lab work though.

Diskpart can also be used to create the VHD from the command line on the Hyper-V host. The command to do this is:

create vdisk file=”d:\path\to\file.vhd” maximum=<size in MB> type=fixed

UPDATE: So apparently I'm getting this error on networks where the domain controllers are still running Windows Server 2003 and an authoritative restore of Active Directory has been performed. The fix for this is to install MSKB 939820 on all the Windows Server 2003-based domain controllers in the affected domain. Interestingly I only found this trying to resolve a System Center Essentials 2010 installation.

Navigating Remote Symlinks on a Windows Server from a Windows Client (or, Poor Man’s DFS Links Without DFS Installed)

I set up a bunch of symlinks in a share on a Windows Server 2008 R2 install, pointing to a range of different UNC paths. My testing on the server showed that the symlink traversal was working fine, but on a Windows 7 install I was getting the following error:

“The symbolic link cannot be followed because its type is disabled.”

Odd error. After much mucking about I found that the fsutil command is used to control this behaviour. The following command was used to display the current symlink evaluation methods:

fsutil behavior query SymlinkEvaluation

which resulted in the following:

Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

Bingo. The Remote to Local evaluation mode is disabled, which is causing the error. Local to Remote evaluation mode is enabled, which is why the symlink traversal was working on the server. I verified that the problem was resolved by issuing the following command on the Windows 7 install:

fsutil behavior set SymlinkEvaluation L2L:1 L2R:1 R2R:1 R2L:1

Excellent, the symlinks are now followed without error. Finally I rolled out the above change via Group Policy. The four modes can be controlled by using Group Policy Editor and navigating to Computer Configuration > Administrative Templates > System > Filesystem and configuring "Selectively allow the evaluation of a symbolic link".

Outsourced Authentication – Smart or Dumb?

A couple of months ago I closed my Facebook account, partly because of the continual privacy abuse by Facebook, but mostly because of what I thought was poor tooling for managing my social graph and timeline.

Since that point I’ve noticed more and more companies outsourcing their authentication mechanism to Facebook. Smart or dumb? Smart, because you’ve offloaded a password database that you can’t lose or have compromised, although you still have a client database that can. Dumb, because you’ve lost a prospect or customer like me.

If you’re going to outsource authentication it might be an idea to use OpenID instead. OpenID Explained is a good site to understand how OpenID operates. It’s worth noting that most of the major Web players are already OpenID Providers. If you don’t have an existing account with an OpenID Provider, then MyOpenID is a good place to start.

Office 2010 SP1 Is Death For Access Developers

My talented wife started complaining last week that Microsoft Access started continually crashing trying to open databases after performing some design modification.

Some cursory debugging wasn’t providing consistent bugchecks, so rather than putting more effort into understanding the symptom I then looked for a cause. Design edits were working the week before the crashes so I then looked at updates. Office 2010 SP1 had been installed during that time, so I uninstalled SP1 and tried again. Bingo, database editing no longer resulted in Access crashes.

If Access databases are suddenly crashing on you for no reason, check to see if Office 2010 SP1 is installed.

UPDATE: Microsoft fixed this with a hotfix described in MSKB 2553385.

FreeBSD 8.1, 8,2 and Hyper-V R2 SP1 Install Problem - Use Fixed Size VHDs

Just tried installing FreeBSD 8.1 and 8.2 virtual machines on a Windows Server 2008 R2 Core install with the Hyper-V role installed and with SP1 applied. newfs created the file systems just fine, but the distribution unpacking would cause random kernel panics, throwing ‘ufs_dirbad: bad dir ino XXX at offset XXX: mangled entry’ errors.

I’d created the VHDs as dynamically sized VHDs. I blew these away and created fixed size VHDs and attached them to the VMs. I’ve been repeatedly performing full distribution installs without error. I managed to find a Hyper-V R2 box without SP1 and couldn’t replicate the install problem with dynamically sized VHDs, so Microsoft have introduced a problem with SP1.

If you’re seeing disk-related problems with your UNIX/UNIX-like VMs on Hyper-V, check to see if you’re using dynamically sized VHDs and convert them to fixed size VHDs to see if this fixes the problem.