Tag Archives: exchange 2010

Citrix NetScaler and Exchange: Case-sensitivity of internal and external URLs

Exchange has known the concept of internal and external URLs for the different services (Outlook Web Access, OAB, EWS, ActiveSync etc) since Exchange 2007. And it’s still confusing people. The internal URL is the URL, that is used to access the desired service from the intranet. The external URL represents the URL that is used to access the service from the internet. Best practice is to use the same URL (the external) for both, use a certificate from a public CA, and use split DNS to access the external domain from the inside of your network.

People tend to imply, that URLs are not case-sensitive. This seems to be true in most cases. The World Wide Web Consortium (W3C) states:

URLs in general are case-sensitive (with the exception of machine names). There may be URLs, or parts of URLs, where case doesn’t matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive.

Source W3C

Citrix NetScaler and URLs

Citrix NetScaler handles URLs as case-sensitive.

A frequently used concept to load balance Microsoft Exchange with a NetScaler is Content Switching. Policies are used to identify traffic, and actions are used to take action on the traffic that matches the policies. The NetScaler uses the advanced policy engine to create expressions for the Content Switching Policies. When creating a Content Switching policy by creating an expression that uses the CONTAINS operator, you might notice that the results are case-sensitive.

This can be a problem in case of Microsoft Exchange, because /Autodiscover/Autodiscover.xml and /autodiscover/autodiscover.xml, or /ews/exchange.asmx and /EWS/Exchange.asmx are handled different.


To make sure that different cases are handled, you should add  SET_TEXT_MODE(IGNORECASE)  to you policy expression. Citrix describes this in CTX115528.

I’ve changed my NetScaler setup script for Exchange to handle this behavior.

Data Protector: Exchange 2010 database recovery from copy session fails

The recovery of an Exchange mailbox using a recovery database is usually no big deal. Simply restore the database, create a recovery database and recover the mailbox or items from the mailbox. Sometimes you have the luck that the customer has licensed the Data Protector Exchange 2010 Granular Recovery for Exchange (GRE). This was unfortunately not true in my case. Okay, so let’s do it the old way. The needed tape was available in the library and luckily it was a full backup. So I quickly added a disk to the VM and started the recovery of the database to a temporary location. At this point, the disaster took its course…


This isn’t a general problem of Data Protector, it’s a bug. The following constraints met in my case:

  • Recovery source is a copy session (e.g. post-backup object copy to tape)
  • Data Protector 7.03
  • Microsoft Exchange 2010 SP2
  • Recovery to temporary location

This is the output of “omnidb -session 2014/08/01-6 -detail” for the wanted session. As you can see, this is a copy of session 2014/08/01-3, which was without protection and therefore was removed by Data Protector.

When trying to recover the DB to a temporary location, I ran into this error:

The session I tried to recover was 2014/08/01-06, the session that was chosen by Data Protector for recovery was 2014/08/01-03. To make the long story short: You can fix it with a site specific path for Data Protector 7.03. Log a call at the HP Support and ask for SSPNT700_038. Plase note that you need a valid HP Software Support contract to get this patch! The patch delivers fixes for the three defects QCCR2A51280, QCCR2A53555 and QCCR2A46724. The patch is delivered as a ZIP file and contains binaries and libraries which has to be installed on the Cell Manager and the Exchange server. The patch contains files for Windows on x64, HP-UX 11.23, 11.31 on IA64, HP-UX 11.23, 11.31 on PA RISC and Linux on x64. When running Data Protector on Windows, you have to replace the following files:

On the Exchange server


On the Data Protector Cell Manager


You have to stop the Data Protector services on the Cell Manager and the Data Protector Inet service on the Exchange server before you can replace the files. Make a backup of the files before you replace them. After the file replacement start the services and try the restore again. In my case the restore didn’t worked after applying the patch: It failed with the same error. I opened a case at HP and after a few day I got the notice, that lab engineering was involved in the case. Short after that notice, the support sent me two files (QCCR2A54842_TM1) that I had to replace on the Data Protector Cell Manager (libob2ecdb.dll & libob2ecmn.dll). Both files were part of SSPNT700_038, so you can interprete this as a patch for a patch. ;) This patch did the trick and the restore was successful. The root cause was, that a database query returns the wrong session for the recovery. So if you face the same problems, ask HP for the site-specific patch. If the problem remains, ask for QCCR2A54842_TM1.

Users on Exchange 2013 can’t open public folders or shared mailboxes on an Exchange 2007/ 2010

When moving users to Exchange 2013 it can happen, that they can’t access public folders housed on the old Exchange 2010 or 2007 server. The same can happen to shared mailboxes (mailboxes with Full Access permissions). The users are constantly prompted for credentials or they get this message:

This can be a huge problem during a migration. Microsoft described this in KB2834139. This error is caused by a misconfigured Outlook security setting, called “Logon network security”. If you experience this issue, check the “Logon network security” setting. If it’s set to “Anonymous Authentication”, then you experience the in KB2834139 described problem. Otherwise you have another problem. Check the “Logon network security” settings in your Outlook client. I took this screenshots from a Outlook 2013, but it looks the same in Outlook 2010. With this setting you will have a problem:


With one of these settings, it will work.



You can change the setting and try the access to a public folder or shared mailbox. If you can access the public folder or shared mailbox, then you have to change some settings on the Exchange Server 2013 Client Access Server (CAS).

Open an Exchange Management Shell:

I would recommend to execute “iisreset” after changing the settings. Please note, that this interrupts the client access for a short moment! After a restart of the Outlook client or during the next Autodiscover, the client should get the correct settings and the access to the public folders and shared mailboxes should work.