cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4435
Views
15
Helpful
18
Replies

TMS 14.2, TMSPE 1.1, Smart Scheduler Launch Error

cecile gallien
Level 1
Level 1

Hello,

I run a lab for a customer in wich I should test Smart Scheduler but I cannot get it launched. I cann access the tmsagent/portal. I can click th home button and the settings button. I can access findme configuration but smart scheduler would not launch with an error message, otherwise, it would probably be a java issue (from what i read in forums and guides). the message is

There was a problem connecting to the scheduler backend : Could not send Message.

Any idea what this message is related to ?

Thanks,

Cecile

2 Accepted Solutions

Accepted Solutions

Hello All,

This indeed is a bug. Unfortunately I don't have a bug reference for you right now. Once I have one, I'll let you know.

The problem stems from different server configurations  concerning the use of the loopback address...meaning in the case we are  working, they don't use the loopback address on their server. For example, and looking  at the IIS logs and when the loopback address is being used, you should  see something like the following concerning the SS:

2013-05-28 09:03:25 127.0.0.1 POST  /tms/external/booking/bookingservice.asmx -  \ 127.0.0.1 TMSScheduler 200 0 0 31

In the customer's case, they see the following:

2013-05-29 15:50:48 192.168.x.x POST  /tms/external/booking/bookingservice.asmx - 443  \ 192.168.x.x TMSScheduler 200 0 0 31

Note the return of the local IP address vs. the loopback address.

In your case, I would take a look in the IIS  log...after you throw the error in SS...and see if this is what you see.  If so, then this is the same problem and this is the problem we're  fixing...meaning we'll check not only for the loopback address but the  local IP address as well.

cheers,

Dale

View solution in original post

cecile gallien wrote:

[...] I hope you can provide a bug id with a version of resolution.

Bug ID: CSCuh24788. We'll fix it the next possible TMS release – 14.2.2.

Regards,

Kjetil

View solution in original post

18 Replies 18

daleritc
Cisco Employee
Cisco Employee

Hi Cecile,

I see that you posted this awhile go but haven't got an answer, but before I get into a series of questions...have you resolved your issue?

rgds,

Dale

thobonho
Level 1
Level 1

Hi Cecile, it's probably because https is not enabled on TMS server.

Smart Scheduler only works over https.

Hello Thomas,

No it was not a https issue. It was a TMSPE configuration issue as my serveur is working only over certificates and I did not provide the proper one and credetials where wrong.

So I have reached next step. I can launch the smart scheduler and do a booking. I get a license issue now which I am very surpised of :

No more Application Integration licenses available (using: 1). For information on how to order more licenses, please contact Cisco.

Here are the licenses I have on my TMS

- Cisco TMS Application Integration License (1 servers) - I have a Lotus Integration

- Cisco TMS Provisioning Extension (25 active clients/devices)

- Systems (10 systems)

I thought Smart Scheduler was not subject to any licensing ?

Cecile

Considering the fact you must have a valid certificate for enabling https, I would be tempted to think I was kind of right... But anyway, you've been able to figure out the problem and find a solution, it's the most important.

Now, for your licensing issue, I would think it's a bug. How can TMS throw "no more license availabe" when a server license is in fact installed? I've personally never experienced similar issue but I can try to reproduce it.

Dale, any thoughts?

Sounds like  bug as bot the lotus notes integration and the smart scheduler are utilizing the TMSBA. I think I remember once a booking is done from lotus notes the application integration only accepts bookings from that server for the next minutes. But I am not 100% sure about that, but indeed sounds like a bug as you do not need this license to make the smart scheduler work. It might be a side effect of actually having that license. Let´s test it.

/Magnus

Good catch, Magnus and I now understand better what server licenses mean... it's not one license for the local TMS server as I was thinking but a license to allow access to the booking API from 1 (or more) sever(s). In that case, it makes complete sense to lock down the connection on first incoming IP address, except that requests coming from localhost should have been allowed for the Smart Scheduler... As you said, it's to be tested.

Hello,

thanks for reply.

I removed my licence '

Cisco TMS Application Integration License (1 servers)' and now when I use Smart Scheduler I have this funny message :

An option key is required to use this feature.  For more information, please contact Cisco.

I am very perplex. If you need more details let me know.

Thanks,

Cecile

Hi,

The Smart Scheduler should be bypassing the license check.

I have seen this issue at another customer site as well, and we have identified a possible TMS defect that can trigger this problem. Please open a TAC service request so that TAC can investigate the root cause of your problem.

Sent from Cisco Technical Support iPhone App

Oups, I did not reach the last post. So I write it again :

Hello,

thanks for reply.

I removed my licence 'Cisco TMS Application Integration License (1 servers)' and now when I use Smart Scheduler I have this funny message :

An option key is required to use this feature.  For more information, please contact Cisco.

I am very perplex. If you need more details let me know.

Thanks,

Cecile

As Kjetil says above, the SS bypasses the license check and we are tracking another similar issue meaning indeed this could be a bug. Therefore, open a case to TAC...referencing this thread...so has to get proper tracking.

/dale

Hi guys,

Thanks for replies and suggestion of a TAC. I will proceed so as soon as I get access to TSRT. So far I get a message that says my login ID is not set up to access the TAC Service Request Tool - i had access before. I sent an email to tac to check this point and i let you know when i can go next step and provide you the SR if needed.

Regards,

Cecile

Hello All,

This indeed is a bug. Unfortunately I don't have a bug reference for you right now. Once I have one, I'll let you know.

The problem stems from different server configurations  concerning the use of the loopback address...meaning in the case we are  working, they don't use the loopback address on their server. For example, and looking  at the IIS logs and when the loopback address is being used, you should  see something like the following concerning the SS:

2013-05-28 09:03:25 127.0.0.1 POST  /tms/external/booking/bookingservice.asmx -  \ 127.0.0.1 TMSScheduler 200 0 0 31

In the customer's case, they see the following:

2013-05-29 15:50:48 192.168.x.x POST  /tms/external/booking/bookingservice.asmx - 443  \ 192.168.x.x TMSScheduler 200 0 0 31

Note the return of the local IP address vs. the loopback address.

In your case, I would take a look in the IIS  log...after you throw the error in SS...and see if this is what you see.  If so, then this is the same problem and this is the problem we're  fixing...meaning we'll check not only for the loopback address but the  local IP address as well.

cheers,

Dale

Hello Dale,

you are right . I had a look on my IIS logs and I get this line :

2013-05-31 12:18:56 10.77.200.249 POST /tms/external/booking/bookingservice.asmx - 443 VIDEO\cgallien 10.77.x.x TMSScheduler 200 0 0 312

where 10.77.x.x is my TMS Server.

I have a question : would TMS keep using local loopback with https and certificate ? I do not have localhost in my certificate defined as CN, only my FQDN. The idea is to avoid any certificate issue.

I searched a bit further and I found another line in my logs :

2013-05-21 00:03:59 10.77.200.249 POST /tms/external/booking/BookingService.asmx - 80 video\tmslotus 10.77.y.y Axis/1.3 200 0 0 31

where 10.77.y.y is my Lotus Server

Thanks for return and I hope you can provide a bug id with a version of resolution.

Regards,

Cecile

cecile gallien wrote:

[...] I hope you can provide a bug id with a version of resolution.

Bug ID: CSCuh24788. We'll fix it the next possible TMS release – 14.2.2.

Regards,

Kjetil