Microsoft Exchange supports Send As and Send On Behalf Of permissions to be granted to users for individual e-mail addresses. Sending e-mail from Outlook for these users is very simple – they just enter the desired address in the From field of a new message (toggled with the Show From command on the Options ribbon) and if they have the required permission it will be sent accordingly – either as if it was actually sent from that address or as sent by the user on behalf of the address in the From field.

If you want to achieve this from code there is a little more work involved. First of all the user must be authenticated on the server using one of the methods below:

SmtpClient smtp = new SmtpClient("smtp.domain.com");

// use user’s existing credentials
smtp.UseDefaultCredentials = true;

// pass username and password
smtp.Credentials = new NetworkCredentials("username", "password");

The next step is to set up the correct headers in the message otherwise the server will return error code 5.7.1 describing the permission the user does not have.

To send the e-mail as only the From property has to contain the desired address:

MailMessage mail = new MailMessage();
mail.From = new MailAddress("send.as@domain.com");

To send the e-mail on behalf of another user the Sender property must additionally contain the user’s e-mail address:

MailMessage mail = new MailMessage();
mail.From = new MailAddress("send.as@domain.com");
mail.Sender = new MailAddress("user.address@domain.com");

On a related note, the required permissions can be granted using PowerShell.

To grant the Send As permission:

Add-ADPermission –Identity "user1" –User "user2" –ExtendedRights Send-As

To grant the Send On Behalf Of permission:

Set-Mailbox "user1" -GrantSendOnBehalfTo "user2"

In both cases the user1 specifies the mailbox to grant the permission for and the user2 specifies the user to grant the permission to.

Today I decided to get to the bottom of the missing driver issue on my computer running Windows 7 RC. It shows up as PCI Simple Communications controller and it really bugged me since I don't have a modem or a similar device on the motherboard.

It turned out that there is a away to identify such a device from the information available in Device Manager. The first step is to open the Properties window for this device and move to the Details tab. After selecting the Hardware Ids in the Property dropdown the device identifiers are displayed.

The important ones are the numbers written after the VEN and DEV keywords. The first one is the Vendor ID and the second one is the Device ID. So in my case the Vendor ID is 8086 (from VEN_8086) and the Device ID is 29A4 (from DEV_29A4).

All that's left to do know is to go to PCIDatabase.com and enter the ids into the corresponding search boxes. In my case it turned out that it was a device from Intel - Intel Management Engine Interface (HECI). Unfortunately it doesn't have a driver for Windows 7 yet and the Vista one doesn't install. But hey, at least I know which driver is missing.

Gama System eArchive, one of the two products in our document product line, received accreditation from the Archives of the Republic of Slovenia last week. This acknowledgement by our national body means that any document stored in Gama System eArchive is automatically legally valid.

This is important for both our company and other companies looking for a long term electronic document storage solution. Our product is the first service oriented solution to receive the accreditation.

Congratulations to everyone involved in the product. Well done!

Today I've taken my new handeld GPS device for a test run. It did its job pretty well but the real challenge started afterwards when I tried geotagging the photos I've taken. I decided to use Microsoft Pro Photo Tools which have just been released with geotagging as its main feature. Downloading the track data from the GPS device with Garmin MapSource software was quick and simple. But the problems started soon afterwards. MapSource can only export track data in its proprietary format GDB which can't be used in Microsoft Pro Photo Tools.

GPSBabel came to the rescue. This free tool can probably convert files between any two existing GPS formats, at least judging from its list of supported formats. I used it to convert my data to the GPX XML format only to find out that Microsoft Pro Photo Tools have problems with it. Converting to NMEA or KML instead didn't help either. Fortunately the latter returned a strange error (Degrees must be between 0 and 90, found degree 46298501) which put me on the right track. Of course there was no such value in the KML file so I correctly deduced that the decimal separator was to blame.

The value in the file was 46.298501 but the Slovenian regional settings have comma as the decimal separator therefore the value was misinterpreted. Temporarily changing the decimal separator to dot solved the problem - the track was successfully imported immediately afterwards. This issue won't keep me from using this otherwise very useful tool with a really nice feature set. It could even fix the mismatching time settings between my GPS unit and the camera with a single setting. I just hope they address this bug soon so that I won't have to change my regional settings every time I use the program.

The only thing I still have to figure out is why the geotags somehow lost resolution when I uploaded the photos from Picasa to Picasa Web Albums. I just fixed them manually and decided to address the issue next time. Any tips are welcome.

A .NET application in the company I work for recently started crashing under Windows Vista when trying to open a window implemented in an ActiveX DLL. Investigations showed that they were caused by an AccessViolationException "Attempted to read or write protected memory. This is often an indication that other memory is corrupt.". The cause was one of the ActiveX controls in the window. When instantited directly in a .NET Form the exception above was contained in a TargetInvocationException "Unable to get the window handle for the '<control name>' control. Windowless ActiveX controls are not supported.". Knowing that the control didn't suddenly turn windowless we dug deeper.

It turned out that the problem appeared with .NET Framework 2.0 Service Pack 1. Apparently it caused the C# compiler in Visual Studio 2005 and later to set the NXCOMPAT bit for all build targets without an option to turn this new behavior off. For those who don't know, this means that DEP (data execution prevention) will kick in unless it is turned off completely in the operating system. This wouldn't be a big deal unless ATL before Visual Studio 2005 didn't have a bug which caused the heap allocated memory not to be flagged as executable, which under the new circumstances results as the already mentioned exception. Windows XP has DEP turned off by default therefore everything still works but in Windows Vista it is turned on and prevents such application from functioning properly.

The best solution would of course be to recompile the ActiveX controls in Visual Studio 2005 or later but this might not be possible if they are supplied by a third party. In this case the most obvious approach to dealing with the situation is to disable DEP in Vista. There is a Data Execution Prevention tab in the Performance Options which open when you click the Settings button in the Performance frame of the Advanced tab in the System Properties dialog but it only allows switching between DEP for all processes with defined exceptions and DEP for essential Windows programs and services, i.e. executables flagged with the NXCOMPAT bit. The only way to turn DEP completely off is executing the following command with administrative privileges:

bcdedit.exe /set {current} nx AlwaysOff

After restart DEP will be turned off and problematic binaries will work once again. To restore the previous (default) state replace AlwaysOff with OptIn. The AlwaysOn option enables DEP for all processes and might cause additional problems (e.g. Google Calendar Sync in its current version 0.9.3.2 doesn't work in this mode).

Unfortunately, this solution would require all your Vista using customers to disable DEP as well which really isn't an option for commercial software. Fortunately, there is another solution. Although there is no compiler option to turn keep the NXCOMPAT bit unset, you can still do this after compilation using the editbin.exe which comes with C++ compiler for Visual Studio 2005 and later:

editbin.exe /NXCOMPAT:NO <filename.exe>

This command removes the NXCOMPAT bit and restores the behavior before .NET 2.0 SP1. If your assembly was signed it also invalidates the signature so you'll have to resign it:

sn.exe -R <filename.exe> <keyfile.snk>

You can automate this by putting the two commands in the Post-build event command line for the project:

editbin.exe /NXCOMPAT:NO "$(TargetPath)"
sn.exe -R "$(TargetPath)" "$(ProjectDir)<keyfile.snk>"

You might need to call vcvars32.bat before that to put the required executables in path and enable editbin.exe dependencies to be resolved. Note that in a completely automated build scenario using MSBuild you'll have to specify full path for the vcvars32.bat because $(DevEnvDir) resolves to *Undefined* outside Visual Studio 2005. Also your strong name key should be in a snk file instead of a password protected pfx file because sn.exedoesn't allow the password to be read from a redirected standard input.

The MonthCalendar control's BoldedDates functionality doesn't appear to work properly on Windows Vista. The dates added to any of the BoldedDates, MonthlyBoldedDates and AnnuallyBoldedDates collections are rendered just the same as those not added to any of the collections. The same code works just fine on Windows XP and causes those dates to be rendered bold. The only workaround i've managed to find is disabling visual styles in the application, i.e. commenting out the first line in the Program.Main() method of a new Windows Application:

Application.EnableVisualStyles();

The Xbox 360 Dashboard update released on 4th December 2007 added support for playing DivX and XviD videos natively, i.e. without installing Transcode 360 for Windows Media Center. Unfortunatelly this only works for media played directly from the dashboard and not within Media Center Extender. Since I didn't want to copy my videos to CDs, DVDs or other external devices, the only thing left to do was to setup Windows Media Player media sharing which I never had to use before.

This turned out to be more difficult than I expected - the reason being that the media I wanted to share wasn't stored locally but on a separate file server. By default such media is not shared and there are few steps one has to follow to make this work, as thoroughly explained here:

• Enable remote content sharing by adding the following entry into the registry:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MediaPlayer\Preferences\HME]
  "EnableRemoteContentSharing"=dword:00000001
• Grant anonymous users access to the shared folders on the file server by adding the read permission on the folder and on the share to the ANONYMOUS LOGON user
• Modify the file server's group policy to allow anonymous access to the selected shares by listing them in the Network access: Shares that can be accessed anonymously policy in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options branch of the group policy tree (just run gpedit.msc to start the Group Policy Object Editor)

In my opinion RSACryptoServiceProvider class is seriously under-documented in MSDN. Since there is also no abundance of examples on the web, I spent more time than I should figuring out how to use it correctly. For future reference I'm listing below the solution to two problems I had.

The maximum byte array length for encrypting without OAEP padding is Modulus size - 11 which is written somewhere in the Encrypt() method documentation. If you pass it a larger array it will return a not so informative Unspecified error. To encrypt a larger chunk of data you have to split it in smaller parts, encrypt them individually and concatenate them back together. You have to do the same when decrypting the data, with the only difference that each part has the size of Modulus in stead of Modulus - 11. To get the modulus size you can use the following piece of code (rsa is an instance of RSACryptoServiceProvider):

RSAParameters rsaParams = rsa.ExportParameters(false); int modulusSize
= rsaParams.Modulus.Length; 

Each time you instantiate RSACryptoServiceProvider it generates a new pair of keys. If you want to use existing ones, you can import them by calling:

rsa.FromXmlString(key);

The key parameter is a string with the XML representation of the keys. You can get it by calling the ToXmlString() method once and storing its results. It's only parameter specifies whether to also export the private key. I guess I don't have to remind you that you need the private key only for decryption and that you should always keep it private for the encryption to make any sense at all.

Is the code below correct? Will inputString and outputString be equal?

              string inputString
= "The text to compress and decompress"; byte[]
inputArray = Encoding.UTF8.GetBytes(inputString); MemoryStream stream = new MemoryStream();
DeflateStream compressionStream = new DeflateStream(stream,
CompressionMode.Compress); compressionStream.Write(inputArray, 0, inputArray.Length);
compressionStream.Flush(); stream.Position = 0; DeflateStream decompressionStream
= new DeflateStream(stream, CompressionMode.Decompress); byte[]
outputArray = newbyte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length); string outputString
= Encoding.UTF8.GetString(outputArray); Console.WriteLine(outputString == inputString);
Console.ReadLine(); 

As it turns out, they won't. The reason for it being that compressionStream.Close() was not called before reading from stream started. Calling compressionStream.Flush() is not enough in this case. I haven't managed to find this documented anywhere but the example in the DeflateStream documentation does it correctly. You can find the fixed code below. Notice the additional last parameter in the first call to the DeflateStream constructor. Without it stream will also be closed when compressionStream gets closed.

              string inputString
= "The text to compress and decompress"; byte[]
inputArray = Encoding.UTF8.GetBytes(inputString); MemoryStream stream = new MemoryStream();
DeflateStream compressionStream = new DeflateStream(stream,
CompressionMode.Compress, true); compressionStream.Write(inputArray,
0, inputArray.Length); compressionStream.Close(); stream.Position = 0; DeflateStream
decompressionStream = new DeflateStream(stream, CompressionMode.Decompress); byte[]
outputArray = newbyte[inputArray.Length];
decompressionStream.Read(outputArray, 0, outputArray.Length); string outputString
= Encoding.UTF8.GetString(outputArray); Console.WriteLine(outputString == inputString);
Console.ReadLine(); 

Thanks once again to my coworker for suggesting this when I was already running out of ideas.

Not so long ago I've been called to my boss's office to prevent him losing unsaved work in a PowerPoint presentation. It turned out that when he tried to save the file to a new location the message box with the overwrite warning for some reason didn't render completely and it was impossible to close it. As it turned out at the end I could have just killed the application and restart it, since the AutoRecover feature kicked in and offered a version of the file with all changes applied.

But just to be on the save side I wanted to copy the AutoRecover files to a save location before actually killing the application. But unlike Word or Excel where the location of these files is set in the options, PowerPoint does not have such an option. After some googling I finally stumbled across a page, correctly stating that the files are stored in the %temp% folder and named ppt*.tmp. I decided to publish this info here just in case I need it again.