Disable Exchange 2010 SP1′s Auto Shared Mailbox Mapping Feature

You may remember from my previous article "Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2007 & 2010", since Exchange 2010 SP1 was released, granting a user permissions to another mailbox automatically adds the mailbox to the user's profile in both Outlook 2010 and fully patched Outlook 2007.

A few of the comments make it clear this isn't a universally-desired feature, in particular if you're an Admin and have access to a range of mailboxes (particularly system mailboxes like support addresses etc). Whilst it can be removed with ADSI edit after granting permissions, that's not a straightforward way to accomplish this.

To get round this and make it easy to add permissions without the auto-mapping I've written a straighforward script that can be used as a direct replacement to the normal Add-MailboxPermission command, Add-MailboxPermissionNoAutoMap.ps1.

Savvy Exchange Powershell coders will ask "why don't you do this using the Scripting Agent, disabling it across the board, even in Exchange Management Console".. Well that was my first thought. However, it appears that with Add-MailboxPermission the actual entries are added after the OnComplete section runs instead of before. If that get's fixed I'll certainly re-visit as it would be ideal to have a solution that allows the feature to be switched on or off on demand.

So, in the meantime, here's your drop in replacement Powershell script. It's very simple - it takes the standard parameters to the Add-MailboxPermission cmdlet and after ensuring we know what domain controller the command will act on (to ensure no replication confusion) it adds permissions the normal way, then removes the msExchDelegateListLink AD entry that has just been added.

Here's an example of it in use..


As you can see, it's very similar to the normal Add-MailboxPermission command - in fact it should accept all the same parameters and pass them through without modification. Hope you find it useful!
The full script is below, along with the file to download underneath:

Download AddMailboxPermissionNoAutoMap.zip

How to Export Exchange Message Tracking Logs to Excel

From time to time you may have a user request to find out what messages they should have received - perhaps they have marked them as Junk Email in Outlook, or deleted them accidentally. Whatever the reason, you might find it useful to be able to quickly pull the information for the user out of the message tracking logs and into a file quickly so they can have a look for themselves.

What this script does is searches for messages delivered to a particular user across all Hub Transport servers, sorts the information by the date and time and saves it to a convenient CSV file ready to open in Microsoft Excel.

How to use the script

Whilst the script is in use, you'll see progress of each log search:


After completion you should find your resulting CSV file similar to this:


Script Code

Script Download
Download Export-MessageTrackingLogsForRecipient.zip

Publishing IMAP, POP and SMTP settings via Exchange 2010 OWA

Do you allow your users to connect to Exchange 2010 directly via IMAP, POP and SMTP? If you do then not only will some Exchange admins call you crazy…  but you'll probably have to document the client settings such as server names, port and encryption settings somewhere and distribute it to users.

In Exchange 2010 there is actually somewhere to publish these settings - and once configured your documentation won't need to be updated if the server details change. You'll find these settings by logging into OWA, and choosing Options. The link "Settings for POP, IMAP, and SMTP access…" should be shown on the default "My Account" page:



By default, nothing will be listed if you click the link:



To configure these links, it's a fairly straightforward process. Before you begin, you need to know what the settings should be and in the case of the SMTP settings, which receive connector on which Hub Transport this relates to.

First, you configure the Client Access servers for the POP and IMAP settings, using the Set-POPSettings and Set-IMAPSettings cmdlets with the -ExternalConnectionSettings parameter.

For each protocol you specify a colon-separated list of values for the ExternalConnectionSettings. For POP3 with TLS, this might be "casserver.contoso.com:110:tls" or POP3 with SSL might be "casserver.contoso.com:995:ssl". IMAP with TLS might be "casserver.contoso.com:143:tls" and IMAP with SSL might be "casserver.contoso.com:993:ssl".

Here's a quick example of the commands against my test setup:

Set-POPSettings -ExternalConnectionSettings "mail.contoso.com:110:tls"Set-IMAPSettings -ExternalConnectionSettings "mail.contoso.com:143:tls"

It's important to remember, you need to run the command on all Client Access servers users will access.
Next, you need to allow the receive connector that you want "published" to advertise it's settings. You do this with the Set-ReceiveConnector cmdlet specifying the -AdvertiseClientSettings:$true parameter and value.
In my example, I want to advertise the port 587 "client" receive connector on my Hub Transport server:

et-ReceiveConnector -Identity "hubtransport\Client HUBTRANSPORT" -AdvertiseClientSettings:$true

Finally, run iisreset to restart IIS on each Client Access Server, the log back into OWA (well, ECP) and test the "Settings for POP, IMAP, and SMTP access…"  link again. It should now show the settings specified:



For further reading check out Set-IMAPSettings, Set-POPSettings and Set-ReceiveConnector.
(Just a footnote- thanks to Jag at Microsoft for providing this information)

Shared Exchange Calendars on iOS devices

Just a quick post on how to view an Exchange 2010 shared calendar/mailbox on your iPhone or iPad…
Once you’ve (or your admin has) configured Exchange to allow iCal publishing, you can then send links via email from the shared calendar mailbox itself:



On the iOS device, you can then click the webcal: link in the email, which will allow you to subscribe to the Calendar:



Simple!

VMware release Exchange 2010 "Best Practices Guide" [Updated]

I recently read via Virtualization.info that VMware have released their "Best Practices Guide" for Exchange 2010. It transpires this was actually released a couple of months ago, however it's the first time I've seen it and I certainly think if you run VMware vSphere and plan on running Exchange 2010 it's worth a read.

So from VMware, it's no surprise to hear that Exchange is a perfect workload to virtualize on their platform. If you're currently running vSphere, and considering virtualizing Exchange 2010, VMware will definitely support this on their ESX platform. However, there are a few caveats…

If you're currently running an Enterprise vSphere deployment, shared storage will most likely be your number one platform for all your VMs running in your virtual environment. Without it, the key VMware features like vMotion, DRS and VMware HA don't work and you're left with your eggs in a number of delicate baskets. So it won't be shock that VMware say "It is preferable to deploy virtual machine files on shared storage ".. "This is considered a best practice for mission-critical Exchange deployments, which are often installed on third-party, shared-storage management solutions.". While I agree with the first part of that, I certainly don't agree that it's still best practice to use shared storage for Exchange - for starters Exchange 2010 no longer supports single copy clusters and CR based clusters such as DAG and CCR really excel when using DAS. Understandably, for VMware this is the main issue. vSphere in the Enterprise == Shared Storage, so to maintain this model they need to recommend shared storage for any application running atop the platform.

So, you've really got to use shared storage for Exchange on vSphere.. But that's OK, isn't it? NFS is getting wider acceptance for running VMs on and of course iSCSI is a great middle ground between F/C and NFS for using traditional storage protocols at a decent price… Well, iSCSI is supported for standalone Mailbox servers, but "For Mailbox servers that belong to a Database Availability Group, only Fibre Channel is currently supported".

According to VMware, though, only supporting DAG on F/C may not be a major problem, though. Instead of using DAG to have multiple database copies, VMware say "The building block approach is a recommended best practice for creating a standalone Exchange Mailbox Servers running on vSphere using pre-sized virtual machine configurations. Exchange servers that have been divided into virtual machine building blocks (as opposed to larger, monolithic Exchange servers) can simplify server sizing during the initial deployment and create a highly scalable solution using virtual machines with predictable performance patterns.". So if you don't mind only having one database copy (or copying it at the array level), the the combination of iSCSI+VMware+Exchange 2010 may be for you.

It's fair to say although there are a few disappointments in the document - like the focus on shared storage, gentle push to avoid DAG and the use of F/C disks in RAID 10s instead of large, dense SATA disks, it's still a worthwhile read (so long as you follow Microsoft's own best practices) and will help with small and large Exchange deployments on vSphere alike.

Download Exchange 2010 on VMWare - Best Practices Guide

Update 1: Microsoft have recently posted (a few hours after this post, taking into account the time difference) a response to the Best Practices guide:  Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance

Update 2: VMware have responded to Microsoft's above post, addressing why VMware HA is a great compliment for DAGs: Virtualizing Exchange on VMware Provides More Recovery and Availability Options

Exchange 2010 Powershell Scripting Resources

If you've ever wondered how to get started with Exchange Powershell scripting, or have looked for ways to find out more information, bulk modify or automate your environment then hopefully you'll find this article I've recently posted on the Exchange 2010 section on the TechNet Wiki useful.

The Exchange Management Shell isn't just for large enterprises with large teams. Scripting Exchange can provide benefits to even administrators of small, single server environments; for example to provide reports on recent changes to the environment, collate patch levels or to make laborious tasks simple.

The article provides information about how to get started, where to find useful resources and how to get help if you get stuck, along with information about how to take things to the next level once you've found your bearings. As it's a wiki, feel free to add your own favourite resources and Exchange Powershell related blogs too!

Exchange 2010 Powershell Scripting Resources

Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing

One of the interesting nuggets of information coming out from TechEd a couple of weeks ago relates to Microsoft's changing advice on whether Windows' Network Load Balancing should be used with Client Access Servers to balance client traffic.

The new advice from Ross Smith IV's session entitled UNC311 - How Outlook connects to Exchange 2010 Client Access Server is in some ways contrary to the TechNet documentation online, which specifically recommends using NLB. However given the source, and that it comes direct from the Exchange team along with reasons why, it's certainly advice worth following.

You can (and should) watch and listen to the whole session online, but for quick reference I've transcribed the relevant part as delivered by Ross along with a little context:



"What we [Microsoft] recommend is a hardware load balancer for most deployments.. there are several reasons..

Hardware load balancers provide you service awareness, so you can actually get down to the individual, not only the individual TCP port, TCP 443 as an example, but you can potentially get down to the individual application as part of that service, depending on the load balancer you deploy. So now you can know if the web service, or the EWS service I should say, is failed - but OWA is still functioning on the CAS array. And you could take that member out of service as the result of that one failure because maybe you have.. Lync deployed and you rely heavily on the EWS service.

Hardware load balancers allow you to deploy different types of persistent methods for the different types of clients, which can then enable you to do different thing depending on your architecture.

What we don't recommend - is DNS round robining; DNS round robin does not provide persistent. It merely provides a means to alternate which servers are responding at a particular time. It does not provide any sort of persistence, or necessarily fault tolerance. So we don't recommend it.

We don't recommend Windows Network Load Balancing, and from a cross site architecture, while there are ways to deploy a single, unified, namespace across multiple datacentres, it's extremely complex, it requires extremely expensive load balancing solutions - you can do it, but it is an operational cost that you have to manage.

So - from our perspective, we recommend creating two separate namespaces, and accessing those namespaces from that perspective."



"Why not Windows Network Load Balancing? Well - there's several issues with it. One - it only provides the ability to do IP-based affinity. So we don't get the persistent capabilities that we need.
Two - it doesn't provide service awareness… it's "server-aware". If the web service fails, Windows Network Load Balancing has no concept of that. It just continues to route requests to that and then the user has a broken experience.

It doesn't scale well. When we talk about Outlook connectivity, and Outlook going to this load balancing solution, you know, if it's just direct Outlook connectivity, at a minimum we're doing 4 TCP sessions - plus one or two HTTP sessions, for that connectivity. So - 4 MAPI sessions, 2 HTTP sessions. So that's 6 sessions that you have to deal with, per Outlook client at a minimum. And then, you look at the perspective that you might have 50,000 of those clients, or a 100,000 of those clients, all connecting to this array. That's just a scale that Windows Network Load Balancing does not deal with.

So anything over 8 nodes - we don't recommend that you use Windows Network Load Balancing.

It also isn't supported with Windows Failover Clustering. So you cannot co-locate CAS and the Mailbox roles and expect to be able to use Windows Failover Clustering and Windows Network Load Balancing on the same machine.

And then, the last one - adding or removing a single node does cause all clients to have to be reconnected to the Network Load Balancing Array.

So there are a multitude of problems of why we no longer recommend Windows Network Load Balancing with Exchange 2010 in enterprise type deployments. Obviously in certain scenarios like a branch office, where you only have a small set of user populations, it obviously makes sense from a cost perspective."
So there you have it. In most circumstances, Windows NLB is not recommended because (as you probably already know) it has no clue as to whether OWA, EWS or any other Exchange service is available on your CAS, it doesn't have decent affinity, and doesn't scale. The first two reasons will apply to every load balanced CAS array designs, so if you budget allows it you should consider a hardware load balancer (or even two, for redundancy!).

If by any chance you're now looking for Microsoft's list of qualified Hardware Load Balancers for Exchange 2010 check out the Microsoft Unified Communications Load Balancer Deployment page on the Microsoft site, and if you're looking for a good article on setup and further recommendations, check out Henrik Walther's multi-part article Load Balancing Exchange 2010 Servers using a Hardware Load Balancer Solution at msexchange.org

How to report which Exchange mailboxes group members have full access to

Mailbox access rights in Exchange are easy to assign, however managing them can be a bit of a pain, especially if they are assigned on a per-user basis, or assigned when troubleshooting issues for a user. What would be really useful is the ability to quickly generate a report against a subset of users to check that their access rights fall in line with organisational policies or just to check for any permissions that need revoking.

To help with visibility in this area, I've written a little script that let's you discover this information so you can act on it. Basically, it takes a group of users, then checks all the mailboxes to find out if any of those users have full access rights to mailboxes other than their own, and outputs the results to the console.

So, why did I write this script? Quite simply, to meet a business need - a management requirement to provide a report on what mailboxes the people in the IT department have full access to. However it's not just useful for that - users move around between departments often and while group memberships are routinely updated in most organisations, there's always the off-chance a user's been granted full access to a certain mailbox and that permission hasn't been revoked.

Usage is fairly straightforward. You need to know the group name; after that simply specify it when executing the script:

.\Get-MailboxPermissionForGroupMembers.ps1 "Example Group"

After execution, the script will expand all the group members (including any in sub-groups), then get all mailboxes. It will compare each mailbox's full access permissions list against those group members and output a result similar to this:



Currently, this is a version 1.1 script. It's aimed at both Exchange 2007 and 2010 at the moment, but I envisage a future version would not only check for other types of permissions set at the mailbox level, but also check for mailbox folder permissions in an Exchange 2010 environment. And, as always your comments and ideas for improvements would be very much appreciated

Download Get-MailboxPermissionsForGroupMembers.zip