Saturday, 30 August 2014

How to Install Updates on Exchange Server 2010 Database Availability Groups

An Exchange Server 2010 Database Availability Group (DAG) provides several benefits to an organization, primarily that of continuous availability of mailbox databases.

To update the DAG members with new patches, update rollups or service packs, the update process should be managed to prevent all of the DAG members from being offline at the same time.

To do this you can move the active mailbox databases off a particular server so that it can be patched, and if necessary rebooted, without causing any downtime for mailbox users on that database.

This tutorial demonstrates how to update the servers in an Exchange Server 2010 Database Availability Group without causing downtime. Because this process differs depending on the version of Exchange Server 2010 you’re running I’ve covered each method here.
  • Preparing an Exchange Server 2010 RTM DAG member for updates, or
  • Preparing an Exchange Server 2010 SP1 DAG member for updates
  • Stopping Conflicting Services
  • Disabling Server Monitoring
  • Updating the Server
  • Verifying the Update
  • Returning an Exchange Server 2010 RTM DAG member to production, or
  • Returning an Exchange Server 2010 SP1 DAG member to production
For this tutorial Update Rollup 4 for Exchange Server 2010 is being installed.

Preparing an Exchange Server 2010 RTM DAG Member for Updates

The first step is to move active mailbox databases to another DAG member so that the server can be updated.
To see a list of mailbox databases and their current active server use the Get-MailboxDatabase cmdlet.
[PS] C:\>Get-MailboxDatabase

Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 02            EX1             False           Remote
Mailbox Database 01            EX2             False           Remote

In this example I want to apply updates to server EX1, and I can see that it currently hosts the active copy of Mailbox Database 02.

If your environment has a lot of DAG members and mailbox databases you can refine this query to only show active mailbox databases for a specific server.

[PS] C:\>Get-MailboxDatabase | where {$_.Server -eq "EX1"}

Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 02            EX1             False           Remote

Move the mailbox databases using the Move-ActiveMailboxDatabase cmdlet.

[PS] C:\>Move-ActiveMailboxDatabase "Mailbox Database 02" -ActivateOnServer EX2

Confirm
Are you sure you want to perform this action?
Moving mailbox database "Mailbox Database 02" from server "ex1.exchangeserverpro.local" to server
"EX2.exchangeserverpro.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
Mailbox Data... ex1             ex2             Succeeded  0                  14/09/2010... Mounted     Mounted

All of the mailbox databases are now active on server EX2.

[PS] C:\>Get-MailboxDatabase

Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 02            EX2             False           Remote
Mailbox Database 01            EX2             False           Remote

As another example, if there were multiple databases active on a server you can move all of them with a single command.

[PS] C:\>Get-MailboxDatabase | where {$_.Server -eq "EX1"} | Move-ActiveMailboxDatabase -ActivateOnServer EX2 -Confirm:$false

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
Mailbox Data... ex1             ex2             Succeeded  0                  14/09/2010... Mounted     Mounted
Mailbox Data... ex1             ex2             Succeeded  0                  14/09/2010... Mounted     Mountede

Note the use of -Confirm:$false to avoid having to confirm each move. Use this option with caution.
After moving all active mailbox databases off the server that you are planning to update, the final preparation step is to block activation on the server to prevent it from automatically reactiving a database copy while you are performing maintenance.

First check the current activation policy on the server using Get-MailboxServer.

[PS] C:\>Get-MailboxServer EX1 | fl Name,DatabaseCopyAutoActivationPolicy

Name                             : EX1
DatabaseCopyAutoActivationPolicy : Unrestricted

Next, use Set-MailboxServer to block activation.

[PS] C:\>Set-MailboxServer EX1 -DatabaseCopyAutoActivationPolicy Blocked

Preparing an Exchange Server 2010 SP1 DAG Member for Updates

For Exchange 2010 with Service Pack 1 the process is a little easier thanks to some scripts provided by Microsoft. Open the Exchange Management Shell and navigate to the scripts folder on the Exchange server.
cd $exscripts

Next run the StartDagServerMaintenance.ps1 PowerShell script.

.\StartDagServerMaintenance.ps1 -serverName ho-ex2010-mb1

The script will automatically do the following tasks for you:
  • Calls Suspend-MailboxDatabaseCopy on the database copies.
  • Pauses the node in Failover Clustering so that it can not become the Primary Active Manager.
  • Suspends database activation on each mailbox database.
  • Sets the DatabaseCopyAutoActivationPolicy to Blocked on the server.
  • Moves databases and cluster group off of the designated server.

Stopping Conflicting Services

If the mailbox server is running any Exchange-integrated services, such as antivirus software, these should be disabled prior to the update.
For example to disable Forefront use the FSUtility command.

C:\> fscutility /disable

Another example is Data Protection Manager 2010, which may be configured to perform Copy backups from passive database copies at frequent intervals through the day. Make sure these jobs are paused to prevent errors or conflicts from occuring.

Disabling Server Monitoring

If the DAG members are monitored using SCOM or a similar system then this should also be disabled or placed into maintenance mode.
This will prevent alarms from being raised as well as prevent any automatic remediation actions from being run by the monitoring agent that may cause the server updates to fail.

Updating the Server

Install the update following the deployment notes for that update type.
Update rollups come in the form of a .MSP file (Windows Installer Patch) that is applied to the server. Simply double-click the file or launch it from a command line window.
Service packs are a complete reissue of the Exchange Server setup files and are installed by running setup in upgrade mode, which can be run in either graphical or command line mode.

C:\> setup /m:upgrade

Both update rollups and service packs can take some time to install, so plan a large window of time for these updates.


Verifying the Update

After the update has completed, and if necessary the server rebooted, you should check the server’s health before placing it back into production in the CAS array.

Event Logs – look for error or warning events that have started since the update was applied.
Setup Logs – service packs write a complete setup log file to C:\ExchangeSetupLogs
Services – check the Exchange services are running (or at least those that you expect to be running, some such as IMAP and POP will be stopped if you have not explicitly enabled them)

[PS] C:\>Get-Service *exchange*

Status   Name               DisplayName
------   ----               -----------
Running  MSExchangeADTop... Microsoft Exchange Active Directory...
Running  MSExchangeIS       Microsoft Exchange Information Store
Running  MSExchangeMailb... Microsoft Exchange Mailbox Assistants
Running  MSExchangeMailS... Microsoft Exchange Mail Submission
Stopped  MSExchangeMonit... Microsoft Exchange Monitoring
Running  MSExchangeRepl     Microsoft Exchange Replication
Running  MSExchangeRPC      Microsoft Exchange RPC Client Access
Running  MSExchangeSA       Microsoft Exchange System Attendant
Running  MSExchangeSearch   Microsoft Exchange Search Indexer
Running  MSExchangeServi... Microsoft Exchange Service Host
Running  MSExchangeThrot... Microsoft Exchange Throttling
Running  MSExchangeTrans... Microsoft Exchange Transport Log Se...
Running  msftesql-Exchange  Microsoft Search  (Exchange)
Running  vmickvpexchange    Hyper-V Data Exchange Service
Stopped  wsbexchange        Microsoft Exchange Server Extension...

Returning an Exchange Server 2010 RTM DAG Member to Production

If the update was successful and the server healthy then it can be placed back into production.
Re-enable services such as Forefront Protection for Exchange.

C:\> fsutility /enable

Re-enable monitoring agents and alarms for the server.
Set the server’s activation policy back to its original setting.

[PS] C:\>Set-MailboxServer EX1 -DatabaseCopyAutoActivationPolicy Unrestricted

At this stage you might move all of the active mailbox databases to the server that was just updated so that you can update the other servers in the DAG. After all of the DAG members have been updated it is likely that mailbox databases will be active on servers that are not their first activation preference.

For Exchange Server 2010 RTM you can view the activation preferences for each database, and manually move active mailbox databases to their preferred server.

[PS] C:\>Get-MailboxDatabase | fl name,activationpreference

Name                 : Mailbox Database 02
ActivationPreference : {[EX2, 1], [EX1, 2]}

Name                 : Mailbox Database 01
ActivationPreference : {[EX1, 1], [EX2, 2]}
[PS] C:\>Move-ActiveMailboxDatabase "Mailbox Database 01" -ActivateOnServer EX1

Confirm
Are you sure you want to perform this action?
Moving mailbox database "Mailbox Database 01" from server "EX2.exchangeserverpro.local" to server
"ex1.exchangeserverpro.local".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Identity        ActiveServerAtS ActiveServerAtE Status     NumberOfLogsLost   RecoveryPoint MountStatus MountStatus
                tart            nd                                            Objective     AtMoveStart AtMoveEnd
--------        --------------- --------------- ------     ----------------   ------------- ----------- -----------
Mailbox Data... ex2             ex1             Succeeded  0                  14/09/2010... Mounted     Mounted

Returning an Exchange Server 2010 SP1 DAG Member to Production

Once again Exchange 2010 with Service Pack 1 makes this task easier thanks to a script provided by Microsoft. Open the Exchange Management Shell and navigate to the scripts folder on the Exchange server.

cd $exscripts

Next run the StopDagServerMaintenance.ps1 PowerShell script.

.\StopDagServerMaintenance.ps1 -serverName ho-ex2010-mb1

The script will automatically reverse each of the actions made by StartDagServerMaintenance.ps1 except that it will not move active mailbox databases back to the server.

To move the active mailbox databases you can continue to go to each mailbox server in the DAG and run StartDagServerMaintenance.ps1 and perform your updates. When all of the servers have been updated you can rebalance the DAG automatically using a script from Microsoft which is demonstrated here.

How to Install Updates on Exchange Server 2010 CAS Arrays

For most organizations the main benefit of deploying an Exchange Server 2010 Client Access Server array is to minimize downtime.

So when it comes time to update the CAS array members with patches, update rollups or service packs, the update process needs to be managed in a way that prevents all of the CAS array members from being offline at the same time.

Typically this means installing the updates to CAS array members one at a time, allowing each one to complete the update and (if necessary) reboot before updating the next member.

This tutorial demonstrates how to update a Client Access Server array without causing the entire array to go offline at once. For this tutorial Update Rollup 4 for Exchange Server 2010 RTM is being installed.

Preparing the NLB Cluster for Updates

The first step is to remove the server that is about to be updated from the Network Load Balancing (NLB) cluster.
There are two ways to take a CAS array member our of the NLB cluster:
  • Issue a Stop command to the server
  • Issue a Drainstop command to the server
The difference between the two is that Stop will immediately stop the server regardless of who is currently connected to it, while Drainstop will put the server in a state where it will not accept new connections but will continue serving existing connections until they disconnect.
For urgent updates a Stop command may be necessary, but for planned maintenance a Drainstop has the least potential impact on active client connections to the CAS array.

To issue a Drainstop launch Network Load Balancing Manager, right-click on the desired server, choose Control Host and then Drainstop.


When the server has no more active connections it will be in a stopped state.



Right click the server and choose Properties. Set the default state of the server to Stopped. This will prevent it from automatically starting and accepting client connections after any reboots that the updates require, to allow you time to verify the updates were successful first before rejoining the NLB cluster.


Stop Conflicting Services

The Client Access Server role is often installed on the same server as the Hub Transport server role, even when deployed as a CAS array.
Hub Transport servers often run additional applications such as antivirus and anti-spam software that hooks into the Exchange Server services. These can cause conflicts with Exchange Server updates, for example if a third party application tries to automatically restart a service that it depends on that has been stopped by the update process.
Forefront is one example of this, so for servers running Forefront Protection for Exchange those services can be stopped using FSUtility.

C:\> fscutility /disable

Disabling Monitoring

If the CAS array members are monitored using SCOM or another system this should also be disabled, or placed into maintenance mode before the update is performed. This prevents unnecessary alarms in the monitoring system due to stopped services or server restarts, and also prevents the monitoring agent from trying to perform any automatic remediation such as restarting services.

Backing Up the Server

Some organizations will require an ad-hoc backup be run of at least one CAS array member before updates are applied. Others will be happy to rely on the latest scheduled backup instead. And some will even be satisfied that multiple CAS array members exist and so if a bad update puts one of them out of action there is no outage to end users, and the server can simply be manually reinstalled.

Updating the Server

Install the update following the procedure for that update type.
Update rollups come in the form of a .MSP file (Windows Installer Patch) that is applied to the server. Simply double-click the file or launch it from a command line window.
Service packs are a complete reissue of the Exchange Server setup files and are installed by running setup in upgrade mode, which can be run in either graphical or command line mode.

C:\> setup /m:upgrade

Both update rollups and service packs can take some time to install, so plan a large window of time for these updates.

Verifying the Update

After the update has completed, and if necessary the server rebooted, you should check the server’s health before placing it back into production in the CAS array.
Event Logs – look for error or warning events that have started since the update was applied.
Setup Logs – service packs write a complete setup log file to C:\ExchangeSetupLogs
Services – check the Exchange services are running (or at least those that you expect to be running, some such as IMAP and POP will be stopped if you have not explicitly enabled them)

[PS] C:\>get-service *exchange*

Status   Name               DisplayName
------   ----               -----------
Running  MSExchangeAB       Microsoft Exchange Address Book
Running  MSExchangeADTop... Microsoft Exchange Active Directory...
Running  MSExchangeAntis... Microsoft Exchange Anti-spam Update
Running  MSExchangeEdgeSync Microsoft Exchange EdgeSync
Running  MSExchangeFBA      Microsoft Exchange Forms-Based Auth...
Running  MSExchangeFDS      Microsoft Exchange File Distribution
Stopped  MSExchangeImap4    Microsoft Exchange IMAP4
Running  MSExchangeMailb... Microsoft Exchange Mailbox Replication
Stopped  MSExchangeMonit... Microsoft Exchange Monitoring
Stopped  MSExchangePop3     Microsoft Exchange POP3
Running  MSExchangeProte... Microsoft Exchange Protected Servic...
Running  MSExchangeRPC      Microsoft Exchange RPC Client Access
Running  MSExchangeServi... Microsoft Exchange Service Host
Running  MSExchangeTrans... Microsoft Exchange Transport
Running  MSExchangeTrans... Microsoft Exchange Transport Log Se...
Stopped  msftesql-Exchange  Microsoft Search  (Exchange)
Running  vmickvpexchange    Hyper-V Data Exchange Service

Returning the Server to Production

If the update was successful and the server healthy then it can be placed back into production.
Re-enable services such as Forefront Protection for Exchange.

C:\> fscutility /enable

Start the server in the NLB cluster.


Set the NLB initial host state to Started.



And re-enable monitoring agents and alarms for the server.
After the first CAS array member has been successfully updated you can move on to the next one.

Exchange 2010 Service Pack 3 Update Rollup 6 Released

Deploying Exchange Server 2010 SP3 Update Rollup 6

The standard order of deployment for Exchange Server updates applies.
  1. Client Access servers, starting with the internet-facing ones. See this article for how to patch a CAS array. http://thiyagarajanradhakrishnan.blogspot.in/2014/08/how-to-install-updates-on-exchange_30.html
  2. Hub Transport servers
  3. Unified Messaging servers
  4. Mailbox servers. See this article for how to patch a Database Availability Group. http://thiyagarajanradhakrishnan.blogspot.in/2014/08/how-to-install-updates-on-exchange_88.html  
  5. Edge Transport servers

Thursday, 28 August 2014

Frequently asked questions about Lync Server 2010 Mobility Service

In this article, we explore five frequently asked questions about Lync Server 2010 Mobility Service. Because Mobility Service was released only ten months ago, there are still some misconceptions about the service and how to properly configure your Lync Server 2010 environment. We hope this article helps you efficiently integrate Mobility Service into your Lync Server 2010 deployment. Here are the five questions:
  • Are changes to my reverse proxy certificate required if I use CNAME records for the Lync Server 2010 Autodiscover Service?
  • Why is it necessary to define SIP listening ports for the Lync Server 2010 Mobility Service in my topology?
  • Why is an internal user forced to make an external connection to the Mobility Service?
  • Why is cookie-based affinity required for load balanced connections to Lync web services?
  • Why doesn't my presence state change when I receive a cellular call on my mobile phone?
Author: Dave Howe, Microsoft Senior Support Escalation Engineer
Publication date: August 14, 2012
Product version: Lync Server 2010

Are Changes to my Reverse Proxy Certificate Required if I use DNS CNAME Records for the Lync Server 2010 Autodiscover Service?

If you plan to use HTTPS for the initial Lync Autodiscover request from mobile clients, the answer is yes. You must add the Lync Autodiscover URL as an additional subject alternative name entry on your reverse proxy certificate.
It is a common misconception that this certificate requirement can be mitigated by using a DNS CNAME record to redirect secure Lync Autodiscover requests to a different address.
A CNAME record provides redirection for a client request, but it does not rewrite the content of the client request.
In the scenario shown in Table 1, Contoso uses a DNS CNAME record to support external Lync Autodiscover requests from mobile clients.
DNS Record TypeFully Qualified Domain NameTarget Address
CNAMElyncdiscover.contoso.comlyncweb01.contoso.com
A / HOSTlyncweb01.contoso.com65.55.12.249
Table 1. DNS CNAME record.
The Lync mobile client constructs a Lync Autodiscover request using a URL comprised of a hardcoded host name value (lyncdiscover) and the SIP domain of the user (contoso.com).
  • DNS lookup finds that lyncdiscover.contoso.com is actually a CNAME of lyncweb01.contoso.com.
  • DNS lookup finds that lyncweb01.contoso.com resolves to the IP address 65.55.12.249.
The Lync mobile client then sends a pair of Lync Autodiscover requests (http://lyncdiscover.contoso.com and https://lyncdiscover.contoso.com) to the reverse proxy at IP address 65.55.12.249.
Note: Although a CNAME record is used to redirect the request to a different address, the Lync Autodiscover URL contained in the request from the mobile client remains unchanged.
If HTTPS is used for the initial Lync Autodiscover request, the certificate offered by the reverse proxy must contain a matching FQDN value in its list of subject alternative name entries.

Why is it Necessary to Define SIP Listening Ports for the Mobility Service in my Topology?

Unlike Lync rich clients that communicate natively over SIP, Lync mobile clients communicate strictly over the HTTPS, XML, and JSON protocols.
A solution is required to bridge communication gap between the Lync mobile clients and the Lync Front End service. This solution is Microsoft Lync Server 2010 Lync Mobility Service.
After deploying Mobility Service, you will find that two new services have been added to your Lync environment.
  • The Autodiscover Service is used by internal or external mobile clients to locate various web services such as the Mobility Service.
  • The Mobility Service is used by internal or external mobile clients to sign in to a Lync Server 2010, Enterprise pool or Lync Server 2010, Standard Edition.
The Mobility Service is essentially an HTTP gateway that communicates with mobile clients over HTTPS, XML, and JSON and with the Lync Server 2010, Front End service over SIP/TLS.

Figure 1. Lync Mobility communication protocols.
To support both internal and external connections from Lync mobile clients, a new virtual directory is created for each service under the Lync Server Internal and External Web Sites in IIS see Figure 2.

Figure 2. Folder file tree showing Autodiscover and Mcx virtual directories in IIS.
The Lync Server 2010, Front End service listens for incoming requests over TCP/5061. Since this port is automatically defined in the topology, the Mobility Service can reach the Front End service.
However, the SIP listening ports for the Mobility Service are not automatically defined in the topology. As a result, the Front End service has no way of knowing how to contact the Mobility Service.
The SIP listening ports for the Mobility Service must be manually added to the topology using the Set-CSWebServer cmdlet.
  • Set-CSWebServer –McxSipPrimaryListeningPort 5086 (defines TCP/5086 as the SIP listening port for the internal Mcx virtual directory)
  • Set-CSWebServer –McxSipExternalListeningPort 5087 (defines TCP /5087 as the SIP listening port for the external Mcx virtual directory)
After defining the SIP listening ports for the Mobility Service, internal SIP communication should route successfully between the Mobility Service (Mcx Internal and Mcx External) and the Front End service as shown in Figure 3.

Figure 3. Route between Mobility Service and Front End service.

Why is an Internal User Forced to Make an External Connection to the Mobility Service?

Mobile devices commonly move between Wi-Fi and cellular networks several times throughout the course of a normal work day. Providing a consistent experience for Lync mobile users depends upon the ability to resume an existing mobility session or to establish a new mobile session from any network.
Although you can find an instance of the Mobility Service in IIS under both the internal and external Lync Server web sites, these virtual directories do not share session state information. This means that mobile users who are connected to the Lync environment from their internal Wi-Fi network are unable to resume their previous mobility session after transitioning to an external Wi-Fi or cellular network.
By forcing internally connected clients to make hair pinned connections to the external instance of the Lync Mobility Service, all requests from mobile clients are handled by a single instance of Mobility Service. This design provides a consistent session experience – regardless of whether you are connected from an internal Wi-Fi network or from an external 3G/Data/Wi-Fi network. And as long as the cookie-based affinity is correctly configured on your load balancer, your Lync mobile client should be able to resume an existing session, even though you may transition frequently between internal and external networks.

Why is a Cookie-Based Affinity Required for Load Balanced Connections to Lync Web Services?

For Enterprise pools containing more than one Lync Server 2010, Front End Server, the Mobility Service instance running on LyncFE01 is unaware of any of the existing sessions established with the Mobility instance running on LyncFE02, and vice versa. Interactions with the Mobility Service from a mobile client are often brief, however the Mobility session itself can last for days if the Lync application is frequently used. Alternatively, the Lync application can be moved to a background state on Microsoft and Apple devices, and the associated Mobility session will remain active on the server to deliver push notifications for up to 72 hours (if enabled). The longevity of a Mobility session lifetime means that a mobile client must always connect to the same Mobility instance whenever it is resumed from a backgrounded state.
Prior to the release of the cumulative update for Lync Server 2010 November 2011 (when Mobility Service was added), our guidance stated that source IP affinity should be used for connections to external Lync web services, with a garbage collection interval of 30 minutes for stale TCP sessions. While this value works great for the Lync desktop application which periodically sends out white space events to keep TCP sessions active, this affinity setting does not work very well for the Lync mobile application.
Consider the following scenario, where source IP affinity is used to load balance Mobility sessions.
9:22 A.M.Launch Lync app (new Mobility session)
9:23-9:27 A.M.Participate in IM conversation
9:28 A.M.Background Lync app (put phone in pocket)
...
11:43 A.M.Launch Lync app (resume Mobility session)
11:44 A.M.Fail to sign in (Mobility session not found)
Because the Lync mobile application does not send white space events while in a backgrounded state, the existing Mobility session is automatically garbage collected by the load balancer around 9:58am. This is the reason load balancers must be configured with cookie-based affinity for connections to external Lync web services with no session lifetime defined for automatic garbage collection. By configuring the load balancer to use cookie-based affinity for load balanced connections to external Lync web services, mobile clients should always hit the same Mobility instance when resuming an existing session (that is, as long as their Mobility session has not expired).
For more information, please see Hardware Load Balancer Requirements for Lync Server 2010.

Why Doesn't my Presence State Change when I Receive a Cellular Call on my Mobile Phone?

Basically, presence state on a mobile device is adjusted only if the Lync Server is involved in the call flow.
Figure 4 represents the simplified signaling path for a typical mobile call.
  • In this scenario, the Lync Server is not involved in the call flow.
  • When the call arrives, the Lync application is moved to the background.
  • When the call is answered, the Lync user presence state remains unchanged.
  • When the call is disconnected, the Lync application is not automatically re-launched.

Figure 4. Simplified signaling path for a mobile call without Lync Server.
Figure 5 represents the simplified signaling path for a typical Lync Mobility call.
  • In this scenario, the Lync Server is involved in the call flow.
  • When the call arrives, the Lync application is moved to the background.
  • When the call is answered, the presence state for the user is changed to In a Call.
  • When the call is disconnected, the Lync application is automatically re-launched.
  • The presence state of the user is changed back after a momentary delay.

Figure 5. Simplified signaling path for a typical Lync Mobility call.
Remember, your contacts will see only what is allowed by your relationship privacy settings.
  • Colleagues will see In a Call.
  • External Contacts (federated users) will see Busy.
There is one call scenario where your presence state can change even though you are away.
  • Your presence state is set to Away.
  • You receive an inbound Lync call or a PSTN call to your Enterprise Voice number.
  • Your cell phone begins to ring simultaneously (based on your call forwarding settings).
  • Your cell phone diverts to voice mail, which then answers the inbound call.
  • Your presence state is changed automatically to In a Call.
  • The caller decides to leave a lengthy voice mail message.
  • Ater they hang up, and the call is disconnected.
  • Your presence state changes back to Away.
We hope this article assists you to deploy Lync Server 2010 Mobility Service. We welcome your comments and questions.

FOPE vs EOP feature comparison

The following table provides a feature comparison between Forefront Online Protection for Exchange (FOPE) and Exchange Online Protection (EOP). It also provides information about new features that are scheduled to be added to the EOP service.

Feature
FOPE
EOP
Anti-spam protection


Inbound spam detection
Yes
Yes
Outbound spam detection
Yes
Yes. EOP adds the ability to configure admin notifications for suspicious outbound messages and blocked outbound messages
NDR backscatter protection
Yes
Yes
Bulk mail filtering
Yes, by following the steps described in Bulk Mail Filtering in FOPE.
Yes. EOP adds enhanced detection methods to better identify bulk email messages. Additionally, you can easily configure EOP to mark bulk email messages as spam through the user interface.
Malicious URL block lists
Yes
Yes. EOP adds two new additional URL block lists that help detect known malicious links within messages.
Anti-phishing protection
Yes
Yes. In EOP we’ve significantly improved our anti-phishing protection. FOPE included 30,000 domains of known spammers on our block lists, but EOP has been enhanced to include 750,000 domains of known spammers.



Spam management


Ability to configure connection filter IP Allow and IP Block lists
Respected for single IP addresses.
Respected for single IP addresses and CIDR IP address ranges. The service has been significantly improved to support IPV6 addresses.
Ability to configure actions on content-filtered messages
Yes
Yes and these options have been enhanced, for example you can now delete content-filtered messages or send them to the Junk Email folder.
Ability to configure advanced options for aggressive spam filtering
Yes
Yes
International spam filtering
No
Yes. you can configure EOP to block messages written in specific languages, or sent from specific countries or regions. You can configure up to 86 different languages and 250 different regions.
Manage spam via Outlook Junk Email folder
Yes
Yes
Safe sender management in Outlook
Yes
Yes
Blocked sender management in Outlook
No
Yes
False negative spam submissions via the Junk Email Reporting Add-in for Microsoft Office Outlook
Yes
Yes
False positive and false negative spam submissions via an email alias
Yes
Yes
False positive and false negative spam submissions via OWA Junk Email Reporting
No
This feature is available for Outlook Web App (OWA) customers whose Exchange Server 2013 SP1 mailboxes are being filtered by EOP. Exchange Online OWA customers will also have this functionality in the near future.
End-user spam quarantine notifications
Yes
Yes
End-user spam quarantine notification frequency
3 days by default.
Configurable from 3 to 14 days. 1 day frequency allowed if Directory Based Edge Blocking is deployed.
3 days by default.
Configurable from 1 to 15 days.
Ability to configure the language of end-user spam quarantine notifications
No
Yes
Access and manage messages in quarantine via a web page
Yes, for end users and administrators.
Yes, for end users and administrators.
Ability to search the quarantine
No
Yes
Customize content filter policies per user, group, or domain
No
Yes
View spam-quarantined message headers from the Exchange admin center
No
Yes
Support for anonymous inbound messages over IPv6
No
This feature is targeted to be added to the service in the third quarter of 2014. There will be limited availability for inbound IPv6 for the first few months, and you can only opt-in by requesting this functionality from technical support. In the future, you’ll be able to opt-in via remote PowerShell or through the Exchange admin center.
Support for validation of DKIM signed messages
No
This feature is targeted to be added to the service for IPV6 only in the third quarter of 2014. In a future release, EOP will verify all inbound messages signed with DKIM over IPv4. We will also be providing DKIM signing in the service.
Web page for looking up and delisting IP addresses from our internal Microsoft block lists
No
This feature is targeted to be added to the service in the third quarter of 2014.
Anti-malware protection


Multi-engine anti-malware protection
Yes
Yes
Option to disable malware filtering
Yes
No.
In the updated service we are enforcing anti-malware scanning for all email messages routing through the service. In the past we had separate anti-malware scanning solutions for FOPE standalone and Exchange Online customers. We believe that providing a consistent and rigorous level of protection for all of our customers is a critical part of the defense in depth strategy necessary to protect your email messaging environment. As a result, malware filtering is automatically enabled for all customers.
Malware inspection of message body
Yes
Yes
Malware inspection of attachments
Yes
Yes
Default or custom malware alert notifications
Yes
Yes
Option to remove attachment when malware is detected
No, the entire message is blocked.
Yes, administrators can select whether to block the entire message or to strip the attachment and send a customized message to the recipients.
Anti-spyware protection
Yes
Yes
Customize malware filter policies per user, group, or domain
No
Yes



Mail routing and connectors


Intelligent mail routing
Yes, using virtual domains
Yes, using criteria based routing (CBR)
Opportunistic TLS
Yes
Yes
Forced TLS
Inbound and outbound
Inbound and outbound
Inbound safe listing (skip spam filtering for trusted domains)
Yes
Yes, but for EOP we recommend that you use the connection filter IP Allow list instead.
Regional routing (restrict mail flow to a specific region)
United States
United States or Europe
Policy rules


Policy-based filtering and actions
Yes, via FOPE policy rules
Yes. Custom policies are significantly enhanced and are more flexible because they are based on Exchange Transport rules. For more information about differences between FOPE policy rules and Exchange Transport rules, see Service upgrade changes for policy rules..
Filter by domain, keyword, file name, file type, subject line, message body, sender, recipient, header, IP address
Yes
Yes
Filter by text patterns
Basic (regular expressions)
Advanced (.NET regular-expression engine)
Custom dictionaries
Yes
Exchange transport rules can include long lists of text and keywords, providing the same functionality as a custom dictionary. FOPE policy rules that include custom dictionaries will be automatically converted into transport rules as part of the transition.
Per-domain policy rules
Yes
Yes
Attachment scanning
Scans the file name and file extension, but not the attachment content.
Scans the file name, file extension, and content of the attachment.
Send policy rule notifications to sender
Yes
Yes
Send policy rule notifications to recipients
Yes
No
Send messages to fixed addresses (such as redirecting or copying a message to a specific address)
Yes
Yes
'Maximum number of recipients' match option in policy rule
Yes
No
Search policies using IP address, SMTP address, etc.
Yes
This functionality is targeted to be added to the service in the third quarter of 2014.
Ability to easily adjust rules priority across multiple rules
Yes
Yes
Administration


Web-based administration
Yes, via FOPE Admin Center
Yes, via the Exchange admin center (EAC)
Integration with Office 365 admin center
No
Yes
Language support for admin center
17 languages
EAC: 60 languages
Excel Reporting Workbook: 60 languages
Directory synchronization
Yes, via the FOPE Directory Sync Tool
Yes, via the Windows Azure Active Directory Sync Tool
Upload user files via SFTP
Yes
EOP does not support uploading a user list by using the Secure File Transfer Protocol (SFTP). However, FOPE tenants who used SFTP to upload users and manage virtual domains can use remote Windows PowerShell in EOP to upload users and add users to distribution groups. For more information, see Use remote Windows PowerShell to manage users by using FOPE SFTP files.
Directory Based Edge Blocking
Yes
Yes. For more information about configuring DBEB, see Use Directory Based Edge Blocking to Reject Messages Sent to Invalid Recipients. For additional information about how FOPE customers who use DBEB are being transitioned to EOP, see the following blog article: In Deployment: Directory Based Edge Blocking for Exchange Online Protection.
SMTP Connectivity Checker tool
Yes
Yes
For more information about using this tool, see Test mail flow with the Remote Connectivity Analyzer.
Configurable domains per tenant
600
900
Match subdomains
Yes
Yes
Remote Windows PowerShell access
No
Yes
Reporting and logging


Message trace
Yes, 30 days of message trace data
Yes, 90 days of message trace data
Subject line shown in message trace
No
Yes
Web-based reports
Yes
Yes, with improved report visualization. The mail protection reports in the Office 365 admin center provide an interactive reporting experience for admins. Summary and detail reporting data is available for 90 days.

Spam reporting
Yes
Enhanced. For example, reports are available by category.
Malware reporting
Yes
Yes
Scheduled delivery of reports via email
Yes
No, we recommend that you run interactive reports in the Office 365 admin center instead.
Detailed reporting via the Excel reporting workbook
No
Yes. The email protection reports in the Excel 2013 reporting workbook is available. However, we recommend using the enhanced Office 365 admin center reports instead. The Excel 2013 reporting workbook is planned to be deprecated in the future.
Deferral notifications (notify an administrator if an inbound message was deferred by the service)
Yes
No
Run reports for a specific domain
Yes
You cannot run Office 365 admin center reports or Excel reporting workbook reports for a specific domain. However, in the message trace you can search by sender/recipient using wildcards to limit to a specific domain.
Audit logging
Yes
Yes (administrator role group report and administrator audit log)
Service Level Agreement (SLA) and support


Spam effectiveness SLA
>99%
>99%
False positive ratio SLA
<1:250,000
<1:250,000
Virus detection and blocking SLA
100% of known viruses
100% of known viruses
Monthly uptime SLA
99.999%
99.999%
24/7 phone and web technical support
Yes
Yes
Free 90-day deployment assistance from Implementation Project Manager for customers with 1,000 seats or more
Yes
Yes
Other features


Data center mail routing by geographic region
No
Yes
Geo-redundant global network of servers
Yes
Yes
Message queuing when on-premises server cannot accept mail
Yes, 5 days
Yes, 2 days
Exchange Hosted Encryption available as an add-on service
Yes
Yes
Migrate on-premises mailboxes to Office 365 including Exchange Online
Yes
Yes, with a significantly simplified transition experience