Exchange: Renaming of room mailbox, Yeay or Nay?

From time to time we come across scenarios where a meeting room or resource has been removed, relocated or we simply would like it to show another name than the original one in our system.

So, is there an easy way to rename the resource in Exchange and have it reflected in the users calendar for previous bookings?

The answer is Yes, and No.

Renaming of the resource is fairly simple using PowerShell. You have to change the attributes Name, Alias, DisplayName, SamAccountName, and UserPrincipalName.

Set-Mailbox “TestRoom” -Name “NewTestRoom” -Alias “new_testroom” -DisplayName “New Test Room” -SamAccountName newtestroom -UserPrincipalName

You also have to change the FirstName attribute using the Set-User command:
Set-User “NewTestRoom” -FirstName “NewTestRoom”

So, does this do the trick?

The answer is yes, in regards to new bookings. The problem is that the name change does not reflect in the previous bookings of the resource. The old name will still show in the booking, but if you click on the name of the room, the new name will show in the properties of the resource.

There is no way to change the name of the room without deleting the booking and make a new reservation with the new name. The room is reserved in the system with the old name, and there is no way for Exchange to display the new name in available resources(if you choose Change Room in the booking) without deleting the reservation and making a new one.


Exchange 2013 Event ID 1039: Failed to detect the bitlocker state for EDS log drive ‘C:\’.

I came across this event on an Exchange 2013 CU9 server which I was configuring for a customer.

Event ID 1039, Exchange 2013 CU9

Searching for solutions to this event made me understand that this is something that’s been going on since Exchange 2013 Cu7. The fix is quite simple and does not have any impact on the Exchange system.

Simply disable the Bitlocker check on the drive where diagnostics root directory exists.

Open below file in notepad (run as admin):
C:\Program Files\Microsoft\Exchange Server\V15\bin\Microsoft.Exchange.Diagnostics.Service.exe.config

Change the parameter “DriveLockCheckEnabled” value=”True” to “DriveLockCheckEnabled” value=”False” and save the config-file.

<!– Settings used when checking Bitlocker state of the drive where the diagnostics root directory exists –>
<add key=”DriveLockCheckEnabled” value=”False” />
<add key=”DriveLockCheckInterval” value=”00:00:10″/>
<add key=”DriveLockMaxDuration” value=”00:04:00″/>

Restart MicrosoftExchangeDiagnostics service, and the error message is gone.

Failed mailbox migration to Office 365: mrsproxy.svc’failed because no service was listening on the specified endpoint. The remote server returned an error: (404) Not Found

I was doing a migration between Exchange 2013 and Office 365 in a Hybrid configuration when I recieved the above error message. Couldn’t quite figure out why until I stumbled accross a forum thread that pointed me in the right direction.

This is what you have to check out and remediate if you have this error:

The ExchangeGuids of on-premise users are different to the ExchangeGuids of the corresponding users in Office 365.

Update the online user’s ExchangeGuid to match the on-premise ExchangeGuid and start migration.

1. On the on-premise Exchange server:

Get-MailBox -Identity userID | Select ExchangeGuid

2. In an Office 365 PowerShell session:

Get-MailUser -Identity UserID | Select ExchangeGuid

If the results don’t match, copy the guid result from command 1 and then run the following command in the Office 365 PowerShell session:

Set-MailUser -Identity userID -ExchangeGuid “copied guid”

Start migration:

$Cred = Get-Credential

$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $s

$OnPremAdmin = Get-Credentials

New-MoveRequest -identity “UPN” -Remote -RemoteHostName “remote host ex OWA URL” -RemoteCredential $OnPremAdmin -TargetDeliveryDomain

Exchange 2013: Inbound mailflow suddenly stops.

I recently came across a problem with Exchange server 2013 which I thought I would like to share with you.

I installed an Exchange 2013 server with CU2 in a migration scenario migrating from Exchange 2007. The servers coexisted for a while when migrating all mailboxes, and I then verified that mailrouting was working as expected with the mailboxes residing on the new Exchange 2013 server. All good so far.

Proceeded with the migration and moved/recreated all connectors on the new server before disabling them on the old one. Everything seemed to be working fine for a while, but then suddenly the server stopped responding for incoming SMTP mail. There was nothing in the logs indicating anything wrong with the server, but every once in a while the server would stop accepting inbound SMTP and a reboot was the only way of getting it back on track(or a restart of the Exchange Transport Service/ Information Store service).

After spending quite some time troubleshooting this issue, a colleague of mine pointed me in the direction of the receive connectors. It turns out I had missed an important thing when I created the SMTP internal receive connector.

Exchange 2013 Receive Connectors
Exchange 2013 Receive Connectors correctly configured

As Paul Cunningham points out in this blog post regarding SMTP relaying, if the server is a multi-role server the connector has to be created using the FrontendTransport role, instead of the HubTransport which I had been using. My mistake… (but it doesn’t point out the fact that failing to create it with the correct properties makes everything else fail as well)

So, with this new info in mind, I proceeded to recreate the Internal SMTP routing connector as a FrontendTransport connector with all the same IP addresses that the old one had. Restarted the Transport service and the information store and watched as e-mail started flowing in.

Turns out that even if the connector in question was just meant for internal mail routing, the fact that it was made as a custom HubTransport caused a total failure for all the default connectors as well.

PS: This “bug” applies only to Exchange Server 2013 CU2. In CU1 this is not a problem as far as I know.