VMWare Fusion 5.0 and Remote Desktop (RDP) Port Forwarding

So, the dilemma with my previous post’s setup is that I now have two VM’s that reside on the same VLAN, and one of them is an AD.

The current problem is that I want to access the second (non-AD) server from the outside world, outside of the host machine.  Normally, this is a private VLAN and there’s no access, but you can configure port forwarding so that you map port 3389 (external host) to one of the statically mapped internal hosts (for me, located at

Here’s the deal:

The file /Library/Preferences/VMware Fusion/networking appears to be produced by the VMWare Fusion networking configuration dialogs.  It appears to drive the creation of the files /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf and /Library/Preferences/VMware Fusion/vmnet8/nat.conf.

The latter of these two files, nat.conf, contains the location where we need to change the NAT settings to allow port 3389 requests to the host to be forwarded to the private VLAN.  The problem?  This file is periodically overwritten by VMWare processes when VMWare is restarted, network configuration changes are made in the GUI, etc.

I don’t have a long term fix for you here -> I can’t find any answers online or in the documentation.  Ideally, you would make the changes to the /Library/Preferences/VMware Fusion/networking file, and restart VMWare or reset the VMware network stack, and the system would regenerate working copies of the nat.conf file.  The problem is the VMWare GUI doesn’t support port forwarding configurations, and you can “hand hack” the nat.conf file if you’re willing to backup you changes or risk losing them periodically.

Networking file sample (/Library/Preferences/VMware Fusion/networking)

answer VNET_1_DHCP yes
answer VNET_1_DHCP_CFG_HASH 4DB1B0245BA0BF9FBCD5D55DA675F9D605B179EF
answer VNET_8_DHCP yes
answer VNET_8_DHCP_CFG_HASH 946433F88FFC278E2E5B8A325353B972A0B5D762
answer VNET_8_NAT yes
add_bridge_mapping en1 2

Basically, you can see there are no available settings for port forwarding.  None the less, this file is transformed by backend processes into nat.conf, which includes this snippet at the end:


# Use these with care – anyone can enter into your VM through these…
# The format and example are as follows:
# = <VM’s IP address>:<VM’s port number>
#8080 =
3389 =

I’ve added the last line to this file to map the RDP service into the VLAN’ed VM.  So, any RDP requests coming into my host machine will be redirected into one of my VM’s.

Once this change is made, you can reset the network interface and load these changes as follows:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

The only problem now?  This file is overwritten when restarting VMware, so I’ve backup up the configuration, and have a script that I quick rerun prior to starting the VM’s (copy over file, stop, then start the interface).  Clunky, but workable.  If you know a way around this, let me know….

Another way, BTW, to see this “overwrite” process is to simply run the configure command:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure

This will blow away your nat.conf changes, which you’ll need to reset.


Challenges with quickly looking up document properties using Document ID’s in SharePoint

Just a few running notes on my work with Document ID’s in SharePoint 2010.  The main challenge that I’m seeing in general with Doc Id’s is that they can only be resolved in one of two ways to actual documents:

  1. You can run a search within your SharePoint search center in the form “docid: 6WJUPFHUC735-11-1” (you can use your own ID in this case).  I presume in the event that you are using FAST, you’ll want to search on “spdocid:” but I haven’t verified this yet.
  2. You can send a query to “http://<serverurl>/_layouts/DocIdRedir.aspx?ID=6WJUPFHUC735-11-1&#8221;, which simply issues a 302 (object moved redirect) and sends your browser to the file content.

In both of these cases, however, the challenge is that you are unable to immediately get to document properties or other ways of manipulating the document.  You either need to take the resulting search result (parsing the search result) to track down a reference to the document (solution #1, above), or you need to parse the contents of the 302 redirect and perform an additional query to lookup the document properties.

From a Document Id, there is not a straightforward way (in a single hop) to get a reference to the document object or the document metadata.  Perhaps I’m obsessing here, but it just feels like you shouldn’t need two hops from Document Id before you can view document metadata.

I’ll be posting further on this once I find a solution…

Removing Unversioned Files and Modified Files as Part of a Continuous Integration Build

As part of my continuous integration builds using CruiseControl, I’ve fallen into the habit of the following pattern:

  1. Perform an SVN Update (get the latest release)
  2. Overwrite the updated project directory with a set of static files. For example, if my project lives in ${cc.home}/projects/${project.name}, I’ll have another directory under ${cc.home}/nonvcsfiles/${project.name} in which I store unversioned content.
  3. Perform the build
  4. Copy out the build artifacts.

Why do I follow such a pattern, you ask? The reasons are twofold:

First, I deal with some rather complex deployments to multiple servers, etc. and this is an easy way of overwriting properties files, web.xml files (Java), and web.config files (.NET) with server specific values. Since I also use CruiseControl to deploy to these servers as part of a larger, integration test scheme, I might have the same build doing a lot of different things. This way, I can store a directory of new or modified files that is simply xcopied over the build directory AFTER the SVN update. When producing artifacts such as WAR files, it allows me to pre-tailor the web.xml file prior to deployment.

Second, it allows me to copy in large quantities of binary files that might be linked in. A number of my projects are now making use of Maven and Artifactory to maintain version relationships to Jar files, etc., and I’m aware that you can use svn:externals to store external libraries or code. In some cases, however, I’m using the same CruiseControl instances to build .NET, Java (ant) and Java (maven) projects all at once, and the simplest thing to do is copy external library binaries into the requisite lib directories without putting them explicitly under version control. Maybe you’ve got a problem with this, and I can understand that, but sometimes, the quick solution is the easy solution. We keep good records of our library dependencies, and store them under a directory structure that makes versioning evident; additionally, we document the dependencies and versions in a repeatable way. Enough about that, that’s another holy war…

The net result of this is that once I’m done with a build in CruiseControl, my build directory is littered with modified configuration files, and newly copied binary libraries and some other crud. The question is, what do you do to revert your build directory back to it’s pristine, trunk versioned goodness?

The answer is twofold: revert any modified files using svn revert, and then delete unversioned files and directories.

The second part of that turned out to be a little trickier than I would have thought. If you want to delete unversioned files automatically, you’ve got a bit of problem: you need some external scripting or a quick macro / command line argument, which required some research.

After a little looking, I found a nice summary of methods that you can use at this link: Automatically Remove Subversion Unversioned Files. It shows a number of methods and number of scripting languages.

For my use, I need to do this on a Windows 2003 machine with the subversion command line tools. Unfortunately, in the link above, I did find a solution for a command line script on windows, but it doesn’t work for directories, and it doesn’t work for files with spaces in the name. However, with a few tweaks, here’s the three lines of script needed.

svn revert -R .
for /f "tokens=1*" %i in ('svn status ^| find "?"') do del /q "%j"
for /f "tokens=1*" %i in ('svn status ^| find "?"') do rd /s /q "%j"

The first line reverts any of the files that are modified. The second line deletes any unversioned files, and the third line deletes any unversioned directories (and their contents, recursively).

There are two GREAT things about this process:

  • If there are certain build files or directories that you don’t want deleted or cleaned up, you can add these to the svnignore list, and these will be ignored by version control and NOT deleted via this process.
  • This ensures that any additional non-versioned files that make it onto your build server over time are accounted for, either appearing in version control, or appearing the special nonvcsfiles directories.

The final step is to drop these items into an ANT task that can be called either before a new build, or at the end of a build to clean up. Just use the exec method for each line, like this:

<!-- clean out nonversioned files -->
<target name="clean">
<!-- revert all SVN version controlled files -->
<exec executable="svn">
<arg value="revert"/>
<arg value="-R"/>
<arg value="."/>

<!-- delete all unversioned files not explicit ignored by SVN-->
<exec executable="cmd">
<arg value="/c"/>
<arg value="for /f &quot;tokens=1*&quot; %i in ('svn status ^| find &quot;?&quot;') do del /q &quot;%j&quot;"/>

<!-- delete all unversioned directories not explicit ignored by SVN-->
<exec executable="cmd">
<arg value="/c"/>
<arg value="for /f &quot;tokens=1*&quot; %i in ('svn status ^| find &quot;?&quot;') do rd /s /q &quot;%j&quot;"/>