No Movi User CDR Reports in TMS

Unanswered Question
Jul 18th, 2011

TMS 12.6

VCS X5.1.1

Movi 4.1

We have had an open ticket with Cisco TAC for months with no real good direction except what feels like a generic guidance to upgrade TMS. Within TMS, under the Reporting -> Call Detail Record -> User CRD reports, it is my understanding that there should be a drop-down for Movi users under the device type field before running the report. My drop-down only shows all and does not include any information about Movi users when running the report with device type set to all.

Any ideas or suggestions?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4 (2 ratings)
Elter Picolo Mon, 07/18/2011 - 23:36

In Reporting > Call detail record > User CDR at TMS 12.6.2 and 13.0.1 have Provisioning statistics, that include Movi users.

From TMS Help:

The User CDR page displays an overview of user activity.  User activity statistics are collected from the Cisco VCS.

The information can be filtered by

  • Date and time
  • Device Type (For example Cisco E20, Movi)
  • Duration (Duration of calls for each user, measured in minutes.)
  • Number of Occurrences (Number of calls)
  • Utilization (Percentage of call time used by each user.)

A Call Detail Record (CDR) is the computer record produced by a telephone exchange containing details of a call that passed through it.

Regards

a.khurshid Tue, 07/19/2011 - 04:51

Elter,

Thanks for the response. So you're saying this was introduced as a new feature in 12.6.2? Is that something that was documented in the release notes? I don't remember seeing that...   

Elter Picolo Tue, 07/19/2011 - 04:59

Hi Andrew,

i´m not sure if this is a new feature. I just checked two different TMSs that i have quick access...

a.khurshid Tue, 07/19/2011 - 05:05

Do you have a TMS that is still on 12.6 that does not have the Movi CDR reports?

Elter Picolo Tue, 07/19/2011 - 05:13

I checked another one that is running 12.1 and also have the User CDR report.

Confirm that TMS Agent is turned on (Yes) on the VCS your checking.

bye

a.khurshid Tue, 07/19/2011 - 05:20

I suspected that may be the case.

TMS Agent is on, and all diagnostics are successful.

awfchan63 Tue, 09/06/2011 - 14:47

I now have that same issue where there are no reports of Movi users fromthe User CDR Reports within TMS

we used to have this working but after our upgrade from TMS v12.6 to 13.1 this functionality is now not working

Upgrade done on Aug 20th so can pull records of the User CDR prior to Aug 20th

TMS 13.1

VCS 5.1.1

Movi 3.1 to 4.2

Thanks

a.khurshid Tue, 09/06/2011 - 15:35

It's hard to pin down what the issue is. My vendor was thinking that it may have to do with the fact that we have multiple, unclustered, un-neighbored VCS's in our environment. At any rate, I did upgrade our test TMS environment to 13.1 and the test VCS to 6.1, and the Movi CDR reports show up there. It will be interesting to see what happens when we upgrade our production environment.

awfchan63 Sun, 09/18/2011 - 11:22

have upgrade our VCS Control and VCS Expressway to v6.1 just today

Tried to pull the USER CDR again after Aug 20th and nothing show up after our upgrade

TMS v13.1

VCS Control V6.1

VCS Expressway V6.1

Movi Users V3.1 to 4.2

do i need to wait until replication finishes?

Thanks

awfchan63 Tue, 09/20/2011 - 11:25

Was on the phone with Cisco Tech, we found that the dbo.objectSystemGateCallLog table has not been updating after our TMS Upgrade

They suggested to uninstall TMS app and do a fresh install but still utilizing the existing database

Does anyone else have any other suggestions before I implement this or have come across this situation?

Thanks

Anthony

a.khurshid Tue, 09/20/2011 - 13:01

I would say it's worth a shot. You could also go up to 13.1.1 while you're at it too.

Martin Koch Tue, 09/20/2011 - 14:10

One thing i noticed with our TMS13.1 (and X7) is that TMS changes (even if "secure only management" is not set),

the communication to https on the VCS.

I would recomend checking on: https:///externalmanager

if the state is active.

if it is not active its no surpise that movi cdrs are not showing up.

Workarounds I currentlly see:

* activate https on the TMS (I would recomend that anyhow)

* check that the firewall towards your tms allows https

* disable "enforce management settings"

I had also heard that if you use ipv6 tms adds a wrong format for the ip, .....

Martin

awfchan63 Thu, 09/22/2011 - 07:27

On the VCS it was set to https but it failed, so changed it to http and is now active (has been up for one whole day)

disabled the "enforce management settings"

dont know why it would not allow https to work since both boxes are within the same VLAN so it is not going thru a firewall

Martin when you indicated above to activate https on the TMS, where is that on v13.1?

from previous version on the VCS the external manager only had http and was working fine but now with the new version wonder it has two opions - http and https and by default is https.  http should still be working but in TMS I am still not getting any results from the User CDR

Puzzled

Anthony

Martin Koch Thu, 09/22/2011 - 15:26

We run 13.1 and in theory enabling https should do the trick, at least it did for some other tests I did.

If you have your own Win Server + IIS install you would most likely have to enable port 443 / https

and if you use the windows firewall also allow the traffic.

Anyhow, on our own production TMS 13.1 which runs on a Win2003 Server it did not do the trick, as the

in general nice working https service does not work for the VCS.

We have a TAC case open which I need to do a capture of the failing connection.

So I would test if you can connect from an other system in the same network to https:///tms/ if not

check your firewall, if you can you might be affected by our issue as well.

As the VCS is not sending a feedback for the calls (like movi) this issue could cause the missing CDRs.

Setting it to http + disable the enforce management settings or if https works using https look like the workarounds.

If you have the connection up and wait a bit and you still do not see an improvement there might be an additional bug.

mek

robert1000 Thu, 09/22/2011 - 15:37

This is most likely a TMS 13.1 issue.

We have seen this behaviour where TMS force the VCS to use HTTPS for communicating with the TMS, even on X5.* version. We usally just enable HTTPS for the TMS server, that has worked for us.

//Robert

awfchan63 Tue, 09/27/2011 - 08:15

Checked that Windows firewall on the TMS is turned off

https is working on the TMS to and from the VCS Control (both are on the same vlan so no other firewall restrictions)

have set it to http + disable the enforce management settings and not getting errors on the VCS Control for the last 1.5 weeks

tried to do User CDR Reporting but still not getting any results and this is the same CDR for Gatekeeper and VCS stats

We have a TAC open with Cisco and have captured logs for them but no answer back

a.khurshid Tue, 09/27/2011 - 09:21

I don't know that I would categorize it specifically as a TMS 13.1 issue as I have an installation of 12.6 also without Movi CDR reports.

jenshoglin Thu, 09/29/2011 - 06:39

Hi!

I had this issue in an early 13.x version of TMS. In my case the TMS and SQL server had some few seconds of time difference on the clock. I resynced the SQL time/clock and then my movi CDR worked again.

Is your TMS and SQL clock on the exact same time? I hope this will help!

Best regards

Jens

a.khurshid Thu, 09/29/2011 - 11:41

Thanks for the suggestion. According to TMS, there is no time mismatch between my TMS and SQL servers.

awfchan63 Fri, 09/30/2011 - 09:30

I am using the SQL Edition within TMS so time mismatch does not occur here

Anthony

Martin Koch Wed, 11/09/2011 - 09:30

The old Tandberg TAC policy was, first upgrade to the latest, test again and report if the problem still exists.

What exactly do you see (or not see).

Are just the user CDRs missung or all CDRs? (as you also wrote something about the GK CDRs)

Btw, if you delete a system also the CDRs get deleted. Not sure which impact it has when you

would delete and re-add an MCU or VCS, ...

Jens Didriksen Wed, 11/09/2011 - 14:39

We're getting no CDRs at all from either of our two non-clustered VCS-C after upgrading to X7.0.

Currently on TMS 13.1.1 and X7.01.

jens

Martin Koch Wed, 11/09/2011 - 14:42

I guess you saw that TMS 13.1.2 and VCS7.0.2 are out as well.

And btw, TE (E20) 4.1 can now also be found on the ftp server.

Martin Koch Wed, 11/09/2011 - 14:45

Jens, did you check "vcs > system > external manager"

If https is not available on your TMS that is most likely the cause.

That should be fixed with TMS13.1.2 btw.

Jens Didriksen Wed, 11/09/2011 - 15:24

Well, doh!

Thanks Martin - that was pretty much the one and only place I hadn't looked - changed to http and all is well - better revisit TMS and https now...

cheers jens

Martin Koch Wed, 11/09/2011 - 15:28

You better also check that on the tms network settings "Enforce Management Settings on Systems"

is set to no, if not it will revert to https the next day (btw, that behavoir is changed with 13.1.2).

Or like said, better enable https on the TMS, makes sense anyhow!

Jens Didriksen Wed, 11/09/2011 - 16:19

Yeah, I had already set that to "No" - and yes, it makes perfect sense to enable https on TMS

cheers jens

awfchan63 Wed, 11/16/2011 - 09:34

I read the release notes on 13.1.2 in the Reporting section where it resolves issue introduced in TMS 13.1  where call details from a Cisco Telepresence ISDN GW were no longer collected.

Does the above also indicates Cisco VCS as well?

awfchan63 Thu, 11/10/2011 - 09:04

What is missing from the CDR Report in TMS is the Gatekeeper & VCS and User CDR Reports

I am getting Endpoints, MCU and Content Server Reports

Jens Didriksen Thu, 11/10/2011 - 17:39

Yup, same here, despite having made the changes as Martin suggested.

TMS log shows this problem started after upgrading to 13.1, but that was most probably due to the http/https issue, so X7.0 is a strong contender for this one. I opened a case with TAC this afternoon.

awfchan63 Wed, 11/16/2011 - 08:17

Cisco TAC came back and said to blow away the existing TMS and do a fresh install of TMS 13.1.  They indicated that the upgrade path was corrupted somehow eventhough it said that it was successful. 

Martin, so what you are saying is that the CDR report should work with https and not http in communicating with the VCS?

As well as version 13.2 resolves the https issue?

Martin Koch Wed, 11/16/2011 - 15:03

1. enable https on the tms, good idea anyhow and then you do not drop into the mentioned issue.

2. TMS13.1 (if enforce management setting is set) will force the vcs to use https as the external manager

3. TMS13.1.2 will force http if not and https if secure only and enforce management settings are set.

They also work with http and tms13.1, but then enforce management has to be disabled as well.

Anyhow you should check the external manager settings/status from time to time if CDRs are important to you.

Cisco: Sounds like an useful future feature to show a warning on the VCS web interface if the external manager failed!

Also the User CDRs are not ideal, at least I have not seen a way to show real movi2movi call-cdrs incl start and stop time instead of the cumulated value.

Anthony: I would really appreciate if you (and all others) would vote answers

Jens Didriksen Wed, 11/16/2011 - 20:06

Just heard from Cisco TAC, they strongly recommend upgrading to 13.1.2 as this fixes the issue.

The changing of HTTP to HTTPS is part of it, even with protocol set to HTTP and external manager status showing "active" in VCS, TMS 13.1 is unable to properly understand the data it is receiving from VCS due to some API changes - and user CDRs will not be available. The Cisco engineer advised me he had proved this in their test lab, so it shall be interesting to see what happens after I upgrade TMS tomorrow morning.

awfchan63 Thu, 11/17/2011 - 16:58

Interesting to hear that your Cisco TAC says upgrade to 13.1.2 whereas my Cisco TAC to blow away and reinstall fresh under 13.1 and then upgrade to 13.1.2

would like to hear your results in your upgrade

Martin Koch Thu, 11/17/2011 - 17:23

Hi Anthony,

you had 13.1 running before, so did you use a backup of the sql and openDS database?

Then I completly agree on going 13.1 and then 13.1.2.

The end result for Jens, you and me is that we all have 13.1.2 running at the end,

which I can at least say work fine for us.

btw, the upgrade from 12.6 to 13.1 and then to 13.1.2 worked ok for us.

I expect the same for Jens and you.

awfchan63 Thu, 11/17/2011 - 19:16

we have nightly backups of the SQL database along with the Provisioning Database

will need to migrate them over to the new TMS

Then will switch the VCS connection to the new TMS server most likely in December where it is calmer

Jens Didriksen Thu, 11/17/2011 - 18:36

Hi Anthony,

"My" TAC was adament he got user CDRs after upgrading, however, I upgraded this morning and am now running 13.1.2 and X7.02 - and no user/VCS/GK CDRs to be found .

So, a clean 13.1 install might be the way to go - perhaps - however, that is just not an option for us, not at this stage at least.

awfchan63 Thu, 11/17/2011 - 19:19

Sorry to hear about the results Jens,

I was able to build a new VM to install a new TMS running 13.1 right now and as above reply to Martin will restore the database over this weekend. Next steps would be to link the new TMS to the VCS and see if that works or not before I upgrade to 13.1.2.  Or should I upgrade first before the link?

Thoughts?

Would be interesting to hear back from your TAC on what the next steps would be?

Jens Didriksen Sun, 11/20/2011 - 17:38

Just had a WebEx session with TAC, and he identified the reason I was not getting user CDRs right away;

once you have upgraded to 13.1.2 you need to enforce management settings as the VCS' will not otherwise know about the change. I have now turned "Enforce Management Settings" back on, and I'm now getting user CDRs again.

awfchan63 Thu, 11/24/2011 - 11:01

awesome news Jens

btw what version of VCS are you using?

and are you using http or https?

awfchan63 Thu, 02/16/2012 - 10:00

Just a quick update on this issue that i was having, it seems now that the Movi User CDR is working again but have lost information from Sept to Nov. 2011.  I have data starting from Dec 1 2011 and forward.  Not sure why it hust came back have not done any upgrade to TMS since Aug or VCS.   TMS currently 13.1.2 and VCS 6.1

jarnold@basco.com Mon, 02/20/2012 - 08:38

I'd been having Movi User CDR and OpenDS issues ever since upgrading from 12.6 to 13.0. Working through TAC they suggested that I upgrade to TMS 13.1.2, which immediately took care of my OpenDS issues I had been seeing, but User CDR was still an issue. After a couple of hours of going through logs and traces, TAC noticed that all of the User CDR information was being sent to the IPv6 Address on the TMS server (which isn't being used) and blowing the information into Never Land. We disabled IPv6 on the TMS server and User CDR records started working again. I'm now running TMS 13.1.2 and my VCS is running x6.0 (working on upgrading this now) and everything seems to be working fine for me. Not sure if this will help anyone or not, but it was the root of my issue.

kabiru_acer Tue, 08/07/2012 - 01:14

Hi all,

it's OK about User CDR, but most of customers always ask about details of CDR, because you know that MOVI CDR is different with Endpoint or MCU CDRs. in MOVI CDR has no detail call history like time start, from to who, etc.

i try to make like CDR use Syslog server, which capture log file from VCS, but it still need some programs to analysis the log, so only call log be collected. i try by use query about string "call completed" and make analysis about time start and end, but folks this is really-really make me sick, but it works.

so maybe we can make it easier if anybody have solution to how capture call history in VCS then save it as log file.

please advice

Thanks

Actions

Login or Register to take actions

This Discussion

Posted July 18, 2011 at 11:35 AM
Stats:
Replies:44 Avg. Rating:4
Views:4607 Votes:0
Shares:0

Related Content

Discussions Leaderboard