Messaging and Colloboration

Sunday, 23 April 2017

Execution Policies

Execution policies are windows security mechanism to control the execution of PowerShell scripts.
There are 4 types of Execution policies that we can set along with five different scopes.
Execution policies:
  1. Restricted - This is the most secure policy because we can’t run any PowerShell scripts in this mode.
  2.  All signed- This policy will allow you to run scripts but that script should be digitally signed by trusted publisher. You will get a prompt while running scripts to confirm the trust of publisher.
  3. Remote signed- It allow you to run scripts locally , but downloaded scripts must be digitally signed, it won’t  prompt to confirm the trust of publisher. This is the default execution policy in Windows Server 2012
  4. Unrestricted- No security, we can run any type of scripts.

  1. Machine policy
  2. User policy
  3. Process
  4. Current user
  5. Local machine

Scope values are listed in precedence order (from higher to lower). For example if you have Remote Singed policy with current user and All Signed policy with local machine scope, then Remote singed will be the effective.

How to change Execution policy?
Set – ExecutionPolicy –executionpolicy remotesigned
Above cmdlet will change the execution policy from default to ‘RemoteSigned’

To check the Execution policy
Simple type Get-ExecutionPolicy

How to get Execution policy of Remote computers
Sometimes you want to collect details about execution policies for all servers in your environment. You may think to use Get-ExecutionPolicy along with identity or computername parameter, but the trickiest part is Get-ExecutionPolicy cmdlet won’t support any such parameter, to check this ,type get-Executionpolicy |gm it will give below output in that no method/parameter is related to identity.

For this situation we can use  Invoke-Command- is a powershell remote management cmdlet that supports one to many remotings. This cmdlet allows you to execute PowerShell commands on multiple remote computers that don’t support -ComputerName parameter.

$servers = import-csv "C:\Users\dinesh\Desktop\servers.csv"
Foreach ($server in $servers)
     Invoke-Command -computername $ -Scriptblock {Get-Executionpolicy}

In the above script I am using csv file as the input which has all server names with “name” as the column name.


Wednesday, 19 April 2017

Mailbox Audit Logs

Mailbox Audit Logs:

Mailboxes may have sensitive and highly confidential information, sometimes we need to track who access that information and what action performed against that. For this purpose we can use ‘Mailbox audit logs’.
You can get details about Mailbox audit logs using the below simple cmdlet,

Get-Mailbox “user_alias” | fl *audit*

By default ‘AuditEnabled’ parameter is set to disable, because audit logs consume more spaces in user mailbox. Also you can get the maximum age for Audit logs, default is ’90 days’ after  90 days all audit logs will get deleted automatically.

How to enable audit logs?

It’s pretty simple to enable audit logs; we can directly use Set-Mailbox cmdlet to enable audit logs.

Set-Maibox "user_alias"  –auditenabled:$true

Once the mailbox is set to enable audit logs, then it starts logging actions performed on that.
Audit logs are stored in “Audits” folder under “Recoverable Items folder” of the user mailbox that cannot be viewed by Outlook. Below is the folder structure of audit logs
           -Recoverable Items

To check Audit folder size and items,

Get-MailboxFolderStatistics -Identity "audit_enabled_mailbox" | ?{$ -eq "Audits" -and $_.foldertype -eq "Audits"} | ft identity,itemsinfolder,foldersize –AutoSize

To get Audits folder contents, use the below cmdlet,

Search-MailboxAuditLog -Identity "audit_enabled_mailbox" -LogonTypes Delegate -ShowDetails -StartDate "04/10/2017" -EndDate "04/17/2017" | ft operation,operationresult,logonuserdisplayname,itemsubject,lastaccessed -autosize


Monday, 27 February 2017

ActiveSync Attachment Size Issue

           When people trying to send email with bigger attachments from mobile device, they will notice that email moves to Outbox and it will try resending in a timely fashion. Sometime people will get ‘memory full’ warnings after certain retries.

What we normally do?
 Obviously we will check the size of the attachment and our organization configurations, finally activesync’s web.config file [%ExchangeInstallPath%ClientAccess\Sync\web.config], in the  web.config file we need to consider certain parameters that accounts for attachment size,

  1.  maxDocumentDataSize ; default size is 10240000 bytes
  2.  maxRequestLength ; default size is 10240 KB
  3.  maxAllowedContentLength ; default size is 30000000 bytes

You will be amazed, the max allowed size is 10 MB but still user can’t send email with attachment size of 8Mb, do you know why?
Because of “33% Rule”

We have to subtract 33% from the total size,
If we subtract 33% from 10240 KB, then the resultant would be 6860.8 Kb, so if you configure ‘maxrequestlength’ value to 10MB, then user can send only 6.8MB of attachment (approx)

But, why 33percent ?
33% accounts for Base64 encoding of attachments.Base64 encoding normally increase the size of the messages by 33% that’s why its advisable to choose 33% more than the actual size.

Why we need Base64 encoding?
Some protocols may interpret your binary data or text as control characters or that it think it’s a combination of data and control data, inorder to avoid this situation, we need some encoding mechanism like Base 64.

So we need to change the foresaid parameter values in the web.config file to higher than the default.

Once done with changes , need to rest IIS (cmd -> IISreset) to take effect.

33% rule is not only applicable to Activesync, it also applicable to Exchange Web Services( EWS) and Outlook WebApp(OWA).


Sunday, 7 August 2016

Unified Messaging SCOM Alerts in Exchange 2013

UM  SCOM alert in Exchange 2013

UM.Protocol health set unhealthy (MediaEstablishedFailedMonitor) - Exchange Server Alert: The UM.Protocol Health Set detected  is unhealthy. - The A/V Edge service is misconfigured or isn''t operating correctly
Knowledge Base: us/library/ms.exch.scom.UM.Protocol(EXCHG.150).aspx?v=15.0.1178.4 - Date raised in SCOM: 2016-08-03T13:59:18


For these types of SCOM Alert, the very first action we have to take is launching Event viewer or Powershell. Here I am using Powershell to dig deep into the event logs. If you know which event log provider is responsible for logging UM events, then it’s very easy to use Powershell to get all UM related events.

Hint: ‘MSExchange Unified Messaging’

I am using Get-WinEvent cmdlet instead of its predecessor Get-EventLog (for easy filtering).

Get-WinEvent  -ProviderName  "MSExchange Unified Messaging"  -MaxEvents 30

The above cmdlet retrieves the most recent 30 events belonging to MSExchange Unified Messaging services.
So the next step is to search for twin sister events 1692, 1438. If twin sisters are there, Game Over!
Just try to get more details about Event ID 1692 & 1438. Event 1692 is very calm, she won’t give you much detail, but 1438 is chatterbox, even she will tell you what exactly needs to do to fix this alert.
Normally there are some limitations that holds you back when you are examining nuts and bolts on events in Powershell like you can’t read full message given by events, messages generated by UM events are bit lengthy when compared to other Events, so we can use formatting options like        Out-String along with ‘Width’ parameter.

Get-WinEvent  -FilterHashtable  @{ logname = 'application' ; id=1438 }  -MaxEvents 20 |ft message | Out-String  -Width 600

“The Microsoft Exchange Unified Messaging service on the Mailbox server has been configured to automatically use the Lync Server A/V Edge resources associated with ‘'. Inbound and outbound calls involving remote users (located outside the enterprise) might be failing using the current Lync Server A/V Edge resources. To correct the issue, set the SIPAccessService property using the Set-UMService cmdlet. The Microsoft Exchange Unified Messaging service will start using the Lync Server A/V Edge resources corresponding to the new value.”

So it’s clear that something needs to be tweaked from Exchange UM configuration . Normally these types of SCOM alert triggers on post migration situations mostly from Lync server 2013 to SFB 2015, what exactly triggers this SCOM alert is when Exchange server UM services were trying to communicate with legacy Lync Edge server pool.

How to make Exchange aware of that new configuration change? By running some cmdlets we can confirm that Exchange doesn’t have updated information.

Get-UMService | Select Name, Status, SIPAccessService
The above cmdlet will give output like this

Name            Status SIPAccessService
----            ------ ----------------
Ucpro001  Enabled
Ucpro002  Enabled
Ucpro003  Enabled
Ucpro004  Enabled
Ucpro005  Enabled
Ucpro006  Enabled

Here ‘Name’ column is nothing but your Exchange server (technically mailbox server), Status ‘enabled’ means it has been enabled for Unified messaging. But the most anticipated column ‘SIPAccessService’ is empty. If it is empty then, we can say exchange is unaware of new configurations. We could directly assign new Lync/SFB Edge server configuration to all our UM enabled Exchange servers.
But the question here is why Exchange needs Lync/SFB edge server pool address assigned?? Because users from outside network must use the closest Edge server pool for seamless RTP (Real time Transport Protocol) media traffic.

Once SDP negotiation is complete, RTP is used to send voice data back and forth between UM server and PBX or other UM server. RTP is merely a format for carrying audio and video data between endpoits, using dynamically assigned set of TCP and UDP ports.

The following cmdlet is used to assign SIPAccessService to UMServices.

Get-UMService | Set-UMService –SIPAccessService :5061
It’s good to restart UM Servers after assigning SIPAcessService.

Set-UMService will accept the following parameters,
            - Identity
            - Dialplans – it specifies all dial plan that UM services handles incoming calls for
            - IPAddressFamily – it specifies whether UM IP Gateway will use IPV4 or IPV6 or both
-MaxCallsAllowed – Max no.of concurrent calls allowed that UM services allows,        default:   100
            - UMStartupMode – it specifies star up mode for UM services. [TCP, TLS, Dual]
            - SIPAccessService*  - it specifies FQDN and TCP port number for the nearest Lync/SFB server for the inbound and outbound calls from remote users located outside the network.

             *When this parameter is not set (in a multi-pool environment), then Exchange UM service may select a Lync/SFB pool that is not closest geographically to the remote user. It’s optional in single pool environment. This parameter is set on a per-Unified Messaging service basis and must point to the Lync/SFB pool that is located the closest geographically to the Exchange server.

Thursday, 21 July 2016

Mailbox Permissions

Mailbox Permissions:
Exchange enables us to assign different levels of control over mailboxes. Exchange has three mailbox permission types under Mailbox Delegations,
  •  Send On Behalf Of
  • Send AS
  • Full Access

Send On Behalf Of:

You can grant someone else to send emails on behalf of you. The delivered email item clearly mentions that the mail has been sent by delegates on behalf of you.

Send As:
‘Send As’ permission will enable you to impersonate other people; it doesn’t have any tag like ‘send on behalf of’. If you have ‘Send As’ permission for others mailbox, then you can send emails by their name, by choosing ‘From’ option while composing emails. This permission works well with ‘Shared Mailboxes’.

Full Access:
Full access permission enables you to grant access to other person’s mailbox or any folders on their mailbox, the only thing is you should have mail-enabled windows user account. Also it has some limitations like you can’t send emails like ‘Send as’. Full Access means full access to complete mailbox.

Comparisons of various permission types
Send On Behalf Of
Send As
Full Access
Delivered email has tag like ‘on behalf of ‘
No tags like ‘send on behalf of’
Can’t send emails when having full access permission alone.
Behind the scene, ‘Send on behalf of’ feature requires Exchange to transport some additional information in message headers, so that recipients can identify the original sender.
‘Send as’ feature requires a user to possess Active Directory permissions to impersonate some else.
When EAC assigns ‘Full Access’ permission, it uses fully distinguished name of the mailbox, but when granting permission via EMS, we can use any identifiers like display name, email address etc.,
Set-Mailbox –Identity  “dbabu” –GrantSendOnBehalfTo “vkarthick”

The above cmdlet grant permission to vkarthick to send emails on behalf of dbabu.
For ‘Send As’ permission we need to manipulate windows permission rather than Exchange property.

Add-ADPermission –Identity “Helpdesk” –ExtendedRights “SendAs” –user “user1”

The above cmdlet assigns ‘send as’ permissions for the “Helpdesk” account to “user1” mailbox

Note: use windows account name instead of Exchange display name.
Add-MailboxPermission –Identity “sharedmx” –user “user1” –AccessRights “FullAccess”

Above cmdlet assigns full access permission to user1 mailbox against ‘sharedmx’ mailbox.

How long it will take to apply permission changes?
Sometimes people can send emails immediately after administrator grant ‘send as’ permission to other mailbox, sometimes people complaining , still they can’t send emails by others name. It’s all because of MSExchange Information Store Cache.

Normally it will take upto an hour or more than an hour to apply the ‘Send as’ or ‘Full Access ‘permission changes. Actually we are applying some changes to the user object in Active Directory, Exchange have to query Active Directory for the changes, also that changes can’t be immediately available for Exchange server. By using ADAccess component Exchange query’s Active Directory in a regular interval of time to get the updated content and caches those changes in it for a certain period of time. This cache is commonly called as Mailbox Information cache (MBI) and how long the content should be available on MBI cache should be determined by the parameter ‘Mailbox cache Age Limit’, default value is 120 mins(2hours).‘Send as/Full Access’ permission changes will apply once MBI cache refreshes itself.

How to avoid complaints from users?
It clearly understood that ‘Mailbox Cache Age Limit’ is responsible for delays.
1. Restart the Information Store service - but it’s not a good practice because it forces all clients to disconnect.
2. Reduce the MBI Cache refreshing time from 2 hours to 30/20 minutes, but it’s also not advisable.
The best practice is to allow the Exchange server to take its own time to apply the changes.
Mailbox Auto Mapping:
Consider the scenario where the user is granted full access to other user’s mailbox, then during Auto Discover process, it brings user’s own mailbox plus additional mailboxes where using is having full access. Basically Auto Discover process query active directory to find whether the account (base) it’s running has access to any additional mailboxes. This is done by looking a user property called “MSExchDelegateLinkList” in Active Directory. 

If user is having access to other mailboxes, then Auto Discover manifest should have xml snippet like this
Sometime users don’t want to show their additional mailboxes in outlook, in that situation we can disable auto mapping functionality using Add-MailboxPermission cmdlet,

Add-MailboxPermission – Identity “TeamExchange” –user “Dinesh” –AccessRights ‘Full Access’  -AutoMapping: $False

Abbreviations used:
EAC – Exchange Control Panel
EMS – Exchange Management Shell
MBI Cache – Mailbox Information Cache

Friday, 15 July 2016

Mailbox Anchoring In Exchange Server 2013

In Exchange 2013 CAS locates where the mailbox by querying Active Directory for the user mailbox GUID, once it obtain the GUID, HTTP Proxy contacts Active Manager to find out the active copy of the database where the user’s mailbox . Once CAS knows where the user’s mailbox is located, then it proxy the connection to appropriate Mailbox Server. This functionality is same for all client protocols such as OWA, ECP and EWS except EMS (Exchange Management Shell)

In Exchange 2013(before CU11), shell opens connection to the local server or just proxy the connection to the other available Exchange server. But in Exchange server 2013 CU11 “Mailbox Anchoring” was introduced, as per the logic Exchange Management Shell will be connected to the mailbox server where the logged on user’s mailbox resides, if the logged on user doesn’t have any mailboxes, then it will connect to the Exchange server where system mailbox {bb558c35-97f1-4cb9-8ff7-d53741dc928c}(arbitration Mailbox) is located.

Mailbox Anchoring:
When a user/admin logs on to the Exchange Server and open up EMS, the session will be proxied to the server where the user’s mailbox is located.

When we upgrading existing Exchange environment (2010 à 2013) or (2013 à 2016) we must move the arbitration mailboxes to the higher version of Exchange databases else we will end up with issues.

To move the arbitration mailboxes,
Get-Mailbox  -Arbitration | New-MoveRequest  -TargetDatabase <Higher_Version_Exchange_Database>

EMS console will always display name of the CAS server that receive the initial connection, but in background the connection may be proxied to different mailbox server.

To check which server your EMS is connected to, use the following cmdlets in EMS,
$env:COMPUTERNAME à will give you the local server name.

Get-ExchangeCertificate, will return the certificate for the server where EMS connected to it. We can find the server name in the subject of the certificate.

Thursday, 7 July 2016

Evolution of Offline Address Book (OAB) Architecture in Exchange Servers

Offline Address Book is used by outlook clients for address book lookup when it is configured for working in cached mode. Outlook client will always query local OAB first for address lookup. There were no major changes in OAB architecture after Exchange 2007. Team Exchange introduced major changes in OAB architecture in Exchange 2013.
In server side, OAB has 2 main phases,
  • OAB Generation
  • OAB Distribution

Below table differentiates OAB generation and distribution process in Exchange 2010 and 2013
Exchange 2010
Exchange 2013
OAB Generation:
  • OAB generation was bound to specific server (mailbox).
  •  First Exchange mailbox server was designated as OAB Generation server.
  • We can also add additional OAB Generation servers

Get-OfflineAddressbook “Default Offline Address book” | fl name,server
This cmdlet will give you which server is designated as OAB generation server.

Better user accessibility.
Single point of failure, since OAB generation was bound to specific server.

OAB Generation:
  •   OAB Generation was not bound to specific server. OAB is generated by Mailboxes.
  • It uses special type of ‘Arbitration mailboxes’ called “Organization Mailbox”

Get-OfflineAddressbook “Default Offline Address book” | fl name,server
This cmdlet won’t show any designated server.
Tip: if the above cmdlet won’t return any output, then run the below cmdlet,
Set-AdServerSettings -ViewEntireForest $true
Greater resiliency in OAB Generation.

Inefficient user experiences.
Component that generates OAB:

  • Microsoft Exchange System Attendant service

  • OAB Generation was a scheduled process, i.e. OAB generation would start at the scheduled time irrespective of the server load.
  • Default schedule runs at 5 AM every day.

Component that generates OAB:

  • OAB Generator assistant (time-based assistant).
  •  It’s a mailbox assistant running under MS Exchange Mailbox Assistants Service.
  • It’s a throttled process, so it runs or pauses based on the server load.

To view the OAB Generation schedule,
Get-OfflineAddressbook “Default Offline Address book” | fl name,schedule

OAB Storage:

OAB generated by mailbox servers are stored in “C:\Program Files\Microsoft\Exchange Server\V14\OAB”. Then folder was shared so that CAS could retrieve OAB files for distribution.

OAB Storage:

In Exchange 2013, OAB files are generated and stored in Organization mailbox first later  copied to “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB”
OAB Distribution:

Exchange 2010 supports 2 types of distribution,
  • Web Distribution
  • Public folder distribution

Steps involved in OAB distributions,
  1. Outlook receives OAB URL from Autodiscover and reaches CAS server.
  2. CAS pulled OAB (using MS Exchange File Distribution service) generated on the mailbox server and stored it locally.
  3. CAS authenticate users and serves OAB file from its local storage.

OAB Distribution:

Exchange 2013 supports only Web distribution method

Steps involved in OAB distribution,
  1. Exchange 2013 CAS doesn’t store anything. So It proxies all OAB download request to appropriate mailbox server.
  2.  Outlook receives OAB URL from Autodiscover and reaches CAS server through OAB URL.
  3. CAS performs initial authentication for OAB requests.
  4. CAS Queries AD to find the closest organization mailbox for that user
  5. Also CAS queries Active manager to find out the mailbox server that’s hosting active mailbox database copy.
  6.  Then CAS Proxy the request to the identified Mailbox severs.
  7. Retrieves OAB and passes them to client.

In Exchange 2013, OAB files are stored in “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB” location. Specifically OAB files are stored to GUID folder of the OAB object. Inside this subfolder lot of .lzx files were created along with .xml files. In fact OAB files are first stored in temp location in OAB folder before they are copied to GUID folder.
Evolution of OAB Architecture since Exchange 2010.
In Exchange 2010, OAB was generated by a particular server within your organization.

In a distributed messaging environment, each site has an OAB generated based on ‘Default Global Address List’, it allow local users to download OAB without any traversing. If travels other site then his outlook application download OAB changes via WAN link, it’s a costly process. This architecture offers greater flexibility but it’s prone to Single point of Failure.
So in Exchange 2013 OAB is generated by a special type of ‘Arbitration Mailbox’ called ‘Organization mailbox’ rather than a server. It also utilizes Exchange 2013 high availability (DAG) by keeping database copies in various servers.

For connectivity,
  1. Autodiscover provides OAB url for the site which has user’s mailbox.
  2. That url resolves to a CAS server.
  3. CAS server will proxy the request to the mailbox server implies OAB mailbox in the local site

a.      If there is no OAB generation mailbox in the local AD site, CAS picks the mailbox in other sites with ‘lowest connection cost’.
                                                              i.      In other site, more than one OAB mailbox with the same connection cost found, then CAS will chose one at random.

Some shortfalls of this architecture,
  • Each OAB generation mailbox generates and stores all the OAB’s in the environment. In the above scenario both Redmond and Portland OAB generation mailbox generate Redmond and Portland OAB’s.
  • Each OAB generation mailbox generates an OAB that is unique when compared to the same OAB generated by other OAB generation mailboxes.

If user travels other site, outlook application will download full OAB each time outlook synchronization request is processed in a different site.

Also Having more than one OAB generating mailbox in a single site leads to a problem because they produces two unique, separate instances of both OAB generating mailboxes. Consider an example, If Redmond site has two OAB’s, then user who is having mailbox in Redmond is directed to Redmond CAS, and the CAS proxies to any one of the OAB mailboxes, so each time outlook client will directed to different OAB, resulting in a full OAB download each time.

To address some inefficiencies in above situation, Exchange Server 2013 Cumulative Update 5 came up with a solution called “Dedicated OAB Generation Mailboxes”. In CU5 an OAB can only be assigned to a single OAB generation mailbox.

So now Redmond users will only download the Redmond OAB from the Redmond AD site and Portland users will only download the Portland OAB from the Portland AD site.
However the above architectural changes did not improve user accessibility in a distributed environment. So Microsoft introduced a new concept “Shadow Distribution” in CU7.

Exchange 2013 Cumulative Update 7 introduces the capability for an OAB generation mailbox to host a shadow copy of another OAB. This functionality enables additional Mailbox servers to be an endpoint for OAB download requests. This feature is disabled by default.

Consider an example, user who is having mailbox in Redmond travelling to Portland. So the client got OAB url via autodiscover response, so the client will now access the Redmond OAB using a URL resolving to the Portland CAS infrastructure ( oab guid/). This is accomplished by Autodiscover leveraging the X-SourceCafeHeader value specified in the HTTP proxy request.

The first attempt made to access OAB will resulting 404 response (OAB does not exist on the Portland mailbox server that hosts OAB generating mailbox). This event invokes the OABRequestHandler, which initiates an asynchronous transfer, via BITS, of the Redmond OAB files to the Portland MBX server hosting the OAB generation mailbox. During the next attempt to synchronize the OAB, user’s Outlook client is able to download the necessary OAB files locally.

How to enable Shadow Distribution?
GlobalWebDistributionEnabled and VirtualDirectoriesproperties of an OAB are still used by Autodiscover to determine which CAS OAB virtual directories are eligible candidates for distributing the OAB. Also it is recommended to enable ‘global web distribution’ for all OAB’s hosted on Exchange 2013.
Set-OfflineAddressBook <Name_of_OAB> -VirtualDirectories $null
Set-OfflineAddressBook < Name_of_OAB > -GlobalWebDistributionEnabled $true
Prior to enabling shadow distribution, you should deploy an OAB generation mailbox in each AD site where Exchange 2013 infrastructure is deployed.
New-Mailbox -Arbitration -Name "New_OAB_Mailbox" -Database "MDB004" -UserPrincipalName –DisplayName "New OAB Mailbox"
Set-Mailbox "New OAB Mailbox" –Arbitration –OABGen $true
Once global distribution is enabled and OAB generation mailboxes are deployed, you can then enable shadow distribution on per-OAB basis,
Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $true