E2K7 OWA Redirect Bug Introduced with Exchange 2010 SP1

I just deployed Exchange 2010 SP1 to an enterprise customer that has a mix of Exchange 2007 and Exchange 2010 users.  It seems that SP1 has introduced a rather aggravating and obvious bug.  Before I get into that, I'll give some background on how Exchange 2010 coexists with previous versions of Exchange.

When you have a mix of Exchange 2010 and older versions in your environment, you have to do a bit of work to make the two work together for your external users.  In a nutshell, you use Exchange 2010 Client Access Server (CAS) as your primary entry point for all external users. 

Say you use owa.company.com as your externally accessible URL.  If an Exchange 2010 user logs in from the Internet, the Exchange 2010 CAS will do its thing and the user will get a nice Outlook Web App screen.

If an Exchange 2007 user logs in using owa.company.com, the Exchange 2010 CAS will redirect the user to an externally accessible Exchange 2007 CAS using a different URL (like legacy.company.com).  The redirection is silent, but the user may notice their browser changed to legacy.company.com. 

How the redirect is handled is managed by the LegacyRedirectType setting in the Exchange 2010 OWA virtual directory.  In most cases, LegacyRedirectType is set to Silent.  To see what the setting is in your environment, run:

Get-OWAVirtualDirectory -Server <CASservername> | FL Identity, LegacyRedirectType

In SP1, this redirection is no longer silent.  When your Exchange 2007 user logs in via owa.company.com, they are presented with this screen:

The text reads:

A temporary change has occurred that requires you to connect to a different server.  To connect, click the button below.  For security reasons, you'll be asked to enter your user name and password again.

Sure enough, when you click Connect, you are redirected to legacy.company.com, where you have to re-enter your user information.

Thankfully, the same sort of thing doesn't seem to happen with Outlook Anywhere or ActiveSync clients.

I checked the LegacyRedirectType value on my 2010 SP1 CAS boxes and they are all still set to Silent.  I've read the issue occurs because the OWA virtual directory value for LegacyRedirectType is being ignored.  Apparently, this bug was to be addressed in Exchange 2010 SP1 RU1, but that wasn't the case.  Hopefully, Rollup 2 will fix the issue.

This is an extraordinarily unfortunate thing to have been introduced with SP1.   If you have a mixed Exchange 2007/2010 environment, I suggest you wait before deploying SP1.

UPDATE (01-Dec-2010):  Thanks to an anonymous commenter below, there is a workaround for the OWA redirect issue.  Navigate to C:\Program Files\Microsoft\Exchange\v14\ClientAccess\Owa (or whereever you installed Exchange) and edit the casredirect.aspx with Notepad.

Add the following line just under the existing meta-tag that starts with <meta http-equiv...:

<meta http-equiv="refresh" content="0;URL=https://legacy.domain.com/owa">

Replace legacy.domain.com with whatever you are using for your redirect URL.  Save the file and issue an IISRESET from the command line.  When your legacy users logon to OWA, they will still see the redirect page, but users will not have to press the button to continue.  It should automatically switch them to the legacy URL. 

It's not perfect, but at least its something.  Thanks again to the anonomous user who brought this to my attention!

FINAL UPDATE (14-Dec-2010): The redirect issue has finally been fixed in Exchange 2010 SP1 Rollup 2!  Read more about it here.

New September 2010 Hotfixes For OCS R2 Response Group Issue

Microsoft has released a new set of hotfixes to fix the Response Group problems introduced with the July 2010 set of hotfixes.  There are 4 required updates for the following services:

• Response Group
• Core Components
• Web Components
• Administration Tools

Get a direct link to the server hotfix installer here, which will install all the required updates.

Lync Click-to-Call in Internet Explorer

In the olden days before Lync, if you wanted to use Communicator to dial a phone number from a webpage, you had to follow a multi-step process: 

1. Select the phone number
2. Copy the phone number using Control-C or right mouse click and select Copy
3. Bring up Communicator
4. Click on the phone dialing window
5. Control-V or right mouse click and select Paste.
6. Click Dial.

Man, I'm tired just from reading that!  A feature that I've been waiting for a long time has finally made its way into Lync 2010: click-to-call from within Internet Explorer.  This has been an oft-asked for feature by several clients.  This feature was available in the past via some 3rd party add-ons, with limited success.  It's nice to see it in the base Lync client product.

When you install Lync, it will also install two IE add-ons:  Lync Browser Helper and Lync add-on, which you can see by clicking on Manage Add-ons from the IE Tools menu.  There are no configurable options.

Also from the Tools menu, you will see an option for Lync add on, which gives you a few simple options (enabled by default).

On every IE webpage you visit, Lync will determine what is a phone number using some internal normalization rules (non-viewable or editable at this time).  When a match occurs, Lync 2010 will place a small icon beside the number like this:

When you hover over the icon in a webpage, you'll see something like the following:

I've found that Lync is fairly good at determining what is a phone number and what isn't. Oddly, it doesn't seem to accept E.164 formatted phone numbers (ie. +15195551111), unless there's a space in it. Other add-ons I've tried would treat pretty much any string of numbers as a dialable number, which was irritating. 

Clicking the icon will bring up a Lync call window and Lync will automatically dial the number.

Instead of six steps, you can dial with just one click of the mouse.  An extremely useful and handy feature!

Lync 2010 and Multiple Locations with Same IP Subnet

One question users keep asking me about the Location Services in Lync 2010 is "What happens if I have the same IP addressing scheme at multiple locations?"

In my previous two posts, I talked about how Lync 2010 will keep track of the locations you've setup and will automatically set your location properly when you return.  So, what DOES happen when you leave the office, which gave you an IP address in the 192.168.20.0/24 subnet and you go home where you just so happen to use the exact same subnet? Will Lync 2010 just look at the subnet and assume that you're still in the office?

It turns out that Lync 2010 will gather as much information about your connection as it can when determining your actual location.  Not only will it use your IP address, but it will also use the identifier of the wireless access point you've connected to, or the switch ID, if connected via a hardline.

I tested this at home by connecting to two different wireless access points.  I first connected to my primary WAP and logged onto Lync 2010.  I dutifully entered my location information and set it as "Home".  I noted my IP address and disconnected.  I reconnected to my backup WAP and logged onto Lync 2010.  I had the same IP address as before.  Lo and behold, Lync asked me for my location information as if it were a new location.  I entered the same information as before, but with the location tag of "Home Test".

I then reconnected to my original WAP and sure enough, the location was set back to "Home".  I reconnected to the backup WAP, and my location changed to "Home Test".  The IP address remained the same on both WAPs, but Lync was obviously looking at more than just the IP address when determining my location.

So, Lync 2010 turns out to be very intelligent about how it determines your actual location.  It will use a combination of your IP address and any other information it can glean from the connection to ensure uniqueness.  Once you've been to most of your usual locations and set your location information once (even if those locations are not in your corporate network, you shouldn't have to ever manually set it again.

UPDATE: Jens Trier Rasmussen's blog provides some more detailed information about what exactly is used to uniquely determine your location:  http://blogs.technet.com/b/jenstr/archive/2010/09/17/how-can-lync-2010-distinguish-between-network-192-168-1-x-at-home-and-in-hotel-x.aspx

Configuring Location Services in Lync Server 2010 - Part 2

In my last post, I talked about how to configure Lync Server 2010 to allow users to enter their detailed location in Lync 2010 for use during a call to E.911 emergency services.  Today, I will talk about how to create and manage a central location database, and how to link the location information with your users.

Giving users the ability to manually input their location is important, especially when they are outside the office. However, when inside your corporate network, requiring all your users to input their specific location is an unnecessary burden, not to mention the inevitable errors that can delay emergency services.  Lync Server 2010 allows administrators to create a database of locations that map to your internal network topology. 

Location information can be set as high level as an entire internal network subnet, or can be as granular as individual switch ports.  Lync Server 2010 allows you to link locations to the following:

• IP subnet via Set-CSLISSubnet
• Wireless access point (basic service set identifier (BSSID)) via Set-CSLISWirelessAccessPoint
• Switch (either MAC or IP address) via Set-CSLISSwitch
• Switch port (switch MAC or IP address and port ID) via Set-CSLISPort

When you create a location database entry using the above Powershell commands, you can also enter all the location-specific information you have available. Hopefully, you have all the information you need in a CSV file that you can manipulate and import, saving you the tedium of manual entry. One thing to note is to make sure you DON'T publish any VPN subnets in your database. Since users who VPN in could be physically anywhere, you don't want to have their location be set to the office when they're really at home.  When a user is at home, they will have to enter their location information manually, as described in yesterday's post.

Once you've populated the location information database, you should validate it against the Master Street Address Guide (MSAG) maintained by your E911 call routing provider.  Microsoft has partnered with a few E911 routing providers in the US: 911 Enable and Intrado, with more to follow.  I understand that there will also be some E911 routing providers in Canada at some point as well.  If you don't have a E911 provider, you can skip these steps and continue on to publishing.

You setup your connection to your E911 provider using the following command:

$pwd = Read-Host –AsSecureString <password>
Set-CsLisServiceProvider -ServiceProviderName <Name> -ValidationServiceUrl <ProviderURL> -CertFileName <ProviderCert> -Password $pwd

Once setup, you can validate your addresses via the following command:

Get-CsLisCivicAddress | Test-CsLisCivicAddress –UpdateValidationStatus

You can also test addresses individually using Test-CSLisCivicAddress by itself.

Once you've validated your addresses (assuming you have a E911 provider), you have to publish the database:

Publish-CSLisConfiguration

If you successfully validated your addresses, your users' location will be automatically set when they are in a supported location (and can't be changed). 

If you are outside the US and can't validate your addresses against a MSAG provider, your users will see the following when they click on Set your Location:

The Suggested Location is populated from the Location Database information.  When a user selects the Suggested Location, they are brought to the same location information entry screen as when the user is outside a corporate network, except the address information is already populated. 

 

The user just has to type in a Location Name that is shown to other users.  The next time the user is at this location, the location will be automatically set.

For the location to be auto-populated, the civic addresses entered have to be validated against a MSAG.  If you're outside the USA, you won't be able to do this. 

An UNSUPPORTED way to gain the same auto-location setting capabilities for non-US installations is to directly edit the dbo.CivicAddresses table in your LIS database using SQL Management Tools and change the MSAGValid field from False to True on all your civic addresses.  If you're running Lync Standard Edition, install the SQL Server 2008 R2 Express Management Tools, or use SQL Management Tools from another SQL server. Keep in mind that this is UNSUPPORTED, and I can't be liable for any issues that arise. If you're unfamiliar with SQL, its best to leave things alone.

UPDATE:  The January 2011 Rollup 1 for Lync 2010 includes an update that removes the requirement for addresses to be validated against a MSAG. 

This post is meant as a basic overview of how to enable location services in Lync Server 2010.  If you want more detailed information on specific aspects of how to perform location or E911 tasks, please refer to the help documents contained with the Lync Server 2010 RC eval.

Configuring Location Services in Lync Server 2010 - Part 1

What is Lync Server 2010, you may ask?  If you haven't seen it mentioned anywhere else yet, then I guess I'm the first to let you know that CS "14" is now officially known as Microsoft Lync Server 2010.  The client is simply known as Lync 2010.  I'm not all that crazy about the name yet, but hopefully it will grow on me. If you want to try it out, the release candidate is now publically available from here.  You really should put it in a lab, but I've been running it in a limited production environment for several months now with very few issues. Its a very solid product. Now on to our regularly scheduled posting....

One important feature added to Lync Server 2010 is support for E.911.  E.911 (or Enhanced 911) is the next-generation of 911 emergency services in North America.  It provides location information for non-landline-based telephone numbers, like mobile phones and IP phones. 

The three most important things to note about E.911 is the same three things you need to worry about with real estate:  location, location, location.  Due to the inherent mobility of Lync users, it is critical that the telephony solution provide some manner of ensuring users can be automatically located in the event of a 911 emergency call. 

Lync Server 2010 provides several ways to ensure locatability (is that a word?).  The simplest method is to allow or force users to enter their location information at login to Lync.  By default, this feature is turned off in Lync Server 2010 RC, but you can enable it by typing the following command:

Set-CSLocationPolicy -Identity Global -EnhancedEmergencyServicesEnabled:$TRUE -LocationRequired:Yes

The default Location Policy is called Global, but you can create new site-level or user-level location policies if required by your deployment.

EnhancedEmergencyServicesEnabled enables the location features in Lync Server 2010. This must be set to $TRUE for anything else to work.

LocationRequired can be set to No (Don't prompt for location), Yes (prompt for location, but allow user to ignore) and Disclaimer (prompt for location and don't allow user to ignore).  If LocationRequired is set to Yes, users will see Set Your Location when they log into Lync for the first time at an unrecognized location:

If LocationRequired is set to Disclaimer, users will see the following:

If they dismiss the prompt, a message like this will pop-up:

The message can be changed by using the command Set-CsEnhancedEmergencyServiceDisclaimer.  The current documentation says that when using the Disclaimer option, users will not be able to make non-emergency calls if they ignore the prompt, but in the Release Candidate I was still able to make calls. 

When they type in a location name such as Home, a dialog box will pop up with additional address information:

To make this information available to emergency services, you have to make a few more modifications to the location policy using Set-CSLocationPolicy:

Set-CSLocationPolicy Global -EmergencyDialString "911" - EmergencyDialMask "112" -PSTNUsage "Emergency"

EmergencyDialString is the number that will be treated as being an emergency call. The call SIP data will include the user's location. This is 911 in North America.

EmergencyDialMask is an alternate number that will be converted to EmergencyDialString for the location profile. In this case, 112 (emergency dial number for many countries) would be converted to 911 and treated as an emergency call.

PSTNUsage is the Phone Usage that will be used to route the emergency call. In this example, I used "Emergency", which is a Phone Usage I created that contains a route for 911 calls. 

With this enabled, your users will be able to input their own specific location information so that emergency services can easily find them if they call 911.  The nice thing about it is that if a user goes to several locations and properly enters their address information, Lync will recognize those locations and will select it automatically the next time they are at that location. 

However, since this particular solution depends on users inputting their location information correctly, it isn't ideal for a corporate setting.  My next blog posting will detail how administrators can assign locations to users based on information stored in a central database.

Until then,
Cheers!
Ken

First Impressions - CS14 Release Candidate

I installed the release candidate of CS14 in my "lab" yesterday.  My "lab" is a single Standard Edition server in our production OCS R2 environment with a few hardy volunteers to try it out.  This release is very polished, and has several little UI improvements that go a long way to make it easier to do common things.

Everything worked just as it should with little fuss.  One thing I absolutely love is the new web client.  Its a very slick Silverlight-based app and is leaps and bounds beyond Live Meeting in terms of usability.  Now, any browser than can run Silverlight can participate in web conferences.  The web client is built in to the base front-end server install so no more dedicated CWA server required.  I've already shown this to several clients and they can't wait to put it in.

The only thing that I didn't see (and I put in a request for) was the ability to test Enterprise Telephony routes from end-to-end.  The test cases you can enter allow you to test normalization rules and routes to make sure everything routes as expected.  However, it doesn't show the effects of any trunk-level translation rules you might be using. 

For instance, my Dialing Rule Optimizer website provides end-to-end routing and trunk translation rules that will route and convert E.164 phone numbers to numbers that conform to the local PSTN dialing requirements for a given area (ie. Don't use 1 for local calls).  Ideally, the Test Cases would show you the number it will send to the next hop gateway, but it doesn't.  It shows you the normalized number and the route it will take, but it doesn't show you the effects of any trunk translation rules.  You have to look at your gateway logs to find out.  To me, this seems like a very simple addition to an otherwise very useful tool.  With any luck, it might make it into the final release if this post finds its way to the right people.

OCS R2 PBX Integration Mode User Experience

If you're familiar with OCS R2, you've probably come across the checkbox under Telephony options called "Enable PBX Integration".  You would enable this setting when you want to set someone up for Enterprise Voice, but still want the user to be able to use a deskphone.  All calls are forked to both OCS and PBX endpoints, and you can also use Communicator to control your deskphone (Remote Call Control - RCC).  This might sound like you would get the best of both worlds, combining the rich featureset of Enterprise Voice and the ability to use Communicator to control your deskphone....a wonderful union of old world and new world technology.  However, the reality is quite different. 

At first glance, it would seem that enabling a user for both Enterprise Voice (EV) and Remote Call Control/PBX Integration (RCC) would combine the best features of EV and RCC. However, in practice, this is not the case. Most EV features are not available in PBX Integration mode, as noted in the table below:

Visually, the differences between the two options are shown below. With Enterprise Voice, you can see the wealth of call control options available to a user. With PBX integration, the options are limited to the same set available with RCC only.

Again, below are the detailed call forwarding options available to Enterprise Voice users (left) and PBX Integration users (right). PBX Integration users are limited to the features available on their desk phone, while EV users have a wide range of options available.

As you can see, enabling a user for both EV and RCC reduces the featureset available to users to essentially the same as simple RCC but with the addition of using your computer as phone.  I've found that presenting the results as above usually makes decision makers change their mind about allowing their users the use of both their old deskphone and Communicator Enterprise Voice.  Ultimately, the best user experience is to use Enterprise Voice exclusively.

Warning about OCS R2 RGS and July 2010 Updates

If you've applied the July 2010 cumulative updates to your OCS R2 environment and you use the Response Group Service, you'll want to take note of this update from Microsoft:  http://support.microsoft.com/default.aspx?scid=kb;en-us;2401878&sd=rss&spid=14030

In a nutshell, if you make any changes to a response group or create a new one, calls to the affected response group could fail unless you restart the service.  This issue will be fixed in the September 2010 cumulative update package.

Thanks to RPasztor for bringing this to my attention.