Block Syncing of Personal Phone Contacts in GAL through Social Connector

Twitt

I have received a question on Exchange 2013 about the syncing of personal contacts in Outlook on GAL. For example, a user that has their own personal iPhone contact were uploaded to GAL. Obviously, a lot of users don’t like that (having their personal contacts loaded into the company directory).

During the research on ‘How do I block or stop the syncing of personal contacts with Exchange 2013 so they do not show up in outlook?’ I have found as ‘Social Connectors‘ are playing the game and automatic update of contacts are enabled by default.

How to change the settings?

In Outlook 2013 Social Network Account can be seen here:

social

 

 

 

 

In Outlook 2010: Go to View-> People->Account Settings->Settings button. Change the option from ‘Update without prompting’ to ‘Prompt before update’ or ‘Never update’

In Outlook 2003 or 2007: Account Settings can found at Tools, Social Networking Account settings

The registry settings are found at the following section:

Outlook 2013

HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\SocialConnector
DWORD: RunAutomaticGALSync
Possible Values:
         0 (Never Sync)
         1 (Update without Prompt)
         2 (Prompt to sync)

Outlook 2010

HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\SocialConnector
DWORD: ScheduleContactGALSync
Possible Values:
         0 (Never Sync)
         1 (Update without Prompt)
         2 (Prompt to sync)

Bulk Operation

We were talking about individual accounts and most of the time it requires to work on multiple users and GPO is the way for that. Change the Outlook settings via GPO will help.

The GPO can be found as applied at the following section:

Outlook -> Outlook Social Connector-> Block Global Address List synchronization

HKCU\Software\Policies\Microsoft\office\outlook\socialconnector
DWORD: disablecontactgalsync
Value: 1 (no sync)
Hope this will find help you to understand and Control a Social Connctor in your organization

Rebuild the Full-Text Index Catalog of Exchange Database

Twitt

Recently, I have noticed one issue showing ‘Database Content Index State: FailedAndSuspended’. 

Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. —> Microsoft.Exchange.Search.Core.Abstraction.CatalogReseedException: The component operation has failed.
at Microsoft.Exchange.Search.Engine.SearchFeedingController.DetermineFeederState()
at Microsoft.Exchange.Search.Engine.SearchFeedingController.InternalExecutionStart()
at Microsoft.Exchange.Search.Core.Common.Executable.InternalExecutionStart(Object state)

 

ResetSearchIndex.ps1helped me to resolve the issue and I would like to describe the steps followed to help you out also.

  1. Start the Exchange Management Shell.
  2. If you want to remove the index directories that are associated with specified mailbox databases: ResetSearchIndex.ps1 [-force] <dbname> [<dbname>]
  3. If you want to remove the index directories that are associated with all mailbox databases: ResetSearchIndex.ps1 [-force] -all
  4. Stop the Microsoft Exchange Search Service by running the following command: Net Stop MsExchangeSearch
  5. Delete the full-text index catalog directory.The scripts are located in the \Exchange Server\Scripts directory. Run the following scripts:
    • GetDatabaseForSearchIndex.ps1 -  The script shows the associated mailbox database names.
      Example: GetDatabaseForSearchIndex IndexDirectoryName1 IndexDirectoryName2
    • GetSearchIndexForDatabase.ps1   – The script shows the index directories for the specified mailbox database names
      Example: GetSearchIndexForDatabase MailboxdatabaseName1 MailboxdatabaseName2 -All
      The following is an example folder name: \CatalogData-b56624f3-bf19-4463-926f-d4705ac3dd08-cc64dd2d-2428-4f12-bba2-79d6d34c4d27
      Finally, Start the Microsoft Exchange Search Service by running : Net Start MsExchangeSearch

‘Single Global Namespace Support’ in Exchange 2013

Twitt

Datacenter switchover in Exchange 2010 are operationally complex because recovery of mailbox data (DAG) and client access (namespace) are tied together there. So if you lose all or a significant portion of your CAS, or the VIP for the array, or a significant portion of your DAG, you were in a situation where you needed to do a datacenter switchover. In Exchange 2010, perhaps the biggest single point of failure in the messaging system is the FQDN that you give to users because it tells the user where to go. In the Exchange 2010 paradigm, changing where that FQDN goes isn’t easy because you have to change DNS, and then handle DNS latency, which in some parts of the world is challenging. And you have name caches in browsers that are typically about 30 minutes or more that also have to be handled.

 

In Exchange 2013, a client can receive multiple IP Addresses from DNS for a given FQDN.

 

In Exchange 2013, the namespace doesn’t need to move with the DAG. Exchange leverages fault tolerance built into the namespace through multiple IP addresses, load balancing (and if need be, the ability to take servers in and out of service).

This means the namespace is no longer a single point of failure as it was in Exchange 2010.

Since almost all client access in Exchange 2013 now relies on HTTP (Outlook, Outlook Anywhere, EAS, EWS, OWA, and EAC), if the first IP Address on a HTTP stack fails, the HTTP client will try the next and so on. If a Virtual IP of a CAS array were to fail, the client can automatically connect to other IPs to access the same service in a matter of seconds, instead of waiting minutes for DNS to failover. For Example, if a client tries one and it fails, it waits about 20 seconds and then tries the next one in the list. Thus, if you lose the VIP for the Client Access server array, recovery for the clients happens automatically, and in about 21 seconds !!!

 

Great news right?

 

If you lose your CAS array, you don’t need to perform a datacenter switchover. Clients are automatically redirected to a second datacenter that has operating Client Access servers, which remains unaffected by the outage (because you don’t do a switchover). Instead of working to recover service, the service recovers itself and you can focus on fixing the core issue

 

If you lose the load balancer in your primary site, you simply turn it off (or maybe turn off the VIP) and repair or replace it. Clients that aren’t already using the VIP in the secondary datacenter will automatically fail over to the secondary VIP without any change of namespace, and without any change in DNS. Not only does that mean you no longer have to perform a switchover, but it also means that all of the time normally associated with a datacenter switchover recovery isn’t spent.

 

Example DAG Design for Exchange 2013: Because you can fail over the namespace between datacenters, all that’s needed to achieve a datacenter failover is a mechanism for failover of the Mailbox server role across datacenters. To get automatic failover for the DAG, you simply architect a solution where the DAG is evenly split between two datacenters, and then place the witness server in a third location so that it can be arbitrated by DAG members in either datacenter, regardless of the state of the network between the datacenters that contain the DAG members.

 

How to deal with intermittent failures in Exchange 2013: An intermittent failure requires some sort of extra administrative action to be taken because it might be the result of a replacement device being put into service. In this scenario, the administrator can perform a namespace switchover by simply removing the VIP for the device being replaced from DNS. Then during that service period, no clients will be trying to connect to it. After the replacement process has completed, the administrator can add the VIP back to DNS, and clients will eventually start using it.

Lagged Mailbox Database Copy-Exchange 2013 Enhancements

Twitt

A Lagged Mailbox Database Copy is a mailbox database copy configured with a replay lag time value greater than 0. A lagged database copy is one that is not updated by replaying transactions as they become available. Instead, the transaction logs are kept for a certain period and are then replayed. The lagged database copy is therefore maintained at a certain remove to the active database and the other non-lagged database copies. If you are planning to have more than two passive database copies of a database, think about a lagged copy also as an additional protection against un predicted situations !!!

My intention through this blog post is to bring your attention to the Microsoft’s works towards the enhancement on Lagged Database Copies in Exchange 2013 when compared to earlier verions

 

Lagged copy enhancements include integration with Safety Net (Similar feature like Transport Dumpster in Exchange 2010) Activating a lagged database copy becomes significantly easier as it uses SafetyNet.

 

For example consider a lagged copy that has a 2-day replay lag. In that case, you would configure Safety Net for a period of 2 days. If you encounter a situation in which you need to use your lagged copy, simply do:

• Mount the lagged copy: This will trigger an automatic request to SafetyNet to redeliver the last two days of mail.

• You get the last two days mail, minus the data ordinarily lost on a lossy failover

 

Lagged copies can now care for themselves by invoking automatic log replay to play down the log files in certain scenarios:

• When a low disk space threshold is reached

• When the lagged copy has physical corruption and needs to be page patched

• When there are fewer than three available healthy copies (active or passive) for more than 24 hours

• Lagged copy play down behavior is disabled by default, and can be enabled by running the following command.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

• After being enabled, play down occurs when there are fewer than 3 copies. You can change the default value of 3, by modifying the following registry value :

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

• To enable play down for low disk space thresholds:

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagPlayDownPercentDiskFreeSpace