[cisco-voip] What controls how quickly Unity does a MWI resync?

[Lelio Fulgenzi]

I would concur.

We have found the following boot order is necessary. Any system booted above requires a boot below. typically you want to wait for five to 10 minutes to ensure everything is running before continuing to the next server.

domain controller
partner server
message store 1
message store x
unity server

we just do it and don't ask questions. 
--------------------------------------------------------------------------------
Lelio Fulgenzi, B.A.
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
...there's no such thing as a bad timbit...

  ----- Original Message ----- 
  From: Matt Slaga (US) 
  To: Robert Kulagowski ; cisco-voip at puck.nether.net 
  Sent: Thursday, March 22, 2007 1:43 PM
  Subject: Re: [cisco-voip] What controls how quickly Unity does a MWI resync?


  It is a good idea to add to your checklist to reboot Unity every time
  it's partner exchange server is rebooted or services are restarted.  In
  my experience, the only real fix is to reboot Unity after hours and let
  them resync correctly.  Cisco has claimed this was fixed first in
  3.0(3), then 3.1(x), then 4.0(x), 4.1(x) and now apparently 4.2(x) but
  it has never really gone away.



  -----Original Message-----
  From: cisco-voip-bounces at puck.nether.net
  [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Robert
  Kulagowski
  Sent: Thursday, March 22, 2007 1:14 PM
  To: cisco-voip at puck.nether.net
  Subject: [cisco-voip] What controls how quickly Unity does a MWI resync?

  Unity 4.2(1), 72 ports, configured for UM, all ports are configured for 
  dialout MWI, port 72 is the only one configured as _only_ MWI.  MWI got 
  out of sync last night due to Exchange maintenance, so this morning we 
  hit the resync button.

  So far, it's been running an hour, and it's still about 20 minutes 
  behind "real time".

  What factors go into how long it takes Unity to perform a resync?  Is 
  there a list maintained by Unity that tells it which lights to turn on 
  and off, and it's just slowly making its way through the list?  If 
  there's a list, then how can I find out where in the list it currently
  is?

  Or is it hitting each mailbox, checking for new messages, and then 
  deciding which ones have new VM?

  In the past, it seems like Unity takes a long time and it only uses port

  72 rather than all ports.  Looking at port status monitor shows that the

  server isn't super-busy; the highest utilized port I've seen has been 
  port #8.  CPU utilization is low.

  However, if we watch long enough, we'll see MWI dialout at about one 
  every 5 seconds (for about an hour), and then all of a sudden Unity will

  use 70 ports all at the same time, "catch up", and then it's done.

  Why isn't is using all 50-60 ports right from the beginning?


  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip
  -----------------------------------------
  Disclaimer:

  This e-mail communication and any attachments may contain
  confidential and privileged information and is for use by the
  designated addressee(s) named above only.  If you are not the
  intended addressee, you are hereby notified that you have received
  this communication in error and that any use or reproduction of
  this email or its contents is strictly prohibited and may be
  unlawful.  If you have received this communication in error, please
  notify us immediately by replying to this message and deleting it
  from your computer. Thank you.

  _______________________________________________
  cisco-voip mailing list
  cisco-voip at puck.nether.net
  https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20070322/f8eae206/attachment.html