Unified Messaging
Create Custom Music on Hold for Cisco UCME
Feb 24th
Here’s one from my personal tip jar. This is well documented on Cisco’s website, but sometimes it’s just nicer to have this type of info in bite-sized portions.
As nice as the canned music on hold files are that come with Cisco Unified Communications Manager Express, sometimes you just want to add that personal touch.
A custom MOH file format must be 8khz 8-bit mono u-Law audio in WAV or AU.
Tools
- Sound editor (I prefer Audacity, as it’s free and does a great job)
- Sound recording (create your own or use your favorite song(s))
Prepare the Sound File
I’m not going to go into how to use Audacity, for that you should check out their well documented website. However, here are some tips related to preparing your sound file for use as a music-on-hold file.
- Adjust your sound levels prior to saving/converting your file, as you can’t adjust audio levels in UCME. Often what sounds great on your computer speakers can be blaring at best or ear-drum shattering at worst playing through the phone system.
- Encoding options:
- Output format: .au or .wav
- Codec: uLaw
- Sample Rate: 8000 or 8khz
- Channels: Mono
When you have your sound file prepared, upload your MOH file via TFTP to the router’s flash file system. I use TFTPD32 for this.
Configuring UCME
Lastly, you’ll need to configure UCME to use the uploaded file for your music on hold.
Configuration Steps:
1. enable
2. configure terminal
3. telephony-service
4. moh filename
5. multicast moh ip-address port port-number [route ip-address-list]
6. exit
7. ephone phone-tag
8. multicast-moh
9. end
Grant Full Access to All Mailboxes in Exchange 2010
Jan 26th
Here’s a little time-saving tip for working with mailboxes in Exchange 2010. Normally if you need full access to another user’s mailbox in Exchange 2007/2010 you would highlight their mailbox in the Exchange Management Console and the choose “Manage Full Access…” from the action pane. You would have to do this individually for each mailbox that you wanted to manage full access permissions for.
Here’s an easier way to grant full access to a user for every mailbox in a mailbox database. Just edit the bracketed fields below and paste the cmdlet in the Exchange Command Shell:
Get-MailboxDatabase -identity “[mailbox database name]” | Add-ADPermission -user [username] -AccessRights GenericAll
Voila! You now have full access to all mailboxes in the selected database. This even applies to new accounts created after you run the cmdlet.
Exchange 2010: Simplify OWA URL
Dec 16th
Exchange Outlook Web Access is a wonderful feature, but directing users to access it on their own can be a patience testing proposal if you’re not using URL redirection.
For example: you’ve installed Exchange 2010, configured all the appropriate roles, including the CAS (Client Access Server; responsible for OWA), and deserve a hero’s welcome, or at least a pat on the back. You then send an email to staff telling them that they can access webmail from the following public URL – https://webmail.domain.com/owa; easy enough right? Wrong! A few days later, calls come streaming in with users attempting to access OWA using incorrect URL’s: http instead of https, forgetting to append /owa to the URL, etc.
Well you can clear all of this up and make it transparent to the user, and they’ll never know you did it; it will just work.
With Exchange 2010 and IIS 7, the process for redirection has been greatly improved over IIS 6. Before, I would place a custom page in the “wwwroot” directory that would automatically redirect the user if they didn’t use “https” or if they didn’t append the “/exchange” (Exchange 2000/2003) or “/owa” (Exchange 2007) directory. This was a combination of customizing the “403.4″ error and the home directory settings (maybe a later blog post, if requested).
In IIS 7, you only need a few mouse-clicks and your proper OWA URL to accomplish the same thing.
Open IIS 7 manager and navigate to your “Default Web Site“. In the options panel, open “HTTP Redirect“
Enter the proper OWA URL (i.e, https://webmail.domain.com/owa), select the “Only redirect requests to content in this directory (not subdirectories)” checkbox, and click “Apply“.
This will apply the redirection to ALL subdirectories of the default site, so you’ll need to click on each subdirectory/virtual directory and remove the redirection by unchecking “Redirect requests to this destination“. We only want to redirect the top level of the default site.
Note: The Exchange, Exchweb, and Public virtual directories should redirect to /owa. This is for coexistence scenarios with older versions of Exchange (2000/2003). There should already have been redirect settings in place for this, just make sure that these settings were not affected by adding the redirect above.
Next, we want to remove the SSL requirement from the default site. Yes we still need to use SSL to access OWA, but if we require it at this level, any user that enters the OWA URL without “https” will receive an error message.
Since any changes made to the “Default Web Site” propagate down to subdirectories, as in the “HTTP Redirect” example above, review the following subdirectories and make sure that “Require SSL” is enabled:
- Autodiscover
- ecp
- EWS
- Microsoft-Server-ActiveSync
- owa
- Rpc
- RpcWithCert
Finally, don’t forget to restart the website and test.
There are some scripts floating out online that will perform these steps for you, such as this one, but I have not had a chance to test, so proceed with caution….and then let me know how it turned out!
Installing a Unified Communications SSL Certificate for Exchange 2007
Aug 11th
Secure communications in an Exchange enterprise messaging environment is critical. In Exchange 2007, Microsoft introduced the use of Unified Communications (UCC) or Subject Alternative Name (SAN) SSL certificates. These Secure Sockets Layer (SSL) certificates allow the secure use of multiple domain names with one certificate, with some certificate providers allowing the use of up to 100 domain names. By default, when initially installed, Exchange 2007 provides a self-signed certificate which secures the hostname of the server (netbios and FQDN). For any use outside of a lab environment, you’ll want to purchase and install a UCC certificate. UCC certificates can be purchased from any major SSL certificate provider (i.e., GoDaddy, GeoTrust, Entrust, Comodo, etc.).
In this example, I’ll show you how to replace a single domain third-party certificate and a self-signed SSL certificate with a new UCC certificate.
Step 1: Certificate Signing Request (CSR)
This is the “planning” stage. The most important part of creating your CSR is to pick your domain names carefully. I recommend using a (5) domain name UCC certificate, using the following names:
- mail.example.com (Internet FQDN)
- example.com (Internet domain)
- InternalHost (Internal hostname)
- InternalHost.example.com (Internal FQDN)
- autodiscover.example.com (Internet hostname used by the “autodiscover” service)
Using the Exchange Management Shell, generate the CSR:
New-ExchangeCertificate -GenerateRequest -Path c:\cert\mail_example_com.csr -KeySize 1024 -SubjectName “c=US, s=State, l=City, o=CompanyName, cn=mail.example.com” -DomainName example.com, InternalHost, InternalHost.example.com, autodiscover.example.com -PrivateKeyExportable $True
Navigate to the path where you saved your CSR in the command above (c:\cert\mail_example_com.csr), open it with notepad or your favorite text editor, and copy all the text. Login to your SSL certificate provider’s website and paste the text in the appropriate form. Depending on their verification process, your certificate will be approved in anywhere from a couple hours to a day.
Step 2: Install and Enable New UCC Certificate
Follow directions provided by your SSL certificate provider to install any required intermediate certificates, if applicable. Copy your UCC certificate to an easily accessible path on your Exchange server (i.e., c:\cert\), then issue the following command using the Exchange Management Shell:
Import-ExchangeCertificate -path c:\cert\mail.example.com.crt -friendlyname “GoDaddy UCC 2009″ | Enable-ExchangeCertificate -services “IIS,POP,IMAP,SMTP” -Force
Step 3: Remove Expired or Unnecessary Certificates
Record the thumbprints of the existing certificates that you wish to remove:
Get-ExchangeCertificate | ft
OR
Get-ExchangeCertificate | fl
Removed expired third-party single domain certificate:
Remove-ExchangeCertificate -thumbprint [thumbprint ID]
Removed self-signed (hostname) cert:
Remove-ExchangeCertificate -thumbprint [thumbprint ID]
Step 4: Wrap Up
To flush out all changes, restart the following service: Microsoft Exchange Transport
Enjoy!
