Archive for Windows Server Core 2008

Symbollic Links on Vista and Windows 2008

// July 5th, 2009 // 1 Comment » // Windows Server Core 2008

After changing jobs years ago and focusing more time on Windows and less on Linux I had nearly forgotten how handy symbolic linking is.  I’ve played with using junctions with NTFS, but didn’t have to use them often.  Now that I’m running Vista and Server 2008 I’m remembering why I used to love symbolic links.  We now have the mklink command in both operating systems, and it’s pretty simple (although it’d be hard to mess something so basic up):

C:\>mklink /?
Creates a symbolic link.

MKLINK [[/D] | [/H] | [/J]] Link Target

/D      Creates a directory symbolic link.  Default is a file
symbolic link.
/H      Creates a hard link instead of a symbolic link.
/J      Creates a Directory Junction.
Link    specifies the new symbolic link name.
Target  specifies the path (relative or absolute) that the new link

However, after creating my symbolic link and sharing it I experienced a strange issue on my remote Vista machine.  I received the error message: “The symbolic link cannot be followed because its type is disabled.”

I immediately thought it was a Vista security issue and I could probably find something to change under secpol.msc.  After a little digging I found one policy for symbolic links under Local Policies > User Rights Assignment > Create Symbolic Links
secpol_1

That was great to know, but I was already an admin so creating the link wasn’t an issue.  After digging around there I checked out gpedit.msc:
gpedit - Symbolic Link EvaluationBingo.  That setting can be tweaked to:

  • Local Link to a Local Target
  • Local Link to a Remote Target
  • Remote Link to Remote Target
  • Remote Link to Local Target

Needless to say that’s very helpful setting to have if you’re going to have Vista or Server 2008 clients access the symlinks.  I also discovered that because this is considered part of the NTFS file system that you can use the handy fsutil command to tweak this.  If you’re not in a domain environment and experiencing this issue you can simply run these commands:

  1. fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
  2. fsutil behavior query symlinkevaluation

The second of which should have output like this:

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

Try it again and you should be able to access your data.

“Group cannot be specified along with other identification conditions.”

// October 31st, 2008 // 13 Comments » // Windows Server Core 2008

While using server core yesterday I came across another interesting error.  I was attempting to update a firewall rule and I kept receiving this error:

“Group cannot be specified along with other identification conditions”

I double checked my spelling and syntax and everything looked right.  Take a look at the picture below, can you see my mistake?

It turns out it was actually a pretty dumb issue, but an easy one to overlook.  I had copy and pasted the command in from a webpage, and the quotes must have been Microsoft Word style quotes.  I deleted the quotes, re-ran the command, and success!  It’s a minor issue that was easy to overlook.  In this case it was quick to find and fix, but it reminded me of the days when I searched for an error in my .NET code only to see that two single quotes ”  looked like one ” double quote character.  It took forever to find the error because everything appeared right, but of course it wasn’t.

Microsoft Server 2008 Core and Netdom

// October 30th, 2008 // 2 Comments » // Windows Server Core 2008

I setup a proof of concept to migrate some of our servers to Microsoft Server 2008 core edition today. The first test was run on my local workstation using VMware Workstation 6.5. While working on that I came across an odd issue.  When I attempted to join the domain in question with netdom I received “The network path was not found” as an error.

The command is pretty straight forward and difficult to mess up:

netdom join <computerName> /Domain:<domain> /UserD:<userid> /passwordd: *

I double checked the obvious things like my static DNS entries being correct, in the right order, my WINS entires being there, the fact that I could ping/trace the domain controller in question, and so on.  Even though the NIC appeared to be working correctly it wasn’t using the right driver.  Next I did what all decent systems admins do, I did a Google search and found a whole lot of nothing.

It was at that time that I realized the tools may not be installed correctly on server core.  I mounted the VMware Tools CD, browsed to the D: drive, and performed a “VMware Tools.msi /quiet”.  msiexec should kick in and begin installing the drivers behind the scenes.  Once it’s done it’ll reboot the server by default and after that you should be able to join the domain without any issues.