Mailhelp

Over the years, displaying recipient photographs in Exchange Server/Outlook's Global Address List (GAL) has been a frequently-requested feature, high on the wish lists of many Exchange folks. Particularly in large organizations or geographically dispersed teams, it's great to be able to put a face to a name for people you've never met or don't frequently have face time with. Employees are commonly photographed when issuing badges/IDs, and many organizations publish the photos on intranets.

There have been questions about workarounds or third-party add-ins for Outlook, and you can also find some sample code on MSDN and elsewhere. A few years ago, an IT person wrote ASP code to make employee photos show up on the intranet based on the Employee ID attribute in Active Directory (AD) - which was imported from the company's LDAP directory. A fun project to satisfy the coder alter-ego of the IT person.

Luckily, you won't need to turn to your alter-ego to do this. Exchange 2010 and Outlook 2010 make this task a snap, with help from AD. AD includes the Picture attribute (we'll refer to it using its ldapDisplayName: thumbnailPhoto) to store thumbnail photos, and you can easily import photos- not the high-res ones from your 20 megapixel digital camera, but small, less-than-10K-ish ones, using Exchange 2010's Import-RecipientDataProperty cmdlet.

The first question most IT folks would want to ask is- What's importing all those photos going to do to the size of my AD database? And how much AD replication traffic will this generate? The cmdlet won't allow you to import a picture larger than 10K. The original picture used in this example was 9K, and you can compress it further to a much smaller size - let's say approximately 2K-2.5K, without any noticeable degradation when displayed at the smaller sizes. If you store user certificates in AD, the 10K or smaller size thumbnail pictures are comparable in size. Storing thumbnails for 10,000 users would take close to 100 Mb, and it's data that doesn't change frequently.

With that out of the way, let's go through the process of adding pictures.

A minor schema change

1. If you haven't registered the Schema MMC snap-in on the server you want to make this change on, go ahead and do so using the following command:

   Regsvr32 schmmgmt.dll

2. Fire up a MMC console (Start -> Run -> MMC) and add the Schema snap-in
3. In the Active Directory Schema snap-in, expand the Attributes node, and then locate the thumbnailPhoto attribute. (The Schema snap-in lists attributes by its ldapDisplayName).
4. In the Properties page, select Replicate this attribute to the Global Catalog, and click OK.
   
   Figure 1: Modifying the thumbnailPhoto attribute to replicate it to Global Catalog

Loading pictures into Active Directory

Now you can start uploading pictures to Active Directory using the Import-RecipientDataProperty cmdlet, as shown in this example:

Import-RecipientDataProperty -Identity "Bharat Suneja" -Picture -FileData ([Byte[]]$Get-Content -Path "C:\pictures\BharatSuneja.jpg" -Encoding Byte -ReadCount 0))

To perform a bulk operation you can use Get-Mailbox cmdlet with your choice of filter (or Get-DistributionGroupMember if you want to do this for members of a distribution group), and pipe the mailboxes to a foreach loop. You can also retrieve the user name and path to the thumbnail picture from a CSV/TXT file.

Thumbnails in Outlook 2010

Now, let's fire up Outlook 2010 and take a look what that looks like.

In the Address Book/GAL properties for the recipient

When you receive a message from a user who has the thumbnail populated, it shows up in the message preview.

While composing a message, the thumbnail also shows up when you hover the mouse on the recipient's name.

There are other locations in Outlook where photos are displayed. For example, in the Account Settings section in the Backstage Help view.

GAL Photos and the Offline Address Book

After you've loaded photos in Active Directory, you'll need to update the Offline Address Book (OAB) for Outlook cached mode clients. This example updates the Default Offline Address Book:

Update-OfflineAddressBook "Default Offline Address Book"

In Exchange 2010, the attributes in an OAB can be customized. This is done using the ConfiguredAttributes property of the OAB (see Set-OfflineAddressBook cmdlet). ConfiguredAttributes is populated with the default set of attributes, and you can modify it to add/remove attributes as required.

By default, thumbnailPhoto is included in the OAB as an Indicator attribute. This means the value of the attribute isn't copied to the OAB- instead, it simply indicates the client should get the value from AD. If an Outlook client (including Outlook Anywhere clients connected to Exchange using HTTPS) can access AD, the thumbnail will be downloaded and displayed. When offline, no thumbnail downloads. Another example of an Indicator attribute is the UmSpokenName.

You can list all attributes included in the default OAB using the following command:

(Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes

For true offline use, you could modify the ConfiguredAttributes of an OAB to make thumbnailPhoto a Value attribute. After this is done and the OAB updated, the photos are added to the OAB- yes, all 20,000 of them. Of course, this would add significant bulk to the OAB. Test this scenario thoroughly in a lab environment- chances are you may not want to provide the GAL photo bliss to offline clients in this manner.

To prevent Outlook cached mode clients from displaying thumbnail photos (remember, the photo is not in the OAB- just a pointer to go fetch it from AD), you can remove the thumbnailPhoto attribute from the ConfiguredAttributes property of an OAB using the following command:

$attributes = (Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes
$attributes.Remove("thumbnailphoto,Indicator")
Set-OfflineAddressBook "Default Offline Address Book" -ConfiguredAttributes $attributes

-Bharat Suneja

Exchange CXP team has released Update Rollup 2 for Exchange Server 2010 RTM (KB 979611) to the download center.

KB 979611 lists all the fixes included in this rollup. Here are some of the product improvements and critical bug fixes we'd like to call out starting with a couple of IMAP improvements:

1. KB 977633 This fixes IMAP4 clients ability to log on to their mailboxes if the mailboxes are located on Exchange 2003 backend servers and if the clients are connecting via Exchange 2010 CAS servers.
2. KB 979480 IMAPid was not working correctly after moving a lot of users from one Exchange 2010 server to another*. IMAP4 users complained about the inbox not being updated any more. Old messages were still visible, but messages which were received after the mailbox move were not visible. The problem affected different IMAP Clients. The problem did not affect MAPI clients and OWA. Now it is fixed up. *(Specifically this occurred in the situation with same DAG, now local storage instead of iSCSI storage, all servers are Exchange 2010 with Update Rollup 1 installed on Windows Server 2008 R2).
3. KB 979431 When user migrated from Exchange Server 2003 to Exchange Server 2010, and that user connected via POP3, the POP3 service crashed. This was fixed up so it will not crash.
4. KB 979563 Push Notifications didn't work because Exchange Server 2010 was not sending SOAPAction header in the notify callback. This caused Exchange to receive a HTTP 500 response from the notification client and the webservice failed. Push notifications should now properly send that SOAP header.
5. KB 980261 We fixed passive page patching when diagnostic tracing code was needed for forensic analysis that was generating a -1022 error case.
6. KB 980262 Source side log copier errors are more gracefully handled when the log has a bad block and the read fails.
7. KB 979566 Activesync proxy was failing for linked mailboxes in a CAS to CAS proxy scenario where the users token is serialized and sent in the request. When attempting to create the client security context from the SID, a AuthZException was thrown because we did not have access to the token information of the linked account, so now for this it no longer throws exceptions.

Only the English Rollup?

Customers may not install the rollup because they may feel that this should only be installed on an English Exchange Server. This was true for Exchange 2007 and is not true for Exchange 2010. When installing this rollup, the UI will be English and the “Add/Remove Programs” text will be English. We are expecting to release the other rollup installation language strings with the next rollup. We are finishing UI validation.

Known Issue

With Update Rollup 2 for Exchange Server 2010 RTM, we introduced a new parameter for the Set-ClientAccessServer cmdlet, CleanUpInvalidAlternateServiceAccountCredentials. Unfornately, the parameter cannot be used at this time, however the Set-ClientAccessServer cmdlet still functions with all other available parameters.

The cmdlet functions but not the parameter because of how RBAC works at the Organization\Enterprise level. The change functions as expected, except for this one issue. This issue blocks some functionality offered by this particular fix. We have a work around and we are currently performing testing and ensuring that we document it correctly. It will require running “Install-CannedRbacRoles” on one server after the rollup is installed. Once replication happens across the AD, the parameter will be available for use for the servers that have the rollup installed.

KB 979611 has more details about this release and a complete list of all fixes included in this rollup.

-Exchange

For various reasons, there are times when an administrator does not want a part of the ECP to be accessible by some users and they desire a features' tab or entry point to not be visible at all. The web.config file for the Exchange Control Panel (ECP) contains the requirements a logged in user must meet before the feature tab or configuration item may be displayed in the UI.

Here we will step through an example of how to go through the process of determining what you must do to accomplish this task.

IMPORTANT: Exchange Control Panel files are not modified to accomplish this — the process only involves changing the user's RBAC Role assignment.

SUPPORT NOTE: Modifying the Exchange Control Panel files to remove parts of the UI is not supported. Serious problems may occur if you modify web.config files. The only supported way of removing a feature from the ECP is by modifying the effective rights a user has using RBAC, as documented in this post.

In Exchange 2010, Role Based Access Control (RBAC) is the new permissions model that allows you to assign granular permissions based on management roles. To learn more about RBAC, see Understanding Role Based Access Control in Exchange 2010 documentation, and the previous post RBAC and the Triangle of Power.

Remove the Delivery Reports tab for a user

1. To remove the Delivery Reports tab from ECP for a user, we need to determine what's needed for the tab to show. To get this information, we need to check the Web.Config file located in ECP's folder at ":\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Reporting". ECP uses the authorization section of the Web.Config file to evaluate if the tab should be displayed. If the user is not allowed to run the cmdlet shown, the tab is not displayed. Let's view the Authorization section of the Deliveryreports.slab location path:
   

   <location path="DeliveryReports.slab">
          <system.web>
              <authorization>
                   <allow roles="Search-MessageTrackingReport@R:Organization" />
                   <!-Deny everyone else ->
                   <deny users="*" />
               </authorization>

   As shown in the above figure, access to the Search-MessageTrackingReport cmdlet is required to display the Delivery Reports tab. To disable the Delivery Reports tab, we need to determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, so we can remove the permission for the user to run it. This ensures the tab will not be displayed to that user.
   
   To determine which RBAC roles can run the Search-MessageTrackingReport cmdlet, we use the Get-ManagementRole cmdlet:
   

   Get-ManagementRole -cmdlet Search-MessageTrackingReport

   The result:
   

   Name                   RoleType
   -------                --------------
   Message Tracking       MessageTracking
   View-OnlyConfiguration ViewOnlyConfiguration
   MyBaseOptions          MyBaseOptions

   Next we must determine which of the above roles the user is a member of and where it would make sense to remove the Search-MessageTrackingReport cmdlet from. For example, we wouldn't want to remove the cmdlet from the ViewOnly Configuration because that is an administrative role. The user is not an administrator, and therefore it's not likely that he/she has been assigned the MessageTracking role. This means that we will have to check to see what roles/assignments the user is a member of:

   Get-RoleGroup | where {$_.Members -like "*Display UserName*"} | fl name

   The command doesn't return any results because the user is not a member of any administrator type role. Next, we will check the management role assignments for this user:

   Get-ManagementRoleAssignment -RoleAssignee UserName

   Among other items you see the list of roles (note these are user/self configuration roles):

   Name                                                         Role
   --------                                                     ---------
   MyBaseOptions-Default Role Assignment Policy                 MyBaseOptions
   MyContactInformation-Default Role Assignment Policy          MyContactInformation
   MyVoiceMail-Default Role Assignment Policy                   MyVoiceMail
   MyDistributionGroupMembership-Default Role Assignment Policy MyDistributionGroupMembership
   Custom Default Policy                                        MyDiagnostics

   It looks like the only one we are interested in here is the "MyBaseOptions" because we already know that the cmdlet we want to block is only available in that role that the user has anything to do with. The user is not an administrator so the other roles are not interesting to us for this scenario.

   To make sure the user is assigned to the role assignment policy we can verify:

   Get-Mailbox UserName | fl roleassignmentpolicy

   RoleAssignmentPolicy: Default Role Assignment Policy

   Tip: If you want to combine some of the above steps into one line to find out which role contains that cmdlet we are interested in (Search-MessageTrackingReport), you can use the following set of cmdlets:
   

   Get-ManagementRole -Cmdlet Search-MessageTrackingReport | Get-ManagementRoleAssignment -RoleAssignee UserName -Delegating $False | FT Role, RoleAssigneeName

   
   The result:
   

   Role            RoleAssigneeName
   ----            ----------------
   MyBaseOptions   Default Role Assignment Policy

2. Now, we know that we need to create a new Role Assignment Policy for the user and associate it with a new (customized) MyBaseOptions role. We will make a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it.

   First, we will create a new (end user) Role Assignment Policy called Alternate Assignment Policy, and leave the original policy unchanged (for other users who should still have access to the Delivery Reports tab).:

   New-RoleAssignmentPolicy "Alternate Assignment Policy"

   For this new policy, we need to turn on a few of the default options that the Default Policy had. For example, to add the ability for the user to edit their own contact information we add the MyContactInformation role to the policy:
   

   New-ManagementRoleAssignment -Name "MyContactInformation-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyContactInformation

   
   To add the ability for the user to manage their own distribution group membership, we add the MyDistributionGroupMembership role to the policy:
   

   New-ManagementRoleAssignment -Name "MyDistributionGroupMembership-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyDistributionGroupMembership

3. Now we need to create a copy of the MyBaseOptions role so we can remove the Search-MessageTrackingReport cmdlet from it and then assign it to the new Role Assignment Policy. We can give it any name, preferably something with a good description.:

   New-ManagementRole "MyBaseOptionsWithoutMessageTracking" -Parent MyBaseOptions

4. We remove the Search-MessageTrackingReport cmdlet from the "MyBaseOptionsWithoutMessageTracking" role:

   Remove-ManagementRoleEntry "MyBaseOptionsWithoutMessageTracking\Search-MessageTrackingReport"

5. Next, we assign the newly created MyBaseOptionsWithoutMessageTracking role to the Role Assignment Policy:

   New-ManagementRoleAssignment -Name "MyBaseOptionsWithoutMessageTracking-Alternate Assignment Policy" -policy "Alternate Assignment Policy" - role MyBaseOptionsWithoutMessageTracking

6. Then, we assign the Role Assignment Policy to the user:

   Set-mailbox mod1user1 -RoleAssignmentPolicy "Alternate Assignment Policy"

   This can also be performed in the ECP, as shown in figure 2.

   
   Figure 2: Assigning the Role Assignment Policy to the user in ECP
   

Done! Now we can test the user experience. As shown in figure 3, when UserName logs on, the Delivery Reports tab isn't visible.

After the Delivery Reports tab is removed, if your user tries to track a message from within Outlook Web App or Outlook, he/she will receive the following error:

-Perry Newman