Thursday, July 28, 2016

Clear Outlook AutoComplete Cache

Microsoft Outlook maintains a nickname list that is used by both the automatic name checking feature and the automatic completion feature. The nickname list is generated automatically as users use Outlook. If the nickname cache is corrupted, Outlook may be unable to identify recipients, may offer incorrect recipients when automatically completing the email address, or may send the message to the wrong person.
Please note that the AutoComplete list for Outlook is specific to Outlook and is not shared by Outlook Web App (OWA). OWA maintains its own AutoComplete list.

Unlike earlier versions of Outlook that store the nickname cache in a file on the local computer, Outlook 2010 and later versions store the nickname cache in the user’s primary message store. This means that deleting the entire nickname cache is no longer a matter of deleting the famous .NK2 file.

To reset the whole Outlook nickname cache for Outlook 2010 and later versions, first open Outlook, go to the File tab, click Options, click the Mail tab and, under Send messages, click Empty Auto-Complete List:

Outlook will then generate a new nickname cache.

Alternatively, you can close Outlook, click the Start menu, click Run (depending on which version of Windows you are using), and start Outlook by using the /CleanAutoCompleteCache switch: Outlook.exe /CleanAutoCompleteCache
Outlook will start up and generate a new nickname cache.

Exchange Shell Certificate Error

The other day, a colleague of mine experienced an issue when updating the certificate for one of his Exchange servers. After using the EAC to update the certificate, the Exchange Management Shell would not start and give the following error:
New-PSSession : [server.domain.com] Connecting to remote server server.domain.com failed with the following error message : [ClientAccessServer=server,BackEndServer=server.domain.com,RequestId=357032aa-2312-477e-be88-8d99 db9027c5,TimeStamp=07/12/2016 23:10:21] [FailureCategory=Cafe-SendFailure]  For more information, see the about_Remote_Troubleshooting Help topic.

In the System event log we would find the following:
Log Name:      System
Source:        Microsoft-Windows-HttpEvent
Date:          6/18/2016 4:45:40 PM
Event ID:      15021
Level:         Error
Computer:      server.domain.com
Description: An error occurred while using SSL configuration for endpoint 0.0.0.0:444.  The error status code is contained within the returned data.

Because this was a passive server of a DAG, no users were connecting to it so they were not impacted. However, we were not able to access OWA/EAC directly on this server.

The problem turned out to be in IIS and the fact that the new certificate was not binding to the Exchange Back End site. To fix it, open IIS, expand the server name, expand Sites, right-click on Exchange Back End and select Edit Bindings. In the new window, select https and then click Edit...:

As you can see, no SSL certificate was selected:

To fix it, simply select the new certificate from the SSL certificate drop-down box and click OK.

Saturday, June 18, 2016

Check Distribution Groups Created

Some organizations provide self-service for Distribution Groups (DG), that is, users are able to create DGs that are available in the Global Address List for everyone to use. Even if an organization does not have a naming convention in place, it is always important to keep an eye on what DGs are created in case a user creates one that is not acceptable.

To do this, we can use the Get-DistributionGroup cmdlet together with the WhenCreated parameter to search for DGs created in the last week, for example. However, using this cmdlet we can see who the DG’s manager is but not exactly who created it. So, we need to use the Admin Audit Logs feature already covered in some tips and articles at MSExchange.org such as the Administrator Audit Logging article by Neil Hobson. Since we will be relying on this feature, it is important that it is enabled and that we keep these logs for as long as we need to.

Another advantage of using these logs, is that we can check for DGs that were created and subsequently deleted!

The following basic script will search the Admin Audit Logs for any DG created and return some information about it such as when it was created, by whom and its display name:
Param (
 [Parameter(Position = 0, Mandatory = $False)]
 [String] $From = "01/01/2016"
)


[Array] $DGs = @()

Search-AdminAuditLog -StartDate $From -Cmdlets New-DistributionGroup | Sort RunDate | % {
 $DG = $_.ObjectModified.Split("/")
 $DG = $DG[$DG.count - 1]

 $user = $_.Caller.Split("/")
 $user = $user[$user.Count - 1]
 $userDN = (Get-Mailbox $user).DisplayName

 $DG = New-Object PSObject -Property @{
  Date  = $_.RunDate
  UserAlias = $user
  UserDN  = $userDN
  DG  = $DG
 }

 $DGs += $DG

}

$DGs | Sort Date | FT Date, UserAlias, UserDN, DG -AutoSize

  
 
For a more complete report, please check my Exchange Distribution Group Creation Report article on MSExchange.org which generates an HTML report similar to:
 


Enable or Disable File Formats for Exchange Search

In Exchange 2013/2016, Exchange Search includes built-in support for indexing many file formats. In order to enable or disable specific file formats for Exchange Search, we use the Set-SearchDocumentFormat cmdlet (which is only available in on-premises Exchange 2013/2016).

When we disable a file format for content indexing by Exchange Search, contents of the file become unsearchable by Exchange Search clients such as Outlook Web App, Outlook in online mode and In-Place eDiscovery.

Let us say that we do not want to include ZIP files. To do this, we simply run the following cmdlet:
Set-SearchDocumentFormat ZIP -Enabled $False

If we disable indexing for a supported file format, such as in the example above, items containing an attachment of that file type are not considered unsearchable. When we perform an In-Place eDiscovery search, and we select the option to include unsearchable items, only items that are actually unsearchable are returned. Items that were not searched because the associated file format is set as unsearchable are not returned.

Please note that JPG and GIF formats are not really used even if enabled. Exchange indexes their metadata but will not scan/OCR the image itself. Exchange will deliberately skip over images and mark the items as partially processed.

Undo Ignore Conversation in Outlook

Outlook has a great feature that allows us to “ignore” particular email conversations that do not really interest us without asking the sender(s) to remove us from future emails. When we select Ignore on an email message, Outlook deletes that email and it also keeps track of all future emails related to the ignored message. If a future email related to the originally ignored email arrives in our Inbox, Outlook automatically moves these future emails to our Deleted Items folder.
 
But how about if we no longer want to ignore a particular conversation? Easy! Simply remove the “ignore” status of the email thread using the following steps:
    1. Select your Deleted Items folder;
    2. Select the email that is currently set to be ignored by Outlook;
    3. Click Ignore on the Delete section of the Home tab on the ribbon:
 
    4. If prompted, click Stop Ignoring Conversation:

 At this point, the email is automatically moved from our Deleted Items folder to the folder from which the it originated, and future emails for this thread will not be automatically deleted.

We can determine if an email is being ignored by the status of the Ignore button in the ribbon. If the Ignore button is highlighted (as in the screenshot above), the conversation thread on that email is currently being ignored by Outlook.

When we enable the Ignore option on a conversation, a message is created in the Associated Contents table of the Conversation Action Settings folder of our mailbox (which we can look at using MFCmapi for example):


It is important to have the following in mind:
  • If there is no activity on a thread for 14 days, the conversation action message for the thread is automatically deleted;
  • The age of the conversation action message is determined by the oldest message for the conversation;
  • We can modify the number of days at which the conversation action messages expire using the following registry data:
    • Key: HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Options\Conversations
    • DWORD: OnGoingActionsExpiration
    • Value: integer specifying the number of days after which an inactive conversation has its conversation action message deleted.
  • We can start Outlook using the following switch to delete all conversation action messages: Outlook.exe /CleanConvOnGoingActions. Using this switch will not move emails back to their original location, but because the conversation action message no longer exists for the conversation, any new messages for the conversation will remain in the Inbox;
  • We can also get different behavior from this feature, depending on the version of Exchange being used:

o   With Exchange 2007 and a cached mode profile, Ignore is based on SUBJECT. For example, any message with “Help!” as the subject will be automatically sent to Deleted Items as long as we clicked Ignore for a previous message with Help! as the subject;

o   With Exchange 2010 and later versions, Ignore is based on the CONVERSATION ID and only the messages related to the same ignored conversation are automatically sent to the Deleted Items folder.

 

Wednesday, June 15, 2016

432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded

The Exchange Team wrote a post named Store Driver Fault Isolation Improvements in Exchange 2010 SP1 a while back regarding a new feature introduced in Exchange 2010 SP1 to throttle the volume of messages delivered to a single recipient.
 
However, this featured caused some issues for organizations with a large volume of emails to Public Folder and, more commonly, a Journal mailbox. In these cases, administrators will see mail queues with the following error:
432 4.3.2 STOREDRV.Deliver; recipient thread limit exceeded
 
The solution mentioned is to create the following two keys:
<add key="RecipientThreadLimit" value="2" />
<add key="MaxMailboxDeliveryPerMdbConnections" value="3" />
 
And add them to the EdgeTransport.exe.config file (located at ...\Program Files\Microsoft\Exchange server\V15\Bin).

However, for organizations using Exchange 2013 or 2016, these two keys need to be added to the MSExchangedelivery.exe.config file located in the same folder!

After adding the keys, restart both the Microsoft Exchange Transport (MSExchangeTransport) and Microsoft Exchange Mailbox Transport Delivery (MSExchangeDelivery) services.

Friday, May 20, 2016

Improved “Automatic Reply” options in OWA

You might have noticed that since last April Microsoft has added a few new (great!) options to the Automatic Replies feature in Outlook on the Web:


These options make it easier to clear our calendar and automatically decline meetings before we head out for some time away from the office. When we set an automatic reply in Outlook on the web, Outlook offers to do the following on our behalf:
1. Block our calendar so people know we are away;
2. Clear existing meetings on our calendar by declining/cancelling them;
3. Automatically send a response to incoming invitations while we are away.



Block my calendar for this period
This option will create an appointment for the duration of our automatic reply with the title we specify:


Automatically decline new invitation for events that occur during this period
Outlook is now able to automatically decline a new invitation on our behalf while we are away! With this option, users will immediately know we will not be attending a meeting that gets scheduled while we are away. After responding on our behalf, Outlook will leave the invitation in our inbox so we know what happened while we were gone.

Decline and cancel my meetings during this period
That last option is to decline and cancel events currently in our calendar. When we now set an automatic reply, Outlook on the web finds all events that occur while we are away and gives us the option to indicate which meetings we would like to cancel or decline, as well as give you reply options to include.

First we select a reply to use when cancelling these meetings:

And then we can select which meetings we actually want to cancel:

Outlook on the web selects all meetings with attendees by default, leaving events without any attendees unchecked (as these are normally reminders or notes users create for themselves). If there is a meeting we don’t want to cancel, we simply uncheck it from the list and Outlook on the web will leave the event in our calendar.

How cool are these new options?! No more manually blocking our calendar and rejecting meetings one by one! Now I just hope this will come to Exchange on-prem soon, but it won’t surprise me if it takes a few good months...


Wednesday, May 18, 2016

Outbound DKIM Signing in Office 365

About a year ago, I wrote an article entitled DKIM and DMARC in Office 365 where I explored what DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are, and how exactly they work with Exchange Online in Office 365.

At the time of writing that article, Office 365 only supported inbound validation of DKIM over IPv4 and IPv6. Outbound DKIM signing was not yet available but was in the roadmap. Well, it is here now!

To continue reading about DKIM signing in Office 365, please check this article at MSExchange.org.

Remote Exchange Monitoring and Reporting using Email

We all know how crucial a messaging service is to most organizations. With the exception of maybe telephones, businesses today rely on email and messaging systems more than any other piece of infrastructure. Every Exchange administrator knows the importance of continuously monitoring Exchange, not only to prevent downtime and quickly fix problems after they occur, but also to be aware of the health of the infrastructure and to help identify potential problems and performance degradations before they turn into problems and cause downtime.

Monitoring solutions like Microsoft’s System Center Operations Manager, SolarWinds, Nagios, MailScape, etc., are just some examples of monitoring tools for Exchange. However, some organizations do not provide access to these tool’s consoles or dashboards outside the internal network. So what happens if an administrator is out and about without anything other than his/her phone and needs to check if this user has gone over their quota and cannot send emails, on which server a particular database is mounted, or even if ServerA has just been rebooted?

These type of situations might be rare, but I have personally been there and it would have been extremely useful if I could send an email to my mailbox with a particular PowerShell cmdlet and get the output of that cmdlet back. And this is what this article is about. We will develop two basic scripts that will monitor incoming emails between two users (for security reasons), run the cmdlet(s) in the email’s subject and reply with the output from that same cmdlet. The first script will use Message Tracking Logs while the second Exchange Web Services (EWS).

To continue reading, please check this article at MSExchange.org.
 
 

Saturday, May 14, 2016

Clutter Disabled by Default in Exchange Online? No!

There have been some discussions online where people are saying that Clutter seems to be disabled by default for new mailboxes in Exchange Online. It turns out that Clutter has not been disabled by default for new Office 365 mailboxes. As we know, Clutter is a learning system, and it requires a certain lower limit of messages in the mailbox to confidently learn about a user's behaviour before Clutter is auto enabled for a mailbox. This means that, for newly created mailboxes and mailboxes that are migrated from an on-premises environment into Exchange Online, the following requirements need to be meet:
  1. At least 1,000 messages delivered to the mailbox after the mailbox was created or migrated;
  2. The user needs to have logged into the mailbox once after creation/migration.
 
After both these requirements are meet, Clutter is auto enabled for that mailbox within 24 hours.

"The Delegates page is not available" Error Message

The other day, a user was trying to give his new personal assistance Delegate permissions to his mailbox. However, whenever he clicked on Delegate Access:

He would receive an error message stating: “The Delegates page is not available. Cannot access Outlook folder.

After some troubleshooting and digging around, it turned out that this was being caused by a particular Outlook (Inbox) rule! I am still to investigate why this rule was causing this problem and why would any rule prevent configuring delegates, so this is still a mystery...

If you are experiencing the same problem, simply disable any existing rules one by one until you are able to configure delegates. Alternatively, you can start Outlook by typing “Outlook /CleanRules” in the Start Menu to start Outlook and delete all rules (probably not recommended).

Thursday, May 5, 2016

Product Review: Stellar Exchange Toolkit v7.0

In this product review, I reviewed the latest version of Stellar Exchange Toolkit, v7.0 launched in March 2016. This toolkit is designed to help Exchange administrators extract data from corrupt Exchange EDB or backup files, easily convert OST to PST files, and to reset domain account passwords. It supports all Exchange versions since 5.5 and all it requires is a machine running Windows Vista / Server 2003 or above to install the software, plus a version of Outlook compatible with the Exchange server being used in order to perform certain export/import operations.

The Toolkit, as the name suggests, is a collection of the following tools that we will review one by one:
  • Stellar Phoenix Mailbox Exchange Recovery
  • Stellar Mailbox Extractor for Exchange Server
  • Stellar OST to PST Converter
  • Stellar Mailbox Extractor for Exchange Backup
  • Stellar Phoenix Password Recovery for MS Exchange

To read the full review, please visit MSExchange.org.
 
 

Wednesday, May 4, 2016

Determine Client Used to Send Email

Just recently someone asked me if there was a way to determine which email client (Outlook, OWA or ActiveSync) was used to send a particular email. On top of that, this person was also interested is finding out how many emails are sent per day using each of these clients.

The good news is that the Message Tracking Logs register this information. Every email sent has a SourceContext property which contains, amongst other information, the ClientType used to send the email. The important thing is to check this property for SUBMIT events, i.e., when the Mailbox Transport Submission service successfully transmits the email to the Transport service.

For SUBMIT events, the SourceContext property contains the following details:
  • MDB: the mailbox database GUID;
  • Mailbox: the mailbox GUID;
  • Event: the event sequence number;
  • MessageClass: the type of message. For example, IPM.Note;
  • CreationTime: date and time of the message submission;
  • ClientType: for example OWA or ActiveSync.


Please note that this only applies to emails sent by internal users. There is no SUBMIT event when an external sender sends an email to an internal user, meaning there is no ClientType property for these emails. In these cases, the only information we have regarding the sender is what the email headers contain, which does not include email client information.

To check what email client was used to send a particular email, we can run something like the following cmdlet and look at the SourceContext field:
Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT -Sender nuno@nunomota.pt -MessageSubject Test | Select SourceContext

This field will contain information like the following:
MDB:34f3dc86-91bb-4ee7-a6a5-3d3ddc536050, Mailbox:a1de664f-9826-43a3-b9c8-3db019c86d8b, Event:29647741, MessageClass:IPM.Note, CreationTime:2016-05-11T07:17:14.922Z, ClientType:MOMT

In this case, MOMT stands for MAPI on the Middle Tier, basically clients that connect using Outlook or any other application that connects using RPC/HTTP or MAPI/HTTP.

To count the number of emails sent using OWA today, we can run something like this:
(Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 05/11/2016 -EventID SUBMIT | Where {$_.SourceContext -match "OWA"}).Count

Easy as that! :)

Friday, April 29, 2016

Empty StorageLimitStatus when running Get-MailboxStatistics in Exchange 2013/2016

The old version of this script, used to gather some statistics out of mailboxes, made use of the StorageLimitStatus attribute of mailboxes (when running the Get-MailboxStatistics cmdlet). However, if you run the script in an Exchange 2013/2016 environment, you will notice that this attribute is always blank while with Exchange 2010 it is not... Unfortunately, this is by design...
 
Unlike versions of the Information Store earlier than the one that comes with Exchange 2013, the Information Store in Exchange 2013 does not cache the values of mailbox quotas. Therefore, the Information Store makes frequent calls to Active Directory (AD) to retrieve the values of mailbox quotas for each mailbox that is specified in the Get-MailboxStatistics cmdlet. Because of the frequent calls to AD, admins may experience poor performance in Exchange. To avoid this, the default Get-MailboxStatistics cmdlet does not retrieve the mailbox quotas and does not display a value in the StorageLimitStatus field...
 
To work around this issue, all we can do is either use the Exchange Admin Console (EAC):
  1. Log on to EAC by using a user account that is assigned at least the Mail Recipients role;
  2. In the feature pane, click recipients. A list of mailboxes is displayed;
  3. Select the mailbox of which you want to verify the quota status and then click the Edit button on the toolbar;
  4. Click mailbox usage. The mailbox quota usage is displayed.
Or we can use the Exchange Management Shell and run the following cmdlet:
Get-Mailbox "user" | FT *quota*, *size -AutoSize

The script has now been updated for Exchange 2013/2016 environments to work around this "issue".

Outlook Chinese NDR

There is a known bug with Outlook 2010 and 2013 that causes Non Delivery Reports (NDR) to be converted to Chinese-like characters when they are forwarded:


The same NDR does not get converted when being forwarded using OWA or when forwarded as an attachment.

The good news is that there are updates to fix this:

Saturday, April 23, 2016

Monitor Mailbox Database Transaction Logs

Excessive database and/or transaction log growth is, unfortunately, not an uncommon problem in Exchange deployments. On top of being hard to troubleshoot, if it is found too late, it can cause serious issues for users and even the business. As such, it is crucial to have an adequate monitoring solution. However, this is not the case in every single organization, so I decided to write a basic script to keep an eye on the number of logs being generated across databases.
 
You can, for example, run the script every hour and if any database currently has more logs than a specified threshold, it sends an alert by email with the number of transaction logs for all databases, highlighting the one(s) that triggered the alert, and the current free space for the database (you might need to update it depending on whether you have the .edb file and logs on the same or different locations).
 
The script simply counts all files in the LogFolderPath location (variable for each database) as this makes it quicker than only looking for *.log files, and still be accurate for what we want to achieve.

You can download the complete final script from the TechNet Script Gallery.

Friday, April 22, 2016

Preserving Auto-Forwarded Messages in Exchange

Over the last few versions of Exchange, the Information Protection team has done an amazing job in improving Exchange’s compliance capabilities. One of these features, called In-Place Hold, does a great job in preserving mailbox items. However, it did not capture emails automatically forwarded by users. This can be important as sometimes emails are forwarded without a copy of the email being stored in the user’s mailbox.



If the email does not get delivered to the mailbox at all, it cannot be placed on hold and, as such, will not be available for eDiscovery. For organizations wanting to stay in compliance, the recommendation has been to either disable automatic forwarding completely or to use Journaling.

Well, not anymore! Microsoft has rectified this and now Exchange Online is able to capture auto-forwarded messages. Transport detects if the user that has AutoForwarding configured is on hold and, if yes, automatically preserves a copy of the email in the Recoverable Items folder, making it available to eDiscovery.

At the time of writing this tip, this feature does not yet seem to be available in Exchange 2016 RTM, but it is already available in Exchange Online. In the following screenshot, we can see an eDiscovery search that contains an item that was sent from Nuno to Mota when Mota had auto forwarding configure to an external recipient without a copy being saved in Mota's mailbox. As we can see, the email was still placed on hold:
 

Thursday, April 21, 2016

Search Admin Audit Log Old Properties

When searching the Admin Audit Log using the Search-AdminAuditLog cmdlet, you might find some useful information missing:
Search-AdminAuditLog -Cmdlets Set-TransportService

ObjectModified     : EXAIO
CmdletName         : Set-TransportService
CmdletParameters   : {MessageTrackingLogMaxAge, MessageTrackingLogMaxDirectorySize, Identity}
ModifiedProperties : { }
Caller             : nunomota.pt/Users/Admin
Succeeded          : True
Error              : None
RunDate            : 9/10/2015 8:47:48 AM
OriginatingServer  : EXAIO (15.00.1104.000)

From the above, we can see what was changed (the maximum age for the logs and the maximum allowed size for the directory) but not what these settings were changed to...

To see this, we have to dig deeper into CmdletParameters:
(Search-AdminAuditLog -Cmdlets Set-TransportService).CmdletParameters

Name                                 Value
----                                 -----
MessageTrackingLogMaxAge             45.00:00:00
MessageTrackingLogMaxDirectorySize   10 GB (10,737,418,240 bytes)
Identity                             EXAIO

Now we know exactly what the user Admin changed! But what about if we want to know what these settings were before this change?

By default, the administrator audit log records only the cmdlet name, cmdlet parameters (and values specified), the object that was modified, who ran the cmdlet, when the cmdlet was run, and on what server the cmdlet was run. The administrator audit log does not log what properties were modified on the object. If we want the audit log to also include the properties of the object that were modified, we need to enable verbose logging by setting the LogLevel parameter to Verbose:
Set-AdminAuditLogConfig –LogLevel Verbose

When we enable verbose logging, in addition to the information logged by default, the properties modified on an object, including their old and new values, are included in the audit log:
(Search-AdminAuditLog -Cmdlets Set-TransportService).ModifiedProperties

Name                                 NewValue      OldValue
----                                 --------      --------
MessageTrackingLogMaxAge             45.00:00:00   31.00:00:00
MessageTrackingLogMaxDirectorySize   10 GB         5 GB

Now we know exactly what got changed and what the old configuration was!

User Photo in Exchange, Lync and Active Directory

There are several posts out there about how to upload users’ photos into Active Directory (AD) so they can be used by Exchange or Lync, but very few on how this works or how to export them if we need to.

In AD we can use images no greater than 96×96 pixels in resolution and 100KB or smaller in size. This looks ok in the Lync and Outlook client, but results in a blurred photo when Lync, for example, attempts to upscale the image for use in a conference.

In Lync 2013 (and Skype for Business Server 2015) photos can be stored in the user's mailbox (when using Exchange 2013), allowing for photo sizes up to 648x648 pixels. In addition to that, Exchange automatically resizes these photos for use in different products as needed:
  • 64x64 pixels (96 dpi, 24 bit depth, approx. 2KB), the size used for the AD thumbnailPhoto attribute. If we upload a photo to Exchange, Exchange will automatically create a 64x64 pixel version of that photo and update the user's thumbnailPhoto attribute. However, if we manually update the thumbnailPhoto attribute in AD the photo in the user's mailbox will not automatically be updated. This photo is only used by Lync 2010 or legacy clients, so we are ok;
  • 240x240 pixels if the original picture is larger than 240, otherwise 96 (96dpi, 24 bit depth, approx. 8KB), for use in Outlook, OWA, Skype for Business Web App, and Skype for Business;
  • 648x648 pixels for use in Skype for Business and Skype for Business Web App.


Importing Photos
To use high resolution photos, we have to use the Set-UserPhoto Exchange cmdlet:
Set-UserPhoto “Nuno Mota” -PictureData ([System.IO.File]::ReadAllBytes(“D:\Photos\nuno.jpg”)) –Confirm:$False

As already mentioned, the Set-UserPhoto cmdlet does two things: it stores a copy of a high resolution image in the user’s Exchange mailbox, and stores a copy of the photo as a 64×64 image in the thumbnailPhoto AD attribute.


Exporting Photos
To check someone’s photo, we can use Exchange Web Services and the following URL (updating the user’s email and maybe image size):
https://mail.domain.com/ews/Exchange.asmx/s/GetUserPhoto?email=nuno@domain.com&size=HR648x648
 
If we want to export a user’s photo from AD, we can PowerShell and the following commands:
$photo = (Get-ADUser nuno -Properties thumbnailphoto).thumbnailphoto

We can now save this photo into a JPEG file and or import it directly to a different user for example (useful if the user gets a new account):
Set-Content “D:\Photos\nuno.jpg” -Encoding byte
Set-ADUser mota -Replace @{thumbnailphoto = $photo}

However, if we are using Exchange 2013, we should use Exchange cmdlets to manage users’ photos. This way we can export the 648x648 pixels photo from the user’s mailbox instead of the small one from AD:
(Get-UserPhoto nuno).PictureData | Set-Content “D:\Photos\nuno.jpg” -Encoding byte

If you want to use high resolution photos in Lync as well, you might want to ensure you update your Lync Client policy with a MaxPhotoSizeKB of at least 100 instead of just 30.

Mailbox Database Seed Status

Seeding large mailbox databases can potentially take a long time. Although it is something that usually does not need to be monitored, it is always good to keep an eye on it to see how it is doing. The Get-MailboxDatabaseCopyStatus cmdlet gives us all the information we need for this.

Usually I use this cmdlet in the following format to ensure the mailbox database copies on a particular server are mounted and/or healthy:
Get-MailboxDatabaseCopyStatus -Server "server_name" | Sort Name


But we can use it to get further details for a particular mailbox databases (the following output has been shortened to only include the most relevant information for this tip):

[PS] C:\>Get-MailboxDatabaseCopyStatus “MDB01\EXAIO” | FL

Identity : MDB01\EXAIO
DatabaseName : MDB01
Status : Seeding
MailboxServer : EXAIO
ActiveDatabaseCopy : EXMBX01
ActiveCopy : False
ActivationPreference : 3
IsLastCopyAvailabilityChecksPassed : False
LastCopyAvailabilityChecksPassedTime :
IsLastCopyRedundancyChecksPassed : False
LastCopyRedundancyChecksPassedTime :
ActivationSuspended : True
ContentIndexState : FailedAndSuspended
ContentIndexErrorMessage : Reseeding of the index is required.
ContentIndexErrorCode : 22
CopyQueueLength : 718053
ReplayQueueLength : 0
ReplicationIsInBlockMode : False
ActivationDisabledAndMoveNow : False
AutoActivationPolicy : Unrestricted
ReplayLagStatus : Enabled:False; PlayDownReason:None; Percentage:0; Configured:00:00:00;
Actual:00:00:00
DatabaseSeedStatus : Percentage:33; Read:95.19 GB; Written:95.19 GB; ReadPerSec:23.65 MB; WrittenPerSec:23.67 MB

DiskFreeSpacePercent : 60
DiskFreeSpace : 434.7 GB (466,730,405,888 bytes)
DiskTotalSpace : 717 GB (769,869,737,984 bytes)
DatabaseVolumeMountPoint : E:\Mount\edb09\
LogVolumeMountPoint : E:\Mount\edb09\



If we are particularly interested on the progress of the seed operation, we can filter the above output to only include what we want:
(Get-MailboxDatabaseCopyStatus “MDB01\EXAIO”).DatabaseSeedStatus