Friday, January 30, 2009
The most common request I hear is that people want to save the recording in a more available format for easier offline viewing or distribution. Well, Microsoft listened and created a tool that converts the LM recording to a WMV file.
Simply download and install it.
When you have used the normal LM Recording Manager and processed the recording start the LM Recording Converter tool and start a conversion from LM to VMW
The tool is not perfect but it does its job fairly well and should be suitable for most people.
Saturday, January 17, 2009
After some investigation I found that they used a certificate created by the internal CA, not exactly best practice but it should work.
Network monitor reveals that communicator will not even try to download the address book, it only contacts the URL and then says goodbye real quick. Well, I finally figured it out.
Certificate contains ‘Certificate Revocation List Distribution Points’ with a URL that is only reachable from the internal network. When communicator cannot reach the CRL distribution point stated in the certificate it will not go further and simply don’t download the address book.
What probably could have been done here is to make the CRL available to internet and change the path in the certificate (that means creating a new certificate). Not so simply in practice.
A simpler way is to change the client behavior not to bother with the CRL. It is not the recommended way, but it will do the job.
Change the setting in Internet Explorer advanced settings; uncheck the “Check for server certificate revocation” checkbox and you should be fine.
The best solution to this is to use a certificate from a commercial certificate authority that is trusted by most computers. With a public trusted certificate, federation and PIC/PIM can be used if there is a need.
The good side is that customer got the address book download working and they will change there own certificate for publically trusted one with reachable CRL paths and also enable federation with some of there partners.
Sunday, January 4, 2009
When you install an Exchange 2007 CAS, OWA is configured with form based authentication (FBA). This gives the end user a HTML form to fill in with username, password and also some configuration on OWA’s behavior.
The checkbox “Use Outlook Web Access Light” gives a light version of OWA with no activeX controls or other IE only features. This is of course a less feature rich version of OWA than if you use IE. Advantage is that is consumes less bytes on the wire and is therefore suitable if you are on a low bandwidth connection. OWA light is also default selected if you use a non IE and cannot be changed.
Now to the interesting part: selection between Public and private computer.
Clicking on the show explanation link doesn’t give any good clues.
This is a public or shared computer. Select this option if you use Outlook Web Access on a public computer. Be sure to log off when you have finished using Outlook Web Access and close all windows to end your session.
This is a private computer. Select this option if you are the only person who uses this computer. Your server will allow a longer period of inactivity before logging you off.
OWA with forms based authentication saves information in a cookie on the client computer. One thing that is stored in the cookie is the idle time before the user is automatically logged off. By selecting Public computer gives the user an idle period of 15 minutes before the cookie expires and the user is logged off. The timeout period for Private computer is 8 hours. CAS is using several encryption keys and cycle them every half of the time out interval so the actual timeout is between 15 to 22.5 minutes and 8 to 12 hours for private computers.
Timeout values can be changed and is configured with registry values in the following key:
Value names are “PublicTimeout” and “PrivateTimeout”, both are DWORD and numbers are in minutes.
some usefull links on the subject.
Other behavior that is dependent on the Public/Private computer selection is “File and Data Access”.
With “File and Data access” the administrator can configure what servers and file types are accessible and how users interact with files by using Allow, Block, or Force save options.This gives the administrator a very good control on how files are accessed through OWA. The good part is that all configurations regarding file access in OWA is separate for public and private computer.
This gives the administrator the ability to have different OWA behavior dependent on what user select during OWA logon. for example a user logon with public computer and tries to download a document from a file server, this is blocked by OWA, but if user logon with a private computer option selected the file is successfully downloaded to the client.
Options that can be configured are: access to windows file shares, access to sharepoint document libraries, webready document viewing, direct file access.
You can also set what file types are allowed and what types are not. Very handy and extremely useful, the only hard part is to make users select the correct option, but I guess that is up to information and education.
But what if you don’t want to use Forms Based Authentication?
There are three other standard authentication mechanisms to choose from: Basic, Windows and Digest authentication.
(Configuring Standard Authentication Methods for Outlook Web Access http://technet.microsoft.com/en-us/library/bb125207.aspx)
With Basic authentication you will always get prompted for username and password.
Once logged on, OWA treats this session as private computer regarding to attachment and data file access, but it will not use a cookie on the client to timeout the session and credentials will be cached by the browser until it’s closed or user click on the Log Off link. With the browser caching users credentials a user can use OWA and then point there browser towards another website and then hit back again and enter OWA without typing in any credentials, so it’s important to educate users about closing the browser or hit the Log Off link to secure access to there’s mailbox.
With Digest Authentication you get almost the same behavior as with basic authentication, except that OWA doesn’t know your credentials and cannot authenticate when you try to open a fileshare or a sharepoint document library. There is an exception when this work anyway and that is if you install CAS and Mailbox role on the same server.
With windows integrated authentication you get the same behavior as with Digest authentication except that if your browser is configured to use windows integrated for your CAS server website you will get automatically logged on with the same user as you’re logged on to windows with. This gives user a seamless access to OWA with typing in credentials. Windows Integrated uses the most secure authentication scheme but hopefully you’re forcing use of SSL on CAS website so this should be no problem to use other authentication than windows integrated.
So be careful when you set your authentication scheme on your CAS, more things change than you first might realize.
If you also have an ISA in front of your CAS, the possibilities and complexity raises, but that’s another story I save for later.