Exchange

All posts tagged Exchange

 

Federation always fun as you may have read in one of my previous blogs. Starting this week we had some issues at a customer where the Free/busy lookups across environments stopped working. Not only to other Exchange environments but also Office 365.

Both the Outlook logging and event logs on the CAS provided the same error. The complete error message is displayed below:

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com failed. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException: Autodiscover failed for e-mail address <johan.veldhuis@domain.com>SMTP:johan.veldhuis@domain.com with exception System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation). —> System.Web.Services.Protocols.SoapHeaderException: An error occurred when processing the security tokens in the message.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)
   at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult asyncResult)
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3()
   at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException(ExecuteAndHandleExceptionDelegate operation)
   — End of inner exception stack trace —
. Name of the server where exception originated: EXC01. This event may occur when Availability Service cannot discover an Availability Service in the remote forest.

The bold part marks the error in this case An error occurred when processing the security tokens in the message. This error tells you there is an issue with the security token which your server has received from the Microsoft Federation Gateway. So probably this customer is not the only customer facing this issue.

Microsoft has acknowledged there were some issues earlier this week which not only affected this functionality but also some Office 365 services.

Office 365 status

Currently a work around is available to fix this issue. To fix the issue you will need to refresh the federation trust metadata. This can be done by using the following Powershell cmdlets:

Get-Federationtrust|Set-Federationtrust -Refreshmetadata

It is important to know that this cmdlet will need to be run on both sides else it may not fix the issues. Once the cmdlet have been executed it may take some time before the free/busy lookups start to work again.

Several companies have published their Exchange environment by using TMG. As you may know Microsoft has announced to discontinue the product but when working in the field you will still see that customers are using TMG.

One of the features of the Lync 2013 mobile client is to retrieve your contacts and free/busy information using Exchange Web Services (EWS). It depends on your TMG config if this will work. You may wonder why? For this we will need to have a closer look at the listener. For those who do not work much with TMG using the listener we can configure:

  • Which certificate is used to provide HTTPS
  • What kind of authentication types do we accept

So the item we need to have  closer look at is the authentication types. Using the authentication types we can configure how clients can authenticate against our Exchange environment. There are various options which you can configure for authentication amongst them:

  • HTTP form
  • Basic

Let’s assume you created one rule to publish OWA, ECP, ActiveSync, EWS and Autodiscover. In this case the listener is probably configured to offer form based authentication. Which will perfectly work for Outlook, OWA, ECP and ActiveSync. But it doesn’t work for Lync 2013 mobile clients. Normally when clients try to authenticate they will hit the form. Some clients however can’t authenticate using the form and will fall back to basic authentication. ActiveSync devices are an example of clients which work like this.

But the Lync 2013 mobile client doesn’t contain the option to fall back to basic authentication which results in authentication to fail. When you have enabled the logging on your device and examine it after trying to authenticate you will see this:

First the form will be displayed (below a small part of the code):

<em><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"></em>
<em><!-- {57A118C6-2DA9-419d-BE9A-F92B0F9A418B} --></em>
<em><html></em>
<em><head></em>
<em>    <title>Microsoft Forefront TMG</title></em>
<em>    <meta http-equiv="Content-Type" content="text/html; CHARSET=utf-8"></em>
<em>    <meta content="NOINDEX, NOFOLLOW" name="Robots"></em>
<em>    <link href="/CookieAuth.dll?GetPic?formdir=3&image=logon_style.css" type="text/css" rel="stylesheet"></em>
<em>    <script src="/CookieAuth.dll?GetPic?formdir=3&image=flogon.js" type="text/javascript"></script></em>
<em><script type="text/javascript"></em>

Followed by the following error:

2013-09-12 11:45:31.020 Lync[4120:5520] ERROR APPLICATION CEwsAutoDiscoverOperation.cpp/652:All possible ews autodiscover urls exhausted.Failing autodiscover operation

So how to solve the issue? Well the resolution is pretty simple allow basic authentication for autodiscover and EWS. This can be realized via two methods:

  • Create a new publishing rule for EWS and Autodiscover and select the option No delegation, but client may authenticate directly. Ensure the rule may be used for the All users group instead of the Authenticated users. This rule must be placed above the existing publishing rules which are used for publishing Exchange
  • Create a new web listener and new publishing rule for EWS and Autodiscover. The remark which must be made to this method is that it requires new IP-address

If you want to have more information about publishing your Exchange environment either using TMG or UAG then  good starting point is the document of Greg Taylor which contains some guidelines on how to publish your Exchange environment using TMG/UAG. This document can be found on the site below:

TechNet: Publishing Exchange Server 2010 with Forefront UAG and TMG: open

Review ScanMail Suite for Microsoft Exchange

Exchange 2013 is available for a few months now and people may start to consider to implement it either in greenfield or in their current Exchange environment. The last one is an option which became an option with the release of Exchange 2013 CU1.

A lot has changed in Exchange 2013 the server which contains the Mailbox role does all the work and the CAS does only proxying and redirection. Redirection is only used for SIP request to the UM server.

From antivirus perspective also a lot has changed. This since Microsoft has announced that it will discontinue Forefront Protection for Exchange. So what options do we have for AV then in Exchange 2013? There are two options

  • Use the build-in AV solution from Exchange 2013
  • Use a 3rd party solution which supports Exchange 2013

The first one might be an option for organizations who can live with the limited functionality. However I think most organizations will start to use 3rd party solutions.

Starting from Exchange 2013 can’t hook in on the VSAPI which was available in previous releases and was used to perform scanning.

Currently all vendors are working hard or have already released their new versions of the product which is compatible with Exchange 2013.

Among those vendors is Trend Micro, they have just release the RTM version of ScanMail™ Suite for Microsoft® Exchange™  , also known as SMEX. You may think that it took long before they released the new version for Exchange 2013 but keep in mind Exchange 2013 is totally different then Exchange 2010 as discussed earlier.

SMEX console

With SMEX 11 Trend Micro does continue to build on previous releases of the product only then available for Exchange 2013. Starting from SMEX 11 you can’t install the product anymore on Exchange 2003. This is a logical result of the support for Exchange 2003 will end in April 2014.

Just like the previous releases SMEX will give organizations the possibility to perform both transport and mailbox scanning. It does contain several scan filters which can be used to perform scanning

As this blog would be to long too describe all of the filters in detail I have out them in the table below. In this table the scan filters are listed including a short description:

Scan Filter description
Attachment Blocking Allows you to scan for attachment types and block them
Content Filtering Allows you to verify messages for specific content and block them
Data Loss Prevention Solution to scan messages for certain content to prevent the leakage of data
Spam Prevention Rules Filter which allows you to perform basic antispam filtering
Web Reputation Filter which allows you to scan content for malicious url’s

All these methods are built on the years of experience Trend Micro has in the world of antivirus for Exchange.

Web Reputation Services

Now we know which filters are available let’s have a look at some new/enhanced features of SMEX 11. From the documentation there are 3 featured where they performed a lot of work to include these in the product.

At first the web reputation service (WRS), as already described in the table this feature will check url’s to websites in messages. For each url it sends a query to check the reputation of a url. If the url has a value which passes the threshold SMEX will perform the configured action.

Queries can be either send directly to the Smart Protection Network (a Cloud based solution) or a Smart Protection Server which is located on the local network. You can limit the Smart Protection Server to prevent queries to the Smart Protection Network but this will restrict the web reputation security level to low. The reason for this is that the Smart Protection Servers cannot maintain the complete repository of the Smart Protection Network.

New functionality introduced in WRS is the integration of the Trend Micro Command & Control (C&C) Contact Alert Services. Using this services you can benefit from the Global Intelligence list. This list is compiled by Trend Micro Smart Protection Network from sources all over the world and test and evaluates the risk level of each C&C callback address. The Web Reputation security level determines the action that needs to be taken on malicious websites or C&C servers bases on the assigned risk levels. Besides the C&C service integration it is also available on other Trend layered defense such as network, endpoint and server security. It will give you a holistic review of entire organization cyber security and targeted attack visibility.

Search and Destroy

The next feature is the search and destroy feature, I think most people will know what it does. Indeed search for items and destroy them. However this is the short story.

The search and destroy functionality is only available when SMEX is installed on an Exchange 2010 SP1 or Exchange 2013 server. When looking under the hood you will find out that SMEX does use the e-discovery functionality from Exchange for this.

So before you can use the functionality you will need to ensure that the service account you are going to use for search and destroy has the required permissions. For those who are unfamiliar with Exchange, since Exchange 2010 Microsoft has implemented Role-Based Access Control (RBAC) to specify what users can do. Exchange contains a default RBAC role called Discovery Management which is attached to the security group Exchange Discovery Management. So in this case add the service account to the group and you should be able to perform search and destroy tasks.

The search and destroy functionality uses two types of accounts which must be configured in addition to the Exchange part:

  • Search & Destroy Administrators, which can search for, monitor and delete undesirable content;
  • Search & Destroy operators, which can search for and monitor undesirable content;

At least one search & destroy administrator needs to be assigned, this since “normal” administrators won’t be able to perform the search & destroy tasks unless assigned this role.

Search & Destroy

The Search & Destroy feature has the ability to create PST files before removing the content. The content in that case will be exported to PST and stored in a folder on the local server. So if performing large search & destroy operations make sure you have enough space left on the volume where you install SMEX. This option does require the Exchange Mailbox Import Export role to be assigned to the user account.

So what happens when performing a search & destroy search:

  1. User specifies the search criteria;
  2. SMEX creates a new mailbox search in Exchange;
  3. Exchange performs the mailbox search, places the result in the discovery mailbox of Exchange and returns the results to SMEX;
  4. User can view the results and either chose to directly delete the content from the mailbox or first export it to PST;

I had a look at this specific feature of SMEX for a while during a co-existence scenario where both Exchange 2010 and Exchange 2013 were implemented. If you do plan to do this make sure to discovery mailboxes exist one for each environment at least else you won’t be able to perform searches. Despite this an additional throttling policy has to be assigned to the service account. This because Exchange will limit the amount of concurrent mailbox searches to a maximum of 2 by default.

Every step which need to be configure for search & destroy is very clear documented in the PDF which is available for download from the Trend Micro website.

Deep Discovery Advisor

New in SMEX 11 is the integration with Trend’s Deep Discovery Advisor. A new product which is currently only available as hardware appliance. Using Deep Discovery Advisor you will get a sort of virtual virus doctor in your network which offers:

  • Centralized location for aggregate, manage and analyze logs;
  • Advanced visualization and investigation tool which monitors, explores and diagnoses security events on your network;
  • Custom signature and custom defense against targeted attack.

To configuration in SMEX consists of a few steps:

  1. Enable the Advanced Threat Scan Engine;
  2. Configure the pickup directory on the Exchange Server;
  3. Specify the IP address of the appliance in SMEX;

Once configured SMEX will forward content that meets the criteria configured in the AV scanning method to the Deep Discovery Advisor. The Deep Discovery Advisor will analyze the content and will report back the results back to SMEX.

While they might have waited a bit longer than expected Trend Micro did a lot of good work which resulted in a new version of SMEX with a lot of new features.  Especially the search & destroy and enhancements in WRS are a great addition to the product. So if you decide to migrate to Exchange 2013 or have a current Exchange 2007 or Exchange 2010 environment and you are looking for an antivirus product for Exchange make sure you have a look at Scanmail.

A trail version of SMEX can be downloaded via the link below:

download

Creating backups from Exchange databases is recommended just like backing up your other data. When using Netapp storage you can use the Snapmanager for Exchange to perform the backups. This product makes it possible to create a backup of a database within a few minutes.

Snapmanager does use the scheduled task from Windows for the scheduling part. Creating the backup tasks can be performed by using a wizard which is available in the Snapmanager console. When you want to do this for a few databases this is a method you can use but when you need to backup a large amount of databases it might be handy to create the backup tasks via a script.

The script is developed using Powershell and uses a XML template. The reason for this is that it is not possible to create a scheduled task via Powershell using the Windows 2003 template. Because Snapmanager for Exchange has this as s requirement so it can display the task in the NetApp console the only solution is to use a XML.

Before starting the script it may be required to modify some of the parameters in the XML:

  • author, this field can be used to change the creater of the task
  • interval, can be used to change the intervals between backups, by default every 8 hour the task is started
  • command, the command which will run, you might need to change this depending on the location where Snapmanager is installed
  • workingdirectory, here the same is applicable as for command and might need to be changed when the Snapmanager installation directory is changed

The script can be used either by specifying the parameters of by using a CSV. Below are two examples of how you can use the script:

Create_BackupSchedule.ps1 -database MBDB01 -server MBS01 -starttime 05:00AM 

Creates a scheduled task on a server called MBS01 and backups the database MBDB01 starting
at 05:00 AM.

Create_BackupSchedule.ps1 -CSV c:\script\backups.csv

Creates backup schedules on the servers using a CSV as input.

The script can be downloaded via the link below:

download

Voicemails are not delivered to the inbox

As you may already know Exchange 2010 has the option to deliver voicemails in a mailbox of a user. The SMTP protocol is used to deliver the message to the HUB server which delivers it to the mailbox server.

In case you have multiple receive connectors you might, if you have configured them incorrectly, have issues which will result in the following error:

The Unified Messaging server encountered an error while trying to process the message with header file “C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\bee89072-35bb-4e28-8f7d-733029404602.txt”. Error details: “Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. —> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

As you can see an error 500 5.3.3 occurs when the UM tries to deliver a message to the HUB  Transport server. By default the UM server will use it’s certificate to authenticate itself. One important thing here is that the receive connector will have the Exchange Server authentication option enabled. By default this will be the receive connector named client servername, for example Client EX003. This connector only accepts connections which are authenticated.

When creating a receive connector, for example for allowing applications to relay, you will need to protect it by specifying IP addresses or IP ranged. If you use the last option this may lead to strange issues. For example if the UM server has the IP address 192.168.1.25 and you will specify the 192.168.1.1/24 range as the valid remote range on the receive connector. This will result in authentication errors on the UM server because it tries to authenticate using the certificate. This because the UM server thinks it needs to authenticate using the certificate.

In case you still want to provide an IP range on the connector there is one solution: configure a seperate connector for the UM server IP address and correct authentication method.

This will cause the UM server to use this connector instead of the relay connector. The rule for receive connectors is use the most restrictive one.

ActiveSync doesn’t work for specific devices

A while ago Microsoft announced the Exchange ActiveSync Logo program. Using this program Microsoft will test the compatability of devices with ActiveSync.

One of the reasons for this is the problems which you may experience with some devices and ActiveSync. As administrator/consultant it is sometimes hard to explain why synchronization doesn’t work to an end user or customer.

At this moment the following devices are certified:

  • Windows Phone 7
  • Windows Phone 6.5
  • Nokia’s using Mail for Exchange 3.0.50
  • Nokia E7
  • Apple devices using iOS 4

When a device doesn’t meet the requirements it may cause issues. One of the issues you may experience is that a device doesn’t synchronize at all. This maybe the case after a mailbox is migrated from Exchange 2003 to Exchange 2010. This last one is an example of one of the issues I experienced myself.

To investigate this issue you will have to use the IIS logs. In the case of the Nokia devices the following could be found in the IIS logs:

2011-05-06 11:29:50 192.168.1.41 OPTIONS /Microsoft-Server-ActiveSync/default.eas User=XXXXXX&DeviceId=IMEIXXXXXXXXXXX&DeviceType=NokiaEmail&Log=V0_LdapC9_LdapL16_Mbx:
MB.DOMAIN.LOCAL_Dc:DC.DOMAIN.LOCAL_Throttle0_Budget:(A)Conn%3a0%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5F3006a3a1-0211-447a-99f5-6c0ab8e33c84%2cNorm_ 443 DOMAIN\Username 192.168.100.201 NokiaE721/2.02(0)MailforExchange+3gpp-gba 200 0 0 140

2011-05-06 11:30:11 192.168.1.41 POST /Microsoft-Server-ActiveSync/default.eas User=Username&DeviceId=IMEIXXXXXXXX&DeviceType=NokiaEmail&Cmd=Settings&Log=
V121_Ssnf:T_LdapC4_LdapL16_RpcC45_RpcL125_Ers1_Cpo19781_Fet19999_Pk0_Error:
DeviceNotProvisioned_As:BlockedP_Mbx:MB.DOMAIN.LOCAL_Dc:DC.DOMAIN.LOCAL_Throttle0_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f1%25%2cCAS%3a%24null%2f%24null%2f1%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f1%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5F3006a3a1-0211-447a-99f5-6c0ab8e33c84%2cNorm%5bResources%3a(Mdb)MBDB01(Health%3a-1%25%2cHistLoad%3a0)%2c(DC.LOCAL(Health%3a-1%25%2cHistLoad%3a0)%2c(DC)DOMAIN.LOCAL(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 DOMAIN\Username192.168.100.201 NokiaE721/2.02(0)MailforExchange+3gpp-gba 449 0 0 19999

The rules above are just two rules of the logging. In the first rule you can see that the user will authenticate and the webserver reponds with a 200. In the next step you see that something goes wrong during the provisioning process. When searching on the internet you will find out that Nokia devices are not the only devices who cause problems. Also some Andriod based devices may cause issues with ActiveSync. The problem is caused by the fact that these devices won’t work with the ActiveSync policy. Using this policy administrators can specify for example the security settings for a device.

When a user logs in via the Exchange Control Panel (ECP) en visits the Phone page he will see the device is visible their. But when getting the properties of the device the following will be displayed:

Access state:
Access Denied
Access set by: Security Policy Application

In some cases this may lead to unwanted scenarios. Most end-users will not be very happy when synchronization stops working, although the reasons for this may be a device issue.

Because it is difficult to make an inventory of which devices are active in your organization it might be wise to implement a workaround. This workaround is only needed temporarily till all devices have been upgraded to the recommended version.

The workaround for this issue is to disable the default ActiveSync policy during a migration. By default this policy will be applied to every user. To do this you will need to use the Exchange Management Shell (EMC):

Set-ActiveSyncMailboxPolicy -Identity:Default -IsDefaultPolicy:$false

When you will reconfigure the device, although this might not be necessary, you will see it works. Because this creates an unwanted situation it is recommended to solve the real issue.

Beside updating the client it might be necessary to update the firmware of the device. In case of the Nokia devices ActiveSync didn’t work after the upgrade to Mail-for-Exchange 3.0.50.

When all devices are upgraded it is recommended to enable the ActiveSync policy again:

Set-ActiveSyncMailboxPolicy -Identity:Default -IsDefaultPolicy:$true

For more information about ActiveSync policies you can visit the page below:

Technet: Understanding Exchange ActiveSync Mailbox Policies open

Open another users calender via OWA

Opening a calender from another user using OWA is not a very hard proces, when you have enough permissions you can easily open the other users calender. But what if you would like to do this via OWA?  This depends on the Exchange version you are using, let’s start with Exchange 2003:

http://ex01.company.om/exchange/johan/calender

In Exchange 2003 you can do this by specifying the url which is used to open but add the following part to the url username/calender. In this case we will open the calender of johan.

For both Exchange 2007 and 2010 you will need to use another method. This is because both the OWA from 2007 and 2010 are using web-parts to build the OWA. In Exchange 2007 and 2010 you will have the option to open another users mailbox followed by the calender, backside from using this is that you will need full mailbox access, this is not what you want in all scenario’s. To open a calender directly use the following syntax:

https://owa.company.com/owa/johan@domain.com/?cmd=contents&module=calendar

Almost the same as 2003 only the last part has changed to username@domain.com/?cmd=contents&module=calender. Besides this way there are a few other options which you can use in Exchange 2007 and 2010 to display the calendar, below an overview:

https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=dialy

or

https://owa.domain.com/owa/johan@domain.com/?cmd=contents&module=calendar&view=dialy

The above command will open the calender folder by using the f parameter which makes it possibly to open a specific folder in a mailbox.  As Michel mentioned in his comment you can also use the module parameter instead of the f parameter to perform the same action. Using the view parameter we will specify how we want to display the calender, when you don’t specify this it will be opened using the dialy view standard.The command above will do exactly the same, open the calender using the dialy view.

https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=weekly

This command will open the calender using the weekly view.

https://owa.domain.com/owa/johan@domain.com/?cmd=contents&f=calendar&view=monthly

And as last option this command will open the calender view using the monthly view. At least you may think this was the last one there is one other possibility:

https://owa.domain.com/owa/johan@domain.com/?cmd=content&f=calendar&view=daily&d=10&m=26&y=2010

This will open the calendar using the dialy view and will open it on the 26th of October 2010.

Microsoft releases security updates for Exchange

Microsoft has released security updates for Exchange 2000 SP3, Exchange 2003 SP2, Exchange 2007 SP1/SP2 and Exchange 2010. For both Exchange 2007 and 2010 this security fix is  included in a rollup. For Exchange 2007 SP1 this is the 10th rollup, for Exchange 2007 the 4th and for Exchange 2010 the 3rd.

The update applies a fix to the Windows SMTP service because of a vulnerability which was recently found. This made it possible to perform a DOS attack on the Windows SMTP service.

Below you will find the links to the patches and a link to the security bulletin which has been published about this  vulnerability.

Exchange 2000 SP3: open
Exchange 2003 SP2: open
Exchange 2007 SP1: open
Exchange 2007 SP2: open
Exchange 2010: open
Microsoft Security Bulletin MS10-024: open

Sometimes you may have the discussion if it is supported to place these files on fileserver so they can be accessed via a LAN/WAN connection. The answer for this is no, it isn’t officially supported by Microsoft. But when you will try it in your environment it will work, so what are the reasons it isn’t supported?

The PST, OST and PAB files will be accessed by a method called file-access-driven. With this method special file access commands will be offered by the OS to read and write files. For writing files to local disks this is an excellent method but when writing to a fileserver via a LAN/WAN another method is used. This method is called network-access-driven and uses specific command from the OS to send/receive data from/to other systems which are connected to the network.

But what does Outlook when a PST is located on the network? Outlook will first try to use the file-access driven commands to read/write to the file. Because the file is not on the local disk but on the network, the OS will send the network-access-driven commands to the server where the file is located.

This will cause a lot of time  for the process to be completed because of all the extra steps.

Besides the performance issues you might  get there are some other things which you should keep in mind:

  • files can get corrupted caused by network issues
  • writing- can take 4 times longer then read actions

If you want to get more information after reading this have a look at the sides below:

Ask the Performance team: Network stored PST files …. don’t do it! open
Configuring Outlook for Roaming Users open

Make OCS client available in OWA

Since Exchange 2007 it’s possible to use your OCS and Exchange together. First you had only the option to use your OCS environment with the Exchange UM server which let you use the voicemail, subscriber access and auto attendant features from Exchange in OCS

The latest addition to this is a limited OCS client integrated in OWA. This gives you the ability to send IM messages via OWA and gives you the option to see precense information.

In this tutorial I will explain how you can install this new feature.

open