Morgan Simonsen's Blog – Page 25 – Information wants to be free!

Exchange 2007: Exploring Global message size restrictions

Exchange 2003

In Exchange 2003 you set the global message size restrictions are set with Exchange System Manager under Global Settings, Message Delivery:

These settings are written to the Message Delivery object in the configuration partition in Active Directory. The object has the distinguished name (DN):

CN=Message Delivery,CN=Global Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

The attributes written are the following:

GUI Name

Active Directory Attribute

Sending message size

submissionContLength

Receiving message size

delivContLength

Recipient limits

msExchRecipLimit

Exchange 2007

In Exchange 2007 these settings are set using the Set-TransportConfig cmdlet. To view the settings you use the Get-TransportConfig cmdlet:

These settings are written to the Transport Settings object in Active Directory. The object has the following DN:

CN=Transport Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

The same attributes are used but on a different object.

PowerShell Name

Active Directory Attribute

MaxSendSize

submissionContLength

MaxReceiveSize

delivContLength

MaxRecipientEnvelopeLimit

msExchRecipLimit

Exchange 2007 comes with a setting of ‘unlimited’ for all these values.

Co-existence

As mentioned, Exchange 2007 uses ‘unlimited’ as the default setting. But there are a few situations where these limits do not work as expected.

These situations are:

If you have both Exchange 2003 and Exchange 2007 servers in your Exchange organization
If you previously had Exchange 2003 and are now running Exchange 2007, and had a period of co-existence between the two systems.
If you previously had Exchange 2003 and are now running Exchange 2007, but have not had co-existence between the two systems.

If you have been in one of these situations it is a good chance that your global message limits are not working as expected. The reason for this is that if the Exchange 2007 Transport Configuration is set to unlimited, the Exchange 2007 store will read the old Exchange 2003 value. This means that if your Exchange 2003 value is set to 10 MB and the Exchange 2003 value is set to unlimited, you actually have a global message limit of 10 MB.

The situations when this might occur are listed above, and the reason is that the value is set in different places in Exchange 2003 and 2007 and may be “left behind” when you remove Exchange 2003. Or may have been left behind when you removed Exchange 2003.

Workaround

To fix this issue when you are in a co-existence situation, make sure the two values are synchronized. Set them to the same value using ESM for Exchange 2003 and the Set-TransportConfig cmdlet for Exchange 2007. When you are ready to remove Exchange 2003 completely, set the limits in ESM to unlimited. This is the same as Not Set in Active Directory, meaning no vale to read. That way there is no vale for the Exchange 2007 store to read and it uses the Transport Config value, whatever it is set to (including unlimited).

If you already have removed Exchange 2003 and are experiencing this problem, use ADSI edit to remove the values from submissionContLength, delivContLength and msExchRecipLimit on the Message Delivery object in the Configuration partition. Exchange 2007 will now heed the Transport Config values.

Microsoft is planning to resolve the problem with the Exchange 2007 store reading the old value in Service Pack 1 for Exchange 2007.

Note: There are also several other message size limits defined in Exchange 2003 and Exchange 2007. Connectors, users, SMTP Virtual Servers can also have limits. The limits discussed here are the global message limits.

Some more info here:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=943981&SiteID=17

Nice tricks with the context menu in Windows Vista

For a long time, we have been enjoying a Windows XP Power Tool called “Command prompt here” on our directories’ and drives’ context menus. I recently discovered that Windows Vista has this functionality build in.

If you right-click your directory or drive while you press the SHIFT key, you get a few more choices. One of them is Open Command Windows Here. You also get Copy As Path which copies the path of the folder or drive to the clipboard. That is also very nice.

I wanted to have the command line available at all times so I had to do some digging in the Registry. The paths for the context menu actions for a directory and drive are the following:

Directory:
HKEY_CLASSES_ROOTDirectory
Drive:
HKEY_CLASSES_ROOTDrive

Under these you will find the shell key, it contains all the context menu actions associated with the drive or directory objects. E.g. cmd for command prompt, find for Search etc. The first thing to notice is that the cmd action is already there, so why isn’t it showing up all the time?

The answer is the value you will find under the cmd key kalled Extended. If this value is present the action will only show up if you hold down the SHIFT key while you right-click. We want the prompt available at all times so we go ahead and delete the Extended value from both the Directory and Drive keys. Now the option is always available.

But what if we want an elevated prompt in the directory? We are all, of course, running User Account Control so we need to elevate to enable our Administator privileges when we need them. To have the option to open an elevated command prompt for your drives or directories we need to take some additional steps.

First we need a copy of cmd.exe, the command line program that we will set to always run elevated. Go to your system32 folder and create a copy of cmd.exe that you call cmd_elevated.exe or a name of your choice. Then select the properties for this new file and select that it should always run as an administrator.

Next, you export the cmd action from the Directory and Drive keys in the registry. We are now going to create a new action that will launch the elevated command prompt. First merge the two exported registry files into one so that you can easily import both changes. Then you need to change the alias of the command so that our new item does not overwrite the old normal command prompt. The old alias is cmd, call the new one cmd_elevated or something. You will then have a file that looks like this:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTDirectoryshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDirectoryshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””
[HKEY_CLASSES_ROOTDriveshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDriveshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””

Notice that the Extended key is missing from both the actions, that is so that the option will always appear. Now you can import the file and you will have two shiny new options whenever you right-click a drive or directory:

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:

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:

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:

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.

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.

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!

Morgan’s favorite quotes #1

Religion:

“May God protect you from his followers.”

Good luck:

“May the Wombat of Happiness snuffle through your underbrush.”

Ancient Aborigine blessing

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:

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

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.

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.

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

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:

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.

Windows Live Writer..

This is a test of Windows Live Writer. Wonder if it will work with my own cBlogs site. Have to check that once I can get my VMWare server backup up after the last thunderstorm.