Worrying Issues With CCA and OM

[David Trad]

Hi Cisco Team,

Would like to bring to the attention of the Cisco Dev's the following issues that are somewhat disturbing and worrying, they have been noticed in particular of the last two larger deployments using UC-560 systems, they are continual and require some further investigating.

Some of these issues may seem like nothing, but I do believe they have a larger implication to the system functioning correctly. Please be aware this will be quite long as it has been an ongoing investigation for a little over 2 months now, SBCS has not been involved as of yet with all the issues only on the most pressing ones (Complicated story as to why).

System Outline:

• Cisco UC-560
• Fractional PRI
• Latest Software Pack
• Incoming Calls go to a receptionist Blast Group (3X Reception Phones)
• 1X SPA-525G2 with 2X SPA-500s Modules & 2X SPA-508G's for Reception Phones
• 4X Park Slots on the system used to hold and manage incoming calls (Due to the SPA phones not support Octo-Line)
• 50X Desk Phones 49 of them SPA-508G's
• 1X Cisco ESW-520-24P & 1X Cisco ESW-502-48P (Updated to the latest SW)
• 100 In-Dial Range, some direct to extensions (Managed and created by CCA) and others to a blast group

First Issue:

• Management of users using CCA & Configurations just disappearing -
  When using CCA to manage the users, a phones/users configuration may be deleted, further to that other phones/users configuration may be deleted when you never even made a change to that phone/user, for instance when making a change to the button layout of 45 of the phones (Which takes a loooooooooong time) 9 of the phones had random configuration removed such as the phone type, button configuration, and a mumble jumbled MAC Address, somehow or another CCA managed to change all that, the only way to reinstate the information correct without put the system in a state of non-use was to do it via CLI, then CCA would recognize the phones again.
  
  The issue is random, but the pattern is distinct, it happens predominantly when making bulk changes, once you reach over 10 users the issue starts to surface and the phones that get effected are random, there is no distinct correlation between the settings update and the effected phones, even the dialogue box that appears and shows what commands where made comes up with just two lines, the DN that was modified and and exit, no other commands issued.
  
  
• Configuration update and loss of information -
  When making basic updates to the configuration such as adding a park slot, or updating a Blast group, or even changing a users details, the system would randomly drop configuration changes that were previously saved, or the update would not complete even tho the dialogue box said it completed successfully and shows you what commands where sent to the system. None of this is explainable, I really cannot narrow down on the problem, other than when working intensely in CCA and for long periods of time, in Task Manager CCA can reach up to 680MB of RAM usage, and it starts to slow down... I'm thinking there is a memory leak in the Java code, this only happens when you are in CCA for long periods of time, say over two hours (Which is not uncommon with larger deployments BTW).
  
  

Second Issue:

• Phones Not Behaving as they should -
  Recently it has been noted that phones are randomly placing their own call forwards and sometimes to an unknown number, typically if it is user error you will see a recognized number, either an extension of a user or a park slot, but in 80% of the cases it was to a random number and usually 8-12 characters in length, its quite mind blowing actually when you see it, kind of makes you laugh when you are investigating it and the client is not looking over your shoulder. There is no way in CCA to remove this call forward, and the phone itself does not show that there is a perm call forward in place, it just thinks that its business as usual, you although OM at times can see it but normally CLI is required to remove it (This was tops the insane chart).
  
  
• Park Slots not functioning as they should -
  The users are taught two ways to place a call on park, that is using the transfer soft-key method and or just pressing the park slot. This works as intended, it is what happens next that is not ordinary, basically at random times no user is able to resume that park slot, the caller just hears an MOH music that sounds like a broken record, constantly looping on itself for about 4-6 seconds and then resuming the MOH from the start again, and then shortly after an engaged signal... However this behavior is random and hard to predict, but a reload of the UC-560 seems to remove this issue for about half the day and then it starts to slowly surface again, with a reasonable progression in miss rates.
  
  Sometimes this problem is not propagated to the other park slots (all sites have been tested for this theory) but after general use that park slot tends to become infected with this aggressive problem. Again I must point out that this is randomness at its best and finest form, because a good portion of the time the issue does not ocurr, it took two hours of watching the receptionist and other users in action to see it come into play, and then from nowhere for it to stop happening, and I know the users where doing the right thing because I was watching them during the process.
  
  

Third Issue:

• Office Manager having its own set of issues -
  I have been training the receptionist and office administrators on the usage of OM, however some bigger challengers are being thrown at us and there is no way to address them, for starters it can take up too 15 minutes for OM to load up and read the configuration (Mainly sticks at the CUE part), after 15 minutes it times out, but if you try again immediately it may do it in 2-3 minutes. When applying changes it will take up to 10 minutes to apply the change or just time out with an error, but if you check the configuration on the CLI it partially applied it (WTH????), if you move on and click the discard button to saving the changes, the partial configuration remains on the system, but the next update can happen in under 2 minutes... And I must point out that these are simple changes such as forwarding calls, password changes and name updates, trivial tasks that should be done with ease.
  
  OM Also at times displays a phone as not in service, but when you walk to that phone and use it, it is in service, it is registered and can make/receive calls etc..etc.. This gives the receptionist/administrators grief as they think something is wrong so they are constantly checking these phones... This needs some looking into, and I point out not at one single site and predominantly only with the larger deployments (15>)
  
  

Fourth Issue:

• UC-560 showing unusual behavior issues (May relate to CCA not to sure) -
  If I program the system with Blast Groups or direct calling, then the client changes their mind and asks for some Park Slots, I program them into the system using CCA (As one should), This all looks good and sweet, until you try to use them and configure them to a button on the phone, either the phones do not take the configuration, or the Park Slot does not work until you reload the system (MUST write mem before you do so). CCA Says it reset the phone, it appears it has as the screen refreshes and the buttons show up, but still you cannot use the function until the system is reloaded, this also happens with speed dials (Never once have I seen this).
  
  Again I must point out that it seems to be on larger deployments, in the LAB setup we have 6 phones and I cannot replicate this one particular issue, and outs is a UC-560 so I am not sure if I can put this down to a UC-560 Issue at this stage (Although these problems appear to be happening on them)
  
  
• Phones Randomly Locking up and becoming unresponsive -
  This one is a really odd issue and again no explanation can be found for it, basically the phone looks alive, the click still keeps ticking, it is showing up as registered on the CME, but it will not ring (Just goes straight to busy tone even if VM is enabled) and you cannot make a call, sometimes unplugging it waiting 5 seconds and then plugging it back in brings it back to life, but I have had to at times reload the whole system to get it to work again, this seems to happen so far on the SPA-508's and SPA-509 phones, have not sold much of the others to see it happen with them yet, and this is completly random and never the same phone in the same day (Yes that part is unexplainable to me) and on more than one system (again on UC-560 systems).
  
  

Fith Issue:

• SPA Phones having bad audio quality -
  Now on more than one deployment (3 now and counting) the clients are complaining that side (B) is unable to hear them properly, at first this was mainly coming from those who were using analogue (FXO) lines, but now this is migrating to PRI based services, not as much admittedly, but still happening none-the-less, this is a bad sign and is going to come crashing down like a house of cards, we sell the Cisco SPA phones with our hearts on our hands as them being high quality, but yet in all actions including replacing 15 of them at one site, the problem will not abate There is something fundamentally flawed with this phones and are reminiscent of the SPA-942 phones when I sold them with Asterisk systems, we had to plain with all sorts of gain settings to get something decent audio out of them, in the end I just went back to SNOM or AATRA phones, I cannot do that this time and cannot even work out a solution of upgrading the phones to 7900 series (Again out of our hands as the systems are sold under our National Carrier), one simple question with a BS answer "ARE THESE PHONES UP TO THE TASK AND ARE OF HIGH QUALITY???" I just want honesty and a straight answer on this, because the concern now is getting very very very deep and being a fan boy of Cisco for so long it is really knocking my confidence about a fair bit selling this... what ever it is!!!!
  
  

There are a host of other issue including that of CDR records, SCC, simple system management, but right now I am emotionally and mentally drained, plus my hands are getting really sore from typing non-stop since I come into work putting out fires, I cannot remember ever being so exhausted working with Cisco System, yeah sure they gave you problems but they were easily fixed with a simple call to TAC, Now when I call SBCS I get people on the phone either cannot speak fluent English or understand me, ask me to do stupid things which are of no relevance to the issue at hand, or cannot merry up the support contract on a device to the UC system because of what ever arrangement is in place between our national carrier and Cisco, the headache is so huge what ever margins are made on selling the things is gobbled up just in managing the clients issues and trying to work through the lack of SBCS support (Not taking shots at the guys because they are only doing their jobs, simple, and I have no animosity towards them what-so-ever).

I could understand and appreciate if this issue was happening on a single system, but when the issues start to surface on more then one system, and many hours are spend looking at if the problem falls squarely with what I am doing, I am left with limited options, I have even tried to side-step SBCS all together by trying to wean some basic support from Dave Harper when I clearly know I shouldn't because desperation sets in to just clear this problem out, which again yields its own problems, because I am now making someone else accountable for the issue when it clearly is not in their domain

HELP!!!

Please take this rant with all seriousness, I am not asking for an army of support but just someone who is in the know to look at the problems, on all fronts I.E CCA/OM/UC-500 as each one will require their own set of expertise. I have worked on UC's and Deployed enough of them in the last 3 years to have hit every issue, but the most recent ones just linger around like a bad smell.

Cheers,

David.

[David Trad]

Geee I hope my post didn't scare the Cisco Team off

The silence is defining

Regardless I am trying to work out a way to get Support involved, although it is not simple to do as replicating the problem would be extremely disruptive to both sites as the phones are constantly ringing off-hook (Yes this problem had to happen in busy sites).

But if the Cisco Team or even the community has any suggestions, it would be great to get some feed-back.

Cheers,

David.

[danplacek]

This isn't really a helpful answer, but I thought I'd add our experiences.

We have seen similar problems with both CCA and Office Manager, I have very little confidence in either of them. We try to avoid giving customers either of them if at all possible - not because we wouldn't want them to be able to make changes -- but out of fear of what might break.

One of the biggest problems I have is that so many of these issues are difficult to reproduce, and Cisco seems to be of the opinion that if it isn't easily reproducible -- it doesn't exist. STAC's only course of action for things that are *clearly* bugs seems to be to blindly change firmware versions until it works -or- just stop responding and close the case.

We've had a great deal more issues than the ones you've listed here even (phones rebooting randomly, un-deletable voicemail messages, paging not going to some phones, phones freezing, screeching noises on incoming calls). Cisco seems to be unable to help with anything thats clearly in the "bug" category and not a configuration problem.

A side note here -- its been my experience that any configuration thats even semi-complex -- there is CLI changes required. Which inevitably makes things with cca and om even worse. Cisco's inability to make management software that is compatible with their own configuration "language" is insane to me.

I could go on about this at length like you have above, but I doubt anything will come of this thread anyway. Its both comforting and depressing that I am not alone with these problems...

[Joe Gadell]

David,

We have done many installations of the UC-series and recently made the decision to move onto 2900 series ISRs with 79xx series phones.  So far, it's been wonderful.  I think it's even costing our customers less money and definitely causing less headaches. You get to stick with TAC and Cisco Configuration Professional appears much more stable than CCA if you prefer a GUI.

The other advantage is you can use the latest IOS/CME/CUE & practically every non-SPA phone.  The 6900 series has many affordable phones that take the place of that stuff anyway.

It sounds like with the experience you have moving to ISR should not be an issue. 

Good luck.

[Thomas Gruendler]

I am right there with you David.  My biggest issue is this:

Phones Randomly Locking up and becoming unresponsive

This only happens to any of the SPA phones that I install.  Any phones from the 79xx line have no issues what so ever.  I am to the point that I am about to not sell the UC5xx line and stick with ISR's and 79xx phones. 

Also with support.  When I had issues with my first install (UC520 w/ 5 phones), I called TAC and was able to get my issues resolved asap as I always got an engineer on the line.  Now it seems that when I call Small Business Support, I get a call center rep reading from a script that has no idea what the issue is and it takes weeks to resolve anything.

[David Trad]

Hi Danial,

We have seen similar problems with both CCA and Office Manager, I have  very little confidence in either of them. We try to avoid giving  customers either of them if at all possible - not because we wouldn't  want them to be able to make changes -- but out of fear of what might  break.

I fully understand your sentiment here, although I find myself in a different thought process. If I do not consider giving them some form of management, basic at that even, I will find myself doing so much Gratis work that again your margins (Bottom Line) starts to get hit, not a good thing for the boss to see

We've had a great deal more issues than the ones you've listed here even  (phones rebooting randomly, un-deletable voicemail messages, paging not  going to some phones, phones freezing, screeching noises on incoming  calls). Cisco seems to be unable to help with anything thats clearly in  the "bug" category and not a configuration problem.

Oh never even scraped the sides of the issues that are being faced, I dont even think the forum would allow such a long post

Never have I seen Cisco in a Rutt like this, and every single angle I look at this with, it all seems to stem from the the 3 main issues... SPA-500 Series phones, Incompatibilities between published applications (CCA/OM/SCC), and what appears to be but may not in fact be, Lack of QA on the CUE more so than the CME prior to release, CME/CUE version 7.1 seemed to be the start of this spiral effect.

However in saying that, the admiration and respect is given for Cisco's ability to quickly turn out updates to resolve it, but it still begs the question, why a reactive approach and not a pro-active one??

Hi Thomas,

I am to the point that I am about to not sell the UC5xx line and stick with ISR's and 79xx phones.  

There is actually very little differences between the UC-500 series and say the 2800 ISR or 2900 series ISR's, fundamentally the CME's are practically the same excluding any UC-500 series specific functionality, and I guess greater capacity to do things like VPN and larger Dial-Plans and more users, the rest are quite close.

I am of the opinion that the UC-500's are brilliant and if not the best at least close to being the market leaders in SOHO/SME systems, but their flaws are frustrating, and I can only put this down to potentially a new breed of programmers/developers, that maybe do not hold the old candle of the way to do things... I am certain CCA has a memory leak in its Java code.

Also with support.  When I had issues with my first install (UC520 w/ 5  phones), I called TAC and was able to get my issues resolved asap as I  always got an engineer on the line.  Now it seems that when I call Small  Business Support, I get a call center rep reading from a script that  has no idea what the issue is and it takes weeks to resolve anything.

The most hardest issue for me to talk about, and I guess because at times I have a bad habit of polarizing people indirectly and non-intentionally. In the dealings I have had with SBCS support, 80% of them have been a pleasant experience, but the same could be said with TAC as well, NOT always did I have a wonderful experience with TAC either, ocasionally getting a CCIE certified person who actually had very little clue about voice fundamentals, but were very proficient with data, they were very destructive and the ending of the conversation seemed more productive than continuing it with them.

I guess my concerns are that these forums seem to have lost the old school boys who were so damn proactive and worked endlessly to resolve issues, with the advent of CCA becoming the predominant method of programming the systems, these old school people have deserted the forums, and now Steve hovering in the shadows and not formally a Cisco Employee, we are down to 2 maybe 3 tops old school who know the community intimately and understand what we go through in the cold face of the customer.. Harsh yes I know but sadly I believe it to be true... The old school boys know who they are so no need to name them.

My fears every day seem to be coming to past, and now with the culling of 6500 emplyees, I fear they will remove those with the most experience but yet MOSTLY under valued and not appreciated for their comitment to the company and the partners/customers alike... I truly hope this does not happen, it will be a devastating blow to ones confidence in Cisco performing as they have in the past.

Cheers,

David.

[Anna Tsukerman]

Hi David,

First of all, thank you for taking time to let us know about the issues you have came across in the last couple of months. We really appreciate your candor, and hope to work together with you to get to the bottom of this.

I will try to address some of the points related to CCA/OM, and I have reached out to my UC500/SPA colleagues and asked them to chime in regarding the other concerns you outlined below.

 First Issue:
Management of users using CCA & Configurations just disappearing -
When using CCA to manage the users, a phones/users configuration may be deleted, further to that other phones/users configuration may be deleted when you never even made a change to that phone/user, for instance when making a change to the button layout of 45 of the phones (Which takes a loooooooooong time) 9 of the phones had random configuration removed such as the phone type, button configuration, and a mumble jumbled MAC Address, somehow or another CCA managed to change all that, the only way to reinstate the information correct without put the system in a state of non-use was to do it via CLI, then CCA would recognize the phones again.

The issue is random, but the pattern is distinct, it happens predominantly when making bulk changes, once you reach over 10 users the issue starts to surface and the phones that get effected are random, there is no distinct correlation between the settings update and the effected phones, even the dialogue box that appears and shows what commands where made comes up with just two lines, the DN that was modified and and exit, no other commands issued.

Configuration update and loss of information -
When making basic updates to the configuration such as adding a park slot, or updating a Blast group, or even changing a users details, the system would randomly drop configuration changes that were previously saved, or the update would not complete even tho the dialogue box said it completed successfully and shows you what commands where sent to the system. None of this is explainable, I really cannot narrow down on the problem, other than when working intensely in CCA and for long periods of time, in Task Manager CCA can reach up to 680MB of RAM usage, and it starts to slow down... I'm thinking there is a memory leak in the Java code, this only happens when you are in CCA for long periods of time, say over two hours (Which is not uncommon with larger deployments BTW).

Did you happen to save a CCA application log for this issue? Especially because this issue is random, it would be good to take a look at the logs and see what may be happening with the system. The best approach, in cases like these, would be to collect the logs as soon as the issue appears for the first time (or resurfaces). Even if you don't call SBSC and open a case right away, at least you have some hard evidence of what was happening, and you can refer to it later.

In many cases, SBSC team can pin point the issue or escalate to CCA engineering team if the logs are collected.

Third Issue:
Office Manager having its own set of issues - 
I have been training the receptionist and office administrators on the usage of OM, however some bigger challengers are being thrown at us and there is no way to address them, for starters it can take up too 15 minutes for OM to load up and read the configuration (Mainly sticks at the CUE part), after 15 minutes it times out, but if you try again immediately it may do it in 2-3 minutes. When applying changes it will take up to 10 minutes to apply the change or just time out with an error, but if you check the configuration on the CLI it partially applied it (WTH????), if you move on and click the discard button to saving the changes, the partial configuration remains on the system, but the next update can happen in under 2 minutes... And I must point out that these are simple changes such as forwarding calls, password changes and name updates, trivial tasks that should be done with ease.

OM Also at times displays a phone as not in service, but when you walk to that phone and use it, it is in service, it is registered and can make/receive calls etc..etc.. This gives the receptionist/administrators grief as they think something is wrong so they are constantly checking these phones... This needs some looking into, and I point out not at one single site and predominantly only with the larger deployments (15>)

The slowness of OM, as you pointed out, has to do with the fact that OM has to access every user voicemail box on the system (CUE) one at a time, and then load that configuration. This performance issue should be addressed on the CUE side, as it is also the reason why CCA is sometimes slow (taking 30-45 secs to load Users and Phones window is one of the examples).

Early next week, we are releasing maintenance release for Office Manager, and I believe it should address the time-out issue that you mentioned. I would like to get your feedback on this OM release and find out if it addresses the time-out issue for your customers or not.

OM reporting a phone being down when in fact it is up and running is something I haven't heard before. Let me talk to the OM engineering team if they have any ideas as to what might be happening, and I'll get back to you on it early next week.

Sincerely,

Anna

[David Trad]

Hi Anna,

I will see if CCA has saved any logs, not sure if it does this automatically and date/time stamps it, but if there are logs there I will scroll through it and start picking it apart.

What ever I can do to help you guys out with narrowing down on these issues I will, I don't care if I have to spend personal time on it, if it means making CCA better you have my attention

Will post up the logs if they are there and produce the results needed to help out...

Cheers,

David.

[Anna Tsukerman]

Hi David,

Just wanted to check back with you if you were able to find any relevant CCA logs to help us understand the issues you ran into recently?

You can send the logs directly to me: atsukerm@cisco.com

Thanks,

Anna

[David Trad]

Hi Anna,

I searched for the logs and I cannot seem to find them, and I think I know what the problem is

I upgraded CCA 3.0.1 to 3.1 and didn't make a copy of the logs in the directory, everything seems to have been re-arranged and there is only 1 log file present now, so it would seem the upgrade procedure removes files from within the directory when you do an upgrade.

I am going out to see the client today, If I have to do any work there today and problem arise I will make sure i pass on the logs, although I am not operating on 3.1 no longer 3.0.1

Cheers,

David.

[Anna Tsukerman]

Hi David,

Thank you. Please let me know if you come across the same issues again (now with CCA 3.1).

Also, new OM 2.0 release is out. If you get a chance to give it a try, please let me know if it addresses the timeout issue you experienced before.

Thank you,

Anna

[David Trad]

Hi Anna,

I was just out at the customers site again today and upgraded their OM to version 2.0, it is much worse than the last one

This time it refuses to acknowledge the manual input of the UC's IP address, instead it takes about 80 minutes for it to finish scanning the network to find the UC.

OM then does odd behaviors once you finally manage to get in, for instance under groups (Blast Groups) when you try to remove a user from the group, it just drags over all the users that were previously removed, it then renames them on the fly to "A Column" Ext Number and "B Column" External Number.... I have no idea why, or what this means.

So we made some password changes to the second reception phone just incase it cause a problem (Vacant at the time) and in OM that phones information on the screen just turned to gibberish.. HUH??? I would have laughed although the receptionist is a hard lady and I am sure she would have back handed me so i maintained a stern composure look on my face and then a puzzled one.

I am at a loss, downgrading back to 1.2 was not an option it errored out when trying to reinstall it, to do it I would have to use CCLEANER and remove all existance of OM of the system... I am not in between a rock and a hard place, between this issue and her SPA-525G2 causing instability on the system and constantly rebooting, Cisco is no longer looking like the quality system it was promoted as... I am somewhat deflated at the moment

Anyway will soldier on and tackle each problem one-by-one, I made the mistake of installing OM on a clients system without first testing the latest version on my own back in the office, desperation causes desperate moves which leads to more problems.

Cheers,

David.

[Anna Tsukerman]

Hi David,

One of the engineers on our team has looked at your OM comments in regards to the OM 2.0 and the "Third Issue:" from the very first post on this thread.

Regarding OM 2.0 issues you've run into, this is the first time that both he and I hear about this. None of this has beed observed in the testing environment... As to the "Third Issue:" , there may be a solution for this, but we don't want to me guessing.

What is really needed to diagnose the problem is real OM logs with debug turned on, without the logs we can only guess and speculate as to what the problem is. Can you please email me these logs?
 
Here are the steps to create the debug log file we need (they are also listed in the OM Installation guide as well as the OM help under the section “Setting Debug Options and Creating Log Files for Troubleshooting”).

I have listed the instruction below.
 
Setting Debug Options and Creating Log Files for Troubleshooting

Follow the steps in this section to clear Office Manager logs, set trace levels for debugging, and collect log files that can be submitted to Cisco Small Business Support for troubleshooting. Office Manager usually runs at the normal trace level, which only allows errors to be placed in the log files. These log files are stored in the Office Manager installation directory. Log files
begin with “Cisco-OM-Log-” and have a timestamp and a .txt extension (for example, Cisco-OM-Log-2010-08-19-15-54-41.txt). Log files are kept for 7 days (older log files are deleted). The maximum size for a single log file is 1.99 GB. When the maximum log file size is reached, a new file is created.
 
To set debug trace options and gather more detailed log files, follow these steps.
 
STEP 1 Launch Office Manager and click the Advanced Settings link at the top of the page.
 
STEP 2 Locate the Cisco Support Options under the Miscellaneous section on the page.
 
STEP 3 Click Clear Logs.
 
STEP 4 Click Set Debug Trace to set the debug trace level so that additional information can be collected when the problem occurs.
 
STEP 5 Close Office Manager.
 
STEP 6 Restart Office Manager.
 
STEP 7 Re-create the problem.
 
STEP 8 After you are finished re-creating the problem, click Set Normal Trace to set the trace level back to Normal.
 
CAUTION It is very important that you set the trace level back to Normal. When
the trace level is set to Debug, the log files that are generated can grow rapidly
and consume a large amount of disk space.
 
STEP 9 Exit Office Manager.
 
STEP 10 On the PC running Office Manager, go to the Office Manager installation directory.
The default installation location is
 
C:\Program Files\Cisco Small Business Office Manager
(supported 32-bit Windows operating systems)
 
or
 
C\Program Files (x86)\Cisco Small Business Office Manager
(supported 64-bit Windows operating systems)
 
STEP 11 Collect all of the log file(s) that begin with “Cisco-OM-LOG”.
 
STEP 12 Create a .zip file that contains all of the log files and submit it as directed by Cisco Small Business Support.

Thank you,

Anna

[David Trad]

Hi Anna,

I'll gather all this for you, from how many machines do you want me to do this?? I have more than one client and even ourselves have hit this issue ... Actually all of them

I will start the logs as soon as I can do a remote desktop session with the receptionist, she gets cranky at me when I disturb her so I have to time it right.

Shall have you something soon though.

Cheers,

David.

[Anna Tsukerman]

Hi David,

As many logs as you can gather comfortably without disturbing receptionists too much .

Thanks,

Anna