Lets Exchange

Microsoft Outlook Configuration Analyzer Tool

noreply@blogger.com (Nuno Mota) — Tue, 14 Feb 2012 11:37:00 +0000

Microsoft just released the Outlook Configuration Analyzer Tool (OCAT ), which provides a quick and easy method to analyze your Outlook profile for common configurations that may cause problems.

This first version of OCAT allows you to do the following:

Scan your computer;
Open a previously run scan on your computer;
Import a scan from another computer;
Use several reporting formats to view the scan results ;
Start the Exchange Remote Connectivity Analyzer tool;
Send feedback to the OCAT team.

System requirements

Before you install OCAT, make sure that your computer meets the following system requirements.

Supported operating systems:

Windows 7
Windows Vista Service Pack 2
Windows XP Service Pack 3

This download works with the following Microsoft Office programs:

Microsoft Office Outlook 2007
Microsoft Outlook 2010 (32-bit or 64-bit)

You also need (minimum version) Microsoft .NET Framework Version 2.0

Be aware that you must make sure that Outlook is running before you start an OCAT scan!

The document that comes with the download covers really well everything that there is to know with this tool, so I will just post here some examples of what I got when I ran it on my Outlook profile.

Just like ExTRA and ExBPA, there are 3 report types: List Reports, Tree Reports and Other Reports.

When in List Reports, you have an “easy to read” view of Informational Issues, All Issues and Critical Issues:

Tree Reports gives you a more detailed a technical view:

Like I said, OCAT’s manual covers these in great detail, so I just wanted to put here a few example so you know what to expect.

DOWNLOAD: you can find OCAT here.

Exchange Server 2010 SP2 Help

noreply@blogger.com (Nuno Mota) — Mon, 13 Feb 2012 15:52:00 +0000

The latest version of the Exchange 2010 help file has been released. This version (related to SP2) is from 31st of January 2012 and can be found here.

Infinite Loop of Nested Folders

noreply@blogger.com (Nuno Mota) — Wed, 08 Feb 2012 13:39:00 +0000

A few weeks ago one user moved a subfolder of her Inbox into another subfolder beneath that one, which triggered the creation of an “infinite” loop of nested subfolders:

I tried to recreate this behaviour but every time I would get the following error (as one would expect):

So I am still not sure how all this happened... Anyway, time to delete those folders! And this is where it got interesting... First thing I tried was obviously to give myself FullAccess permissions to the mailbox and delete the folders myself. However, Outlook returned the following error:

4,000?! Humm... Let’s see how many items are in these folders and how many folders in total. To do this, I used the following two cmdlets (most output removed for simplicity):

[PS] C:\> Get-MailboxFolderStatistics “user” | ? {$_.FolderPath -eq "/Inbox/Pictures of Y"}

Name : Pictures of Y

FolderPath : /Inbox/Pictures of Y

FolderType : User Created

ItemsInFolder : 0

DeletedItemsInFolder : 0

FolderSize : 0 B (0 bytes)

ItemsInFolderAndSubfolders : 0

DeletedItemsInFolderAndSubfolders : 0

FolderAndSubfolderSize : 0 B (0 bytes)

[PS] C:\> (Get-MailboxFolderStatistics “user”).Count

2922

Ok, so excluding all the default folders and the ones manually created by the user, there’s “only” around 2,890 folders with nothing on them. So why the error about the 4,000 limit?! Time to troubleshoot and get rid of these annoying folders!

Attempt 1

Although I had FullAccess permissions to the mailbox, decided to use ExFolders to grant myself Owner permissions on the top folder and all the subfolders. After almost 1h of propagating the permissions throughout all folders, still got the same error when trying to delete them using Outlook...

Noticed that after trying to delete the folders in Outlook, I would get the following error in the Application log of the Mailbox server (using my account to access the user’s mailbox):

Mapi session "a7198e9f-265f-4e94-b63d-7ee3d78c00c3: /o=domain/ou=exchange administrative group (fydibohf23spdlt)/cn=recipients/cn=motan" exceeded the maximum of 500 objects of type "objtFolder".

Attempt 2

Tried to delete the folders using OWA but a similar result...

Attempt 3

Tried exporting the mailbox to a PST file but it wouldn’t export it because of the folders... The export reaches 100%, then it goes down to 5%, then up again, until it eventually fails.

Tried excluding the top folder from the export using the following cmdlet:

New-MailboxExportRequest "user" -FilePath “\\server\F$\PSTs\user.pst” -ExcludeFolders “#Inbox#/Pictures of Y”

But it still didn’t work. I am not sure if the ExcludeFolders parameter also excludes subfolders or not... Both failed with the following message:

Error: MapiExceptionPartialCompletion: Unable to copy to target. (hr=0x40680, ec=0)

Operation: ISourceFolder.CopyTo

OperationSide: Source

Primary (c0e7ee8d-6f43-430a-b11f-dfba42501ee6)

PropTags: [ContainerContents; FolderAssociatedContents; ContainerHierarchy; DisplayName; RulesTable; 1071710466]

Attempt 4

Tried deleting the folders with MFCMapi but got the following error:

Attempt 5

Tried using Microsoft Exchange Server Information Store Viewer (MDBVU32) but it didn’t work as well. I wasn’t getting any errors and could create and delete other folders, but not the ones I wanted to...

MDBVU32 works “a bit” like MFCMapi. You basically logon and open the Message Store you want to access and then look for the folder (or e-mail) you want to work on.

You then change the operation to DeleteFolder() and click on Call Function... Select the flags you want and then click OK.

In my case nothing would happen for these folders although it would work for any other folders/e-mails...

Attempt 6

Thought about creating another mailbox and simply copy everything across but this would have an impact on the user and the categories wouldn’t be moved, so out of the question for now...

Attempt 7

Changing the type of the folder using MFCMapi:

Start MFCMapi with Outlook not set to cached mode;
Logon and display store table;
Open mailbox/Top of Information Store;
For an email sub folder that you want to delete;
Change PR_CONTAINER_CLASS to IPF.IMAP from IPF.Note;
Click OK in the property pane.

But still the same error when deleting both from MFCMapi and Outlook...

Attempt 8

Isinteg was out of the question as it would take days to run on the DB where the user is and would affect everyone on that DB. So tried moving the mailbox to another DB but it didn’t work... After more than 3h always in 5%, it finally failed with the error (some output removed for simplicity):

Alias : user

Status : Failed

StatusDetail : FailedMAPI

BadItemLimit : 5000

BadItemsEncountered : 0

OverallDuration : 04:38:45

TotalFailedDuration : 03:25:37

TotalQueuedDuration : 00:00:03

TotalInProgressDuration : 01:13:04

TotalTransientFailureDuration : 00:31:19

TotalMailboxSize : 1.23 GB (1,320,399,499 bytes)

TotalMailboxItemCount : 25749

BytesTransferred : 0 B (0 bytes)

ItemsTransferred : 0

PercentComplete : 5

FailureCode : -2147024882

FailureType : MapiExceptionNotEnoughMemory

FailureSide : Source

Message : Error: MapiExceptionNotEnoughMemory: Unable to synchronize manifest. (hr=0x8007000e,

ec=1008)

Diagnostic context:

Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=142]

Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=739][latency

=46]

Lid: 23226 --- ROP Parse Start ---

Lid: 27962 ROP: ropOpenFolder [2]

Lid: 27962 ROP: ropIncrCfg [112]

Lid: 27962 ROP: ropUpldStStrmBegin [117]

Lid: 27962 ROP: ropUpldStStrmEnd [119]

Lid: 27962 ROP: ropUpldStStrmBegin [117]

Lid: 27962 ROP: ropUpldStStrmEnd [119]

Lid: 27962 ROP: ropUpldStStrmBegin [117]

Lid: 27962 ROP: ropUpldStStrmEnd [119]

Lid: 27962 ROP: ropUpldStStrmBegin [117]

Lid: 27962 ROP: ropUpldStStrmEnd [119]

Lid: 27962 ROP: ropFXSrcGetBufferEx [156]

Lid: 17082 ROP Error: 0x3F0

Lid: 23137

Lid: 21921 StoreEc: 0x3F0

Lid: 27962 ROP: ropExtendedError [250]

Lid: 1494 ---- Remote Context Beg ----

Lid: 1238 Remote Context Overflow

Lid: 7155 StoreEc: 0x3F0

Lid: 6131 StoreEc: 0x3F0

Lid: 22184

Lid: 24312 StoreEc: 0x3F0

Lid: 22360

Lid: 2238 StoreEc: 0x3F0

Lid: 20888

Lid: 24504 StoreEc: 0x3F0

Lid: 24148 StoreEc: 0x3F0

Lid: 23796

Lid: 2478 StoreEc: 0x3F0

Lid: 1750 ---- Remote Context End ----

Lid: 26849

Lid: 21817 ROP Failure: 0x3F0

Lid: 32758

Lid: 16586 StoreEc: 0x3F0

Lid: 22518

Lid: 28874 StoreEc: 0x3F0

Lid: 29516

Lid: 31820 StoreEc: 0x3F0

FailureTimestamp : 02/02/2012 10:27:38

FailureContext : --------

Operation: ISourceMailbox.EnumerateHierarchyChanges

OperationSide: Source

Primary (c0e7ee8d-6f43-430a-b11f-dfba42501ee6)

Catchup: True

Attempt 9

Already getting desperate, decided to temporarily increase the maximum number of objects that can be handled by Outlook clients by setting both objtfolder and objtfolderview to a value greater than 500 (KB842022 or Maximum open folder objects per logon has been changed).

WARNING: this affects everyone on the mailbox server you set this and it also needs an IS restart so be very careful!!!

As I have a few servers that only host passive DBs, decided to implement the change in one of those servers (I set the registry key value to 3000) and switched over only that DB to that server.

Tried deleting the folders but was getting the same error regarding the 4,000 limit! Not sure why this time... Increased the registry key’s value to 6000 and decided to try again. However, although there were no errors at all on the server, no one could access any mailbox in that server!... Ups! Time to quickly rollback!

Another failed attempt...

Resolution

So how did I fix this problem? Since the beginning that I was thinking about what would happen if I tried to delete the last folder? Because I didn’t feel like expanding almost 3,000 folders (probably for Outlook to complain about the 500 limit!) this had to be done using a script.

Although I love writing scripts, I was avoiding doing this for some reason. But since everything else was failing, I decided to give it a go. And the result was that it worked without any problems! :-D

I just wanted to quickly try this, so didn’t pay much attention to performance. For this reason, the script is not very efficient because:

it goes through all the folders one by one and then deletes the last one;

starts all over again, goes through all the folders one by one and then deletes the last one;

starts all over again....

In this case it took between 30 to 60 minutes to delete 2,890 folders but it eventually got there! :)

WARNING: as with every script, make sure you test it properly before running it for a live user!!!

You can also find the script in the Microsoft TechNet Script Repository: Delete Outlook Folders Bottom-Up

# Script: DeleteFoldersBackwards.ps1
# Purpose: This scripts deletes every folder and subfolders for a specific top-folder starting from the last one
# Author: Nuno Mota
# Date:  Feb 2012

[String] $mbxName = "motan@parliament.uk"
[Int] $intCount = 0

[String] $dllPath = "E:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll"
[Void] [Reflection.Assembly]::LoadFile($dllPath)

$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
$Service.AutodiscoverUrl($mbxName, {$True})

# This is the root folder from where we want to start searching for the folder we want to delete.
# Once we find it, then we will go recursively down that folder.
# Other option would be to get the FolderID and start the search straight from there
$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox, $mbxName)
#$RootFolderID = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root, $mbxName)
$RootFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($Service, $RootFolderID)

$FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(1000)
$FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
$Response = $RootFolder.FindFolders($FolderView)

# Go through all folders under the Inbox folder looking for the folder we want to delete
ForEach ($folder in $Response.Folders)
{
 # Check if the current folder is the folder we want to delete
 If ($folder.DisplayName -eq "Pictures of Y")
 {
  # Found the folder, so start a new Deep search across all its sub-folders
  $FolderView = New-Object Microsoft.Exchange.WebServices.Data.FolderView(3000)
  $FolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
  $Response = $folder.FindFolders($FolderView)
  $RootFolder = $folder
  
  # Loop to go through all sub-folders while there are any
  While ($($Response.Folders).Count -gt 0)
  {
   # Get the last folder so we can then delete it (not very efficient...)
   ForEach ($folder in $Response.Folders)
   {
    #$folder.DisplayName
    $lastFolder = $folder
   }

   Write-Host "Deleting", $lastFolder.DisplayName
   $lastFolder.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete)
   $intCount++
   Write-Progress -Activity "Deleting Folders" -Status "Folders Deleted: $intCount"

   $Response = $RootFolder.FindFolders($FolderView)
  }

  # Delete the top folder and exit the first ForEach
  #Write-Host "Deleting Top ""$($RootFolder.DisplayName)"""
  $RootFolder.Delete([Microsoft.Exchange.WebServices.Data.DeleteMode]::HardDelete)
  Break
 }
}

Exchange AD Schema Changes

noreply@blogger.com (Nuno Mota) — Fri, 03 Feb 2012 15:54:00 +0000

We all know that with every Exchange Service Pack [SP] we have to run the usual setup /PrepareSchema (or setup /ps) in order to prepare the Active Directory Domain Services Schema for the newer version of Exchange. This is because every new SP introduces new attributes and modifies some existing classes and attributes in the Schema. But what exactly is added and/or changed?! To help answering this question, Microsoft made available the Exchange Server Active Directory Schema Changes Reference document.

The latest version of the document, from November 2011, includes changes made by:

Exchange Server 2010 SP2, SP1 and RTM
Exchange Server 2007 SP3, SP2, SP1 and RTM
Exchange Server 2003

Not sure why the file is not available a “simple” download, but you have to download a nADSchemaRef.msi file, install it and then get the document from (by default) C:\Program Files\Microsoft\ExDevCenterDownloads\Exchange Server Active Directory Schema Changes Reference. Very strange...

DOWNLOAD: Exchange Server Active Directory Schema Changes Reference,November 2011

Other alternative you have, is by looking at all the .ldf files that are used in the process, which are located in the \amd64\Setup\Data\ directory on the setup DVD.

I recon you will prefer the first method :)

Exchange 2010 SP2 Breaks OWA

noreply@blogger.com (Nuno Mota) — Sun, 29 Jan 2012 15:40:00 +0000

The other day we decided it was time to apply SP2 to our Exchange 2010 SP1 environment (in pre-production first of course). After installing it to one CAS server without any issues, it was time to test it to make sure OWA, ECP, etc., was working fine.

We have Hardware Load Balancers in front of our CAS servers and we also do SSL Offloading so to test it we connected directly to the CAS server:

OWA opened fine. We could navigate through all the e-mails in the Inbox folder without any problems;
We noticed that the integration with OCS wasn’t working… After checking all the configurations, everything seemed to be correct;
The ECP was working without any problems;
But whenever we selected a different folder in OWA, we would get the following error message:

After a while, we noticed that by using HTTP://CASserver/OWA we would experience all these problems but if we used HTTPS everything would work fine!

So we checked IIS settings regarding SSL, Certificates, SSL Offloading and the OWA Virtual Directory configuration but everything was as before!...

It was only when we compared the web.config file for OWA that we noticed something different:

SP2 introduces a new key called httpCookies:

Although in IIS we have the Default WebSite to require SSL but the OWA one to not require SLL, this setting seems to take precedence and so it makes OWA to require SSL. For this reason, we were getting all those problems when using HTTP only...

After changing the requireSSL="true" to false, everything was back to normal!

According to Microsoft, this is a new feature in SP2 to simplify the Outlook Web App URL (in most scenarios).

In the Exchange 2010 SP2 Release Notes there is a mention to this that we missed:

If you’re using redirection for Outlook Web App and aren’t requiring Secure Sockets Layer (SSL), redirection will fail after the Client Access server is upgraded to Exchange 2010 SP2. To avoid this problem, after you’ve completed the upgrade to Exchange 2010 SP2, modify the Outlook Web App web.config file. For directions, go to “Use IIS Manager and Notepad to simplify the Outlook Web App URL when SSL isn’t required” in Simplify the Outlook Web App URL. You don’t have to make any changes in IIS Manager to prevent redirection from failing. You just have to modify the web.config file.

Bottom line: always read everything in the release notes and always test it before implementing any change/rollup/SP in your production environment!

Mobile Device Management

noreply@blogger.com (Nuno Mota) — Thu, 19 Jan 2012 22:27:00 +0000

As we all know, Exchange 2010 brought many, many welcomed new features.

With the latest version of Exchange ActiveSync [EAS] 14.1 released with Exchange 2010 SP1, came a few more such as GAL photos or Information Rights Management over EAS. A major one was the addition of device and user information to the provision command of mobile devices. This allows administrators to create Allow, Block and Quarantine lists (known as ABQ lists) in order to control which mobile devices are allowed to access Exchange mailboxes.

Although this functionality was present in the RTM version of Exchange 2010 with version 14 of EAS, SP1 adds a user interface in Exchange Control Panel [ECP] for easier management of ABQ lists.

We can, for example, quarantine all or just specific devices based on their model:

In this case, we created a Device Access Rule to block all Samsung Galaxy S II devices. When I then tried to connect my phone to Exchange, I got the following message:

Because this is a new device, Exchange sent the following e-mail to the administrator so he was aware of it:

To read more about this new functionality, explore it in-depth and see a few examples on how to configure everything, please check the following posts on MSExchange.org:

Hope you find it interesting!

PDC emulator is not excluded from DSAccess topology

noreply@blogger.com (Nuno Mota) — Sun, 15 Jan 2012 13:38:00 +0000

When running the Exchange Best Practices Analyzer Tool [ExBPA] you will probably get the following warning:

This is because it is recommended to exclude the Primary Domain Controller [PDC] from the list of DCs available for use by Exchange.

First, let’s clarify what ADAccess and PDC are:

The PDC Emulator is an Active Directory [AD] operations master role computer that processes replication requests from Microsoft Windows NT Server 4.0 backup domain controllers and processes all password updates for clients that are not running AD enabled client software. PDC emulators are also Domain Controllers [DC] and are therefore available for use by applications such as Exchange;
Directory Service Access [DSAccess] is an internal component of Exchange that controls how all Exchange Server components access AD. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the AD topology and detects if DCs and global catalog servers are available and responding to queries.

By default, DSAccess includes the PDC emulator computer in its list of available and usable DCs. If non-Exchange Server programs are making heavy use of the PDC emulator, Exchange can worsen this situation or even suffer from it.

To prevent such performance issues, the MinUserDC registry value can be added to the registry on an Exchange server to force DSAccess to query all other available DCs before querying the domain controller that holds the PDC emulator operations master role.

To create/update MinUserDC registry value:

1. Open the Registry

2. On a computer that is running Exchange Server 2010, locate the following subkey:

HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\MinUserDC

On a computer that is running Exchange Server 2007, locate the following subkey:

HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

3. Locate the MinUserDC value and make any required changes. If this DWORD value does not exist, you can manually create it.

Note: The value for the MinUserDC registry entry is the maximum number of DCs to contact before contacting the PDC emulator. For example, setting MinUserDC to 4 configures DSAccess to exclude the PDC emulator only when a total of 4 DCs are available. When this condition is met, the PDC emulator is excluded from use and DSAccess communicates only with the remaining 3 DCs.

Another way to configure the DSAccess component to exclude a particular DC or a list of DCs from use is by using the Set-ExchangeServer cmdlet together with the -StaticExcludedDomainControllers parameter:

Set-ExchangeServer "server" -StaticExcludedDomainControllers "pdc.domain.com"
Get-ExchangeServer "server" -Status | Select Name, StaticExcludedDomainControllers

However, please note that the MinUserDC key will still allow Exchange to use the PDC Emulator if the other DCs/GCs go offline but the static exclude list will not!

Hope this helps!

Prevent Mailbox AutoMapping

noreply@blogger.com (Nuno Mota) — Sun, 08 Jan 2012 17:36:00 +0000

With Exchange 2010 came the great AutoMapping feature. With it, administrators could grant users full access to mailboxes and these would automatically appear in user’s Outlook without the need to manually add them.

As you might know, this is done by using an Active Directory attribute on the user’s mailbox called msExchDelegateListLink that contains a list of Distinguished Names of mailboxes the user has full access to and should auto-mount in Outlook.

However, in cases where administrators have access to dozens, hundreds or thousands of mailboxes, this is not ideal... You can give permissions and then manually edit msExchDelegateListLink to remove the mailbox from the list or create a script to do this automatically, but with Exchange 2010 SP2 comes an easier way to achieve this.

By using the Add-MailboxPermission cmdlet you now have available the –AutoMapping parameters that allows you to specify if the mailbox should auto-mount or not!

Add-MailboxPermission "mailbox" -User "user" -AccessRights FullAccess –AutoMapping $False

Hope this helps!

Multi-Valued Custom Attributes

noreply@blogger.com (Nuno Mota) — Wed, 04 Jan 2012 23:07:00 +0000

As I mentioned in my previous post, Exchange 2010 SP2 introduces “multi-value custom attributes”. But what exactly does this mean? Basically, now there are 5 new custom attributes that can hold more than one value: ExtensionCustomAttribute1 to ExtensionCustomAttribute5, which can now hold up to 1,300 values each! Why do we need to store more than 1 value when we have 15 CustomAttributes?! Well, you might want to save in ExtensionCustomAttribute1 all the times you increased the user’s mailbox or all the databases you moved the user from/to, etc... I’m sure someone will come up with a good use for them!

If we compare CustomAttributes with ExtensionCustomAttributes, we can see that the new ones are stored in an array to allow for multiple values:

These parameters are used by the following cmdlets:

Set-DistributionGroup
Set-DynamicDistributionGroup
Set-Mailbox
Set-MailContact
Set-MailPublicFolder
Set-RemoteMailbox

As you can see from this list, you can use attributes with Distribution Groups, Mailboxes, Contacts, mail enabled Public Folders and Remote Mailboxes.

There are several methods of saving data in these attributes. First, let’s look at how we can set new values:

Now let’s add values to the existing ones. Here we have two options:

Using the “normal” method that most administrators are used to;
Using the Add functionality introduced with SP1.

As you can see, the second method is much easier! A very welcome improvement.

To remove, we can also use both methods but, again, the easiest one is the second:

Hope this helps and please let me know if you plan to use them and for what!

Exchange Server 2010 SP2 Released

noreply@blogger.com (Nuno Mota) — Mon, 05 Dec 2011 22:57:00 +0000

Exchange 2010 SP2 has been released today! Here are the new features/improvements:

Hybrid Configuration Wizard
Address Book Policies
Cross-Site Silent Redirection for Outlook Web App
Mini Version of Outlook Web App
Mailbox Replication Service
Mailbox Auto-Mapping
Multi-Valued Custom Attributes
Litigation Hold

I’m not going to describe what each one of these are/do as the topic What’s New in Exchange 2010 SP2 does the job very well. What I will do is post here some more information once I test them.

Just a quick note: when you try to install it, you might get the following error:

CAS Prerequisites SETUP error: The "IIS WMI Compatibility" component is required. Install the component via the Web Server Manager.

This is because SP2 introduces a new requirement for CAS servers to have the IIS6 WMI Compatibility role. So, probably the best way is to use one of the following methods:

setup.com /m:upgrade /InstallWindowsComponents

Import-Module ServerManager
enable-windowsfeature web-wmi

Import-Module ServerManager
Add-WindowsFeature NET-Framework, RSAT-ADDS, Web-Server, Web-Basic-Auth, Web-Windows-Auth, Web-Metabase, Web-Net-Ext, Web-Lgcy-Mgmt-Console, WAS-Process-Model, RSAT-Web-Server, Web-ISAPI-Ext, Web-Digest-Auth, Web-Dyn-Compression, NET-HTTP-Activation, RPC-Over-HTTP-Proxy, Web-WMI –Restart

Disable iSCSI Networks for DAGs

noreply@blogger.com (Nuno Mota) — Wed, 30 Nov 2011 15:18:00 +0000

If you have Exchange 2010 DAGs and you use iSCSI to present those servers with storage for the databases, you must ensure the DAG does not use this network.

When a DAG is configured, it tries to discover all networks configured on the server and configure them to be used by the underlying cluster, which includes any iSCSI networks... If you have a problem with your MAPI and Replication networks, Exchange will try to use the iSCSI network for normal DAG and user traffic which, obviously, will not work and generate loads of errors (such as cluster.exe trying to communicate with other nodes over this network).

As a best practice, iSCSI storage should use dedicated networks and network adapters. These networks shouldn't be managed by the DAG or its cluster, or used as DAG networks (MAPI or replication).

You can check what networks your DAG is currently using by running the following cmdlet in EMS:

Get-DatabaseAvailabilityGroup -Status | Select Name, NetworkNames

or get a more detailed view with which networks were detected, what are they used for and if they are excluded from the DAG:

Get-DatabaseAvailabilityGroupNetwork -Server MBX1 | Select Name, MapiAccessEnabled, ReplicationEnabled, IgnoreNetwork

Disabling it/them, is a two-step process:

1. DAG

Configure the DAG to ignore your iSCSI networks (replace with the correct name):

Set-DatabaseAvailabilityGroupNetwork <MbxDAG1\iSCSInetwork> –ReplicationEnabled $False –IgnoreNetwork $True

2. Cluster

To disable the network for use by the cluster you can use the GUI. However, there was a bug in a certain Windows 2008 R2 version (apologies, not sure which one) where you would select the following option:

You would then click ok but when you went back to the same screen, the Allow cluster network communication on this network was still selected...

So, the best option is to use the Cluster Network command. You can check what the network is currently configured for:

Role 0 (0x0) tells the cluster not to use the network;
Role 1 (0x1) tells the cluster that this is a private network;
Role 3 (0x3) tells the cluster that this is a public network.

And set the Role to 0:

Cluster network ClusterNetworkName /prop Role=0

To check if the command worked properly, run the Cluster network ClusterNetworkName /prop again.

After disabling all iSCSI networks for use by the DAG and its cluster, you can optionally force network discovery by running the Set-DatabaseAvailabilityGroup cmdlet with the DiscoverNetworks parameter.

Hope this helps!

EWS Managed API 1.2 SDK Documentation Available

noreply@blogger.com (Nuno Mota) — Sun, 27 Nov 2011 15:59:00 +0000

The new Exchange Web Services Managed API v1.2 documentation is now available.

You can check all the new features in the What’s New website, but for me best additions/improvements are:

GetPasswordExpirationDate method that allows you to get the domain password expiration date for a specified mailbox user;
The possibility to set automatic replies, such as Out of Office (OOF) messages;
The possibility to expand a distribution list to display all members ;
The possibility of getting user free/busy information.

Unfortunately, you cannot download the new API just yet… As usual, the documentation was released earlier so that administrators/developers can start having a look at what’s coming. But it shouldn't be long before it is released.

For more information:

"Changes to the distribution list membership cannot be saved" - Part 2

noreply@blogger.com (Nuno Mota) — Sat, 29 Oct 2011 09:56:00 +0000

One of my first posts was regarding Distribution Groups Managers, how they work and how to set them up both through Active Directory and through PowerShell.

Recently, I wrote another post regarding the “Changes to the distribution list membership cannot be saved” error that Exchange 2010 users might receive when trying to manage Distribution Lists (DLs).

In this new post, again about DLs, I will talk about another scenario where users are not able to manage their DLs even if you followed the instructions on the previous two posts and if you transitioned from an Exchange 2003 environment.

If you still have users experiencing the following error whenever they try to add or remove a member from a DL they manage, check if the DL’s scope is set to Global:

If you can’t remember what the differences are between Group Scopes, here’s a quick (and simplified!) overview:

Universal Group: can include accounts, global groups and universal groups from any domain of the same forest. Can be assigned permissions in any domain or forest;
Global Group: can include accounts and global groups from the same domain. Can be assigned permissions in any domain;
Domain Local: can include accounts, global groups and universal groups from the any domain (can also include other Domain Local groups but only from the same domain). Can be assigned permissions only in same domain.

If you look in the EMC, these DLs will most probably be greyed out and showing as Mail Non-Universal Group, which are not supported by Exchange 2010, thus causing the problem...

E-mails are still delivered to their members but you will not be able to manage or change them.

To check the Group Scope, the easier way is to use AD Users and Computers. In the following picture we can see that the DL HP-SSL-VPN is a Global DL:

To fix this issue, all you have to do is convert these DLs to Universal. You can easily do this using the EMC by sorting your DLs by Recipient Type Details, selecting the DLs you want to convert (you can select/convert multiple at a time!) and then clicking in Convert to Universal Group:

Alternatively, you can use PowerShell with the following cmdlet:

Import-Module ActiveDirectory
Get-ADGroup -Filter {(mail -like "*") -and (GroupScope -eq "Global")} | Set-ADGroup -GroupScope Universal -WhatIf

WARNING: Just make sure you want to convert all of them or update the cmdlet to only convert the ones you want to!

Exchange Server 2003

In the beginning of this post I mentioned that this might happen if you transitioned from Exchange 2003. This is because Exchange 2003 used different DL types.

To check the version of a DL, run the following cmdlet in the EMS:

Get-DistributionGroup HP-SSL-VPN | Select Name, ExchangeVersion

Name                   ExchangeVersion
----                   ---------------
HP-SSL-VPN             0.0 (6.5.6500.0)

From the output, we can see that the Exchange version of this DL is 6.5 (Exchange 2003).

You can use the same command to see the versions of all the DLs in your environment to check exactly how many you have that are still 2003 or, possibly, 2007:

Get-DistributionGroup | Select Name, ExchangeVersion | Sort ExchangeVersion

Or if you want to group and count them:

Get-DistributionGroup | Group ExchangeVersion

Count   Name
-----   ----
  207   0.0 (6.5.6500.0)
   12   0.10 (14.0.100.0)
   45   0.1 (8.0.535.0)

For these ones, if you try to add a Manager to it, you will get the following warning:

If you click Yes, Exchange will automatically convert the DL to Exchange 2010 so you can edit it.

The easiest way to convert all your DLs from Exchange 2003/2007 to Exchange 2010 is by using the 2010 EMS and simply running the following cmdlet:

Get-DistributionGroup | Set-DistributionGroup

Which will ask you the following:

To save changes on object "HP-SSL-VPN", the object must be upgraded to the current Exchange version. After the upgrade, this object cannot be managed by an earlier version of the Exchange Management Tools. Do you want to continue to upgrade and save the object?

Hope this helps!

Exchange 2010 Calendar Repair Assistant Behaviour (Part 2)

noreply@blogger.com (Nuno Mota) — Mon, 10 Oct 2011 14:55:00 +0000

In my previous post Exchange 2010 Calendar Repair Assistant Behaviour I discussed some of the behaviour of the new Calendar Repair Assistant [CRA] functionality of Exchange 2010. Namely, I mentioned the following issue:

“An attendee accepted the organizer's meeting request or recurring meeting request, but the meeting isn't on the attendee's calendar.

The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response. If the assistant can't determine that the meeting item was intentionally deleted by the attendee, the assistant creates the meeting request again. If the assistant determines that the attendee intentionally deleted the meeting request, no further action is taken.”

Note that is says “The assistant checks the attendee's record in the mailbox database and finds that the attendee deleted the calendar item without sending a response”. However, in all my tests, I deleted the appointments after accepting them, and Exchange always puts them back... So, not sure how it detects if the appointment was “intentionally deleted by the attendee”...

What I forgot to mentioned is that this happened with Outlook 2007. When I tested the exact same scenario with Outlook 2010 and OWA 2010, this didn’t happen! Which means that the assistant does indeed check if the attendee deleted the appointment on purpose or not. :)

So why does it work for Outlook 2010 and OWA 2010 but not for Outlook 2007? We all know Outlook 2010 has better integration with Exchange 2010, but I wanted to know. To try to find out why, I turned to MFCMapi and compared two appointments: one deleted in Outlook 2007 and one deleted in OWA 2010 (both without sending a notification to the organiser).

Besides some obvious differences in some properties such as subject, times, etc., here is the big difference (look at the value tags):

Outlook 2007

<NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>

<NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>

</property>

OWA 2010

<NamedPropGUID>{11000E07-B51B-40D6-AF21-CAA85EDAB1D0} = PSETID_CalendarAssistant</NamedPropGUID>

<NamedPropName>id: 0x0015=21 = PidLidClientIntent, dispidClientIntent</NamedPropName>

</property>

The PidLidClientIntent property indicates what actions the user has taken on a Meeting object.

According to the MSDN website 2.2.2.4 PidLidClientIntentProperty a value of 0x20 (32 in decimal or 0010 0000 in binary) means that the ciDeletedWithNoResponse property is set which proves the user deleted the Meeting object with no response sent to the organiser.

So basically, OWA 2010 and Outlook 2010 set the PidLidClientIntent property correctly and, as such, the CRA knows that the user deleted the appointment on purpose and doesn’t put it back.

Because Outlook 2007 doesn’t set this property to 0x20, CRA doesn’t know the user deleted the appointment, thinks it’s missing for some other reason and puts it back in the calendar!

Now the question: is there or will there be an update to rectify this for Outlook 2007?

I’m running version 12.0.6550.5003 SP2 with the update KB2412171 to have access to my Exchange Archive.

For more information:

Outlook 2007 Update for Exchange 2010 Personal Archive Support

noreply@blogger.com (Nuno Mota) — Thu, 06 Oct 2011 13:00:00 +0000

I have used Outlook 2010 to play around with Exchange 2010 Personal Archives but never Outlook 2007.

As most of you know, Outlook 2007 doesn’t support these by default. However, an update released last January (KB2412171) brings archives to Outlook 2007! However, not completely so support is limited...

After you download and install the update (you don’t need to restart you PC, just close and reopen Outlook), your archive will appear automatically (please see note below) and you will be able to do the following:

Copy/move messages between your primary mailbox and your archive;
Copy/move messages between any PST open in Outlook and your archive.

NOTE: if you have full access permissions to another mailbox or archive, these will automatically show up in your Outlook view! This is known as auto-mapping in Outlook 2010 and uses the msExchDelegateListLink AD attribute together with AutoDiscover to achieve this.

However, here’s what you will not be able to do:

Search across your primary and archive mailboxes at once, only separately;
Use Personal Tags to override Retention and Archiving Policies set up, if any, on your Exchange 2010 environment.

As this update is now somewhat old, I was expecting for these 2 issues to have been already addressed in another hotfix. However, I was unable to find anything related to this... So, as far as I know, this is still the latest functionality available for Outlook 2007 users.

Don’t forget that the archive is only accessible when you are connected to Exchange as it is never cached locally even when on cached mode.

Changes to the distribution list membership cannot be saved

noreply@blogger.com (Nuno Mota) — Tue, 27 Sep 2011 10:27:00 +0000

If you are in the middle of a migration from Exchange 2003/2007 to Exchange 2010 (or already finished) and your users are complaining that they can no longer manage distribution lists they own, please note that this is RBAC working as expected.

I will not go through the explanation of why and all the steps involved to fix it as that would be rewriting this excellent post: How to Manage Groups that I already own in Exchange 2010?

Just be aware of this before you actually start migrating users across!

Exchange 2010 Calendar Repair Assistant Behaviour

noreply@blogger.com (Nuno Mota) — Thu, 22 Sep 2011 09:29:00 +0000

After enabling the new Calendar Repair Assistant (CRA) in Exchange 2010, I got a complaint from a user saying items were being re-created on her calendar.

After some troubleshooting and a few tests, I realised that when a user accepts a meeting request and later on deletes it without sending an update, Exchange will put it back in the calendar. This is by design and as expected. According to Understanding Calendar Repair, one of the conflicts the CRA fixes is:

“An attendee accepted the organizer's meeting request or recurring meeting request, but the meeting isn't on the attendee's calendar.

After I deleted the appointment test03 – delete future recur meeting, Exchange put it back in my calendar the following day (I have CRA scheduled to run every night for all servers and users) and I received the following e-mail:

If we have a look at the CRA log for this instance:

<Description>Checks whether the counterpart user can be validated or not.</Description>

</ConsistencyCheck>

<Description>Calls Validate() on the base calendar item.</Description>

</ConsistencyCheck>

<Description>Checkes whether the item can be found in the owner's calendar or not.</Description>

<Description>Could not find the matching meeting in attendee's calendar. Error: [21/09/2011 05:00:51(UTC)] FindMatchingItem: Could not find calendar item, exception = Microsoft.Exchange.Data.Storage.OccurrenceNotFoundException. </Description>

</Inconsistency>

</Inconsistencies>

</ConsistencyCheck>

</ConsistencyChecks>

<RUMs>

<Flags>

<Flag>MissingItem</Flag>

</Flags>

</RUM>

</RUMs>

</Attendee>

</Attendees>

</Meeting>

We can see all the tests CRA performs in between <ConsistencyChecks> and what it checks for (I have included some more that weren’t part of this check but that CRA normally checks as well):

CanValidateOwnerCheck - Checks whether the counterpart user can be validated or not;
ValidateStoreObjectCheck - Calls Validate() on the base calendar item;
MeetingExistenceCheck - Checke whether the item can be found in the owner's calendar or not;
MeetingCancellationCheck - Checks to make sure that the meeting cancellations statuses match;
TimeZoneMatchCheck - Checks to make sure that the attendee has correct recurring time zone information with the organizer;
MeetingPropertiesMatchCheck - Checks to make sure that the attendee has the correct critical properties for the meeting;
RecurrenceBlobsConsistentCheck - Checks to make sure that the recurrence blobs are internally consistent;
RecurrencesMatchCheck - Checks to make sure that the attendee has the correct recurrence pattern.

From the <Inconsistencies> section, we can see why Exchange put it back in my calendar:

</Inconsistency>

Basically Exchange detected the meeting in the organizer’s calendar and that I had previously accepted it but it wasn’t in my calendar (because I deleted it without sending a notification)!

If, however, I had rejected it afterwards (or deleted and sent a notification) the organizer would have received a cancellation from me and Exchange wouldn’t check my calendar for that meeting.

To summarise, when a user receives an appointment and:

rejects it – Exchange doesn’t put it back;
accepts it, later on declines it - Exchange doesn’t put it back;
accepts it, later on deletes it and sends an update - Exchange doesn’t put it back;
accepts it, later on deletes it and doesn’t send an update - Exchange puts it back.

Update: Please check Part 2 regarding this last issue!

Hope this helps!

Exchange Server 2010 SP1 Help

noreply@blogger.com (Nuno Mota) — Wed, 14 Sep 2011 19:17:00 +0000

A new version of the Exchange Server 2010 SP1 Help chm file has just been released last week!

Follow this link to download it.

OWA 2010 cannot open 2007 mailbox

noreply@blogger.com (Nuno Mota) — Sun, 04 Sep 2011 15:45:00 +0000

As you know, as long as you have the proper permissions you can access another users’ mailbox using OWA.

However, if you are in the middle of a migration from Exchange 2007 to 2010 and you have deployed Update Rollup 1 for Exchange 2007 Service Pack 3 you will find that a user in 2010 cannot open a 2007 mailbox even though he/she has Full Access permissions to it...

When I login to OWA using my Nuno account (in 2010) and try to open the Mota mailbox (in 2007) I get the following error:

This is because Rollup 1 introduces the following “fix”:

976100 - Shared calendar items are shown incorrectly in the server time zone instead of the time zone of an Exchange Server 2007 user who is accessing the shared calendar

“Consider the following scenario:

• User A and User B are Exchange Server 2007 users;

• User B shares a calendar with User A;

• User B grants User A read access permission to the calendar;

• User A accesses the shared calendar of User B by using Outlook Web Access (OWA).

In this scenario, the shared calendar items are shown in the time zone of the server instead of the time zone of User A. However, if User A has full access permission to the shared calendar of User B, the calendar items are shown in the time zone of User A.

This problem occurs because the time zone information is stored in a configuration message that is in the root of the mailbox. A user who does not have full access permission to a shared calendar, cannot access the time zone information. Therefore, the server time zone is used.”

After this Rollup is installed, you can control the time zone at the Organization level by running the Set-OrganizationalSetting cmdlet together with the SharedCalendarTimeZone parameter. Principal, Delegate and UserConfigured are the three values for the SharedCalendarTimeZone parameter which, by default, is set to UserConfigured.

If the parameter value is set to Principal, the time zone is shown in the principal’s time zone. If set to Delegate, the time zone is shown in the Delegate’s time zone. If set to UserConfigured, the user can follow these steps to change the time zone to the delegate’s time zone or to the principal’s time zone:

• Log on to OWA, and navigate to the Options page;

• Check the default value for the shared calendar time zone;

• Select the value for the "When viewing a shared calendar, show items in:" drop-down list to Delegate Time Zone or to Principal Time Zone.

Note: when you configure the SharedCalendarTimeZone parameter to either Principal or to Delegate by using the Set-OrganizationalSetting cmdlet, the option to configure the time zone in OWA is disabled.

Resolution

To fix this issue, all you have to do is run the following command from a 2007 server to set the SharedCalendarTimeZone to Principal (which is the only option that fixes this issue):

Set-OrganizationalSetting –SharedCalendarTimeZone Principal

Note: Please test this change before deploying it to your live environment as it might confuse users if they are spread across different time zones!

Hope this helps!

550 5.7.1 Submission has been disabled for this account

noreply@blogger.com (Nuno Mota) — Sat, 03 Sep 2011 16:16:00 +0000

If you are migrating from Exchange 2007 to Exchange 2010 and 2007 users are getting the following error when e-mailing 2010 users:
The following recipient(s) could not be reached:
Nuno
(…)
nuno@letsexchange.com
HTCAS1.letsexchange.com #550 5.7.1 Submission has been disabled for this account # #
(…)

and you see the same error on the 2007 Transport Logs for that e-mail:
Source: SMTP
EventID: FAIL
Recipients: {nuno@letsexchange.com}
RecipientStatus: {550 5.7.1 Submission has been disabled for this account}
(...)

be aware that this is (most likely) due to a bug (not confirmed with Microsoft) with Exchange 2010...

If your 2007 users have the following set for their mailboxes:
UseDatabaseQuotaDefaults: True
ProhibitSendReceiveQuota: 0KB
ProhibitSendQuota: 0KB

This is what’s causing the issue! Although they are still able to e-mail 2003 and 2007 users, they can’t send e-mails to 2010 users due to the way Exchange 2010 checks the user’s quotas, even though they are set to use the database defaults!...

To check if this has already happened to any of your users, run the following command to check your transport logs for the error message mentioned before:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "01/09/2011" -EventID FAIL | ? {$_.RecipientStatus -match "550 5.7.1 Submission"} | Select *, {$_.Recipients}, {$_.RecipientStatus} | Export-Csv D:\Nuno\550.csv -NoTypeInformation

To see if you have any users with 0KB quotas:

Get-Mailbox -ResultSize Unlimited -Filter {UseDatabaseQuotaDefaults -eq $True} | ? {$_.ProhibitSendReceiveQuota -eq 0KB -or $_.ProhibitSendQuota -eq 0KB} | Select Alias, ProhibitSendReceiveQuota, ProhibitSendQuota, UseDatabaseQuotaDefaults

and to correct them, run the following:

Get-Mailbox -ResultSize Unlimited -Filter {UseDatabaseQuotaDefaults -eq $True} | ? {$_.ProhibitSendReceiveQuota -eq 0KB -or $_.ProhibitSendQuota -eq 0KB} | Set-Mailbox -ProhibitSendQuota unlimited -ProhibitSendReceiveQuota unlimited

Note: 2010 users with 0KB quotas and using the database quota defaults are still able to e-mail 2010 and 2007 users!

Hope this helps!

“Insufficient access rights to perform the operation error” when moving mailbox to Exchange 2010

noreply@blogger.com (Nuno Mota) — Sat, 03 Sep 2011 16:06:00 +0000

When moving mailboxes to Exchange 2010, you might come across the following error:

Or when using the EMS, you might find some move operations with a state of Failed or Queued for hours.

When you try to suspend/resume these queued move requests, you get a similar error:

[PS] C:\>Resume-MoveRequest "Nuno Mota"

Active Directory operation failed on dc1.letsexchange.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.

Active directory response: 00002098: SecErr: DSID-03150A48, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

+ CategoryInfo : NotSpecified: (0:Int32) [Resume-MoveRequest], ADOperationException

+ FullyQualifiedErrorId : 2851DFD3,Microsoft.Exchange.Management.RecipientTasks.ResumeMoveRequest

Since Exchange 2000 every version of Exchange has a massive dependency on Active Directory. What is happening here is that whenever a move request is issued, the Mailbox Replication Service (MRS) needs to update several attributes in the user object. These attributes are used by the MRS to keep track and report the progress of the move. Using ADSIEdit you can see all these attributes under msExchMailboxMove*:

msExchMailboxMoveBatchName

msExchMailboxMoveFlag

msExchMailboxMoveRemoteHostName

msExchMailboxMoveSourceMDBLink

msExchMailboxMoveStatus

msExchMailboxMoveTargetMDBLink

These attributes are populated when the move request is issued and cleared when the move request is deleted with the Remove-MoveRequest cmdlet (or from the EMC). Because the MRS needs to be able to update these AD fields, the move will fail if it can’t. And this is what is happening here.

So, all you have to do is fix the permissions for the affected user. To do this:

1. go to Active Directory Users and Computers

2. click on View and select Advanced Features (so you have access to the Security tab of AD objects)

3. find the affected user, right-click on it and go to Properties

4. Select the Security tab and then click on Advanced

5. Tick the Include inheritable permissions from this object’s parent box

6. Click OK

This should fix it! You can now suspend/resume the Queued move request or issue a new move request if the first one failed.

This seems to only affect highly privileged user objects that were created before the deployment of Exchange 2010. But why? Exchange 2010 system components are granted access to AD through the Exchange Trusted Subsystem, which has privileged and powerful access to AD. However, it can’t deal with cases where the Access Control Entries (ACEs) that Exchange depends on are not stamped into user objects. In these situations, any attempt by Exchange to update the object is declined by AD, like the problem with the Move Request.

Hope this helps!

Office 365 Diagnostic and Logging with ADFS

noreply@blogger.com (Nuno Mota) — Fri, 26 Aug 2011 12:11:00 +0000

With the recent release of Office 365, the Microsoft Office Services Diagnostics and Logging (MOSDAL) tool has also been updated to provide ADFS authentication diagnostic information.

So if you are experiencing issues with Office 365 / ADFS, give it a go!

Monitor Databases in DAGs

noreply@blogger.com (Nuno Mota) — Thu, 18 Aug 2011 12:58:00 +0000

A few days ago, someone at the Microsoft Forums asked if there was a script to alert an administrator of when Exchange performs a failover of databases in a DAG.

This was something that I have wanted to do for a long time, but never actually got to do it... So here is my current solution (might get improved in the future).

With Exchange 2010 and DAGs, it is important to monitor whenever a database automatic fails over to another server. Although everything keeps working without any problems for end users (hopefully), administrators still have to investigate why a failover happened.

In case you have Exchange deployed across multiple AD sites and a database fails over to a server on another site, this will probably impact the way your users access OWA, for example.

Databases in a DAG, and therefore with multiple copies, have the ActivationPreference attribute that shows which servers have preference over the others to mount the database in case of a disaster or a manual switchover.

The following output is just an example of what you will get if you run the following command in an environment with at least a DAG and multiple copies:

Get-MailboxDatabase | Sort Name | Select Name, ActivationPreference

Name ActivationPreference

---- --------------------

ADB1 {[MBXA1, 1], [MBXA2, 2]}

ADB2 {[MBXA1, 1], [MBXA2, 2]}

ADB3 {[MBXA1, 1], [MBXA2, 2]}

...

MDB1 {[MBX1, 1], [MBX2, 2], [MBX3, 3], [MBX4, 4]}

MDB2 {[MBX1, 1], [MBX2, 2], [MBX3, 3], [MBX4, 4]}

MDB3 {[MBX1, 1], [MBX2, 2], [MBX3, 3], [MBX4, 4]}

...

Based on the ActivationPreference attribute, we can monitor if databases are currently active on the servers that they should be, i.e., on servers with an ActivationPreference of 1.

To check this, we can use the following script:


Get-MailboxDatabase | Sort Name | ForEach {
 $db = $_.Name
 $curServer = $_.Server.Name
 $ownServer = $_.ActivationPreference | ? {$_.Value -eq 1}

 Write-Host "$db on $curServer should be on $($ownServer.Key) - " -NoNewLine

 If ($curServer -ne $ownServer.Key)
 {
  Write-Host "WRONG" -ForegroundColor Red
 }
 Else
 {
  Write-Host "OK" -ForegroundColor Green
 }
}

Which basically compares the server where the database is currently active with the server that has an ActivationPreference of 1. If they differ, then write WRONG in red to let the administrator know.

But since we are at it, why not also check for the status of the database and the state of its content index? This can be checked using the Get-MailboxDatabaseCopyStatus cmdlet.

According to the Monitoring High Availability and Site Resilience TechNet article, here are all the possible values for the database copy status:

Database Copy Status

Failed - The mailbox database copy is in a Failed state because it isn't suspended, and it isn't able to copy or replay log files. While in a Failed state and not suspended, the system will periodically check whether the problem that caused the copy status to change to Failed has been resolved. After the system has detected that the problem is resolved, and barring no other issues, the copy status will automatically change to Healthy;

Seeding - The mailbox database copy is being seeded, the content index for the mailbox database copy is being seeded, or both are being seeded. Upon successful completion of seeding, the copy status should change to Initializing;

SeedingSource - The mailbox database copy is being used as a source for a database copy seeding operation;

Suspended - The mailbox database copy is in a Suspended state as a result of an administrator manually suspending the database copy by running the Suspend-MailboxDatabaseCopy cmdlet;

Healthy - The mailbox database copy is successfully copying and replaying log files, or it has successfully copied and replayed all available log files;

ServiceDown - The Microsoft Exchange Replication service isn't available or running on the server that hosts the mailbox database copy;

Initializing - The mailbox database copy will be in an Initializing state when a database copy has been created, when the Microsoft Exchange Replication service is starting or has just been started, and during transitions from Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite, or Disconnected to another state. While in this state, the system is verifying that the database and log stream are in a consistent state. In most cases, the copy status will remain in the Initializing state for about 15 seconds, but in all cases, it should generally not be in this state for longer than 30 seconds;

Resynchronizing - The mailbox database copy and its log files are being compared with the active copy of the database to check for any divergence between the two copies. The copy status will remain in this state until any divergence is detected and resolved;

Mounted - The active copy is online and accepting client connections. Only the active copy of the mailbox database copy can have a copy status of Mounted;

Dismounted - The active copy is offline and not accepting client connections. Only the active copy of the mailbox database copy can have a copy status of Dismounted;

Mounting - The active copy is coming online and not yet accepting client connections. Only the active copy of the mailbox database copy can have a copy status of Mounting;

Dismounting - The active copy is going offline and terminating client connections. Only the active copy of the mailbox database copy can have a copy status of Dismounting;

DisconnectedAndHealthy - The mailbox database copy is no longer connected to the active database copy, and it was in the Healthy state when the loss of connection occurred. This state represents the database copy with respect to connectivity to its source database copy. It may be reported during DAG network failures between the source copy and the target database copy;

DisconnectedAndResynchronizing - The mailbox database copy is no longer connected to the active database copy, and it was in the Resynchronizing state when the loss of connection occurred. This state represents the database copy with respect to connectivity to its source database copy. It may be reported during DAG network failures between the source copy and the target database copy;

FailedAndSuspended - The Failed and Suspended states have been set simultaneously by the system because a failure was detected, and because resolution of the failure explicitly requires administrator intervention. An example is if the system detects unrecoverable divergence between the active mailbox database and a database copy. Unlike the Failed state, the system won't periodically check whether the problem has been resolved, and automatically recover. Instead, an administrator must intervene to resolve the underlying cause of the failure before the database copy can be transitioned to a healthy state;

SinglePageRestore - This state indicates that a single page restore operation is occurring on the mailbox database copy;

Based on these values, we want the Status attribute to be either Mounted (true for the server where the database is mounted) or Healthy (for the servers that hold a copy of it). For the ContentIndexState attribute, we want it to be always Healthy.

To monitor both these attribute, we can use the following command:


Get-MailboxDatabase | Sort Name | Get-MailboxDatabaseCopyStatus | ForEach {
 If ($_.Status -notmatch "Mounted" -and $_.Status -notmatch "Healthy" -or $_.ContentIndexState -notmatch "Healthy")
 {
  Write-Host "`n$($_.Name) - Status: $($_.Status) - Index: $($_.ContentIndexState)" -ForegroundColor Red
 }
}

Now, let’s put everything together and tell the script that if something is wrong with any database, to send an e-mail to the administrator! This way, we can create a schedule task to run this script every 2 minutes, for example.

Let’s also compare the AD sites where the current server hosting the database is against the AD site where the server that should be hosting the database is. As I mentioned before, this is important as it can change the way users access OWA.

You can also download the entire script from here.

Function getExchangeServerADSite ([String] $excServer)
{
 # We could use WMI to check for the domain, but I think this method is better
 # Get-WmiObject Win32_NTDomain -ComputerName $excServer

 $configNC =([ADSI]"LDAP://RootDse").configurationNamingContext
 $search = new-object DirectoryServices.DirectorySearcher([ADSI]"LDAP://$configNC")
 $search.Filter = "(&(objectClass=msExchExchangeServer)(name=$excServer))"
 $search.PageSize = 1000
 [Void] $search.PropertiesToLoad.Add("msExchServerSite")

 Try {
  $adSite = [String] ($search.FindOne()).Properties.Item("msExchServerSite")
  Return ($adSite.Split(",")[0]).Substring(3)
 } Catch {
  Return $null
 }
}



[Bool] $bolFailover = $False
[String] $errMessage = $null

Get-MailboxDatabase | Sort Name | ForEach {
 $db = $_.Name
 $curServer = $_.Server.Name
 $ownServer = $_.ActivationPreference | ? {$_.Value -eq 1}

 # Compare the server where the DB is currently active to the server where it should be
 If ($curServer -ne $ownServer.Key)
 {
  # Compare the AD sites of both servers
  $siteCur = getExchangeServerADSite $curServer
  $siteOwn = getExchangeServerADSite $ownServer.Key
  
  If ($siteCur -ne $null -and $siteOwn -ne $null -and $siteCur -ne $siteOwn)
  {
   $errMessage += "`n$db on $curServer should be on $($ownServer.Key) (DIFFERENT AD SITE: $siteCur)!" 
  }
  Else
  {
   $errMessage += "`n$db on $curServer should be on $($ownServer.Key)!"
  }

  $bolFailover = $True
 }
}

$errMessage += "`n`n"

Get-MailboxDatabase | Sort Name | Get-MailboxDatabaseCopyStatus | ForEach {
 If ($_.Status -notmatch "Mounted" -and $_.Status -notmatch "Healthy" -or $_.ContentIndexState -notmatch "Healthy")
 {
  $errMessage += "`n$($_.Name) - Status: $($_.Status) - Index: $($_.ContentIndexState)"
  $bolFailover = $True
 }
}

If ($bolFailover)
{
 Send-MailMessage -From "admin_nuno@letsexchange.com -To "exchange.alerts@letsexchange.com" -Subject "DAG NOT Healthy!" -Body $errMessage -Priority High -SMTPserver "mail.letsexchange.com"
 Schtasks.exe /Change /TN "MonitorDAG" /DISABLE
}

As always, sorry for the format of the code...

At the end of the script, if an e-mail is sent, you might want to disable the schedule task, otherwise you will receive an e-mail every two minutes until you resolve the issue...

Please note that there are more attributes that can and should be monitored! For example, you could run the Test-ReplicationHealth to view replication status information about mailbox database copies.

Hope this helps!

Publishing Exchange 2010 with UAG and TMG

noreply@blogger.com (Nuno Mota) — Fri, 12 Aug 2011 12:48:00 +0000

If you are experiencing issues regarding publishing Exchange with Unified Access Gateway / Threat Management Gateway or simply want to learn how to do it, check out the white paper from Greg Taylor.

It has information and guidance on publishing Exchange 2010 using Forefront UAG and TMG, how to choose between UAG and TMG for different scenarios as well as steps on how to configure them products in order to publish Exchange 2010.

You can download it here.

Concurrent Mailbox Moves in Exchange 2010

noreply@blogger.com (Nuno Mota) — Wed, 03 Aug 2011 22:07:00 +0000

Have you ever tried to do a migration from Exchange 2007 to 2010 only to find Exchange seems to move only 2 or 5 mailboxes at a time? And where is the so useful –MaxThreads parameter we used with the Move-Mailbox command?!

With Exchange 2010, this changed... Without going into detail regarding the great asynchronous moves and the Microsoft Exchange Mailbox Replication service (responsible for moving mailboxes, importing/exporting .pst files and restoring disabled and soft-deleted mailboxes) here’s how you can increase the number of concurrent moves.

Because the MRS is responsible for all these tasks, it is throttled by default. The only way to tweak it is by manually editing the MSExchangeMailboxReplication.exe.config file, located on all CAS servers in the same folder where Exchange is installed: \Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config.

In this file, navigate to the MRSConfiguration section. In here you can edit the following properties:

MaxRetries - This property specifies the maximum number of times MRS will attempt to perform a task after encountering a transient failure. You can specify a value from 0 through 1000. The default value is 60.

MaxCleanupRetries - This property specifies the number of times that MRS should attempt to clean up a task. If the maximum number of attempts is reached, the task fails. You can specify a value from 0 through 100. The default value is 5.

MaxStallRetryPeriod - This property specifies the maximum duration for which MRS pauses while waiting for the Microsoft Exchange Information Store service to bring the target mailbox database into compliance with its configured data redundancy constraints. If the Microsoft Exchange Information Store service reports that the mailbox database is unhealthy, MRS will pause. If the maximum time is reached, the task fails. You can specify a value from 00:00:10 (10 seconds) through 05:00:00 (5 hours). The default value is 00:15:00 (15 minutes).

RetryDelay - This property specifies the amount of time MRS will wait before it attempts to perform a task again after a transient failure. You can specify a value from 00:00:10 (10 seconds) through 00:30:00 (30 minutes). The default value is 00:00:30 (30 seconds).

MaxMoveHistoryLength - This property specifies the maximum number of move histories to maintain in the mailbox. You can specify a value from 0 through 100. The default value is 2 move histories per mailbox.

MaxActiveMovesPerSourceMDB - This property specifies the total number of tasks MRS can perform that involve the mailbox database as a data source. Types of tasks include moving mailboxes located on the database, exporting mailbox data from mailboxes located on the database, and restoring mailbox data from the database. You can specify a value from 0 through 100. The default value is 5 concurrent tasks.

MaxActiveMovesPerTargetMDB - This property specifies the total number of tasks MRS can perform that involve the mailbox database as a data target. Types of tasks include moving mailboxes to the database, importing mailbox data into a mailbox located on the database, and restoring mailbox data to a mailbox located on the database. You can specify a value from 0 through 100. The default value is 2 concurrent tasks.

MaxActiveMovesPerSourceServer - This property specifies the total number of tasks MRS can perform that include the server as a data source. You can specify a value from 0 through 1000. The default value is 50 concurrent moves.

MaxActiveMovesPerTargetServer - This property specifies the total number of tasks MRS can perform that involve the server as a data target. You can specify a value from 0 through 1000. The default value is 5 concurrent moves.

MaxTotalMovesPerMRS - This property specifies the total number of tasks that a single instance of MRS can perform at a time. You can specify a value from 0 through 1024. The default value is 100 concurrent moves.

FullScanMoveJobsPollingPeriod - This property specifies how often each instance of MRS scans for new tasks. You can specify a value from 00:03:00 (3 minutes) through 1.00:00:00 (1 day). The default value is 00:10:00 (10 minutes).

As you can see from this list, there are 5 attributes that control the way mailbox moves happen:

- MaxActiveMovesPerSourceMDB

- MaxActiveMovesPerTargetMDB

- MaxActiveMovesPerSourceServer

- MaxActiveMovesPerTargetServer

- MaxTotalMovesPerMRS

So, depending on your environment, you will probably have to increase some of these. For example, if you’re moving 100 users from a single database to 10 different databases in one server, you will probably want to set the following (assuming you want to move 10 users at a time):

- MaxActiveMovesPerSourceMDB - 10

- MaxActiveMovesPerTargetMDB - 5 (just in case)

- MaxActiveMovesPerTargetServer - 10

If you have multiple 2010 CAS servers, just make sure any changes you make are also applied to the MSExchangeMailboxReplication.exe.config file on all of them.