Zone Information for downloaded files and NTFS Alternate Data streams

Since Windows XP Service Pack 2 was launched, every time you try to run or open a file that has been downloaded from the Internet, or more correctly, from the Internet Zone in Internet Explorer. You are prompted with the following warning message:

 022207_2051_ZoneInforma1

What this message does, basically, is to warn you that you are opening a file that is downloaded from an un-trusted location. You can see further evidence of this if you view the file’s properties:

 022207_2051_ZoneInforma2

Notice the Unblock button on the lower right. If you select it, the next time you try to open the same file you see no warning. Somehow, by pressing Unblock, you have told Windows that you want to allow this particular file, even if it is from the Internet. But where is this information stored? I searched in all the places I could think of; attributes, DACLs, SACLs, details. What prompted me to do this was that I wanted to unblock several file and was looking for a command line utility to do it. Not even Google knew where this information was stored.

The reason I wanted a command line tool was this. If you download an archive from the Internet and then extract the files in it before you unblock it, all the extracted files are also marked as coming from the Internet and require individual unblocking.

When I attended Tech Ed IT Forum last week in Barcelona I asked Microsoft Security Guru Steve Riley about this, and, not surprisingly, he knew the answer. The information is stored in an NTFS alternated data stream!

NTFS alternate data streams are a little known feature of the NTFS file system, and have been available since Windows NT 3.1. This feature allows you to store data of any kind in an alternate location within a file. When we use files normally we are accessing stream 0. When you open an EXE file or a DOC file you are reading stream 0 of that file. But as I said, you can add several more streams. A while back, ADSs was the cause of a security scare. Someone had read about ADS and found them to be a security risk. What if a malicious user stored a virus or malware in an ADS? The user and all his anti-virus and anti-malware software, would be oblivious! As it turned out, this quickly blew over and now several anti-virus/malware packages scan for the presence of ADSs within files.

So how does this apply to files from the Internet? Consider this example; you have a file you have downloaded from the Internet. In my case it is called daemon408-x86.exe and is the installer for Daemon Tools. When I try to run this file I receive the warning mentioned earlier. Now that I know that this is caused by an alternate data stream I can use a tool to view and delete that stream. There are several tools available, but I chose streams from SysInternals. This is the output from streams for my file:

 022207_2051_ZoneInforma3

As you can see, this file has an ADS called Zone.Identifier:$DATA. To see what it contains we use the more command, which is part of Windows.

 022207_2051_ZoneInforma4

This is the raw data that is stored in the additional stream. Not very much in this case, just two lines of text. But this is what Explorer looks for when you ask to open a file.

To delete this additional stream so that the file opens without warning we again use streams from SysInternals.

 022207_2051_ZoneInforma5

If you want to know more about NTFS Alternate Data Streams, check out these links:

You can download the streams tool from the SysInternals site:

http://www.microsoft.com/technet/sysinternals/Utilities/Streams.mspx

Until next time!

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:
    http://vmtoolkit.com/files/default.aspx
    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:

022207_1414_MovingtoVir1

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:

022207_1414_MovingtoVir3

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.

Morgan

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.

 022207_1451_TheCaseofth1

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:

 022207_1451_TheCaseofth2

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):

 022207_1451_TheCaseofth3

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

 022207_1451_TheCaseofth4

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
BUILTINAdministrators:R
NT AUTHORITYSYSTEM:R
BUILTINUsers:R

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:

 022207_1451_TheCaseofth5

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:

 022207_1451_TheCaseofth6

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:

022207_1451_TheCaseofth7 

D’oh!

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!

Another SharePoint Services Update

I upgraded the server hosting the blog to WSS 3.0 RTM yesterday. Some small problems since I had been running TR2, but it worked out OK. Now I am just waiting for the Norwegian language pack to become available so that I can migrate the sites that are in norwegian.

Also have a few new posts ready, that I have written offline in the past two weeks. I could not upload them directly beacuse I have upgraded my firewall to ISA 2006 and it had to be reconfigured.

Morgan

Blog back online!

I finally got the blog back online (did anyone even notice that it was gone?).
I have completed an upgrade of the server that hosts the blog and am now running Windows SharePoint Service 3.0 Beta 2 Technical Refresh, intead of the old cBlog template for WSS 2.0.
I must say WSS 3.0 looks good. Looking forward to testing it some more. The bad news is that there is yet no language template for Norwegian, which is my native language, so all the other sites on the server are not yet available.
I will be back with more posts soon.

Testing Exchange ActiveSync with Internet Explorer

1. Open Internet Explorer. In the Address bar, type https://published_server_name/Microsoft-Server-Activesync, where published_server_name is the published name of your OWA server (the name your end users will type).

2. Type the user name and information that you want to authenticate.

3. If you receive an Error 501/505 “Not implemented” or “Not supported” error message, Exchange ActiveSync is working properly.

Exchange, SharePoint Services and ActiveSync Administration…

Running Exchange 2003 and SharePoint Services on the same machine can be a challenge, as is well documented:
I recently tried to accomplish this, but without much success.
First some background. I was trying to run Exchange 2003 Standard Edition with OWA/OMA and EAS and SharePoint Services 2.0 on the same server, which was also a Domain Controller. Actually, it was the only server in the network.
Things started out great, I installed Exchange and performed the steps outlines in KB817379 (http://support.microsoft.com/kb/817379/), which I had to do to get OMA and EAS to work since I did not have a Front-End Exchange server. After testing all the Exchange services I proceeded with installing SharePoint Services. It installed without incident, but then the trouble started. OWA was not working, the same for OMA and EAS. WSS, however, was working. I started troubleshooting and soon found the article I linked to at the beginning of this post. Following the steps in it I was able to get OWA working, but not OMA and EAS. Every time I tried to sync a phone or access OMA I got an error in the event log that said HTTP 400 Bad request. Bad request means a malformed request was sent to the server.
Literally, for days, I search the net and finally had to put in a call to Microsoft PSS. The technician and I spent even more days looking at logfiles and traces of communication between server and clients. We were stomped. I was seriously beginning to contemplate reinstalling the server from scratch. But then we found something.
If you read article KB817379, in step 21 you see the value of the new VDir registry key you will create. Not that the article explicitly states that it should be /exchange-oma, with a forward slash. When we looked at the trace logs from Exchange we found this:
As you can see we had double forward slashes. This was the cause of the Bad Request message. An HTTP GET requestcontaining two slahes is obviously malformed. When I removed the slash from the VDir value in the registry and restarted IIS all services worked.
When this problem was resovled I installed the ActiveSync Mobile Administrator. That was also pretty hard to get working together with WSS, but I succeded.

Information wants to be free!