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 email@example.com
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.
As the distribution of Office 365 spreads accross the planet, the need for hybrid deployments rises. In many scenarios we find that environments are partly hosted on-prem and in the cloud. The reason for such deployments vary in some degree, and when it comes to Lync deployments it’s often due to enterprise voice which is not possible in the cloud(at the moment).
To implement a hybrid configuration where Lync resides on-prem and Exchange is hosted online, we have to do some configuration in the on-prem environment.
First, if the Lync environment is a Lync 2010 installation the minimum requirement is that the March 2013 server Update is installed on the Lync servers. In addition to this, a standalone server with Lync 2013 Administrative Tools has to be deployed in order to be able to connect with Office365. All PowerShell commands against the Online environment has to be executed on the server running Lync 2013 Admin Tools.
To enable Lync On-prem integration with Exchange Online, the first step is to make sure that federation is allowed(most environments already have open federation enabled):
Set-CsAccessEdgeConfiguration -AllowFederatedUsers $True
The next step is to configure the shared address space with Exchange Online:
New-CsHostingProvider -Identity "Exchange Online" -Enabled $True -EnabledSharedAddressSpace $True -HostsOCSUsers $False -ProxyFqdn "exap.um.outlook.com" -IsLocal $False -VerificationLevel UseSourceVerification
- Identity specifies a unique string value identifier for the hosting provider that you are creating (for example, “Exchange Online”). Values that contain spaces must be in double quotes.
- Enabled indicates whether the network connection between your domain and the hosting provider is enabled. This must be set to True.
- EnabledSharedAddressSpace indicates whether the hosting provider will be used in a shared SIP address space scenario. This must be set to True.
- HostsOCSUsers indicates whether the hosting provider is used to host Office Communications Server or Lync Server. This must be set to False.
- ProxyFQDN specifies the fully qualified domain name (FQDN) for the proxy server used by the hosting provider. For Exchange Online, the FQDN is exap.um.outlook.com.
- IsLocal indicates whether the proxy server used by the hosting provider is contained within your Lync Server topology. This must be set to False.
- VerificationLevel Indicates the verification level allowed for messages that are sent to and from the hosted provider. Specify UseSourceVerification, which relies on the verification level included in messages sent from the hosting provider. If this level is not specified, the message will be rejected as being unverifiable.
Check replication status to verify that the changes has replicated to the access edge server: