Friday, May 3, 2013

CCIE Voice Lab Strategy Part 4 - Morning Configuration Strategy

In a previous installment of this series I went over planning a configuration strategy and the first configuration phase of my lab approach. Including the read through, I would be somewhere around 2 hours into the lab at this point. IMO, these are the most critical minutes of your exam day (followed by the first 30 minutes after lunch). 

It is during this first 120 minutes where you establish a good rhythm and you should be firing on all cylinders. You don't want to lose this rhythm as move into the next configuration phase, which is CUCM provisioning.

In this installment I will cover the CUCM provisioning and move on through the configurations I try to nail down before lunch. 
A Word on Modularity

If you haven't figured this out by now, I am a bit of a process freak. I use words like "phase", "tactics", and "strategic objectives" in my blogs. This is probably the one place where I can let go and relax on protocol. Well, this is relaxed! I always tend to sort and categorize things by "phases" and "attributes" and "relationships". Yeah, I got dork-dom down. It is in my nature.

Anyway... "phases". When I was studying for my exam I started putting together my strategy early on I started building a list of what I call configuration phases. I would organize my self study labs and drills by their association to certain phases. I would do timing drills within individual phases. When I would do full blown mock labs, my time tables (used to track progress) were also organized by the configuration phase. 

Why is this important? Grouping tasks into phases helps you map out your day and practice your timing to a set plan. You should be comfortable with experimenting with your process. This helps you understand dependencies and how well certain tasks flow together. At one point I was getting frustrated with myself for tweaking too much. Of course, I now look at my experimentation as a positive thing. At the time, I didn't realize that the exercise of trying different approaches helped me to gain the confidence needed to navigate unforeseen challenges in the real lab.

So, I highly recommend you take time to organize your strategy in a modular fashion and be willing to experiment. Don't ask questions like "should I use the GUI or CLI to provision CUE?". Practice both, think of both in context to your other configuration tasks and pick what has the best overall fit. 

Now, I tweaked my strategy up until my last week of studies. However, in that last week I did no tweaking. I believe Kevin Wallace characterized the days leading up to your exam as the "bomb run". It is a good analogy. You get to a point where you should just put your head down and practice your "ideal" configuration strategy. Don't deviate. Just be prepared to dodge, weave, and jump hurtles on your lab day or the only thing you will be blowing up is --- well, you.

Task List

After the Base Infrastructure configuration phase I move on to the Base CUCM Configuration. The following "table" shows roughly where I am in the process. The blue cells are configurations associated with the transition from the Base Infrastructure to the Base CUCM. The SRST configurations are being developed in notepad and I don't apply them until much later. The crossed out cells are completed config tasks and the red cells are for the phase following the Base CUCM.


If you read the last installment then you may recall that I don't just finish the Base Infrastructure config and jump right into the Base CUCM. I am trying to smooth the transition and maintain the rhythm that I worked up to in the previous phase. 

As I transition, I am opening a RDP session to UCCX for the purpose of launching an IE session from UCCX to CUCM. I am also launching a separate IE session to CUCM on my candidate PC. At this point I have done my NTP work, I have started (and likely finished) my SRST configs in notepad, and I am ready to get my CUCM jig on. All the while, I am doing the proper care and feeding of CUE. 

After provisioning NTP on CUCM I recommend you run a dbreplication status check on the CUCM publisher node. Do not use RTMT or Cisco Unified Reporting to look at replication status/replicates. Those reports are not always accurate. I have hit DB replication issues when doing practice labs (never in the real lab). If you do hit a replication issue, fix it. Don't wait. Don't freak out, just fix it.  

Following the NTP/DB config step I move on to:
  • Service Params for CUCM. I do this in UCCX. I have already logged into UCCX by this time and launched a web browser (I am an Alt-Tabbing fool). I have a base set of service parameters I always apply and I take note of additional parameters during the read through. The goal is to knock it out in one blow.
  • Enterprise Params for CUCM. At the same time I am doing my thing in UCCX, I am browsing to the Enterprise Parameter page in CUCM. Yes, I have a set of Enterprise Params I configure by default (and I check things, like auto registration protocol). 
I am executing the above configs in parallel. You see there are pauses when you click through these pages. They are relatively short (a couple of seconds). However, I don't wait. I click, alt-tab, click, alt-tab, fill in, save, alt-tab, etc. Is it faster? I don't know but my goal is to carry a steady rhythm through this transition period.

After I configure the service/enterprise parameters I will then configure DHCP in CUCM. I use the candidate PC browser for this. When configuring DHCP in CUCM, I make sure I copy/paste the IP address information I put in notepad during the read through. Meanwhile, I use the UCCX browser to go check the service activation and status. 

Once I have DHCP provisioned I transition to enabling switch ports (which I disabled during my Base Infrastructure config). I let the phones auto register to the CUCM. I let this run in the background. If the phones have issues I don't bother looking at it right away. Don't forget to check in on CUE.

CUCM Device Provisioning

I execute the Device Provisioning phase with complete focus. No jumping around to other windows. Most of my configuration comes from my "mental template".  I use the "basic.txt" config file I capture during the read through to augment or customize my config. 

You should note that this configuration phase isn't really in the task table as one task. Most of the work is just foundation for the device-specific tasks. I basically "walk" the CUCM configuration menus and set the stage. At a high-level I configure the following, in the order listed:
  1. System > Cisco Unified CM.  Setting auto-reg.
  2. System > Cisco Unified CM Group.
  3. System > Date/Time Group
  4. System > Region
  5. System > Location
  6. System > SRST (Yes, I set SRST reference - I don't use default gateway)
  7. Device > Gateway (I add a dummy h323 gateway for staging LRG)
  8. Voicemail > Pilot
  9. Voicemail > Profile
  10. Media Resources > Media Resource Group
  11. Media Resources > Media Resource Group List
  12. Call Routing > AAR
  13. Call Routing > Route/Hunt > Route Group (I add LRG for each site)
  14. Call Routing > Class of Control > Partition
  15. Call Routing > Class of Control > Calling Search Spaces
  16. Device > Device Pool (I add all relevant device pools)

Once I complete the foundation work, I can then add devices. I don't think order matters here but I like to add media resources first and then I add voice gateways. When I add MGCP voice gateways I will use the config statements I built in notepad (during the Base Infrastructure config phase) and paste them into the appropriate router. Obviously, this is done after the gateway is configured in CUCM. 

I move on to phones and users after the media resources and gateways have been provisioned and registered. I do the following when provisioning phones and users (leveraging my "basic.txt" file heavily):
  1. Configure all IP phone services (note, I recommend memorizing all of the URLs)
  2. Configure phone button templates and soft key templates (as needed)
  3. Provision Directory Numbers
    • Call Routing > Route Plan Report and  delete unassigned/unallocated DNs
    • Go to Call Routing > Directory Number and create ALL DNs
  4. I use SQL from the CLI of the Publisher node to provision devices and DNs
  5. I use BAT to round out the Device provisioning
  6. I walk through the users and associate devices/lines
If I did my job correctly all phones, gateways, and media resources are fully configured and registered. If my phones have issues registering then I will work on resolving issues because I want my phones up and happy before moving on to the next phase.

Tangent Alert!!!

I should pause a moment here and clarify something. In my example walk through I am focused on a configuration where all phones are registering to CUCM. There are other variants. For instance, if one of my sites had phones that were registering to CME then I would work on finishing that configuration at this point in the game. 

VM Apps Provisioning

The next phase is VM provisioning. In my PoV, this is the next logical step. I use the import process for CUC and CUE. I know, people say the CUE CLI is the cat's meow and blah blah blah. That's cool dude, I just use the GUI. Especially when I am doing a CUCM-CUE integration. 

I start with CUE during this phase because you have to bounce that damn thing one last time when integrating with CUCM. I want to get that step out of the way. So, I configure the CTI route points and CTI ports. I have already created the profile/pilot number. Once I have the CTI stuff configured I add the appropriate application users (depends on requirements). I do all of the device association steps and move on.

Tim to go back to my Alt-Tab waltz. Using my UCCX RDP session I web to the CUE host. I will use that session to walk through the wizard. Meanwhile, I will double-check/provision the Unity Connection stuff in CUCM. At the same time, I open a tab in my candidate PC browser and go to Unity Connection. As noted previously, I click and alt-tab between all of the interfaces. I don't wait for the browser to render the next page. I just keep moving between all three interfaces.

Once I have the users imported in CUE, I restart the module (see you in 20 minutes). BTW, has anyone in Cisco ever stopped to think that Express implies fast to some people? Anyway, by the time I bounce CUE I have also finished configuring users in Unity Connection. Since my mind is on voicemail, I will go ahead and finish all of the Unity Connection tasks. I'll finish CUE later.

WAN QoS Provisioning

I know some people do the WAN QoS way before this point in the game. That's fine. I wait on WAN QoS for several reasons. First, I want to see my devices register before I do something that could "break" that registration. I don't want to think too deeply on root cause when phones are spinning. When phones are struggling to register before I do QoS I know it is a port, DHCP, or vlan screw up. If phones start struggling after I do QoS I don't have to think too hard about what went wrong. Second, if the bandwidth between my HQ site and the site running CUE is supposed to be 384kbps then walking through the wizard could be sluggish. Finally, I want to get to the final reboot of the CUE as fast as possible.

So, WAN QoS is pretty straightforward. First and foremost, I save the current configs and make a backup copy before proceeding. Unless I am being asked to do class-based shaping I use auto qos. I start on the HQ site. After auto qos runs, I do some show commands to pull configs into notepad and then I tweak. Paste the configs back into HQ and then move on to the next device. Depending on what I am being asked I may just copy from the HQ config or I may run auto qos again. 

I recommend doing a full validation of WAN QoS once it is configured. I reboot phones at the remote site(s) and make sure they register OK (validates fragmentation). I place calls between phones and check policy map counters. I also make sure I have full duplex audio. Then I save the config and move on. No need to check WAN QoS again.

Time Check

After I provision WAN QoS I do a time check. I choose my next tasks based on how much time I have before lunch. The following table shows where we are up to this point. The tasks that are red with a strikethrough are done. The blue tasks have the competed SRST configurations in notepad but they haven't been applied to the router yet. 

If I have 0 minutes before lunch (i.e. time to leave) I save configs and walk away. If I have somewhere in the neighborhood of 5 to 10 minutes (meaning, the proctor has come in and given the 10 minute warning) then I will configure some features (i.e. I put off applications like CCX and CUPS). 

For instance, sticking with the example above, I would finish out CUE so that I can be done with voicemail. Following that, I would probably knock out the MVA task under Branch 1. I held off on this task because I wanted to make sure the service was provisioned in CUCM. Since I am touching MVA here I would likely configure the mobility bits in CUCM. That task  will likely eat up 5 minutes or so. After I did the mobility stuff I would do another quick time check. If there is time remaining I would start working the CUCM features. 

The point is keep working until you are told to stop. Don't be an ass and continue working after everyone is going to lunch. Take 30 seconds or so to save configs and just walk away. 

Where do we go from here?

Lunch? Yes, lunch. This is my least favorite time of the whole day. All I want to do is get back to my rack but you do want to eat. I recommend eating light. I avoid carbs and cookies or whatever they brought to the party. If your morning didn't go as planned then take time to calm yourself down and focus on what you are going to do in the afternoon. Don't fret over what happened in the morning, because you can't do anything about it now. 

The Series

This wound up being a 5 part series. I break my strategy down as follows:

Part 1: Formulate Your Strategy discusses the more well-known configuration strategies that can be used to successfully achieve the CCIE

Part 2: The Read Through focuses on the first read through of the lab and the custom notes, tables, etc. that you may develop as part of the read through

Part 3: Planning and Starting the Configuration walks through the planning and first hour or two of provisioning the lab solution

Part 4: Morning Configuration Strategy focuses on the configuration tasks that should be knocked out before lunch

Part 5: Bringing it Home focuses on the afternoon configuration tasks, how to adapt to issues, and how to validate your solution

Thanks for reading. If you have time, post a comment!


  1. Hi,

    This is a great series of posts. I hope you will be posting the next one soon.
    I'll be trying my lab the end of the month, every bit of help will be more than useful :D

    Would you be so kind to share your list of standard settings you change/check? I've seen some of these lists of other people, and find it really interesting to see what the others find important, and further complete my own list.

    Keep up the good work.

    Kind regards

  2. Great stuff William!!! Really helps. I'm 3 weeks out and still trying to work out all the kinks, inefficiencies and redundancies.

  3. Hi,

    Can you explain how you do the folllowing ?

    I use SQL from the CLI of the Publisher node to provision devices and DNs

    Thanks in advance

  4. Hey Amam,

    I have been asked that a couple of times so I will queue up an entry to try and explain the process I used.