Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Design Phase Details Page

Design Phase

This phase typically lasts a couple months and involves the customer working  with their partner, and possibly Cisco Advanced Services and/or UCBU  representatives.


GOAL: The focus here is to get down to nuts and bolts detail on the design.

T3.1 Create the Why Do Low Level Design -- a very detailed, thorough plan that  contains all the data necessary to build an Implement Phase Details Page.

          T3.1.1 Create the Cisco Unity system description -- the criteria necessary  to build each Cisco Unity server you install. Include the following information:  
          T3.1.1.1 Cisco Unity system configurations -- How each Cisco Unity server  should be configured including how you should set up your subscriber templates,  classes of service, distribution lists, naming conventions, extensions, other  subscriber data.
          T3.1.1.2 Cisco Unity hardware configurations -- The physical layout of the  hardware including how you plan to organize files and applications on the hard  drives of each server.
          T3.1.1.3 Cisco Unity networking configurations -- For each Cisco Unity  server, detail the dialing plan that you use with Cisco Unity. Show how  subscribers on each Cisco Unity server can be addressed by subscribers on other  Cisco Unity servers or legacy voicemal systems. Show a digital networking table  depicting how it will be set up for each Cisco Unity server.
          T3.1.1.4 Physical network connectivity -- Show exactly how each Cisco Unity  server connects to the network and communicates with each and every server that  it services or depends upon. Show the IP addresses and server/DNS names of each  server that Cisco Unity communicates with. Show switch port settings such as  speed/duplex, VLAN, etc.
     T3.1.2 Identify the Cisco Unity switch integration detail -- explain exactly  how Cisco Unity will integrate with each switch that each Cisco Unity server  services. This includes the voice ports and the switch-integration  configuration. 
          T3.1.2.1 If you are using Dialogic gateways to integrate with a legacy PBX,  document their IP addresses, switch port settings, physical location and  connection to the PBX. Document PBX settings such as LTN assignments, hardware  assignments, serial port settings, extension numbers, hunt group pilot numbers.
          T3.1.2.2 If Cisco Unity is integrated with CallManager, show the network  connection. Does it use the same VLAN or a different VLAN? Show the actual IP  addresses on the cards
          T3.1.3 Identify the Cisco Unity messaging infrastructure detail -- Include  the following:
          T3.1.3.1 Cisco Unity domain usage -- Indicate for each Cisco Unity server  the domain names and domain controllers that Cisco Unity will use, and the  Global Catalog server that Cisco Unity will use. 
          T3. Remember that Cisco Unity for Exchange must be installed into the  same Windows site as the Exchange servers that it services and must use the same  domain controller and Global Catalog server as these Exchange servers. List the  directory OUs where all  mail-enabled users are located in Active Directory for  the same Exchange servers that Cisco Unity services.
          T3. If your Cisco Unity design involves Domino only, you must  indicate which Windows domain Cisco Unity is installed into. Remember that Cisco  Unity uses the Windows domain and that Domino might not; also note that Cisco  Unity's interaction with Domino primarily depends on DUC and the Domino domain  and not the Windows domain, even though a Windows domain is required for Cisco  Unity only. If you dedicate a Windows domain for your Cisco Unity installations,  note that in your design. Also note how each Cisco Unity server accesses and  uses the domain controller for the Windows domain where it is installed.
          T3.1.3.2 Cisco Unity directory usage - Your directory capacity-planning  exercise should have helped you determine the impact that legacy voice-messaging  objects created in Active Directory have on your directory. Indicate location  and where these objects will be created. Include particulars about the detail  and activities involved in performing the schema extension, in the case of  Active Directory, or in installing DUCS, in the case of Domino.
          T3.1.3.3 Name resolution -- For each Cisco Unity server, indicate which  name-resolution hosts will service Cisco Unity.
          T3.1.3.4 Messaging system - For each Cisco Unity server, indicate which  server will be its partner server and which servers Cisco Unity will service.
          T3.1.3.5 Service accounts and administrative access -- Indicate how each  Cisco Unity server will be accessed and how the service accounts will be used,  as well as their names, their level of permissions, who will manage them, and  what is necessary for management (such as password policies, permissions checks  and verification, auditing, and so on). 
          T3. For each Cisco Unity server, note the service accounts that will  be used or created for Cisco Unity.
          T3. You also must consider how the servers will be accessed  administratively. Is OS-level access treated differently than the Cisco Unity  application level?
          T3. If you plan to use an existing administrative policy or procedure  within your organization, indicate that and note how it will be applied to Cisco  Unity.
          T3. When you indicate the accounts that you will use, you might want  to address both the installation of and operations of Cisco Unity, which can be  considered two different activities.
          T3.1.3.6 End-user access -- For each Cisco Unity server, indicate which  levels of access are to be allowed for your end users. Will it be TUI only? Are  only some end-users allowed to access the GUI web? What about directly accessing  the server? Are any end-users allowed or required to access the Cisco Unity  server directly?
          T3.1.3.7 Security considerations -- Make sure that you not only include  security considerations in your design, but that you also use the lab trials and  production pilot to ensure that Cisco Unity is capable of supporting whatever  you indicate in your design,
          T3.1.4 Indicate Cisco Unity administration and management design specifics.  Address how Cisco Unity should be administered and indicate any design issues  associated with your administrative plan. If bandwidth is an issue for remotely  accessing the Cisco Unity System Administrator, or if you need to run remote  administrative clients to access the server, indicate that in this section. 
          T3.1.4.1 Consider administrative access -- which accounts or which users  need to access each Cisco Unity server and how. 
          T3. Your administrative plan should include how mail-enabled users  are imported into Cisco Unity and also how those users are managed after they  are imported.
          T3. As a part of your design topology, indicate your administrative  model and how it will support normal Cisco Unity administration, including  subscriber management (subscribers, distribution lists, and so on), audio-text  applications, and the Cisco Unity server system configuration, especially its  connectivity to a legacy switch, Cisco Unified Communications Manager, or both.
          T3. What tools do you use? Indicate this and set up a policy for how,  when, and where these tools are used.
          T3.1.4.2 Document Cisco Unity system management -- monitoring the server's  resources and performance, as well as also proactively monitoring the server's  ongoing, daily activity. This means that you will monitor Cisco Unity at  different levels: the OS (event logs, SNMP service, Performance Monitor), Cisco  Unity itself (traces, port status, Cisco Unity-specific performance activity,  logs, and so on), application event viewer logs (possibly using the  event-monitoring service), and other components, such as security, antivirus,  and other management tools.
          T3.1.4.3 Indicate the subscriber account-naming conventions, and make sure  that your design uses the same naming conventions as your existing user accounts  database.
          T3.1.4.4 Indicate support considerations. Whom do subscribers call for  problems? Whom do your tech support engineers contact for operational issues  during each phase of the migration? How does moving from legacy voice messaging  to unified messaging affect how subscribers are supported?
          T3.1.5 Create and perform any customer certification testing (if required).
          T3.1.6 Conduct a detailed Design Phase Details Page
          T3.1.6.1 Prepare for the Why Do Low Level Design presentation. Customize a letter  of understanding with design specifics and customer remediation  responsibilities.
          T3.1.6.2 Present the Why Do Low Level Design
          T3. Present Letter of Understanding.
          T3. Obtain Signed Letter of Understanding.


     GOAL: Refine and finalize training materials and subscriber communications plans.

S3.1 Continue working on your subscriber preparation.

          S3.1.1 Determine the scope of the migration from a legacy voicemail system  to Cisco Unity. 
          S3.1.1.1 What data will need to migrate from the legacy voicemail system to  Cisco Unity?
          S3.1.1.2 Who will perform the research on the legacy voicemail system and  mine the data?
          S3.1.1.3 What access to systems or documentation will they require?
          S3.1.1.4 How will you handle their requests for additional information?
          S3.1.2 Continue to document the existing legacy voicemail configuration. 
          S3.1.2.1 What menu services are currently in use?
          S3.1.2.2 What announcement services are being used? How will the new  messages get recorded?
          S3.1.2.3 How many system distribution lists are being used?
          S3.1.2.4 What zero-out targets are used?
          S3.1.2.5 How will the migration impact voicemail networking?
          S3.1.2.6 Are there any special departments or groups that have unique  configurations in the existing legacy voicemail system?
          S3.1.3 Begin to develop your migration support plan. 
          S3.1.3.1 How soon before the Day 1 Cutover will subscribers be able to access the  new voicemail system and record new personal greetings?
          S3.1.3.2 How long after the Day 1 Cutover will subscribers be able to access old  messages on the old voicemail system?
          S3.1.3.3 What impact will the Day 1 Cutover have on the existing voicemail pilot  numbers and remote access?
          S3.1.4 Start thinking about your subscriber support strategy. 
          S3.1.4.1 Who will staff the help desk? How long will it be available to  end-users? Will you have live bodies, a group mailbox or both? What turnaround  time do you plan to commit to for new requests/problems?
          S3.1.4.2 What printed documentation will you distribute?
          S3.1.4.3 What web-based resources will you utilize?
          S3.1.4.4 Think about having dedicated contact points per department.
          S3.1.4.5 How will you communicate status to the end-user community?
          S3.1.5 Continue work on your subscriber training plan. 
          S3.1.5.1 Who will need be trained?
          S3.1.5.2 Who will be your trainers?
          S3.1.5.3 What training documentation will be required?

          S3.2 Develop the Why Do Staff Training Plan.

          S3.2.1 Job Role Training Requirements 
          S3.2.1.1 Determine job role tasks and responsibilities.
          S3.2.1.2 Determine knowledge and skill requirements.
          S3.2.2 Develop curriculum maps. 
          S3.2.2.1 Determine training requirements.
          S3.2.2.2 Determine who will conduct training.
          S3.2.2.3 Determine who will be trained.
Version history
Revision #:
1 of 1
Last update:
‎07-02-2009 05:15 AM
Updated by: