Exchange Virtual Directory HTML Report

Update 12/09/2016: script updated to version 1.8:

  • Included support for Exchange 2016 CU2+
  • Made some minor changes to the code + output now shows a message if successful/unable to write the html file.

Previous updates in version 1.7:

  • Added more recent Exchange build numbers
  • Updated download location to TechNet Script Gallery

You can download v1.8 here

Hi,

as a consultant, I regularly come across situations in which I have to troubleshoot an existing Exchange server environment or perhaps have to make an assessment, health report, etc.

Almost every time, I found myself looking up the information from the different (commonly used) virtual directories like: Autodiscover, ActiveSync, OWA, ECP, Web Services, OAB… That’s why I thought it became about time I automated this process so that I didn’t have to type the commands in manually anymore.

The result is a simple script which will query the Exchange Client Access Servers in your environment and will query them for their virtual directory information. Depending on the use of the virtual directory, different object are shown:

image

Blog Exchange PowerShell

A closer look at the “Minimal Hybrid Configuration” option

Just a few weeks ago, Microsoft announced a new feature in its line-up of hybrid Exchange capabilities: the Minimal Hybrid Configuration option. With the introduction of this new capability, Microsoft seems to have responded to a long-standing question from customers who can now move mailboxes to Office 365 without the need to deploy a ‘full’ Hybrid configuration.

Blog Exchange Hybrid Exchange Office 365

Exchange Hybrid Deployments and cross-premises Full Access permissions

Nothing but excellent news in the hybrid Exchange realm these days! Microsoft recently updated the support statement for cross-premises permissions in a hybrid deployment. As of now, Full Access delegate permissions are supported cross-premises. I know many customers will be delighted to hear this as this has been a big ask for quite some time now.

It’s important to understand that the support only applies to Full Access permissions, as stated here. Other permissions like Send-As, Receive-As or Send-on-Behalf are still not supported. Note that Microsoft is in the process of updating its documentation; you should see a more consistent message across TechNet over the next few days!

Although full access permissions have been reported to work intermittently, no cross-premises permissions were supported previously. As such, you could not rely on them working either. From what I understand, the plumbing was already in place for a while but the intermittent results were partially due to the Outlook client not honoring them quite as one would expect. Provided you have the November 2015 update to Outlook 2013, you should no longer run into any problems.

As you move mailboxes to Office 365, permissions are migrated along. If you already had permissions assigned before the move, there is nothing you need to do. Although the permissions were also migrated previously, you had to move connected mailboxes at the same time so they would be hosted in the same organization in order for them to work. Not too long ago, I was talking to a customer who started out with a handful of mailboxes to move to Office 365 but ended up with a huge migration batch because of the interweaved permissions… As of now, this is no longer needed, making planning for migration batches a lot easier!

You should now also be able to add the Full Access permissions after mailboxes have been moved. This means you can give an on-premises mailbox access to a mailbox in Office 365 and the other way around without having to set the permissions prior to moving the target mailbox to Office 365.

In order to explain things more clearly, I have put together a Q&A. I hope this helps!

Until later,

Michael

What cross-premises permissions are supported in a hybrid deployment today?

Full Access only. Other delegate permissions like Send-As, Receive-As or Send-on-Behalf are not. There are no changes to cross-premises calendar delegation either. That continues to work the same way it did before.

Will the permissions work both ways?

Yes. On-premises mailboxes can access Office 365 mailboxes and vice versa.

What do I need to do to make this work?

Nothing, really. Just make sure you are using an up-to-date Outlook client. For Outlook 2013, this means you need at least the November 2015 Cumulative Updates. Needless to say, the more up-to-date you are, the better!

In order to add permissions for a recipient in the other organization, you can either use PowerShell or the Exchange Admin Center. Unlike the EAC in Office 365, you cannot use the on-premises EAC to grant an Office 365 mailbox access to an on-premises mailbox. For that you must revert to using PowerShell.

How do I add permissions to an Office 365 mailbox for an on-premises recipient?

Follow these steps to add Full Access permissions to an Office 365 mailbox for an on-premises recipient:

  1. Login to the EAC in Office 365 (Exchange Online)
  2. Navigate to recipients > mailboxes and then select properties of the mailbox you want to add Full Access permissions for.
  3. In the properties window, navigate to mailbox delegation
  4. Scroll down to you get to the Full Access From there, use the recipient picker (plus-sign) to add the on-premises mailbox you wish to grant permissions to:
    hybridperm1
  5. Click save.

How do I add permissions to an on-premises mailbox for an Office 365 recipient?

As mentioned earlier, you cannot use the EAC to add permissions for an Office 365 recipient. Instead, you must use the on-premises Exchange Management Shell. Don’t worry it’s quite simple!

Add-MailboxPermission –Identity <On-Prem_mailbox_to_give_permissions_for> -User <O365_mailbox_to_give_permissions_to> -AccessRights FullAccess –AutoMapping $false

For example:

Add-MailboxPermission –Identity onpremmbx@domain.com –User clouduser@domain.com –AccessRights FullAccess –AutoMapping $false

Unlike for permissions in the same environment, the AutoMapping feature is not supported. Hence why I specified the –AutoMapping $false parameter. I suspect the permissions to work without adding the parameter too!

What will my users see?

There is no difference in how Outlook displays an Office 365 mailbox over an on-premises mailbox you have access to. However, an on-premises user might get prompted for credentials when trying to access a mailbox in Office 365. This is because, in the back, the Outlook client must establish a connection with the Office 365 service first.

How that looks, depends on a number of things like the version of the Outlook client, whether you use Modern Authentication and whether or not they already have another Office 365 mailboxes in their Outlook profile.

Blog Exchange Hybrid Exchange News Office 365

Exchange User Permission Enumeration Script

A few years ago, I wrote a PowerShell script which would enumerate the permissions a user had been given in an Exchange environment. Because of some connectivity issues over on pro-exchange.be, earlier, I decided to post the script to the TechNet gallery and do a little write-up here.

The code for the script might be a little old (or clunky FWIW), but it does the trick. Unlike some other scripts out there, the intention of this script is to find where a user has access to (instead of generating a report that shows you who has access to a specific report). Because of that, the script needs to enumerate all permissions in the environment and go through them one by one. As such, the performance of the script might suffer a little in larger environments; but that’s just a small price to pay.

As some of my other scripts, this script was designed to be dot-sourced. In the future, I’ll update the script to add a little more error handling and remove the requirement to dot-source it.

You can download the script from here.

If you have any thoughts or comments, feel free to post them below!

Cheers,

Michael

Exchange PowerShell

[updated: July 20, 2015] Script: putting Exchange Server 2013 into Maintenance Mode

Latest Update:

v1.8 (07/20/2015): fixed a copy/paste error in the script and cleaned up the code to be a little more efficient (removed redundant IF-statement. Published the script to the TechNet Script Gallery for easier download access.

Introduction

In Exchange 2010 one had the option to put a Mailbox server which was part of a DAG into “maintenance mode” by running the “StartDagServerMaintenance.ps1” script that was included with the product. Likewise StopDagServerMaintenance.ps1 was used to pull a server out of this so-called maintenance state. In fact, this script would move any active mailbox databases to another node in the DAG and mark this server as temporarily unavailable to the other servers. That way, if a failover would occur during the server was in ‘maintenance mode’ you wouldn’t risk that it ended up as a valid failover target.

Exchange 2013 now has the ability to go beyond what was possible before and extend this functionality. You now have the possibility to put an entire server into maintenance mode, meaning that also components like e.g. Transport Service or the Unified Messaging Call Router are temporarily put on hold why you do some work on your server.

There might be various reasons to put a server into maintenance mode. For instance when you need to install software or you want to do some troubleshooting without affecting users that might have a mailbox in an active mailbox database on that server. To facilitate the process, I created two scripts which will automatically put an Exchange 2013 Server in or take it back out of Maintenance Mode.

The manual process

The process for putting an Exchange 2013 server into maintenance mode is relatively straightforward. To enable the Maintenance Mode, you must run the commands below.

If the server is a Mailbox server and before you can disable the transport service, all active queues need to be drained first. To help clearing out the queues, existing messages on the server will be moved to another server. Please note that the TargetServer value has to be a FQDN:

Set-ServerComponentState  -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server  -Target &lt;server_fqdn&gt;

If the server is part of a DAG, you must also run these commands:

Suspend-ClusterNode
Set-MailboxServer  -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer  -DatabaseCopyAutoActivationPolicy Blocked

Once all queues are empty, you can disable all components:

Set-ServerComponentState  -Component ServerWideOffline -State Inactive -Requester Maintenance

Taking the server out of Maintenance Mode is a matter of simply reversing the actions we took to put it into Maintenance Mode.

First, we reactive all components:

Set-ServerComponentState  -Component ServerWideOffline -State Active -Requester Maintenance

If the server is part of a DAG, you need to reactive it in the cluster (by resuming the cluster node):

Resume-ClusterNode
Set-MailboxServer  -DatabaseCopyActivationDisabledAndMoveNow $false
Set-MailboxServer  -DatabaseCopyAutoActivationPolicy Unrestricted

If the server is a Mailbox Server, the transport queues need to be resumed as well:

Set-ServerComponentState –Identity  -Component HubTransport -State Active -Requester Maintenance

Although not explicitly required, it’s best to restart the transport services after changing their component states. This ensures they ‘pick up’ the changed component states immediately rather than having to wait for Managed Availability (Health Service) to take action.

Using the scripts

Sometimes it can take a while before active queues are drained. Because I do not always want to wait in front of the screen and periodically check the queues myself, I created two little script that fully automate the process explained above. Besides the required steps, the scripts also perform additional safety-checks and inform you about other server component states which might prevent a server from working correctly.

The first script, Start-ExchangeServerMaintenanceMode.ps1 will put a server into Maintenance Mode, whereas Stop-ExchangeServerMaintenanceMode.ps1 can be used to take a server out of the maintenance state.

Please note that the scripts rely on built-in Exchange functions and therefore need to be run from the Exchange Management Shell.

Version history

v1.8 (07/20/2015): fixed copy/paste bug; removed duplicate code and made some overall improvements to script efficiency.

v1.7 (07/08/2015): removed the requirement to dot-source the script. Published the script to the TechNet Script Gallery for easier download access.

v1.6 (29/11/2013): some minor bug fixes in the Start-ExchangeMaintenanceMode script.

v1.5 (28/11/2013): Based on feedback from several readers, I’ve improved the scripts by rewriting parts of the code and, as such, making it more lenient and more usable in scenarios where you want to run the script from a remote Exchange server. The script now also restarts the Transport service(s) after changing their component states. This ensures that the new component states are picked up immediately, rather than after Managed Availability kicks in. Without the change it could take anywhere from a few minutes to a few hours before the transport services were really inactive/active again. The download links at the bottom of the page are updated to point to the new versions of the scripts. Last, but not least, when ending a maintenance mode, the script will query the server for any components that might still be inactive and display a warning if any are found. A special thanks to Dave Stork for some of the ideas!

v1.4: update the script to include some additional error checks. First it will check whether the person who is executing the script has local admin rights. If not, the script will throw a warning and exit. Secondly it will also check whether the TargetServer name can be resolved. If it’s not an FQDN, it will resolve it to an FQDN. If it cannot be resolved, an error will be thrown.

v1.3: after some feedback from Brian Reid (thanks Brian!), I’ve finally updated the script to include the “Redirect-Message” cmdlet. This will ensure that the queues will drain more quickly on the server by moving messages from one server to another. Have a look at Brian’s blog if you need more info: http://blog.c7solutions.com/2012/10/placing-exchange-2013-into-maintenance.html

v1.2: Maarten Piederiet emailed me pointing out that he had encountered some issues while using the script. Apparently, while draining the message queues, the script ran forever because it waits for every queue to become empty; including Poison- & Shadow Redundancy queues. To avoid this from happening, he made a minor change to the script to now excluded both queues. Thanks for the tip!

The scripts

Below you find links to my SkyDrive from where you can download the scripts. Enjoy!

Start-ExchangeServerMaintenanceMode (v1.8)

Stop-ExchangeServerMaintenanceMode (v1.5)

Disclaimer: these scripts are provided “as-is” and are to be used on your own responsibility. I do not and cannot take any reliability for the use of these scripts in your environment. Please use with caution and always test them before use.

If you have suggestions, comments or think things can be better: please let me know! Your feedback is greatly appreciated!

Blog Exchange PowerShell

Announcing “Office 365 for Exchange Professionals” (ebook)!

Hey all,

It’s been a while since I have last posted an article on my blog, and there’s a good reason for that. For the past few months, Paul Cunningham, Tony Redmond and I have been working fiercely on a new ebook, called “Office 365 for Exchange Professionals“. Together with Exchange MVP Jeff Guillet who is leading the efforts as our technical editor, we are confident that this book will deliver high quality, up-to-date and relevant information!

office-365-for-exchange-pros-cover-350

As the name might already give away, this book is targeted to Exchange administrators, enthusiasts and experts to help them transition their skills to the cloud. One of the biggest challenges writing about Office 365 is the fast rate at which things change. That is also the reason why we have chosen to publish the book as an ebook rather than a traditional, printed, book. We plan to have the book available in early May with contents being up-to-date as close as possible to the release date! We’re continuously editing the text to ensure that even the latest changes in Office 365 are included.

We are also looking at keeping the book up-to-date in the future to stay relevant as Office 365 (and Exchange Online) evolve. Right now, we are still figuring out what the best way would be to do that. Once we’ve come up with something suitable, we will definitely share that with you.

In the meantime, if you have any questions or there are topics which you would like to see covered in the book, feel free to leave a comment. The book already contains a lot (really, a LOT) of information, but getting your feedback has proven to be invaluable!

Looking forward to hearing from you!

-Michael

 

Blog Exchange News Office 365

Microsoft increases onboarding message size limit to 150MB

In yesterday’s rollup article for December 2014, Microsoft mentioned that they have upped the 25MB message size limit to 150MB when onboarding a mailbox to Office 365. The new limit applies, for instance, to mailboxes moved through a hybrid configuration to Office 365:

Office 365 Exchange Online message size onboarding limit increase — We are making a change to allow customers to migrate larger mail messages to Exchange Online. We now allow messages up to 150MB to be migrated to the service. The change is available immediately to all customers and is published as a new limit in the Exchange Online limits page in the Office 365 service description. We are not changing other limits such as mailbox size or maximum send/receive limit for messages. This change enables customers with large messages to easily migrate their existing content to the message.

Before, any message greater than 25MB were skipped. The hard limit might have been a little over 25MB, because the system accounted for overhead as well. As a result of that, the administrator either had to manually export those message from the mailbox (to keep them) or just ‘leave them behind’.

According to Paul Cunningham (ExchangeServerPro.com) this change also applies to offboarding scenarios.

This new limit is without any doubt good news for many organizations that are moving (or looking to move) to Office 365. The change also adds something extra to consider when onboarding mailboxes –mainly with regards to the velocity of a migration. Before, mailboxes could potentially be a lot smaller if it contained many items that exceeded the limit. With the new limit, administrators will have to take into account the additional payload (size) of those messages; potentially increasing the amount of data that has to be moved to ‘the cloud’.

All in all, this is yet another obstacle that Microsoft got rid of in favor of moving to Office 365 easier, but there are still some ‘limitations’ left; I can’t wait for Microsoft to address those too! For instance, the message size limit for sending and receiving messages hasn’t changed and Free/Busy lookups between two hybrid organizations is still a pain as well. However, I have no doubt that Microsoft will tackle these issues in due time as well.

Blog Exchange News Office 365