Office 365 Hybrid – On Premise Room Mailboxes not available in OWA

I came across an issue today wherein a user whose mailbox was hosted on Office 365 attempted to use OWA to book a meeting On Premise, and was told that there were no rooms available. The list simply didn’t contain any rooms. The Room Mailboxes were synchronised to Office 365 using the AADSync tool, however OWA knew nothing about them. When using Outlook, the Rooms were shown correctly, so this was just an issue with OWA, not with Room Mailboxes per se.

After a little digging, I found the following KB article: https://support.microsoft.com/en-us/kb/2904381 which explains that a Room List should be created and synchronised to Office 365 to get this working in OWA.

However the PowerShell cmdlet in the KB article fell a little short as I had over 100 Rooms to add into the Distribution Group. This was the PowerShell I ended up using:

$members=Get-Mailbox -RecipientTypeDetails RoomMailbox
New-DistributionGroup -Name "RoomList" -RoomList -Members $Members

I then moved the newly created Distribution Group into the correct OU and performed a Directory Sync. The RoomList showed up instantly, but it took 5-10 minutes for it to become populated. Once this was all done, the Rooms were available!

RoomOWA

Script to change Exchange internal URLs

All Exchange consultants will have been through this situation at least once now; a customer is using a split namespace in their Exchange environment with a .local name internally, and due to the new requirements for purchasing SAN certificates, they can no longer purchase certificates with a .local name on them. One way of remedying this is to change all the Exchange internal URLs to use the public name, and add in an internal DNS zone and record to point the public name at the Exchange environment.

Changing the URLs for multiple virtual directories and servers can be a pain. There are many scripts like this out there on the internet, but I frankenstein’ed this one to fit the needs I had. I wanted it to prompt for the server name, public FQDN and autodiscover FQDN and then change the directories on that particular server to reflect the names I had entered. I also love simplicity, so I wanted the most simple script possible. If you wanted to change this to do the external URL’s, then just do a find and replace internal with external! This script will work on Exchange 2010 and 2013.

Also, if you are using a wildcard certificate, be sure to run the below command to force the name match, otherwise you may get certificate errors on your clients!

Set-OutlookProvider -identity EXPR -certprincipalname msstd:*.domain.com

Here is the script I use:

#get variables
write-host "Set Exchange 2010 Internal URLS" –Foregroundcolor Yellow
$urlpath = Read-Host "Type CAS Array FQDN starting with https://"
$autodpath = Read-Hosts "Type Autodiscover FQDN starting with https://"
$CASserver = Read-Host "Type internal server FQDN"
#change urls for all internal directories
Set-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" –internalurl “$autodpath/autodiscover/autodiscover.xml”
Set-ClientAccessServer –Identity "$CASserver" –AutodiscoverServiceInternalUri “$autodpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity "$CASserver\EWS (default web site)" –internalurl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity "$CASserver\OAB (default web site)" –internalurl “$urlpath/oab”
Set-owavirtualdirectory –Identity "$CASserver\OWA (default web site)" –internalurl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity "$CASserver\ECP (default web site)" –internalurl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity "$CASserver\Microsoft-Server-ActiveSync (default web site)" -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"
#get commands to to doublecheck the config
get-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" | ft identity,internalurl
get-ClientAccessServer –Identity "$CASserver" | ft identity,AutodiscoverServiceInternalUri
get-webservicesvirtualdirectory "$CASserver\EWS (default web site)" | ft identity,internalurl
get-oabvirtualdirectory "$CASserver\OAB (default web site)" | ft identity,internalurl
get-owavirtualdirectory "$CASserver\OWA (default web site)" | ft identity,internalurl
get-ecpvirtualdirectory "$CASserver\ECP (default web site)" | ft identity,internalurl
get-ActiveSyncVirtualDirectory "$CASserver\Microsoft-Server-ActiveSync (default web site)" | ft identity,internalurl

Hybrid Configuration Wizard and Multiple Domains – Get-FederationInformation cmdlet had thrown an exception

When running the Exchange Hybrid Wizard for multiple domains, you may find it fails and shows you the error below:

Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.

Federation information could not be received from the external organization.

In addition to this, if you check the Update-HybridConfiguration log file in the Exchange Logging directory, you will find that the failure occurs just after the command Get-FederationInformation is run on one of your domains.

The first test you can run is to login to Microsoft Online PowerShell and try running:

Get-FederationInformation -DomainName domain.com

If this comes back with an error, then you likely have an issue with Autodiscover. It may be that autodiscover is not configured for all your domains, which is quite a common occurrence. There are 2 traditional ways to get around this:

  1. Configure multiple SRV DNS records to point Autodiscover at your primary Autodiscover service
  2. Add all your autodiscover domains to your SAN certificate and configure A records to point autodiscover to the public facing IP of your Exchange server/s

As of Exchange 2010 SP3 UR6 and Exchange 2012 SP1 however, there is a much cleaner way of doing this.

  1. Make sure Autodiscover is configured and working on your Primary SMTP domain (use https://testconnectivity.microsoft.com/ to verify functionality)
  2. Run the HCW (Hybrid Configuration Wizard) for just your Primary domain. This should complete without issues
  3. Go into the Exchange Management Shell on your On Premise Exchange environment and run:

Set-HybridConfiguration -Domains domainb.com,domainc.com,domain.com,autod:domaina.com

Where domaina.com is your Primary SMTP domain. This sets your autodiscover domain for all domains to domaina.com.

  1. Re-run the HCW. You should now see all domains populated and the HCW should complete successfully.

The operation couldn’t be performed because object ‘EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)’ couldn’t be found on ‘DC.domain.local’.

A most inventive and amusing title to this post, if I do say so myself!

After installing Exchange 2010 into a legacy Exchange 2003 environment, you may be faced with the following error when viewing the properties of an Exchange 2003 mailbox in the Exchange Management Console. In addition to this, if you attempt to migrate a mailbox to Exchange 2010 from 2003, you may see this error:

Mailbox database “EXCHANGE\First Storage Group\Mailbox Store (EXCHANGE)” doesn’t exist.

This is a permissions issue, and the fix is relatively simple:

1. Log into your Exchange 2003 server and open the Exchange System Manager (affectionately known as ESM).

2. Go to the properties of the Mailbox Store mentioned in the error message:

Mailbox Store Properties

3. Go to the Security Tab of the Mailbox Store and select the Advanced option. Tick the box to ‘Allow inheritable permissions’ , and Apply your changes.

Mailbox Store Properties

4. If this doesn’t fix your problem, or if the ‘Allow inheritable permissions’ box is already ticked, then do the same thing (Advanced settings under the Security tab, make sure the ‘Allow inheritable permissions’ box is ticked) but to do this, go into the Properties of the server itself, not the Mailbox Store.

5. If even this doesn’t work, then you should manually add in the Exchange 2010 server into the permissions group for the Exchange 2003 server and give it Full Control.

 

Hope this helps!

Exchange 2010 Update Rollup failed – error 1603

If you’ve never seen this error code before when installing Update Rollups for Exchange 2010, then you haven’t lived. There’s plenty of blogs and articles out there about it, but I wanted to record it for my own purposes so I don’t go trawling for the answer next time!

In a nutshell, the reason this happens is that UAC hates you.

Simple fix to this is to run CMD as Administrator, and use msiexec to install the Update Rollup, like this:

msiexec /update Exchange2010-KB2961522-x64-en.msp

Gotchas? Well the file should be on a local drive (not a network share). If you are still having problems after this, take a gander at the following KB article: http://support.microsoft.com/en-us/kb/2784788/en-us

That’s about it. Happy Update Rollup’ing!

Working with date specific PST exports using PowerShell

With all the various email archiving tools in place across the world, invariably in the world of Exchange consulting we get involved in lots of mass exports/ingestions of data to and from various services. One task which is performed often is exporting mail from Exchange mailboxes from a specific date range.

In order to do this, you first need to have the required permissions to actually export data from Exchange 2010/2013. This is not part of your permission set as a member of the Organisation Management role group (which some admins assume is an account with god level rights). So to begin with, we will run some commands to create a new custom role group, and then add ourselves into said role group. If you try and run the export commands and receive the following error, then you need to follow the below process to setup a new role group.

The term ‘New-MailboxExportRequest’ is not recognized as the name of a cmdlet, function, script file, or operable program.

Open up your Exchange Management Shell (as Administrator of course!), and run the following commands:

New-RoleGroup "Mailbox Import-Export Management" -Roles "Mailbox Import Export"
Add-RoleGroupMember "Mailbox Import-Export Management" -Member DavidD

You will now have the required permissions to allow you to run the New-MailboxExportRequest commands. By the way, this powershell command only became available as of Exchange 2010 SP1 so if you are mad enough to be running Exchange 2010 RTM, this command will not be available.

In order to have access to your lovely new cmdlets, you will need to close and reopen the Exchange Management Shell (as Administrator!). Now you can run the command as shown below, just tweak the settings marked in bold to get your desired effect 🙂 As a side note, the -lt stands for less than, and the -gt is greater than. You can also use -le, which is less or equal to, or -ge, which is greater or equal to.

New-MailboxExportRequest -ContentFilter {(Received -lt '01/04/2014') -and (Received -gt '12/02/2012')} -Mailbox "DavidD" -Name DavidDExport -FilePath \\myserver\pst\DavidDExport.pst

At this stage, I’d like to point out a little gotcha to do with this command. As I am in the UK, the servers I work on are configured with UK regional settings, including date and time. This means that dates are displayed in a DD/MM/Year format rather than the American MM/DD/Year format. If your regional settings reflect the UK configuration, then the trick is to use UK date format but never use a number above 12. So if you were to use 15/03/2015 (15th March 2015) this would queue the request but would fail after a minute or two with the error:

“The value “15/03/2015 00:00:00 AM” could not be converted to type System.DateTime.”

However if you use 12/03/2015 (12th March 2015) this would work and would export the correct date ranges. If you used 03/12/2015 in the UK, Exchange would think you meant the 3rd December 2015. Obviously if you are in the US this is not a problem, but I struggled with this in the UK. If anybody has seem differently or knows a way around this, please comment and let me know! My advice at the moment though is to use UK date formats, but never use a number above 12 for the day.

Once your request has started, you can run the below command to see the status of your request.

Get-MailboxExportRequest

If your request shows a status of failed, use the below command to retrieve some useful information about the failure.

Get-MailboxExportRequestStatistics -Identity DavidD\DavidDExport

Hopefully this can get the ball rolling for you when attempting to export mail out of Exchange 2010/2013.

Thanks for reading!

Rebalance DAG automatically using Task Scheduler

Those of you who manage Exchange Database Availability Groups, particularly in Exchange 2013, will understand the frustration of coming to the office on a Monday morning to find that your Databases have migrated to A. N. Other server because of some scheduled backup or other task which occurred over the weekend.

To solve this problem, we can configure a Scheduled Task to run the RedistributeActiveDatabases.ps1 script, which will balance your databases out based on the Activation Preference set for each server. Before you configure this task, make sure that your Activation Preference settings are applied as per your desired configuration.

For example, say I have a database named MBDB and two servers named Server1 and Server2 (I’m feeling particularly inventive today). To set the Activation Preference for these database copies, I would run the following Powershell command from EMS:

Set-MailboxDatabaseCopy -identity MBDB\Server1' -ActivationPreference 1
Set-MailboxDatabaseCopy -identity MBDB\Server2' -ActivationPreference 2

This configuration will mean that when I run the RedistributeActiveDatabases.ps1 script, the MBDB database will be moved, if required, to Server1, as long as the required Database Mount Dial setting is achieved (the default setting is Best Availability which requires the Copy Queue Length to be no more than 12).

If I wanted to see how my database copies are currently configured, I would run the following Powershell command from EMS:

Get-MailboxDatabase MBDB | fl server, databaseCopies, activationPreference

This would show me all the database copies and their Activation Preference. So we now have our settings configured and we want to setup our Scheduled Task. Open your Task Scheduler and create a new Basic Task. Give the task a name and configure your recurrence schedule for the Task. When you get to the Action menu, choose ‘Start a Program’.

Now we need to tell the task to:

1. Launch Powershell
2. Load the Exchange modules and connect to the Exchange server
3. Run the RedistributeActiveDatabases.ps1 script with the correct switches
4. Supress the confirmation dialog which appears when running the script

To do this, we enter the details as follows:

  • Program/script:
    • C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe
  • Add arguments:
    • -NonInteractive -WindowStyle Hidden -command “. ‘C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto; .’C:\Program Files\Microsoft\Exchange Server\V15\scripts\RedistributeActiveDatabases.ps1’ -DagName DD-DAG -BalanceDbsByActivationPreference -Confirm:$false”
    • Note: Please change the DagName parameter to reference your own DAG!

It looks a little bit like this (OK, it looks just like this):

TaskScheduler DAG Rebalance

Complete the task creation and then go into the properties of the task. On the General page, configure the task to:

1. Run whether the user is logged on or not
2. Run with highest privileges
3. If need be, change the account running the task to a service account of some kind. That account must be a member of the Organisation Management group

Just like this:

TaskScheduler DAG Rebalance 2

Your Scheduled Task is not configured. You can test it out by manually running it. Hopefully this solves a headache for one or two of you out there!