Customizing Role Assignment Policies for multi-tenants in Exchange Server 2013: Gal Pictures

When dealing with multi-tenants in Exchange Server 2013 (RTM and CU1) with a Hosting Control Panel that can only feed data into Exchange, rather than taking data back out of it to back-fill the Portal we have to lock down certain elements to only allow a customer to edit certain aspects via their desginated Panel Provider.

 

Take Exchange 2013, by default in most multi-tenant Hosting Orgs “MyContactInformation”, “MyPersonalInformation”, “MyMobileInformation” and “MyAddressInformation” and disabled, only allowing a tenant to configure this from the Hosting Control Panel.

 

The biggest issue this presents is that this means a user cannot change their Photo within OWA, as this is locked into “MyContactInformation”

 

 

1. A user cannot change their picture and thus it is empty, giving an unfulling experience in Outlook, OWA and Lync.

 

 

 

2. The logged in user can’t change their picture

 

 

3. Additionally other information is locked down also

 

 

 

So if we log into the EAC we can see this is because the Default Role Assignment Policy has “MyContactInformation”, “MyPersonalInformation”, “MyMobileInformation” and “MyAddressInformation” disabled. Standard practice in nearly all Enterprise Hosting environments.

 

 

 

So how can we keep this aspect locked down, allowing co-existence with a Control Panel but allowing tenants to actually upload pictures to get a more fulfilling experience?

 

Let takes a look at the Management Roles in question in PowerShell. We can do this simply by using “Get-ManagementRole”

 

 

So we can see above that “MyContactInformation” owns “Set-UserPhoto”, “Remove-UserPhoto” and “Get-UserPhoto”. We can take this built in Management Role and create a custom one from it, to allow pictures to be uploaded and used.

 

 

Let’s create a new Management Role using “New-ManagementRole”. We’ll call it “Oliver Test” and create it from the parent “MyContactInformation”

 

 

 

Now if I view this new Management Role I can see it has all the cmdlets from the parent.

 

 

 

I can now start to customise it by removing certain cmdlet elements. You can see I am using “Get-MangementRoleEntry”, specifing the cmdlet I do not want, and then removing it with “Remove-ManagementRoleEntry”

 

 

Once I have cleaned up my Management Role “Oliver Test”, let’s look at what I have left. You can see I now have just the cmdlets needed to allow photos to be uploaded and removed and edited if desired.

 

 

Logging back into the EAC I can now see this new Management Role under the Default Role Assignment Policy. I check it to enable it.

 

 

Logging back into my tenant user I am now able to change my photo, allowing picture integration into Outlook, OWA and Lync.

 

 

 

Checking the rest of my details you can see as before I cannot edit them, keeping the unity of your Hosting Control Panel which should control these settings.

 

 

 

Finally let’s log into OWA and Lync and see the new experience!

 

 

 

I hope this helps Hosters to integrate pictures into Exchange 2013 Enterprise. I will look to push a new blog out in a few weeks for managing different Role Assignments Policies per tenant in Exchange 2013 Enterprise.

 

Have a great week!

 

Take care!

 

Oliver Moazzezi - MVP Exchange Server

 

Lyncdiscover redirection using CNAME records

There is a great article and download on Lync Mobility from Microsoft here.

http://www.microsoft.com/en-us/download/details.aspx?id=28355


One thing that it doesn't specifically cover _exactly_ is the Lync App from the Windows Store for Windows 8.

When using iOS, Android or Windows Phone devices we can specifically set an https url location for the lyncdiscover service, for example: https://lyncdiscover.contoso.com. However this is not possible to set using the Windows 8 app.

So Lync deployments that have multiple SIP domains in use but only one lyncdiscover record on these devices manually enter https://lyncdiscover.contoso.com, if they have a SIP address of user@tailspintoys.com, but are ultimately part of the same Lync infrastructure.

In the above guide it mentions using CNAME records to create for example, a lyncdiscover CNAME record for the tailspintoys.com domain, pointing it to lyncdiscover.contoso.com.

Now if your reverse proxy solution only has port 443 open this redirect will fail on Windows Phone and iOS devices. Newer Android devices appear to be able to cope with the redirection and bind to SSL ok, hence many organizations simply entering the lyncdiscover record manually in the setup information.

But as I said this work-around doesn't exist for the Windows 8 app. So here's what you do.

1. On your reverse proxy solution as well as having the 443-4443 redirection to the Lync Director or Front End pool that owns the this lyncdiscover endpoint, also add an 80-8080 rule. This will then allow a CNAME in DNS to work on iOS and Windows Phones, and also the Windows 8 app.

2. Once this is configured simply open the Windows 8 Lync app and when logging in you will receive a redirection notice (which just like autodiscover redirects for Exchange you can set to only prompt the first time)

 

 

 



  

The Windows 8 app will then allow your users to login. Additionally this will also allow your iOS and Windows Phone devices to use discovery also and login without additional manual input.

 

 

 

So is this really needed? Well if you only have a select few SIP domains you can simply add these additional lyncdiscover records to your public SSL certificate and just pay any additional fees that come from your SSL provider for adding extra SAN names. But in a multi-tenant environment where you may have many hundreds of domains the only real solution at this time is the above.

 

Looking at my recent blogs it has all been about Lync so I have a few Exchange 2013 blogs I will get out of the door in the next two weeks.

 

Take care!

 

Oliver Moazzezi - MVP Exchange Server

 

 

Lync 2010 Mobilty service MCX Director install issue

I recently had an issue on Lync 2010 Directors where the entire Lync Mobility install would occur, not just the autodiscover service like you would expect.

Information on the internet for this appears to be vague at best so I thought a clear post about the issue should help others clear this up and fix it without some serious head scratching.

 

When deploying the Lync Mobility service you can easily see what parts are installed from the command line process.

 

 

Lync Front End:

 

Lync Director:

 

 

However I was repeatedly getting both the autodiscover and mcx component installed on a Director server.

 

So how was that possible? Surely the process realises it is a Director server right?

 

Well it turns out the above isn’t entirely true. It checks to see on the server it is being installed on whether the McxPrimaryListeningPort and MxcSIPExternalListningPort are set.

If these are anything other than zero it will install both packages and the Lync Mobility service will not work if you are directing users to your Directors!

 

So how did this happen and how do we fix this?

 

Well the issue was caused because I ran the following on both the Director and Lync Front End FQDNs:

 

Set-CSWebServer LyncDirector_FQDN –McxSIPPrimaryListeningPort “value” –McxSIPExternalListeningPort “value”

 

And specified a value other than zero, 0.

 

When configuring this service this should only be run against your Front End FQDNs.

 

So to fix this I ran:

 

1. Set-CSWebServer LyncDirector_FQDN –McxSIPPrimaryListeningPort 0 –McxSIPExternalListeningPort 0

2. Remove the Lync Mobility Service via the uninstall feature from Programs and Features

3. Re-deploy the Lync Mobility Service via the bootstrapper process (and as a side note only ever do it via .\bootstrapper.exe, running it via the UI appears to unlock a number of bugs)

 

You should now find you get the following on your Director:

 

 

All fixed!

 

Take care,

Oliver Moazzezi - MVP Exchange Server

 

 

Installing Exchange 2013 UM Language Packs

 

Following on from my previous article on Exchange 2013 UM integration with Lync, I said I would blog on how to install the language packs. This hasn’t really changed at all from Exchange 2010.

 

To download available UM language packs for Exchange 2013 see here.

 

To see my previous blog on installing and removing language packs for Exchange 2010 Unified Messaging see here.

 

 

 

Browse to the BIN directory to confirm setup.exe is present

 

 

In a command prompt move to the BIN directory

 

 

Run the following command:

 

 

 

It will then open a new window and begin installation:

 

Please hold.

Hold a little longer.

 

All done! Once completed the window will close.

 

 

If we now open up the EAC and browse to | Unified Messaging | Dial Plans | Properties of Dial Plan | Settings |  we should now see the additional language pack available:

 

 

Set your required default.

 

To perform the same action in Powershell we would perform: Set-UMDialPlan –Identity ‘DialPlan’ –DefaultLanguage ‘languagepack’ In my example below it is en-GB

 

 

Ensure the Language pack is installed on all Back End servers that are in the Dial Plan. It doesn’t need to be installed on your Front End servers.

 

That’s it!

I'll look to write a PS script to automate this across Back Ends and Dial Plans - stay tuned.

Take care,

 

Oliver Moazzezi - MVP Exchange Server

 

 

Configuring Exchange 2013 Unified Messaging for Lync 2010 Voicemail access

 

Following on from my Exchange 2013 OWA and Lync IM integration guide I thought I’d turn my attention to the Exchange 2013 UM service and Lync integrated voicemail. For my previous blog post see here.

Exchange 2013 has split the UM service across both the Front End and Back End roles. In the following blog I have the roles split – but if you have the roles co-located you still need to perform each step.

 

Whilst the Back End officially has the UM role as part of it’s colocation of all role services (Mailbox, Client Access, Hub Transport and Unified Messaging), the Front End actually has a UM service called the UM Call Router Service. This is effectively a proxy for UM calls to the Back End servers. For a full breakdown of Exchange 2013 Unified Messaging take a look at the TechNet article “What’s New for Unified Messaging in Exchange 2013” located here.

 

On top of the new UM service and the breakout of services between the Front End and Back End servers, some of the commands have also changed from Exchange 2010.

                Running Get-UmServer on Exchange 2013 no longer works
               

 

Firstly note that Get-UMServer has been depreciated. It has been superceeded by Get-UMService and there is a new set of commands for the UM Call Router service. In fact take a look at the updated parameters and new cmdlets here.

 

So as promised here’s a guide on setting it up from start to finish on setting this absolutely wonderful feature between Lync and Exchange up.

 

 

 

 

      1. Create a Dial Plan. This can be created in the EAC (Exchange Admin Center) but is performed in Powershell here. Note: it still appears to be a requirement to have your Exchange UM Dialplan names matching any Lync Dialplans you have created.

      New-UMDialPlan –Name ‘Name’ – URIType SipName –Numberofdigitsinextension ‘x’ –countryorregioncode ‘xx’ –AccessTelephoneNumbers +00123456789

     

      2. We assign UM servers using the ‘Set-UMservice’ cmdlet

      Set-UMService –identity ‘SERVER’ –DialPlans ‘Plan Name’

     
  
      Perform this for the rest of your Back End servers that require to be in this Dial Plan. If you have created the Dial Plan in EAC and not used Powershell as I have, you will have to click on the Servers in the EAC and then specify Unified Messaging to add them to a Dial Plan.

      3.  We now need to set the UM Service Startup mode to either ‘dual’ or ‘tls’. This can be performed in the EAC or Powershell. We need to ensure each Back End Server has a certificate that can be used to secure the service. Please see my last blog post here for setting this up.

      In Powershell set the startup mode using Set-UMService.

      Set-UmService –Identity ‘SERVER’ –UMStartUpMode ‘dual _or_ tls’

     
 
      Again note the need for the certificate. Perform this action on all required Back End servers. As a side note I did say you can do this within EAC. Login and go to:

      Servers | Your Server | Unified Messaging | Set the ‘UM startup mode’:

     

      4.  We now need to ensure the certificate for the UM service has been assigned to the UM service.

      Enable-ExchangeCertificate –thumbprint ‘thumbprint’ –services UM

     

      Repeat this for all Back End servers. If you do not set the certificate for UM then the UM service will be in a constant state of restarting when proceeding to the next step.

      5.  We need to know restart the UM service, again do this for all Back End servers that we have configured in steps 3 and 4. You can restart the Microsoft Exchange Unified Messaging service in Services under Server Manager or use Powershell. Note if using Powershell you will have to be running a ‘run as Administrator’ session or this will not work.

      Restart-Service –msExchangeUM

     

      6.  We also need to assign certificates to the UM Call Router service that is on the Front Ends.

      Enable-ExchangeCertificate –Server ‘SERVER’ –thumbprint ‘thumbprint’ –services umcallrouter

     

      This one threw me originally as I kept trying to enable it for UM – and that kept failing, until I realised through the help of the ECP that it has been renamed for the FE role. Be aware that you can assign the cert for a Front End for the UM Call Router Service in the ECP.

      7.  Restart the service, again you can use Restart-Service, however the service name on the FE is msExchangeUMCR. So:

     Restart-Service msExchangeUMCR

      8.  Finally we need to add the Front Ends to the Dial Plan also. This is done using the Set-UMCallRouterSettings cmdlet – different to how we have done it above for the Back Ends.

      Set-UMCallRouterSettings –server ‘SERVER’ –DialPlans ‘DialPlan’

     

      Ensure this process is completed for all Front Ends.

 

      It is absolutely imperitive that you add Front Ends that hold the UM Call Router service to the Dial Plans otherwise UM will not work. This is the proxy service that routes the calls to the Back Ends.

 

      Also be aware that there is absolutely no way to do this in the ECP that I could see, so this must be performed in Powershell.

 

      9.  We now need to run exchucutil.ps1 which is in the scripts directory in the Exchange 2013 install path. Run it from a Back End server.

     
 
      Run it within the Exchange Management Shell .\ExchUCUtil.ps1 it should complete successfully.

     

      10.  We now need to run OCSUMUtil.exe, this is in the script support folder on a Lync server within “\Common Files\Microsoft Lync Server 2010\”

      

     Once it has loaded click on the Dial Plans and then click on ‘Add’, this will create a contact as shown:

     

      Ensure the number is correct and matches the number you entered for the Exchange UM Dial Plan in step 1. Repeat this process for each Dial Plan you want to merge. Also be aware that should you ever add new Dial Plans or UM Servers repeat steps 9 and 10 to configure them with Lync.


      That’s it! Configuration is completed and voicemail integration between Lync 2010 and Exchange 2013 UM should be working.

As you can see it is wildy different in setting up UM on both the Front End and Back End servers, but the process does share some similarities with Exchange 2010. We still need to set the UM service to dual mode or TLS and assign a certificate, the Unified Messaging role has to be a member of a Dial Plan and we still need to run ExchUCUtil.ps1 and OcsUMUtil.exe

 

In a further blog post coming this week I’ll move on to adding Language Packs for Exchange 2013 Unified Messaging. In the mean time you can download them here.

Take care,

 

 Oliver Moazzezi - MVP Exchange Server

 

 

 

Lync 2010 and 2013 IM integration into Exchange 2013 OWA

IM integration was a great feature in Exchange 2010 and is followed through into Exchange 2013.

 

The steps have changed slightly however and the current TechNet documentation isn’t _that_ clear. So I thought I’d write it up. You'll find the TechNet article here, and I hope you agree my blog is more informative.

 

Exchange 2013 has two roles. The Front End proxy, and the Back End. The Back End co-locates all roles which are: Mailbox, Client Access, Hub Transport and Unified Messaging.

 

In Exchange 2010 you configured the IM integration entirely on the server that had the Client Access role. This could be a standalone server all co-located role server depending on the infrastructure needed. This was a config file at Exchange 2010 RTM and later moved to Powershell and settings on OWA virtual directories with SP1+.

 

In Exchange 2013 configuration is necessary on both the Front End and Back End roles. Again this can be co-located or standalone. I will treat them as separated for ease of understanding here.

 

 

Exchange 2013 Front Ends

 
1.    Perform in Powershell “Get-OWAVirtualDirectory”, you can use “Get-OWAVirtualDirectory –identity “Exchange2013FrontEnd\owa (default web site)” |select inst*” to immediately get the necessary information.

 

 2.  You will, if familiar with IM integration in Exchange 2010, be immediately at home here. However for IM integration in Exchange 2013 we only set two of the above four values. The values are ‘InstantMessagingEnabled’ and ‘InstantMessagingType’. We leave both ‘InstantMessagingCertificateThumbprint’ and ‘InstantMessagingServerName’ blank. This is very important as it actually does break the integration between Lync 2010 and Exchange 2013.

      We can set these values with the following command:
  
       3.      “Set-OwaVirtualDirectory –identity “Exchange2013FrontEnd\owa (default web site)” –InstantMessagingEnabled $true –InstantMessagingType OCS”

 

(Ignore the yellow text in my example below – I’m running the command to show you but as I’ve already set these attributes it’s telling me no settings have been modified)

       4. Perform the above command against ALL your Exchange 2013 Front End servers in your       associated sites that need IM integration.



      Exchange 2013 Back ends

      5.   Once this has been set we need to configure certificates. But the certificate configuration is on our Back End Exchange 2013 Servers. Browse to your Back End Servers and generate a new Certificate using New-ExchangeCertificate against the internal CA that Lync uses. I recommend this TechNet article for Cert creation: http://technet.microsoft.com/en-us/library/aa998327.aspx

 

Use the following two commands:

 

$Data = New-ExchangeCertificate –GenerateRequest –SubjectName “details here, use server FQDN as CN” –DomainName “FQDN of server” –PrivateKeyExportable $true –FriendlyName “Desired Cert Name”

Then:

Set-Content –Path “x:\your desired location” –Value $Data

      6.    Once this is done we need to complete the signing request against your internal certificate authority. I have used the web request of our SubOrdinate for this example. Use the same internal CA as what you used for SSL procurement for your Lync platform!

     
   
      Save the signing request.

        7.  We now need to complete the signing request using Import-ExchangeCertificate. Information on this cmdlet is available here: http://technet.microsoft.com/en-us/library/bb124424.aspx

       “Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path ‘x:\cert location’ -Encoding byte -ReadCount 0))

The certificate is now installed.

 

Ensure you do this for all Exchange 2013 Back End Servers.
  

8.        We are now in a place where all our Exchange 2013 Front End Servers have had the necessary configuration via Powershell and ‘Set-OWAVirtualDirectory’, and we have installed Certificates on all our Exchange 2013 Back End servers. We now need to edit a web config file on each Exchange 2013 Back End.

      The file we want to modify is the web.config file in the following location “x:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa”. Where x is the drive you installed too.

     

     9.    Open the Web Config file and perform a search for “</appsettings>”. This takes you to the end of all App Settings configuration. Add these two lines in:

    <add key="IMCertificateThumbprint" value="Enter Thumbprint here!" />
   <add key="IMServerName" value="FQDN of Lync Pool or Director Pool" />

   

   You can see I have commented this out to explain the change I am making.
 

 It is important to note that the thumbprint you enter in each web.config file is the thumbprint of the Certificate you have created on each Back End server.

      10.   Once you have performed this on all Back Ends we need to open the Lync Topology Builder and enter each Back End as a Trusted Application

       Add each Exchange 2013 Back End server separately, matching the FQDN of the server and the certificate published for the Back End as the Trusted Application. Add all required Exchange 2013 Back Ends.

     

      11.   Once created you can edit them and remove ‘Enable replication of configuration data to this pool’ as this is not needed for Lync IM integration.

     

     12.  Once all have been added Publish the Topology.

    13.   We now need to open a Lync Powershell session and perform the following:

       New-CsTrustedApplication –ApplicationID “Server Name” –TrustedApplicationPoolFqdn “FQDN of Exchange 2013 Back End server” –Port ‘desired port number’

I     Set the ApplicationID as the server name for easy reference. Set the TrustedApplicationPoolFQDN as the FQDN of the Exchange 2013 Back End you are adding. Add a port number that isn’t in use. I normally start at 5070 and work my way up after ensuring they aren’t in use.

      14.  Once this is done ensure you repeat it for every Exchange 2013 Back End server that you need and indeed published in the Topology Builder in step 11. and 12.

       15.  Finally we may need to do the following two things to get Lync IM integration working.

      The first is to recycle the MSExchangeOWAAppPool on each Exchange 2013 Back End. This is needed to be done only if IM integration is not working in OWA.

       The second is to restart IIS on each Exchange 2013 Front End server. This is needed to be done only if IM integration is not working in OWA.

 

     16.    Open OWA. You should now be able to sign in and see this:

      

      The first thing you’ll notice over Exchange 2010 OWA integration is that the contact list is not shown on the left pane anymore. You have to get it from the People Hub.

       


     If you aren't seeing the above then you may have an OWA Mailbox Policy that isn't allowing IM. Perform in Powershell: Get-OWAMailboxPolicy to confirm against the affected users.

     In the event this is the issue, use:

     "Set-OWAMailboxPolicy -identity 'OWAMailboxPolicy' -InstantMessagingType OCS" to fix.

    That’s it! Take care.

   

     Oliver Moazzezi - MVP Exchange Server