Exploring Exchange 2007 Mail-enabled contacts

In Exchange 2007 a mail-enabled contact represents a recipient outside your own Exchange organization. They can be recipients on your Domino server or external recipients with a partner etc. A mail-enabled contact always has at least two addresses, but can have several. One or more are addresses from you own SMTP domain that let you see the contact in the Global Address List (GAL) and send mail to it. The other is the “real” address, namely the address that Exchange forwards the message to. This is usually an address outside your own SMTP domain.

On a mail-enabled contact you have two options for setting properties for the addresses; Set as Reply and Set as External. Set as Reply configures which address should be specified as the reply address when someone wants to reply to the message that was sent to the contact. This was known as the Primary SMTP address in Exchange 2000/2003. You can set one reply address for each address type, e.g. SMTP or Notes. Exchange requires that you have a primary, or reply address, for each address type.

Set as External is a little more interesting. It specifies where the message will end up; it’s final address. As mentioned above, a contact can have several addresses from you own SMTP domain. When a message is received by Exchange sent to one of these addresses, Exchange will look up the external address and forward the message to that address. In effect, the internal addresses are aliases for this external address. The address selected as the external address is stored in the targetAddress attribute in Active Directory. You can only have one address that is marked as external.

The addresses discussed here need not be SMTP addresses; both reply and external addresses can be either SMTP or another type.

Only contacts have the Set as External option, regular mailboxes do not need a target address since the message will be delivered directly to a store in your own Exchange organization.

Moving to Virtual Server

Just finished moving all my virtual machines from VMware ESX server to Microsoft Virtual Server 2005 R2 SP1 (Beta 2). Had a couple of reasons for doing so:

  • The SCSI requirement for ESX was a pain; SCSI is quite a bit more expensive than IDE/SATA. Plus the IBM SCSI drive I used was incredibly loud.
  • I wanted to try out the new version of Virtual Server. R2, especially with SP1, has many new features.
  • The machine that was running ESX has several IDE drives. The space on these drivers were unavailable to me since running SAMBA on ESX is not supported and is not well integrated with AD. I wanted that space back.
  • I also wanted to move away from the rigid ESX system and run a pure Windows Server environment on all my servers. Now I can have a unified administration, management and patching solution.

Since the server running ESX was the same one that I wanted to run VS on I had to copy the VMs to another machine and migrate them, before moving them back into Virtual Server. This required quite a few steps:

  • Make a backup of the VM on ESX, and keep it in a safe place for recovery.
  • Uninstall VMware Tools from the VM and reboot.
  • Replace the HAL (hal.dll) and kernel (ntoskrnl.exe) with the standard ones (found on the CD or in the ServicePackFiles directory).
  • Run a cleanup script.
    The script disables all known VMware devices.
  • Shut down the VM.
  • Export it through the ESX file manager (in the web interface) or through vmkfstools.
    Just copying the vmdk file using WinSCP or FTP will not work. The file will be corrupt and unusable. The reason for this is the VMFS file system that is used by ESX.
  • Convert the virtual disk file (vmdk) to a Virtual Server VHD file using the vmdk2vhd utility available here:
    This is a nice utility that can convert a VMware vmdk file to a Virtual Server VHD file.
  • Move the new VHD files to the Virtual Server machine and create new VMs and select the existing disks.
  • Boot up the VMs and let Windows detect the new hardware, reboot when asked.
  • Install Virtual Machine Additions and reboot.
  • Configure IP address and verify all services.

After this procedure I had my VMs running on Virtual Server. The performance is quite good, even though I am running on only IDE drives now. There is a little performance drop as opposed to ESX, but weighed against the other drawbacks I experienced with ESX, that is not a problem. It will be interesting to see how the servers perform after some time.

I also tried out the new vhdmount utility in Virtual Server. This is a tool that can mount a VHD file on a computer without running Virtual Server or Virtual PC. The tool can be installed on Windows Vista as well, where it also supports the /m parameter which not only plugs the disk (physical) into Windows, but also mounts the partitions to drive letters in one operation. On Windows XP/Windows Server 2003 you have to use /p to plug in the disk and then assign drive letters to the partitions manually in Disk Manager.

There is a caveat, however. Since Virtual Server 2005 R2 SP1 is in beta, the driver that does the mounting and plugging is not signed. That means that Windows Vista, or XP/2003, will display an error when you try to mount a virtual disk:


The command will succeed but you will not see anything in Explorer or Disk Manager:022207_1414_MovingtoVir2

If you look in Device Manager you will see this:


The solution is to choose Update Driver Software… in Device Manager and manually point Windows to the vhdstore.inf file in the vhdmount directory. (Default location; C:Program FilesMicrosoft Virtual ServerVHDMount.) This requires not only telling Windows to look in the vhdmount folder for a driver, but to select Have Disk and manually selecting the vhdstore.inf file.

Afterwards, the disk should be available in Disk Manager and you can assign a drive letter to its partitions. The real killer is that you have to perform the manual driver installation each time you want to mount a disk. Hopefully VS 2005 R2 SP1 will RTM soon and the driver will be signed. Also, check out the VS SP1 release notes for information about how to install the vhdmount utility on a machine not running Virtual Server.

I am looking forward to playing with VS more in the coming days. The new support for VSS snapshots looks very promising. It lets you back up a running VM using the snapshot functionality provided by the Virtual Disk Service and the Snapshot provider.

Until next time.


The Case of the Missing File Transfer Manager

Everyone downloading from MSDN, the MCT Download Center or any other semi-open Microsoft download site, is familiar with the Microsoft File Transfer Manager application. It is a rather nice utility that is installed on your machine the first time you start a download from one of the sites I mentioned. It supports queuing and resume of downloads. As I said; nice.


It has, however, a rather nasty habit of disappearing once you close it. This makes it hard to resume your downloads if they did not finish, and to view your download history. The only way (well, not really, but more on that later) to start it again is to visit one of the Microsoft download sites and start a new download. Then it will launch again and you can examine the command line in Process Explorer and find where it is stored so that you can launch it again later without having to start a download. Or not…

I have gone through this exercise many times and I know where the FTM is installed, or at least I used to know, back when I was running Windows XP. Then it was something like c:windowsMicrosoft File Transfer Manager. But now I am running Vista, and it’s not at that location any more. I set out to find it, I mean, how hard could it be?

First I searched the machine for a filename containing trans, using Windows Desktop Search which is integrated into Windows Vista. No matches. Then I tried some variations on the filename; still nothing. So now I started looking in the Program Files and Windows directories trying to find it using empirical observation. Meaning that I manually looked in each folder in those directories. Still nothing. This was getting frustrating so I signed in to MSDN and started a new download. After the FTM started I checked it’s command line in Process Explorer:


And there it was; in c:windowsDownloaded Program FilesTransferMgr.exe. Success! So now let’s go there and make a shortcut on the desktop so that I have it ready next time I need it. This is how that folder looks in Explorer (with ‘show hidden and system files’ turned on):


This was getting really frustrating. Switching to my old friend, the command line I got some more info:


Finally I could see all the files. Now how do you make a shortcut from the command line? That’s right, you can’t (at least I don’t know how). So that left me with trying to view the actual files present in the Downloaded Program Files directory in Explorer, where I could create a shortcut.

A folder’s layout in Windows is controlled by a file called desktop.ini. It is present in almost all directories on a Window system and controls everything from the icon of the folder, it’s name and localized name. You can do some cool stuff with desktop.ini, but that is beyond this post. My guess was that it was the desktop.ini file that was responsible for the limited view I could see in Explorer. So let’s get rid of it.

C:WindowsDownloaded Program Files>del desktop.ini
Access is denied.

OK. So what are the file permissions?

C:WindowsDownloaded Program Files>cacls desktop.ini
C:WindowsDownloaded Program Filesdesktop.ini NT SERVICETrustedInstaller:F

The only account that has Full Control permission to the desktop.ini file is the NT SERVICETrustedInstaller principal. So who is the owner?

subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /display=owner
+File c:windowsDownloaded Program Filesdesktop.ini
/owner =trustedinstaller

Again, the NT SERVICETrustedInstaller principal.

Note: subinacl is not included in any Windows version and must be downloaded from the Microsoft Download site. It is included in the Windows Server 2003 Resource Kit, but that version does not work.

Note: You must run the above command from an elevated command prompt.

So let’s take ownership of the file, then we can change the permissions and delete it:

subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /setowner=Morgan
c:windowsDownloaded Program Filesdesktop.ini : simonsenmorgan is the new owner
c:windowsDownloaded Program Filesdesktop.ini : 1 change(s)

And change it’s permissions so that we can delete or rename it:

cacls “c:WindowsDownloaded Program Filesdesktop.ini” /G simonsenmorgan:F /E

Make a backup:

copy desktop.ini c:Usersmorgan.SIMONSENDownloadsdesktop.ini.bak

And finally delete it:

del desktop.ini

Now the view in Explorer is quite different:


Note: You have to close Explorer if it was open during the desktop.ini manipulation. Otherwise the customizations in desktop.ini are cached and remain in effect.

Now I could finally create a shortcut on my desktop:


Puh, what an operation!

Now for the real killer. This was all a waste of time! Remember that I said the only way to launch the FTM was to visit a Microsoft download site and start a new download? Well, once the FTM is running you can click on the Options button, and you see this:



Actually I knew that the option was there. Trying to save time, my first attempt was just to try to locate it in the file system and then launch it and click the option. But then I couldn’t and as I started investigating I discovered some interesting stuff about Windows Vista and that made it all worth while.

By the way, if you are trying this on your own system, you can set the system back to it’s default state with these commands:

copy c:Usersmorgan.SIMONSENDownloadsdesktop.ini.bak .desktop.ini
cacls desktop.ini /R simonsenmorgan /E
subinacl.exe /file “c:windowsDownloaded Program Filesdesktop.ini” /setowner=”NT SERVICEtrustedinstaller”

You, of course, have to replace my paths with your own.

Now for some sleep!