GAL Photos in Exchange 2010 and Outlook 2010
Over the years, displaying recipient photographs in the 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 unnamed IT person wrote ASP code to make employee photos show up on the intranet based on the Employee ID attribute in Active Directory - which was imported from the company's LDAP directory. A fun project to satisfy the coder alter-ego of the said 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 Active Directory. Active Directory 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. Photos in Active Directory? Really? 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 Active Directory database? And how much Active Directory replication traffic will this generate? The thumbnailPhoto attribute can accomodate photos of up to 100K in size, but the Import-RecipientDataProperty cmdlet won't allow you to import a photo that's larger than 10K. (Note, the attribute limit was stated as 10K earlier. This has been updated to state the correct value. -Bharat) 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 Active Directory, 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. Note: The recommended thumbnail photo size in pixels is 96x96 pixels. With that out of the way, let's go through the process of adding pictures. A minor schema change First stop, the Active Directory Schema. A minor schema modification is required to flip the thumbnailPhoto attribute to make it replicate to the Global Catalog. Note: If you're on Exchange 2010 SP1, skip this step. The attribute is modified by setup / SchemaPrep. 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 Fire up a MMC console (Start -> Run -> MMC) and add the Schema snap-in 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). 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 the Get-Mailbox cmdlet with your choice of filter (or use the Get-DistributionGroupMember cmdlet 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 Figure 2: Thumbnail displayed in a recipient's property pages in the GAL When you receive a message from a user who has the thumbnail populated, it shows up in the message preview. Figure 3: Thumbnail displayed in a message While composing a message, the thumbnail also shows up when you hover the mouse on the recipient's name. Figure 4: Recipient's thumbnail displayed on mouse over when composing a message There are other locations in Outlook where photos are displayed. For example, in the Account Settings section in the Backstage Help view. Update from the Outlook team Our friends from the Outlook team have requested us to point out that the new Outlook Social Connector also displays GAL Photos, as well as photos from Contacts folders and from social networks, as shown in this screenshot. Figure 5: Thumbnail photos displayed in the People Pane in the Outlook Social Connector More details and video in Announcing the Outlook Social Connector on the Outlook team blog. 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 recipient attributes included in an OAB are specified in the ConfiguredAttributes property of the OAB. ConfiguredAttributes is populated with a default set of attributes. You can modify it using the Set-OfflineAddressBook cmdlet 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 Active Directory. If an Outlook client (including Outlook Anywhere clients connected to Exchange using HTTPS) can access Active Directory, 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 photos you just uploaded...). Depending on the number of users and sizes of thumbnail photos uploaded, 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 Active Directory), 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 Updates: 11/3/2010: Corrected size limit of thumbnailPhoto attribute to 100K. 8/25/2011: Added note to reflect Exchange 2010 SP1 setup / SchemaPrep modifies thumbnailPhoto attribute to replicate to Global Catalog. GAL Photos now has an FAQ. Check out GAL Photos: Frequently Asked Questions. To visit this post again, use the short URL aka.ms/galphotos. To go to the 'GAL Photos: Frequently Asked Questions' post, use aka.ms/galphotosfaq.How to Export and Import mailboxes to PST files in Exchange 2007 SP1
There might be times when an Exchange Administrator will need to export the contents of individual mailboxes to offline files in order to present specific users with a format that is easily portable and ready to consume using Outlook clients. To fulfill this need Exchange 2007 SP1 will have a new set of features to export and import mailboxes to and from PST files. As I know you will ask - yes, those PST files can be bigger than 2 GB, which was a limitation of Exmerge tool used for this purpose in previous versions of Exchange. Export/Import to PST Requirements In order to export or import mailboxes to PST files the following requirements must be met: Export/Import to PST must be run from a 32 bit client machine with Exchange Management Tools installed (Version Exchange 2007 SP1 or later). The 32bit requirement comes from a dependency with the Outlook client. Either Outlook 2003 or Outlook 2007 must be installed on the client machine. The user running the task must be an Exchange Organization Admin or an Exchange Server Admin on the server where the mailbox to export/import lives. Exporting mailboxes to PST files The most basic cmdlet to export a mailbox to a PST file is as follows: Export-Mailbox –Identity <mailboxUser> -PSTFolderPath <pathToSavePST> PSTFolderPath must be a full path pointing either to a directory or to a (.pst) file. If a directory is specified a PST file named after the mailbox alias will be used as the target of the export. Note that if the PST file already exists the contents of the mailbox will be merged into it. Example: After the cmdlet finishes execution, the .pst file will be ready in the specified location: To export multiple mailboxes to their respective .pst files at once you can pipe in the identities of those mailboxes to the export task. Notice that when bulk exporting the PSTFolderPath parameter must forcefully point to a directory since one .pst file will be created for each mailbox. Example: Get-Mailbox -Database 'MDB' | Export-Mailbox -PSTFolderPath D:\PSTs Importing mailboxes from PST files The process for importing mailbox contents from a PST file is quite similar: Import-Mailbox -Identity <mailboxUser> -PSTFolderPath <PSTFileLocation> Again, PSTFolderPath must be the full path to the directory where the .pst file lives or to the (.pst) file itself. In the case where PSTFolderPath points to a directory the cmdlet will try to match the mailbox alias with the name of an existing .pst file in the specified directory and import the content of that file. Example: Just as with the export to PST scenario, when bulk importing mailboxes the PSTFolderPath must forcefully point to a directory and the task logic will try to match mailboxes alias with the .pst file names under that location. If no match is found for a particular mailbox, that mailbox will be skipped. Example: Get-Mailbox -Database 'MDB' | Import-Mailbox -PSTFolderPath D:\PSTs Filtering content in Export/Import to PST When only specific content is desired in the PST file (or back into the mailbox) a common set of filters can be used to leave out the rest of the messages. Export/Import to PST support the following filters: Locale, StartDate, EndDate, ContentKeywords, SubjectKeywords, AttachmentFileNames, AllContentKeywords, SenderKeywords, and RecipientKeywords. Example: Import only those messages that were created between 1/1/06 and 12/1/06 and contain the word "review" in the subject and any of the words {"project","alpha"} in the body. Import-mailbox -Identity ricardr -PSTFolderPath D:\PSTs -StartDate 1/1/06 -EndDate 12/1/06 -SubjectKeywords:'review' -ContentKeywords:'project','alpha' Now, we realize that you would like to try this today, but please be patient! - Ricardo Rosales GuerreroResolving WinRM errors and Exchange 2010 Management tools startup failures
As was discussed in the previous (related) blog post "Troubleshooting Exchange 2010 Management Tools startup issues", in Exchange 2010 the Management tools are dependent on IIS. As was discussed in that blog, we have seen situations where the management tool connection to the target Exchange server can fail, and the error that is returned can be difficult to troubleshoot. This generally (but not always) happens when Exchange 2010 is installed on an IIS server that is already in service, or when changes are made to the IIS server settings post Exchange Install. We have seen that these changes are usually done when the IIS administrator is attempting to "tighten up" IIS security by editing the Default Web Site or PowerShell vdir settings. The situation is further complicated by the fact that some of the errors presented have similar wording; most seem to originate with WinRM (Windows Remote Management), and in some cases different root problems can produce the exact same error message. In other words, depending on how knowledgeable you are with these errors, troubleshooting them is all around... not much fun. I was approached by a good friend of mine and he asked what I thought we could do to make these errors a little easier to troubleshoot. I was studying PowerShell and PowerShell programming at the time (I just happened to be reading Windows PowerShell for Exchange Server 2007 SP1), and I thought that this would be a perfect opportunity to try and apply what I was learning. This is the result. Introducing the Exchange Management Troubleshooter (or EMTshooter for short). What it does: The EMTshooter runs on the local (target) Exchange server and attempts to identify potential problems with management tools connection to it. The troubleshooter runs in 2 stages. First, it will look at the IIS Default Web Site, the PowerShell vdir, and other critical areas, to identify known causes of connection problems. If it identifies a problem with one of the pre-checks it will make a recommendation for resolving the problem. If the pre-checks pass, the troubleshooter will go ahead and try to connect to the server in the exact same way that the management tools would. If that connection attempt still results in a WinRM-style error, the troubleshooter will attempt to compare that error to a list of stored strings that we have taken from the related support cases that we have seen. If a match is found, the troubleshooter will display the known causes of that error in the CMD window. Here is an example of how this might look like: When I was designing the troubleshooter, I could have just written a little error lookup tool that handed over the appropriate content for the error you were getting, but I felt that was not as robust of a solution as I was aiming for (and not much of a learning experience for me). So the tool runs active pre-checks before moving on to the error look-up. The amount of pre-checks it can run depends on the flavor of OS you are running on and the options you have installed on it, such as WMI Compatibility. Basically, I have taken all of the documentation that has been created on these errors to date, and created a tool that will make the information available to you based on the error or problem it detects. Hopefully this will cut down on the amount of time it takes to resolve those problems. Event reporting: When you run the EMTshooter it will log events in the event log. All results that are displayed in the CMD window are also logged in the event log for record keeping. Events are logged to the Microsoft-Exchange-Troubleshooters/Operational event log and are pretty self-explanatory. Things to remember: Depending on your current settings, you may need to adjust the execution policy on your computer to run the troubleshooter, using: Set-ExecutionPolicy RemoteSigned Or Set-ExecutionPolicy Unrestricted Remember to set it back to your normal settings after running the troubleshooter. This version of the troubleshooter needs to run on the Exchange Server that the management tools are failing to connect to. While our final goal is that the troubleshooter will be able to run anywhere the Exchange Management tools are installed, the tool isn't quite there yet. We have seen instances where corruption in the PowerShell vdir or in IIS itself has resulted in errors that seemed to be caused by something else. For instance, we worked on a server that had an error that indicated a problem with the PowerShell vdir network path. But the path was correct. Then we noticed that the PowerShell vdir was missing all its modules, and quite a few other things. Somehow the PowerShell vdir on that Exchange Server had gotten severely... um... modified beyond repair. WinRM was returning the best error it could, and the troubleshooter took that error and listed the causes. None of which solved the problem. So be aware that there are scenarios that even this troubleshooter cannot help at this time. The troubleshooter is still a bit rough around the edges, and we plan to improve and expand its capabilities in the future. We also hope to be able to dig a little deeper into the PowerShell vdir settings as time goes on. Also note that the troubleshooter will NOT make any modification to your IIS configuration without explicitly asking you first. Permissions required: In order to run the troubleshooter, the user will have to have the rights to log on locally to the Exchange server (due to local nature of the troubleshooter at this time) and will need permissions to run Windows PowerShell. Installing the troubleshooter: First, you will need to download the troubleshooter ZIP file, which you can find attached to this post. Installing the EMTshooter is pretty easy. Just drop the 4 files from the ZIP file into 1 folder, rename them to .ps1 and run EMTshooter.ps1 from a normal (and local) PowerShell window. I personally just created a shortcut for it on my desktop with the following properties: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command ". 'C:\EMTshooter\EMTshooter.ps1'" However, as most users probably won't run this more than a few times you might not need or want an icon. Just remember that EMTshooter.ps1 is the main script to run. Providing feedback: As I mentioned before, the troubleshooter is still a work in progress. If you wish to provide feedback on it, please post a comment to this blog post. I will be monitoring it and replying as time allows, and also making updates to the troubleshooter if needed. If you run into errors that are not covered by the troubleshooter, please run the troubleshooter, reproduce the error through it and send me the transcript.txt file (you will find it in the folder where the 4 scripts have been placed), along with what you did to resolve the error (if the problem has been resolved). My email is sbryant AT Microsoft DOT com. Errors currently covered: Connecting to remote server failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. Connecting to remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'. Connecting to remote server failed with the following error message : The WinRM client received an HTTP status code of 403 from the remote WS-Management service. Connecting to the remote server failed with the following error message: The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: Connecting to remote server failed with the following error message : The WS-Management service does not support the request. Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer - Steve BryantControlling Exchange ActiveSync device access using the Allow/Block/Quarantine list
Note: Customers looking for more device access or management control in Microsoft 365, should explore Basic Mobility and Security or Microsoft Intune. What is the Allow/Block/Quarantine list? In Exchange 2010 we added a feature called the Allow/Block/Quarantine list (or ABQ for short). This feature was designed to help IT organizations control which of the growing number of Exchange ActiveSync-enabled devices are allowed to connect to their Exchange Servers. With this feature, organizations can choose which devices (or families of devices) can connect using Exchange ActiveSync (and conversely, which are blocked or quarantined). Some of you may remember my previous post on this topic dealing with organizations that do not have Exchange 2010 and thus I wanted to show you the far better way you can do this in Exchange 2010 (which is also what you will see in Office 365 and Exchange Online if you are looking at our cloud-based offerings). It is important to understand that the ABQ list is not meant to displace policy controls implemented using Exchange ActiveSync policies. Policy controls allow you to control and manage device features (such as remote wipe, PIN passwords, encryption, camera blocking, etc.) whereas the ABQ list is about controlling which devices are allowed to connect (for example, there may be a lot of devices that support EAS PIN policies, but some IT departments only want to allow certain devices to connect to limit support or testing costs). The easy takeaway is that Exchange ActiveSync policies allow you to limit device access by capabilities while the Allow/Block/Quarantine list allows you to control device access by device type. If you're curious as to what devices OS support which policies, the Wikipedia article we blogged about is a good place to look. Different device access models for different folks When we designed the ABQ list, we talked to a lot of organizations to find out how all of you use (or wanted to use) this kind of technology. What we realized is that there is a continuum of organizations; from permissive organizations that let employees connect whatever device they have to their Exchange Server, all the way to restrictive organizations that only support specific devices. Since we always want to make our software as flexible for IT as possible (as we know there are a lot of you folks that are using our software in a lot of different ways) we created this feature so that no matter which type of organization you are (or even if you are one that is in between these two extremes) we could help meet your needs. Below are some descriptions and "how-to"s for using the ABQ list in these different ways. The restrictive organization Restrictive organizations follow a more traditional design where only a set of supported devices is allowed to connect to the Exchange server. In this case, the IT department will only choose to allow the particular devices they support and all other devices are blocked. It's important to note that a restrictive organization is created by specifying a set of allowed devices and blocking the unknown. The permissive organization: Permissive organizations allow all (or most) to connect to their Exchange Server. In these cases, the ABQ list can help organizations block a particular device or set of devices from connecting. This is useful if there's a security vulnerability or if the device is putting a particularly heavy load on the Exchange server. In these cases, the IT department can identify the misbehaving device and block that device until a fix or update for that device brings it into compliance. All other devices, including the unknown devices, are given access. The one off case: Of course, if you are limiting the devices that connect to your organization, there's almost always a need for an exception. Whether it's testing a new device before rolling it out to the organization as a supported device, or an exception made for an executive, we wanted to give you the ability to make an exception without allowing all users with that device to access your organization's email and PIM data. When to quarantine: Quarantining devices is useful when an IT department wants to monitor new devices connecting to their organization. Both permissive and restrictive organizations may choose to employ this mechanism. In a permissive organization, quarantine can be used so that IT administrators know what devices, and which users, are making new connections. In restrictive organizations, this can be used to see who is trying to work around policy and also gauge demand from "Bring Your Own Device" (BYOD) users. Now that we've gone through the theory, let's talk about how we would do this in practice. Accessing the ABQ settings: Log in to the Exchange Control Panel (ECP) (you can also access the ECP from Outlook Web App (OWA) by selecting Options > See all options) In the ECP , make sure you are managing My Organization (#1 in the screenshot below). Be aware that most users won't see the "My Organization" option — it's only visible to users with Exchange Administrator access. Select Phone & Voice (#2 in the screenshot below) > ActiveSync Access tab (#3 in the screenshot below). This is the Allow/Block/Quarantine configuration screen. Note for all you Exchange Management Shell (EMS) gurus, you can also configure device access using PowerShell cmdlets if you prefer. Creating a device (or a family of devices) rule: To create a new rule, select New from the Device Access Rules section of the ABQ page (#5 in the screenshot above). When setting up a rule for a device, it is important to understand the difference between the "family" of the device and the specific device. This information is communicated as part of the EAS protocol and is reported by the device itself. In general, you can think of the deivce rule as applying only to the particular device type (like an HTC-ST7377 as shown in the image below) whereas a device family might be something more broad like "Pocket PC". This distinction between the specific (device type) and the general (device family) is important since many device manufacturers actually release the same device with different names on different carriers. To make it so that you don't have to make a separate rule for each device. For instance, the HTC Touch Pro was available on all four majour US carriers as well as some of the regional ones, and that's just the USA, not to mention the other versions around the world. As you can see, making a rule for each of those different devices (which are all in the same family and effectively the same device) could mean a lot of extra work for IT, so we added the family grouping to help you make good decisions about devices in bulk. It's important to note that when making a new rule you select the device family or the model but not both. Once you've selected the device or a device family, you can then choose what Exchange will do with that device (in this example, I'm just going to do a specific device). This brings you to the New Device Access Rule page. The easiest way to set the rule is to select Browse, which will show you a list of all the devices or device families that have recently connected to your Exchange Server. Once you've selected the device or family, you can choose the action to take. This is where you can choose to block the device if you are a permissive organization looking to limit a specific device for a specific reason or where you can set access rules if you are a restrictive organization (in such a case you would just create an allow rule for each supported device and then set the state for all unknown devices to block (we'll talk about how to set the action for unknown devices in the next section)). Once you select the action (Allow access, Block access, or Quarantine), click Save and you're done! You can repeat this process for each rule you want to create. You can also have both block and allow rules simultaneously. Setting up a rule for unknown devices: To access the rule for unknown devices, select Edit (#4 in Figure 5 above). On the Exchange ActiveSync Settings page, you can configure the action to take when Exchange sees a user trying to connect with a device that it does not recognize. By default, Exchange allows connections from all devices for users that are enabled for EAS . This example configures the Exchange organization to quarantine all unknown devices. This means that if there's no rule for the device (or device family) or if there's no exception for the particular user, then an unknown device will follow this behavior. Quarantine notifications We have the ability to specify who gets an email alert when a device is placed in quarantine. You can add one or more administrators (or users) or even a distribution group to this list of notified individuals. Anyone on this list will receive an email like the one shown in the screenshot below. The notification provides you information about who tried to connect the device, the device details and when the attempt was made. Custom quarantine message You can also set a custom message that will be delivered to the user in their Inbox and on their device. Although the device is in quarantine, we send this one message to the device so the user doesn't automatically call help desk because their device isn't syncing. The custom message is added to the notification email to the user that their device is in quarantine. The user and device will also now appear on the Quarantined Devices list on the ABQ configuration page. Managing Quarantined Devices The device will stay in quarantine until an administrator decides to allow or block the device in quarantine. This can be done by selecting the device and then clicking on the Allow or Block buttons in Quarantined Devices. This creates a personal exemption (the "one off case" mentioned earlier). If you wish to create an access rule that is to apply to all devices of the same family or model, you can select Create a rule for similar devices to open a new, prepopulated, rule. Making changes: Of course we realize that many organizations are dynamic and have changing requirements and policies. Any of the rules that have been set up can be changed dynamically by accessing the ABQ page in the ECP and editing, deleting, or adding the desired rule. Adam Glick (@MobileGlick) Sr. Technical Product Manager P.S. To read about Microsoft's licensing of Exchange ActiveSync, check out this article on Microsoft NewsCenter. Julia White also put up a more business focused blog in the UC Blog about the importance of EAS to Exchange 2010 customers.Modern Auth and Unattended Scripts in Exchange Online PowerShell V2
Today, we are happy to announce the Public Preview of a Modern Auth unattended scripting option for use with Exchange Online PowerShell V2. This feature provides customers the ability to run non-interactive scripts using Modern Authentication.
