Forum Discussion

Josh_41258's avatar
Josh_41258
Icon for Nimbostratus rankNimbostratus
Mar 13, 2013

Testing Exchange 2010 iApp

I currently have Exchange 2010 deployed on 10.x using an older iApp in two datacenters. In my primary datacenter, I want to migrate load balancing to a new v11 platform using the newest iApp.

 

I see two options for deploying and testing the iApp on the new v11 platform:

 

1) Pre-create the virtual addresses on the v11 boxes and disable ARP. Then, I can run the iApp and use the production VIP's that are already in use on the v10 platform without causing traffic interruptions or ARP conflicts. When I'm ready to cutover to the v11 platform, I can disable ARP for the virtual-addresses on the v10 box, and enable ARP on the v11 boxes. However, I won't really be able to test the new v11 iApp deployment using this method.

 

2) Use the new iApp template on the v11 boxes using NEW VIP's. This will allow me to test the deployment to some extent. Once testing is completed, I can disable the VIPs on the v10 platform, and CHANGE the IP's of the VIP's on the v11 platform to match the production/v10 IPs. Do you think it would be as simple as this (just re-iping the virtual servers?).

 

Any thoughts or suggestions on either of these options?

 

Thanks

 

8 Replies

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Hi Josh, I would recommend option 2. With v11, you can simple re-configure the iApp template using the production IP address for your virtual server (after taking down your v10 box). That ability to re-enter iApps is the big advantage over the v10 application wizards.

     

    Mike
  • Mike,

     

     

    Ah, thanks! So, I should actually use the iApp reconfigure option to change the IP's, and not modify the bigip.conf or virtual server IP's directly.

     

     

    Thanks,

     

     

    Josh
  • Hm, looks like there is a problem with the iApp accepting passwords for mailbox accounts (for advanced monitoring) that contain special characters:

    script did not successfully complete: (can't read "123456": no such variable
    while executing
    "do_tmsh_modify "/ ltm monitor http" "FC-EX2010-DC1_f5monitor1_owa_http_monitor username na\\\\f5monitor1 password F\\$123456""
    invoked from within
    "tmsh::run_proc f5.app_utils:do_tmsh_modify "\"$component\"" "\"$arguments\"""
    (procedure "tmsh_modify" line 6)
    invoked from within
    "tmsh_modify "/ ltm monitor http" "$monitor_name username $full_username password $password" "
    (procedure "create_http_monitors" line 117)
    invoked from within
    "create_http_monitors $::OWA_NAME_EXTENSION"
    (procedure "create_ltm_monitors_and_pools" line 50)
    invoked from within
    "create_ltm_monitors_and_pools"
    (procedure "configure_ltm_exchange_deployment" line 24)
    invoked from within
    "configure_ltm_exchange_deployment"
    (procedure "configure_exchange_deployment" line 17)
    invoked from within
    "configure_exchange_deployment"
    invoked from within
    "if { $provisioned == $::PROVISIONED_ANSWER } {
    configure_exchange_deployment
    } else {
    puts "The app template failed because LTM is required."
    ..." line:3075) 

    In this example, "F$123456" is the password.
  • Changed the password to get rid of the special character and it fixed that problem, although now I'm getting:

    
    01070333:3: Virtual Server /Common/FC-EX2010-DC1.app/FC-EX2010-DC1_as_http illegally shares both address and vlan with Virtual Server /Common/FC-EX2010-DC1.app/FC-EX2010-DC1_ad_http. 

    This particular deployment uses the same VIP for all HTTP related services, but it uses another IP address for RPC/MAPI connections. Because of this, I had to choose to deploy "Different IP Addresses for different services." I specified the same VIP for all HTTP related (AS,OA,AS) services, and another VIP for the RPC/MAPI virtual server.

    Is this maybe causing a problem?

    Thanks,

    Josh
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    For the MAPI/RPC virtuals, I would actually create a new instance of the iApp just for your MAPI connections. That way you can use a single IP for all HTTP services, and a different IP for your MAPI/RPC.
  • Using the most recent that I see - 2012_06_08.

     

     

    I'll try creating a separate instance.

     

     

    Thanks!