The counter list and portability (read I/O operations)

An ExRAAP scanning detected this issue “The read I/O operations latency is greater than expected for an Exchange database” with an advice I started to monitor related performance counters according to post Analysing Exchange Server 2010 Jetstress BLG Files By Hand which contains also the following table:

7- 8- 2014 12-15-22Time to time I needed to check read I/O operations without a Data Collector Set, but I did not want to have the counter list/settings dependent on particular server (i.e. the server below hosts mailbox database MDB01 or MDB05 but not MDB02 and I want to have counters for all of them and I do not mind that some counter will not work).

7- 8- 2014 12-03-147- 8- 2014 12-44-28Well, I saved the settings from the server into HTML file and modify its content for 18 databases.

  • Changing value: <PARAM NAME=”CounterCount” VALUE=”18″/>
  • Adding parameters for missing databases (be careful you have to always use unique PARAM NAME):7- 8- 2014 12-59-42After that I could check the latency by pasting the same counter list on any server.

7- 8- 2014 13-12-18


How to alter Retention policies in Exchange 2013

One of my friends want to alter automatic deletion of Junk Email folder so, that it contains only 30 days of messages. The way how it should be done is simple. We can create new retention policy or add Retention policy tag to existing one.


Exchange 2013 (as well as Exchange 2010) contains a set of Retention policy tags grouped in Default Retention and Archive policy. Retention policy tag says, what action will be done with item (for example all Messages calls) within specified Retention period and defined folder. Retention policy can be assigned to mailbox in 1:1 ratio, meaning only one Retention policy can exist on mailbox. It is not supported to have no retention policy on mailbox or to have Retention policy without any Retention policy tag, which might cause, that no item in mailbox will expire. More info about Retention policies and tags can be found here: Retention Tags and Retention policies are described here:

Retention policy can contain several types of Retention policy tags:

  • One or more retention policy tags (RPTs) for supported default folders
  • One default policy tag (DPT) with the Move to Archive action
  • One DPT with the Delete and Allow Recovery or the Permanently Delete action
  • One DPT for voice mail
  • Any number of personal tags

Retention policy is then added to mailbox and it is up to administrator to configure how often Managed Folder Assistant will process mailboxes. I picked up and option to add Retention policy tag to existing policy and here is the result:

Creation of Retention policy tag

To create Retention policy tag we must be sure what action to perform and to what folder type. In my case to delete and allow recovery on all items older than 1 month in folder type Junk Email. Here is the command:

New-RetentionPolicyTag -Name "Junkmail Cleanup" -MessageClass * -AgeLimitForRetention 30.00
:00:00 -RetentionAction DeleteAndAllowRecovery -Type JunkEMail


Assigning Retention policy tag to Retention policy

To add Retention Policy tag to Retention policy use the following commands:

$TagList = (Get-RetentionPolicy "Default Archive and Retention Policy").RetentionPolicyTagLinks
$TagList.Add((Get-RetentionPolicyTag 'Junkmail Cleanup').DistinguishedName)
Set-RetentionPolicy "Default Archive and Retention Policy" -RetentionPolicyTagLinks $TagList


Assigning Retention policy to mailbox

First gather what retention policy is used and if different, add needed retention policy to mailbox:

Get-Mailbox zbynek | select *ret*
Set-Mailbox zbynek -RetentionPolicy "Default Archive and Retention Policy"

Force running Retention policy

Start-ManagedFolderAssistant -Identity zbynek

Assign Retention policy and cleanup

Change Retention policy cycle

The default is to run policy for all mailboxes daily, but it can be changed altering mailbox server property ManagedFolderWorkCycle. In my example there will be 10 days cycle to run Retention policies on all mailboxes on the server.

Set-MailboxServer EX13NODE2 -ManagedFolderWorkCycle 10




IMAP connection settings and workload management on Exchange 2013

One of my Exchange 2013 customers currently running Exchange 2013 CU2v2 started to have problems with IMAP connections to his server. IMAP log stated, that conection limit has been reached:


I have examined IMAPSettings from Exchange management shell, and here it is. Connection limit per user is set to 16 by default and counters are reset after 240000 milliseconds (4 minutes), which is not enough. First part of this article will be about the possibilities how to set IMAP from connection point of view. Second part is, how to deal with IMAP in case server is under heavy load and it is expected to have IMAP running.

1. IMAP Settings from connection point of view

IMAP connections limits can be set in levels of MaxConnections, MaxConnectionFromSingleIP, MaxConnectionsPerUser. First two limits are very high, but third limit is set to 16 by default and throttling policy let counter reset after 240000 milliseconds by default, which means, that if user make more than 16 connections in 4 minutes, he is banned till next counter reset.

imap limit

So connection limit might be increased by the following command:

Set-IMAPSettings -MaxConnectionsPerUser <Number>
Get-Service *IMAP* | Restart-Service

Result can be seen on the Picture below (Reset of IMAP services must be made):


imap limita

Details about settings are here:

2. IMAP settings from Workload management point of view

Limits per user are set and now I would need to fulfill customer needs if server load is increased. In my case customer needs to have IMAP working properly even there is high utilization of system resources. First I went to Technet web link and selected the best suitable Workload Classification for my customer. Default Workload Classification for IMAP is Internal Maintenance. If one of performance indicators is in Overloaded or pass the Critical threshold, IMAP service might be temporarily inaccessible for users (Monitored system resources are described in the Technet article as well).

So in this stage I have checked tables and according the server utilization I suggested to increase Workload Classification from Internal maintenanace (Picture below) to Customer Expectation, which means, that even the server will be under heavy load, IMAP is going to work for users.

Before Setting (Default Workload Classification):


After setting performed by the following command:

Get-WorkloadPolicy IMAP | Set-WorkloadPolicy -WorkloadClassification CustomerExpectation

IMAP_Connection_limit_Workload_management_after Done!


Exchange federation trust – part 2.

Finally here is the continuation of previous article about Exchange federation trust. So we have established the trust between Microsoft Federation Gateway and our organizations. Next step is to configure inter-organizational behavior. It is a mesh-like net, where 1:1 organization relationship is established.


  • Autodiscover service must be accessible to at least one CAS server from the internet
  • EWS should be accessible to at least one server and External URL should match the name accessible from  internet and 3rd party certificate SN or SAN name

Organization Relationship

Once we have configured our organizations to trust MS Federation Gateway, we can use it to create organization relationship. We will use

command Get-FederationInformation about opposite organization and pipe it to create new organization relastionship. Access level on both side of relationship should be the same.

In our organization:

Get-FederationInformation -DomainName | New-OrganizationRelationship -Name "Metrosys" -FreeBusyAccessEnabled $true 
-FreeBusyAccessLevel -LimitedDetails

Or directly:

New-OrganizationRelationship -Name <foreignorganizationname>  -FreeBusyAccessEnabled $True -FreeBusyAccessLeve LimitedDetails -
Enabled $true -PhotosEnabled $true -TargetAutodiscoverEpr -
DomainNames .cz -TargetApplicationURI -TargetSharingEpr

Note: Domain names are CASE SENSITIVE!
Result of creation test:

Test-OrganizationRelationship -identity <ForeignOrganizationname> -UserIdentity -Verbose

OK success rel test

In foreign organization:

Get-FederationInformation -DomainName | New-OrganizationRelationship -Name "Salonovi" -FreeBusyAccessEnabled $true -
FreeBusyAccessLevel LimitedDetails

Or directly:

New-OrganizationRelationship -Name  -FreeBusyAccessEnabled $True -FreeBusyAccessLeve LimitedDetails -Enabled $true -PhotosEnabled 
$true -TargetAutodiscoverEpr -DomainNames -TargetApplicationURI -TargetSharingEpr

Note: Domain names are CASE SENSITIVE!

Finally result of proper configuration is, that you can see Free/Busy limited details of users in foreign organization

Errors you might face

Index error is cause by Case sensitive domain name inserted (in my case instead of or wrong URLs for EWS or Autodiscover.


Errors from the following picture are caused by wrongly or misspelled URLs (Self explaining)


Usually autodiscover URL is created in format, however Federation trust use autodiscover service, which is created as URL: where WSSecurity is authentication used by federeation trust:



SMTP certificate renewal and EDGE subscription

I have had to renew SMTP certificate on EDGE servers. Here is the procedure how to renew certificate and re-create Edge subscription. This procedure starts,when CSR is created and we have received certificate from trusted CA.

1. Import new certificate
To import certificate to local certification store run:

import-exchangecertificate -FileData ([byte[]]$(Get-Content -Path "D:\tempo\certificate_mx1_2013.cer" -Encoding Byte -ReadCount 0))

2. Connect pending request to certificate
If step 1 failed to connect certificates together inside certification store run:

certutil -repairstore my "1268f7300044bc90ff426d5f515d3729"

Explanation can be found in my previous article:

3. Enable new Exchange certificate for SMTP service
Before certificate can be used, it must have been enabled for particular services.

Enable-ExchangeCertificate  -services SMTP


[PS] C:\Windows\system32>Enable-ExchangeCertificate 81315B240A62B5B5AD5570AA58A06D90B4B90B7E -Services SMTP

Overwrite the existing default SMTP certificate?

Current certificate: 'C661DC9E16FB391EDA2A852C3514AD035D710F68' (expires 4/27/2013 2:59:59 AM)
Replace it with certificate: '81315B240A62B5B5AD5570AA58A06D90B4B90B7E' (expires 4/28/2014 2:59:59 AM)
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
WARNING: The internal transport certificate attribute for the local Edge Transport server has been updated. If this
Edge Transport server is subscribed to an Active Directory site, you must  subscribe it again by using the
New-EdgeSubscription cmdlet in the Shell, and then restart AD LDS.
[PS] C:\Windows\system32> 

4. Restart transport service and AD LDS service
At this moment e-mail stop to flow to this EDGE server, because AD LDS is using new certificate and Edge is subscribed via old one.

5. Create subscription file (XML) on Edge server ans copy it to HUB server
We don´t need to create connectors for EDGE Subscription, since those are already created. EDGE must be subscribed to AD site within 24 hours after creation of subscription file.

New-EdgeSubscription -FileName d:\subscription_2013.xml -Site <SITE_NAME> -CreateIternetSendConnector $false -CreateInboundSendConnector $false


[PS] C:\Windows\system32>New-EdgeSubscription -FileName d:\subscription_2013.xml -Site Default-First-Site-Name -CreateIternetSendConnector $false -CreateInboundSendConnector $false

The Edge Subscription should be completed inside your organization within the next "1440" minutes before the bootstrap
account expires.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

6. Subscribe EDGE server on HUB by subscription file (XML).
We need to re-create trusted connection between Edge server and HUB servers. Subscribtion needs to be re-created, because AD LDS needs to use new certificate instead of old one. It is enough to subscribe each EDGE server once per subsciption.

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "D:\subscription_2013.xml" -Encoding Byte -ReadCount 0)) -Site "Default-First-Site-Name"

7. Restart EDGE server
Just to be sure all settings are applied before tests.

8. Test Edge Subscription
If the test is not successfulm you receive error.

Test-EdgeSynchronization -FullCompareMode

Successful result:

[PS] C:\Windows\system32>Test-EdgeSynchronization -FullCompareMode

RunspaceId                  : 4f4c61e7-1059-43fc-963b-877641087e2a
SyncStatus                  : Normal
UtcNow                      : 4/26/2013 6:43:50 AM
Name                        : EDGE
LeaseHolder                 : CN=HUB2,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrati
                              ve Groups,CN=OR,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=SALONOVI,DC=cz
LeaseType                   : Option
FailureDetail               :
LeaseExpiryUtc              : 4/26/2013 7:12:12 AM
LastSynchronizedUtc         : 4/26/2013 6:42:12 AM
TransportServerStatus       : Synchronized
TransportConfigStatus       : Synchronized
AcceptedDomainStatus        : Synchronized
RemoteDomainStatus          : NotSynchronized
SendConnectorStatus         : Synchronized
MessageClassificationStatus : Synchronized
RecipientStatus             : Synchronized
CredentialRecords           : Number of credentials 6
CookieRecords               : Number of cookies 2

9. Test mailflow

10. To start Edge synchronization manually



[PS] C:\Windows\system32>Start-EdgeSynchronization

RunspaceId     : 4f4c61e7-1059-43fc-963b-877641087e2a
Result         : Success
Type           : Configuration
Name           : EDGE
FailureDetails :
StartUTC       : 4/26/2013 6:46:45 AM
EndUTC         : 4/26/2013 6:46:45 AM
Added          : 0
Deleted        : 0
Updated        : 0
Scanned        : 0
TargetScanned  : 0

RunspaceId     : 4f4c61e7-1059-43fc-963b-877641087e2a
Result         : Success
Type           : Recipients
Name           : EDGE
FailureDetails :
StartUTC       : 4/26/2013 6:46:45 AM
EndUTC         : 4/26/2013 6:46:45 AM
Added          : 0
Deleted        : 0
Updated        : 0
Scanned        : 0
TargetScanned  : 0


Exchange federation trust – part 1.

I need to configure federation trust between two organizations, but what is federation trust? It is secure trusted connection of separate organizations, which need to share their internal data (From Exchange point of view it is Calendar,Free/busy and contact information and others (see Set-OrganizationRelationship) without a need of establishing special Forests/Domains trusts, VPN connections or buying expensive synchronization servers.

Federation trust works based on free Microsoft cloud service Microsoft Federation Gateway. Microsoft Federation Gateway acts like middle authority, with which all Exchange organizations need to establish one time trust before those will be able to communicate with each-other. After one time trust is established, Microsoft Federation Gateway issues SAML tokens for users, which requests to get information about users from federated Exchange organization. These tokens are then trusted by fedetated partners and contain info about user e-mail address, immutable (constant) number and action to which token is issued for.
If we imagine the description above, all Exchange organizations will be trusted with Microsoft Federation Gateway, but it will not allow it to communicate with each-other, before 1:1 trust relationship “Organization Relationship” is not established between 2 Exchange organizations. Organization Relationship connects 2 Exchange organizations and allow them to share data defined by Sharing policies.

In first part of article I will go through prerequisites, you need to start configuring Federation trust, actual configuration of Federation trust with Microsoft Federation Gateway, Configuring of Organization identifier. Preparation for configuration of Organization relationship will be part 2 of this series. Reason is simple. I don´t have DNS records in place during the time writing this article.

For full technology description please visit MS Technet


  • Autodiscover and EWS virtual directories must be published to internet (or in case internal connection exists between your organizations, these must be accessible in both directions)
  • Federation trust needs to have WSSecurity authentication in place on EWS and Autodiscover virtual directories

Run the following commands to check if all of these are in place:

Get-ClientAccessServer | Get-WebServicesVirtualDirectory |select *auth*

CertificateAuthentication     :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory |select *auth*

InternalAuthenticationMethods : {Basic, OAuth}
ExternalAuthenticationMethods : {Basic, OAuth}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : True
AdfsAuthentication            : False

As you can see in the result, AutoDiscover virtual directory doesn´t have WSSecurity authentication enabled. To enable it use the command below followed by IIS reset.

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $true

After these are ready, we can continue configuring Federation trust.

Federation trust

  • To get Federation trust working we need to generate self-signed certificate with unique Subject Key Identifier. This certificate will be used to sign and encrypt delegation tokens  (3rd party sign certificate can be used too, but why if we can use free self-signed one with longer validity period).

First command generates unique SKI, second generates the certificate

$ski = [System.Guid]::NewGuid().ToString("N")
New-ExchangeCertificate -FriendlyName "Exchange Federated Sharing" -DomainName "" -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski

Next command creates Federation trust, but we are not able to communicate with MFG yet.

Get-ExchangeCertificate | ?{$_.friendlyname -eq "Exchange Federated Sharing"} | New-FederationTrust -Name "Microsoft Federation Gateway"

To be able to communicate with MFG we must proove, that domains , which will be defined in Federation Organization Identifier are owned by us. This is accomplished by adding HASHES as TXT records to our DNS.
Hashes can be gathered by the following commands. Domain is used to create namespace for communication between organizations and to be honest I am not sure if this hash needs to be in place, but I put it there to be sure it works.

Get-FederatedDomainProof -DomainName

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
DomainName :
Name       : OrgPrivCertificate
Thumbprint : 82E68E80B61290475025A0E9737FECE922D4E8C3
Proof      : EmJKFNW+frdgGM+fkDZyKE+nbJzdRaouCKM2NHNzIjgVPB6TuwlEmWdqxCa1BWuxfTth+Do2R+fLLbbahTWmLg==
DnsRecord  : TXT IN 

Get-FederatedDomainProof -DomainName

The format of DNS records is as follows: TXT IN <hash>

And live example is TXT IN iE64T7bsM8auQUYoAD/Dc/+sEAieDjG6gJFkGvZRIvyb+5FiwjCQY8BiIrrwafVUr7r3VdyAOXm9F/eb0R8kuA==

After hashes are in external DNS, we can set Federated Organization Identifier. It defines which domains of our organizations will be enabled for federation and what federation trust it will use.
Before setting of Federation identifier we get the following results


RunspaceId          : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
AccountNamespace    : missing
Domains             : missing
DefaultDomain       : missing
Enabled             : False
OrganizationContact : 
DelegationTrustLink : 
Identity            : Federation
IsValid             : True
ExchangeVersion     : 0.10 (
Name                : Federation
DistinguishedName   : CN=Federation,CN=SalonoviMail,CN=Microsoft 
Guid                : 3a69e332-7156-4251-856c-f3cc17853e39
ObjectCategory      :
ObjectClass         : {top, msExchFedOrgId}
WhenChanged         : 1/7/2013 7:18:04 PM
WhenCreated         : 11/29/2011 9:21:30 PM
WhenChangedUTC      : 1/7/2013 6:18:04 PM
WhenCreatedUTC      : 11/29/2011 8:21:30 PM
OrganizationId      : 
OriginatingServer   :
ObjectState         : Unchanged

Get-FederationInformation -DomainName
Federation information could not be received from the external organization.
    + CategoryInfo          : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
    + FullyQualifiedErrorId : D04C5818,Microsoft.Exchange.Management.SystemConfigurationTasks.GetFederationInformation
    + PSComputerName        :

Federated Organization Identifier

Set-FederatedOrganizationIdentifier -Enabled $true -DefaultDomain -AccountNamespace -DelegationFederationTrust "Microsoft Federation Gateway"

Final step is to test if Federation Trust is working. I use verbose parameter to troubleshoot but in this example I was lucky and all worked as expected at first glance.

Test-FederationTrust -UserIdentity

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationTrustConfiguration
Type       : Success
Message    : FederationTrust object in ActiveDirectory is valid.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : FederationMetadata
Type       : Success
Message    : The federation trust contains the same certificates published by the security token service in its 
             federation metadata.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : StsPreviousCertificate
Type       : Success
Message    : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : OrganizationCertificate
Type       : Success
Message    : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenRequest
Type       : Success
Message    : Request for delegation token succeeded.

RunspaceId : 7b47ba54-c78f-4d73-8337-a457b9ebfd1b
Id         : TokenValidation
Type       : Success
Message    : Requested delegation token is valid.

Next part comes soon (tomorrow) continuing with setting 1:1 relationships.

Exchange mass mailing?

Of course it is not recommended and there is much of cheap tools, but if your customer wants to send thousands of e-mails several times a day due to business needs and no delay is allowed, there is a possibility to set this behavior in Exchange:

The goal is to create special receive connector for this application and besides other settings you need (authentication, message size …) you should modify the following parameters:

  • MaxAcknowledgementDelay (Default 30 seconds) – This is time out parameter, if Exchange server cannot confirm delivery of message to all recipients, if the message was received by MTA, which does not support  shadow redundancy feature.
  • TarpitInterval (Default 5 seconds) – This parameter is valid for unauthenticated sources and specifies how much time SMTP response is delayed to source server in case, that Exchange determines source server is abusing connection.

The combination of settings MAxAcknowledgementDelay and TarpitInterval  to small values might put your environment to performance problems and it is NOT recommended to set it on internet receive connectors.


Get-ReceiveConnector SERVER\Relay | select *ack*,*tarp*,*lim*,iden* | fl

MaxAcknowledgementDelay : 00:00:30
TarpitInterval          : 00:00:05
MessageRateLimit        : Unlimited
Identity                : CHM2\Relay


Get-ReceiveConnector SERVER\Relay | Set-Receiveconnector -MaxAcknowledgementDelay : 00:00:01 -TarpitInterval 00:00:00

This will not work in Exchange 2013, since shadow redundancy has been improved and Safety Net feature has been added instead of transport dumpster..


IMAP pst file import problems – folders containing IMAP items (IPF.Imap) type are not displayed in Exchange 2010 / 2013 OWA

Problem description

I have been solving problem in my friends Exchange 2013 environment. After migration (from IMAP profile) some folders were not visible in his OWA while those were visible in Outlook.
After research I have found, that every folder is “Different in properties” as seen in result Picture below.

wrong properties

Hmm, what now? I dont wanna use MFCMapi, since my friend has many folders. EWS? OK, but how?



  • As far as I understand Exchange, there are several kind of permissions and properties and mailbox folder properties belong to MAPI and those can be edited via MFC Mapi (ExFolders) ( or via EWS Managed API (
  • Yes. Exchange Web Services Managed API allows you to write custom applications, but I am not a programmer. I have downloaded a script from (, which I want to say thanks for and made additions to it.
  • Behind the scenes I have found nice technet discussion about how to change folder class so, that it will be visible in OWA, because OWA doesnt show folders with IMAP items. The goal is to change IPF.Imap class to IPF.Note. After changing via EWS you will see the diference as in picture below and after refresh OWA will work as needed.

Correct properties

  • As administrator I am not keen in C# so I will use my domain. Powershell (3.0) as I do the script on Exchange 2013 server


  • Before you even start to play with EWS, you need to install EWS Managed API fom the link: or newer version (Link is from Fall 2012)
  • After downloading install it to directory, from which you run the script. Note, that you will need to make reference for “Microsoft.Exchange.WebServices.dll” which is key component of EWS managed API. Example from my script is below:

$dllpath =“d:ExchangeScriptsEWSmanagedAPIMicrosoft.Exchange.WebServices.dll”  

  • Next step is to add your user name full access to mailbox, which will be checked and impersonate role, which will allow impersonation of mailbox under your user as you were owner of the mailbox. Commands are as follows:

New-ManagementRoleAssignment -Name Impersonation -User administrator -Role ApplicationImpersonation


Script can be downloaded from Skydrive

$dllpath = "d:ExchangeScriptsEWSmanagedAPIMicrosoft.Exchange.WebServices.dll" #Define DLL Path

[void][Reflection.Assembly]::LoadFile($dllpath) #Load DLL

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP2) #Define EWS Service and version

$service.Url = New-Object System.Uri("") #Define uri for EWS VDir

$MBXID = "mailbox.identity" #Define mailboxID

foreach ($MailboxIdentity in $MBXID) {

Write-Host "Searching for $MailboxIdentity"

$MailboxName = (Get-Mailbox -Identity $MailboxIdentity).PrimarySmtpAddress.ToString()

$MailboxDName = (Get-Mailbox -Identity $MailboxIdentity).DisplayName

$ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId -ArgumentList ([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress),$MailboxName #Define impersonation

$service.ImpersonatedUserId = $ImpersonatedUserId #Impersonate service under userID

$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Root,$MailboxName) #MsgFolderRoot selection and creation of new root folder object

$f1 = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service, $MailboxName) #Binding folder under mailbox identity

$fold = get-mailboxfolderstatistics $MailboxIdentity #Getting complete list of selected mailbox

foreach ($mbxfolder in $fold){

#Define Folder View Really only want to return one object

$fvFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(100) #page size for displayed folders

$fvFolderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep; #Search traversal selection Deep = recursively

#Define a Search folder that is going to do a search based on the DisplayName of the folder

$SfSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::Displayname,$ #for each folder in mailbox define search

$findFolderResults = $service.FindFolders($folderid,$SfSearchFilter,$fvFolderView) #for each folder in mailbox define folder view (this is online task for store.exe) and perform search

if ($findFolderResults.TotalCount -eq 0){ "Folder Doesn't Exist" } #Info if folder still exist

else {"Folder Exist"

ForEach ($Folder in $findFolderResults.Folders) { #for each folder in folder results perform check of folder class

$folder.folderclass #Info about folder class

if ($Folder.folderclass -eq "IPF.Imap"){ #If folder class is target type, do change and update

$Folder.folderclass = "IPF.Note" #Folder class change in variable

Write-Host "Updating folder $ to correct type IPF.Note. Folder will start to be visible in OWA"

$Folder.update() #Folder class update in mailbox via EWS






The script will generate some output to host:

converting via script


Tips for good articles and tools

Here is articles list. I like those, need those and don´t have time to look for them again and again.

Active Sync features comparison:

Free e-mail checking tools:

RBAC manager

My friend’s Exchange-related blog!!!!

Exchange 2010 / 2013 DAG – Active manager determine/move

In some cases it is needed to determine which server is Active manager for DAG and move it away.

  • Determine which server is active manager

We can use two ways. Powershell or command line cmdlets.

In PowerShell we can use cmdlet:

Get-DatabaseAvailabilityGroup -status | select PrimaryActiveManager 

and parameter -Status is needed to gather current state of DAG.

In CMDline we need to be logged on the server, which is part of DAG or has Windows clustering installed. Then the commad line is simple:

cluster group

Move active manager

easiest way is to use cluster command:

cluster group "cluster group" /move:TARGETMACHINE