1. Set the Powershell Format enumeration limit to unlimited (to ensure no attribute values are cut off) $formatenumerationlimit = -1 For those not familiar, the Exchange Management Shell has an enumeration limit which can result in some values being cut off, which is evidenced by the trailing …) at the end of a value.
2. Get-RemoteMailbox “user identity” | fl This is so you have a record of all current attributes. If you want to save it to a text file or CSV or something else, knock yourself out.
3. Disable-RemoteMailbox This will remove all Exchange attributes (including Archive guid)
4. Run Dirsync delta sync from your AAD Connect server Start-ADSyncSyncCycle -PolicyType delta This will sync and remove the Exchange Online Mailuser
5. Enable-RemoteMailbox “user identity” -RemoteRoutingAddress user@contoso.mail.onmicrosoft.com This will set the remote recipient flags to "ProvisionMailbox" and the Exchange Guid will be blank (all 0's)
6. Run Dirsync delta sync. Start-ADSyncSyncCycle -PolicyType delta Since the Exchange guid is no longer populated, as long as the Exchange Online license is assigned a new mailbox will be provisioned. HALLELUJAH!
7. Optionally, provision an Archive mailbox Enable-RemoteMailbox "user identity" -Archive *Note* - if a previous archive guid was present, and the archive mailbox still somehow exists, you may see a provisioning error referencing not being able to disable the old archive guid. If you encounter this error, you can try setting the archive guid on the remote mailbox to the old one. The validation error can be exposed to you in PowerShell by running the following command from MSOL PowerShell (Get-MsolUser -UserPrincipalName upnofuser).errors.errordetail.objecterrors.errorrecord.errordescription If there is a validation error, and it is the archive, it will show you the new archive guid and the old one.
8. Set-RemoteMailbox “user identity” -ArchiveGuid “old archive guid”After confirming that the Exchange Online mailbox is successfully provisioned, you can stamp the Exchange Guid on the on-premises Remote mailbox object. This is really only required if you think you might have to Offboard the mailbox back to On-Premises, but I like to set it for the sake of being consistent.
9. Set-RemoteMailbox “user identity” -ExchangeGuid “Exchange guid value from new Exchange Online mailbox”
10. Re-stamp any attributes that were previously stamped, such as custom attributes, or additional email addresses (compare with the Get-RemoteMailbox from step 2)

Starting with RTM and up through CU5, managing System Workload Management settings were available via the following cmdlets

*-ResourcePolicy
*-WorkloadManagementPolicy
*-WorkloadPolicy

WorkloadPolicy defined the classifications for various different workloads. Examples of Classifications include InternalMaintenance, CustomerExpectation, Discretionary and Urgent.

ResourcePolicy defined the Thresholds for the various classifications upon which those workload types would begin to be throttled (micro-delayed).

WorkloadManagementPolicy simply links the two together.

However, starting with CU6, these cmdlets disappeared, and the TechNet links were removed and replaced with this simple statement found here

Note:

The *-ResourcePolicy, *-WorkloadManagementPolicy and *-WorkloadPolicy system workload management cmdlets have been deprecated. System workload management settings should be customized only under the direction of Microsoft Customer Service and Support.

That is all fine and good (after all, I work in CSS!). But for a while, even I didn’t know how to view what the current settings were!!!

Alas – nothing (well, ALMOST nothing) can remain hidden forever. And so I found that the System workload management settings are now visible by using Get-ExchangeDiagnosticInfo. Now I do want to add a caveat here that this blog post will not provide information on how to modify System Workload Policies. However, I felt like it was important to be able to view what the current settings are so that you can understand why certain workloads might end up getting throttled.

If you haven’t already had the pleasure of using Get-ExchangeDiagnosticInfo, there is a lot of information available. I won’t delve in to everything that can be retrieved, but rather will focus on the System Workload policy-related information.

The general syntax to view System Workload policy information is

Get-ExchangeDiagnosticInfo –server <server> -process MSExchangeMailboxAssistants –Component SystemWorkloadManager –Argument policy

However – you will probably notice that the output from this cmdlet is XML format, which is, well, ugly to read. Lets clean it up a little, shall we? Define a variable for your command, and specify the format as XML so Powershell can format it.

[xml]$diag = Get-ExchangeDiagnosticInfo –server <server> -process MSExchangeMailboxAssistants –Component SystemWorkloadManager –Argument policy

Now that we have the data stored in memory, we can look at the components. The Policy is actually comprised of several sub-components. Lets look at the Resource policy portion first. This shows the Metric types (core resources that we measure the health of)

$diag.diagnostics.components.systemworkloadmanager.policy.resourcepolicy

Now notice that the ResourcePolicy actually has a property that is multivalued. We can look at that in more detail and see that each metric type has different values for each classification type. This is what allows workloads with a classification of a higher priority to continue working while those with a lower priority are throttled (micro-delayed).

$diag.diagnostics.components.systemworkloadmanager.policy.resourcepolicy.resourcemetricpolicy | ft

Finally, we can view the workload policy, which provides the list of each defined workload type and the respective classification.

$diag.diagnostics.components.systemworkloadmanager.policy.workloadpolicy

Enjoy!

So when the opportunity came up to help explain a strange calendar permissions issue, I of course jumped at the chance!

The issue:
Users were complaining that they were granting "Owner" permissions on their Calendar using Outlook, but then if they viewed permissions in OWA, it was showing as "Limited Details". Huh?!? Confusing, right?

I set up a repro. Lets look at what each one looks like.

First, Powershell. I used the Get-MailboxFolderPermission cmdlet to display the ACL on the Calendar folder. You can see here that Peggy Sue has been granted Owner rights on my Calendar.

This matches up with what displays in Outlook as well.

Now OWA. Remember, both Outlook and Powershell display as Owner.

Hmm. One of these things is not like the others… :-)

The first clue I had that OWA was displaying something different is the "INSIDE ORGANIZATION" text. From previous experience, this is related to Sharing Policies, which define how you can share your calendar with others (both Inside and Outside of your Organization). This clued me in that OWA is not displaying the actual folder permissions (ACL entry). Instead, what is doing is looking at the permissions entries, and attempting to convert that permission to an equivalent Calendar Sharing permission (which is not the same!).

Next, what I found is that related to Sharing, there are only 5 Calendar Sharing permissions that are displayed (whereas the folder permissions have many more!). Those are:

Delegate
Editor
Full Details
Limited Details
Availability Only

The logic for the calendar sharing permission goes something like this.

Analyze the permisssions entry.

Is it Editor?
If the permission is Editor, and View Private Items is set, display as Delegate
If the permission is Editor, and view private items is NOT set, display as Editor

If the permission is Reviewer, display as Full details

Note at this point, we have come to the end of the actual *folder permissions* that we evaluate (I don't count Free/Busy permissions as a real folder permission, because you are only granting rights to view Availability information, which to me isn't the same. You can make an argument that they are still folder permissions, but I don't count them in the same boat as the others). If you review the list of Folder permissions available to add with the Add-MailboxFolderPermission here, you can see that there are a bunch of folder permissions that we don’t look at, including Owner, Author, and Contributor.

Now we move on to Free/Busy permissions, which are calendar-specific.

If the Free/Busy permission is LimitedDetails (Outlook displays as View Free/Busy Time, Subject, location), display as Limited Details

If the Free/Busy permission level is AvailabilityOnly (Outlook displays as Free/Busy time), display as Availability Only.

The net result is that OWA Calendar Sharing Permission does not have an equivalent for some of the permissions on the calendar folder, and it attempts to map it to a sharing permission as best it can. Since Owner (and Author and Contributor for that matter) have write permissions to the calendar, it is defaulting to displaying Limited Details. The following table summarizes the above information.

I hope you find this information helpful.

I wanted to share a recent experience I had that left me stumped for quite some time and which I just recently figured out the cause.

I was working on troubleshooting a problem with a Site Mailbox not being created (Site Mailboxes are that cool feature that combines email storage on Exchange and document library on SharePoint), and so I was trying to get some additional tracing from my lab, and noticed that Site mailboxes weren't getting created in my lab either. Funny, since I've had this lab running for the better part of 2 years, and it has always worked. After fixing a minor issue with the Site Mailbox provisioning which was due to a configuration issue with the autodiscover domain I had previously set up, I got to the point where the mailbox should have been provisioned, but it wasn't. Instead, I was presented with an error page indicating the following

The next thing I noticed was that I also couldn't create a mailbox using the Exchange tools (specifically, I was using the Exchange Management Shell). One never likes to see red come back from a Powershell command, and there it was. The same error as displayed by the attempt to create the Site Mailbox.

A value can't be provided automatically for the "Database" mandatory parameter. Specify an explicit value for the
parameter and try again, or add the Verbose parameter to obtain more information about the failure.
    + CategoryInfo          : NotSpecified: (:) [New-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : [Server=MYSERVER,RequestId=b37c727e-3473-4223-b9c3-32483c927aa3,TimeStamp=DateTime
  ] [FailureCategory=Cmdlet-RecipientTaskException] 50FA30F,Microsoft.Exchange.Management.RecipientTasks.NewMail
  box
    + PSComputerName        : myserver.mylab.com

My first thought was - oh great, maybe I'm running out of space, and the databases have the flag set to exclude from provisioning. That would totally make sense, right? See, starting with Exchange 2010, you didn't have to specify a mailbox database when you create a mailbox. Exchange would automatically select one for you. For mailboxes created with the Exchange management tools (EMC or EMS for 2010, EAC or EMS for 2013), you still have the option to specify a database if you wish, but for Site Mailboxes, this functionality is required because you have no way to specify a database when the mailbox is requested to be created from the SharePoint Site. Instead, it relies on the automatic mailbox provisioning.

Well, I checked every database on my servers, and found that none of them had the excluded from provisioning flags set.

Get-MailboxDatabase | fl name, *provision*

Here was the output from one database. The others matched. You can see from this that none of the provisioning flags to exclude the database from automatic provisioning of mailboxes were set to True.

Name                                        : e15db1
IsExcludedFromProvisioning                  : False
IsExcludedFromInitialProvisioning           : False
IsSuspendedFromProvisioning                 : False
IsExcludedFromProvisioningBySpaceMonitoring : False

Bummer! What else could cause this? Maybe the database weren't mounted? That could also cause this. I checked to make sure all the databases were mounted, and they were.

Get-MailboxDatabase -Status | fl name, *mount*

Name                  : e15db1
MountedOnServer       : Myserver
MountAtStartup        : True
Mounted               : True
AutoDatabaseMountDial : GoodAvailability

Again - each database was indeed mounted. Scratch that possibility. Hmm. Where to look next?

At Microsoft, in Support, we have access to some internal tools that are quite helpful. One of these is the Exchange Troubleshooting Assistant (ExTRA). This was first introduced as part of the Best Practices Analyzer family (ExBPA) with Exchange 2007, and although it no longer ships with Exchange 2013, it is still available to install if a Support Engineer needs to collect the diagnostic tracing that it offers. Although ExTRA can be installed and traces captured, the traces are stored in an ETL format, and in order to convert those traces to human readable output, an internal tool must be used.

Sooo...I captured a trace with what I thought would be relevant tags, converted it and reviewed the results. Needless to say, it wasn't very helpful in this case.

I next reviewed some of our source code relating to the particular error message. This was the proverbial needle in the haystack that I needed that led me to the solution.

What was the problem, you ask?

The "Mailbox Resources Management Agent" Cmdlet Extension Agent was disabled. I have no idea how it was disabled, but it was.

Take a look here for an explanation of what Cmdlet Extension Agents do.

http://technet.microsoft.com/en-us/library/dd335054(v=exchg.150).aspx

Specifically,

"in Exchange 2013, the New-Mailbox cmdlet invokes the Mailbox Resources Management agent when the cmdlet runs. If the Database parameter isn't specified, the Mailbox Resources Management agent automatically determines a suitable mailbox database on which to create the new mailbox and inserts that value into the Database parameter."

Aha! That perfectly explains why this wasn't working.

I enabled that cmdlet extension agent, and VOILA! Automatic mailbox provisioning began to work again, and creating the Site Mailbox also worked.

Here I am trying to create a new mail contact.  I tried to keep the parameters I used pretty simple.  By specifying the domain controller as a DC in the remote forest, I ensure that I am talking to that forest when I attempt to create the contact.  I’ve highlighted a few things that stood out to me.

[PS] C:\WINDOWS\system32>New-MailContact -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@mydomain.com –DomainController <Remote Forest DC> -Verbose –OrganizationalUnit <Remote Forest OU>
VERBOSE: New-MailContact : Beginning processing.
VERBOSE: New-MailContact : Searching objects "<Remote Forest OU>" of type "ExchangeOrganizationalUnit" under the root "$null".
VERBOSE: New-MailContact : Previous operation run on domain controller <Remote ForestDC>.
VERBOSE: New-MailContact : Administrator Active Directory session settings are:  View Entire Forest: 'False', Default Scope: ‘<Source Forest>’, Configuration Domain Controller: '<Source Forest DC>',
VERBOSE: New-MailContact : Applying RUS policy to the given recipient "<Remote Forest>/Contacts/Blah Test" with the home domain controller "<Remote Forest DC>".
VERBOSE: New-MailContact : The RUS server that will apply policies on the specified recipient is "<Remote Forest MBX server>".
VERBOSE: New-MailContact : Searching objects of type "ADRecipient" with filter "(&((!((Id Equal <Remote Forest>/Contacts/Blah Test)))(|((EmailAddresses Equal SMTP:blah@<Remote forest.com>)))))", scope "SubTree" under the root "$null".
VERBOSE: New-MailContact : Processing object "<Remote Forest>/Contacts/Blah Test".
VERBOSE: Creating Mail Contact "Blah Test" with External E-mail Address "SMTP:blahblah@blah.com", Organizational Unit "<Remote Forest>/contacts".
VERBOSE: New-MailContact : The properties changed are: "{ DisplayName='Blah Test', AddressListMembership={ '\Default Global Address List' }, Alias='BlahTest', EmailAddresses={ 'SMTP:blah@<remote forest.com>' }, RawExternalEmailAddress='SMTP:blahblah@blah.com', PoliciesExcluded={ '{26491cfc-9e50-4857-861b-0cb8df22b5d7}' }, Id=’<Remote Forest>/Contacts/Blah Test', RawName='Blah Test', ObjectCategory='<Source Forest>/Configuration/Schema/person' }".
VERBOSE: New-MailContact : Saving object "<Remote Forest>/Contacts/Blah Test" of type "ADContact" and state "New".
VERBOSE: New-MailContact : Previous operation run on domain controller ‘<Remote Forest DC>’. New-MailContact : Active Directory operation failed on <Remote Forest DC>. This error could have been caused by user input or by the Active Directory server being unavailable. Please retry at a later time. Additional information: Additional information: The global catalog verification failed. The global catalog is not available or does not support the operation. Some part of the directory is currently not available. Active directory response: 000020E1: SvcErr: DSID-032005F2, problem 5002 (UNAVAILABLE), data 0. At line:1 char:16 + New-MailContact  <<<< -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@<RemoteForest.com> –DomainController <Remote Forest DC> -Verbose –OrganizationalUnit <Remote Forest>/contacts
VERBOSE: New-MailContact : Ending processing.

I was capturing a Netmon trace during this after disabling LDAP encryption (see , and this was the frame that showed the LDAP add request (creating the mail contact).  Note the highlighted part below.

Frame: Number = 233, Captured Frame Length = 1035, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-41-BD-00],SourceAddress:[00-15-5D-41-BD-0B]
+ Ipv4: Src = 10.10.100.16, Dest = 10.10.0.200, Next Protocol = TCP, Packet ID = 13162, Total IP Length = 1021
+ Tcp: Flags=...AP..., SrcPort=33110, DstPort=LDAP(389), PayloadLen=981, Seq=1117411596 - 1117412577, Ack=4214889466, Win=64154
- Ldap: Add Request, MessageID: 119
  + SASLBuffer: 
  - Parser: Add Request, MessageID: 119
   + ParserHeader: 
   + MessageID: 119
   + OperationHeader: Add Request, 8(0x8)
   - AddRequest: Entry: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
    - Entry: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
     + AsnOctetStringHeader: 
       OctetStream: CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com
    - Attributes: 13 Partial Attributes
     + SequenceHeader: 
     + PartialAttribute: CountryCode=( 0 )
     + PartialAttribute: displayName=( Blah Test )
     + PartialAttribute: showInAddressBook=( CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=<ORG Name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<remote forest>,DC=com )
     + PartialAttribute: mailNickname=( BlahTest )
     + PartialAttribute: proxyAddresses=( SMTP:blah@<remote forest>.com )
     + PartialAttribute: targetAddress=( SMTP:blahblah@blah.com )
     + PartialAttribute: internetEncoding=( 1310720 )
     + PartialAttribute: msExchPoliciesExcluded=( {26491cfc-9e50-4857-861b-0cb8df22b5d7} )
     + PartialAttribute: msExchRecipientDisplayType=( 6 )
     + PartialAttribute: distinguishedName=( CN=Blah Test,OU=Contacts,DC=<remote forest>,DC=com )
     + PartialAttribute: msExchVersion=( 4535486012416 )
     + PartialAttribute: objectCategory=( CN=person,CN=Schema,CN=Configuration,DC=<source forest>,DC=com )

In response to this, I got the LDAP error seen in the Powershell window.

LDAP:Add Response, MessageID: 119, Status: Unavailable ErrorMessage: 000020E1: SvcErr: DSID-032005F2, problem 5002 (UNAVAILABLE), data 0

If you see the same thing I did (well, since I’ve been nice and highlighted it), you probably know why the operation failed.  Yes indeed, the LDAP Add request is passing an attribute value that contains the source forest.  No wonder why the remote domain controller was responding with an error!

Luckily, Powershell allows you to control some additional settings via $AdminSessionADSettings.  Checking the current settings, I found the following listed

[PS] C:\WINDOWS\system32>$adminsessionadsettings
ViewEntireForest              : False
DefaultScope                  : <source domain>
PreferredGlobalCatalog        :
ConfigurationDomainController : <souce domain DC>
PreferredDomainControllers    : {}

On a whim, I changed the config DC to point to one in the remote forest by running the cmd

$adminsessionadsettings.configurationdomaincontroller = ‘<remote forest DC>’

[PS] C:\WINDOWS\system32>$adminsessionadsettings
ViewEntireForest              : False
DefaultScope                  : <source domain>
PreferredGlobalCatalog        :
ConfigurationDomainController : <remote forest DC>
PreferredDomainControllers    : {}

After making this change, I ran the cmdlet once again, expecting it to fail, but it succeeded.

[PS] C:\WINDOWS\system32>New-MailContact -Name "Blah Test" -ExternalEmailAddress blahblah@blah.com -PrimarySmtpAddress blah@mydomain.com –DomainController <remote forest DC> -Verbose –OrganizationalUnit <remote forest OU>
VERBOSE: New-MailContact : Beginning processing.
VERBOSE: New-MailContact : Searching objects "<remote forest OU>" of type "ExchangeOrganizationalUnit" under the root "$null".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>'.
VERBOSE: New-MailContact : Administrator Active Directory session settings are:  View Entire Forest: 'False', Default Scope: '<source forest>', Configuration Domain Controller: '<remote forest DC>',
VERBOSE: New-MailContact : Applying RUS policy to the given recipient "<remote forest OU>/Blah Test" with the home domain controller "<remote forest DC>".
VERBOSE: New-MailContact : The RUS server that will apply policies on the specified recipient is "<remote forest MBX server>".
VERBOSE: New-MailContact : Searching objects of type "ADRecipient" with filter "(&((!((Id Equal <remote forest>/Contacts/Blah Test)))(|((EmailAddresses Equal SMTP:blah@<remote forest>)))))", scope "SubTree" under the root "$null".
VERBOSE: New-MailContact : Processing object "<remote forest OU>/Blah Test".
VERBOSE: Creating Mail Contact "Blah Test" with External E-mail Address "SMTP:blahblah@blah.com", Organizational Unit "<remote forest OU>".
VERBOSE: New-MailContact : The properties changed are: "{ DisplayName='Blah Test', AddressListMembership={ '\All Contacts', '\Default Global Address List' }, Alias='BlahTest', EmailAddresses={ 'SMTP:blah@<remote forest>' }, RawExternalEmailAddress='SMTP:blahblah@blah.com', LegacyExchangeDN='/o=<ORG name>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=BlahTest', PoliciesExcluded={ '{26491cfc-9e50-4857-861b-0cb8df22b5d7}' }, Id='<remote forest>/Contacts/Blah Test', RawName='Blah Test', ObjectCategory='<remote forest>/Configuration/Schema/person' }".
VERBOSE: New-MailContact : Saving object "<remote forest>/Contacts/Blah Test" of type "ADContact" and state "New".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>’.
VERBOSE: New-MailContact : Reading new object "<remote forest>/Contacts/Blah Test" of type "ADContact".
VERBOSE: New-MailContact : Previous operation run on domain controller '<remote forest DC>'.
Name                      Alias                                          RecipientType
----                      -----                                          -------------
Blah Test                 BlahTest                                       MailContact
VERBOSE: New-MailContact : Ending processing.

This time, both Netmon and the verbose output from the cmdlet show that the Configuration partition being referenced to set the objectcategory is for the correct domain/forest, and the add request succeeds.

If you don’t like this behavior, and are looking to export only certain folders (for example, just export the Inbox), I want to suggest a workaround.  You see, along with –IncludeFolders, there is another switch-ExcludeFolders.  Instead of specifying the list of folders to include, you specify the folders you want excluded.  Specifically, we tell the Export-Mailbox cmdlet that if it doesn’t match the “exact” path of the folder we want, it should be excluded.  Read on for more details.

First, we define a variable to do our “search”.  The reason why we have to do this is that we are first running Get-MailboxFolderStatistics, and the folderpath it outputs to is in the form of “/Folderpath”, but Export-Mailbox expects a folder path of “\FolderPath”, so we have to convert the forward slashes to backslashes.

$r = [regex]'/';

Next, we define another variable.  This is used to store our “list” of folders to exclude.  We use the Get-MailboxFolderStatistics to get a list of all folders that we want to “exclude”.  For example, where the folder path is not like the “Inbox”, and not like the “Top of Information Store”.  We have to include “Top of Information Store” here because the Inbox is a folder underneath the Top of Information Store, and if it isn’t included, the Inbox won’t be exported either.

From that output, we select only the FolderPath object (because that is all we need), we convert it to a String value (because right now, it is an Object), then change the “/” character to “\” and we store that as a variable. 

This can be modified to include other folders as well.  Just keep adding things to the where statement, for example $_.folderpath –ne “/Sent Items”.

$exclude = Get-Mailbox "Mailbox Name" | Get-MailboxFolderStatistics | where {$_.folderpath -ne "/" -and $_.FolderPath -ne "/Inbox"} | Select-Object FolderPath | Foreach {$_.folderpath.tostring()} | foreach {$r.replace($_”,”\”,-1)}

The -1 at the end tells it to iterate through all folders in the list.

OK – admittedly, that is a lot of work to get what you need, but it should work.  So now, you have a variable that contains an array of all the folders you want to “Exclude”.  You are ready to run the Export.

This will perform the export for the 1 user you define.  You can also modify the above to run against all users. 

Export-Mailbox "Mailbox Name" -FoldersExclude $exclude -TargetMailbox "Mailbox Name" -TargetFolder "Folder Name"

In the below example, it is running against all users except the mailbox you are exporting to, and getting a list of all folders except the Inbox, Top of Information Store, and Deleted Items.  Since the –ExcludeFolders doesn’t care if a folder doesn’t exist in a mailbox, we’ll keep the size of the list to a manageable level by only including Unique folder names.

$exclude = Get-Mailbox | where {$_.name –ne “Mailbox Exporting To”} | Get-MailboxFolderStatistics | where {$_.folderpath -ne "/" -and $_.FolderPath -ne "/Inbox" –and $_.FolderPath –ne “/Deleted Items”} | Select-Object FolderPath | Foreach {$_.folderpath.tostring()} | foreach {$r.replace($_”,”\”,-1)} | Sort -Unique

Now we are going to get the list of mailboxes to export.

Get-Mailbox | where {$_.name –ne “Mailbox Exporting to”} | Export-Mailbox –ExcludeFolders $exclude –TargetMailbox “Mailbox Exporting To” –TargetFolder “Folder name”

Now since I don’t have a large lab with lots of mailboxes that have lots of data (and folders) in them, I haven’t verified how much time this method will save, but I believe the time savings here will be substantial.  If you try this method out, please let me know if it saves you time.

First, one of my colleagues, Tim McMichael, has a blog that details the different ExBPA rules that can be ignored for Windows 2008 clusters (both Exchange 2007 and Exchange 2010).  That blog is located here:

http://blogs.technet.com/b/timmcmic/archive/2009/05/19/exbpa-incorrectly-flags-windows-2003-cluster-rules-on-windows-2008.aspx

I’m not sure if the rules ever got updated for Exchange 2007, but they definitely were not updated for Exchange 2010 RTM (Oops!).  These rules will be fixed with Exchange 2010 SP1.

Now, on to the issue.

If you run ExBPA on Exchange 2010 RTM, one of the issues detected (under All Issues) is that the Quorum Log size is too small (see below screenshot from my lab)

You’ll note that the recommendation is to change the current setting from 1024 to 4096.

http://technet.microsoft.com/en-us/library/aa995830(EXCHG.80).aspx details the recommended change and where to modify this setting.  If you are astute, you’ll note that the text only discusses Windows 2000 and Windows 2003.  That’s because this setting no longer applies to Windows 2008.  Unfortunately, you won’t find anything currently documented about this (I’ve asked our friends over in Windows Clustering to please get something documented).

You’ll also see the same recommendation if you run Test-SystemHealth (the Shell version of ExBPA)

So, let’s say you are running Exchange 2010 in a Database Availability Group (DAG), and you decide to make the change.  Remember that for a DAG, you have to specify a Witness server during creation.  This results in the Quorum model being set to Node and File Share Majority, which will show as follows:

As soon as you modify the MaxQuorumLogSize registry value to anything but the default of 1024, and refresh the Failover Cluster Management interface, you will notice that the Quorum model changes to Other.

As stated previously, this doesn’t affect the actual functionality of the cluster, but if I was a customer, and encountered this situation, I sure wouldn’t be happy, especially seeing that a Quorum model of “Other” isn’t documented anywhere, and isn’t even shown as a valid Quorum model.

The resolution to this is easy.  Change the MaxQuorumLogSize back to 1024.  No restarts required – just refresh the Failover Cluster Management interface.  The Quorum model should change back to “Node and File Share Majority (\\UNC of FSW)” as expected.

In a scenario where there are multiple Exchange organizations (or multiple connected organizations, such as in a Notes –> Exchange co-existance scenario), and the delegate of one person sends a meeting request to someone in the other organization who also happens to have a delegate, and the delegate is configured to receive the meeting requests, the meeting request may not be delivered to the delegate.

Let me see if I can simplify this with a diagram.

This problem is seen because when a Delegate sends the meeting request, the Sent-By field is populated, and this field is what is used for the Sender address.  Unfortunately, this field gets populated as “SMTP:mailto:user@organizationA.com.”.  This is a problem because anything after the SMTP: is interpreted as the address, and when the mailto: is present, that is picked up as part of the address.  Colons are invalid characters in an smtp address, however, so when the message is processed, an invalid sender exception is thrown, and the message does not get delivered to the Delegate.

Another side effect of this issue was that the “Messages queued for submission” performance counter would be incremented on the destination mailbox server, and if you have a monitoring solution in place (such as Microsoft Operations Manager, or System Center Operations Manager), alerts may be generated.  More information about this can be found in KB article 953094

The good news is that this was fixed in Rollup 7 for Exchange 2007 SP1 (and would thus be included in both Rollup 8 and 9 and beyond since Rollups are cumulative), so unless you are behind on your rollups, hopefully you won’t encounter this situation.  It’s also worth noting that the fix (which works by simply stripping out the mailto: portion) needs to go on Hub Transport servers.  So make sure that your Hub Transport servers are running Rollup 7 or higher!

The computer account '<Exchange Virtual Server Name>' was created on the domain controller \\<pdc emulator name>, but has not replicated to the desired domain controller (<local DC name>) after waiting approximately 60 seconds. Please wait for the account to replicate and re-run setup /newcms.

Most (if not all) of you probably already know, but the Cluster portion of setup is completely separate from installing the Mailbox role.  The Mailbox Role can be installed as part of the same instance of setup, but it will complete prior to the Clustered Mailbox Server portion of setup.  The issue encountered above appears to be isolated to Exchange 2007 clusters that are running on Windows 2003 only.

The issue stems from how the Windows 2003 Cluster service works.  When Exchange setup runs, it makes a call into the Cluster API to create the computer account for the Exchange CMS.  It is important to note here that Exchange is not what is creating the computer account, rather the Cluster service is.  At this point, what happens is that the Cluster service attempts to contact the PDC Emulator for the domain, and creates the computer account on that Domain Controller.  If the PDC Emulator FSMO role happens to be in a different Active Directory Site than the Active Directory Site where you are installing the Exchange cluster, then there may be a delay in getting that computer account replicated to a local Domain Controller.  This issue is also observed because Exchange setup will now use a Domain Controller in the local AD site rather than also automatically going to the PDC Emulator.  This change was first made in Sp1 for Exchange 2007.  So given the above, let’s consider the following chain of events.

1. Exchange setup calls in to Cluster API to create the computer account for the CMS.
2. Cluster API contacts the DC holding the PDC Emulator role, and creates the computer account.
3. Exchange setup contacts a DC in the local AD site and checks for the existence of the CMS computer account.

At this point, if either the computer account doesn’t exist, or if the computer account exists but is disabled on the local DC, then setup will fail with the above error.  Re-enabling the computer account on the local DC will not fix this issue, as the computer account was created or reset on the PDC Emulator, and the account on the local DC no longer matches what is on the PDC Emulator.

Further complicating the issue is that when you re-run setup /newcms, the entire procedure appears to be repeated.  If you watch in Cluster Administrator, you will see that the group that was created for the CMS, along with all resources inside the group, is deleted.  Now at this point, the only resources that exist are the IP Address resource, and the Network Name resource.  The CMS group will then be re-created, and the IP address resource, and Network Name resource will also be re-created.  Re-creating the Network Name resource causes the computer account to be reset on the PDC Emulator, and causes it to be disabled on any other DC’s (that is my understanding here at least).  So you’re right back to square one.

How do we get around this?  Pre-staging the computer account on the PDC Emulator, and allowing that to replicate to the local DC does not work, because the pre-staged account will be deleted and re-created by the Cluster service during setup.  I have thus found the following 2 workarounds that should allow setup to continue past this section.

1. Move the PDC Emulator role to a Domain Controller in the local AD Site.

Pros: Relatively easy to do, should not cause any additional issues with Active Directory.
Cons: Requires a functional design change to Active Directory Infrastructure.  May require approval of multiple teams.

2. Block the Cluster service from communicating with the PDC Emulator.

Pros: Works except in rare situations where the PDC Emulator is in a different AD site, but the same IP subnet.  Fairly easy to implement.
Cons: not “officially” supported/tested by the Exchange Product Group.

Let’s talk a little more about workaround 2.  What does this involve?  Actually, just a few minor changes.  You need to modify the local Hosts file on the Exchange Server (located in C:\Windows\System32\Drivers\Etc – look for the file Hosts with no extension), and add the following entries to the bottom of the file.

127.0.0.1    PDCEmulator.FQDN.com
127.0.0.1    PDCEmulatorNetBIOS

Save the Hosts file, the run ipconfig /flushdns, and nbtstat –R

Run setup again, and the operation should be successful.  What’s the difference you ask?  Well, if you prevent the Cluster service from communicating with the PDC Emulator, then it will fall back to using a local DC.  When it creates the computer account on a local DC, intra-site replication is almost instantaneous, so Exchange is able to find the correct computer account on the DC that setup chooses, and is able to go on past this portion of setup.

As mentioned above, this issue can be encountered when setting up a new cluster (setup /newcms), or if you are recovering an existing cluster (setup /recoverCMS).  The second scenario would be especially common if you are testing your DR procedures, and performing a failover/activation to an SCR Target.

This issue should not be present in Windows 2008, as the cluster service is smarter, and when the PDC Emulator is detected as being in a different site, the cluster service should automatically use a local DC for operations such as this.

There may be times when in order to further troubleshoot a problem, you need to capture a Network Monitor trace.  Netmon is very helpful in finding delays, and LDAP errors.  However, there is one major hurdle.  Virtually all LDAP traffic is signed and sealed, and encrypted.  This unfortunately makes viewing the queries and responses impossible by default.  You would see something similar to the following.

And that is all you will see.  Of course, this makes troubleshooting much harder, because you can’t see what queries are being issued, or what the Domain Controller is responding with.  Fortunately, there are ways to turn off LDAP encryption.  I have gathered together the following list of things that need to be done in order to ensure that all forms of LDAP encryption are disabled.  Some steps are only for Exchange 2003, and others are only for Exchange 2007.  Where specific to a version, I have included which version it applies to.

Here are the steps to turn off LDAP encryption.  There are a few different places we have to do this in order to catch everything.

These steps apply to both Exchange 2003 and Exchange 2007

1. Modify the Local Security Policy. 

Under Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.  Find the policy setting “Network Security: LDAP client signing requirements”.  Note that the default is set to “Negotiate signing”.  On the Domain Controller side, it is actually set to None by default, but since the client requests to negotiate, it will always be signed if supported.  Set this to None on the “client” (the Exchange server is the client in this case).  You should also check the Default Domain Controller group policy, as if the LDAP signing policy is set to Negotiate, or Require, you will need to modify the Domain Controller policy as well.

2. Set the following registry key and value on the Exchange server.  If the AdminDebug key is not present, add it.  This registry value disables Encrypted LDAP Bind’s.  Normally, once a Bind request is issued, all LDAP traffic sent after that will be encrypted. 

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\AdminDebug

New DWORD value: ADsOpenObjectFlags

Data Value: 0x3

Per KB 325465, the following values correspond with the following actions.  As you can see, by setting the value to 0x3, we disable both Signing and Encryption.

Value Data (Hexadecimal)  Disables 
1  Signing 
2  Encryption 
3  Encryption and Signing 

This step is for Exchange 2007 only

3. Add the following registry key to disable LDAP encryption for the Exchange 2007 DSAccess process

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess

New DWORD value: Disable LDAP Encryption

Data Value: 0x1

This step is for Exchange 2003 only

4. Per KB818479, to disable signing and encryption for traffic created by Exchange 2003 Admin tools, add the following value

HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange

New DWORD value: DebugLDAP

Data Value: 0x1

Once you have set all of these options, you should be good to go.  Get another Netmon trace, and you should now be able to view the contents of every LDAP frame.  On rare occasions, you may need to reboot to get all of these settings to be correctly read.  Also, don’t forget to undo any changes that are made once you are done.  Signing and Encryption of LDAP traffic is a good thing to have in place for security reasons, so only leave this disabled as long as you need to.