Quantcast
Channel: Practical 365
Viewing all 520 articles
Browse latest View live

Exchange Server 2013 High Availability: What Would You Like to Know?

$
0
0

So far the feedback from readers of Deploying and Managing Exchange Server 2013 High Availability has been positive, but there’s always more to learn about a topic as complex as high availability.

Perhaps there’s a concept you’re still unsure about. Or perhaps you have a specific scenario in mind and want to clarify how it should be approached.

Here’s your chance to get your questions answered by myself and fellow Exchange MVPs Michael Van Horenbeeck and Steve Goodman.

Simply leave your question in the comments below and we will do our best to answer as many of them as possible. At this stage we are planning to record our answers in audio, but there may be some that answered with an article here on the website.

So don’t hold back. Ask your questions below, and please provide as much detail as possible so that we can give you the best answer.


This article Exchange Server 2013 High Availability: What Would You Like to Know? is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2013 Setup Fails with Error “Couldn’t Find the Enterprise Organization Container”

$
0
0

When attempting to install Exchange Server 2013 setup may fail with an error message:

Setup encountered a problem while validating the state of Active Directory:
Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx

Reviewing the Exchange setup log (C:\ExchangeSetupLogs\ExchangeSetup.log) shows similar messages.

[11/12/2014 06:36:10.0207] [1] Failed [Rule:AdInitErrorRule] [Message:Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.]
[11/12/2014 06:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2007 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2007 servers.
[11/12/2014 06:36:10.0223] [1] [RECOMENDED] Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.
[11/12/2014 06:36:10.0223] [1] [REQUIRED] Setup encountered a problem while validating the state of Active Directory: Couldn’t find the Enterprise Organization container. See the Exchange setup log for more information on this error.
[11/12/2014 06:36:10.0223] [1] Help URL: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.AdInitErrorRule.aspx
[11/12/2014 06:36:10.0238] [1] Ending processing test-SetupPrerequisites

This problem can occur when installing Exchange Server 2013 into an Active Directory forest that previously contained an Exchange organization.

I have reproduced this error condition in a test lab environment after encountering it at a customer site:

  • An on-premises Exchange Server 2007 organization existed
  • The business migrated to Office 365
  • The on-premises Exchange server was cleanly and completely uninstalled

Under these conditions setup of Exchange Server 2013 CU6 will fail. The problem may also occur with pre-existing Exchange Server 2010 organizations, or with other builds of Exchange 2013, but I have not tested all of those scenarios.

The solution is to re-run setup for the previous version of Exchange to prepare Active Directory again. There is no need to fully install a server, simply preparing Active Directory should be enough.

For example, with Exchange Server 2007 (SP3) the following command is run:

C:\Admin\Ex2007sp3> setup /preparead /on:”First Organization”

(The /on: switch is short for /OrganizatioName, and “First Organization” is the name I gave my organization.)

Let’s walk through the scenario in more detail. An Exchange Server 2007 organization exists, with the usual containers visible in ADSIEdit.

exchange-2013-setup-fails-01

Exchange 2007 is cleanly removed from the environment.

exchange-2013-setup-fails-03

After removal, the Microsoft Exchange System Objects container is still visible in Active Directory Users & Computers (select View -> Advanced Features to see it), with the Exchange Install Domain Servers group still present.

exchange-2013-setup-fails-04

The Microsoft Exchange Security Groups container is also still visible in Active Directory Users & Computers, with the Exchange Trusted Subsystem group the only group left behind (all other groups normally seen here have been removed by the uninstall process).

exchange-2013-setup-fails-05

The organization is no longer visible in ADSIEdit.

exchange-2013-setup-fails-06

The simplest execution of Exchange Server 2013 setup is to prepare the schema. The command line is:

C:\Admin\ex2013cu6> setup /prepareschema /IacceptExchangeServerLicenseTerms

This fails with the error message.

exchange-2013-setup-fails-07

If you search the internet for information on this error “Couldn’t find the Enterprise Organization container” you will encounter some advice about manually deleting certain containers and objects from Active Directory. In my testing none of these actions helps to resolve the issue, and in some cases make things worse.

However, re-running Exchange 2007 (SP3) setup as mentioned earlier to prepare Active Directory resolves the issue and allows Exchange Server 2013 setup to proceed as normal.


This article Exchange Server 2013 Setup Fails with Error “Couldn’t Find the Enterprise Organization Container” is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Hybrid Mailbox Move Fails with Mismatched Archive GUID Error

$
0
0

While performing a remote mailbox move to off-board a user from Office 365 to Exchange Server 2013 on-premises you may encounter an error due to a mismatched archive GUID.

Error: MigrationPermanentException: Recipient ‎’office365bootcamp.net/Staff/People/DirSync/Alan.Reid‎’ has mismatched archive GUID ‎(00000000-0000-0000-0000-000000000000)‎. Expected value: 77d97d5b-8f61-4fd4-b355-1463525a068f.

In this example a Hybrid configuration has been established and the user Alan Reid is being migrated to the on-premises Exchange 2013 server. Alan is archive-enabled in Office 365.

Using PowerShell connected to Exchange Online and looking at the properties of the cloud mailbox the archive GUID is visible:

PS C:\> get-mailbox alan.reid | fl *archiveguid*
ArchiveGuid         : 77d97d5b-8f61-4fd4-b355-1463525a068f

For the on-premises object the archive GUID does not match.

[PS] C:\>Get-RemoteMailbox alan.reid | fl *archiveguid*
ArchiveGuid         : 00000000-0000-0000-0000-000000000000

To resolve the issue and allow Alan’s mailboxes to be moved we can set the on-premises archive GUID to the expected value so that they match.

[PS] C:\>Set-RemoteMailbox alan.reid -ArchiveGuid "77d97d5b-8f61-4fd4-b355-1463525a068f"

Resume the migration batch and it should now proceed without the archive GUID error.


This article Hybrid Mailbox Move Fails with Mismatched Archive GUID Error is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

New Updates Released for Exchange Server 2013, 2010 and 2007

$
0
0

The Microsoft Exchange Team has announced new update releases for all current versions of Exchange Server. The updates include:

Also included are UM Language Packs for Exchange 2013 CU7.

Important Security Update MS14-075

Included in these update releases is the fix for MS14-075 which resolves four vulnerabilities relating to Outlook Web App, the worst of which could allow elevation of privilege.

The fix is included with Exchange 2010 SP3 UR8 and Exchange 2007 SP3 UR15, and is available as a standalone security update for Exchange 2013 SP1 and Exchange 2013 CU6.

The fix is not provided for any other versions of Exchange Server which may be vulnerable, as they are unsupported.

Improvements in Exchange Server 2013 Cumulative Update 7

Microsoft calls out the following improvements in CU7 for Exchange 2013:

Exchange Server 2013 Cumulative Update 7 includes updates which make migrating to Exchange Server 2013 easier. These include:

  • Support for Public Folder Hierarchies in Exchange Server 2013 which contain 250,000 public folders
  • Improved support for OAB distribution in large Exchange Server 2013 environments

Customers with Public Folders deployed in an environment where multiple Exchange versions co-exist will want to read Brian Day’s post for additional information.

Improvements in Backup for Exchange Server 2013

CU7 also included a minor improvement (what we might also consider a bug fix) in the area of backup. In Microsoft’s words:

We encourage all customers who backup their Exchange databases to upgrade to Cumulative Update 7 as soon as possible and complete a full backup once the upgrade has been completed. These improvements remove potential challenges restoring a previously backed up database.

This sounds a bit scary (nobody wants to hear that their backups may be unusable for restores) but Microsoft assures us that the condition they are referring to is an edge case only, identified in internal testing, and has not been known to impact production customers.

Obviously you should still follow their advice and take a full backup after your CU7 deployment.

Deploying the Latest Exchange Server Updates

For Exchange Server 2013:

For Exchange Server 2010:

Recommendations and Known Issues

I frequently receive questions about whether to wait or deploy when new updates are released. My general rule is to wait two weeks to allow time for testing and reviewing any other real world feedback from others, unless circumstances require an urgent deployment (eg for critical security or bug fixes).

  • Exchange Server 2013 environments – too early to tell. Important security update should be reviewed. Backup issue should be taken seriously if no restore tests have been performed in your environment previously.
  • Exchange Server 2013/Office 365 Hybrid – too early to tell. Refer to notes above for Exchange 2013 concerns. Office 365 Hybrid customers are required to deploy the most current CU release on-premises.
  • Exchange Server 2010 environments – Currently withdrawn from the Download Center due to an issue with the update causing Outlook connectivity problems.
  • Exchange Server 2007 environments – too early to tell. Important security update should be reviewed. Recent update quality has been good. Test and deploy.

This article New Updates Released for Exchange Server 2013, 2010 and 2007 is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Completing Individual Move Requests from a Migration Batch

$
0
0

Mark left a comment asking whether he could complete the mailbox moves for only specific mailboxes that were included in a very large migration batch.

Consider a scenario in which you create a migration batch, but some circumstance leads to you wanting to be more selective in which mailbox moves within that batch are completed, instead of initiating the completion for the entire batch.

Although the migration batch is a single object that you can manage, each mailbox move in that batch is still handled as an individual move request.

For example, here is a migration batch with five mailboxes included. I can see all five move requests when I run Get-MoveRequest.

[PS] C:\>Get-MigrationBatch
Identity                        Status                    Type                           TotalCount
--------                        ------                    ----                           ----------
Migration Batch 10              Syncing                   ExchangeLocalMove              5
[PS] C:\>Get-MoveRequest
DisplayName                                    Status                    TargetDatabase
-----------                                    ------                    --------------
Alison Pugh                                    InProgress                DB03
Annette O'sullivan                             InProgress                DB03
Alannah Shaw                                   InProgress                DB03
Chrissie Varney                                InProgress                DB03
Carol Okyere                                   InProgress                DB01

When the migration batch reaches a suspended state (because I did not choose to automatically complete it), I can use Set-MoveRequest to set the SuspendWhenReadytoComplete flag on one of the move requests to $false, then resume only that move request.

The reason for setting SuspendWhenReadytoComplete to $false is to ensure that the move request does not auto-suspend again when you actually want it to complete.

[PS] C:\>Get-MoveRequest "Alannah Shaw" | Set-MoveRequest -SuspendWhenReadyToComplete:$false
[PS] C:\>Get-MoveRequest "Alannah Shaw" | Resume-MoveRequest
[PS] C:\>Get-MoveRequest
DisplayName                                    Status                    TargetDatabase
-----------                                    ------                    --------------
Alannah Shaw                                   InProgress                DB03
Alison Pugh                                    AutoSuspended             DB03
Annette O'sullivan                             AutoSuspended             DB03
Chrissie Varney                                AutoSuspended             DB03
Carol Okyere                                   AutoSuspended             DB01

That move request will complete, while the others remain suspended.

[PS] C:\>Get-MoveRequest
DisplayName                                    Status                    TargetDatabase
-----------                                    ------                    --------------
Alison Pugh                                    AutoSuspended             DB03
Annette O'sullivan                             AutoSuspended             DB03
Chrissie Varney                                AutoSuspended             DB03
Carol Okyere                                   AutoSuspended             DB01
Alannah Shaw                                   Completed                 DB03

That can be repeated as many times as necessary to get the desired result. Or I can simply complete the entire migration batch.

[PS] C:\>Get-MigrationBatch "Migration Batch 10" | Complete-MigrationBatch
Confirm
Are you sure you want to perform this action?
Complete migration batch "Migration Batch 10"?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

The remaining move requests will then complete as expected.

[PS] C:\>Get-MoveRequest
DisplayName                                    Status                    TargetDatabase
-----------                                    ------                    --------------
Alison Pugh                                    Completed                 DB03
Annette O'sullivan                             Completed                 DB03
Alannah Shaw                                   Completed                 DB03
Chrissie Varney                                Completed                 DB03
Carol Okyere                                   Completed                 DB01
[PS] C:\>Get-MigrationBatch "Migration Batch 10"
Identity                        Status                    Type                           TotalCount
--------                        ------                    ----                           ----------
Migration Batch 10              Completed                 ExchangeLocalMove              5

This article Completing Individual Move Requests from a Migration Batch is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2013 High Availability Q&A Recording Now Available

$
0
0

This week I got together on a Lync call with my fellow Exchange Server MVPs Michael Van Horenbeeck and Steve Goodman and we recorded a Q&A session about Exchange Server 2013 high availability. The questions came from readers of Exchange Server Pro and the Deploying and Managing Exchange Server 2013 High Availability ebook.

In this recording we cover:

  • Site resilience and datacenter switchovers
  • Azure file share witness
  • Multi-site/Geo load balancing
  • Lagged database copies
  • Dynamic quorum

You can download or listen to the recording on Soundcloud.

You can also download the MP3 file here if Soundcloud download is not available.


This article Exchange Server 2013 High Availability Q&A Recording Now Available is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

How to Remove an SSL Certificate from Exchange Server 2013

$
0
0

Victor asks:

I assigned a new SSL cert to the SMTP service on my Exchange 2013 server and got the prompt about overwriting the old one. However, the old cert is still bound to the SMTP service and I can’t uncheck the box. Do I need to reboot the server or can I just restart the SMTP service to unbind it?

Certificates bound to SMTP are a little different than other services on an Exchange server. If you bind a certificate to IIS for example, it removes the binding for any previous certificate, and becomes the only certificate bound to that service. However with SMTP you can have multiple SSL certificates bound to the service.

Here’s an example:

[PS] C:\>Get-ExchangeCertificate | select thumbprint,services,notafter,subject,certificatedomains | where {$_.Services -
match "SMTP"} | fl
Thumbprint         : 21D75A8C5BA4003005DF16D5EF577DE4563114D1
Services           : IMAP, POP, IIS, SMTP
NotAfter           : 10/08/2015 10:00:00 PM
Subject            : CN=mail.exchangeserverpro.net, OU=IT Department, O=LockLAN Systems Pty Ltd, L=Hemmant, S=Qld, C=AU
CertificateDomains : {mail.exchangeserverpro.net, AutoDiscover.exchangeserverpro.net, exchangeserverpro.net,
                     smtp.exchangeserverpro.net, pop.exchangeserverpro.net, imap.exchangeserverpro.net}
Thumbprint         : E769A3DB29AA4EA612B2C27D78CE01EBDB1C7005
Services           : SMTP
NotAfter           : 11/06/2019 7:40:13 PM
Subject            : CN=EX2013SRV1
CertificateDomains : {EX2013SRV1, EX2013SRV1.exchangeserverpro.net}
Thumbprint         : 5C5E9124B0960BBFB570596AAE6902742D95361E
Services           : SMTP
NotAfter           : 27/05/2019 10:05:25 PM
Subject            : CN=EX2013SRV1
CertificateDomains : {EX2013SRV1, EX2013SRV1.exchangeserverpro.net}

As you can see I’ve got my SAN certificate bound to IMAP, POP, IIS, and SMTP. But then I’ve also got two additional certificates bound to SMTP. These are self-signed certificates created by Exchange setup.

Why do I have two? It’s possible I’ve reinstalled this server at some stage, or manually created one of them. Regardless, you can see that multiple certificates are bound to SMTP, which is the point I’m making.

Anyway, let’s say for some reason we want to remove one of those self-signed certificates, or at the very least unbind it from SMTP. To bind a certificate to a service we use Enable-ExchangeCertificate, however there is no corresponding Disable-ExchangeCertificate cmdlet.

As Victor points out, trying to do it via the Exchange Admin Center is impossible – the tick box is greyed out.

However we still have a PowerShell solution to the problem. If you look closely at the documentation for Enable-ExchangeCertificate you can see that the -Services parameter accepts a value of “None”.

So this command will set the certificate with a thumbprint of “5C5E9124B0960BBFB570596AAE6902742D95361E” to be bound to no services on the server.

[PS] C:\>Enable-ExchangeCertificate -Services $null -Thumbprint 5C5E9124B0960BBFB570596AAE6902742D95361E

If you want to remove the certificate from the server entirely use Remove-ExchangeCertificate. However, don’t do this until you’re 100% sure you don’t need the certificate any more. I have seen customers who delete a certificate only to later realise that the server was still using that certificate for something.

[PS] C:\>Remove-ExchangeCertificate -Thumbprint 5C5E9124B0960BBFB570596AAE6902742D95361E
Confirm
Are you sure you want to perform this action?
Remove certificate with thumbprint 5C5E9124B0960BBFB570596AAE6902742D95361E from the computer's certificate store?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

This article How to Remove an SSL Certificate from Exchange Server 2013 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

PowerShell Script to Remove Mailbox Folder Permissions

$
0
0

In a previous article I demonstrated how to use a PowerShell script to grant read-only permissions to an Exchange mailbox. The script achieves this by granting the “Reviewer” permission to each folder within the mailbox. In fact, it can be used to grant any mailbox folder permission or role (eg Owner, Editor, Contributor), not just read-only, and I have just made a minor update to the script to handle errors better.

One of the most common requests from people who use that script is how to *remove* permissions from mailbox folders.

Fortunately this is an easy task with just a few modifications to the original script. Naturally just as there is an Add-MailboxFolderPermission cmdlet for Exchange Server, there is also a Remove-MailboxFolderPermission cmdlet.

So we can use the same approach of traversing the mailbox folder hierarchy, checking for the user in question, and removing the permissions.

Here is a sample from the script that shows how this is performed:

$mailboxfolders = @(Get-MailboxFolderStatistics $Mailbox | Where {!($exclusions -icontains $_.FolderPath)} | Select FolderPath)
foreach ($mailboxfolder in $mailboxfolders)
{
    $folder = $mailboxfolder.FolderPath.Replace("/","\")
    if ($folder -match "Top of Information Store")
    {
       $folder = $folder.Replace(“\Top of Information Store”,”\”)
    }
    $identity = "$($mailbox):$folder"
    Write-Host "Checking $identity for permissions for user $user"
    if (Get-MailboxFolderPermission -Identity $identity -User $user -ErrorAction SilentlyContinue)
    {
        try
        {
            Remove-MailboxFolderPermission -Identity $identity -User $User -Confirm:$false -ErrorAction STOP
            Write-Host -ForegroundColor Green "Removed!"
        }
        catch
        {
            Write-Warning $_.Exception.Message
        }
    }
}

You can download the complete Remove-MailboxFolderPermissions.ps1 script from Github here.

And here is an example of the script in action, removing permissions for the user “Alan Reid” from the mailbox of “Alex Heyne”.

[PS] C:\Scripts\MailboxFolderPermissions>.\Remove-MailboxFolderPermissions.ps1 -Mailbox alex.heyne -user alan.reid
Checking alex.heyne:\ for permissions for user alan.reid
Removed!
Checking alex.heyne:\Calendar for permissions for user alan.reid
Removed!
Checking alex.heyne:\Contacts for permissions for user alan.reid
Removed!
Checking alex.heyne:\Contacts\{06967759-274D-40B2-A3EB-D7F9E73727D7} for permissions for user alan.reid
Removed!
Checking alex.heyne:\Contacts\GAL Contacts for permissions for user alan.reid
Removed!
Checking alex.heyne:\Contacts\Recipient Cache for permissions for user alan.reid
Removed!
Checking alex.heyne:\Conversation Action Settings for permissions for user alan.reid
Removed!
Checking alex.heyne:\Deleted Items for permissions for user alan.reid
Removed!
Checking alex.heyne:\Drafts for permissions for user alan.reid
Removed!
Checking alex.heyne:\Inbox for permissions for user alan.reid
Removed!
Checking alex.heyne:\Inbox\Customers for permissions for user alan.reid
Removed!
Checking alex.heyne:\Inbox\Marketing Reports for permissions for user alan.reid
Removed!
Checking alex.heyne:\Inbox\Team Matters for permissions for user alan.reid
Removed!
Checking alex.heyne:\Journal for permissions for user alan.reid
Removed!
Checking alex.heyne:\Junk E-Mail for permissions for user alan.reid
Removed!
Checking alex.heyne:\News Feed for permissions for user alan.reid
Removed!
Checking alex.heyne:\Notes for permissions for user alan.reid
Removed!
Checking alex.heyne:\Outbox for permissions for user alan.reid
Removed!
Checking alex.heyne:\Quick Step Settings for permissions for user alan.reid
Removed!
Checking alex.heyne:\RSS Feeds for permissions for user alan.reid
Removed!
Checking alex.heyne:\Sent Items for permissions for user alan.reid
Removed!
Checking alex.heyne:\Suggested Contacts for permissions for user alan.reid
Removed!
Checking alex.heyne:\Tasks for permissions for user alan.reid
Removed!
Checking alex.heyne:\Working Set for permissions for user alan.reid
Removed!
Checking alex.heyne:\Calendar Logging for permissions for user alan.reid

This article PowerShell Script to Remove Mailbox Folder Permissions is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Office 365 Exchange Online Message Size Onboarding Limit Increased to 150mb

$
0
0

Included in the latest round of Office 365 announcements is details of the new Exchange Online message size limit for onboarding (mailbox migrations). Previously the limit was 25mb (attachment size) + overheads, which roughly came out to 35mb total message size.

We are making a change to allow customers to migrate larger mail messages to Exchange Online. We now allow messages up to 150MB to be migrated to the service. The change is available immediately to all customers and is published as a new limit in the Exchange Online limits page in the Office 365 service description. We are not changing other limits such as mailbox size or maximum send/receive limit for messages.

I confirmed with Microsoft that this also applies to offboarding mailbox moves as well, which is good news for customers who have had to skip (and therefore lose) oversized messages when offboarding a mailbox.

You may be wondering how a message that exceeds the previous service limits could possibly exist in an Exchange Online mailbox. That is indeed a good question.

Anyway, enjoy your new message size limits when migrating mailboxes in and out of Office 365 :)


This article Office 365 Exchange Online Message Size Onboarding Limit Increased to 150mb is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

How to Permanently Remove Deleted Users from Office 365

$
0
0

When you delete a user from the Office 365 control panel they are moved into a recycle bin for 30 days so that they can be recovered easily if the deletion was not intended.

However, if you want to permanently remove a deleted user in Office 365 you can use PowerShell. For this task you will need the Azure Active Directory for PowerShell module installed on your computer.

First, connect to your Azure Active Directory by running Connect-MsolService and entering your admin credentials in the dialog box that appears.

Caution: do not proceed unless you are completely sure that you want to permanently remove the users.

PS C:\Scripts> Connect-MsolService

To see a list of the deleted users run Get-MsolUser with the -ReturnDeletedUsers switch.

PS C:\Scripts> Get-MsolUser -ReturnDeletedUsers

office-365-remove-deleted-users

You can remove a specific deleted user with Remove-MsolUser and the -RemoveFromRecycleBin switch.

PS C:\Scripts> Remove-MsolUser -UserPrincipalName Lynn@office365bootcamp.com -RemoveFromRecycleBin
Confirm
Continue with this operation?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

To remove all deleted users you can pipe the Get-MsolUser output to Remove-MsolUser and add the -Force switch to avoid being prompted for each removal.

Caution: be very careful here not to accidentally delete all users from your Azure Active Directory.

PS C:\Scripts> Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force

This article How to Permanently Remove Deleted Users from Office 365 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Office 365 ProvisioningFailedException: Failed to Update One of the Recipient Properties

$
0
0

During an Office 365 migration (cutover migration in this case) you may encounter an error message on one or more of the users that is automatically provisioned for you in the cloud:

ProvisioningFailedException: Failed to update one of the recipient properties.

office365-failed-to-update-recipient-properties

Unfortunately the error message and report give no further details about exactly which recipient property failed to update. And some searches online also turned up no specific information about this error.

However, on inspection of the properties of the failed users I noticed that they had some issues. For example, the list of send on behalf permissions for the mailbox included disabled user accounts for people who were no longer working for the company. In other cases it was the Manager field that contained an invalid user.

After clearing up these invalid entries I was then able to stop and restart the migration batch, and the users were provisioned successfully on the next attempt.


This article Office 365 ProvisioningFailedException: Failed to Update One of the Recipient Properties is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Exchange Server 2010 Reaches the End of Mainstream Support

$
0
0

This week, 13th January 2015 to be precise, marks the end of mainstream support for Exchange Server 2010. The product now enters the extended support phase, which will end in January 2020.

What does this mean for customers? The best explanation of mainstream vs extended support comes from Microsoft’s own Support Lifecycle FAQ page.

exchange-2010-support-lifecycle

As you can see Microsoft will still provide security updates for Exchange Server 2010 (as long as you’re on the supported service pack level, which is Service Pack 3), however they will no longer be providing non-security updates (without an Extended Hotfix Support contract), and there is limited complimentary (free) technical support provided.

So for now you are still supported from a security perspective, and can still access paid technical support if you need it. Information in TechNet, knowledge bases, forums, and of course throughout the community on blogs and other platforms will continue to be available to you. And by now you would imagine that most questions are answered somewhere, although there can always be new problems or use cases appear that haven’t been answered yet.

I know there are customers currently deploying new Exchange Server 2010 environments today. Some are doing it because they have no other option, for example they are still migrating off Exchange Server 2003. Others are doing it because they feel more comfortable with Exchange 2010 than with newer options.

Customers who are concerned about being in extended support can look to migrate from Exchange 2010 to Exchange Server 2013 or Office 365. Both are high quality, stable platforms these days and worth considering.


This article Exchange Server 2010 Reaches the End of Mainstream Support is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Amazon Enters the Cloud Email Race with WorkMail

$
0
0

workmail_logoInteresting news out of Amazon Web Services (AWS) this week with the announcement of WorkMail, Amazon’s cloud email service for businesses.

On-premises email has many players competing but the cloud is mostly a two horse race between Microsoft Office 365 and Google Apps for Business. A big player like AWS entering the race is something to pay attention to.

Looking at the details of the announcement is seems that AWS is ticking most of the important boxes:

  • Location control – choose the AWS region where you want your WorkMail hosted. Currently this is limited to the US East and Ireland regions, but you could expect this to expand quickly. The physical location of cloud services is a big concern for a lot of businesses, and providers are taking it seriously as we’ve seen recently with Microsoft opening more and more regional datacenters such as the Australian Azure and Office 365 locations.
  • Encryption – S/MIME support, TLS for encryption in transit, and encryption at rest using the AWS Key Management Service or bring your own key. In comparison, Office 365 also covers these requirements.
  • Antivirus/Antispam – you would not be able to run a cloud-hosted email service without this, but it remains to be seen how effective and adaptable Amazon’s protection is.
  • Mobile Device Management – the basic policy items such as password strength, device encryption are there, as well as remote wipe. But the MDM landscape is moving on quickly in the BYOD world, with Microsoft baking in many more advanced MDM features directly into Office 365.
  • Directory Integration – AWS can host a cloud-only WorkMail for you or integrate with an existing Active Directory.
  • Client Support – WorkMail supports Outlook and a variety of modern web browsers and mobile devices.

A migration tool is also being made available. Migrating existing mailbox contents is a major hurdle to onboarding with any email platform, so this is an area that Amazon will need to get right if they want to win existing customers from other services.

The pricing is competitive at $4 per user per month that includes 50Gb of mailbox storage or $6 per user per month that also includes 200Gb of WorkDocs storage.

Without having fully explored the WorkMail service my initial opinion is that Office 365 offers better value and a better user experience to many businesses and enterprises due to the inclusion of the Office applications suite and a lot more features built in to the service itself (such as Lync Online, larger storage allowances in OneDrive, collaboration features such as Groups).

However, I would not dismiss WorkMail at this early stage. Aside from the fact that it comes from a powerful player like Amazon Web Services it’s important to realise that WorkMail is not just an email service that stands on its own. Instead, it integrates with a wide range of other established AWS services such as WorkDocs, IAM, KMS, Directory Service, and SES.

I could certainly foresee new startups who are not Microsoft-centric, and who are already moving into the AWS ecosystem for their compute and storage needs, strongly considering going “all in” and using WorkMail as well, instead of Office 365 or Google Apps. However, with the pace of innovation that is occurring in Office 365 Amazon will need to move fast to stay in the race.


This article Amazon Enters the Cloud Email Race with WorkMail is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

How to Block or Quarantine the Outlook for iOS and Android App in Exchange Server and Office 365

$
0
0

Microsoft has released the Outlook for iOS and Android app, which is intended to replace the OWA for Devices mobile client on Apple iOS and Google Android smartphones and tablets.

The Outlook for iOS and Android app is essentially another ActiveSync client for connecting mobile devices to Exchange and Office 365. It also supports other mail services like Outlook.com.

For some organizations there are a number of security and compliance concerns with the way the new Outlook for iOS and Android app functions that will mean those organizations will want to block or quarantine the app from connecting to their Exchange or Office 365 mailboxes until it can be further evaluated.

You can read more about the new app and some of the technical concerns people have with it here:

In the meantime, here’s how to block or quarantine Outlook for iOS and Android app. First let’s look at how it appears as a mobile device association in Exchange.

[PS] C:\>Get-MobileDevice -Mailbox alex.heyne | fl FriendlName,Device*,Client*,Is*
FriendlyName            : Outlook for iOS and Android
DeviceId                : 94B42B2A37D109AE
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : Outlook for iOS and Android 1.0
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS-Android/1.0
DeviceModel             : Outlook for iOS and Android
DeviceAccessState       : Allowed
DeviceAccessStateReason : Global
DeviceAccessControlRule :
ClientVersion           : 14.1
ClientType              : EAS
IsManaged               : False
IsCompliant             : False
IsDisabled              : False

For Exchange Server 2010 use Get-ActiveSyncDevice instead of Get-MobileDevice.

ActiveSync device access rules can be based on a few different device criteria. From the information above it looks like the DeviceModel will be the simplest approach here, as others such as UserAgent may change with later versions of the Outlook for iOS and Android app.

To block the Outlook for iOS and Android app in Office 365, Exchange Server 2010 or 2013:

[PS] C:\>New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

To quarantine instead:

[PS] C:\>New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Quarantine

Devices should now appear as blocked or quarantined with the reason of “DeviceRule”.

[PS] C:\>Get-MobileDevice -Mailbox alex.heyne | fl FriendlName,Device*,Client*,Is*
DeviceId                : 94B42B2A37D109AE
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : Outlook for iOS and Android 1.0
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS-Android/1.0
DeviceModel             : Outlook for iOS and Android
DeviceAccessState       : Blocked
DeviceAccessStateReason : DeviceRule
DeviceAccessControlRule : Outlook for iOS and Android (DeviceModel)
ClientVersion           : 14.1
ClientType              : EAS
IsManaged               : False
IsCompliant             : False
IsDisabled              : False

This article How to Block or Quarantine the Outlook for iOS and Android App in Exchange Server and Office 365 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Microsoft Wants to Improve Your Mobile Email Experience with the New Outlook for iOS and Android

$
0
0

Microsoft has launched Outlook for iOS and Android, a new mobile email client that is available for iOS and Android devices. This new app will replace the OWA for Devices app which remains available for now while Outlook for iOS and Android is developed and improved further.

The launch of Outlook for iOS and Android has stirred up some controversy around security and the way that the application and its back-end infrastructure handle user credentials. I want to go into this further here, but first let’s briefly look at the application itself.

Managing Email, Not Just Accessing Email

A major gripe with many mobile email applications, particularly the native mail apps that ship with mobile operating systems like iOS and Android, is that they deliver only basic access to email and calendars. Very little functionality exists in these apps to help end users manage their email.

In a world where email is supposedly dead, yet more and more people are drowning in the ever increasing volume of email they receive, it is not surprising to see specialized mobile email applications arrive on the scene. Examples include Mailbox, Google Inbox, and Acompli (which was acquired by Microsoft and is now Outlook for iOS and Android).

These apps put features in the hands of users to allow them to manage their email better, sort through the noise, and (for some people) achieve “Inbox Zero”. This is a good thing for users, and I applaud Microsoft for getting into this space rather than live with the user experiences that other applications are providing.

Functionally the application is fine, if a little rough around the edges. But that is easily improved and no doubt Microsoft has a roadmap of rapid updates planned to improve the user experience.

I want to talk about other things instead.

Security Concerns with Outlook for iOS and Android

Much noise has been made about the way that Outlook for iOS and Android works, with particular concern around the storing of user credentials.

In short, Outlook for iOS and Android connects to a server or service hosted in the cloud. It does not connect directly to your corporate Exchange server, Office 365 tenant, or other email services (the app supports Outlook.com, Yahoo!, and Gmail).

When you configure an account in Outlook for iOS and Android you’re sending your credentials to the cloud service to store. The cloud service then connects to your mailbox on your behalf, accesses your email for the purposes of indexing and sorting (for example, to determine what should go in your “Focused” inbox view), and then the app on your mobile device downloads the messages from that cloud service.

Here’s a more detailed explanation from Microsoft’s Javier Soltero (previously co-founder and CEO of Accompli):

Outlook uses Oauth for the accounts that support it (Outlook.com, OneDrive, Dropbox, Box, Gmail). For those not familiar, this provides us a way to access those cloud services without ever touching your password. For accounts that don’t support Oauth (Exchange ActiveSync, Yahoo, iCloud), we have to handle this differently.

When a user logs into Exchange and Office 365, we encrypt their password with a unique key that is specific to that user’s device and stored securely on it. The encrypted password is then passed along to Outlook’s cloud service and used to connect the accounts. Any time our service needs to present that password, it needs to have cooperation from the device in order to decrypt it using the key.

This architecture means that in order to gain access to your password, you would have to have access to both our cloud service and have physical access to the unlocked device. This applies to both us as well as anyone who would attempt to gain access from the outside.

As we continue to innovate on both our app and our service we will leverage alternative mechanisms such as OAuth as soon as they are available.

Cynics would say this is akin to a “man in the middle” attack. Which it is; except it is not malicious.

There are legitimate concerns to be had here, let’s be honest.

  • Microsoft is storing your credentials (in the case of Gmail I believe OAuth is used instead). How are they stored? This has not been communicated at this stage. However, I trust Microsoft to securely store my data including my credentials, and so do thousands of organizations around the world (take DirSync with Password Sync as an example).
  • Corporate policies are being violated. Providing your user credentials to a third party is a breach of many IT usage policies, and the app doesn’t make clear to end users that this is occurring. In fact the typical end user would have no idea that this is happening.
  • Data is stored in the USA. For organizations with data sovereignty or regulatory issues with off-shore data storage this will be a problem.

Microsoft needs to address these concerns as soon as possible. Let’s assume for now that the architecture of Outlook for iOS and Android is not going to change, and that the cloud service acting as a proxy between the user and their mailbox will remain in place. Microsoft needs to maintain open and transparent communication what is happening here, and work to address the data storage location issues, so that end users and corporate IT can make a proper risk assessment about the use of Outlook for iOS and Android.

In the meantime, if you would prefer to block or quarantine the app from your Exchange or Office 365 mailboxes while you do more investigation then you can follow the steps here to create an ActiveSync device access rule:

Microsoft also needs to open up a process whereby a customer can request removal of stored credentials. Microsoft says that a remote wipe will remove all stored in the cloud service. But an end user removing the app from a device does not necessarily remove the stored credentials and data from the cloud service. I’m sure a mechanism for this can be developed in the near future, one that allows the end user or corporate IT staff to determine what is currently stored in the cloud.

Mobile Device Management Concerns with Outlook for iOS and Android

I spent some time examining Outlook for iOS and Android from a mobile device management perspective. I found a few interesting things that I wanted to expand on here.

Policy Compliance

The first thing some people will notice is that Outlook for iOS and Android will successfully connect to mailboxes that have ActiveSync mailbox policies in place that require things like PIN codes and device encryption.

However, the app itself has no PIN code functionality that I can see, and in-app encryption is an unknown as well. Yet it reports itself to the server as compliant and is allowed in. Remember, ActiveSync policy compliance is an honesty system where the server relies on the device accurately reporting its compliance. This is true of straight ActiveSync connectivity but can be mitigated with additional mobile device management.

This is not automatically a problem. The default policies for Exchange 2013 and Office 365 are quite permissive and do not require PINs or device encryption. So any organization still running those defaults has no problem with Outlook for iOS and Android’s behavior.

That said, it would be nice if Microsoft would ship an app that respects an organization’s policies. Microsoft has stated that PIN lock, maximum failed password attempts, and an activity time out are top priorities for development efforts in this area.

Device Associations

Due to the “man in the middle” approach being used with Outlook for iOS and Android there will only ever be one mobile device association visible for the user, no matter how many different devices they have installed the app on.

This is fine, if a little awkward to report accurately on, until someone loses a device. Imagine an executive who has the app on their phone and tablet. The tablet is lost in the back of a taxi, but they still have their phone. The IT team has to make a decision – issue a remote wipe for the single “device”, which will wipe the account data from every device the app is installed on. Or, do nothing.

There’s no right answer there. But it does lead us into the next problem.

Remote Wipe Behavior

I was pleased to see that in my testing the remote wipe does actually work, and it does only remove the specific account from the Outlook for iOS and Android app. Other accounts configured in the app are untouched, as is the rest of the data on the device itself.

This type of “selective wipe” is perfect for BYOD environments. But there’s still a problem with how it works with this app.

Unfortunately, the app (or the cloud service in the middle) never reports back with the result of the wipe. No matter whether the remote wipe was request was successful or not, it will remain in a “pending” state forever. Or until the wipe request is removed.

In the earlier example of the executive with two devices this presents a problem. All their devices are blocked from connecting due to the remote wipe request. If they want to keep using their phone then the remote wipe request needs to be removed, without anyone knowing whether the lost tablet was successfully wiped.

There may be a workaround available whereby the app is completely removed and reinstalled, which gives it a new device ID and circumvents the problem. But that is still an awkward solution, and doesn’t solve the issue of the remote wipe result never being reported accurately.

Blocking Behavior

This falls more into the user experience side of things rather than being an architectural concern, but I’ll call it out here anyway.

When Outlook for iOS and Android is blocked, for example by using ActiveSync device access rules as mentioned earlier, it interprets this as an authentication failure and re-prompts for credentials. The other option given to the user at that time is to delete the account from the app. However, it is not clear whether this deletes the account only from the app, or also from the cloud service that is storing credentials and polling for email on the user’s behalf.

Other mail apps such as the native Mail app on iOS simply interpret a block as a “failure to connect to server”, which is also not a great user experience but is possibly better than falling into a cycle of re-entering credentials or removing the account entirely.

Summary

In my view Microsoft has done the right thing in acquiring this application from Acompli and launching it as Outlook for iOS and Android. The world is crying out for better email management apps and Microsoft needs to be in this space.

In the push to get it released I think they’ve fallen short on some of the communication aspects of the launch. These can be quickly remedied and I’m sure a series of blog posts and other announcements will clear up a lot of the confusion and concern that is floating around right now.

From a functional perspective I agree that the app needs some work, but I also think it is ready for launch and is past the point of being labelled a “beta” release. Holding things back and trying to get them perfect is how the old, slow Microsoft would have done it. This is the new Microsoft, ready to compete with the smaller, more agile startups out there, and more open to user feedback and letting that guide their development efforts. The more hands using the app and giving feedback the better.

Give it a try and let me know your thoughts in the comments below.

Further reading:


This article Microsoft Wants to Improve Your Mobile Email Experience with the New Outlook for iOS and Android is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Should You Block Outlook for iOS and Android?

$
0
0

Since the release of the Outlook for iOS and Android app, and my tutorial on how to block or quarantine the app using ActiveSync device access rules, a lot of people have asked me for a direct recommendation on what they should do about it.

I’d love to give a single answer, but really it depends on a few factors. So instead I will walk you through a short decision making process that will hopefully clear things up for you.

Firstly, let me just say that I am using the app myself. I have it connected to my Office 365 mailbox and I am likely to continue using it and watching how Microsoft is able to improve some of the user experiences and features.

I happily use the app because I’ve considered the following factors and decided the application is safe and secure for me to use.

Data Storage in US-based Cloud Servers

Outlook for iOS and Android acts as a proxy for your email account, storing mailbox data in a cloud service that Microsoft runs.

If you have a concern with this model for your organization, such as a data sovereignty or regulatory issue, then you should block/quarantine the app.

Credential Storage in the Cloud

Similar to the data storage point, Microsoft’s servers store an encrypted version of your user credentials so that they can connect to your Exchange/Office 365 mailbox and retrieve data. The encryption key is unique to your device and is stored on your device. Read more about that here.

If that credential disclosure by your users is prohibited by your IT usage policies, or you otherwise object to the storage of encrypted credentials, then you should block/quarantine the app.

ActiveSync Policy Compliance

Outlook for iOS and Android does not support PIN codes or in-app data encryption. It also reports itself to Exchange/Office 365 as compliant with these requirements, in effect bypassing any such requirement that you have set in your policies.

If your organization has PIN/encryption requirements for mobile devices, and you aren’t able to trust your users to maintain a suitable PIN or enable encryption on their device, then you should block/quarantine the app.

Note – the default ActiveSync policy for Exchange 2013 and Office 365 do not require PIN or encryption. Some customers may be unaware of this and not realise that the software configuration does not match their written policies. I recommend reviewing your ActiveSync policies to verify that they match what you think they should be.

ActiveSync Remote Wipe

Although Outlook for iOS and Android supports remote wipe, and does so in a “selective” manner (ie, only application data is wiped, not the entire device), it does not report remote wipe results back to your Exchange/Office 365 service. Therefore, you’ll never know whether a remote wipe of a lost device was successful.

This is also a risk with other remote wipe scenarios, which are often thwarted by things like airplane mode being enabled on the device, SIM cards being disabled, or passwords being changed.

If you are not satisfied that this remote wipe behaviour meets your IT security expectations then you should block/quarantine the app.

Integration with Other Services

The app has integration with additional services such as Dropbox, Box, iCloud, Google, OneDrive, and Yahoo! If your organization sees this as a risk, such as a data leakage or theft risk, then you should block/quarantine the app.

What if Users Still Try to Use the App?

Unless you have a mobile device management system deployed to the devices connecting to your Exchange/Office 365 system there’s nothing you can really to do prevent users from trying to use Outlook for iOS and Android. Even if you’re blocking or quarantining the app this means that the user credentials are still likely being stored by Microsoft, at least for a short time.

If that is a concern for your organization I recommend reviewing the ActiveSync device associations for mailboxes. You can do this quite easily using my Get-EASDeviceReport.ps1 script.

What Would I Do?

As I wrote earlier I do use the app myself and I’m happy to do so. I have no data sovereignty concerns, am satisfied that credentials are being securely stored, and I have a PIN and encryption enabled on my device.

However, if I was working for an organization that had one of the above reasons to block/quarantine the app then my response would be:

  1. Configure an ActiveSync device access rule to quarantine the app (refer to this article for exact steps).
  2.  Periodically review mobile device associations using Get-EASDeviceReport.ps1.
  3. When a user is found to have attempted to use the app, force a password reset on the user’s account and contact them to request they remove the app from their devices.

I hope that helps you with your decision making.


This article Should You Block Outlook for iOS and Android? is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Get-MailboxAuditLoggingReport.ps1 – PowerShell Script to Generate a Report of Mailbox Audit Log Entries

$
0
0

In Exchange Server environments where mailbox audit logging is used there may be a need to regularly generate reports of mailbox audit log data. I’ve written a PowerShell script, Get-MailboxAuditLoggingReport.ps1 to perform this task.

Although mailbox audit log reports can be created in the Exchange Admin Center the interface is not as fast to use as PowerShell, and it can’t be scheduled to run automatically for regular reports like a script can.

This script will generate a report of the mailbox audit log entries for a specified mailbox, for a period of time (the last 24 hours by default), and save the full results to CSV as well as a summary of the data to a HTML file. The script can also be used to send the results via email with the CSV data attached.

mailbox-audit-log-report-example

This script is available on the TechNet Script Gallery and Github. Comments are welcome below. If you find a bug please consider raising it as an issue on Github.


This article Get-MailboxAuditLoggingReport.ps1 – PowerShell Script to Generate a Report of Mailbox Audit Log Entries is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

How to Fix a Failed Database Content Index for Exchange Server 2013

$
0
0

Note: this tip applies to Exchange Server 2013 Mailbox servers that are not members of a Database Availability Group. For failed content indexes on DAG members refer to this article.

On an Exchange Server 2013 server you may encounter failed content indexes that are preventing end users from being able to run searches in OWA and Outlook.

A failed content index will be visible in the output of Get-MailboxDatabaseCopyStatus:

[PS] C:\>Get-MailboxDatabaseCopyStatus * | ft -auto
Name             Status  CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
----             ------  --------------- ----------------- -------------------- -----------------
DB01\EX2013SRV1  Mounted 0               0                                      FailedAndSuspended
DB02\EX2013SRV1  Mounted 0               0                                      FailedAndSuspended
DB03\EX2013SRV1  Mounted 0               0                                      Healthy
DB04\EX2013SRV1  Mounted 0               0                                      FailedAndSuspended
DB05\EX2013SRV1  Mounted 0               0                                      Disabled

In the example above the content indexes for DB01, DB02, and DB04 are failed.

Other indications of a problem can be seen in the Application event log, for example:

Log Name: Application
Source: MSExchangeIS
Date: 2/16/2015 11:09:26 AM
Event ID: 1012
Description:
Exchange Server Information Store has encountered an error while executing a full-text
index query ("eDiscovery search query execution on database 191987bf-5e9f-4ba4-b13b-3cadcb9e51f5
failed."). Error information: System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]:
Internal error while processing request (Fault Detail is equal to An ExceptionDetail, likely created by
IncludeExceptionDetailInFaults=true, whose value is:
Microsoft.Ceres.InteractionEngine.Component.ProcessingEngineException: Internal error while processing request
at Microsoft.Ceres.InteractionEngine.Component.CieProcessingEngine.LogAndRethrowException(Exception e)
Log Name: Application
Source: MSExchangeFastSearch
Date: 2/16/2015 11:06:13 AM
Event ID: 1009
Description:
The indexing of mailbox database DB02 encountered an unexpected exception. Error details:
Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed.
---> Microsoft.Exchange.Search.Engine.FeedingSkippedForCorruptionException: "Feeding was skipped for
'63fe7551-8100-4e3e-9a3e-4b14744eddb6 (DB02)' due to the state 'Failed', error code: 'CatalogCorruption',
failure code: '2400519', failure reason: 'Failed to initialize FastServer: Generation mismatch:
0 < GID[82381] [IndexName=63FE7551-8100-4E3E-9A3E-4B14744EDDB612.Single]'."
at Microsoft.Exchange.Search.Engine.SearchFeedingController.InternalExecutionStart()
at Microsoft.Exchange.Search.Core.Common.Executable.InternalExecutionStart(Object state)
--- End of inner exception stack trace ---
at Microsoft.Exchange.Search.Core.Common.Executable.EndExecute(IAsyncResult asyncResult)
at Microsoft.Exchange.Search.Engine.SearchRootController.ExecuteComplete(IAsyncResult asyncResult)

To rebuild a failed content index we first need to stop the search services on the Exchange server. Not
that this may impact searches for other healthy databases, and the rebuilding process can also create a
significant load on the server, so you may wish to do these steps outside of normal business hours.

Stop the following services:

  • Microsoft Exchange Search Host Controller
  • Microsoft Exchange Search
[PS] C:\>stop-service MSExchangeFastSearch
[PS] C:\>stop-service HostControllerService

Navigate to the location of the content index for the database. This will be the same folder that the database file is located in. For example, DB01 is located in F:\DB01\.

[PS] C:\>Get-MailboxDatabase DB01 | select EdbFilePath
EdbFilePath
-----------
F:\DB01\DB01.edb

The content index is stored in a folder named for the GUID of the database.

exchange-2013-catalog-index-location

Delete the folder. Repeat the same steps to delete the folder for any other failed content indexes you’re also dealing with at the time.

Then start the search services again.

[PS] C:\>start-service MSExchangeFastSearch
[PS] C:\>start-service HostControllerService

The content indexes will be rebuilt, which can take quite a while to complete depending on the amount of data in the databases.

Eventually you should find that your content indexes are healthy again.

[PS] C:\>Get-MailboxDatabaseCopyStatus * | ft -auto
Name             Status  CopyQueueLength ReplayQueueLength LastInspectedLogTime ContentIndexState
----             ------  --------------- ----------------- -------------------- -----------------
DB01\EX2013SRV1  Mounted 0               0                                      Healthy
DB02\EX2013SRV1  Mounted 0               0                                      Healthy
DB03\EX2013SRV1  Mounted 0               0                                      Healthy
DB04\EX2013SRV1  Mounted 0               0                                      Healthy
DB05\EX2013SRV1  Mounted 0               0                                      Disabled

This article How to Fix a Failed Database Content Index for Exchange Server 2013 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Outlook for iOS and Android Gets Updated with Support for PIN Policies

$
0
0

Microsoft has shipped an update for Outlook for iOS and Android that includes support for device PIN policies. The new version number with this feature for both iOS and Android versions is 1.0.4.

outlook-ios-update-pin-policies

outlook-android-update-pin-policies

Lack of support for PIN policies was one of the major criticisms of Outlook for iOS and Android when it first shipped. Basically the application would successfully connect to Exchange or Office 365 if the mobile device policies required a PIN, even when the device itself had no PIN. In effect it was ignoring the mobile device policies set by the organization. This caused some organizations to decide that blocking the app was the the safest approach.

I tested the new version of the app on both iOS and Android and confirmed that the PIN requirements are now enforced.

On iOS if the mobile device has the PIN removed the Outlook app blocks the user from accessing any of the email accounts in the app until the non-compliant account is deleted from the app.

outlook-ios-locked

This actually means that the user can’t access any email account in the app, even normal consumer accounts like Outlook.com, as long as the non-compliant account is still configured. A little disruptive to the end user perhaps, but it certainly achieves the desired outcome from a corporate security perspective.

For Android the behaviour is a little different, with the user prevented from removing the PIN code from the device (or at least this is how my Nexus 7 tablet behaved).

outlook-android-pin-policies

Unfortunately this isn’t a clear win for Microsoft or customers. There are some caveats here that you need to be aware of.

When Outlook for iOS and Android connects to your Exchange or Office 365 services it does not connect directly. Instead it connects to some servers that Microsoft operates, and those servers connect to your network to retrieve the user’s emails. This acts as a kind of proxy and allows the application to remain light-weight, be developed and optimized faster, and do intelligent processing of your emails.

However what this also means is that no matter how many devices you are using Outlook for iOS and Android on, you only see one device association for your mailbox.

outlook-ios-android-app-device-associations

In the example above an Android device and two iOS devices are connected to a mailbox, but the mailbox only shows a single device association.

PS C:\> Get-MobileDevice | where devicetype -eq "Outlook" | select Device*
DeviceId                : AB5F6EFCDA6E681E
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : Outlook for iOS and Android 1.0
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS-Android/1.0
DeviceModel             : Outlook for iOS and Android
DeviceAccessState       : Allowed
DeviceAccessStateReason : Global
DeviceAccessControlRule :

There is no distinction between different devices, nor is there any distinction between different versions of the application. I can still connect a non-compliant version of the application to my mailbox and it will work. Only the devices with the new version will enforce the PIN requirement.

This puts organizations who want to allow the new version of the application in a tricky situation, because removing their device access rule will allow the non-compliant versions to connect again. There is a slightly cumbersome middle ground, where a quarantine rule is used until the IT team is able to confirm that the end user is on the newer version of the app before allowing the device to connect. That process wouldn’t scale very well though.

I’m sure Microsoft has plans to resolve this in a future update, perhaps by updating the user agent or some other characteristic of the app to allow the specific versions to be blocked/allowed with device access rules. But at least we’re seeing the rapid development and updates that were promised when the app was first launched.


This article Outlook for iOS and Android Gets Updated with Support for PIN Policies is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

Shared Mailbox Sent Items Changes Coming to Office 365

$
0
0

In Exchange Server 2010 there is a useful feature that allows an administrator to configure the sent items behavior for shared mailboxes. For example, this feature can be configured to automatically store emails sent from a shared mailbox in the Sent Items folder of the shared mailbox itself, rather than the Sent Items folder of the person who actually sent it.

This is quite important to some organizations and certainly makes it easier to find a sent item for a shared mailbox instead of needing to hunt down the sender using mailbox audit logging.

This sent items control is unfortunately not included with Exchange Server 2013, which also means it is not currently available in Exchange Online (Office 365). For several customers of mine this has actually been considered a reason not to upgrade to Exchange 2013 or migrate to Office 365.

The Office 365 public roadmap has good news for customers with “More control over Sent Items for Shared Mailboxes” currently in development and testing.

Emails can be sent as the shared mailbox itself or on behalf of it by members who have proper permissions. This change will allow newly created shared mailboxes to retain a copy of emails sent from the mailbox by default. You will no longer have to figure out which mailbox member sent an email as the shared mailbox or on behalf of it.

What isn’t clear from that brief statement is whether the feature will also be available for existing shared mailboxes, and whether the behavior will be configurable by administrators. The default behavior described above sounds fine to me, but enterprises love control.

There is no ETA for rolling out this feature to customers, but having it on the public roadmap is certainly a good sign for customers.


This article Shared Mailbox Sent Items Changes Coming to Office 365 is © 2015 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     
Viewing all 520 articles
Browse latest View live