Phone system deployments are complicated no matter how much planning you do, because there is a lot to consider and think about, and this is especially true when you’re looking to integrate with other technologies. The goal of this post is to help you consider all the pieces of your environment and give you reasoning for my own choices.

The categories in my deployment plan can be broken into the following subsections:

• Extension Planning
• User Planning
• Phone Planning
• Voicemail Planning
• Mobility Planning
• Hunt Group Planning
• Music-On-Hold Options
• Paging Options
• Analog Devices
• Unified Presence
• Testing and Training
• Go Live and Disaster Recovery

In this post, I will discuss the first four items.

Read the rest of this entry…

My big project at work for the next three months is to implement Cisco Unified Communications Manager into our enterprise and specifically tie it in with our Exchange server for unified messaging, and it’s a project I’ve been looking forward to for a very long time now. So here’s a bit of background…

Currently, I have an NEC Electra Elite IPK-II PBX system that I loathe with every fiber of my being. It’s slow, it’s complicated to manage, it’s archaic and lacks functionality beyond call routing, and quite frankly it does a pretty horrible job of routing calls too. I have to 23-channel PRI’s with about 60 Direct-In-Dial (DID) lines assigned to various users and fax lines, but most people call into the receptionist number and get redirected that way. We’re generally a very personable enterprise and wish to avoid auto-attendant setups as much as possible, but that has created a lot inefficiencies and annoyances because of our existing phone system. Unfortunately, we spent a lot of money on this system at the start of 2009, because I had just started and we were in the midst of a hospital expansion, and my boss and I didn’t have the time or resources to investigate Cisco UCM sooner.

Last year, as we reached capacity limits on the NEC system at a time when we were still growing and needed mobile solutions, we decided to band-aid the solution by implementing Cisco Call Manager Express, and we used that to overcome some of the capacity limitations of the NEC system, and we were able to leverage our wireless infrastructure to implement Cisco 7921G wireless phones. For a year, this has been a great solution and has introduced our staff to some of the benefits of a full-blown Cisco solution. So I set to work on a proposal to replace the entire NEC system.

Read the rest of this entry…

It’s been a really long time since I last posted here, because I really haven’t had the time, interest, or content to post to make it a worthwhile endeavor for myself or potential readers. All of what I could have posted can be found elsewhere, so I felt no need to just parrot existing information.

However, I’m hoping this is about to change. I’m about to implement Cisco Unified Communications Manager 7.1 in my enterprise with a direct integration with Microsoft Exchange Server 2010, and as I scour the web for resources, I am discovering that information is scattered and repeated far across the web. Unfortunately, half of that information is highly technical for system administrators who are just getting started with these technologies, and the other half of it is incomplete or scattered. So my goal from here on out is to discuss the implementation process from beginning to end in layman’s terms for the new Unified Communications and Unified Messaging Administrators like myself.

Read the rest of this entry…

In my test lab environment, I recently attempt to upgrade from Exchange 2007 SP2 to Exchange 2010. Mostly, it went just fine, but then I started making some changes along the way and things went terribly wrong… I started getting the following error when installing/removing components:

Setup previously failed while performing the action "install". You cannot resume setup by performing the action "BuildtoBuildUpgrade"

Setup previously failed while performing the action "uninstall". You cannot resume setup by performing the action "BuildtoBuildUpgrade"

The trick to solving these errors is simple, but finding the solution took me several days of research, since Google and Bing searches produced only a handful of results with people having the same problem but none having the answer.

One forum mentioned something about the HKLM\Software\Microsoft\Exchange registry location and looking for a “Watermark” DWORD value. Well, turns out, this is partially right, but there’s more to it than that. For each role installed, there are 3-4 values… “Action”, “ConfiguredVersion”, “UnpackedVersion”, and “Watermark”.

Now ordinarily, Action and Watermark  shouldn’t show up from what I can tell. If they do, that’s the problem. The errors above are generated when a previous attempt to install/uninstall/upgrade failed and left those two values behind.

Deleting the two values ensures that you’re able to proceed again with the setup process. But here’s where we run into another snag… because the previous process didn’t work, you’re going to be left with some files and data lingering that probably ought not be. Because of this, I would personally recommend that you INSTALL any affected roles from scratch, reboot, and then uninstall them (if that was your desired course of action).

Of course, if you’re trying to install/re-install, I would recommend uninstall Exchange in its entirety first and then re-installing. Annoying? Yeah. Definitely. I hope that Exchange Server 2014 (or whatever year is next) will have the Exchange team focusing on the setup process a bit, because in my opinion the readiness checks are nice, but need a lot of improvement too.

Quick word of advice to anyone doing a Unity Express upgrade (of any kind)… always reboot your CUE module first to make sure there’s plenty of memory available for the install process.

This is an easy tutorial for configuring a Cisco CallManager Express (CME) system to use Exchange 2007/2010 Unified Messaging for voice mail and other Exchange messaging needs. For what it’s worth, I highly recommend using 2010 instead of 2007 due to the MWI (Message Waiting Indicators) functionality, but there are add-ons for 2007 to enable it as well.

Read the rest of this entry…

Over the past several months, I’ve spent an insane amount of time working with my business’s NEC vendor and our Cisco vendor to implement a SIP integration between a Cisco CallManager Express install and our existing NEC IPK II PBX phone system. Eventually, this post will become a full step-by-step, but for now I’ll start with a list of the major problems and quick solutions:

1. Make sure your NEC system has a slot with enough power for the SIP card, otherwise, you can configure it all you want, but it will never be able to establish a call. Total time spent by our vendor on this: 1.5 months. Reason: We actually had multiple hardware failures on the NEC side during this diagnostic, so we spent more time fixing those than dealing with the SIP integration.
2. Don’t let your vendor convince you that “station side” implementation is either necessary or recommended. In fact, SIP Trunking is definitely recommended unless you need more than 24 trunk ports between the two systems. Total time spent on this debate: 2 weeks. Reason: Your NEC SIP licenses are essentially “per connection”. If you’re like me, you plan to grow your Cisco solution but won’t have more than 24 concurrent connections between the two. This way is cheaper and keeps you less dependent on the NEC system. The reason station side is recommended by NEC is that it supposedly allows more functionality and control on the NEC side which probably isn’t all the desirable, and really I haven’t seen any evidence of it being true.
3. DTMF (touch tone) support isn’t going to work with the default settings on either system. In order to make it work, on your NEC system you have to go to 84-13 in System Data to enable DTMF Relay Mode as RFC2833. On the Cisco system, you need to enable dtmf-relay rtp-nte for each dial-peer (except your Cisco voicemail/auto-attendants which should be sip-notify) along with nte-end-digit-delay 50 for each ephone device connected. Total time spent determining this fix: 3 weeks, and I finally figured it out since our NEC vendor washed their hands of it and the Cisco vendor was convinced the config was right with just the rtp-nte. Actually, it really is a problem on the NEC side, because IPK II doesn’t allow the beginning and end packets to be sent/received at the same time per the RFC2833 spec. the nte-end-digit-delay setting basically provides a work-around to tell the Cisco system to slow down the tone packets so that the NEC system can get a clue what to do.
4. Caller ID is still a problem for us… Cisco to Cisco and Cisco to NEC is perfect, but the NEC system doesn’t seem to pass the proper Caller ID information back to the Cisco system. I’m still working on finding a solution, but I’m on my own, because our NEC vendor insists that it’s not possible, just like they insisted DTMF was never going to work. Update: I finally discovered that the issue is how NEC is sending the ID string during call initiation. While the standard is “Display Name”[Extension@SIP_IP_ADDRESS], NEC insists on using “Extension”[PrimaryNumber@SIP_IP_ADDRESS] which is not standard practice. I’m still looking for a fix for this.
5. Make sure you have decent vendors on both sides. There’s going to be a lot of blame to pass around when things don’t work. Don’t make it worse by allowing either vendor to be incompetent about the process. Work with them both directly, and make both work together to get it working! Hopefully my advice here will make someone else’s life a whole lot easier!

All that said, moving away from the NEC PBX solution to a full-blown Cisco VoIP solution is highly recommended, and much more cost effective in the long run. You may pay more up-front for the Cisco implementation, but the support costs are drastically reduced and support efforts significantly reduced… not to mention the total boost in functionality and expandability by comparison.

One of the favorite customizations of Cisco Call Manager systems is to install and enable custom ringtones. Doing this with the bundled stock ringtones is easy enough, but for those who don’t want to wade through complicated technical documentation, here’s a straight-forward guide for the entire process of making your own and publishing them on your CM/CME device.

To begin, you’ll need three things to begin:

• Digital copies of your desired ringtones… MP3’s, WMA’s, WAV’s, etc.
• WavePad… inexpensive audio editor that makes conversion and editing of ringtones a cinch. It’s free for trial if you’re only planning to use it for a short time, but I highly recommend buying it… it’s also less than Audition which is the only other program that is “recommended” by various posts on the Cisco Support Forums.
• Cisco Configuration Pro (requires Cisco.com login with download privileges)… Cisco utility for Integrated Services Routers (provides a simple interface to upload your files), if you’re running CME.

Creating/Editing Your Ringtones

1. Once you install WavePad, open the program and create a new file based on the parameters shown here:
• 
2. Click Edit > Insert File > Begin, and pick the audio file to use as your ringtone.
3. Edit the file to be less than 20 seconds (18 seconds is the default ring sequence for CM/CME).
4. Save the file as a RAW format (don’t use spaces or punctuation in your names), and when prompted, use the following parameters:
• 
5. Rinse and Repeat for each desired ringtone.

Preparing the RingList.xml File

Once your ringtones are ready, you need to create a RingList.xml file that will be uploaded in conjunction with the ringtone files. The file can be created and edited with Notepad or other plain-text editor and should look like this:

<CiscoIPPhoneRingList>
    <Ring>
        <DisplayName>Bass</DisplayName>
        <FileName>Bass.raw</FileName>
    </Ring>
</CiscoIPPhoneRingList>

For each ringtone you add, you need a <Ring> tag, the DisplayName and FileName tags, and a closing </Ring> tag. For example:

<CiscoIPPhoneRingList>
    <Ring>
        <DisplayName>Bass</DisplayName>
        <FileName>Bass.raw</FileName>
    </Ring>
    <Ring>
        <DisplayName>Chime</DisplayName>
        <FileName>Chime.raw</FileName>
    </Ring>
</CiscoIPPhoneRingList>

Again, when finished, save the file as RingList.xml and put it in the same location as your ringtones for the following section.

Uploading Your Ringtones and RingList.xml Files

The goal here is to get your files onto the server. Now, there’s varying ways to do this… Telnet/SSH via command-line, TFTP, but I recommend using the Cisco Configuration Professional utility’s File Management tool or the same tool in the older SDM tool. CCP is perfect for CME-based Integrated Services Routers, but may not be as perfect for full-blown CM solutions. In this case, use the tools that work best for you, but ultimately, you need to upload to your CM/CME devices storage for use with its TFTP service.

Once the files are uploaded, dump to command line’s config terminal prompt and issue the following commands:

tftp-server flash:Ringtone.raw
tftp-server flash:RingList.xml

Repeat the first command for each ringtone, replacing Ringtone.raw with the actual filenames.

Once this is done, you may have to restart the TFTP service on full-blown CM servers due to file caching, and you definitely have to issue a “reset” your phones (in other words, restart them). Your ringtones should be listed and working perfectly.

Why did I feel a need to document this when it’s largely a rehash of the Cisco document found here and elsewhere? Simple. The Cisco document gives you the audio parameters required for the audio files, but it makes no recommendation on the programs to use. I really feel it’s important to document exactly what tools work easiest to get the job done. WavePad makes it easy, and let’s face it, the Cisco document does assume you’re quite versed in the whole process.

Quite some time ago, I migrated my website to a Windows Server 2008 system with IIS7. Since my blog is based on WordPress, I was quite pleased when I discovered the IIS7 URL Rewrite module that allows me to create “pretty” URL paths instead of the usual date/time URL’s that WordPress normally uses.

Unfortunately, enabling these rules broke my Outlook Web Access with Exchange 2007. I was able to login to OWA without issue, but I’d constantly get “Access Denied” prompts when trying to navigate to folders, open emails, write emails, etc etc.

The problem ended up being that my URL Rewrite rule was incomplete. In order to make the URL Rewrite rule for WordPress coexist with OWA, I had to add an extra condition to the rule:

Basically, in addition to setting the default pattern as .* and your URL rewrite target as index.php, you also need 3 conditions. The first two are included in the documentation on the IIS.net site, however, the third one– {PATH_INFO} Does not match the pattern /owa/ — is the one required for OWA coexistence.

Hopefully this information will help others who may be running this similar configuration.

One of the things I needed to do at work was to give myself remote desktop capability to a terminal server on my networks for off-site administration.

To do this, I logged into my ASA 5505 and used  the following commands:

access-list acl_out permit icmp any any
access-list acl_out permit tcp any interface outside eq 3389
global (outside) 1 interface
static (inside,outside) tcp interface 3389 Terminal-Server-IP 3389 netmask 255.255.255.255 0 0
access-group acl_out in interface outside

On one of my devices, I couldn’t figure out why it wasn’t working, but it turned out that I had forgotten the last command which enables the access-list on the outside interface.

One important note here is that you should make sure the name “acl_out” is appropriate for your configuration. If you’re not sure, you can use “show access-list” to figure it out. Also, make sure you replace “Terminal-Server-IP” with the internal IP address of your server.

Oh and this isn’t exclusive to Remote Desktop either… you can replace 3389 with any port needed (ie 80 for web or 110 for POP, etc).